WO2019000156A1 - Synchronization of label switched paths - Google Patents

Synchronization of label switched paths Download PDF

Info

Publication number
WO2019000156A1
WO2019000156A1 PCT/CN2017/089960 CN2017089960W WO2019000156A1 WO 2019000156 A1 WO2019000156 A1 WO 2019000156A1 CN 2017089960 W CN2017089960 W CN 2017089960W WO 2019000156 A1 WO2019000156 A1 WO 2019000156A1
Authority
WO
WIPO (PCT)
Prior art keywords
label switched
switched path
synchronization process
synchronization
lsp
Prior art date
Application number
PCT/CN2017/089960
Other languages
French (fr)
Inventor
Cuihua DENG
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/CN2017/089960 priority Critical patent/WO2019000156A1/en
Publication of WO2019000156A1 publication Critical patent/WO2019000156A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/52Multiprotocol routers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]

Definitions

  • the present disclosure generally relates to communication networks, and more specifically, relates to label switching networks.
  • MPLS multi-protocol label switching
  • LSP label switched path
  • various label signaling mechanisms such as a border gateway protocol (BGP) , a border gateway protocol labeled unicast (BGP-LU) , a label distribution protocol (LDP) , a resource reservation protocol (RSVP) and/or the like, may be used to establish LSPs for routing traffics through the network.
  • BGP border gateway protocol
  • BGP-LU border gateway protocol labeled unicast
  • LDP label distribution protocol
  • RSVP resource reservation protocol
  • the present disclosure proposes a solution for synchronization of different LSPs, which may orchestrate the hierarchy LSPs by controlling traffic transmissions on a LSP, so that the traffic loss caused by the availability incoordination of the LSPs for transmitting traffics may be eliminated or reduced.
  • a method implemented at a communication device may comprise initiating a synchronization process for a first LSP setup by a first protocol and a second LSP setup by a second protocol, in response to a synchronization event which indicates potential incoordination between the first LSP and the second LSP underlying the first LSP.
  • the method may further comprise detecting a status of the second LSP during the synchronization process, where the first LSP is in an operational status. Based at least in part on the detection of the status of the second LSP, it may be determined whether to terminate the synchronization process.
  • an apparatus may comprise one or more processors and one or more memories comprising computer program codes.
  • the one or more memories and the computer program codes may be configured to, with the one or more processors, cause the apparatus at least to perform any step of the method according to the first aspect of the present disclosure.
  • a computer program product comprising a computer-readable medium bearing computer program codes embodied therein for use with a computer.
  • the computer program codes may comprise code for performing any step of the method according to the first aspect of the present disclosure.
  • an apparatus may comprise an initiating module, a detecting module and a determining module.
  • the initiating module may be operable to carry out at least the initiating step of the method according to the first aspect of the present disclosure.
  • the detecting module may be operable to carry out at least the detecting step of the method according to the first aspect of the present disclosure.
  • the determining module may be operable to carry out at least the determining step of the method according to the first aspect of the present disclosure.
  • initiating the synchronization process may comprise: triggering a synchronization timer for timing the synchronization process; and decreasing a probability of the first LSP being selected for traffic transmission.
  • the probability of the first LSP being selected for traffic transmission may be related to reliability of the first LSP for the traffic transmission.
  • the reliability of the first LSP for the traffic transmission may be indicated by an administrative distance (AD) of the first LSP.
  • AD administrative distance
  • decreasing the probability of the first LSP being selected for the traffic transmission may comprise: setting an AD of the first LSP as 254.
  • the termination of the synchronization process may comprise: stopping the synchronization timer; and increasing the decreased probability of the first LSP being selected for the traffic transmission.
  • the synchronization event may comprise one of the following: an event of the first LSP becoming operational in a network setup procedure; an event of the first LSP becoming operational in a path recovery procedure; and an event of receiving a report that the second LSP becomes non-operational.
  • determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to detecting an operational status of the second LSP, wherein the duration of the synchronization process is shorter than a predefined period of time.
  • determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to receiving a synchronization interrupt indication, wherein no operational status of the second LSP is detected during the synchronization process and the duration of the synchronization process is shorter than a predefined period of time.
  • the synchronization interrupt indication may comprise at least one of a service indication, a control-plane indication, and an operations, administration and maintenance (OAM) indication.
  • OAM operations, administration and maintenance
  • determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to the duration of the synchronization process reaching up to a predefined period of time, wherein no operational status of the second LSP is detected during the synchronization process.
  • the predefined period of time may be an expiration period of a synchronization timer.
  • the first protocol may comprise a BGP or a BGP-LU.
  • the second protocol may comprise a LDP, a RSVP or a combination thereof.
  • Fig. 1 is a diagram illustrating an exemplary communication network according to an embodiment of the present disclosure
  • Fig. 2 is a diagram illustrating an example of route convergence according to an embodiment of the present disclosure
  • Fig. 3 is a flowchart illustrating a method according to an embodiment of the present disclosure
  • Fig. 4 is a flowchart illustrating a process of LSP synchronization according to an embodiment of the present disclosure
  • Fig. 5 is a block diagram illustrating an apparatus according to an embodiment of the present disclosure.
  • Fig. 6 is a block diagram illustrating another apparatus according to another embodiment of the present disclosure.
  • the term “communication device” may refer to an electronic device that communicatively interconnects other electronic devices on the network, such as network devices, end-user devices or the like.
  • the communication device may act as a multiple services communication device which can provide support for multiple networking functions (for example, routing, bridging, switching, session border control, and/or subscriber management) , and/or provide support for multiple application services (for example, data, voice and/or video) .
  • the terms “first” , “second” and so forth refer to different elements.
  • the singular forms “a” and “an” are intended to include the plural forms as well, unless the context clearly indicates otherwise.
  • the term “based on” is to be read as “based at least in part on” .
  • the term “one embodiment” and “an embodiment” are to be read as “at least one embodiment” .
  • the term “another embodiment” is to be read as “at least one other embodiment” .
  • Other definitions, explicit and implicit, may be included below.
  • LSRs label switch routers
  • LERs label edge routers
  • IP Internet protocol
  • LDP/RSVP is widely deployed in MPLS networks as a signaling protocol for LSPs.
  • LDP/RSVP LSPs may be used as transport LSPs in applications such as BGP free core, layer 2 virtual private network (L2VPN) , layer 3 virtual private network (L3VPN) and other applications, by stacking the LDP/RSVP LSP label (the tunnel label) over the application label.
  • LDP/RSVP cannot be used to establish edge-to-edge LSPs for interconnecting network domains. Inter-domain LSPs are generally setup using BGP or BGP-LU.
  • BGP is a widely used protocol for interconnecting network domains, for example, interconnecting autonomous systems (AS) , operated by different service providers. This protocol is designed to exchange routing and reachability information, such as information between routers as to which destination networks are reachable through which routers. BGP-capable routers are called BGP speakers. Neighbor BGP speakers are called BGP peers. As a label signaling and routing protocol between BGP peers, BGP-LU (for example, as defined by RFC3107) is very useful where a MPLS network is segmented within an AS or spanned across multiple-AS.
  • AS interconnecting autonomous systems
  • BGP is also used to support other applications than traditional Internet applications, for example to carry reachability information for VPNs.
  • BGP may be used to distribute VPN reachability information across a provider backbone
  • MPLS is used to transport VPN traffics from a VPN site to another over the provider backbone.
  • the provider backbone may be made of several interconnected domains, and each domain such as an AS may be operated by a service provider.
  • Fig. 1 is a diagram illustrating an exemplary communication network according to an embodiment of the present disclosure.
  • the communication network shown in Fig. 1 is an example of Inter-AS MPLS VPN Option-C.
  • This exemplary communication network may comprise a seamless MPLS or scaled MPLS network which uses BGP-LU to establish edge-to-edge LSP or provider edge-to-provider edge (PE-to-PE) LSP.
  • BGP-LU edge-to-edge LSP
  • PE-to-PE provider edge-to-provider edge
  • Fig. 1 shows that CE1 is attached to a PE router PE1 (which is also denoted by D1 in Fig. 1) , and CE2 is attached to another PE router PE2 (which is also denoted by D7 in Fig. 1) .
  • PE provider edge
  • Fig. 1 shows that CE1 is attached to a PE router PE1 (which is also denoted by D1 in Fig. 1)
  • CE2 is attached to another PE router PE2 (which is also denoted by D7 in Fig. 1) .
  • P routers such as D2 shown in Fig. 1.
  • Routers located at the border between two ASs are known as autonomous system border routers (ASBR) , such as ASBR1, ASBR2, ASBR3 and ASBR4 which are respectively denoted by D3, D4, D5 and D6 in Fig. 1.
  • ASBR autonomous system border routers
  • An AS which also may be regarded as an intraregional MPLS network, typically employs an interior gateway protocol (IGP) to exchange network topology information among routers within the AS.
  • IGP interior gateway protocol
  • BGP may be used to exchange the reachability information of the network between BGP peers, such as PE1, PE2, ASBR1, ASBR2, ASBR3 and ASBR4.
  • BGP LSP setup by BGP or BGP-LU needs to ride on top of the LDP/RSVP LSP which is setup by LDP, RSVP or the combination thereof.
  • a PE such as PE1 may allocate three labels to an unlabeled packet.
  • a service label as the inner label can identify a MPLS service for L2VPN/L3VPN.
  • the middle label allocated by BGP-LU for the Inter-AS MPLS network is used to forward the packet to the final edge or PE such as PE2, forming an inter-region LSP.
  • the outer label allocated by LDP and/or RSVP is used to forward the packet to the internal BGP (IBGP) peer in the same region, forming an intra-region LSP.
  • IBGP internal BGP
  • the middle label allocated by BGP-LU is supported by the IBGP in the same region and by the external BGP (EBGP) between two regions.
  • the outer label allocated by LDP and/or RSVP is coupled with IGP1 in AS100 and with IGP2 in AS200.
  • PE1 may send traffics from CE1 to ASBR1 as ASBR1 is the next hop of the best BGP path.
  • ASBR1 becomes unreachable
  • the traffics can be switched to ASBR2.
  • the 50ms traffic switch performance can be achieved by deploying BGP fast re-route (BGPFRR) . But when the path failure is cleared, traffic loss may happen as well during route convergence.
  • BGPFRR BGP fast re-route
  • Fig. 2 is a diagram illustrating an example of route convergence according to an embodiment of the present disclosure.
  • the exemplary route convergence shown in Fig. 2 may be performed in a path recover procedure for a BGP-LU enabled MPLS network.
  • the path recover procedure may be initiated due to a path failure such as a link failure, a node failure and/or the like.
  • the BGP LSP setup by BGP-LU rides on top of the LDP/RSVP LSP setup by LDP and/or RSVP.
  • the BGP LSP and the LDP/RSVP LSP are setup independently since they are signaled by different protocols.
  • IGP convergence may be performed for the route convergence as shown in block 202, and then the LDP/RSVP LSP and the BGP LSP may be setup according to corresponding protocols, as respectively shown in blocks 204 and 206.
  • the BGP LSP which is setup in block 206 may be included in BGP best path computation, as shown in block 208. Traffics can be conveyed with the selected BGP path according to the BGP best path computation, as shown in block 210.
  • the BGP LSP becomes operational before the underlay LDP/RSVP LSP.
  • the traffic transmission shown in Fig. 1 as an example, when the faulty path associated with ASBR1 recovers, the BGP LSP between PE1 and ASBR1 recovers but the underlying LDP/RSVP LSP is not yet.
  • ASBR1 is selected as the best path to CE2 according to the BGP best path computation. Traffics are then switched back to ASBR1. As a result, a black hole occurs and traffics may be dropped before the LDP/RSVP LSP between PE1 and ASBR1 becomes operational.
  • the duration depends on the extra time which the LDP/RSVP LSP takes to become operational. For example, for a three nodes region, the time difference between the LDP/RSVP LSP and the BGP LSP becoming operational can reach hundreds of million-seconds. The larger the network, the bigger the time difference.
  • the introduced synchronization mechanism may be applied to coordinate two types of LSPs, such as BGP LSP and LDP/RSVP LSP, within a network region.
  • LSP such as BGP LSP
  • LDP/RSVP LSP LDP/RSVP LSP underlying the BGP LSP
  • Fig. 3 is a flowchart illustrating a method according to an embodiment of the present disclosure.
  • the method illustrated in Fig. 3 may be performed by an apparatus implemented at a communication device or communicatively coupled to a communication device.
  • the communication device may comprise a router, a node or an entity with label switching functions, such as a PE, an ASBR, a BGP peer or any other device being capable of supporting MPLS.
  • the communication device may be configured to setup hierarchal LSPs for routing traffics in a seamless MPLS network.
  • a synchronization process in response to a synchronization event which indicates potential incoordination between a first LSP and a second LSP underlying the first LSP, a synchronization process may be initiated for the first LSP setup by a first protocol and the second LSP setup by a second protocol, as shown in block 302.
  • the first protocol may comprise a BGP, a BGP-LU, or any other protocol being capable of setting up a LSP riding on top of the second LSP.
  • the second protocol may comprise a LDP, a RSVP, any other protocol capable of setting up a LSP underlying the first LSP, or a combination thereof.
  • the first LSP may comprise a BGP LSP.
  • the second LSP may comprise a LDP/RSVP LSP. In an intraregional MPLS network as illustrated in Fig. 1, the BGP LSP would ride on top of the LDP/RSVP LSP.
  • LSPs herein are not limited to the BGP/BGP-LU LSP and the LDP/RSVP LSP in the context of MPLS, but may comprise other tunnels established by the network operator for a variety of purposes.
  • the proposed methods, apparatus and related products herein may also be applicable to other suitable network environments or protocols which can support various types of label switched routing, although some exemplary embodiments are described with respect to the LSPs setup by the BGP/BGP-LU and the LDP/RSVP.
  • the synchronization event may comprise one of the following: an event of the first LSP becoming operational in a network setup procedure; an event of the first LSP becoming operational in a path recovery procedure; and an event of receiving a report that the second LSP becomes non-operational.
  • non-synchronized statuses of different types of LSPs and/or uncoordinated availabilities of hierarchical LSPs may cause traffic loss in the network.
  • a black hole on the first LSP such as BGP LSP
  • the second LSP such as LDP/RSVP LSP
  • a status of the second LSP may be detected during the synchronization process, as shown in block 304, while the first LSP is in an operational status.
  • the status of the first LSP may become operational from non-operational due to a network setup procedure or a path recovery procedure. Alternatively, the status of the first LSP may be always operational without any change.
  • the second LSP its status may be different from that of the first LSP, for example, due to like failure or different recovery time. Based at least in part on the detection of the status of the second LSP, it may be determined at block 306 whether to terminate the synchronization process.
  • initiating the synchronization process may comprise triggering a synchronization timer for timing the synchronization process.
  • the LDP/RSVP LSP may be considered fully operational when LDP or RSVP hello adjacency exists on the concerned link or path, a suitable associated LDP session or RSVP session is established to the peer, and all label bindings have been exchanged over the path.
  • a simple implementation strategy is to use a configurable LSP synchronization timer to allow establishment of the LDP/RSVP LSP before declaring this LDP/RSVP LSP fully operational.
  • initiating the synchronization process may further comprise decreasing a probability of the first LSP being selected for traffic transmission.
  • this probability may be related to reliability of the first LSP for the traffic transmission. If the reliability of the first LSP is high, it may be encouraged to use the first LSP for the traffic transmission. Thus, decreasing the reliability of the first LSP for the traffic transmission may result in discouraging the first LSP to transmit traffics. It is noted that routing over the first LSP is still regarded as a last resort in case of a massive failure although it is discouraged to transmit traffics over the first LSP during the synchronization process.
  • the reliability of the first LSP for the traffic transmission may be indicated by an AD of the first LSP.
  • the AD is just an example and the reliability for traffic transmission also may be indicated by any other suitable parameter or indicator.
  • a default AD value may be assigned for a LSP in an operational status. The default AD value may be defined and adjusted according to contexts of the network, such as network environments, protocols, services and/or the like. For example, the RSVP LSP, the LDP LSP and the BGP LSP in the operational statuses may be respectively advertised with the default AD values of 6, 7 and 8. It will be realized that other proper values also may be defined as the default AD values.
  • decreasing the probability of the first LSP being selected for the traffic transmission may comprise setting an AD of the first LSP as 254 or any other suitable value indicating the lower transmission reliability.
  • the BGP LSP to the BGP peer will be advertised with a special AD to avoid transmitting any traffic over it. Since the AD value of 255 is reserved as unknown and routing with this AD value will be dropped, the AD value of 254 is proposed here. It is important to keep the BGP route as a last resort in case of a massive failure.
  • determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to detecting an operational status of the second LSP, where the duration of the synchronization process is shorter than a predefined period of time.
  • determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to receiving a synchronization interrupt indication, where no operational status of the second LSP is detected during the synchronization process and the duration of the synchronization process is shorter than a predefined period of time.
  • the synchronization interrupt indication may comprise at least one of a service indication, a control-plane indication and an OAM indication. It will be appreciated that the synchronization interrupt indication may also comprise any other indications which tell that the corresponding LSP peer is unreachable.
  • the synchronization interrupt indication may have a higher priority than the second LSP status change event. Thus, the synchronization process may be terminated by the synchronization interrupt indication even though the second LSP has not become operational and the synchronization timer is not expired yet.
  • determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to the duration of the synchronization process reaching up to a predefined period of time, where no operational status of the second LSP is detected during the synchronization process.
  • the predefined period of time as described with respect to the determination as to whether the synchronization process needs to be terminated may be an expiration period of a synchronization timer.
  • the synchronization timer may be introduced for the LSP synchronization and configured with some predefined parameters. During the LSP synchronization timed by this configurable timer, the traffic transmission over the first LSP are reduced or even avoided so as to wait for the establishment of the second LSP. In other words, the synchronization timer may be used to allow establishing or recovering the second LSP before declaring it as fully operational.
  • the termination of the synchronization process may comprise: stopping the synchronization timer, and increasing the decreased probability of the first LSP being selected for the traffic transmission. For example, when the synchronization timer is stopped, the AD of the first LSP may be changed back to the default AD value, or another AD value indicating the relative higher transmission reliability of the first LSP than that during the synchronization process.
  • the probability of the first LSP being selected for the traffic transmission after the synchronization process may be changed back to that before the synchronization process. For example, it may be corresponding to the case where the operational status of the second LSP is detected during the synchronization process.
  • the probability of the first LSP being selected for the traffic transmission after the synchronization process may be lower than that before the synchronization process, but higher than that during the synchronization process. For example, this may be corresponding to the case where the operational status of the second LSP is not detected during the synchronization process.
  • the hierarchy LSP synchronization function as illustrated in connection with Fig. 3 can be enabled or disabled by some predefined configurations. For example, it may be disabled by default. Alternatively, this function may be enabled as required or for a specific network context. It is proposed to configure this function under BGP neighbors. In this way, it may explicitly tell which BGP LSP segment rides on top of the LDP/RSVP LSP.
  • Fig. 4 is a flowchart illustrating a process of LSP synchronization according to an embodiment of the present disclosure.
  • the LSP synchronization may be implemented at a BGP peer, for example, in a procedure for network setup or path recovery.
  • a black hole on a BGP LSP which may occur in situations where the BGP LSP is operational but the underlay LDP/RSVP LSP is non-operational, may be avoided or eliminated effectively.
  • the exemplary synchronization of different LSPs in Fig. 4 is illustrated with respect to a network environment such as MPLS VPNs using BGP-LU to provide the edge-to-edge or PE-to-PE LSP reachability, it will be appreciated that other network scenarios also may benefit from the synchronization mechanism described here.
  • IGP convergence may be performed at block 402, when faulty paths recover for the BGP-LU enabled MPLS network. Then, the establishment of BGP peers can be carried out at block 404 and BGP-LU label bindings may be exchanged at block 406. As such, a related BGP LSP can be setup between the BGP peers at block 408. If a LSP synchronization function is disabled for the BGP peer, as shown by the “No” branch of block 410, the process proceeds to block 420 and just follows the normal operations for the BGP best path computation without changing the AD value originally set for the BGP LSP.
  • a predefined AD value such as 254 may be set for the related BGP LSP which becomes operational, and a LSP synchronization timer can be triggered correspondingly, as shown in block 412.
  • the AD of the BGP LSP may be set or initialized as any suitable value which can restrain or even prevent traffic transmission over the BGP LSP compared with the case where the AD of the BGP LSP is set as the default value.
  • the triggered LSP synchronization timer can be used for timing the execution of the LSP synchronization function.
  • the expiration period of the synchronization timer can be predefined according to network configurations or set dynamically as required.
  • the underlay LDP/RSVP LSP status may be checked or monitored during the LSP synchronization, as shown in block 414.
  • the underlay LDP/RSVP LSP status may be enrolled to indicate whether the AD of the BGP LSP needs to be changed.
  • the AD of the BGP LSP may be used with the synchronization timer to indicate whether to continue monitoring the LDP/RSVP LSP status. For example, if the AD of the BGP LSP is 254 and the synchronization timer is not expired, the BGP peer may check the LDP/RSVP LSP status in a round robin style.
  • the LDP/RSVP LSP status may be checked or detected periodically or according to a predefined criterion, if a condition to terminate the LSP synchronization is not satisfied, as shown by the “No” branch of block 416.
  • the condition to terminate the LSP synchronization may comprise: the LDP/RSVP LSP becoming operational before the synchronization timer expires, the expiration of the synchronization timer, reception of a synchronization interrupt indication, or any event triggering the termination of the LSP synchronization.
  • the LSP synchronization is terminated and the process proceeds to block 418, where the BGP peer may change the AD of the BGP LSP back to the default value.
  • the BGP LSP with the default AD is enrolled for the BGP best path computation. It is noted that the BGP best path computation during the LSP synchronization may also comprise this BGP LSP, but the AD value of 254 may decrease the probability of the BGP LSP being selected as the best BGP path.
  • traffics can be conveyed to the selected best BGP path according to the BGP best path computation.
  • the LSP synchronization as illustrated in Fig. 4 also may be applied in a procedure during which the LDP/RSVP LSP status changes from operational to other status such as non-operational.
  • an LDP/RSVP LSP status change event can be sent or reported to the corresponding BGP peer.
  • the BGP peer may change the AD to 254 for the top BGP LSP while triggering the synchronization timer.
  • the BGP peer can terminate the LSP synchronization by stopping the synchronization timer and adjusting the BGP LSP AD correspondingly, and follow its original procedure for further actions.
  • the proposed LSP synchronization solution as illustrated with respect to Figs. 1-4 can orchestrate different types of LSPs effectively, so as to eliminate or reduce the traffic loss due to incoordination of LSPs setup by different protocols. For example, a black hole on a BGP LSP for a MPLS network, which may occur in situations where the BGP LSP is operational but the underlay LDP/RSVP LSP is not, may be avoid by applying the proposed LSP synchronization solution.
  • Figs. 1-4 may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function (s) .
  • the schematic flow chart diagrams described above are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of specific embodiments of the presented methods. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated methods. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
  • Fig. 5 is a block diagram illustrating an apparatus 500 according to an embodiment of the present disclosure.
  • the apparatus 500 may comprise one or more processors such as processor 501 and one or more memories such as memory 502 storing computer program codes 503.
  • the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform any operation of the method as described in connection with any of Figs. 2-4.
  • the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
  • Fig. 6 is a block diagram illustrating another apparatus 600 according to another embodiment of the present disclosure.
  • the apparatus 600 may comprise an initiating module 601, a detecting module 602 and a determining module 603.
  • the apparatus 600 may be implemented at a communication device such as a BGP peer.
  • the initiating module 601 may be operable to carry out the operation in block 302
  • the detecting module 602 may be operable to carry out the operation in block 304
  • the determining module 603 may be operable to carry out the operation in block 306.
  • the initiating module 601, the detecting module 602 and/or the determining module 603 may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
  • the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic or any combination thereof.
  • some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto.
  • firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto.
  • While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
  • the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.
  • exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device.
  • the computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, random access memory (RAM) , etc.
  • RAM random access memory
  • the function of the program modules may be combined or distributed as desired in various embodiments.
  • the function may be embodied in whole or partly in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA) , and the like.

Abstract

A method for communications is proposed. The method may comprise initiating a synchronization process for a first label switched path setup by a first protocol and a second label switched path setup by a second protocol, in response to a synchronization event which indicates potential incoordination between the first label switched path and the second label switched path underlying the first label switched path. According to the method, a status of the second label switched path may be detected during the synchronization process, while the first label switched path is in an operational status. The method may further comprise determining whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path.

Description

SYNCHRONIZATION OF LABEL SWITCHED PATHS FIELD OF THE INVENTION
The present disclosure generally relates to communication networks, and more specifically, relates to label switching networks.
BACKGROUND
This section introduces aspects that may facilitate a better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.
Communication service providers and network operators have been continually facing challenges to deliver value and convenience to consumers by, for example, providing compelling network services and performances. Nowadays, more and more telecommunication operators deploy multi-protocol label switching (MPLS) for a better user experience. MPLS is a mechanism in high-performance telecommunications networks, which directs data from a network node to the next based on short path labels rather than long network addresses. In a MPLS network, data packets are assigned labels. Packet-forwarding decisions can be made solely on the contents of this label. This allows one to create end-to-end virtual circuits across any type of transport medium, using any protocol. A label switched path (LSP) can be setup to transport traffics in the MPLS network. Different types of LSPs for the MPLS network may be setup independently since they may be signaled by different protocols. Traffic loss may happen in situations where different types of LSPs are not coordinated properly.
SUMMARY
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In a communication system such as a MPLS network, various label signaling mechanisms, such as a border gateway protocol (BGP) , a border gateway protocol labeled unicast (BGP-LU) , a label distribution protocol (LDP) , a resource reservation protocol (RSVP) and/or the like, may be used to establish LSPs for routing traffics through the network. However, a black hole of traffic communications may occur due to incoordination of LSPs setup by different protocols. Therefore, it may be desirable to synchronize different types of LSPs, so as to coordinate the traffic communications over the LSPs.
The present disclosure proposes a solution for synchronization of different LSPs, which may orchestrate the hierarchy LSPs by controlling traffic transmissions on a LSP, so that the traffic loss caused by the availability incoordination of the LSPs for transmitting traffics may be eliminated or reduced.
According to a first aspect of the present disclosure, there is provided a method implemented at a communication device. The method may comprise initiating a synchronization process for a first LSP setup by a first protocol and a second LSP setup by a second protocol, in response to a synchronization event which indicates potential incoordination between the first LSP and the second LSP underlying the first LSP. The method may further comprise detecting a status of the second LSP during the synchronization process, where the first LSP is in an operational status. Based at least in part on the detection of the status of the second  LSP, it may be determined whether to terminate the synchronization process.
According to a second aspect of the present disclosure, there is provided an apparatus. The apparatus may comprise one or more processors and one or more memories comprising computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the apparatus at least to perform any step of the method according to the first aspect of the present disclosure.
According to a third aspect of the present disclosure, there is provided a computer program product comprising a computer-readable medium bearing computer program codes embodied therein for use with a computer. The computer program codes may comprise code for performing any step of the method according to the first aspect of the present disclosure.
According to a fourth aspect of the present disclosure, there is provided an apparatus. The apparatus may comprise an initiating module, a detecting module and a determining module. In accordance with some exemplary embodiments, the initiating module may be operable to carry out at least the initiating step of the method according to the first aspect of the present disclosure. The detecting module may be operable to carry out at least the detecting step of the method according to the first aspect of the present disclosure. The determining module may be operable to carry out at least the determining step of the method according to the first aspect of the present disclosure.
In accordance with an exemplary embodiment, initiating the synchronization process may comprise: triggering a synchronization timer for timing the synchronization process; and decreasing a probability of the first LSP being selected for traffic transmission.
In accordance with an exemplary embodiment, the probability of the first LSP being selected for traffic transmission may be related to reliability of the first LSP for the traffic transmission.
In accordance with an exemplary embodiment, the reliability of the first LSP for the traffic transmission may be indicated by an administrative distance (AD) of the first LSP.
In accordance with an exemplary embodiment, decreasing the probability of the first LSP being selected for the traffic transmission may comprise: setting an AD of the first LSP as 254.
In accordance with an exemplary embodiment, the termination of the synchronization process may comprise: stopping the synchronization timer; and increasing the decreased probability of the first LSP being selected for the traffic transmission.
In accordance with an exemplary embodiment, the synchronization event may comprise one of the following: an event of the first LSP becoming operational in a network setup procedure; an event of the first LSP becoming operational in a path recovery procedure; and an event of receiving a report that the second LSP becomes non-operational.
In accordance with an exemplary embodiment, determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to detecting an operational status of the second LSP, wherein the duration of the synchronization process is shorter than a predefined period of time.
In accordance with an exemplary embodiment, determining whether to terminate the synchronization process based at least in part on the detection of the  status of the second LSP may comprise: determining to terminate the synchronization process, in response to receiving a synchronization interrupt indication, wherein no operational status of the second LSP is detected during the synchronization process and the duration of the synchronization process is shorter than a predefined period of time.
In accordance with an exemplary embodiment, the synchronization interrupt indication may comprise at least one of a service indication, a control-plane indication, and an operations, administration and maintenance (OAM) indication.
In accordance with an exemplary embodiment, determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to the duration of the synchronization process reaching up to a predefined period of time, wherein no operational status of the second LSP is detected during the synchronization process.
In accordance with an exemplary embodiment, the predefined period of time may be an expiration period of a synchronization timer.
In accordance with an exemplary embodiment, the first protocol may comprise a BGP or a BGP-LU.
In accordance with an exemplary embodiment, the second protocol may comprise a LDP, a RSVP or a combination thereof.
BRIEF DESCRIPTION OF THE DRAWINGS
The disclosure itself, the preferable mode of use and further objectives are best understood by reference to the following detailed description of the  embodiments when read in conjunction with the accompanying drawings, in which:
Fig. 1 is a diagram illustrating an exemplary communication network according to an embodiment of the present disclosure;
Fig. 2 is a diagram illustrating an example of route convergence according to an embodiment of the present disclosure;
Fig. 3 is a flowchart illustrating a method according to an embodiment of the present disclosure;
Fig. 4 is a flowchart illustrating a process of LSP synchronization according to an embodiment of the present disclosure;
Fig. 5 is a block diagram illustrating an apparatus according to an embodiment of the present disclosure; and
Fig. 6 is a block diagram illustrating another apparatus according to another embodiment of the present disclosure.
DETAILED DESCRIPTION
The embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled persons in the art to better understand and thus implement the present disclosure, rather than suggesting any limitations on the scope of the present disclosure. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an  embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.
As used herein, the term “communication device” may refer to an electronic device that communicatively interconnects other electronic devices on the network, such as network devices, end-user devices or the like. The communication device may act as a multiple services communication device which can provide support for multiple networking functions (for example, routing, bridging, switching, session border control, and/or subscriber management) , and/or provide support for multiple application services (for example, data, voice and/or video) .
As used herein, the terms “first” , “second” and so forth refer to different elements. The singular forms “a” and “an” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” as used herein, specify the presence of stated features, elements, and/or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. The term “based on” is to be read as “based at least in part on” . The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment” . The term “another embodiment” is to be read as “at least one other embodiment” . Other definitions, explicit and implicit, may be included below.
In a communication system such as a MPLS network, routers that perform  routing based on the label are called label switch routers (LSRs) . The ingress node and the egress node of a MPLS LSP are called label edge routers (LERs) , which, respectively, push a MPLS label onto an incoming packet and pop it off the outgoing packet. LSPs, which may also be referred to as “tunnels” , are established by the network operator for a variety of purposes, such as to create network-based Internet protocol (IP) virtual private networks or to route traffics along specified paths through the network.
Labels are distributed between LERs and LSRs manually or by using the label signaling mechanisms, such as LDP and RSVP. LDP/RSVP is widely deployed in MPLS networks as a signaling protocol for LSPs. LDP/RSVP LSPs may be used as transport LSPs in applications such as BGP free core, layer 2 virtual private network (L2VPN) , layer 3 virtual private network (L3VPN) and other applications, by stacking the LDP/RSVP LSP label (the tunnel label) over the application label. However, LDP/RSVP cannot be used to establish edge-to-edge LSPs for interconnecting network domains. Inter-domain LSPs are generally setup using BGP or BGP-LU.
BGP is a widely used protocol for interconnecting network domains, for example, interconnecting autonomous systems (AS) , operated by different service providers. This protocol is designed to exchange routing and reachability information, such as information between routers as to which destination networks are reachable through which routers. BGP-capable routers are called BGP speakers. Neighbor BGP speakers are called BGP peers. As a label signaling and routing protocol between BGP peers, BGP-LU (for example, as defined by RFC3107) is very useful where a MPLS network is segmented within an AS or spanned across multiple-AS.
Nowadays, BGP is also used to support other applications than traditional Internet applications, for example to carry reachability information for VPNs. In the  MPLS VPNs application, BGP may be used to distribute VPN reachability information across a provider backbone, and MPLS is used to transport VPN traffics from a VPN site to another over the provider backbone. The provider backbone may be made of several interconnected domains, and each domain such as an AS may be operated by a service provider.
Fig. 1 is a diagram illustrating an exemplary communication network according to an embodiment of the present disclosure. The communication network shown in Fig. 1 is an example of Inter-AS MPLS VPN Option-C. This exemplary communication network may comprise a seamless MPLS or scaled MPLS network which uses BGP-LU to establish edge-to-edge LSP or provider edge-to-provider edge (PE-to-PE) LSP.
It is noted that some embodiments of the present disclosure are mainly described in relation to MPLS specifications being used as non-limiting examples for certain exemplary network configurations and system deployments. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples and embodiments, and does naturally not limit the present disclosure in any way. Rather, any other system configuration or deployment may equally be utilized as long as complying with what is described herein and/or exemplary embodiments described herein are applicable to it.
As shown in Fig. 1, traffic communications from a customer edge (CE) device such as CE1 to another CE device such as CE2 are across two network regions, which are denoted by AS100 and AS 200 in Fig. 1. The CE device may be attached to one or more devices acting as provider edge (PE) routers through an attachment circuit. For example, Fig. 1 shows that CE1 is attached to a PE router PE1 (which is also denoted by D1 in Fig. 1) , and CE2 is attached to another PE router PE2 (which is  also denoted by D7 in Fig. 1) . Routers in the network which do not attach to CE devices are known as P routers, such as D2 shown in Fig. 1. Routers located at the border between two ASs are known as autonomous system border routers (ASBR) , such as ASBR1, ASBR2, ASBR3 and ASBR4 which are respectively denoted by D3, D4, D5 and D6 in Fig. 1.
An AS, which also may be regarded as an intraregional MPLS network, typically employs an interior gateway protocol (IGP) to exchange network topology information among routers within the AS. BGP may be used to exchange the reachability information of the network between BGP peers, such as PE1, PE2, ASBR1, ASBR2, ASBR3 and ASBR4. In an intraregional MPLS network, the BGP LSP setup by BGP or BGP-LU needs to ride on top of the LDP/RSVP LSP which is setup by LDP, RSVP or the combination thereof.
The exemplary network as shown in Fig. 1 illustrates how BGP-LU behaves in the context of Inter-AS MPLS VPN Option-C. According to an exemplary embodiment, a PE such as PE1 may allocate three labels to an unlabeled packet. A service label as the inner label can identify a MPLS service for L2VPN/L3VPN. The middle label allocated by BGP-LU for the Inter-AS MPLS network is used to forward the packet to the final edge or PE such as PE2, forming an inter-region LSP. The outer label allocated by LDP and/or RSVP is used to forward the packet to the internal BGP (IBGP) peer in the same region, forming an intra-region LSP.
As shown in Fig. 1, on the inter-region LSP, the middle label allocated by BGP-LU is supported by the IBGP in the same region and by the external BGP (EBGP) between two regions. On the intra-region LSP, the outer label allocated by LDP and/or RSVP is coupled with IGP1 in AS100 and with IGP2 in AS200.
According to an exemplary embodiment, for CE1 to CE2 direction shown in Fig. 1, PE1 may send traffics from CE1 to ASBR1 as ASBR1 is the next hop of the  best BGP path. When ASBR1 becomes unreachable, the traffics can be switched to ASBR2. Venders spare no efforts to make sure the traffic switch performance is in million-seconds instead of in seconds. There are technologies to achieve this when a path failure happens in the network. For example, the 50ms traffic switch performance can be achieved by deploying BGP fast re-route (BGPFRR) . But when the path failure is cleared, traffic loss may happen as well during route convergence.
Fig. 2 is a diagram illustrating an example of route convergence according to an embodiment of the present disclosure. The exemplary route convergence shown in Fig. 2 may be performed in a path recover procedure for a BGP-LU enabled MPLS network. The path recover procedure may be initiated due to a path failure such as a link failure, a node failure and/or the like.
According to an exemplary embodiment, in an intraregional MPLS network such as AS100 or AS200 as shown in Fig. 1, the BGP LSP setup by BGP-LU rides on top of the LDP/RSVP LSP setup by LDP and/or RSVP. The BGP LSP and the LDP/RSVP LSP are setup independently since they are signaled by different protocols. When the path recover procedure is initiated, IGP convergence may be performed for the route convergence as shown in block 202, and then the LDP/RSVP LSP and the BGP LSP may be setup according to corresponding protocols, as respectively shown in  blocks  204 and 206. The BGP LSP which is setup in block 206 may be included in BGP best path computation, as shown in block 208. Traffics can be conveyed with the selected BGP path according to the BGP best path computation, as shown in block 210.
Most of the time, the BGP LSP becomes operational before the underlay LDP/RSVP LSP. Taking the traffic transmission shown in Fig. 1 as an example, when the faulty path associated with ASBR1 recovers, the BGP LSP between PE1 and ASBR1 recovers but the underlying LDP/RSVP LSP is not yet. Still, ASBR1 is  selected as the best path to CE2 according to the BGP best path computation. Traffics are then switched back to ASBR1. As a result, a black hole occurs and traffics may be dropped before the LDP/RSVP LSP between PE1 and ASBR1 becomes operational. The duration depends on the extra time which the LDP/RSVP LSP takes to become operational. For example, for a three nodes region, the time difference between the LDP/RSVP LSP and the BGP LSP becoming operational can reach hundreds of million-seconds. The larger the network, the bigger the time difference.
Therefore, it is desirable to introduce a synchronization mechanism to couple different types of LSPs. For example, the introduced synchronization mechanism may be applied to coordinate two types of LSPs, such as BGP LSP and LDP/RSVP LSP, within a network region. In the proposed synchronization mechanism according to some exemplary embodiments of the present disclosure, if a type of LSP (such as BGP LSP) is operational in advance, this type of LSP will be discouraged for traffic forwarding as long as another type of LSP (such as LDP/RSVP LSP underlying the BGP LSP) is not fully operational. Taking the advantage of the proposed synchronization mechanism makes it possible to eliminate or reduce the traffic loss due to the incoordination of operation statuses of different types of LSPs.
Fig. 3 is a flowchart illustrating a method according to an embodiment of the present disclosure. The method illustrated in Fig. 3 may be performed by an apparatus implemented at a communication device or communicatively coupled to a communication device. In accordance with an exemplary embodiment, the communication device may comprise a router, a node or an entity with label switching functions, such as a PE, an ASBR, a BGP peer or any other device being capable of supporting MPLS. In particular, the communication device may be configured to setup hierarchal LSPs for routing traffics in a seamless MPLS network. 
According to the exemplary method illustrated in Fig. 3, in response to a synchronization event which indicates potential incoordination between a first LSP and a second LSP underlying the first LSP, a synchronization process may be initiated for the first LSP setup by a first protocol and the second LSP setup by a second protocol, as shown in block 302.
In accordance with an exemplary embodiment, the first protocol may comprise a BGP, a BGP-LU, or any other protocol being capable of setting up a LSP riding on top of the second LSP. The second protocol may comprise a LDP, a RSVP, any other protocol capable of setting up a LSP underlying the first LSP, or a combination thereof. Accordingly, the first LSP may comprise a BGP LSP. The second LSP may comprise a LDP/RSVP LSP. In an intraregional MPLS network as illustrated in Fig. 1, the BGP LSP would ride on top of the LDP/RSVP LSP.
It is noted that the exemplary illustrations of LSPs herein are not limited to the BGP/BGP-LU LSP and the LDP/RSVP LSP in the context of MPLS, but may comprise other tunnels established by the network operator for a variety of purposes. The proposed methods, apparatus and related products herein may also be applicable to other suitable network environments or protocols which can support various types of label switched routing, although some exemplary embodiments are described with respect to the LSPs setup by the BGP/BGP-LU and the LDP/RSVP.
In accordance with an exemplary embodiment, the synchronization event may comprise one of the following: an event of the first LSP becoming operational in a network setup procedure; an event of the first LSP becoming operational in a path recovery procedure; and an event of receiving a report that the second LSP becomes non-operational.
As illustrated in connection with Fig. 1 and Fig. 2, non-synchronized statuses of different types of LSPs and/or uncoordinated availabilities of hierarchical  LSPs may cause traffic loss in the network. For example, a black hole on the first LSP (such as BGP LSP) may occur in situations where the first LSP is operational but the second LSP (such as LDP/RSVP LSP) is not. Therefore, it may be advantageous to enroll a status of the second LSP to orchestrate the two types of LSPs.
Referring back to Fig. 3, a status of the second LSP may be detected during the synchronization process, as shown in block 304, while the first LSP is in an operational status. The status of the first LSP may become operational from non-operational due to a network setup procedure or a path recovery procedure. Alternatively, the status of the first LSP may be always operational without any change. For the second LSP, its status may be different from that of the first LSP, for example, due to like failure or different recovery time. Based at least in part on the detection of the status of the second LSP, it may be determined at block 306 whether to terminate the synchronization process.
According to an exemplary embodiment, initiating the synchronization process may comprise triggering a synchronization timer for timing the synchronization process. In an example of the second LSP being a LDP/RSVP LSP, the LDP/RSVP LSP may be considered fully operational when LDP or RSVP hello adjacency exists on the concerned link or path, a suitable associated LDP session or RSVP session is established to the peer, and all label bindings have been exchanged over the path. However, such conditions cannot generally be verified by a router and some estimation may have to be used. A simple implementation strategy is to use a configurable LSP synchronization timer to allow establishment of the LDP/RSVP LSP before declaring this LDP/RSVP LSP fully operational.
According to an exemplary embodiment, initiating the synchronization process may further comprise decreasing a probability of the first LSP being selected  for traffic transmission. For example, this probability may be related to reliability of the first LSP for the traffic transmission. If the reliability of the first LSP is high, it may be encouraged to use the first LSP for the traffic transmission. Thus, decreasing the reliability of the first LSP for the traffic transmission may result in discouraging the first LSP to transmit traffics. It is noted that routing over the first LSP is still regarded as a last resort in case of a massive failure although it is discouraged to transmit traffics over the first LSP during the synchronization process.
In accordance with an exemplary embodiment, the reliability of the first LSP for the traffic transmission may be indicated by an AD of the first LSP. It is noted that the AD is just an example and the reliability for traffic transmission also may be indicated by any other suitable parameter or indicator. A default AD value may be assigned for a LSP in an operational status. The default AD value may be defined and adjusted according to contexts of the network, such as network environments, protocols, services and/or the like. For example, the RSVP LSP, the LDP LSP and the BGP LSP in the operational statuses may be respectively advertised with the default AD values of 6, 7 and 8. It will be realized that other proper values also may be defined as the default AD values.
According to an exemplary embodiment, decreasing the probability of the first LSP being selected for the traffic transmission may comprise setting an AD of the first LSP as 254 or any other suitable value indicating the lower transmission reliability. For example, when the LDP/RSVP LSP to a given BGP peer is detected as “not fully operational” , the BGP LSP to the BGP peer will be advertised with a special AD to avoid transmitting any traffic over it. Since the AD value of 255 is reserved as unknown and routing with this AD value will be dropped, the AD value of 254 is proposed here. It is important to keep the BGP route as a last resort in case of a massive failure.
According to an exemplary embodiment, determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to detecting an operational status of the second LSP, where the duration of the synchronization process is shorter than a predefined period of time.
Alternatively or additionally, determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to receiving a synchronization interrupt indication, where no operational status of the second LSP is detected during the synchronization process and the duration of the synchronization process is shorter than a predefined period of time. According to an exemplary embodiment, the synchronization interrupt indication may comprise at least one of a service indication, a control-plane indication and an OAM indication. It will be appreciated that the synchronization interrupt indication may also comprise any other indications which tell that the corresponding LSP peer is unreachable. The synchronization interrupt indication may have a higher priority than the second LSP status change event. Thus, the synchronization process may be terminated by the synchronization interrupt indication even though the second LSP has not become operational and the synchronization timer is not expired yet.
Alternatively or additionally, determining whether to terminate the synchronization process based at least in part on the detection of the status of the second LSP may comprise: determining to terminate the synchronization process, in response to the duration of the synchronization process reaching up to a predefined period of time, where no operational status of the second LSP is detected during the synchronization process.
According to an exemplary embodiment, the predefined period of time as  described with respect to the determination as to whether the synchronization process needs to be terminated may be an expiration period of a synchronization timer. The synchronization timer may be introduced for the LSP synchronization and configured with some predefined parameters. During the LSP synchronization timed by this configurable timer, the traffic transmission over the first LSP are reduced or even avoided so as to wait for the establishment of the second LSP. In other words, the synchronization timer may be used to allow establishing or recovering the second LSP before declaring it as fully operational.
According to an exemplary embodiment, the termination of the synchronization process may comprise: stopping the synchronization timer, and increasing the decreased probability of the first LSP being selected for the traffic transmission. For example, when the synchronization timer is stopped, the AD of the first LSP may be changed back to the default AD value, or another AD value indicating the relative higher transmission reliability of the first LSP than that during the synchronization process.
As such, the probability of the first LSP being selected for the traffic transmission after the synchronization process may be changed back to that before the synchronization process. For example, it may be corresponding to the case where the operational status of the second LSP is detected during the synchronization process. Optionally, the probability of the first LSP being selected for the traffic transmission after the synchronization process may be lower than that before the synchronization process, but higher than that during the synchronization process. For example, this may be corresponding to the case where the operational status of the second LSP is not detected during the synchronization process.
In accordance with an exemplary embodiment, the hierarchy LSP synchronization function as illustrated in connection with Fig. 3 can be enabled or  disabled by some predefined configurations. For example, it may be disabled by default. Alternatively, this function may be enabled as required or for a specific network context. It is proposed to configure this function under BGP neighbors. In this way, it may explicitly tell which BGP LSP segment rides on top of the LDP/RSVP LSP.
Fig. 4 is a flowchart illustrating a process of LSP synchronization according to an embodiment of the present disclosure. The LSP synchronization may be implemented at a BGP peer, for example, in a procedure for network setup or path recovery. By using the LSP synchronization, a black hole on a BGP LSP, which may occur in situations where the BGP LSP is operational but the underlay LDP/RSVP LSP is non-operational, may be avoided or eliminated effectively. Although the exemplary synchronization of different LSPs in Fig. 4 is illustrated with respect to a network environment such as MPLS VPNs using BGP-LU to provide the edge-to-edge or PE-to-PE LSP reachability, it will be appreciated that other network scenarios also may benefit from the synchronization mechanism described here.
In the process illustrated with respect to Fig. 4, IGP convergence may be performed at block 402, when faulty paths recover for the BGP-LU enabled MPLS network. Then, the establishment of BGP peers can be carried out at block 404 and BGP-LU label bindings may be exchanged at block 406. As such, a related BGP LSP can be setup between the BGP peers at block 408. If a LSP synchronization function is disabled for the BGP peer, as shown by the “No” branch of block 410, the process proceeds to block 420 and just follows the normal operations for the BGP best path computation without changing the AD value originally set for the BGP LSP.
If the LSP synchronization function is enabled for the BGP peer, as shown by the “Yes” branch of block 410, a predefined AD value such as 254 may be set for the related BGP LSP which becomes operational, and a LSP synchronization timer  can be triggered correspondingly, as shown in block 412. It will be realized that the AD of the BGP LSP may be set or initialized as any suitable value which can restrain or even prevent traffic transmission over the BGP LSP compared with the case where the AD of the BGP LSP is set as the default value. The triggered LSP synchronization timer can be used for timing the execution of the LSP synchronization function. To this regard, it may be allowed to take a certain period of time (for example, up to an expiration period of the synchronization timer) to establish a LDP/RSVP LSP for the BGP peer. The expiration period of the synchronization timer can be predefined according to network configurations or set dynamically as required.
In the process as illustrated in Fig. 4, the underlay LDP/RSVP LSP status may be checked or monitored during the LSP synchronization, as shown in block 414. The underlay LDP/RSVP LSP status may be enrolled to indicate whether the AD of the BGP LSP needs to be changed. From another aspect, the AD of the BGP LSP may be used with the synchronization timer to indicate whether to continue monitoring the LDP/RSVP LSP status. For example, if the AD of the BGP LSP is 254 and the synchronization timer is not expired, the BGP peer may check the LDP/RSVP LSP status in a round robin style.
The LDP/RSVP LSP status may be checked or detected periodically or according to a predefined criterion, if a condition to terminate the LSP synchronization is not satisfied, as shown by the “No” branch of block 416. The condition to terminate the LSP synchronization may comprise: the LDP/RSVP LSP becoming operational before the synchronization timer expires, the expiration of the synchronization timer, reception of a synchronization interrupt indication, or any event triggering the termination of the LSP synchronization.
If the condition to terminate the LSP synchronization is satisfied, as  shown by the “Yes” branch of block 416, the LSP synchronization is terminated and the process proceeds to block 418, where the BGP peer may change the AD of the BGP LSP back to the default value. In block 420, the BGP LSP with the default AD is enrolled for the BGP best path computation. It is noted that the BGP best path computation during the LSP synchronization may also comprise this BGP LSP, but the AD value of 254 may decrease the probability of the BGP LSP being selected as the best BGP path. In block 422, traffics can be conveyed to the selected best BGP path according to the BGP best path computation.
In accordance with an exemplary embodiment, the LSP synchronization as illustrated in Fig. 4 also may be applied in a procedure during which the LDP/RSVP LSP status changes from operational to other status such as non-operational. For example, when the underlay LDP/RSVP LSP turns non-operational, an LDP/RSVP LSP status change event can be sent or reported to the corresponding BGP peer. The BGP peer may change the AD to 254 for the top BGP LSP while triggering the synchronization timer.
If the BGP peer receives one or more indications which have higher priorities than the LDP/RSVP LSP status change event, such as a service indication, a control-plane indication, an OAM indication or any other indications reporting that the related BGP peer is unreachable, the BGP peer can terminate the LSP synchronization by stopping the synchronization timer and adjusting the BGP LSP AD correspondingly, and follow its original procedure for further actions.
The proposed LSP synchronization solution as illustrated with respect to Figs. 1-4 can orchestrate different types of LSPs effectively, so as to eliminate or reduce the traffic loss due to incoordination of LSPs setup by different protocols. For example, a black hole on a BGP LSP for a MPLS network, which may occur in situations where the BGP LSP is operational but the underlay LDP/RSVP LSP is not,  may be avoid by applying the proposed LSP synchronization solution. In addition, it may be beneficial to configure the LSP synchronization function under BGP neighbors, since such configuration can indicate which BGP LSP segment rides on top of the LDP/RSVP LSP.
The various blocks shown in Figs. 1-4 may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function (s) . The schematic flow chart diagrams described above are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of specific embodiments of the presented methods. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated methods. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
Fig. 5 is a block diagram illustrating an apparatus 500 according to an embodiment of the present disclosure. As shown in Fig. 5, the apparatus 500 may comprise one or more processors such as processor 501 and one or more memories such as memory 502 storing computer program codes 503. The one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform any operation of the method as described in connection with any of Figs. 2-4. Alternatively or additionally, the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
Fig. 6 is a block diagram illustrating another apparatus 600 according to  another embodiment of the present disclosure. As shown in Fig. 6, the apparatus 600 may comprise an initiating module 601, a detecting module 602 and a determining module 603. In an exemplary embodiment, the apparatus 600 may be implemented at a communication device such as a BGP peer. The initiating module 601 may be operable to carry out the operation in block 302, the detecting module 602 may be operable to carry out the operation in block 304, and the determining module 603 may be operable to carry out the operation in block 306. Optionally, the initiating module 601, the detecting module 602 and/or the determining module 603 may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
In general, the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
As such, it should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry  (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.
It should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, random access memory (RAM) , etc. As will be appreciated by one of skill in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or partly in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA) , and the like.
The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-Limiting and exemplary embodiments of this disclosure.

Claims (30)

  1. A method implemented at a communication device, comprising:
    initiating (302) a synchronization process for a first label switched path setup by a first protocol and a second label switched path setup by a second protocol, in response to a synchronization event which indicates potential incoordination between the first label switched path and the second label switched path underlying the first label switched path;
    detecting (304) a status of the second label switched path during the synchronization process, wherein the first label switched path is in an operational status; and
    determining (306) whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path.
  2. The method according to claim 1, wherein initiating the synchronization process comprises:
    triggering a synchronization timer for timing the synchronization process; and
    decreasing a probability of the first label switched path being selected for traffic transmission.
  3. The method according to claim 2, wherein the probability is related to reliability of the first label switched path for the traffic transmission.
  4. The method according to claim 3, wherein the reliability of the first label switched path for the traffic transmission is indicated by an administrative distance of the first label switched path.
  5. The method according to any of claims 2 to 4, wherein decreasing the probability of the first label switched path being selected for the traffic transmission comprises:
    setting an administrative distance of the first label switched path as 254.
  6. The method according to any of claims 2 to 5, wherein the termination of the synchronization process comprises:
    stopping the synchronization timer; and
    increasing the decreased probability of the first label switched path being selected for the traffic transmission.
  7. The method according to any of claims 1 to 6, wherein the synchronization event comprises one of the following:
    an event of the first label switched path becoming operational in a network setup procedure;
    an event of the first label switched path becoming operational in a path recovery procedure; and
    an event of receiving a report that the second label switched path becomes non-operational.
  8. The method according to any of claims 1 to 7, wherein determining whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path comprises:
    determining to terminate the synchronization process, in response to detecting an operational status of the second label switched path, wherein the duration of the synchronization process is shorter than a predefined period of time.
  9. The method according to any of claims 1 to 8, wherein determining whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path comprises:
    determining to terminate the synchronization process, in response to receiving a synchronization interrupt indication, wherein no operational status of the second label switched path is detected during the synchronization process and the duration of the synchronization process is shorter than a predefined period of time.
  10. The method according to claim 9, wherein the synchronization interrupt indication comprises at least one of a service indication, a control-plane indication, and an operations, administration and maintenance indication.
  11. The method according to any of claims 1 to 10, wherein determining whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path comprises:
    determining to terminate the synchronization process, in response to the duration of the synchronization process reaching up to a predefined period of time, wherein no operational status of the second label switched path is detected during the synchronization process.
  12. The method according to any of claims 8 to 11, wherein the predefined period of time is an expiration period of a synchronization timer.
  13. The method according to any of claims 1 to 12, wherein the first protocol comprises a border gateway protocol or a border gateway protocol labeled unicast.
  14. The method according to any of claims 1 to 13, wherein the second protocol comprises a label distribution protocol, a resource reservation protocol or a  combination thereof.
  15. An apparatus (500) , comprising:
    one or more processors (501) ; and
    one or more memories (502) comprising computer program codes (503) ,
    the one or more memories (502) and the computer program codes (503) configured to, with the one or more processors (501) , cause the apparatus (500) at least to:
    initiate a synchronization process for a first label switched path setup by a first protocol and a second label switched path setup by a second protocol, in response to a synchronization event which indicates potential incoordination between the first label switched path and the second label switched path underlying the first label switched path;
    detect a status of the second label switched path during the synchronization process, wherein the first label switched path is in an operational status; and
    determine whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path.
  16. The apparatus according to claim 15, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the apparatus to initiate the synchronization process by:
    triggering a synchronization timer for timing the synchronization process; and
    decreasing a probability of the first label switched path being selected for traffic transmission.
  17. The apparatus according to claim 16, wherein the probability is related to reliability of the first label switched path for the traffic transmission.
  18. The apparatus according to claim 17, wherein the reliability of the first label switched path for the traffic transmission is indicated by an administrative distance of the first label switched path.
  19. The apparatus according to any of claims 16 to 18, wherein decreasing the probability of the first label switched path being selected for the traffic transmission comprises:
    setting an administrative distance of the first label switched path as 254.
  20. The apparatus according to any of claims 16 to 19, wherein the termination of the synchronization process comprises:
    stopping the synchronization timer; and
    increasing the decreased probability of the first label switched path being selected for the traffic transmission.
  21. The apparatus according to any of claims 15 to 20, wherein the synchronization event comprises one of the following:
    an event of the first label switched path becoming operational in a network setup procedure;
    an event of the first label switched path becoming operational in a path recovery procedure; and
    an event of receiving a report that the second label switched path becomes non-operational.
  22. The apparatus according to any of claims 15 to 21, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the apparatus to determine whether to terminate the synchronization process based at least in part on the detection of the status of the second label  switched path by:
    determining to terminate the synchronization process, in response to detecting an operational status of the second label switched path, wherein the duration of the synchronization process is shorter than a predefined period of time.
  23. The apparatus according to any of claims 15 to 22, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the apparatus to determine whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path by:
    determining to terminate the synchronization process, in response to receiving a synchronization interrupt indication, wherein no operational status of the second label switched path is detected during the synchronization process and the duration of the synchronization process is shorter than a predefined period of time.
  24. The apparatus according to claim 23, wherein the synchronization interrupt indication comprises at least one of a service indication, a control-plane indication, and an operations, administration and maintenance indication.
  25. The apparatus according to any of claims 15 to 24, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the apparatus to determine whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path by:
    determining to terminate the synchronization process, in response to the duration of the synchronization process reaching up to a predefined period of time, wherein no operational status of the second label switched path is detected during the synchronization process.
  26. The apparatus according to any of claims 22 to 25, wherein the predefined period of time is an expiration period of a synchronization timer.
  27. The apparatus according to any of claims 15 to 26, wherein the first protocol comprises a border gateway protocol or a border gateway protocol labeled unicast.
  28. The apparatus according to any of claims 15 to 27, wherein the second protocol comprises a label distribution protocol, a resource reservation protocol or a combination thereof.
  29. An apparatus (600) , comprising:
    an initiating module (601) for initiating a synchronization process for a first label switched path setup by a first protocol and a second label switched path setup by a second protocol, in response to a synchronization event which indicates potential incoordination between the first label switched path and the second label switched path underlying the first label switched path;
    a detecting module (602) for detecting a status of the second label switched path during the synchronization process, wherein the first label switched path is in an operational status; and
    a determining module (603) for determining whether to terminate the synchronization process based at least in part on the detection of the status of the second label switched path
  30. A computer program product comprising a computer-readable medium bearing computer program codes (503) embodied therein for use with a computer, wherein the computer program codes (503) comprise codes for performing the method according to any one of claims 1-14.
PCT/CN2017/089960 2017-06-26 2017-06-26 Synchronization of label switched paths WO2019000156A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/089960 WO2019000156A1 (en) 2017-06-26 2017-06-26 Synchronization of label switched paths

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/089960 WO2019000156A1 (en) 2017-06-26 2017-06-26 Synchronization of label switched paths

Publications (1)

Publication Number Publication Date
WO2019000156A1 true WO2019000156A1 (en) 2019-01-03

Family

ID=64742687

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/089960 WO2019000156A1 (en) 2017-06-26 2017-06-26 Synchronization of label switched paths

Country Status (1)

Country Link
WO (1) WO2019000156A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110096780A1 (en) * 2009-10-22 2011-04-28 Verizon Patent And Licensing Inc. Label distribution protocol synchronization in multi-protocol label switching environments
CN102664809A (en) * 2012-04-28 2012-09-12 杭州华三通信技术有限公司 Method for implementing Internet gateway protocol (IGP) and label distribution protocol (LDP) synchronization in broadcast network
US20130182609A1 (en) * 2012-01-12 2013-07-18 Cisco Technology, Inc. Technique for improving ldp-igp synchronization
CN103595641A (en) * 2013-11-06 2014-02-19 杭州华三通信技术有限公司 Device and method for synchronizing label distribution protocol and inner gateway protocol

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110096780A1 (en) * 2009-10-22 2011-04-28 Verizon Patent And Licensing Inc. Label distribution protocol synchronization in multi-protocol label switching environments
US20130182609A1 (en) * 2012-01-12 2013-07-18 Cisco Technology, Inc. Technique for improving ldp-igp synchronization
CN102664809A (en) * 2012-04-28 2012-09-12 杭州华三通信技术有限公司 Method for implementing Internet gateway protocol (IGP) and label distribution protocol (LDP) synchronization in broadcast network
CN103595641A (en) * 2013-11-06 2014-02-19 杭州华三通信技术有限公司 Device and method for synchronizing label distribution protocol and inner gateway protocol

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Configuring LDP-IGP Synchronization", JUNIPER NETWORKS - TECHNICAL DOCUMENTATION, 18 August 2014 (2014-08-18), pages 1, XP055558445, Retrieved from the Internet <URL:https://www.juniper.net/documentation/en_US/junose15.1/topics/task/configuration/mpls-ldp-icp-synchronization.html> [retrieved on 20180221] *

Similar Documents

Publication Publication Date Title
US20210390000A1 (en) Loop conflict avoidance in a network computing environment
US10855574B2 (en) Method and network device for computing forwarding path
US10432514B2 (en) Multiprotocol label switching traffic engineering tunnel establishing method and device
US8082340B2 (en) Technique for distinguishing between link and node failure using bidirectional forwarding detection (BFD)
US8279749B2 (en) Failure protection for P2MP tunnel head-end node
US8355315B2 (en) Failure protection for P2MP tunnel tail-end node
US8976645B2 (en) Dynamic protection against failure of a head-end node of one or more TE-LSPS
US7765306B2 (en) Technique for enabling bidirectional forwarding detection between edge devices in a computer network
US8208372B2 (en) Technique for fast activation of a secondary head-end node TE-LSP upon failure of a primary head-end node TE-LSP
US7583590B2 (en) Router and method for protocol process migration
US8902766B2 (en) Method and apparatus to improve LDP convergence using hierarchical label stacking
US9571381B2 (en) System and method for inter-domain RSVP-TE LSP load balancing
US9668160B2 (en) Topology discovery based on SCTP/X2 snooping
US9294986B2 (en) Topology discovery based on explicit signaling
EP3130115B1 (en) Ldp switchover threshold tlv to denote lsp switchover threshold
WO2007140703A1 (en) Method and apparatus of rsvp node interactive
WO2019000156A1 (en) Synchronization of label switched paths
Abukhshim Intra-Area, Inter-Area and Inter-AS Traffic Engineering and Path Selection Evaluation
Metsälä Resilience

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17915763

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17915763

Country of ref document: EP

Kind code of ref document: A1