Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND APPARATUS FOR SERVICE PROVISION IN A COMMUNICATION NETWORK
Document Type and Number:
WIPO Patent Application WO/2018/133931
Kind Code:
A1
Abstract:
A method (100) for managing the provision of a service between origin and destination endpoints over a communication network is disclosed. The communication network comprises at least two Autonomous Systems (ASs). The method comprises defining an Abstraction and Control of Traffic Engineered Networks (ACTN) Virtual Network (VN) between the origin and destination endpoints (110), the VN comprising a specified tunnel in each of the ASs. The method further comprises defining, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel (120) and binding the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint for the service as routing next hop only to traffic corresponding to the service (140). Also disclosed are a management element (300, 400) for managing the provision of a service between origin and destination endpoints over a communication network and a computer program configured to carry out a method for managing the provision of a service between original and destination endpoints over a communication network.

Inventors:
CELESTINO FRANCESCO (IT)
MARCHESINI MARCO (IT)
CECCARELLI DANIELE (SE)
Application Number:
EP2017/050994
Publication Date:
July 26, 2018
Filing Date:
January 18, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ERICSSON TELEFON AB L M (SE)
International Classes:
H04L12/715; H04L12/46
Foreign References:
US20040028064A12004-02-12
US8774047B22014-07-08
US20120207058A12012-08-16
US20100161960A12010-06-24
US6614809B12003-09-02
US20150092783A12015-04-02
Other References:
None
Attorney, Agent or Firm:
ERICSSON (Stockholm, SE)
Download PDF:
Claims:
CLAIMS

1 . A method for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two Autonomous Systems, ASs, the method comprising:

defining an Abstraction and Control of Traffic Engineered Networks, ACTN, Virtual Network, VN, between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs;

defining, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel; and

binding the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service. 2. A method as claimed in claim 1 , wherein binding the service to the VN further comprises using a Routing Policy to expose the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop for traffic having that loopback interface as its destination. 3. A method as claimed in claim 2, wherein the operation of exposing comprises exposing the loopback interface to AS border nodes in the AS of the destination endpoint.

4. A method as claimed in any one of the preceding claims, wherein binding the service to the VN further comprises using a Routing Policy to expose the loopback interface defined at the egress node of a tunnel in an AS adjacent to the AS of the destination endpoint as routing next hop for traffic having the loopback interface defined at the egress node corresponding to the destination endpoint as its destination. 5. A method as claimed in claim 4, wherein the operation of exposing comprises exposing the loopback interface to AS border nodes in the AS adjacent to the AS of the destination endpoint.

6. A method as claimed in any one of the preceding claims, wherein exposing loopback interfaces comprises exposing the interfaces via Border Gateway Protocol, BGP, signalling

7. A method as claimed in any one of the preceding claims, wherein binding the service to the VN further comprises using the defined loopback interfaces as tunnel endpoints for traffic routing within each individual AS.

8. A method as claimed in claim 7, wherein using the defined loopback interfaces as tunnel endpoints for traffic routing within each individual AS comprises using RSVP - TE capabilities to create the tunnels. 9. A method as claimed in claim 7 or 8, wherein binding the service to the VN further comprises engineering the tunnels within each individual AS with routing satisfying Service Level Agreement, SLA, requirements applicable to the service.

10. A method as claimed in any one of the preceding claims wherein defining a VN between the origin and destination endpoints further comprises:

identifying the tunnels of the VN as a primary path for the VN; and

identifying at least one additional tunnel to serve as a secondary path for the VN; and wherein the method further comprises:

defining, at an egress node of the identified secondary path tunnel, a loopback interface that corresponds to the VN and is specific to the identified secondary path tunnel.

1 1 . A method as claimed in claim 10, wherein binding the service to the VN further comprises using a Routing Policy to expose the loopback interface defined at the egress node of the identified secondary path tunnel as routing next hop for traffic having the loopback interface defined at the egress node corresponding to the destination endpoint for the service as the traffic's destination.

12. A method as claimed in claim 10 or 1 1 , wherein binding the service to the VN further comprises distinguishing between tunnels identified as primary and secondary paths for the VN using a Routing Policy.

13. A method as claimed in any one of the preceding claims, wherein the service comprises a Virtual Private Network, VPN.

14. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any one of the preceding claims. 15. A carrier containing a computer program as claimed in claim 14, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

16. A computer program product comprising non transitory computer readable media having stored thereon a computer program as claimed in claim 14.

17. A management element for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two Autonomous Systems, ASs, the management element adapted to:

define an Abstraction and Control of Traffic Engineered Networks, ACTN, Virtual Network, VN, between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs;

define, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel; and

bind the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service. 18. A management element for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two Autonomous Systems, ASs, the management element comprising a processor and a memory, the memory containing instructions executable by the processor such that the management element is operable to:

define an Abstraction and Control of Traffic Engineered Networks, ACTN, Virtual

Network, VN, between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs;

define, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel; and bind the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service. 19. A management element for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two Autonomous Systems, ASs, the management element comprising:

a Virtual Network module for defining an Abstraction and Control of Traffic Engineered Networks, ACTN, Virtual Network, VN, between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs; and

a routing module for defining, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel; and for binding the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service.

Description:
Method And Apparatus For Service Provision In A Communication Network Technical Field The present disclosure relates to a method for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two Autonomous Systems (ASs). The present disclosure also relates to a management element for managing the provision of a service between origin and destination endpoints over such a communication network and to a computer program product configured, when run on a computer, to carry out a method for managing the provision of a service between origin and destination endpoints over such a communication network.

Background

Software Defined Networking (SDN) of transport networks is increasing in popularity, with operators beginning to deploy SDN based solutions for single domain management in transport networks. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator. Abstraction and Control of Traffic Engineered Networks (ACTN) is an initiative standardised in various IETF drafts with the aim of facilitating resource abstraction in multi technology and multi vendor transport networks. In ACTN terminology, an SDN based solution for single domain management in transport networks is referred to as a Physical Network Controller (PNC) controlled domain. The driver for the introduction of SDN in transport networks is to provide network operators with Traffic Engineering (TE) capabilities in terms of constraints to be applied to the routing of traffic in the network. Such capabilities may include for example computing paths with minimum delay, minimum cost etc.

Service providers offer to their customers services built on top of, and transported via, the tunnels defined in transport networks. The tunnels themselves do not form part of the customer offering, but rather the services built on top of the tunnels. There is therefore a need to bind the overlay services provided to customers to particular tunnels that will transport the service traffic in accordance with constraints to be applied to the service. Such overlay services may include for example Layer 3 and Layer 2 Virtual private Networks (L3VPNs and L2VPNs). This requirement is very common for L3VPN services, according which Virtual Routing Functions (VRFs) are defined on Provider Edge (PE) nodes and it is required to bind a VPN to a given VRF and to bind a VRF to a given tunnel. This situation is illustrated in Figure 1 , according to which a request is received for VPN A1 2 between PE X1 4 and PE Y1 6 with minimal delay. The transport network between PE X1 4 and PE Y1 6 includes transport nodes 8. Supposing that the path with minimal delay is the path going through nodes PE X1 -P1 -P2-P3-P4-PE Y1 , a mechanism is required to bind VPN A1 2 to that particular tunnel. Such a mechanism exists and different vendors implement it in different ways, but most commercial nodes allow for binding between a VRF and a given tunnel.

Existing solutions function effectively in a single network domain, that is in situations in which the Customer Edge (CE) nodes of the VPN are connected to PE nodes belonging to the same Autonomous System (AS). This is the situation illustrated in Figure 1 , but this situation in fact just a small subset of actual deployment situations in customer networks, according which it is usual for multiple ASs to be crossed by the traffic belonging to a single VPN, meaning that the CE nodes of the VPN are connected to PE nodes belonging to different ASs. A multi-AS situation of this type is illustrated in Figure 2. For the sake of simplicity, a scenario with only 2 domains is illustrated in the Figure, although the concepts discussed are applicable to an arbitrarily high number of ASs. In the situation illustrated in Figure 2, a request is again received for VPN A1 2 between PE X1 4 and PE Y1 6 with minimal delay. However, in the situation of Figure 2, PE X1 4 and PE Y1 6 belong to different ASs. In multi domain scenarios, there is no single end to end tunnel, that is there is no single entity connecting PE X1 and PE Y1 in Figure 2, only tunnels within each domain and mechanisms to forward the traffic from one domain to another. The domain tunnels include tunnel 10 and 12 in the left domain 14 and tunnels 16 and 18 in the right domain 20. The mechanisms for forwarding traffic from one domain to another are illustrated by the dashed lines 22 and 24 between the AS Border Router (AS BR) nodes 26, 28, 30, 32. In order to provide end to end constraints against the service VPN A1 it is necessary to guarantee that the traffic for this service is bound to a specific path in each domain, for example to the path composed of tunnels 10 and 16 or of tunnels 12 and 18. Using existing techniques it is possible force the VPN to use for example tunnel 10 between PE X1 4 and ASBR X1 26 by binding VPN A1 2 to VRF 1 34 and binding VRF1 34 to tunnel 10. However, once the traffic is delivered from ASBR X1 26 to ASBR Y1 30 there is no way to tell ASBR Y1 30 to use tunnel 16 as opposed to tunnel 18 to reach PE Y1.

According to existing techniques, it is possible to force traffic forwarding between ASBR nodes on a class of service basis, meaning that if N tunnels with the same class of service characteristics are available between ASBR Y1 30 and PE Y1 6, the path would be chosen randomly or based on load balancing mechanisms. While the VPN A1 traffic would still be delivered to the VPN CE node, there can be no SLA guarantee for the traffic as for example tunnel 16 may provide 10 ms of delay while tunnel 18 provides 50 ms of delay. In addition, troubleshooting is not possible owing to the lack of a relationship between the underlay infrastructure and the overlay service. In the case of a failure of a link, and hence of a tunnel, in the transport network it is not possible to know which services are impacted as it is not possible to know the path followed by the different services.

Summary

It is an aim of the present invention to provide a method, apparatus and computer readable medium which at least partially address one or more of the challenges discussed above.

According to a first aspect of the present disclosure, there is provided a method for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two Autonomous Systems (ASs). The method comprises defining an Abstraction and Control of Traffic Engineered Networks (ACTN) Virtual Network (VN) between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs. The method further comprises defining, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel, and binding the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service.

According to examples of the present disclosure, the steps of defining loopback interfaces at egress nodes and binding the service to the VN may be repeated for each newly created service to bind the newly created service to an appropriately defined VN. According to examples of the present disclosure, binding the service to the VN may further comprise using a Routing Policy to expose the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop for traffic having that loopback interface as its destination.

According to examples of the present disclosure, the operation of exposing the loopback interface may comprise exposing the loopback interface to AS border nodes in the AS of the destination endpoint.

According to examples of the present disclosure, the loopback interface may be exposed only to AS border nodes in the AS of the destination endpoint. The loopback interface may therefore not be propagated into an Interior Gateway Protocol of the AS. According to examples of the present disclosure, binding the service to the VN may further comprise using a Routing Policy to expose the loopback interface defined at the egress node of a tunnel in an AS adjacent to the AS of the destination endpoint as routing next hop for traffic having the loopback interface defined at the egress node corresponding to the destination endpoint as its destination.

According to examples of the present disclosure, the operation of exposing the loopback interface comprises exposing the loopback interface to AS border nodes in the AS adjacent to the AS of the destination endpoint. According to examples of the present disclosure, the loopback interface may be exposed only to AS border nodes in the AS adjacent to the AS of the destination endpoint. The loopback interface may therefore not be propagated into an Interior Gateway Protocol of the AS. According to examples of the present disclosure, exposing loopback interfaces may comprise exposing the interfaces via Border Gateway Protocol (BGP) signalling

According to examples of the present disclosure, binding the service to the VN may further comprise using the defined loopback interfaces as tunnel endpoints for traffic routing within each individual AS. According to examples of the present disclosure, using the defined loopback interfaces as tunnel endpoints for traffic routing within each individual AS may comprise using RSVP - TE capabilities to create the tunnels. According to examples of the present disclosure, binding the service to the VN may further comprise engineering the tunnels within each individual AS with routing satisfying Service Level Agreement (SLA) requirements applicable to the service.

According to examples of the present disclosure, defining a VN between the origin and destination endpoints may further comprise identifying the tunnels of the VN as a primary path for the VN, and identifying at least one additional tunnel to serve as a secondary path for the VN. According to examples of the present disclosure, the method may further comprise defining, at an egress node of the identified secondary path tunnel, a loopback interface that corresponds to the VN and is specific to the identified secondary path tunnel.

According to examples of the present disclosure, binding the service to the VN may further comprise using a Routing Policy to expose the loopback interface defined at the egress node of the identified secondary path tunnel as routing next hop for traffic having the loopback interface defined at the egress node corresponding to the destination endpoint for the service as the traffic's destination.

According to examples of the present disclosure, binding the service to the VN may further comprise distinguishing between tunnels identified as primary and secondary paths for the VN using a Routing Policy.

According to examples of the present disclosure, primary and secondary paths may be distinguished using attributes set using Routing Policies, including for example BGP Local Preferences.

According to examples of the present disclosure, the service may comprise a Virtual Private Network (VPN). According to examples of the present disclosure, each time a new VPN service is created, specific route policies may be created according to examples of the method of the present disclosure in order to expose the relevant loopback interfaces to bind the newly created VPN service to a desired VN. According to examples of the present disclosure, the method may be implemented by a Physical Network Controller (PNC) or a Multi Domain Service Coordinator (MDSC).

According to another aspect of the present disclosure, there is provided a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any preceding aspect of example of the present disclosure.

According to another aspect of the present disclosure, there is provided a carrier containing a computer program according to the preceding aspect of the present disclosure, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

According to another aspect of the present disclosure, there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program according to a preceding aspect of the present disclosure.

According to another aspect of the present disclosure, there is provided a management element for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least ASs. The management element is adapted to define an ACTN VN between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs, and to define, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel. The management element is further adapted to bind the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service.

According to another aspect of the present disclosure, there is provided a management element for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two ASs. The management element comprises a processor and a memory, the memory containing instructions executable by the processor such that the management element is operable to define an ACTN VN between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs. The management element is further operable to define, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel, and to bind the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service. According to another aspect of the present disclosure, there is provided a management element for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two ASs. The management element comprises a Virtual Network module for defining an ACTN VN between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs, and a routing module for defining, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel, and for binding the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service.

Brief description of the drawings

For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

Figure 1 illustrates service to tunnel binding in a single domain of a transport network;

Figure 2 illustrates service to tunnel binding options in a multi-domain transport network;

Figure 3 illustrates process steps in a method for managing the provision of a service between origin and destination endpoints over a communication network;

Figure 4 illustrates service to tunnel binding in a multi-domain transport network according to examples of the method of Figure 3;

Figure 5 illustrates a further example of service to tunnel binding in the multi-domain transport network of Figure 4 according to examples of the method of Figure 3; Figure 6 illustrates transport loopback interface creation in the multi-domain transport network of Figure 4; Figures 7 a and 7b illustrate process steps in another example of a method for managing the provision of a service between origin and destination endpoints over a communication network;

Figure 8 illustrates service loopback interface creation and propagation in the multi- domain transport network of Figure 4;

Figure 9 illustrates service to tunnel binding using the loopback interfaces of Figure 8;

Figure 10 illustrates functional modules in a management element; and

Figure 1 1 illustrates functional modules in another example of management element. Detailed Description

Aspects of the present disclosure provide a method according to which a service may be bound to the individual tunnels forming an end to end path in a multi-domain transport network. Examples of the method use the concept of an ACTN Virtual Network (VN) to identify an end to end path comprising a different tunnel in each domain of the transport network, each domain operating as a distinct AS. A service may then be bound to a defined VN, which binding translates as a binding to each individual tunnel comprised within the VN in the different domains. Figure 3 illustrates a first example of a method 100 for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two ASs. Referring to Figure 3, the method comprises, in a first step 1 10, defining an ACTN VN, between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs. The method then comprises, in step 120, defining, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel. Finally, the method comprises, in step 140, binding the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service. Figure 4 illustrates service to tunnel binding in an example multi domain transport network, which binding may be achieved using examples of the method of Figure 3. Referring to Figure 4, a multi-domain transport network comprises a first AS or domain 40 and a second AS or domain 42. Each AS comprises transport nodes 69, 70, 72, 74 and ASBR nodes 76, 78, 80, 82. A plurality of ACTN VNs is defined between PE node 56 in domain 40 and PE node 58 in domain 42. The plurality of ACTN VNs includes VN A 60, VN B 62, VN Xa 64 and VN Xb 66. Each VN comprises a specific tunnel through each of the ASs 40, 42, as illustrated in the Figure. A range of VPN services may be bound to the different VNs, resulting in the services being bound to the specific tunnels comprised within the VNs. Thus VPN A1 44 and VPN A2 46 are bound to VN A 60, and VPN B1 48 and VPN B2 50 are bound to VN B 62. VPN X1 52 and VPN X2 54 are unbound, and may be transported over either of VN Xa 64 or VN Xb 66.

Figure 5 illustrates the service to tunnel binding of Figure 4 together with aspects of an example control architecture though which examples of the method 100 of Figure 3 may be implemented. As illustrated in Figure 5, the multi domain transport network comprises multiple IP/MPLS domains 40, 42 connected using Inter AS option C, also known as seamless MPLS. In the illustrated example, a Multi Domain Service Coordinator (MDSC) 84 coordinates the end to end service and tunnel provisioning and is in communication with a dedicated PNC 86, 88 for each domain. Tunnels within each domain may be created by any means including for example RSVP-TE, segment routing, NMS etc. The different domains are managed as different ASs, each with its own routing instance including for example ISIS-TE or OSPF-TE. Border Gateway Protocol Label Unicast (BGP-LU) is used for the signalling of the transport layer between the different domains.

As illustrated in Figure 6, transport loopback interfaces (Lo.O) may be used for the setup and the management of the IP/MPLS infrastructure, using Interior Gateway Protocol (IGP), RSVP and interior BGP (iBGP) protocols as illustrated in steps 1 .a and 1.b of Figure 6.

Figures 7a and 7b illustrate another example of a method 200 for managing the provision of a service between origin and destination endpoints over a communication network, the communication network comprising at least two ASs. The method 200 of Figures 7a and 7b illustrates one way in which the steps of the method 100 of Figure 3 may be subdivided and supplemented to achieve the above discussed and additional functionality. The method 200 may for example be carried out by a PNC or an MDSC, such as the PNCs 86, 788 or MDSC 84 illustrated in Figure 5. Figures 8 and 9 illustrate example execution of some of the steps of the method 200 on Figures 7a and 7b in the example multi domain transport network of Figures 4, 5 and 6. Referring to Figure 7a, in a first step 210, the method 200 comprises defining an ACTN VN between origin and destination endpoints, the VN comprising a specified tunnel in each AS. Referring to Figure 5, this step may for example comprise defining VN A including tunnels 90 and 92 and/or VN B comprising tunnels 94 and 96. In step 21 1 , the method comprises identifying the tunnels of the VNs as a primary path for the VN. In step 212, the method comprises identifying at least one additional tunnel to serve as a secondary path for the VN. This may include for example tunnel 98, which is also a primary path for VN Xb in Figure 5.

In step 220, the method 200 comprises defining, at each egress node of each tunnel in the VN, a loopback interface, referred to in the following description as a service loopback interface, which loopback interface corresponds to the VN and is specific to the particular tunnel of the egress node. Such interfaces may be defined for each VN that is to be used for binding of a service. The operation of defining service loopback interfaces may comprise manual configuration or configuration by a PNC or MDSC. Service loopback interface definition is illustrated in Figure 8, with the definition of service loopback interface Lo.A' on ASBR X1 76 and service loopback interface Lo.A on the destination PE node PE Y1 58 for VN A. Each service loopback interface corresponds to the ACTN VN VN A but they are differentiated by the use of a ' symbol, such that each service loopback interface is specific to the particular tunnel at the egress of which it is defined. Equivalent service loopback interfaces are defined for VN B, with Lo.B' defined at ASBR X1 76 and Lo.B defined at destination PE node PE Y1 58. Lo.A' and Lo.B' at ASBR X1 76 may be used to force traffic onto the correct tunnel in the first domain 40 and Lo.A and Lo.B may be used to force traffic onto the correct tunnel in the second domain 42.

In step 230, the method 200 comprises defining a loopback interface corresponding to the VN at an egress node of the identified secondary path tunnel. Thus, referring again to Figure 8, Lo.A" and Lo.B" may be defined at ASBR X2 78 to provide an end to end BGP FRR driven recovery mechanism for the traffic in the event of a failure on the primary path. The failure of any link or node within each domain would be recovered locally to the domain in order to restore the affected tunnel. However, the definition of the service loopback interfaces Lo.A" and Lo.B" on the identified secondary path tunnel allows for the recovery of failures affecting the ASBR nodes, and specifically ASBR X1 76. Lo.A" and Lo.B" enable the identification of an alternative BGP next hop in the event of a failure at ASBR X1 76. Different BGP Local Preferences may be used on ASBR X1 and ASBR X2 in order to identify primary and secondary paths as discussed in further detail below.

A PNC or MDSC may configure the destination PE node PE Y1 58 such that the defined service loopback interfaces at the node, Lo.A and Lo.B, are announced into the network via a regular BGP network statement with send label request (BGP LU). This is illustrated at 2. a in Figure 8.

Referring again to Figure 7a, in step 241 , the method 200 comprises using a Routing Policy to expose the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop for traffic having that loopback interface as its destination. As illustrated in step 241 a, this may comprise exposing the loopback interface to AS border nodes in the AS of the destination endpoint. This step is illustrated in step 2.b of Figure 8 and may comprise a PNC or MDSC forcing exposure of Lo.A and Lo.B as BGP next hop via route policy on IPv4 labelled unicast address family (match on destination). It will be appreciated that exposure only to AS border nodes means the defined service loopback interfaces are not propagated into each domain IGP, thus ensuring scalability, separation of transport and service layer routing and ease of troubleshooting. Referring now to Figure 7b, in step 242, the method 200 comprises using a Routing Policy to expose the loopback interface defined at the egress node of a tunnel in an AS adjacent to the AS of the destination endpoint as routing next hop for traffic having the loopback interface defined at the egress node corresponding to the destination endpoint as its destination. As illustrated in step 242a, this may comprise exposing the loopback interface to AS border nodes in the AS adjacent to the AS of the destination endpoint. This step is illustrated in step 2.c of Figure 8, in which a PNC or MDSC forces exposure of Lo.A' and Lo.B' as next hop for the origin PE node PE X1 56 for traffic having Lo.A Lo.B as its destination. This may be done by configuring the route policy on the ASBR nodes on IPv4 LU (match on destination). In step 243, the method 200 comprises exposing the loopback interface defined at the egress node of the identified secondary path tunnel as routing next hop for traffic having the loopback interface defined at the egress node corresponding to the destination endpoint for the service as the traffic's destination. As illustrated in step 243a, this may comprise exposing the loopback interface to AS border nodes in the AS of the identified secondary path tunnel. This is illustrated in Figure 8 via the exposure of Lo.A" and Lo.B" as next hop for traffic having Lo.A Lo.B as its destination. As mentioned above, BGP Local Preferences may be used to distinguish between primary and secondary path tunnels. As illustrated in Figure 8, the loopback interface defined on the primary path tunnel is set to have a Local preference ++, while the loopback interface defined on the secondary path tunnel is set to have a Local Preference— .

In order to have the loopback interfaces Lo.A (and Lo.A A") and Lo.B (and Lo.BVB") installed in BGP tables and relevant labels created, they need to be valid BGP next hops, that is they need to be reachable via IGP protocol. Instead of directly injecting the loopback interfaces into local IGP, the loopback interfaces are resolved not via simple static routes, but by means of dedicated local transport tunnels. In step 244, the method 200 therefore creates tunnels using the defined service loopback interfaces as their endpoints. This can be achieved for example using "RSVP autoroute destination" functionality, as illustrated in step 2.d of Figure 8, or similar standard RSVP-TE capabilities. As a result, service loopbacks are made available in local IGP routing tables without explicit redistribution, and traffic aiming at each service loopback class (for example A or B) is deterministically conveyed over the desired path. A deterministic correlation is thus created between inter-domain BGP and intra-domain transport layers, only using standard IP/MPLS functionalities. As illustrated in step 245 of method 200, each tunnel is engineered with the desired explicit routing satisfying SLA requirements applicable to services to be bound to the VN.

As discussed above, the relevant service loopback interfaces are exposed as next hop only for traffic having the service loopback interface defined at the destination endpoint as the traffic's destination. Thus a service is bound to the relevant VN by configuring the route policy on the VPNv4 address family (match on ext-community router target) and exposing the loopback interface defined at the destination endpoint (Lo.A Lo.B) as next hop only for traffic belonging to the service that is to be bound to the VN. This is illustrated in Figure 9, with Lo.A and Lo.B exposed as next hops only for customer subnets belonging to the relevant VPNs A1 and B1 as shown in step 3. a. According to the transport infrastructure established in the preceding steps, the VPN traffic is bound to the relevant VN as shown at 3.b. The route policy on the VPNv4 address family may be dynamically configured, such that each time a new VPN service is created, specific route policies are created by control plane in order to expose needed service loopback interfaces and associate the VPN to the desired VN. As discussed above, the methods 100, 200 may be performed by a PNC or MDSC which may be hosted within a management element. The management element may be virtualised and may be centralised or distributed as appropriate. Figure 10 is a block diagram illustrating an example management element 300 which may implement the methods 100, 200 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program. Referring to Figure 10, the apparatus comprises a processor 310, a memory 320 and interface or interfaces 330 for communications with other elements of the network. The memory 320 contains instructions executable by the processor 310 such that the management element is operative to conduct the steps of the method 100 and or 200.

Figure 1 1 illustrates functional modules in another example of management element 400 which may execute examples of the methods 100, 200 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the modules illustrated in Figure 1 1 are functional modules, and may be realised in any appropriate combination of hardware and/or software. The modules may comprise one or more processors and may be integrated to any degree.

Referring to Figure 1 1 , the management element 400 comprises a VN module 410 for defining an ACTN VN between the origin and destination endpoints, the VN comprising a specified tunnel in each of the ASs. The management element 400 also comprises a routing module 420 for defining, at each egress node of each tunnel in the VN, a loopback interface that corresponds to the VN and is specific to the particular tunnel, and for binding the service to the VN by exposing the loopback interface defined at the egress node corresponding to the destination endpoint as routing next hop only to traffic corresponding to the service. The management element 400 further comprises interface or interfaces 430 for communications with other elements of the network.

Aspects of the present disclosure thus provide methods and apparatus enabling the binding of a service to all the different tunnels composing an end to end path in a mutli domain transport network. On an ingress PE node, it is possible to use existing "VRF to tunnel" binding techniques, but when a domain is crossed without the presence of a VRF, aspects of the present disclosure provide a mechanism to force the traffic to use a given tunnel instead of another. The disclosed mechanism allows for the binding of overlay services to the underlay transport infrastructure through the use of ACTN Virtual Networks, which define an end to end path spanning multiple domains or Ass and comprising a specific tunnel in each AS. Methods according to the present disclosure allow for the binding of a service to a defined VN, which binding translates as a binding of the service to each tunnel in the VN across the different ASs spanned by the VN. Aspects of the present disclosure may use standard routing policy functionality of BGP or any similar protocol to manipulate the way in which routing information is advertised though a multi AS environment. According to aspects of the present disclosure, routing policies may be used to define loopback interfaces that force traffic onto particular tunnels, and then to expose those interfaces as next hops only for traffic that is to be bound to those particular tunnels.

As noted above, aspects of the present disclosure may use standard IP/MPLS methods (including for example BGP route policy and Traffic Engineering) thus ensuring their compatibility with existing mechanisms, and provide stricter service to transport correlation than simple QoS criteria without invoking any vendor specific tunnel policy feature. Aspects of the present disclosure may be easily applicable to High Availability deployments (i.e. redundant ASBR's), once again with standard IP tools (i.e. BGP Local Preference).

Example methods of the present disclosure enable guaranteed satisfaction of end to end SLAs and also enable, though the binding of services to specific tunnels, a clear understanding of which services may be impacted by any failure or congestion situation in the network. Example methods of the present disclosure are compatible with existing inter AS mechanisms, including the seamless MPLS architecture, and rely on standard BGP route policy and Traffic Engineering methods without using vendor specific policies or features. Example methods of the present disclosure offer traffic segregation between 'eligible for binding' VPNs, such as VPN A1 , VPN A2, VPN B1 and VPN B2 in Figure 4, and 'unbound or assigned to Default VN's' VPNs such as VPN X1 and VPN X2 in Figure 4. Examples of the present disclosure thus allow the flexibility of having both VPNs that are bound to a VN and VPNs that are not bound to a VN. Example methods of the present disclosure also allow for the definition of a redundancy mechanism using for example BGP Local Preferences to provide end to end resiliency mechanisms. The methods of the present invention may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present invention also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer-readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.