METHOD AND SYSTEM FOR REPORTING UNAVAILABILITY IN A LABEL-SWITCHED PATH

Abstract

Method for reporting unavailability in a label-switched network (110), wherein the method comprises: Determination by a switch (124) of the label-switched network that a label-switched path (170) is not available for forwarding a packet (102); Generating a notification message (104) to collect unavailability information at each upstream hop of the label-switched path, wherein the notification message: a depth indicator showing the depth (324) of the collected unavailability information (306), and an input label (326) of the packet at the switch, where the depth indicates how many switches contributed to the unavailability information; a label-switching header (304) of the packet, on the basis of which the packet is forwarded on the label-switched path; and containing an inner header (302) of an inner package that is encapsulated within the package; In response to the fact that the switch is an intermediate switch on the label-switched path, the notification message is forwarded to an upstream switch (122) on the label-switched path, allowing the upstream switch to gather further unavailability information in the notification message; and in response to the fact that the switch is an edge switch (112) on the label-switched path, Identifying a service identifier of the label-switching header in the notification message, where the service identifier is associated with a service provided through the label-switching path; and Identification of a service database based on the service identifier.

Description

BACKGROUND area

[0001] The present disclosure relates to communication networks. More specifically, the present disclosure relates to a method and system for efficiently reporting unavailability in a label-switched path.

[0002] CN 101127765 A relates to communication technologies and a method for detecting a label-switched path (LSP), an LSP reachability detection device and a label-switching device.

[0003] US 2017 / 0078150 A1 relates to communication networks and a method for establishing a scalable switching system. BRIEF DESCRIPTION OF THE CHARACTERS Fig. 1A shows an example unavailability notification in a label-switched path in a distributed network environment according to an embodiment of the present application. Fig. 1B shows an exemplary unavailability notification in a label-switched path to a customer network in accordance with one embodiment of the present application. Fig. 2 shows an exemplary communication for reporting unavailability in a label-switched path in a distributed network environment according to an embodiment of the present application. Fig. 3A shows an exemplary notification message with information about the unavailability of a label-switched path according to an embodiment of the present application. Fig. 3B shows an exemplary notification message with accumulated unavailability information of a label-switched path according to an embodiment of the present application. Fig. 4A shows a flowchart illustrating the process of a switch incorporating information about the unavailability of a label-switched path into a notification message, in accordance with an embodiment of the present application. Fig. 4B shows a flowchart illustrating the process of a switch collecting information about the unavailability of a label-switched path in a notification message, in accordance with an embodiment of the present application. Fig. 5 shows a flowchart illustrating the process of a switch providing information about the unavailability of a label-switched path to a customer network, in accordance with an embodiment of the present application. Fig. 6 shows an exemplary switch that supports unavailability reporting in a label-switched path, according to an embodiment of the present application.

[0004] In the figures, like numbers refer to the same elements of the figure. DETAILED DESCRIPTION

[0005] The following description is intended to enable one skilled in the art to make and use the invention and is presented in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications. The present invention is defined in independent claims 1 and 9; exemplary embodiments are subject to the respective dependent claims. Overview

[0006] The internet is the transmission medium for a wide variety of applications running on physical and virtual devices. Such applications have led to an increasing demand for networks distributed across multiple devices. As a result, device manufacturers are striving to develop switches that can support distributed networks. A virtual private network (VPN), such as a virtual private local area network (LAN) service (VPLS) or a Layer 3 VPN (L3VPN), can provide a virtualized network within a customer network spread across multiple remote locations. A VPN enables geographically dispersed locations to share a Layer 2 and / or Layer 3 domain. Consequently, different locations within a customer network can forward traffic within the Layer 2 and / or Layer 3 domain. A VPN can be implemented using a label switching protocol, such asan MPLS protocol (Multiprotocol Label Switching).

[0007] A label-switching protocol can facilitate a routing procedure in a network that directs packets from one switch to the next based on short path labels instead of network addresses, such as Internet Protocol (IP) addresses. In this way, the label-switching protocol can facilitate the efficient forwarding of traffic by avoiding complex lookups in a routing table. If a switch cannot forward a packet due to unavailability (e.g., a link or node failure), the switch can use the Internet Control Message Protocol (ICMP) to send the unavailability information to other switches. ICMP can also be used to exchange operational information, such as the unavailability of a service or the unreachability of a host or switch.However, because a switch in a label-switched path may rely on labels to forward packets, it may not know the packet's customer network. As a result, the switch cannot use ICMP to inform the customer network of its unavailability.

[0008] An embodiment of the present invention provides a switch capable of reporting unavailability in a label-switched network. During operation, the switch may determine that a label-switched path is unavailable for forwarding a packet. The switch may then generate a notification message to collect unavailability information at a corresponding upstream hop of the label-switched path. The notification message includes a depth indicator indicating the depth of the collected unavailability information and an input label of the packet at the switch. If the switch is an intermediate switch on the label-switched path, the switch may forward the notification message to an upstream switch on the label-switched path so that the upstream switch can collect further unavailability information in the notification message.

[0009] In a variation of this embodiment, the switch may release a local label for the packet if the label-switched path for forwarding the packet is unavailable.

[0010] In another variant, the switch can trigger a timer to release the local label upon detection of unavailability and release the local label when the switch detects a release condition based on the timer.

[0011] In a variation of this embodiment, the switch may determine the unavailability of the label-switched path by receiving a second notification message from a downstream switch on the label-switched path. The switch may then obtain information about the unavailability from the second notification message, which may include a second input label of the packet at the downstream switch.

[0012] In another variant, to generate the notification message, the switch may combine local unavailability information, which may include the packet's ingress label at the switch, with the received unavailability information to generate the aggregated unavailability information. Subsequently, to generate the notification message, the system may increment a second depth indicator of the second notification message to generate the depth indicator and include the aggregated unavailability information and the depth indicator in the notification message.

[0013] In a variation of this embodiment, the notification may also include a label-switching header of the packet and an inner header of an inner packet encapsulated within the packet. The packet may be forwarded along the label-switched path based on the label-switching header.

[0014] In another variation, if the switch is an edge switch on the label-switched path, it can identify a source address of the inner header in the notification message. The switch can then send an error message indicating the unavailability to the identified source address.

[0015] In another variant, if the switch is an edge switch on the label-switched path, the switch can identify a service identifier from the Label-Switching header in the notification message. The service identifier can be mapped to a service provided by the label-switched path. The switch can then identify a service database based on the service identifier.

[0016] In a variation of this embodiment, if the switch is an edge switch on the label-switched path, it can generate an alert for a management system that configures the label-switched network. The alert can include the collected unavailability information in the notification message.

[0017] In a variation of this embodiment, the switch can determine a forwarding class for the packet. The forwarding class can specify a class of packets that can be forwarded to a similar edge switch. The switch can include information about the forwarding class in the notification message.

[0018] The embodiments described herein solve the problem of reporting unavailability in a label-switched path to the path's edge switch by forwarding a notification message that can collect (or accumulate) unavailability information at each upstream hop of the path to the edge switch. At each hop of the path, a switch can retrieve (or generate) the message, insert local path information into the message, and forward the updated message to an upstream switch. In this way, when the message reaches the path's edge switch, the edge switch can determine the unavailability information for the entire path and perform remedial actions. Furthermore, the edge switch can send an error message to the customer network based on the collected (or accumulated) unavailability information.

[0019] With existing technologies, when a switch detects that a packet is undeliverable due to a problem (e.g., link and / or node unavailability), the switch can generate an error message. On an IP network, the error message may typically contain an ICMP packet. The error message may contain information about the unavailability (e.g., the reason and type of problem), as well as the IP header and 64 bits of the original packet. The error message can be used by the switch to notify other switches and management systems about the problem. A network operator can obtain information related to the problem from a management system. The switch can determine the source address of the original undelivered packet and set the determined address as the destination address for the error message. This allows the switch to inform the source device about the problem.

[0020] However, if the switch operates on a label-switching protocol such as MPLS, the packet may be a label-switched packet, which includes the original IP packet encapsulated with a label-switching header. The label-switching header may contain a label (e.g., an MPLS transport label). If the packet belongs to a service delivered over the label-switching network between customer sites, the label-switching header may also contain a service identifier that identifies a service entity associated with the service. For example, if the packet belongs to a VPN between customer sites, the label-switching header may also contain a VPN identifier (e.g., an MPLS VPN label). In this way, the label-switching header can be doubly labeled with a transport label that is switched at a corresponding hop and a VPN identifier that can persist between edge switches.Because the switch can forward the packet over a label-switched path by switching the label in the Label-Switching header, it does not need to examine the inner IP header of the original packet to determine the source of the packet.

[0021] If the switch is an intermediate switch on the path, it can also be an intermediate switch in the provider network that connects the customer sites. Because the switch does not process the inner IP packets, it may not be involved in the customer network. Therefore, the switch may not maintain information about a customer virtual routing and forwarding (VRF) or know about a VPN label. Consequently, even if the switch inspects the inner IP header, the switch may not have sufficient information about the original packet. Therefore, the switch may not be able to determine the source of the packet. Under these circumstances, the switch may drop the packet without notifying the source of the original IP packet. To mitigate this problem, the provider network can implement a network of detection mechanisms (e.g.,MPLS Bidirectional Forwarding Detection (BFD) can be deployed between edge switch pairs. However, such deployment is cumbersome and specific to the two switches.

[0022] To solve this problem, when the switch determines that the packet cannot be forwarded over the label-switched path, it can generate a notification message containing the unavailability information associated with the switch and the path. The notification message can also include header information from the original packet. The switch can then send the message to the upstream switch of the path. The upstream switch can receive the message and retrieve the unavailability information. Based on the retrieved unavailability information, the upstream switch can identify the path and determine that the packet cannot be forwarded over the path. The upstream switch can then add the unavailability information associated with the upstream switch to the retrieved unavailability information.

[0023] The upstream switch can then regenerate the notification message with the updated unavailability information and send the newly generated notification message forward along the path. This allows the notification message to collect (or accumulate) information about the unavailability at a corresponding upstream hop. When the path's edge switch (i.e., the switch connected to the customer network) receives the notification message, the edge switch is informed of the information at each hop and can take corrective action. For example, the edge switch can determine if the packet can be forwarded along an alternative path that bypasses the unavailability. If the path is based on MPLS, the edge switch can be a provider edge switch (PE) connected to the customer network through a gateway switch, such as a customer edge switch (CE).

[0024] Because the edge switch enables VPN between customer network sites across the provider network, the edge switch can participate in and maintain the customer VRF. Therefore, the edge switch can know the source IP address of the original packet. Based on the original packet's header information in the notification message, the edge switch can send an error message (e.g., an ICMP error message for an IP-level error) through the gateway switch to the packet's source IP address. Furthermore, the edge switch can generate an alert detailing the unavailability information and forward the alert to a management system that configures and / or manages the provider network. Based on the message, a provider network administrator can perform recovery action (e.g., repair a link and / or node failure).Instead of testing a corresponding switch in the provider network with a tool such as traceroute or ping, the administrator can easily retrieve the unavailability information.

[0025] In some embodiments, the notification may be an ICMP error message, which may be addressed as a unicast message to an upstream switch in the path. The unavailability information may include a forwarding class of the original packet, the depth of the unavailability information, an ingress label (or ingress labels) of the packet, and an identifier of the switch. If the label-switched path is based on MPLS, the forwarding class may be a forwarding equivalence class (FEC), which specifies a class of packets that can be forwarded in the same way. The depth may indicate how many switches contributed to the unavailability information. The depth may be represented by a counter that may be incremented by the respective switch for which the notification message collected the unavailability information.The packet's input label can be the label assigned to the upstream switch. The switch identifier can be an IP address and / or a MAC (Media Access Control) address of the switch.

[0026] If a switch has multiple upstream switches, the switch can forward the notification to a corresponding upstream switch. However, if only one upstream switch is involved in the path, the switch can determine which upstream switch sent the packet and send the notification message to that switch. The switch can determine the upstream switch based on the packet's input port and / or a label specified by its downstream switch in the notification message. The switch can look up the label in the Label Information Base (LIB), determine the corresponding input label, and identify the upstream switch. This allows the switch to send the notification not to all upstream switches, but only to the switch from which it received data for the path.

[0027] If a path becomes unavailable, packets sent over that path can no longer reach their destination. However, if an upstream switch cannot process or recognize the notification due to incompatibility, the unavailability information may not be forwarded to the edge switch. Reasons for the incompatibility can include different software / operating system versions, firmware versions, and vendors. As a result, a switch may continue to receive packets for the path from an upstream switch, even if the switch has sent the notification message to the upstream switch.

[0028] To solve this problem, in addition to sending the notification message, the switch can also release (or revoke) the label associated with the path. For example, if the path is MPLS-based, the switch can use the MPLS label revocation process to release the label. This label can be the egress label for the packet at the switch. By releasing the label, the switch can notify the upstream switch that the ingress label assigned to the packet by the upstream switch can no longer be used and the labels should be reassigned. This allows the upstream switch to recognize that the local label for the packet is no longer usable, and the current path is terminated.

[0029] In some embodiments, in parallel with sending the notification message, the switch can trigger a label release timer and wait for a release condition to be triggered. If the switch continues to receive traffic and the path is unavailable after the timer expires, the switch can detect that the release condition exists and release the label. By waiting until the timer expires before releasing the label, the switch can wait until the unavailability is resolved before abandoning the path. Therefore, even if the switch sends the notification message, it can still maintain the path. If the unavailability is resolved quickly (e.g., in the case of a link flap), the switch does not need to terminate the path; the management system and the edge switch are still notified of the unavailability.

[0030] In this disclosure, the term "switch" is used in a general sense and can refer to any standalone or fabric switch operating at any network layer. The term "switch" should not be construed to limit embodiments of the present invention to Layer 2 networks. Any device that can forward traffic to an external device or another switch can be referred to as a "switch." Any physical or virtual device (e.g., a virtual machine / switch on a computer) that can forward traffic to an end device can be referred to as a "switch." Examples of a "switch" include, but are not limited to, a Layer 2 switch, a Layer 3 router, a routing switch, a component of a Gen Z network, or a fabric switch comprising a plurality of similar or heterogeneous smaller physical and / or virtual switches.

[0031] The term "PE node" is used in a general sense and can refer to any network device participating in a label-switched network. A PE node can refer to any network device capable of establishing and maintaining a label-switched path to another PE node. A PE node can also refer to a network device capable of coupling a provider network and a customer network while simultaneously participating in path / forwarding discovery in both networks.

[0032] The term "message" refers to a group of bits that can be transported together over a network. The term "message" should not be understood to limit embodiments of the present invention to Layer 3 networks. The term "message" may be replaced by other terms that refer to a group of bits, such as "packet," "frame," "cell," "datagram," or "transaction." Network architecture

[0033] Fig. 1A shows an example unavailability notification in a label-switched path in a distributed network environment according to an embodiment of the present application. As shown in Fig. 1, a distributed network environment 100 may include customer networks 140 and 150 belonging to two different entities (e.g., two different institutions). Each of the customer networks 140 and 150 may be distributed across a plurality of locations. The locations of the customer networks 140 and 150 may be interconnected via a provider network 110. The provider network 110 may include a series of switches 112, 114, 122, 124, 126, 132, 134, and 136. The switches 112 and 114 may be edge switches for the network 110. For example, the edge switch 112 may connect the network 110 to location 1 of the customer networks 140 and 150 via the customer gateways 142 and 152. Similarly, edge switch 114 may couple network 110 to site 2 of customer networks 140 and 150 via customer gateways 144 and 154, respectively.

[0034] In some embodiments, network 110 may be a label-switched network. Examples of a label-switched network may include, but are not limited to, Frame Relay, Asynchronous Transfer Mode ATM, and MPLS. If network 110 is based on MPLS, switches 112 and 114 may be PE switches, and the remaining switches of network 110 may be provider switches. A corresponding customer gateway may then be a CE switch. A corresponding customer network may be an Ethernet and / or IP network, and a corresponding switch of a customer network may be an Ethernet switch and / or IP router. In such a scenario, communication between the switches in a customer network may be based on Ethernet and / or IP. A customer network may also be a Gen-Z network, and a corresponding switch of the customer network may then be a Gen-Z component.A Gen-Z network can be a memory-semantic structure that can be used to communicate with devices in a computing environment.

[0035] The customer network 150 enables a virtualized network distributed across sites 1 and 2 of the customer network 150 using a VPN over the network 110 (e.g., based on VPLS or L3VPN). The VPN may enable the geographically distributed sites 1 and 2 of the network 150 to share a Layer 2 and / or Layer 3 domain. As a result, sites 1 and 2 of the customer network 150 may forward traffic within the Layer 2 and / or Layer 3 domain over the network 110. A routing protocol, such as an Open Shortest Path First (OSPF) protocol, may be deployed in the network 110 to establish routers or paths using the addresses (e.g., IP and / or MAC addresses) of the switches in the network 110. Assume that the IP addresses of edge switches 112 and 114 are ABCD and WXYZ, respectively. The routing protocol can then determine routes for the two addresses ABCD and WXYZ. ABCD and W can be used.XYZ represent corresponding FECs.

[0036] Network 110 may also employ a label assignment protocol for assigning labels. Examples of the label assignment protocol may include, but are not limited to, the Label Distribution Protocol (LDP), the Resource Reservation Protocol (RSVP), and a variation thereof. To transfer packets between sites 1 and 2 of customer network 150, the routing protocol may then establish reachability over one or more paths, such as path 170, between switches 112 and 114 using their respective IP addresses. Using the label assignment protocol, a downstream switch may assign a label and make it available to the upstream switch. This process may be repeated for a corresponding route prefix. For an FEC specified by the prefix WXYZ / 32, switch 114 may assign a pop label (e.g., an implicit NULL label) to upstream switches 126 and 136.The pop label can indicate that any label-switched packet for FEC WXYZ / 32 should be dropped at switch 126 or 136 without further label switching.

[0037] Subsequently, switch 126 on path 170 may assign a label 172 to switch 124. Thus, if a packet for FEC WXYZ / 32 is received at switch 124, the output label may be 172. Similarly, switch 124 may assign a label 174 to switch 122, and switch 122 may assign a label 176 to switch 112. In the same way, switches 136, 134, and 132 may assign a label for FEC WXYZ / 32 after assigning the pop label to switch 136 of their respective upstream switch. In this way, there may be two paths (e.g., path 170) from switch 112 for FEC WXYZ / 32 (i.e., to edge switch 114). The VPN service for coupling sites 1 and 2 of the customer network 150 can be provided via these paths between switches 112 and 114.

[0038] To facilitate VPN service, sites 1 and 2 of the customer network 150 can import each other's site information by exchanging routing information (e.g., the customer VRFs). The exchange of routing information can occur during VPN configuration via a Border Gateway Protocol (BGP). When the routing information is exchanged between the sites, a VPN identifier that identifies the VPN can also be exchanged. The VPN identifier can enable a remote edge switch to deliver the packet to the correct customer site.

[0039] These two label-switched paths can be considered logical tunnels. With FEC WXYZ / 32, switch 112 can encapsulate a packet received from switch 152 with a label-switching header (e.g., an MPLS header). Regardless of which path is used, the packet can be forwarded based on the label-switching header without examining the inner IP header of the original packet. To forward the packet on path 170, switch 112 can insert label 176 into the packet's label-switching header as the egress transport label and forward the packet to the next-hop switch 122.

[0040] Here, switch 112 can use path 170 created by the routing protocol to determine the next-hop switch. If the packet belongs to a service provided over network 110, the Label-Switching header can also include a service identifier that identifies a service entity (e.g., a service database) associated with the service. For example, if the packet belongs to a VPN service, the Label-Switching header of the packet can also include an inner header containing the VPN identifier (e.g., an MPLS VPN label that persists within the header). The service database can then be the VRF associated with the VPN identifier. After receiving the packet, switch 122 may consider label 176 as the input label, swap (or switch) label 176 with label 174 as the output label, and forward the packet to next-hop switch 124.

[0041] Switch 124 can swap label 174 with label 172 as the outgoing label and forward the packet to the next switch 126. After receiving the packet, switch 126 can unstamp label 172, removing the label-switching header, and forward the packet to switch 114. The VPN identifier can remain in the inner header and must not be swapped. Consequently, switch 114 can receive the packet with the inner header containing the VPN identifier. Switch 114 can then determine which VPN the packet belongs to and identify the corresponding switch 154 as the next-hop switch, since the packet originated from customer network 150. Switch 114 can then forward the packet to switch 154 based on the customer VRF associated with the VPN identifier.

[0042] Assume an IP packet 180 from site 1 of customer network 150 is forwarded over path 170 of network 110. Upon receiving the packet, switch 112 may encapsulate the packet with a label-switching header to generate packet 102. Therefore, packet 102 may be a label-switched packet comprising an IP packet 180 encapsulated with a label-switching header. Due to a problem 160 (e.g., a connection between switches 124 and 126 and / or an unavailable switch 126), switch 124 may determine that packet 102 cannot be delivered to the next switch 126. Because switch 124 can forward packet 102 over path 170 by switching the label in the Label Switching header, switch 124 cannot examine the inner IP header in packet 102 (i.e., the IP header of packet 180) to determine the source IP address of packet 180.

[0043] Because switch 124 does not process the inner IP packets, switch 124 may not know information about the VRF of customer network 150 or the VPN label. Consequently, even if switch 124 examines the inner IP header of packet 102, switch 124 may not have sufficient information about the IP header of packet 180. Therefore, switch 124 may not be able to determine the source address of packet 180 within packet 102. Under such circumstances, switch 124 may discard packet 102 without notifying the source. To mitigate this problem, network 110 may deploy a mesh-of-detection mechanism (e.g., MPLS BFD) between the edge switch pair. However, such a deployment is cumbersome and specific to switches 122 and 114.

[0044] To solve this problem, if switch 124 determines that packet 102 cannot be forwarded to the next-hop switch 126 of path 170, it may generate a notification message 104 containing the unavailability information associated with switch 124 and path 170. Notification message 104 may also include header information of packet 102. The header information may include the label switching header of packet 102 and the internal headers, such as the IP and / or Ethernet headers, of packet 180. Switch 124 may then send message 104 to upstream switch 122 of path 170. Switch 122 may receive message 104 and retrieve the unavailability information. Based on the retrieved unavailability information, switch 122 can determine that packet 102 cannot be forwarded for FEC WXYZ / 32. Switch 122 can then retrieve the local unavailability information (e.g.,in conjunction with Switch 122) to the retrieved unavailability information.

[0045] Switch 122 may then regenerate notification message 106 with the updated unavailability information and the header of packet 102. Switch 122 may then send message 106 to upstream switch 112 on path 170. Because message 106 includes unavailability information from switches 124 and 122, message 106 has accumulated unavailability information at a corresponding upstream hop (denoted by a thick line). When switch 112 receives message 106, switch 112 may detect the unavailability information associated with each hop and take corrective action. For example, switch 112 may determine whether packet 102 can be forwarded over another path that can bypass problem 160 (e.g., through switches 132, 134, and 136).Using the header information of packet 102 in message 106, switch 112 can determine the source address of packet 180. Switch 112 can then send an error message 108 (denoted by a dashed line), such as an ICMP error message, to the source address of packet 180 to inform the source device of problem 160.

[0046] If switch 122 has multiple upstream switches, switch 122 may forward message 106 to an appropriate upstream switch. However, if only one upstream switch, such as switch 112, participates in path 170, switch 122 may determine that switch 112 sent packet 102 and send message 106 to switch 112. Switch 122 may determine switch 112 as the upstream switch based on the input port of packet 102 and / or the label 174 specified by switch 124 in message 104. Switch 122 may look up label 174 in the local LIB, determine the appropriate label 172, and identify switch 112 as the upstream switch. In this way, switch 122 can send message 106 only to the switch 122 from which it received packet 102, rather than to all upstream switches.

[0047] If path 170 becomes unavailable, packets sent over path 170 can no longer reach switch 114. However, if a switch, such as switch 122, cannot process or recognize message 104 due to incompatibility, the unavailability information may not be forwarded to switch 112. The incompatibility may arise because switches 122 and 124 have different software / operating system versions, firmware versions, and manufacturers. As a result, switch 124 may continue to receive packets for FEC WXYZ / 32 from switch 122 even if switch 124 has sent message 104 to switch 122. To resolve this issue, in addition to sending message 104, switch 124 may also release (or retire) label 172 associated with path 170. For example, if path 170 is MPLS-based, switch 124 may use the MPLS label revocation procedure to release label 172.

[0048] By releasing label 172, switch 124 may notify switch 122 that label 174 corresponding to label 172 is no longer usable and should be reassigned. As a result, switch 122 may detect that label 174 can no longer be used for FEC WXYZ / 32, and path 170 is terminated. In some embodiments, in parallel with sending message 104, switch 124 may initiate a timer to release label 172 and wait for a release condition to be triggered. If switch 124 continues to receive traffic and problem 160 still exists (e.g., path 170 is still unavailable) when the timer expires, switch 124 may determine that the release condition has been triggered and therefore release label 172.By waiting for the timer to expire before releasing label 172, switch 124 can wait until problem 160 is resolved before terminating path 170. Therefore, even if switch 124 sends message 104, switch 124 can still maintain an operational state for path 170. If problem 160 is resolved quickly (e.g., a link flap), switch 124 does not need to terminate path 170, and switch 112 will still be informed of problem 160.

[0049] Fig. 1B shows an example unavailability notification in a label-switched path to a customer network according to an embodiment of the present application. A device 158 may send a packet 180 to the provider network 110 via switch 156 of the customer network 150. Because switch 112 enables the VPN between sites 1 and 2 of the customer network 150 via network 110, switch 112 may participate in and maintain the VRF of the customer network 150. Therefore, switch 112 may know the location of the source IP address, which may be the IP address of device 158, of the packet 180. Upon receiving message 106, switch 112 may retrieve the unavailability information from message 106 and determine that path 170 is unavailable for forwarding packet 180.

[0050] Switch 112 may examine the Label Switching header of packet 102 in message 106 and determine the VPN identifier (or any service identifier) ​​from the inner header of the Label Switching header. In some embodiments, the VPN identifier may be an identifier of the VRF of customer network 150. Switch 112 may also examine the IP header (for an L3VPN) or the Ethernet header (for a VPLS) of packet 180 in message 106. Switch 112 may then determine the source and destination addresses of the examined header. If the examined header is an IP header, the source and destination addresses are corresponding IP addresses. The source IP address of packet 180 may be the IP address of device 158. Based on the VPN identifier, the switch 112 can also identify the customer network 150 and determine the corresponding VRF.Switch 112 can then determine forwarding information for the IP address of device 158 from the VRF.

[0051] Switch 112 may then generate a message 108 indicating that path 170 is unavailable. Switch 112 may specify the IP addresses of device 158 and switch 112 as the source and destination addresses of message 108. Error message 108 may be an ICMP error message reporting the problem that prevented packet 180 from being forwarded. By looking up the IP address of device 158 in the VRF of customer network 150, switch 112 may determine the forwarding information for message 108. Accordingly, switch 112 may send error message 108 through switch 152 to the IP address of device 158. Switch 152 may then forward message 108 through switch 156 to device 158. In this way, message 106 enables switch 112 to become aware of the unavailability information and to notify device 158 based on message 108.

[0052] Additionally, switch 112 may generate an alert with the unavailability information and forward the alert to a management system 190 that configures and / or manages network 110. The alert may be an error message in a format that management system 190 can process. The message may include the unavailability information from message 106. Furthermore, the message may include a reformatted copy of message 106 with updated source and destination IP addresses. Based on the alert, an administrator of network 110 may identify the problem in management system 190 and perform a recovery action (e.g., repair a link and / or node failure). Instead of testing a corresponding switch in network 110 with a tool such as traceroute or ping, the administrator may readily retrieve the unavailability information from management system 190.

[0053] Fig. 2 shows an example communication for reporting unavailability in a label-switched path in a distributed network environment according to an embodiment of the present application. During operation, switch 124 may detect the unavailability of forwarding resources (e.g., a link or a next-hop node) on a forwarding path of a packet (operation 202). Switch 124 may generate a notification message containing unavailability information associated with the detected unavailability (operation 204). Switch 124 may then send the notification message to upstream switch 122 (operation 206). Based on the detection, switch 124 may, in parallel, initiate a timer to release a label for the forwarding path (operation 222).

[0054] If a release condition is detected, switch 124 may release the label (operation 224). The release condition may be triggered if switch 124 receives traffic before the timer expires and the unavailability is not resolved after the timer expires. Switch 122 may accumulate the local unavailability information in the unavailability information of the notification message and regenerate the notification message (operation 208). Switch 122 may then send the newly generated notification to the upstream switch 112 (operation 210). Based on the notification message and / or the release of the label at switch 124, switch 122 may, in parallel, initiate a timer for releasing a label for the forwarding path (operation 226). If a release condition is detected, switch 122 may release the label (operation 228).

[0055] Based on the received notification, switch 112 can identify the path (e.g., the corresponding FEC) and a service identifier of a service offered on the path (e.g., a VPN identifier) ​​(operation 212). Switch 112 can then perform a corrective action that allows switch 112 to forward packets while bypassing the unavailability (operation 214). For example, if an alternative path for the FEC exists, switch 112 can select that path for forwarding. This alternative path can be specified in advance or determined upon detection of the unavailability.

[0056] Switch 112 may also trigger an alarm for a management system and generate an error message indicating the unavailability (operation 216). Switch 112 may then send the error message to switch 156 (operation 218). Switch 156 may be a gateway switch through which the packet was received. Based on the notification message and / or the release of the label at switch 122, switch 112 may, in parallel, initiate a timer for releasing a label for the forwarding path (operation 230). If a release condition is detected, switch 122 may release the label (operation 232).

[0057] Fig. 3A shows an exemplary notification message with information about the unavailability of a label-switched path according to an embodiment of the present application. The notification message 104 may include an outer IP header 302, a label-switching header 304, unavailability information 306, and original label-switched packet information 308. The notification message 104 may be an ICMP error message, each of which may be a unicast message from switch 124 to switch 122. Thus, the source IP address 342 and the destination IP address 344 of the outer IP header 302 may be the IP addresses of switches 124 and 122, respectively. The label-switching header 304 can then be an ICMP header and can contain a type 312, a code 314, and a checksum 316. The value for type 312 can indicate that the label-switched path (e.g., path 170) is unreachable. The value for code 314 can indicate that there is no access for the label (e.g.,Label 172) there is no label-switched path. Checksum 316 can be the checksum of packet 104. The fields in Label-Switching header 304 can be the first four bytes of an ICMP message.

[0058] The unavailability information 306 may include a forwarding class 322 of the path 170, the depth 324 of the unavailability information 306, the ingress label 326 of the packet 102 at the switch 124, and an identifier 328 of the switch 124. If the label-switched path is based on MPLS, the forwarding class 322 may be an FEC corresponding to the switch 114. In this example, the FEC may be WXYZ / 32, which indicates a class of packets that can be forwarded to the switch 114. Thus, if another path to switch 114 exists, packets associated with the FEC WXYZ / 32 may be forwarded over that path. The depth 324 may indicate how many switches contributed to the unavailability information 306. Since the message 104 is generated by the switch 124, the depth 324 can have the value 1. The depth 324 can be indicated by an indicator, e.g.a counter represented by a positive integer, which can be incremented by the respective switch for which message 104 has collected unavailability information.

[0059] Since packet 102 was received by switch 122, input label 326 of packet 102 may be label 174 assigned to upstream switch 122. In other words, label 326 may be the label that switch 124 failed to forward. Switch 124 identifier 328 may be an IP address and / or a MAC address of switch 124. Unavailability information 306 may be followed by label-switched packet information 308, which may include header information (e.g., header fields) of the original label-switched packet 102 that failed to forward. The label-switched packet information 308 may include the label switching header 332 of packet 102 (e.g., a doubly tagged MPLS header) and the original headers 334 (e.g., the Ethernet and / or IP headers) of packet 180, if available.The label switching header 332 may be followed by the IP header of packet 180 for an L3VPN and the Ethernet header of packet 180 for VPLS.

[0060] When message 104 reaches switch 122, message 104 may collect the unavailability information from switch 122. Switch 122 generates message 106 based on the accumulated unavailability information. Fig. 3B shows an exemplary notification message with accumulated unavailability information of a label-switched path according to an embodiment of the present application. The notification message 104 may include an outer IP header 352, a label-switching header 354, unavailability information 356, and original label-switched packet information 308. Since the message 106 is sent from switch 122 to switch 112, the source IP address 346 and the destination IP address 348 of the outer IP header 352 may be the IP addresses of switches 122 and 112, respectively. The label-switching header 354 may include type 312, code 314, and a checksum 318. Type 312 and code 314 may remain unchanged from the message 104. The checksum 318 may be the checksum of packet 106. The fields in the label switching header 354 may be the first four bytes of an ICMP message.

[0061] The unavailability information 356 may include the forwarding class 322 of path 170 (e.g., FEC WXYZ / 32), since the forwarding class 322 remains unchanged on path 170. The unavailability information 356 may also include the depth 364 of the unavailability information 356 and accumulate an input label 366 of the packet 102 at switch 122 and an identifier 368 of the switch 122. The unavailability information 356 may retain the label 326 and the identifier 328 of the switch 124 from the message 104. Since the unavailability information 356 may include information collected at switches 122 and 124, the depth 364 may have a value of 2. Since switch 122 receives packet 102 from switch 112, the input label 366 of packet 102 at switch 122 may be label 172. The identifier 368 of switch 122 may be an IP address and / or a MAC address of switch 122.The unavailability information 356 may be followed by information 308 about the label-switched packet, which may remain unchanged from message 104. In this way, the unavailability information 356 may accumulate the information associated with the switch 122 in the unavailability information 306 of message 104. Operation

[0062] Fig. 4A shows a flowchart illustrating the process of a switch incorporating information about the unavailability of a label-switched path into a notification message, in accordance with an embodiment of the present application. During operation, the switch may determine the unavailability of a label-switched path for forwarding a packet (operation 402). For example, the switch may determine that the forwarding resources (e.g., a next-hop switch) for an ingress label of the packet are unavailable. The switch may then generate an unavailability notification (operation 404) and initialize an accumulation depth for the message (operation 406). The switch may then include the forwarding class information, the depth, the ingress label, and the local IP address in the notification message (operation 408).The switch can forward the notification message to an upstream switch in the path (operation 410).

[0063] After detecting the unavailability (operation 402), the switch can, in parallel, start an unavailability timer (operation 412) (indicated by dashed arrows). The switch can then determine whether a release condition has been triggered (operation 414). The release condition can be triggered if the switch receives traffic before the timer expires and the unavailability is not resolved by the timer expires. If packets continue to arrive after the notification message is sent, the switch can determine that an upstream switch is unable to process the notification message. Therefore, if the timer expires and the unavailability is not resolved, the switch can determine that the unavailability is due to a long-term problem and the path is no longer available.Therefore, when the release condition is triggered, the switch can release the label associated with the path (operation 416).

[0064] Fig. Figure 4B shows a flowchart illustrating the process of a switch collecting information about the unavailability of a label-switched path in a notification message, in accordance with an embodiment of the present application. During operation, the switch may receive a notification message from a downstream switch (operation 452) and determine the unavailability of a label-switched path for forwarding a packet based on the notification message (operation 454). The switch may then obtain the unavailability information from the notification message (operation 462) and increment the accumulation depth indicated in the unavailability information (operation 464).The switch can then append the decremented depth, ingress label, and local IP address to the forwarding class information of the received notification message to generate the updated unavailability information (operation 466).

[0065] The switch can then append the remainder of the unavailability information to the updated unavailability information (operation 468). The switch can then generate an updated notification message with the updated unavailability information (operation 470). The switch can then forward the updated notification message to the upstream switch of the path (operation 472). After determining unavailability (operation 454), the switch can, in parallel, initiate an unavailability timer (operation 456) (indicated by dashed arrows). The switch can then determine whether a release condition has been triggered (operation 458). If the release condition has been triggered, the switch can release the label associated with the path (operation 460).

[0066] Fig. Figure 5 shows a flowchart illustrating the process of a switch providing information about the unavailability of a label-switched path to a customer network, in accordance with an embodiment of the present application. During operation, the switch may receive a notification message from a downstream switch (operation 502) and determine the unavailability of a label-switched path for forwarding a packet based on the notification message (operation 504). The switch may generate an alert for a management system (operation 512) and determine whether an alternative path exists for forwarding the path (operation 514). If an alternative path exists, the switch may initiate label switching over the alternative path (operation 516).

[0067] If the alternate path does not exist (operation 514) or label switching has been initiated (operation 516), the switch may determine whether to send a notification to the customer network (operation 518). In some embodiments, the switch may maintain a customer notification policy that specifies whether to send the notification when an alternate path exists or when recovery is detected within a predetermined time. For example, if an alternate path exists, packet forwarding from the customer network cannot be affected. Therefore, the switch may not send a notification if an alternate path exists. On the other hand, the customer notification policy may also stipulate that any problem must be reported to the customer network regardless of the existence of an alternate path.

[0068] Accordingly, the switch can determine whether to send the notification based on the customer notification policy. The customer notification message indicates whether the source of the packet should be notified of the unavailability. The switch can then generate an error message for the source switch in the customer network indicating the unavailability (operation 520). The switch can then forward the error message to the edge / gateway switch of the customer network (operation 522).

[0069] After determining the unavailability (operation 504), the switch can, in parallel, initiate an unavailability timer (operation 506) (indicated by dashed arrows). The switch can then determine whether a release condition has been triggered (operation 558). If the release condition has been triggered, the switch can release the label associated with the path (operation 510). This allows the switch to provide information about the unavailability of a label-switched path to the source of the packet that could not be forwarded. Example switch system

[0070] Fig. 6 shows an exemplary switch that supports unavailability reporting in a label-switched path according to an embodiment of the present application. In this example, a switch 600 includes a number of communication ports 602, a packet processor 610, a logic block 630, and a memory device 650. Switch 600 may also include switch hardware 660 (e.g., processing hardware of switch 600, such as its application-specific integrated circuit (ASIC) chips) that contains information based on which switch 600 processes packets (e.g., determines output ports for packets). Packet processor 610 extracts and processes header information from the received packets. Packet processor 610 may identify a switch identifier (e.g., a Media Access Control (MAC) address and / or an IP address) associated with switch 600 in the header of a packet.

[0071] The communication ports 602 may include communication channels between the switches for communication with other switches and / or user devices. The communication channels may be implemented over a standard communication port and may be based on any open or proprietary format. The communication ports 602 may include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header. The communication ports 602 may also include one or more IP ports capable of receiving IP packets. An IP port may receive an IP packet and may be configured with an IP address. The packet processor 610 may process Ethernet frames and / or IP packets.

[0072] In some embodiments, switch 600 may be a label-switching switch that may implement a label-switching protocol such as MPLS. Switch 600 may then include a label-switching logic block 640 that may facilitate the control and / or data plane of the label-switching protocol within switch 600. Switch 600 may maintain a database 652 (e.g., in storage device 650). Database 652 may be a relational database and may run on one or more DBMS instances. Switch 600 may maintain a LIB associated with the label-switching protocol, a Routing Information Base (RIB), and a Forwarding Information Base (FIB) within database 652.

[0073] The multicast notification logic block 630 may include a detection logic block 632, a notification logic block 634, a collection logic block 636, and a customer logic block 638. During operation, the detection logic block 632 may detect a problem with a packet, such as the unavailability of forwarding resources. The detection logic block 632 may determine that a packet cannot be forwarded. For example, the detection logic block 632 may determine, based on the packet's input label, that the next-hop switch of switch 600 is unreachable. If the problem is detected, the notification logic block 634 may generate a notification message, as described in connection with Fig. 3A. The notification message may be directed to an upstream switch of switch 600 on a label-switched path of the packet and may include information about the unavailability. Packet processor 610 may then forward the notification message to the upstream switch. In some embodiments, the notification message may be an ICMP error message.

[0074] Switch 600 may receive a notification from a downstream switch via one of communication ports 602. Logic block 636 may allow the notification message to collect local unavailability information. To this end, logic block 636 may accumulate the unavailability information in the received notification message and regenerate the notification message accordingly, as described in connection with Fig.3B. Switch 600 may be an edge switch (e.g., an MPLS PE switch) that can manage the VRF of a customer network (e.g., in the RIB). When switch 600 receives a notification message from a downstream switch, customer logic block 638 may identify the VRF (e.g., based on a service identifier) ​​and examine the packet information in the notification message. Accordingly, customer logic block 638 may send an error message to the source address of the packet via one of communication ports 602.

[0075] The data structures and code described in this Detailed Description are typically stored on a computer-readable storage medium, which can be any device or medium capable of storing code and / or data for use by a computer system. Computer-readable storage medium includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as floppy disks, magnetic tapes, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed.

[0076] The methods and processes described in the "Detailed Description" section may be embodied as code and / or data that may be stored in a computer-readable storage medium, as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and code stored in the computer-readable storage medium.

[0077] The methods and processes described herein may be performed by and / or embodied in hardware modules or devices. These modules or devices may include, but are not limited to, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a dedicated or shared processor that executes a specific software module or piece of code at a specific time, and / or other programmable logic devices known now or later developed. When activated, the hardware modules or devices execute the methods and processes embodied within them.

[0078] The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or limiting of this disclosure. Accordingly, many modifications and variations will be apparent to those skilled in the art. The scope of the present invention is defined by the appended claims.

Claims

[1] A method for reporting unavailability in a label-switched network (110), the method comprising: Determining by a switch (124) of the label-switched network that a label-switched path (170) is unavailable for forwarding a packet (102); Generating a notification message (104) for collecting unavailability information at a respective upstream hop of the label-switched path, the notification message: a depth indicator indicating the depth (324) of the collected unavailability information (306), and an input label (326) of the packet at the switch, the depth indicating how many switches contributed to the unavailability information; a label-switching header (304) of the packet, on the basis of which the packet is forwarded on the label-switched path; and an inner header (302) of an inner packet encapsulated in the packet; in response to the switch being an intermediate switch on the label-switched path, forwarding the notification message to an upstream switch (122) on the label-switched path, whereby the upstream switch can collect further unavailability information in the notification message; and in response to the switch being an edge switch (112) on the label-switched path, Identifying a service identifier of the label-switching header in the notification message, wherein the service identifier is associated with a service provided by the label-switching path; and Identification of a service database based on the service identifier. [2] The method of claim 1, further comprising, in response to determining that the label-switched path is unavailable for forwarding the packet, releasing a local label (172) for the packet. [3] The method of claim 2, wherein releasing the local label comprises: triggering a timer in response to the determination of unavailability; and in response to the detection of a release condition based on the timer, release the local label. [4] The method of claim 1, further comprising: Determining the unavailability of the label-switched path by receiving a second notification message (106) from a downstream switch on the label-switched path; and Obtaining unavailability information (356) including a second input label (366) of the packet at the downstream switch from the second notification message. [5] The method of claim 4, wherein generating the notification message further comprises: Incorporating local unavailability information, including the packet's input label at the switch, with the received unavailability information to generate the aggregated unavailability information; Incrementing a second depth indicator (364) of the second notification message to generate the depth indicator; and Include the collected unavailability information and the depth indicator in the notification. [6] The method of claim 1, further comprising: in response to the switch being an edge switch on the label-switched path, identifying a source address of the inner header in the notification message; and Sending an error message (108) about the unavailability to the identification source address. [7] The method of claim 1, further comprising, in response to the switch being an edge switch on the label-switched path, generating an alert for a management system (190) configuring the label-switched network, the alert including the collected unavailability information in the notification message. [8] The method of claim 1, further comprising: Determining a forwarding class (322) for the packet, the forwarding class indicating a class of packets that can be forwarded to a same edge switch; and Include information about the forwarding class in the notification message. [9] A computer system (600) in a label-switched network (110), comprising: a processor (610); a non-transitory, computer-readable storage medium (650) storing instructions that, when executed by the processor, cause the processor to perform a method for reporting unavailability in the label-switched network, the method comprising: determining that a label-switched path (170) is unavailable for forwarding a packet (102); Generating a notification message (104) for collecting unavailability information at a respective upstream hop of the label-switched path, the notification message: a depth indicator indicating the depth (324) of the collected unavailability information (306), and an input label (326) of the packet at the computer system, the depth indicating how many switches contributed to the unavailability information, a label-switching header (304) of the packet, on the basis of which the packet is forwarded on the label-switched path; and an inner header (302) of an inner packet encapsulated in the packet; in response to the computer system being an intermediate node on the label-switched path, forwarding the notification message to an upstream node (122) on the label-switched path, whereby the upstream node can collect further unavailability information in the notification message; and in response to the computer system being an edge switch (112) on the label-switched path, Identifying a service identifier of the label-switched header in the notification message, wherein the service identifier is associated with a service provided by the label-switched path; and Identification of a service database based on the service identifier. [10] The computer system of claim 9, wherein the method further comprises, in response to determining that the label-switched path is unavailable for forwarding the packet, releasing a local label (172) for the packet. [11] The computer system of claim 10, wherein releasing the local label comprises: triggering a timer in response to the determination of unavailability; and in response to the detection of a release condition based on the timer, release the local label. [12] The computer system of claim 9, wherein the method further comprises: Determining the unavailability of the label-switched path by receiving a second notification message (106) from a downstream node on the label-switched path; and Obtaining unavailability information (356) comprising a second input label (366) of the packet at the downstream node from the second notification message. [13] The computer system of claim 12, wherein generating the notification message further comprises: Incorporating local unavailability information containing the input label of the packet in the computer system into the received unavailability information to generate the collected unavailability information; Incrementing a second depth indicator of the second notification message to generate the depth indicator; and Include the collected unavailability information and the depth indicator in the notification message. [14] The computer system of claim 9, wherein the method further comprises: in response to the computer system being an edge node on the label-switched path, identifying a source address of the inner header in the notification message; and Sending an error message (108) about the unavailability to the identification source address. [15] The computer system of claim 9, wherein the method further comprises, in response to the computer system being an edge node on the label-switched path, generating an alert for a management system (190) configuring the label-switched network, the alert including the collected unavailability information in the notification message. [16] The computer system of claim 9, wherein the method further comprises: Determining a forwarding class (322) for the packet, the forwarding class indicating a class of packets that can be forwarded to a same edge node; and Include information about the forwarding class in the notification message.

Images