COMPUTING A PATH IN A LABEL SWITCHED NETWORK

Field of the Invention

The present invention relates to the field of telecommunications and more particularly to a method and apparatus for computing a path in a labels switched network.

Background of the invention

The IETF document RFC 4655 describes an architecture for a Path Computing Element (PCE)-based model, which addresses the problem space of path computation in large, multi-domain, multi-region or multi-layer networks. It distinguishes between stateful PCEs and stateless PCEs. According to RFC4655, there is a strict synchronization in the former case between the PCE and not only the network states in terms of topology and resource information, but also the set of computed paths and reserved resources in use in the network.

Accordingly, in order to have an efficient stateful PCE, the PCE should know if the computed path has been used and consequently the related reserved resources. In particular when multiple PCEs are used for path computation in a network, a tight synchronization between the states stored in each PCE is

required. This increases control plane traffic and requires complex mechanisms and computation resources.

The present solution for stateful PCEs is based on the routing protocol OSPF- TE to gather the network resources and their availability. However, it would be complicated to Jink modifications of the network resource availability with information about adoption or non-adoption of the proposed path solutions.

Summary of the Invention

It is therefore an object of the present invention to provide a method and related apparatus for computing a path in a labels switched network, which is more efficient than known solutions but less complex to implement.

These and other objects are achieved by a method computing a path in a label switched network according to claim 1 , a path computing element according to claim 7 and a path computation client according to claim 8.

In particular, according to the invention, a stateful path computing element stores in a traffic engineering database topology and resource information about the label switched network, The path computing element receives a path computation request from a path computation client and computes a path serving this path computation request using the topology and resource information. It transmits then a path computation reply to the path computation client including the computed path. The path computation client returns then to the path computing element an acknowledgment indicating whether it has used the proposed path to set up a label switched path or not. This link state information can then be used by the path computing element for future path computations.

Brief description of the drawings

A preferred embodiment of the present invention will now be described with reference to the accompanying drawings in which

Fig. 1 shows α schematic diagram of a data network in which the present invention is applied;

Fig. 2 shows the data network of claim 1 after a set-up of a label switched path;

Fig. 3 shows a detailed schematic diagram of a Path Computing Element

(PCE) in accordance with the present invention and comprised in the data network of Fig. 1 ; and

Fig. 4 shows a schematic block diagram of a network element in accordance with the present invention.

Detailed description

Fig. 1 shows a schematic diagram of a telecommunications network NET. It contains a first network node Nl, a second network node N2 and number of intermediate network nodes nl -n9.

In the context of the present invention telecommunications network NET can be identified with a label switched packet data network operated in accordance with the principles of Multiprotocol Label Switching (MPLS) or Generalised Multiprotocol Label Switching (GMPLS). Network paths are established as

Label Switched Paths (LSPs) by means of an appropriate signalling protocol as known to a person skilled in the art. A commonly known protocol which is appropriate in the context of the present invention is OSPF (Open Shortest Path First). OSPF uses a Link State Database (LSDB) or Traffic Engineering Database (TED) for routing purposes, wherein such database comprises information which reflect network topology.

In accordance with RFC 4655, which is incorporated by reference herein, path computation is performed by a Path Computing Element (PCE), which is an

entity, i.e., α component, an application, or a network node that is capable of computing a network path or route, based on network topology and resource information and applying computational constraints, as explained in detail in Section 3 of RFC 4655.

Network node Nl has a Path computation client (PCC) function PCCI , which is connected to a Path Computing Element PCEl , PCEl is a stateful PCE, which means that it keeps in memory established LSPs and previous computed paths. PCEl comprises a TED for path computing purposes.

Building said database and updating it in case of topology changes requires an exchange of routing information between elements of the telecommunications network NET. In accordance with the OSPF protocol, which more generally can be referred to as an Interior Gateway Protocol (IGP), the routing information are provided through flooding which occurs regularly based on an incompressible time interval in accordance with the IGP used (such as OSPF, IS-IS, RIP, or IGRP).

In figure 1 , PCEl receives network topology and resource usage information via protocol IGP from other network devices (not shown). A Traffic Engineering Database (TED) is implemented in PCEl and the information received via IGP is used to populate this database, as will be explained in detail below with reference to appended figure 3. For path setup and resource reservation, network nodes Nl , N2, and nl -n9 in figure 1 comprise respective signaling engines (not shown in Fig. 1), as will be explained in detail below with reference to appended Fig. 4.

Network node Nl is equipped with respective a Path computation client function PCCl , which can address Path Computation Element PCEl . When Nl whished to establish a path to network node N2, indicated as dashed arrow in figure 1 , it sends a corresponding path computation request REQ from its PCCl function to a PCE, which is by way of example in the present embodiment PCEl . It should be noted that in the general case, there can be more than one PCE and PCCl can address different PCEs with requests. The

choice of the addressed PCE for a particular computation request can be diverse and can depend for example on configuration , load status of the PCEs, network knowledge of the PCEs, security choice, routing optimization algorithms available on PCEs, etc.

PCEI computes a path P using the topology and resource information in its TED and returns the computed path in a path computation reply PCR to PCCl .

After PCEl has returned the computed path P, the resources used for this path should not be assigned again for another path computation request. On the other hand, it takes a while until the change in the available resource will be propagated through the IGP.

In figure 2, a computed path P is shown by way of example along the dashed line leading from NI over routing nodes nl - n8 - n5 - no to destination node N2. Path setup is initiated by network node Nl in a conventional manner using the RSVP (Resource reSerVation Protocol). However, Nl is not forced to use a computation result and establish the computed path or the establishment can fail. Therefore, according to a basic idea of the present invention, a direct communication between the PCE and the PCC is introduced. According to the invention, the PCCl sends an acknowledgment ACK back to PCEl indicating whether it has been used the computed path or not.

In a preferred embodiment, the acknowledgment is based on the existing protocol PCEP, i.e. the communication protocol between PCC and PCE. The PCEP is thus enhanced by a notification message (PCNtf message) to advertise a PCE that the path result sent to the PCC is used or not. This notification message will contain an Request Parameter (RP) object to refer to a particular path computation request. Such RP object is already existing in the PCEP notification protocol message as an option. In the preferred embodiment, a new NOTIFICATION object is defined. This is done by defining in the standard NOTIFICATION object structure a new Notification-type which specifies the class of notification. This class will be called herein "ERO path usage".

Moreover, two Notification-values are also defined providing the important addition information related to the nature of the notification i.e. usage "YES/ERO applied" or "NO/ERO not applied".

The RP object is specified in the context of PCEP by the IETF (see Internet Draft draft-ietf-pce-pcep-08.txt, which is incorporated by reference herein) and is used to specify various characteristics of the path computation request.

The NOTIFICATION object is exclusively carried within a PCNtf message and can either be used in a message sent by a PCC to a PCE or by a PCE to a PCC so as to notify of an event. The referred Internet Draft describes also the format of such NOTIFICATION objects:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+ - + - + - + - + - + - + - + - + -H H -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I Reserved | Flags | NT | NV |

// Optional TLV(s) //

+ I - + - + - + -+- + - + - + - + - + - + - + -+- + - +-+- + - + -+- + - + -+- + — H- + - + - + - + - + - + -+- + - +i

It contains 8 bit for a Notification Type (NT), which specifies the class of notification, and 8 bit for a Notification Value (NV), which provides addition information related to the nature of the notification, followed by a number of optional TLV (Type, Length, Value) fields.

In the preferred embodiment, a specific value ("ERO path usage") exists for the Notification Type (NT) field to identify that the NOTIFICATION object relates the usage status of one ERO given in a PCErep message by the PCE to the PCC in response of a PCEreq. The value of the NV field will specify if the ERO is used or not. Two possible value are: "YES/ERO applied" or "NO/ERO not applied". A TLV named ERO is therefore included in the NOTIFICATION object that specifies the related path.

Optionally, as a further improvement, a TLV named REASON may be included in the NOTIFICATION object if the value of the NV field is "Not Established" that specifies the reason why the proposed path has not been established.

Through the information about the usage of the computed path, the PCEs can improve with a higher precision the states of the network. Implementation of a stateful PCE is hence simplified. The blocking probability will be lower when paths are computed by a stateful PCE rather than by a stateless PCE.

According to known path computation models, the PCE is informed of the path set-up by analyzing OSPF-TE messages to determine the network resource availabilities. A PCE can then compare this new information with the previous its computed and proposed routes to find out the "chance of success" of its proposed routes and, if necessary change its behavior.

The introduction of a direct acknowledgement from the PCC to the PCE reduces the computational effort in the PCE. Moreover, it has no impact on the control plane messages and does not increase the complexity of the control plane.

The optional reason can further improve the computation. On the other hand, a simple ,,No" value can also be used by a PCC, for example, if this PCC had requested the same path computation to several PCEs and then choose only one of them among all the responses path for the signaling. Then the PCC can send to the non chosen PCEs the notification message with the ERO usage object with a "No" value. In such case the PCC has no reason to justify its choice to the PCEs.

In the exemplary embodiment of figures 1 and 2 , a network architecture with only a single PCEs is shown. It will be appreciated by a skilled person that the present invention is by no means limited to such an architecture. Various other PCE architectures can be devised, as explained in detail in Section 5 of RFC 4655.

While for the sake of simplicity only node Nl is shown in figures 1 and 2 with a PCC function, this is not necessarily the case, and the present invention also encompasses other architectures where multiple or all network elements have a PCC function.

Figure 3 shows a detailed schematic diagram of a Path Computing Element (PCE) in accordance with the present invention and comprised in the data network of Fig. 1. PCE 31 has a control plane signaling engine 32 for receiving link state information from other entities in the network via control plane messages using an IGP such as OSPF-TE. PCE 31 stores the link state information in a Traffic Engineering Database (TED) 34. Furthermore, PCE 31 comprises processing means 33 for computing network paths based on the link state information stored in the TED 34. An interface 35 serves for the communication with a PCC using PCEP.

Path computation requests are received at interface 35 and transferred to processor 33, which computes a path corresponding to the request. The result is transferred back by interface 35 to the PCC. According to the invention PCC then sends back an acknowledgement indicating whether the proposed path has been used or not. This acknowledgement is also received at interface 35, transferred to processor 33, and stored as status information in TED 34. Alternatively, link state information derived from acknowledgements can also be stored in an extra memory rather than in a TED.

Fig. 4 shows a schematic block diagram of a network element in accordance with the present invention. As already mentioned above, network element Nl , here generally depicted as network element 40, comprise signaling engine 41 including first means 42 and second means 43. The first means 42 is devised for generating messages to inform other network elements in data network NET (Fig. 1 ) in case of a particular link reaching a respective predefined filling capacity or in case of a detected link failure. As will be appreciated by those skilled in the art, the above-mentioned functionality of said first means 42 corresponds to a functionality of standard Resource reSerVation Protocol-

Traffic Engineering (RSVP-TE), which is one of the most important signaling protocols in the internet protocol suite.

As further known to a person skilled in the art, RSVP includes sending a special message from a sender in a data network to a receiver, which message is called an RSVP Path Message. This type of message is employed for detecting a possible path from the sender to the receiver. Passed routers are logged and notified to the receiver. Along the path, the receiver sends a further message called RSVP Reservation Message. Routers along the path reserve resources according to the specification comprised in the RSVP Reservation Message or send back an error message. If the RSVP Reservation Message reaches the sender, the latter may rely on the reservations and establish the LSP.

The second means 43 is a PCEP interface which serves for communication with a PCE. When a new path has to be established, network element 40 sends at PCEP interface 43 a path computation request to an associated PCE. When the PCE has computed a path, a proposal for the path will be received at interface 43. According to the invention, when the path is established, network element 40 sends at interface 43 an acknowledgment indicating whether the path uses the route proposed by the PCE or not and optionally a reason why the proposed path was not used.

As will be appreciated those skilled in the art, the present invention is not necessarily limited to the use of the OSPF routing protocol: any other future standard protocol which is able to gather network information for the PCEs can be employed instead. Furthermore, the present invention is not limited to the use of existing RSVP messages for notifying the PCEs, As an alternative, Path Computation Element (PCE) Communication Protocol (PCEP) could be employed (as disclosed, e.g., at http://www.ietf.org/internet-drafts/draft-ietf- pce-pcep-02.txt). In this case, however, a PCC should exist on the node that wishes to advertise.