WO2012080470A1

WO2012080470A1 - Method and system to guarantee ip routing scalability in full-mesh ip offloading over transport network scenario

Info

Publication number: WO2012080470A1
Application number: PCT/EP2011/073056
Authority: WO
Inventors: Francisco Javier Jimenez Chico; María Angeles CALLEJO RODRIGUEZ
Original assignee: Telefonica, S.A.
Priority date: 2010-12-16
Filing date: 2011-12-16
Publication date: 2012-06-21
Also published as: ES2398298A1; ES2398298B1

Abstract

A method between an Internet Protocol layer and a transport layer in a communication network, wherein said communication network comprises a plurality of Internet Protocol/Multi-Protocol Label Switching nodes interconnected through a plurality of transport nodes, for allowing to establish end to end communication between said plurality of Internet Protocol/Multi-Protocol Label Switching nodes, by switching Internet Protocol traffic flows at said transport layer by means of at least one of said plurality of transport nodes, while keeping a hierarchical topology at the Internet Protocol/Multi-Protocol Label Switching control plane level which allows said Internet Protocol/Multi Protocol Label Switching nodes to keep a plurality of adjacencies between Internet Protocol/Multi-Protocol Label Switching nodes without scalability concerns.

Description

METHOD AND SYSTEM TO GUARANTEE IP ROUTING SCALABILITY IN FULL- MESH IP OFFLOADING OVER TRANSPORT NETWORK SCENARIO

DESCRIPTION

FIELD OF THE INVENTION

The present invention relates to the field of communication networks. More in particular it refers to Internet Protocol (IP) routing in large scale multi-layer Internet Protocol (IP) over transport networks.

STATE OF THE ART

In the present context of continuous exponential traffic growth, operators are concerned about the cost of traffic switching. Nowadays, most IP backbones are based on a hierarchy of IP (Internet Protocol)/MPLS (Multi-protocol Label Switching) routers (also called IP/MPLS nodes) interconnected through high speed point-to- point Wavelength Division Multiplexing (WDM) links. This architecture (shown in figure 1 ) has proven to be very useful in the provision of IP residential and business services, due to the tremendous flexibility provided by IP routers.

In the scenario shown in figure 1 , where Layer 2/Layer 1 transport nodes (from now on L2/L1 transport nodes or just transport nodes) are represented by 12, the IP/MPLS routers 1 1 are interconnected by point-to-point connections established through the layer of transport nodes 12. IP topologies usually follow a hierarchical approach, where there is usually one (or more) transit levels between edge routers 21 and the interconnection to Internet 22, as shown in figure 2. This hierarchy permits to efficiently aggregate the traffic, but also maintains the scalability of the IP/MPLS control plane by ensuring that every router will only have a reduced number of neighbours.

However, the use of IP/MPLS routers 1 1 to switch high volumes of transit traffic introduces unnecessary IP/MPLS hops in the IP/MPLS end to end path, potentially introducing additional electro-optic conversions and switching delays, which could hinder the network performance and add unnecessary cost. This drawback could be potentially reduced by switching the transit traffic in lower layers. The concept of IP Offloading consists on the progressive migration of a set of selected large IP traffic flows to be switched directly at the transport (e.g. WDM, OTN, MPLS-TP or Ethernet) layer, avoiding the need for them to be processed in intermediate nodes at the IP layer.

In this sense, IP Offloading concept is claimed to provide significant switching resources savings in IP transit routers, due to the fact that transport technologies can be configured to carry high volumes of network traffic directly to their destinations without the need of IP/MPLS intermediate switching. This approach reduces the required number of interfaces between the transport nodes and the IP/MPLS routers, as well as the the required switching capacity of intermediate routers.

In an extreme scenario, IP/MPLS switching capacity could be restricted to the network edges, so that the the IP topology would consist on a full mesh of edge routers. Figure 3 shows this envisioned architecture, where any two routers at the network edge 31 are directly communicated at the IP/MPLS layer without the need of traversing other intermediate routers, but only a number of L2/L1 transport nodes

32.

However, such a drastic change in the IP topology could create scalability problems to the IP/MPLS control plane. In a full mesh scenario, each border router is connected to N-1 neighbours (being N the total number of IP edge routers) which means that the total number of IGP (Interior Gateway Protocol) adjacencies in the network grows as an N² factor, as it is shown in figure 4, which becomes a scalability problem especially in big networks with hundreds or thousands of nodes. In IGP routing protocols (such as Intermediate System to Intermediate System (IS¬

IS) or Open Shortest Path First (OSPF)), the maintenance of an adjacency typically implies the following actions (the detailed list of messages depends on each protocol): ^■ The exchange of "hello" packets, which are used to keep the information about the status of the link. An interval for sending this kind of packets is defined, and if hello packets are not answered, the link is considered to be down.

^■ The exchange of "link state" packets, which include updated information about the topology. If a failure is detected in an interface, the IP node will flood a link state packet over all its interfaces, and when other node receives this packet, it forwards this packet through all the interfaces except the one it receives the message from.

The scalability problem is especially important when there is a network failure, since if a link state IGP routing protocol is used, all the nodes use the flooding mechanism to send topology update messages to all their neighbours when they receive an update of the topology from any single neighbour. This behaviour results in such a significant amount of messages to be managed in large fully meshed networks, that it could hinder the whole network performance and stability.

There are other drawbacks related to the establishment of a full mesh of adjacencies. For instance, the maintenance of routing adjacencies per router consumes memory and CPU resources due to the need for those resources to receive and process all the IGP control information. In addition, the maintenance of a full mesh of adjacencies could result in an operational challenge if IGP is deactivated to avoid the mentioned issues.

In summary, the implementation of a large, highly meshed IP/MPLS network based on a full IP Offloading over transport network approach has a significant impact in the number of IP/MPLS routing adjacencies (and any other router to router protocols typically running between neighbouring nodes) that has to be established.

These effects could make the IP Offloading solution not scalable for these scenarios. In this context, it becomes essential to develop alternative solutions to allow IP Offloading in fully or highly meshed scenarios, aiming at significant savings for IP/MPLS transit resources but maintaining the IP/MPLS control plane scalability. One of the major advantages of the current hierarchical organization of the IP networks is that it allows deploying a scalable and distributed control plane, as long as the node degree is controlled, that is, as long as the number of neighbours is not too large. That means that the transit nodes serve not only to aggregate traffic but also to aggregate the control information, which reduces the amount of control plane information (associated with control plane adjacencies) that must be managed by the edge nodes.

Figure 5 summarizes the current architecture of a control plane enabled transport node, and its interfaces towards the IP/MPLS client and the rest of the transport network elements (transport network side 56).

On the client side 53 (between the L2/L1 transport node 52 and the IP/MPLS router 51 ), the L2/L1 transport node 52 typically provides the following interfaces to the IP/MPLS router 51 :

^■ One (or more) physical interface 54, which logically provides data plane connectivity across the transport network traversing the data plane controller 50 of the transport node 52. This interface or interfaces, namely data plane interfaces, transparently transport IP/MPLS traffic but also any in-band control plane traffic belonging to the IP/MPLS layer.

^■ One (ore none) physical or logical interface 55, which logically provides an out-of- band transmission means for any potential inter-layer communication control, typically based on GMPLS control plane protocols managed by the GMPLS controller 59 of the transport node 52. The multi-layer control plane interface 55 can be represented as the UNI -User-to-Network Interface- (overlay and augmented models) or an l-NNI -Internal-Network to Network Interface- (peer model), as detailed below. This control plane interface permits to the IP/MPLS routers to request for end to end connectivity across the transport network. Note that this interface is not needed whenever there is no control plane interaction between transport and client networks. On the transport network side 56 (between two L2/L1 transport nodes 52), the L2/L1 transport node 52 typically provides the following interfaces to its neighbouring transport nodes: ^■ A physical or logical interface 58, which logically provides an out-of-band transport of the intra-domain GMPLS control plane (l-NNI). Note that this interface will not be required if the transport network does not have a control plane.

^■ One or more physical interfaces 57, which provide data plane connectivity between the transport network elements. These interfaces transparently transport

IP/MPLS traffic but also any in-band control plane traffic belonging to the IP/MPLS layer.

The main drawback of already existing technology is that the IP/MPLS control plane is transported in-band along with the IP/MPLS data plane, and thus it is transported transparently across the transport network. For this reason, any connection between remote routers will require an adjacency to be established between them, as if there was no transport layer in between. A good starting point to solve this issue would be to benefit from the fact that both the IP/MPLS and the transport layer implement somehow similar control planes. On one side, IP/MPLS layer is usually based on an MPLS control plane (an IGP for internal routing and a label distribution protocol), together with external routing protocols such as Border Gateway Protocol (BGP). On the other side, control plane enabled transport networks are usually based on GMPLS (Generalized Multi-

Protocol Label Switching), an evolutionary adaptation of MPLS to support packet switching, time division and wavelength multiplexing, and which is the state-of-the- art technology to support recovery in an optical network. Current IP/MPLS and GMPLS coordination models are focused on the interconnection of multi-layer networks, but they leave an important part of the global scenario with no solutions yet. There are three interaction models as described below: ^■ IETF (Internet Engineering Task Force) Overlay model ([RFC 4208: G. Swallow et al, "Generalized Multi-protocol Label Switching (GMPLS) User-Network Interface (UNI): Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005]): IETF defines the overlay model so that it provides layer separation (mainly in terms of routing) but it still maintains an end to end signaling. There is no control plane mechanism that allows any kind of coordination to tackle the adjacency growth challenge.

^■ IETF Augmented Model: this model pretends to extend UNI interface capabilities, without reaching full control plane integration. For instance, border equipment on client layer implements IP/MPLS and GMPLS to interact with transport layer. This approach does not solve any adjacency issues, since the goal of this model is that the IP/MPLS border nodes are able to manage the L2/L1 control information. The S- GMPLS (Segmented GMPLS) model also follows this approach as it is proposed e.g. in [Cisco, "Cisco Segmented Generalized Multi-protocol Label Switching for the

IP Next-Generation Network", April 2006].

^■ IETF GMPLS peer model ([RFC3945: Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.]): With a GMPLS peer model, both IP/MPLS and GMPLS networks are considered as a unique one from a control plane point of view, and therefore they are controlled by a single control plane. This implies that both networks use the same routing and signaling protocol instance, and due to integrated routing (peer model), any IP/MPLS node can compute and trigger by itself an end to end path across any number of intermediate IP/MPLS or transport nodes, towards any remote IP/MPLS router. This is due to the fact that IP/MPLS routers implement GMPLS protocols. It is important to note that although this model could potentially solve the mentioned scalability issue (which should be proved by additional studies), it requires to substitute the use of IP/MPLS by GMPLS in the whole IP/MPLS network. For many reasons, this is not a desirable situation for most of telecom operators.

In summary, the different interconnection models do not provide a solution to the adjacency scalability challenge at the IP/MPLS layer in the case of a full mesh topology, while maintaining a separation between the IP/MPLS and transport network. So far, there is no single standard, patent or document in the literature that provides a feasible mechanism to solve the adjacency scalability issue presented before. In this framework, a feasible alternative to solve the scalability issue derived from the IP full mesh scenario could be the substitution of the presently deployed access routers by new equipment with better performance, and supporting a huge number of adjacencies, so that they comply with the requirements mentioned in the previous section. However, this solution would not prevent scalability problem to come up again if the network size grows, for instance if the IP border is placed closer to the end users (as it could be possible in future Fiber To The Home -FTTH- deployment).

The solution presented hereafter proposes another alternative to solve the scalability of adjacencies.

SUMMARY OF THE INVENTION

In order to solve the scalability problem derived from the Internet Protocol full mesh scenario a new coordination method between the Internet Protocol and transport layers is proposed, so that the transport network establishes Internet Protocol/Multi- Protocol Label Switching adjacencies with the border Internet Protocol/Multi- Protocol Label Switching routers, and thus keeps scalability under control. In particular, in one aspect of the present invention a method between an Internet

Protocol layer and a transport layer within a communication network is proposed. Said communication network comprises a plurality of Internet Protocol/Multi-Protocol Label Switching nodes interconnected through a plurality of transport nodes, in which it is possible to establish direct communication between said plurality of Internet Protocol/Multi-Protocol Label Switching nodes, by switching Internet

Protocol traffic flows at said transport layer by means of at least one of said plurality of transport nodes, without involving any intermediate Internet Protocol/Multi- Protocol Label Switching nodes. The method allows highly or fully meshed Internet Protocol/Multi-Protocol Label Switching architectures while keeping a hierarchical logical topology for Internet Protocol/Multi-Protocol Label Switching control plane, which allows said Internet Protocol/Multi-Protocol Label Switching nodes to keep a plurality of adjacencies to remote Internet Protocol/Multi-Protocol Label Switching nodes without scalability concerns. The method comprises establishing an end-to- end communication between two Internet Protocol/Multi-Protocol Label Switching nodes of said communication network using at least one of said interconnection transport nodes and is characterized in that said at least one interconnection transport node is configured to provide to each of said two Internet Protocol/Multi- Protocol Label Switching nodes:

^■ at least a physical interface, configured to provide data plane connectivity and to transport both IP/MPLS traffic and also in-band control plane belonging to the Internet Protocol/Multi-Protocol Label Switching layer

^■ and a second physical interface, configured to provide out-of-band control plane communication between said Internet Protocol/Multi-Protocol Label Switching node and said transport network, said second physical interface comprising two logical interfaces: a first logical interface configured to interchange multi-layer control plane information, and a second logical interface running an Interior Gateway routing Protocol for the Internet Protocol/Multi-Protocol Label Switching layer, used to exchange, at least, control and link state messages.

Optionally, two Generic Routing Encapsulation tunnels are established to separate said two logical interfaces on top of the physical interface, according to the Request For Comments 2784, in said second physical interface in order to carry said two logical interfaces.

If said end-to-end communication between two Internet Protocol/Multi-Protocol Label Switching nodes uses more than one of said interconnection transport nodes, each one of said transport nodes further comprises the following interfaces to each one of the rest of said interconnection transport nodes:

^■ at least a physical interface, configured to provide data plane connectivity and to transport both IP/MPLS traffic and also in-band signalling belonging to the Internet Protocol/Multi-Protocol Label Switching layer ^■ and a second physical interface, configured to provide out-of-band control plane communication between transport nodes, said second physical interface comprising two logical interfaces: a first logical interface configured to interchange transport layer control plane information, and a second logical interface running an Interior Gateway routing Protocol for the Internet Protocol/Multi-Protocol Label Switching layer, used to exchange, at least, control and link state messages.

Like in the previous case, optionally, two Generic Routing Encapsulation tunnels are established to separate said two logical interfaces on top of the physical interface according to the Request For Comments 2784 in said second physical interface in order to carry said two logical interfaces.

Preferably, said first logical interface comprised in said second physical interface between two transport nodes is implemented according to the Internal Network to Network Interface specification and said second logical interface comprised in said second physical interface between one transport node and one Internet Protocol/Multi-Protocol Label Switching node is configured with the maximum cost value available for the protocols running on it, so as to avoid the propagation of data plane traffic.

Besides, in a preferred embodiment, said first logical interface comprised in said second physical interface between one transport node and one Internet Protocol/Multi-Protocol Label Switching node is implemented according to the User to Network Interface specification.

In a preferred embodiment, the Interior Gateway routing Protocol, running on any of said second logical interfaces is, alternatively, the Intermediate System to Intermediate System protocol or the Open Shortest Path First protocol, with any potential extension.

In an alternative embodiment, any of said first logical interfaces is not needed due to lack of control plane information interchange. In an alternative embodiment, any of said second logical interfaces is directly transported over a dedicated physical interface, without the need for Generic Routing Encapsulation. In another aspect of the invention a system for establishing an end to end communication in a communication network wherein said communication network comprises a plurality of Internet Protocol/Multi-Protocol Label Switching nodes interconnected through a plurality of transport nodes is presented. The system comprises means for carrying out the method previously described.

In a preferred embodiment, each one of said plurality of transport nodes comprises an Internet Protocol Interior Gateway routing Protocol controller module, wherein said module is configured for:

^■ establishing an Interior Gateway routing Protocol adjacency using an Interior Gateway routing Protocol to communicate with each of said Internet Protocol/Multi- Protocol Label Switching nodes it is connected to, and to the rest of said plurality of transport nodes it is connected to and

^■ exchanging and processing Internet Protocol/Multi-Protocol Label Switching control plane messages with said Internet Protocol/Multi-Protocol Label Switching nodes and the rest of transport nodes.

Preferably, said Internet Protocol Interior Gateway routing Protocol controller module comprises two logical interfaces: a first logical interface used to exchange Internet Protocol/Multi-Protocol Label Switching routing information between an Internet Protocol/Multi-Protocol Label Switching node and the transport node and a second logical interface used to exchange Internet Protocol/Multi-Protocol Label Switching Interior Gateway routing Protocol information between transport nodes.

Finally, a computer program comprising computer program code means adapted to perform the method previously described is provided.

BRIEF DESCRIPTION OF THE DRAWINGS To complete the description and in order to provide for a better understanding of the invention, a drawing is provided. Said drawing forms an integral part of the description and illustrates a preferred embodiment of architecture for implementing the method of the invention, which should not be interpreted as restricting the scope of the invention, but just as an example of how the invention can be embodied.

Figure 1 depicts the general architecture of a multilayer IP/MPLS over transport network.

Figure 2 shows a hierarchical topology with various transit levels between edge routers and connection to Internet.

Figure 3 shows full IP Offloading approach architecture.

Figure 4 shows a scenario with a full mesh of adjacencies.

Figure 5 shows current architecture and interfaces of control and data planes enabled in a transport node both at the client side and the network side.

Figure 6 shows the data plane topology (left) and control plane topology (right) according to an embodiment of the present invention.

Figure 7 illustrates a basic schema of the present invention, including the new interfaces and modules at the transport and IP/MPLS nodes.

Figure 8 depicts the basic schema of the invention from an end-to-end point of view.

DESCRIPTION OF PREFERRED EMBODIMENTS

This disclosure provides a novel inter-layer coordination method between the IP and transport layers, to solve the adjacency scalability problem in highly or fully meshed IP/MPLS networks. With this mechanism, the L2/L1 transport nodes provide a L3 adjacency to their IP/MPLS client nodes, and this way a hierarchical topology from a control plane perspective is maintained, which permits the edge IP/MPLS routers to establish a number of adjacencies without scalability concerns.

The method is based on the separation of IP/MPLS data and control channels in the link between the router and the transport node, and the propagation of the IGP routing information of the IP/MPLS layer through out-of-band control plane mechanisms across the transport network 56. As depicted in figure 6, the goals of this solution are the following:

^■ To keep the data plane topology 63 as a full mesh between border IP/MPLS routers 61 .

^■ To define a hierarchy at the control plane 64 for IGP information interchange, considering the interaction between the IP/MPLS routers 61 and the L2/L1 transport nodes 62. The transport nodes 62 work as aggregators of this information, preventing the flooding problems which appear in an IP/MPLS full mesh topology when a network failure is detected.

Figure 7 illustrates the basis of the proposed method. As it was described previously the L2/L1 transport network element has a User to Network (UNI) interface 76 and an Internal Network to Network (l-NNI) interface 77. But the invention itself is based on the specification of a new element inside the L2/L1 transport network element 62 72, named IP IGP controller module 75, able to manage the IGP routing control information from the IP/MPLS routers 61 71 . This IP IGP controller 75 provides two interfaces:

^■ The CCPCh UNI (Client Control Plane Channel - User Network Interface) 73 used to exchange the routing information related to the IP/MPLS layer between the IP/MPLS router 61 71 and the L2/L1 transport node 62 72.

^■ The CCPCh l-NNI (Client Control Plane Channel - Internal Network to Network Interface) 74 which is used to send the IGP information related to the IP/MPLS layer between the L2/L1 transport nodes 62 72.

Note that, in a preferred embodiment, the CCPCh UNI 73 and the CCPCh l-NNI 74 could implement the same functionality, and that the IP IGP controller 75 could be a regular routing and packet processing controller as in IP/MPLS networks. In alternative embodiments these interfaces and module could be extended with additional features. It is important to state that the CCPCh UNI 73 is configured in such a way that the IP/MPLS router 61 71 never uses this interface to forward data plane packets.

Next, the following points are described in depth:

^■ Specification of the new IP IGP Controller module 75 located in the L2/L1 transport node 62 72.

^■ Specification of the CCPCh UNI 73 as a full adjacency at the IP/MPLS IGP level.

^■ Specification of the CCPCh l-NNI 74 as a full adjacency at the IP/MPLS IGP level.

^■ Configuration of the IGP procedures at the IP/MPLS routers 61 71 in order to avoid the flooding of control packets when a failure is detected.

Specification of the new IP IGP controller module 75 located in the L2/L1 transport node 62 72

This module 75 is in charge of establishing an IGP adjacency using OSPF (Open Shortest Path First) or IS-IS (Intermediate System to Intermediate System) routing protocols with both the IP/MPLS routers 61 71 and the other L2/L1 transport nodes 62 72. Therefore this module 75 exchanges IGP HELLO packets and Link State packets with the IP/MPLS routers 61 71 and L2/L1 transport nodes 62 72 following the format specified for each specific routing protocol. This module also has a loop- back interface which is known by the rest of the IP/MPLS nodes 62 72 by means of said routing protocols.

The IP IGP controller module 75 is, therefore, in charge of maintaining the exchange of IGP information across the CCPCh UNI 73 and CCPCh l-NNI 74.

Preferably, this module 75 is implemented following the standards to process signaling information and keeping the link state database with the topology at the IP/MPLS level.

Specification of the CCPCh UNI 73 as a full adjacency at the IP/MPLS IGP level In a preferred embodiment, this interface 73 is setup using the same physical interface also used to set up of the UNI interface 76. In order to separate both interfaces, the new control interface between the IP/MPLS router 61 71 and the L2/L1 transport nodes 62 72 is set up in the following way:

^■ Two Generic Routing Encapsulation (GRE) tunnels are established according to [RFC 2784: D. Farinacci et al, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000] in the physical interface dedicated to manage the control interfaces between the L2/L1 transport nodes 62 72 and the IP/MPLS nodes 61 71 , in such a way that the physical interface dedicated to control information between the IP/MPLS routers 61 71 and the L2/L1 transport nodes 62 72 supports two logical interfaces 73 76.

^■ One logical interface 76 is used to manage the data interface implementing the UNI specification, e.g. as described in [OIF, "User Network Interface (UNI) 2.0 Signaling", February 2008].

^■ The other logical interface 73 is configured to run an IGP routing protocol such as IS-IS or OSPF.. All the IGP control messages are interchanged through this interface (that means, both HELLO and link state packets are sent through this interface). This interface 73 is configured with a much higher cost than the cost associated to the links between the IP/MPLS nodes 61 71 , so as to avoid data traffic to be sent over it. For example a cost of 65535 is defined for this link, since it is the maximum value for the protocols.

Note that in an alternative embodiment, the CCPCh UNI 73 is established over a dedicated physical interface, so that the GRE encapsulation is not needed. This could be the case if no UNI interface 76 is implemented, of if it runs over a dedicated physical interface.

In an alternative embodiment, the interface 76 additionally implements other protocols than the UNI without any impact. Specification of the CCPCh l-NNI 74 as a full adjacency at the IP/MPLS IGP level

In a preferred embodiment, this interface is setup using the same physical interface also used to set up of the l-NNI interface 77. In order to separate both logical interfaces, the new control interface, between the adjacent L2/L1 transport nodes 62 72, is set up in the following way:

^■ Two Generic Routing Encapsulation (GRE) tunnels are established according to [RFC 2784: D. Farinacci et al, "Generic Routing Encapsulation (GRE)", RFC 2784,

March 2000] in the physical interface dedicated to manage the control interfaces between the L2/L1 adjacent transport nodes 62 72 in such a way that the physical interface dedicated to control information between the L2/L1 adjacent transport nodes supports two logical interfaces 74 77.

^■ One logical interface 77 is used to manage the data interface implementing the I- NNI which is in charge of carrying the GMPLS control plane as described in [RFC 3495: Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004].

^■ The other logical interface 74 is configured to run an IGP routing protocol such as IS-IS or OSPF. All the IGP control messages are interchanged through this interface (that means, both HELLO and link state packets are sent through this interface). This interface 74 is not used for data transport since the L2/L1 nodes 62 72 that are interfacing the IP/MPLS routers 61 71 are configured in such a way that they do not carry data traffic; therefore the cost assigned to this IGP interface is not relevant.

In an alternative embodiment, the CCPCh l-NNI 74 is established over a dedicated physical interface, so that the GRE encapsulation is not needed. This could be the case if no l-NNI interface 77 is implemented, of if it runs over a dedicated physical interface.

Configuration of the IGP at the IP/MPLS routers 61 71 Figure 8 depicts thoroughly end to end system architecture for a specific communication between two remote edge routers 61 71 81 interconnected by a number of transport nodes 62 72 82.

In order to allow the IP/MPLS nodes 61 71 81 to be configured in a full mesh topology 63 and to assure the scalability of the solution, the following steps must be followed:

^■ The IP/MPLS nodes 61 71 81 establish end-to-end one transport network connections to each other using the L2/L1 transport network 88 through the UNI signaling interface 76 86. This way, all the IP/MPLS edge nodes 61 71 81 have a full mesh of point to point interfaces between them, as it is depicted in the data plane link 79 89 shown in figure 8 for a specific communication between two remote edge routers 61 71 81 .

^■ Every single data plane link 79 89 is configured as an IGP interface in the following way:

o The cost associated to this interface typically depends on the bandwidth available (typically, 1 Gbps or 10Gbps).

o The interface is configured so that it belongs to a mesh group, and it is configured as blocked with a similar behavior as it is specified in the [RFC 2963: R. Balay et al. "IS-IS Mesh Groups", RFC 2963, October 2000]. In this way, through this interface HELLO messages are exchanged in order to keep the state of the interface, but no information about link states is sent.

^■ The link state information is managed instead through the CCPCh UNI interface 73 83 that is configured as an IGP interface with all the control messages allowed.

^■ Once the IGP routing is configured, the set up of MPLS is done thanks to the activation of a protocol, such as the Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP), over the data interface 79 89.

The main benefit of this solution is that it allows the transport network 88 (typically the transport network border nodes) to provide IP/MPLS adjacencies to client IP/MPLS routers 61 71 81 , and it permits to transfer IP/MPLS control plane information across the transport network 88 towards the rest of remote IP/MPLS clients 61 71 81 . This mechanism supports the implementation of IP full mesh scenarios, with the consequent avoidance of intermediate IP/MPLS processing in transit IP routers due to IP offloading, and without a significant impact on IP/MPLS control plane scalability. In particular, the presented solution guarantees the following:

^■ The state of all the data links 79 89 is maintained since all the IP/MPLS nodes 61 71 81 keep an IGP adjacency.

^■ The problem of the flooding is avoided since the IGP adjacencies between the IP/MPLS nodes 61 71 81 are configured as belonging to a mesh group and with a blocked configuration, and the information about the topology updates is sent to the L2/L1 transport nodes 62 72 82 through the new CCPCh UNI interface 73 83, which is configured as full IGP interface with a very high cost that results in its utilization for carrying out only the link state information.

^■ The L2/L1 transport nodes 62 72 82 aggregate and distribute the IGP information in a scalable way by just running the IGP protocol in the new IP IGP controller module 75 85 of the node 62 72 82.

In this way, as previously stated, the full mesh topology is maintained in the data plane (the IP/MPLS nodes 61 71 81 only send data information through the data plane links set up through the L2/L1 transport nodes 62 72 82 without any packet processing and the IGP topology updates are aggregated thanks to the new specified IP IGP Controller module 75 85, the CCPCh UNI 73 83 and l-NNI 74 84, as well as thanks to the appropriate configuration of the IP/MPLS nodes 61 71 .

In contrast to alternative solutions based on pure GMPLS (e.g. the GMPLS peer model), this solution works with already deployed IP/MPLS equipment and only requires minor changes in these elements. Moreover, it permits to keep separated control planes both at the IP/MPLS and the transport layer, and subsequently, to better promote the deployment of full IP offloading architectures in multi-provider scenarios.

Although this invention has been designed with the full mesh of IP/MPLS routers 61 71 81 in mind, it could be used in partial meshing scenarios too.

Claims

1 . - A method between an Internet Protocol layer and a transport layer in a communication network, wherein said communication network comprises a plurality of Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ) interconnected through a plurality of transport nodes (62 72 82), for allowing to establish end to end communication between said plurality of Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ), by switching Internet Protocol traffic flows at said transport layer by means of at least one of said plurality of transport nodes (62 72

82) , while keeping a hierarchical logical topology at the control plane level which allows said Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ) to keep a plurality of adjacencies among them without scalability concerns, the method comprising establishing an end-to-end communication between two Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ) of said communication network using at least one of said interconnection transport nodes (62 72 82), the method being characterized in that said at least one interconnection transport node (62 72 82) is configured to provide to each of said two Internet Protocol/Multi- Protocol Label Switching nodes (61 71 81 ):

^■ at least a first physical interface (79 89), configured to provide data plane connectivity and to transport both IP/MPLS traffic and also in-band control plane belonging to the Internet Protocol/Multi-Protocol Label Switching layer;

^■ a second physical or logical interface, configured to provide out-of-band control communication between said two Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ) and said transport network (88), said second physical interface comprising two logical interfaces: a first logical interface (76 86) configured to interchange multi-layer control plane information, and a second logical interface (73

83) running an Interior Gateway routing Protocol for the Internet Protocol/Multi- Protocol Label Switching layer, used to exchange, at least, control and link state messages.

2. - The method of claim 1 , wherein two Generic Routing Encapsulation tunnels are established to separate said two logical interfaces on top of the physical interface, according to the Request For Comments 2784, in said second physical interface in order to carry said two logical interfaces.

3. - The method of any preceding claim, wherein if said end-to-end communication between two Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ) uses more than one of said interconnection transport nodes (62 72 82), each one of said transport nodes (62 72 82) further comprises the following interfaces to each one of the rest of said interconnection transport nodes (62 72 82): ^» at least a first physical interface (79 89), configured to provide data plane connectivity and to transport both IP/MPLS traffic and also in-band control plane belonging to the Internet Protocol/Multi-Protocol Label Switching layer;

■ a second physical or logical interface, configured to provide out-of-band control plane communication between transport nodes (62 72 82), said second physical interface comprising two logical interfaces: a first logical interface (77 87) configured to interchange transport layer control plane information, and a second logical interface (74 84) running an Interior Gateway routing Protocol for the Internet Protocol/Multi-Protocol Label Switching layer, used to exchange, at least, control and link state messages.

4. - The method of claim 3, wherein two Generic Routing Encapsulation tunnels are established to separate said two logical interfaces on top of the physical interface, according to the Request For Comments 2784 in said second physical interface in order to carry said two logical interfaces.

5. - The method of either claim 3 or 4, wherein said first logical interface (77 87) comprised in said second physical interface between two transport nodes (62 72 82) is implemented according to the Internal Network to Network Interface specification.

6.- The method of any preceding claim, wherein said second logical interface (73

83) comprised in said second physical interface between one transport node (62 72 82) and one Internet Protocol/Multi-Protocol Label Switching node (61 71 81 ) is configured with the maximum cost value available for the protocols running on it, so as to avoid the propagation of data plane traffic.

7. - The method of any preceding claim, wherein said first logical interface (76 86) comprised in said second physical interface between one transport node (62 72 82) and one Internet Protocol/Multi-Protocol Label Switching node (61 71 81 ) is implemented according to the User to Network Interface specification.

8. - The method of any preceding claim, wherein said Interior Gateway routing Protocol, running on any of said second logical interfaces (73 83 74 84) is the Intermediate System to Intermediate System protocol.

9. - The method of any claims from 1 to 8, wherein said Interior Gateway routing protocol, running on any of said second logical interfaces (73 83 74 84) is the Open Shortest Path First protocol.

10.- The method of any preceding claim, wherein any of said first logical interfaces is not needed due to lack of control plane information interchange.

1 1 . - The method of any preceding claim, wherein any of said second logical interfaces is directly transported over a dedicated physical interface, without the need for Generic Routing Encapsulation.

12. - A system for establishing an end to end communication in a communication network, wherein said communication network comprises a plurality of Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ) interconnected through a plurality of transport nodes (62 72 82), wherein said system comprises means for carrying out the method according to any preceding claim.

13. - The system of claim 12, wherein each one of said plurality of transport nodes (62 72 82) comprises an Internet Protocol Interior Gateway routing Protocol controller module (75 85), wherein said module (75 85) is configured for:

^■ establishing an Interior Gateway routing Protocol adjacency using an Interior Gateway routing Protocol to communicate with said Internet Protocol/Multi-Protocol Label Switching nodes (61 71 81 ) and the rest of said plurality of transport nodes (62 72 82); ^■ exchanging control and link state messages related to the Internet Protocol/Multi-Protocol Label Switching layer with said Internet Protocol/Multi- Protocol Label Switching nodes (61 71 81 ) and the rest of transport nodes (62 72 82).

14.- The system of claim 13, wherein said Internet Protocol Interior Gateway routing Protocol controller module (75 85) comprises two logical interfaces: a first logical interface (73 83) used to exchange Internet Protocol/Multi-Protocol Label Switching routing information between an Internet Protocol/Multi-Protocol Label Switching node (61 71 81 ) and the transport node (62 72 82) and a second logical interface

(74 84) used to exchange Internet Protocol/Multi-Protocol Label Switching routing Protocol information between transport nodes (62 72 82).

15.- A computer program comprising computer program code means adapted to perform the method according to any claims from 1 to 1 1 when said program is run on a computer, a digital signal processor, a field-programmable gate array, an application-specific integrated circuit, a micro-processor, a micro-controller, or any other form of programmable hardware.