Method and apparatus for segment routing label switched path

Abstract

Segment tracking routing for segment routing traffic engineering is described. For example, an ingress device includes one or more processors, operatively coupled to a memory, the one or more processors configured to: in response to a request to verify connectivity of a segment routed LSP, configure a FEC stack specifying a stack of segment routed labels of the segment routed LSP; for each of one or more devices identified from the FEC stack: generate a respective MPLS connectivity request packet for a respective device identified from an outermost FEC of the FEC stack; send the MPLS connectivity request packet to the respective device; receive an MPLS connectivity response packet verifying connectivity of the respective device; and in response, update the FEC stack by removing the outermost FEC of the FEC stack that identifies the respective device.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 202011064035.3, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0002] The present invention relates to computer networks, and more specifically, to a software utility for determining the status of computer network connections. BACKGROUND

[0003] A computer network is a collection of interconnected computing devices that can exchange data and share resources. In a packet-based network, such as the Internet, computing devices transmit data by dividing the data into small pieces called packets, which are individually routed across the network from a source device to a destination device. The destination device extracts the data from the packets and assembles the data into its original form.

[0004] Certain devices (i.e., nodes), such as routers, maintain routing information that describes routes through the network. A “route” can generally be defined as a path between two locations on the network. Upon receiving an incoming packet, a router examines information in the packet to identify the destination of the packet. Based on the destination, the router forwards the packet according to the routing information.

[0005] Packet-based networks increasingly use label switching protocols for traffic engineering and other purposes. Multiprotocol label switching (MPLS) is a mechanism for engineering traffic patterns within an Internet Protocol (IP) network according to routing information maintained by routers in the network. By utilizing the MPLS protocol, a label switching router (LSR) can use a label prepended to traffic to forward the traffic along a particular path (i.e., a label switched path (LSP)) through the network to a destination device. The LSP defines a different path through the network to carry MPLS packets from a source device to a destination device. Routers can employ segment routing techniques, such as by using the Source Packet Routing (SPRING) paradigm, to advertise network segments between nodes using an Interior Gateway Protocol (IGP) and establish single-hop or multi-hop tunnels within an IGP domain. To perform segment routing, an ingress router adds one or more labels in a label stack (e.g., a segment list) to a packet, and intermediate routers along the path remove labels from the label stack applied to the packet as the packet is forwarded through the network.

[0006] Various software utilities exist for identifying faulty connections between two nodes of a network and for exploring network topology. One such utility, referred to as an LSP ping mechanism, is used to detect data plane failures in MPLS LSPs. The LSP ping mechanism can include two modes: a ping mode for testing LSP end-to-end connectivity and a traceroute mode for performing failure isolation. In the ping mode, an ingress router of an LSP tests connectivity with a remote device by sending MPLS echo request packets to detect the connection status of an egress router of the LSP. If an MPLS echo reply packet is not received within a defined time period, the connection along the LSP to the egress router is considered broken. In the traceroute mode, the ingress router identifies the location of a failure in the LSP by tracing the path of the MPLS echo request packet from the ingress router to the egress router. For example, the MPLS echo request packet is typically sent to the control plane of each transit router that is a transit router for the LSP, which performs various checks for the transit router. Each of the transit routers can return an MPLS echo reply indicating a functioning connection of the LSP. If an MPLS echo reply packet is not received within a defined time period (e.g., time-to-live (TTL) value), the connection along the LSP to the egress router is assumed to be broken. SUMMARY

[0007] Generally, this disclosure describes techniques for an ingress device (e.g., a router) that is configured to selectively ping certain devices along a segment routed label switched path (LSP) to detect failures (e.g., data plane failures) in the segment routed LSP. For example, a network can be configured to establish a segment routed LSP from an ingress device to an egress device through the network. In segment routing, when an ingress router receives a packet, the ingress router typically assigns the packet to a forwarding equivalence class (FEC), encapsulates the packet using a segment routing label stack associated with the FEC, and forwards the packet over the segment routed LSP according to the segment routing label stack. The LSP ping mechanism can then be used within the network to test whether packets belonging to a particular FEC are indeed delivered to an egress router of the LSP associated with the FEC. According to the techniques described herein, the ingress router operates according to an enhanced LS ping mechanism that selectively pings certain devices along the segment LSP such that the ingress router only receives a response from the devices identified by the FEC stack and not from every routing device located along the path taken by the segment routed LSP.

[0008] In one example, an ingress router or other device is configured to operate according to the techniques described herein to iteratively send MPLS echo request packets to each router identified from a forwarding equivalence class (FEC) stack configured from a segment routing label stack without having to send MPLS echo request packets to every next hop router along a path, which can include intermediate routers or other network devices not participating in a particular segment routing LSP (i.e., network devices not identified in the segment routing label stack). The FEC stack in segment routing identifies one or more devices participating as routers (e.g., segment endpoints), and as further described herein, the FEC stack can be used to identify particular routers for verification along a path traversed by a segment routing LSP.

[0009] An ingress router selectively verifies particular segment routers by generating a multiprotocol label switching (MPLS) connectivity request packet (e.g., an MPLS echo request packet, also referred to as an MPLS ping) including a FEC stack and a label stack to direct the MPLS echo request packet to a selected device identified from an outermost FEC of the FEC stack of a segment routing LSP. The ingress router sends the MPLS echo request packet to the corresponding device and waits for an MPLS connectivity response packet (e.g., an MPLS echo reply packet) from the respective device verifying connectivity of the respective device of the segment routing LSP. In response to receiving the MPLS echo reply packet, the ingress router updates the FEC stack by removing the outermost FEC from the FEC stack and determines whether the updated FEC stack is empty. If the FEC stack is not empty, the ingress device sends a subsequent MPLS echo request packet including the updated FEC stack and a label stack to direct the MPLS echo request packet to a respective device identified from an outermost FEC of the updated FEC stack. The ingress router repeats this process for each of the devices identified from the FEC stack until the FEC stack is empty. In this way, an ingress device (or other device) can selectively verify devices operating as segment routers along a particular segment routing LSP without having to verify every next hop router along a path traversed by the segment routing LSP.

[0010] The techniques described in this disclosure can provide one or more technical advantages that enable practical applications. For example, by selectively verifying certain devices identified in a segment routing label stack, an ingress router receives responses only from devices identified in the segment routing label stack, which reduces the load on the network, especially in large scale networks.

[0011] In one example, the present disclosure is directed to a method comprising: in response to a request to verify connectivity of a segment routing label switched path (LSP), configuring, by an ingress device of the segment routing LSP, a forwarding equivalence class (FEC) stack that specifies a stack of segment routing labels of the segment routing LSP, wherein the FEC stack includes information that identifies one or more devices that operate as segment endpoints along the segment routing LSP to be verified; and for each device of the one or more devices identified from the FEC stack: generating, by the ingress device, a respective multi-protocol label switching (MPLS) connectivity request packet for a respective device of the one or more devices, wherein the respective device is identified from an outermost FEC of the FEC stack; sending, by the ingress device, the MPLS connectivity request packet to the respective device; receiving, by the ingress device, an MPLS connectivity response packet from the respective device, the MPLS connectivity response packet verifying connectivity of the respective device of the segment routing LSP; and in response to receiving the MPLS connectivity response packet, updating, by the ingress device, the FEC stack by removing the outermost FEC of the FEC stack that identifies the respective device.

[0012] In another example, the present disclosure is directed to an ingress device of a segment routing label switched path (LSP) comprising: one or more processors operably coupled to a memory, wherein the one or more processors are configured to: in response to a request to verify connectivity of the segment routing LSP, configure a forwarding equivalence class (FEC) stack that specifies a stack of segment routing labels of the segment routing LSP, wherein the FEC stack includes information that identifies one or more devices that operate as segment endpoints along the segment routing LSP; and for each device of the one or more devices identified from the FEC stack: generate a respective multi-protocol label switching (MPLS) connectivity request packet for a respective device of the one or more devices, wherein the respective device is identified from an outermost FEC of the FEC stack; send the MPLS connectivity request packet to the respective device; receive an MPLS connectivity response packet from the respective device, the MPLS connectivity response packet verifying connectivity of the respective device of the segment routing LSP; and in response to receiving the MPLS connectivity response packet, update the FEC stack by removing the outermost FEC of the FEC stack that identifies the respective device.

[0013] In another example, the disclosure is directed to a non-transitory computer- readable medium comprising instructions for causing one or more programmable processors of an ingress device to: in response to a request to verify connectivity of a segment routing label switched path (LSP), configure a forwarding equivalence class (FEC) stack that specifies a stack of segment routing labels of the segment routing LSP, wherein the FEC stack includes information that identifies one or more devices that operate as segment endpoints along the segment routing LSP; and for each device of the one or more devices identified from the FEC stack: generate a respective multi-protocol label switching (MPLS) connectivity request packet for a respective device of the one or more devices, wherein the respective device is identified from an outermost FEC of the FEC stack; send the MPLS connectivity request packet to the respective device; receive an MPLS connectivity response packet from the respective device, the MPLS connectivity response packet verifying connectivity of the respective device of the segment routing LSP; and in response to receiving the MPLS connectivity response packet, update the FEC stack by removing the outermost FEC of the FEC stack that identifies the respective device.

[0014] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 is a block diagram illustrating an example network in which an ingress device selectively pings certain devices along a segment routing label switched path to detect a fault in the segment routing label switched path, in accordance with the techniques described in this disclosure.

[0016] Figure 2 is a block diagram illustrating another example network in which an ingress device selectively pings certain devices along a segment routing label switched path to detect a fault in the segment routing label switched path, in accordance with the techniques described in this disclosure.

[0017] Figure 3 is a block diagram illustrating another example network in which an ingress device selectively pings certain devices along a segment routing label switched path to detect a fault in the segment routing label switched path, in accordance with the techniques described in this disclosure.

[0018] Figure 4 is a block diagram illustrating an example of a network device (such as an ingress router) in accordance with the techniques described herein. Figure 1

[0019] Figure 5 is a flow diagram illustrating an example operation of a network in accordance with the techniques described in this disclosure. ​DETAILED DESCRIPTION

[0020] Figure 1 is a block diagram illustrating an example network in which ingress devices selectively inspect certain devices along a segment routed label switched path (LSP) to detect a failure (e.g., a data plane failure) in the segment routed LSP, in accordance with the techniques described in this disclosure.

[0021] In Figure 1 In the illustrated example, network 2 includes a set of network devices, e.g., routers 12A-12G (collectively referred to as "routers 12"), under common administrative control and sharing a common routing protocol, such as an Interior Gateway Protocol (IGP) area or domain. Example IGPs include Intermediate System-Intermediate System (IS-IS) and Open Shortest Path First (OSPF). In Figure 1 In the illustrated example of, router 12A is an ingress router for the IGP domain, and router 12G is an egress router for the IGP domain. Routers 12B-12F operate as transit routers to forward traffic within the IGP domain. While described with respect to routers, the techniques can be implemented by any other type of network device having routing functionality, and need not be dedicated routing devices.

[0022] Sources of network traffic received by ingress router 12A can include one or more devices (not shown) and / or any public or private network or the Internet that provides traffic to ingress router 12A in network 2. Further, in this example, router 12G can serve as an egress router for the IGP domain. Destinations of network traffic forwarded over the LSP can include one or more destination devices and / or a network that can include a local area network (LAN) or a wide area network (WAN) containing multiple devices. For example, the destination devices can include personal computers, laptop computers, workstations, personal digital assistants (PDAs), wireless devices, network-enabled devices, file servers, print servers, or other devices that access the source via network 2.

[0023] In Figure 1In the example of network 2, in which the path that a packet should take is determined without relying on intermediate devices in the network, routers 12 can use a segment routing technique (such as the Source Packet Routing In Networking (SPRING) paradigm) to enable ingress routers to direct packets through a specific set of nodes and links in the network. Routers 12 can use the segment routing technique to advertise segments between routers and establish single-hop or multi-hop tunnels in network 2. A first type of segment is an "adjacency segment," which represents a strict forwarding, typically single-hop tunnel, that carries packets over a specific link between a router and a particular node, regardless of the link cost. A second example type of segment is a "prefix segment," which generally represents a multi-hop tunnel that uses the lowest cost path link between a router and a particular address prefix.

[0024] In segment routing, the "path" information of a segment is propagated between routers within an IGP domain as part of the IGP link state information for the domain. For example, the path information of a segment is propagated or advertised between routers 12 using IGP (or to controller devices such as a Software Defined Networking (SDN) controller using Border Gateway Protocol Link State (BGP-LS)). Ingress router 12A can prepend one or more Segment Identifiers (SIDs) (such as an adjacency SID that identifies an adjacency segment and / or a node SID that identifies a particular prefix) to a packet to direct the packet through an ordered list of instructions (i.e., segments). In other words, ingress router 12A can direct a packet through a desired set of nodes and links by prepending the packet with an appropriate combination (stack) of SIDs. Segment routing allows routers to force flows through any topological path and service chain while maintaining per-flow state only at the ingress node to each domain.

[0025] Segment routing can be applied directly to a Multiprotocol Label Switching (MPLS) architecture without changing the forwarding plane. A network administrator or centralized controller only needs to assign SIDs to particular routers, and the segment routing control plane architecture automatically establishes the required MPLS forwarding constructs from a router to any other router. In some examples, a SID is encoded as an MPLS label, and an ordered list of SIDs is encoded as a stack of labels. A stack of SIDs is also referred to herein as a "segment routing label stack." The SID of a segment to be processed is at the top of the label stack, and the relevant label pops off the label stack as the packet is forwarded through the network when the segment is complete (i.e., when the packet reaches the endpoint of the segment).

[0026] Segment Routing Architecture," Internet Engineering Task Force (IETF), Request for Comments (RFC 8402), July 2018, and Segment Routing Use Cases," Internet-Draft draft-filsfils-rtgwg-segment-routing-use-cases-01, July 2013, the entire contents of each of which are incorporated herein by reference. Further details on SPRING can be found in (1) "Segment Routing Architecture," IETF draft: draft-filsfils-spring-segment-routing-04, July 3, 2014; (2) "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements," RFC 7855, May 2016, by S. Previdi et al.; and (3) "Segment Routing with MPLS data plane," IETF draft: draft-filsfils-spring-segment-routing-mpls-03, August 1, 2014, each of which is incorporated herein by reference in its entirety.

[0027] Further description of establishing and using prefix segments in network 2 is provided below as illustrative examples. Each of routers 12 can be associated with an address prefix. For example, an administrator or controller can assign a prefix to one or more routers 12. The prefix can be an address or a block of addresses. The prefix corresponding to a router can include an Internet Protocol (IP) address (e.g., IPv4 or IPv6), a block of IP addresses, or another type of data that identifies the router. Further, one or more of routers 12 can be configured with a Segment Identifier (SID) (i.e., a label) associated with the prefix. In the example of FIG. 1, router 12A is configured with a SID of 1001, router 12B is configured with a SID of 1002, router 12C is configured with a SID of 1003, and so on. Figure 1 In the example of FIG. 1, router 12A is configured with a SID of 1001, router 12B is configured with a SID of 1002, router 12C is configured with a SID of 1003, and so on.

[0028] Routers in network 2 can advertise the router prefix and SIDs to neighboring routers within the same domain of network 2. For example, router 12 can distribute the prefix and SIDs within the domain using an IGP. When a router receives an advertisement, the router determines from the router's link state database (LSDB) or traffic engineering database (TED) whether the prefix specified in the advertisement is already associated with the SID specified in the advertisement. If this is the case and if the advertisement presents a new best path, the router can update a routing table in response to the advertisement such that the routing table indicates the next hop in the route for the prefix. If the advertisement presents an equal cost to an existing route, the router can add an equal cost multi-path (ECMP) next hop to the existing route.

[0029] If the advertisement specifies a prefix and SID that are not in the LSDB or TED of the receiving router, the router can compute a route to the prefix specified in the advertisement. In some examples, the router can compute the route according to a shortest path algorithm or a strict shortest path algorithm. Further, in some examples, the advertisement can specify a type of algorithm to use to compute the route to the prefix specified in the advertisement. Further, the router can associate the SID specified by the advertisement with the computed route to the prefix specified by the advertisement. In other words, the router can generate data that associates the SID with the route. The router can then install the route as an active route. Installing the route as an active route can include generating forwarding information that a forwarding component of the router can use to forward a packet to a next hop of the route that is associated with the SID attached to the packet. For example, installing the route as an active route can include generating information in a forwarding table that maps the SID to an interface card that is attached to a link of the next hop of the route that is associated with the SID.

[0030] When router 12 receives a packet, router 12 can determine whether a stack of labels is attached to the packet. The stack of labels includes an ordered sequence of labels. If the stack of labels still includes one or more labels, the router can determine a next hop or route associated with an active label of the stack. The active label can be the label that is "on top" of the stack. For example, the active label can be the first label to appear in the ordered sequence of labels attached to the packet. If the next hop of the route associated with the active label advertises an active SID, the router (referred to as a penultimate hop popping (PHP) router) can remove the active label from the stack of labels attached to the packet, potentially leaving one or more labels still attached to the packet. In other words, the router can "pop" the active label from the stack. The router can then forward the packet to the next hop on the route associated with the active label along with the remaining labels of the stack. This system can allow a source node (such as ingress router 12A) to control the path taken by a packet through network 2.

[0031] If there is no stack of labels to attach to the packet when the router receives it, or if there are no remaining labels to attach to the packet after the router removes the active label, the router will forward the packet to another node in network 2 without further use of fragmentation routing. For example, the router can forward the packet based on its IP address.

[0032] exist Figure 1 In the example, router 12 can route packets along segmented route LSP 16 based on a segmented route label stack including labels 1003, 1005, and 1007 associated with routers 12C, 12E, and 12G, respectively. For example, ingress router 12A encapsulates the packet including the packet route label stack and forwards the packet to its next hop, such as router 12B. Since router 12B's next hop is router 12C, router 12B removes the active label (e.g., 1003) from the segmented route label stack and forwards the packet to router 12C. Router 12C forwards the packet to router 12D, which removes the active label (e.g., 1005) from the segmented route label stack and forwards the packet to router 12E. Router 12E then forwards the packet to router 12F, which removes the active label (e.g., 1007) from the segmented route label stack and forwards the packet to router 12G. Since no label stack is attached to the packet, router 12G can forward the packet to another node in network 2, for example, based on the packet's IP address, without needing to use segmented routing further.

[0033] When an ingress router receives a packet, it assigns the packet to a Forwarding Equivalence Class (FEC), encapsulates the packet with the Fragmented Route Label Stack associated with the FEC, and forwards the packet on a Fragmented Route LSP according to the Fragmented Route Label Stack. An FEC indicates a packet that is forwarded through the network in the same way (i.e., along the same path). An FEC can be identified by its address, tunnel, or Class of Service (CoS). Typically, devices assign the same label to the same FEC. The label encapsulated in a packet is used to identify the FEC to which the packet has been assigned.

[0034] In some examples, the router 12 can use an LSP ping mechanism to test whether packets belonging to a particular FEC do indeed end at the egress router of the LSP associated with the FEC. The LSP ping mechanism generally includes two modes of testing: basic connectivity check ("ping") and fault isolation ("traceroute"). In the "ping" (basic connectivity check) mode, an MPLS connectivity request packet (e.g., an MPLS echo request packet) is typically sent to the egress router of the LSP to test the end-to-end connectivity to the egress router. For example, an ingress router of the LSP typically sends an MPLS echo request packet to the egress router. The egress router, in response to receiving the MPLS echo request packet, sends the packet to its control plane. The egress router then verifies that it is the egress of the LSP and sends an MPLS connectivity response packet (e.g., an MPLS echo reply packet) indicating a functioning connection of the LSP. If the MPLS echo reply packet is not received within a defined time period (e.g., a time-to-live (TTL) value), the connection along the LSP to the egress router is assumed to be broken.

[0035] In the "traceroute" (fault isolation) mode, the ingress router identifies the location of a fault in the LSP by tracing the path of the MPLS echo request packet from the ingress router to the egress router. For example, the MPLS echo request packet is typically sent to the control plane of each transit device, which performs various checks that the transit device is a transit device in the LSP. Each transit device in the LSP can also return information that helps to check the control plane against the data plane (i.e., forwarding data structures and operational matching routing protocol determinations for the contents of the LSP).

[0036] The LSP ping mechanism uses a FEC stack that includes information identifying the FEC to be verified. For each label in the label stack, the associated FEC information is included in the FEC stack for verification. The FEC information of the FEC stack can include one or more prefixes such as a label distribution protocol (LDP) prefix (IPv4 or IPv6), a resource reservation protocol (RSVP) IP session (IPv4 or IPv6), a virtual private network (VPN) prefix (IPv4 or IPv6), a generic IP prefix (IPv4 or IPv6), a Nil FEC, an IPv4 IGP-prefix segment identifier, an IPv6 IGP-prefix segment identifier, an IGP-adjacency segment identifier, etc.

[0037] Further description of LSP ping mechanisms are described in K. Kompella et al., “Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures,” IETF, RFC 8029, March 2017; N. Kumar et al., “Label Switched Path (LSP) Ping / Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes,” IETF, RFC 8287, December 2017; and K. Arora et al., “TTL Procedures for SR-TE Paths in Label Switched Path Traceroute Mechanisms,” draft-arora-mpls-spring-ttl-procedures-srte-paths-01, Internet-Draft, February 21, 2019, each of which is incorporated by reference herein in its entirety.

[0038] Without the techniques described herein, ingress routers would typically send MPLS ping request packets along the path of a segment LSP to each router, and receive a response from each of the routers, even for routers that are not operating as a segment endpoint for the segment LSP. As the size of the network increases, the ingress router receives more and more MPLS ping response packets, which increases the load on the network.

[0039] According to the techniques described in this disclosure, an ingress router (e.g., router 12A, referred to as “ingress router 12A”) can selectively ping certain routers along a segment routed LSP to detect a failure (e.g., a data plane failure) in the segment routed LSP without sending MPLS pings to every router along the path of the segment routed LSP.

[0040] In Figure 1In the examples of FIG. 1, assume network 2 is configured with a segment- routed LSP 16 having three segments 16A, 16B, and 16C, and the segment- routing label stack includes a respective label for each router (e.g., routers 12C, 12E, and 12G) operating as a segment endpoint along the segment- routed LSP. To check connectivity of each of routers 12C, 12E, and 12G without receiving a response from each of the routers in segment- routed LSP 16, ingress router 12A can configure a FEC stack including information identifying the routers of the segment- routing label stack in response to a request (e.g., via an interface or controller of ingress router 12A) to verify connectivity of segment- routed LSP 16 and iteratively send MPLS echo request packets to each of the routers 12C, 12E, and 12G identified from the FEC stack. In Figure 1 In the examples of FIG. 1, ingress router 12A can send a first MPLS connectivity request packet (e.g., MPLS echo request packet 22A) including a first label stack 24A including a first label corresponding to a device identified from an outermost FEC of the FEC stack (e.g., 1003 associated with router 12C) and a FEC stack 26A having information associated with the routers (e.g., routers 12C, 12E, and 12G) identified from the segment- routing label stack. In these examples, ingress router 12A includes a time-to-live (TTL) value (e.g., a default value of 255) for the label of the label stack. In Figure 1 In the examples of FIG. 1, ingress router 12A sends MPLS echo request packet 22A having first label 24A <1003, 255> and FEC stack 26A including prefix segment identifiers of routers 12C, 12E, and 12G.

[0041] Router 12B, which is the penultimate hop popping (PHP) router operating as the last hop before router 12C, pops the active label (e.g., first label 24A) from the label stack of MPLS echo request packet 22A and forwards MPLS echo request packet 22A via an interface of router 12B directly connected to router 12C. In response to receiving MPLS echo request packet 22A, router 12C can send the packet to its routing engine to verify that the router 12C is a segment endpoint of segment- routed LSP 16 associated with the FEC. In some examples, if MPLS echo request packet 22A includes a router alert (RA) object in an IP option, router 12C can send the packet to its routing engine.

[0042] Router 12C validates the outermost FEC of FEC stack 26A (e.g., the prefix associated with router 12C) and, if validated, sends a first MPLS echo reply packet (e.g., MPLS echo reply packet 28A) to ingress router 12A to indicate that router 12C is indeed a segment endpoint of the segment routing LSP 16 associated with the FEC. In response to receiving MPLS echo reply packet 28A, ingress router 12A updates the FEC stack, e.g., by removing the outermost FEC of FEC stack 26A (e.g., the prefix associated with router 12C), which leaves the prefix segment identifiers associated with routers 12E and 12G in the FEC stack (shown in Figure 1 as FEC stack "26B") in

[0043] Ingress router 12A sends a second MPLS echo request packet (e.g., MPLS echo request packet 22B) that includes a second label stack 24B having a first label (e.g., 1003 associated with router 12C) and a second label (e.g., 1005 associated with router 12E) corresponding to the device identified from the outermost FEC of the updated FEC stack, and a FEC stack 26B having information associated with routers 12E and 12G. In Figure 1 the example, ingress router 12A can send MPLS echo request packet 22B having first label <1003, 255> and second label <1005, 255>, and FEC stack 26B that includes the prefix segment identifiers of routers 12E and 12G.

[0044] Router 12B, operating as a PHP router for router 12C, pops the active label (e.g., the first label) and forwards MPLS echo request packet 22B to router 12C. In this example, the second label <1005, 255> becomes the active label for MPLS echo request packet 22B. Router 12C then forwards MPLS echo request packet 22B to router 12D. Router 12D, operating as a PHP router for router 12E, pops the active label (e.g., the second label) and forwards MPLS echo request packet 22B to router 12E. In response to receiving MPLS echo request packet 22B, router 12E can send the packet to a routing engine of the router 12E to verify that router 12E is a segment endpoint of the segment routing LSP 16 associated with the FEC, e.g., if MPLS echo request packet 22B includes a router alert object in an IP option.

[0045] Router 12E verifies the outermost FEC of FEC stack 26B (e.g., the prefix associated with router 12E) and sends a second MPLS echo reply packet (e.g., MPLS echo reply packet 28B) to ingress router 12A to indicate that router 12E is indeed a segment endpoint of the segment routing LSP associated with the FEC. For example, in response to receiving MPLS echo reply packet 28A, ingress router 12A updates the FEC stack by removing the outermost FEC of FEC stack 26B (e.g., the prefix associated with router 12E), which leaves the prefix associated with router 12G in the FEC stack (shown in Figure 1 FIG. 11 as FEC stack “26C”).

[0046] Ingress router 12A sends a third MPLS echo request packet (e.g., MPLS echo request packet 22C) that includes a third label stack 24C having a first label (e.g., 1003 associated with router 12C), a second label (e.g., 1005 associated with router 12E), and a third label (e.g., 1007 associated with router 12G) corresponding to the device identified from the outermost FEC of the updated FEC stack, and a FEC stack 26C having information associated with router 12G. As one example, ingress router 12A can send MPLS echo request packet 22C having a first label <1003, 255>, a second label <1005, 255>, and a third label <1007, 255>, and a FEC stack 26C that includes the prefix of router 12G.

[0047] Router 12B, operating as a PHP router for router 12C, pops the active label (e.g., the first label) and forwards MPLS echo request packet 22C to router 12C. In this example, the second label <1005, 255> becomes the active label for MPLS echo request packet 22C. Router 12C then forwards MPLS echo request packet 22C to router 12D. Router 12D, operating as a PHP router for router 12E, pops the active label (e.g., the second label) and forwards MPLS echo request packet 22C to router 12E. In this example, the third label <1007, 255> becomes the active label for MPLS echo request packet 22C. Router 12E then forwards MPLS echo request packet 22C to router 12F. Router 12F, operating as a PHP router for router 12G, pops the active label (e.g., the third label) and forwards MPLS echo request packet 22C to router 12G. In response to receiving MPLS echo request packet 22BC, (e.g., if MPLS echo request packet 22C includes a route warning object in the IP option) router 12G can send the packet to a routing engine of the router 12G to verify that router 12G is a segment endpoint for the segment routing LSP 16 associated with the FEC.

[0048] Router 12G verifies the outermost FEC of FEC stack 26C (e.g., 1007 associated with router 12G) and sends a first MPLS echo reply packet (e.g., MPLS echo reply packet 28C) to ingress router 12A to indicate that router 12G is indeed a segment endpoint for the segment routing LSP 16 associated with the FEC. In response to receiving MPLS echo reply packet 28C, ingress router 12A removes the last FEC in FEC stack 26C (e.g., the prefix associated with router 12E), which signals to ingress router 12A that the LSP ping mechanism is complete and that the connection for the segment routing LSP 16 associated with the FEC is verified.

[0049] Figure 2 is a block diagram illustrating another example network in which ingress devices selectively ping certain routers along a segment routing LSP to detect a fault (e.g., a data plane fault) in the segment routing LSP. In this example, the segment routing LSP 16 is associated with a FEC that includes a prefix 1001 associated with router 12A, a prefix 1002 associated with router 12B, a prefix 1003 associated with router 12C, a prefix 1004 associated with router 12D, a prefix 1005 associated with router 12E, a prefix 1006 associated with router 12F, and a prefix 1007 associated with router 12G. Figure 2In the example, network 100 includes access networks 106A-106D (collectively referred to as "access network 106") connected via an intermediate network (e.g., intermediate network 108). Intermediate network 108 may represent a service provider network owned and operated by a service provider, typically a large telecommunications entity or company. Intermediate network 108 represents a Layer 3 (L3) computer network, where the reference to a layer with a number refers to the corresponding layer in the Open Systems Interconnection (OSI) model. Intermediate network 108 is a Layer 3 network in the sense of supporting Layer 3 operations as described in the OSI model. Common L3 operations include those performed according to L3 protocols such as the Internet Protocol (IP). L3 is also referred to as the "network layer" in the OSI model and as the "IP layer" in the TCP / IP model, and throughout this disclosure, the term L3 may be used interchangeably with the phrases "network layer" and "IP." In this disclosure, intermediate network 108 may also be referred to as a "core" network.

[0050] Intermediate network 108 can be coupled to one or more networks managed by the provider of intermediate network 108 or other providers, and thus can form part of a large-scale public network infrastructure (e.g., the Internet). Therefore, access network 106 can be considered as an edge network of the Internet. Intermediate network 108 can provide internet access to computing devices within access network 106 and can allow computing devices within access network 106 to communicate with each other.

[0051] like Figure 2 As shown, network 100 can be divided into multiple IGP domains or areas 104. For example, network 100 includes four domains 104A-104D (collectively referred to as "domain 104"). In some examples, domain 104 may include an Interior Gateway Protocol (IGP) domain or area, which comprises a group of routers under common management and control and sharing a common routing protocol. Example IGPs include Intermediate System-Intermediate System (IS-IS) and Open Shortest Path First (OSFP). In this example, routers 112A-112B belong to domain 104A, routers 112E-112F belong to domain 104B, routers 112G-112H belong to domain 104C, and routers 112I-112J belong to domain 104D. Figure 2 In the example shown, router 112 includes border routers, such as routers 12C and 12D, located at the edge and between different domains. Area border routers 12C and 12D include interfaces attached to multiple areas. For example, router 12C includes interfaces attached to domains 104A and 104C, and router 12D includes interfaces attached to domains 104B and 104D. Although Figure 2Each of the domains 104 includes one or more other network devices operating as transit routers or switches to forward traffic within the respective domain and between the border routers, although not shown.

[0052] As shown, the network 100 includes a controller 128 that can operate as a software-defined networking (SDN) controller or other centralized controller that provides control plane operations and management for the routers and other network devices within one or more of the domains 104. For purposes of explanation, the controller 128 is described herein as providing control plane operations and management for the domain 104A and the domain 104B. In other examples, each of the domains 104 can include a designated centralized controller. Figure 2 As shown, the router 112A serves as an ingress router for the inter-domain segment routing LSP 116, and thus can be referred to in this disclosure as the ingress router 112A. Similar to the examples described in

[0053] The source of the inter-domain segment routing LSP 116 received by the ingress router 112A can include one or more devices (not shown) and / or any public or private network or the Internet that provides traffic to the ingress router 112A in the network 100, similar to the examples described in Figure 1 In some examples, the router 112F serves as an egress router for the inter-domain segment routing LSP 116, and thus can be referred to in this disclosure as the egress router 112F.

[0054] Similar to the examples described in Figure 1 The routers 112 can use segment routing techniques (e.g., SPRING paradigm) to advertise segments between nodes using IGP or BGP and establish single-hop or multi-hop tunnels within each domain 104, similar to the examples described in

[0055] In this example, the routers 112 can advertise the prefixes and SIDs to the controller 128. For example, the routers 112 can use Border Gateway Protocol Link State (BGP-LS) to propagate the intra-domain path information for each domain 104 to the controller 128. In a controller-based inter-domain segment routing provisioning model, the controller 128 programs the ingress router (e.g., ingress router 112A) with a list of SIDs for establishing the inter-domain segment routing LSP. For example, the controller 128 can establish a configuration session with the ingress router 112A, e.g., via Path Computation Element Protocol (PCEP), to send the ingress router the list of SIDs for establishing the inter-domain segment routing LSP.

[0056] In this way, the controller 128 can provide the ingress router 112A with FEC information to enable the ingress router 112A to selectively probe certain devices along the inter-domain segment routing LSP 116 to detect a failure (e.g., a data plane failure) in the inter-domain segment routing LSP 116, similar to the examples described in Figure 1

[0057] Figure 3 is a block diagram illustrating another example network in which ingress devices selectively probe certain devices along a segment routing label switched path (LSP) to detect a failure (e.g., a data plane failure) in the segment routing LSP, in accordance with the techniques described in this disclosure. As shown, the network 200 includes autonomous systems 204A and 204B (collectively referred to as “autonomous systems 204”). Each of the autonomous systems 204 can include a set of routers under common administrative control and sharing a common routing protocol. Each of the autonomous systems 204 can include at least one border device that communicates with routers in other autonomous systems. In this example, the autonomous system 204A includes routers 212A, provider routers 214A-214B, and autonomous system border routers (ASBRs) 216A and 216C. Similarly, the autonomous system 204B includes routers 212B, provider routers 214C-214D, and ASBRs 216B and 216D. Each of the autonomous systems 204 can be owned or managed by a different service provider. Figure 3

[0058] Similar to the controller 128 of Figure 2 , the controller 228 can operate as an SDN controller or other centralized controller that provides control plane operations and management for routers and other network devices within one or more of the autonomous systems 204. Similar to the controller 128 of Figure 1 ​​As described in the example, router 212 can use fragmentation routing techniques (e.g., the Spring paradigm) to advertise fragmentation between nodes using IGP or BGP and establish single-hop or multi-hop tunnels within each autonomous system 204. Traditionally, inter-AS fragmented routing LSPs are constructed with a list of fragmentation identifiers (SIDs) for ASBR 216 and router 212. Because nodes within a given autonomous system typically do not store data describing nodes and routes within other autonomous systems, including prefixes and SIDs (e.g., node SIDs and / or binding SIDs), ingress router 212A cannot possess FEC information from other autonomous systems used to test the connectivity of inter-AS fragmented routing LSPs associated with that FEC.

[0059] In this example, router 212 and ASBR 216 can advertise prefixes and SIDs to controller 228. For example, router 212 and ASBR 216 can use Border Gateway Protocol Link State (BGP-LS) to propagate path information within each autonomous system of autonomous system 204 to controller 228. In a controller-based inter-AS segmented routing provisioning model, controller 228 programs the ingress router (e.g., ingress router 212A) with a list of SIDs used to establish inter-AS segmented routing LSP 218. For example, controller 228 can establish a configuration session with ingress router 212A, for example, via Path Computing Unit Protocol (PCEP), to send the list of SIDs used to establish inter-AS segmented routing LSPs to the ingress router.

[0060] In this way, it is similar to Figure 1 As described in the example, controller 228 can provide FEC information to ingress router 212A to enable ingress router 212A to selectively inspect certain devices along inter-AS segmented route LSP 218 to detect faults (e.g., data plane faults) in inter-AS segmented route LSP 218. In these examples, MPLS echo reply packets can use a reverse label stack as described in S. Hegde et al., “PMS / Head-end based MPLS Ping and Traceroute in Inter-AS SR Networks,” Internet-Draft, draft-ninan-spring-mpls-inter-as-oam-01, July 5, 2019, the entire contents of which are incorporated herein by reference.

[0061] Figure 4 This is a block diagram illustrating an example network device 400 capable of operating according to the techniques described herein. Network device 400 may represent... Figures 1 to 3any of the ingress routers. While described with respect to routers, the techniques can be implemented by any other type of network device having routing functionality, and need not be dedicated routing devices.

[0062] In Figure 4 In the example of FIG. 4, network device 400 includes interface cards 454A-454N (“IFCs 454”) that respectively receive and transmit data units, such as packet flows, via inbound links 456A-456N (collectively “inbound links 456”) and outbound links 457A-457N (collectively “outbound links 457”). Network device 400 can include a chassis (not shown) having a plurality of slots for receiving a set of cards, including IFCs 454. Each card can be inserted into a respective slot of the chassis to electrically couple the card to routing component 444 via a high speed switch (not shown), e.g., that can include a switch fabric, a switch device, a configurable network switch or hub, or other high speed switching mechanism. IFCs 454 can be coupled to network links 456A-456N and 457A-457N via a plurality of physical interface ports (not shown). Generally, IFCs 454 can each represent one or more network interfaces through which network device 400 can interface with links of a network.

[0063] Generally, network device 400 can include a control unit 442 that determines the routing of received packets and forwards the packets accordingly via IFCs 454. In Figure 4 In the example of FIG. 4, control unit 442 includes a routing component (control plane) 444 that configures and controls packet forwarding operations applied by forwarding component (data plane) 446.

[0064] Routing component 444 provides an operating environment for various routing protocols 470 that operate at different layers of the network stack. Routing component 444 is responsible for maintaining routing information 460 that reflects the current topology of networks and other network entities connected with network device 400. In particular, routing protocols periodically update routing information 460 to accurately reflect the topology of networks and other entities based on routing protocol messages received by network device 400. The protocols can be software processes executing on one or more processors. For example, routing component 444 includes a network protocol that operates at the network layer of the network stack, which is typically implemented as executable software instructions.

[0065] In Figure 4In the example of FIG. 4, the protocols 470 can include an IGP 471 to exchange link state information and facilitate the forwarding of packets or other data units between routers within a routing domain. In some examples, the IGP 471 can include an OSPF routing protocol according to one or more of RFC 2328, “OSPF Version 2,” by J. Moy, April 1998, RFC 5340, “OSPF for IPv6,” by R. Coltun et al., July 2008, RFC 6845, “OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type,” by N. Sheth et al., January 2013, and RFC 6845, “OSPFv3 Link State Advertisement (LSA) Extendibility,” by Lindem et al., April 2018. In some examples, the IGP 471 can include an IS-IS routing protocol that implements an IGP for exchanging routing and reachability information within a routing domain according to RFC 1142, “OSI IS-IS Intra-domain Routing Protocol,” by D. Oran, February 1990 (republication of ISO / IEC 10589, last updated November 2002). The IGP 471 can include IS-IS extensions to support traffic engineering as described in RFC 5305, “IS-IS Extensions for Traffic Engineering,” by T. Li et al., October 2008. In some examples, the network device 400 can include both an OSPF component and an IS-IS component.

[0066] In some examples, alternatively or additionally, the protocols 470 can include a Border Gateway Protocol Link State (BGP-LS) 472 to exchange traffic engineering and segment routing policy information with the controller 228. The BGP-LS protocol is described in further detail in “North-Bound Distribution of Link-State and Traffic Engineering (TE) Information using BGP,” by H. Gredler et al., Internet Engineering Task Force (IETF) RFC 7752, March 2016, which is incorporated by reference herein in its entirety.

[0067] Protocol 470 can also include a configuration protocol. For example, protocol 470 can include PCEP 473 in accordance with RFC 5440, entitled "Path Computation Element (PCE) Communication Protocol (PCEP)," by JP. Vasseur, Ed. et al., March 2009, or include NETCONF (not shown) in accordance with RFC 6241, entitled "Network Configuration Protocol (NETCONF)," by R. Enns, Ed. et al., June 2011. In some examples in which network device 400 includes an ingress router for an inter-domain segment routing LSP or an inter-AS segment routing LSP, controller 428 (e.g., controller 128 of Figure 2 or controller 228 of Figure 3 ) can configure network device 400 with a list of SIDs 486 for a segment routing tunnel via PCEP 473 or a NETCONF component (not shown). Protocol 470 can include other routing protocols (not shown), such as a label distribution protocol (LDP), a resource reservation protocol with traffic engineering extensions (RSVP-TE), a routing information protocol (RIP), or other network protocols.

[0068] Routing component 444 includes a link state database (LSDB) 480 for storing domain topology information, including SIDs and labels for provisioned segments (e.g., adjacency segments, prefix segments, and / or binding segments). The contents of LSDB 480 are maintained according to IGP 473 and have the scope of a single routing domain. Routing component 444 also includes a traffic engineering database 482 that augments LSDB 480 with traffic engineering link attributes. Each of LSDB 480 and TED 482 can be in the form of various data structures, such as multiple tables, linked lists, radix trees, databases, flat files, or other data structures.

[0069] Routing component 444 includes a segment routing (SR) component 476 to implement segment routing techniques that specify how network device 400 can provision and advertise SIDs to adjacency segments and / or prefix segments. In some examples, segment routing component 476 of network device 400 operating as an ingress router can use SIDs in LSDB 480 or TED 482 to construct SID label stacks stored in SID list 486. Alternatively or additionally, network device 400 can receive SID list 486 from controller 228. Network device 400 can direct packets through the network by prepending a packet header with a SID label stack from SID list 486.

[0070] By executing a routing protocol, the routing component 444 identifies existing routes through the network and determines new routes through the network. For example, the routing component 444 stores routing information 460 that includes known routes through the network. The forwarding component 446 stores forwarding information 462 that includes destinations for the outbound links 457. The forwarding information 462 can be generated from the routing information 460.

[0071] According to the described techniques, the network device 400 includes a selective ping component 490 that is configured to selectively ping certain devices along a segment routed LSP to detect a failure (e.g., a data plane failure) of the segment routed LSP. In this example, the network device 400 operating as an ingress router (e.g., ingress router 12A of Figure 1 may iteratively send MPLS ping request packets to each of the routers identified from the FEC stack configured from the segment routed label stack of the segment routed LSP.

[0072] For example, in response to receiving a request to verify connectivity of a segment routed LSP, e.g., via the CLI 478, the selective ping component 490 can configure the FEC stack 494 that specifies a stack of segment routed labels of the segment routed LSP. The selective ping component 490 can determine the segment routed label stack of the segment routed LSP from the SID list 486. For ease of illustration, in this example, the SID list 486 can include a segment routed label stack that includes labels associated with routers 12C, 12E, and 12G as described in Figure 1 The selective ping component 490 can configure the FEC stack 494 to include information associated with the routers (e.g., routers 12C, 12E, and 12G) identified from the SID list 486.

[0073] The selective ping component 490 can generate an MPLS ping request packet that includes the label stack 492 including a first label corresponding to a device identified from an outermost FEC of the FEC stack 494 (e.g., 1003 associated with router 12C) and the FEC stack 494 having information associated with the routers (e.g., 12C, 12E, and 12G) identified from the segment routed label stack.

[0074] Network device 400 can send an MPLS echo request packet on the segment routing LSP path via one of the outbound links 457 connected to the next hop of the segment routing LSP. In response, network device 400 can receive an MPLS echo reply packet if router 12C is verified as a segment endpoint of the segment routing LSP. In this example, network device 400 can receive the MPLS echo reply packet via one of the inbound links 456, and forwarding component 446 forwards the MPLS echo reply packet to selective inspection component 490.

[0075] For example, in response to receiving the MPLS echo reply packet, selective inspection component 490 updates FEC stack 494 by removing the outermost FEC (e.g., the prefix associated with router 12C) of FEC stack 494, which leaves the prefix segment identifiers associated with routers 12E and 12G in FEC stack 494.

[0076] Selective inspection component 490 can determine whether any prefix segment identifiers remain in FEC stack 494. If FEC stack 494 includes at least one prefix, selective inspection component 490 continues the LSP inspection process for each of the next routers identified in FEC stack 494 (e.g., routers 12E and 12G) until FEC stack is empty. For example, selective inspection component 490 can generate a subsequent MPLS echo request packet that includes an updated label stack that includes a previous label (e.g., 1003 associated with router 12C) and a subsequent label corresponding to the device identified from the outermost FEC of the updated FEC stack 494 (e.g., 1005 associated with router 12E), and the updated FEC stack has information associated with routers 12E and 12G. Network device 400 can send the subsequent MPLS echo request packet on the segment routing LSP path, and in response, receive an MPLS echo reply packet from router 12E. For example, selective inspection component 490 updates FEC stack 494 by removing the outermost FEC (e.g., the prefix associated with router 12E) of FEC stack 494, which leaves the prefix segment identifier associated with router 12G in FEC stack 494.

[0077] In the next iteration, the selective probing component 490 can generate a subsequent MPLS echo request packet including an updated label stack that includes the previous labels (e.g., 1003 associated with router 12C and 1005 associated with router 12E) and a subsequent label corresponding to the device identified from the outermost FEC of the updated FEC stack 494 (e.g., 1007 associated with router 12G), and the updated FEC stack has information associated with router 12G. The network device 400 can transmit the subsequent MPLS echo request packet over the segment routing LSP path and, in response, receive an MPLS echo reply packet from router 12G. For example, the selective probing component 490 updates the FEC stack 494 by removing the outermost FEC of the FEC stack 494 (e.g., the prefix associated with router 12G), which results in the FEC stack 494 being empty. The empty FEC stack 494 signals to the selective probing component 490 that the LSP probing mechanism has completed and that the connectivity of the segment routing LSP has been verified. In some examples, for example, the selective probing component 490 can generate an indication to a user via an interface that the segment routing LSP has connectivity.

[0078] Figure 4 The architecture of the network device 400 illustrated in FIG. 4 is shown for example purposes only. The techniques of this disclosure are not limited to this architecture. In other examples, the network device 400 can be configured in various ways. In one example, some of the functionality of the control unit 442 can be distributed within the IFC 454. In another example, the control unit 442 can include multiple packet forwarding engines that operate as client routers.

[0079] The control unit 442 can be implemented individually in software or hardware, or can be implemented as a combination of software, hardware, or firmware. For example, the control unit 442 can include one or more processors that execute program code in the form of software instructions. In this case, the various software components / modules of the control unit 442 can include executable instructions stored on a computer-readable storage medium such as a computer memory or a hard disk.

[0080] Figure 5 is a flow diagram illustrating example operations of a network 2 in accordance with the techniques described in this disclosure. For purposes of explanation, the Figure 1 ingress router 12A of Figure 2 ingress router 112A of Figure 3 ingress router 212A) of Figure 5 .

[0081] In response to a request to verify the connection of Fragmented Route LSP 16, Ingress Router 12A configures an FEC stack that specifies the stack of Fragmented Route Labels for the Fragmented Route LSP. For example, Ingress Router 12A may receive a request to verify the connection of Fragmented Route LSP 16, for example, via CLI 478. In response, the Selective Authentication component 490 of Ingress Router 12A may determine the Fragmented Route Label stack of the established Fragmented Route LSP (e.g., Fragmented Route LSP 16). Figure 1 In the example described, the selective authentication component 490 of the ingress router 12A determines that the segmented route label stack of segmented route LSP 16 includes labels associated with routers 12C, 12E, and 12G. The selective authentication component 490 configures the FEC stack, which includes information associated with routers 12C, 12E, and 12G (e.g., prefix segmentation identifier).

[0082] Ingress router 12A can iteratively send MPLS echo request packets to each router identified from the FEC stack configured by the segmented routing label stack, without having to send MPLS echo request packets to each next-hop router along segmented route LSP 16. For example, ingress router 12A generates an MPLS connection request packet (504) for the corresponding device identified from the outermost FEC of the FEC stack. For example, ingress router 12A can generate a first MPLS connection request packet (e.g., MPLS echo request packet 22A) including a first label stack 24A and an FEC stack 26A, the first label stack 24A including a first label (e.g., 1003 associated with router 12C) corresponding to the device identified by the outermost FEC of the FEC stack, and the FEC stack 26A having information associated with the routers identified from the segmented routing label stack (e.g., routers 12C, 12E, and 12G). In these examples, ingress router 12A includes TTL values ​​for the labels used in the label stack (e.g., a default value of 255). In this example, ingress router 12A generates an MPLS echo request packet 22A with a first label 24A as <1003, 255> and an FEC stack 26A, which includes prefix segment identifiers for routers 12C, 12E, and 12G.

[0083] Ingress router 12A sends an MPLS echo request packet to the next hop (506) corresponding to the fragmented routing LSP associated with the FEC stack. If router 12C is authenticated as the fragment endpoint of the fragmented routing LSP, router 12C of the FEC stack returns an MPLS connection response packet (e.g., Figure 1 MPLS echo response packet 28A).

[0084] The ingress router 12A determines whether the ingress router 12A received an MPLS connectivity response packet (e.g., MPLS echo reply packet 28A) (508). If the ingress router 12A did not receive an MPLS echo reply packet ("No" at step 508), the ingress router 12A determines that the segment routing LSP is faulty (510). If the ingress router 12A received an MPLS echo reply packet ("Yes" at step 508), the ingress router 12A updates the FEC stack by removing the outermost FEC from the FEC stack (512). For example, the ingress router 12A updates the FEC stack by removing the prefix associated with the router 12C, which is the outermost FEC of the FEC stack. In this example, the updated FEC stack includes the prefixes associated with the routers 12E and 12G in the FEC stack 26B of the FEC stack 26A. Figure 1

[0085] The ingress router 12A can determine whether any prefix segment identifiers remain in the updated FEC stack (i.e., whether the FEC stack is empty) (514). In this example, the FEC stack includes at least one prefix (e.g., the prefix segment identifiers associated with the routers 12E and 12G). In response to determining that at least one prefix remains in the FEC stack ("No" at step 514), the ingress router 12A generates (504) an MPLS connectivity request packet and sends (506) the MPLS connectivity request packet to each of the remaining routers identified in the FEC stack. In some examples, after the ingress router 12A updates the FEC stack by removing the outermost FEC from the FEC stack, the ingress router 12A can determine that the FEC stack is empty ("Yes" at step 514), which signals to the ingress router 12A that the LSP ping mechanism is complete and that the connectivity of the segment routing LSP associated with the FEC has been verified (516). Continuing the example above, the ingress router 12A can receive a response from the last router of the FEC stack (e.g., the router 12G). The ingress router 12A updates the FEC stack by removing the prefix associated with the router 12G, which is the last prefix of the FEC stack. Because the FEC stack is empty, the ingress router 12A determines that the LSP ping mechanism is complete and that the connectivity of the segment routing LSP 16 associated with the FEC has been verified.

[0086] The techniques described herein can be implemented in hardware, software, firmware, or any combination thereof. Various features described as modules, units or components can be implemented together in an integrated logic device or separately as discrete but interoperable logic devices or other hardware devices. In some cases, various features of electronic circuitry can be implemented as one or more integrated circuit devices, such as integrated circuit chips or chip sets.

[0087] ​If implemented in hardware, the present disclosure can be directed to an apparatus such as a processor or integrated circuit device, such as an integrated circuit chip or chipset. Alternatively or additionally, if implemented in software or firmware, the techniques can be realized at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, the computer-readable data storage medium can store such instructions for execution by a processor.

[0088] A computer-readable medium can form part of a computer program product, which can include packaging materials. The computer-readable medium can include a storage medium such as a random access memory (RAM), read only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read only memory (EEPROM), FLASH memory, magnetic or optical data storage media, and the like. In some examples, an article of manufacture can include one or more computer-readable storage media.

[0089] In some examples, a computer-readable storage medium can include a non-transitory medium. The term "non-transitory" can indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium can store data that can, over time, change (e.g., in RAM or cache).

[0090] Code or instructions can be software and / or firmware executed by processing circuitry including one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term "processor" as used herein can refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described in this disclosure can be provided within software modules or hardware modules.

[0091] Further, the present technology can be configured as follows.

[0092] (1) A method comprising:

[0093] configuring, by an ingress device of a Segment Routing Label Switched Path, a Forwarding Equivalence Class stack in response to a request to verify connectivity of the Segment Routing Label Switched Path, the Forwarding Equivalence Class stack specifying a stack of Segment Routing labels of the Segment Routing Label Switched Path, wherein the Forwarding Equivalence Class stack includes information identifying one or more devices operating as segment endpoints along the Segment Routing Label Switched Path to be verified; and

[0094] For each of the one or more devices identified from the forwarding equivalence class stack:

[0095] generating, by the ingress device, a respective multi-protocol label switching connection request packet for a respective device of the one or more devices, wherein the respective device is identified from an outermost forwarding equivalence class of the forwarding equivalence class stack;

[0096] sending, by the ingress device, the multi-protocol label switching connection request packet to the respective device;

[0097] receiving, by the ingress device, a multi-protocol label switching connection response packet from the respective device, the multi-protocol label switching connection response packet verifying connection of the respective device of the segment routing label switching path; and

[0098] in response to receiving the multi-protocol label switching connection response packet, the ingress device updating the forwarding equivalence class stack by removing the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the respective device.

[0099] (2) The method of (1),

[0100] wherein the one or more devices of the segment routing label switching path comprise a first device and a second device,

[0101] wherein the forwarding equivalence class stack comprises the outermost forwarding equivalence class that identifies the first device and a subsequent forwarding equivalence class that identifies the second device,

[0102] wherein generating the respective multi-protocol label switching connection request packet comprises generating a first multi-protocol label switching connection request packet that includes the forwarding equivalence class stack and a first label stack to direct the first multi-protocol label switching connection request packet to the first device,

[0103] wherein sending the multi-protocol label switching connection request packet to the respective device of the one or more devices comprises sending the first multi-protocol label switching connection request packet to the first device,

[0104] wherein receiving the multi-protocol label switching connection response packet that verifies connection of the respective device of the segment routing label switching path comprises receiving a first multi-protocol label switching connection response packet that verifies connection of the first device of the segment routing label switching path, and

[0105] wherein updating the forwarding equivalence class stack comprises updating the forwarding equivalence class stack by removing the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the first device, the updating causing the subsequent forwarding equivalence class to become an outermost forwarding equivalence class of the updated forwarding equivalence class stack.

[0106] (3) The method of (2),

[0107] wherein the first label stack comprises a label associated with the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the first device.

[0108] (4) The method of (2),

[0109] wherein generating the respective multi-protocol label switching connection request packet comprises generating a second multi-protocol label switching connection request packet comprising the updated forwarding equivalence class stack and a second label stack to direct the second multi-protocol label switching connection request packet to the second device,

[0110] wherein sending the multi-protocol label switching connection request packet to the respective one or more devices comprises sending the second multi-protocol label switching connection request packet to the second device,

[0111] wherein receiving the multi-protocol label switching connection response packet verifying the connection of the respective device of the segment routing label switched path comprises receiving a second multi-protocol label switching connection response packet verifying the connection of the second device of the segment routing label switched path, and

[0112] wherein updating the forwarding equivalence class stack comprises updating the updated forwarding equivalence class stack by removing the outermost forwarding equivalence class of the updated forwarding equivalence class stack that identifies the second device.

[0113] (5) The method of (4),

[0114] wherein the second label stack comprises a first label and a second label, the first label being associated with the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the first device and the second label being associated with the outermost forwarding equivalence class of the updated forwarding equivalence class stack that identifies the second device.

[0115] (6) The method of (1),

[0116] wherein the multi-protocol label switching connection request packet comprises a multi-protocol label switching echo request packet, and

[0117] wherein the multi-protocol label switching connection response packet comprises a multi-protocol label switching echo reply packet.

[0118] (7) The method of any of (1) to (6), wherein the segment routing label switched path comprises an inter-domain segment routing label switched path, the method further comprising:

[0119] receiving, by the ingress device from a controller, a segment routing label stack.

[0120] (8) The method of any of (1) to (6), wherein the segment routing label switched path comprises an autonomous inter-system segment routing label switched path, the method further comprising:

[0121] receiving, by the ingress device from a controller, a segment routing label stack.

[0122] (9) An ingress device of a segment routing label switched path, comprising:

[0123] one or more processors, operatively coupled to the memory, wherein the one or more processors are configured to:

[0124] in response to verifying a request for connection of the segment routing label switched path, configure a forwarding equivalence class stack, the forwarding equivalence class stack specifying a stack of segment routing labels of the segment routing label switched path, wherein the forwarding equivalence class stack comprises information identifying one or more devices operating as segment endpoints along the segment routing label switched path; and for each device of the one or more devices identified from the forwarding equivalence class stack:

[0125] generate a respective multi-protocol label switching connection request packet for the respective device of the one or more devices, wherein the respective device is identified from an outermost forwarding equivalence class of the forwarding equivalence class stack;

[0126] send the multi-protocol label switching connection request packet to the respective device;

[0127] receive a multi-protocol label switching connection response packet from the respective device, the multi-protocol label switching connection response packet verifying connection of the respective device of the segment routing label switched path; and

[0128] in response to receiving the multi-protocol label switching connection response packet, update the forwarding equivalence class stack by removing the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the respective device.

[0129] (10) The ingress device of (9),

[0130] wherein the one or more devices of the segment routed label switched path comprise a first device and a second device,

[0131] wherein the forwarding equivalence class stack comprises the outermost forwarding equivalence class identifying the first device and a subsequent forwarding equivalence class identifying the second device,

[0132] wherein to generate the respective multi-protocol label switching connection request packet, the one or more processors are further configured to generate a first multi-protocol label switching connection request packet comprising the forwarding equivalence class stack and a first label stack to direct the first multi-protocol label switching connection request packet to the first device,

[0133] wherein to send the multi-protocol label switching connection request packet to the respective device of the one or more devices, the one or more processors are further configured to send the first multi-protocol label switching connection request packet to the first device,

[0134] wherein to receive the multi-protocol label switching connection response packet verifying the connection of the respective device of the segment routed label switched path, the one or more processors are further configured to receive a first multi-protocol label switching connection response packet verifying the connection of the first device of the segment routed label switched path, and

[0135] wherein to update the forwarding equivalence class stack, the one or more processors are further configured to update the forwarding equivalence class stack by removing the outermost forwarding equivalence class of the forwarding equivalence class stack identifying the first device, the update causing the subsequent forwarding equivalence class to become an outermost forwarding equivalence class of the updated forwarding equivalence class stack.

[0136] (11) The ingress device of (10),

[0137] wherein the first label stack comprises a label associated with the outermost forwarding equivalence class of the forwarding equivalence class stack identifying the first device.

[0138] (12) The ingress device of (10),

[0139] wherein to generate the respective multi-protocol label switching connection request packet, the one or more processors are further configured to generate a second multi-protocol label switching connection request packet comprising the updated forwarding equivalence class stack and a second label stack to direct the second multi-protocol label switching connection request packet to the second device,

[0140] wherein, to transmit the multi-protocol label switching connection request packet to the respective device of the one or more devices, the one or more processors are further configured to transmit the second multi-protocol label switching connection request packet to the second device,

[0141] wherein, to receive the multi-protocol label switching connection response packet verifying the connection of the respective device of the segment routing label switched path, the one or more processors are further configured to receive a second multi-protocol label switching connection response packet verifying the connection of the second device of the segment routing label switched path, and

[0142] wherein, to update the forwarding equivalence class stack, the one or more processors are further configured to update the updated forwarding equivalence class stack by removing the outermost forwarding equivalence class of the updated forwarding equivalence class stack that identifies the second device.

[0143] (13) The ingress device of (9),

[0144] wherein the multi-protocol label switching connection request packet comprises a multi-protocol label switching echo request packet, and

[0145] wherein the multi-protocol label switching connection response packet comprises a multi-protocol label switching echo reply packet.

[0146] (14) The ingress device of any of (9) to (13), wherein the segment routing label switched path comprises an inter-domain segment routing label switched path, wherein the one or more processors are further configured to:

[0147] receive a segment routing label stack from a controller.

[0148] (15) The ingress device of any of (9) to (13), wherein the segment routing label switched path comprises an inter-autonomous system segment routing label switched path, wherein the one or more processors are further configured to:

[0149] receive a segment routing label stack from a controller.

[0150] (16) A non-transitory computer-readable medium containing instructions for causing one or more programmable processors of an ingress device to perform operations comprising:

[0151] In response to a request to verify connectivity of a segment routing label switched path, a forwarding equivalence class stack is configured, the forwarding equivalence class stack specifying a stack of segment routing labels of the segment routing label switched path, wherein the forwarding equivalence class stack includes information identifying one or more devices operating as segment endpoints along the segment routing label switched path; and

[0152] For each device of the one or more devices identified from the forwarding equivalence class stack:

[0153] a respective multi-protocol label switching connection request packet is generated for a respective device of the one or more devices, wherein the respective device is identified from an outermost forwarding equivalence class of the forwarding equivalence class stack;

[0154] the multi-protocol label switching connection request packet is sent to the respective device;

[0155] a multi-protocol label switching connection response packet is received from the respective device, the multi-protocol label switching connection response packet verifying connectivity of the respective device of the segment routing label switched path; and

[0156] in response to receiving the multi-protocol label switching connection response packet, the forwarding equivalence class stack is updated by removing the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the respective device.

[0157] (17) The non-transitory computer-readable medium of (16),

[0158] wherein the one or more devices of the segment routing label switched path include a first device and a second device,

[0159] wherein the forwarding equivalence class stack includes the outermost forwarding equivalence class that identifies the first device and a subsequent forwarding equivalence class that identifies the second device,

[0160] wherein to generate the respective multi-protocol label switching connection request packet, the one or more processors are further configured to generate a first multi-protocol label switching connection request packet that includes the forwarding equivalence class stack and a first label stack to direct the first multi-protocol label switching connection request packet to the first device,

[0161] wherein to send the multi-protocol label switching connection request packet to the respective device of the one or more devices, the one or more processors are further configured to send the first multi-protocol label switching connection request packet to the first device,

[0162] wherein to receive the multi-protocol label switching connection response packet verifying the connection of the respective device of the segment routing label switching path, the one or more processors are further configured to receive a first multi-protocol label switching connection response packet verifying the connection of the first device of the segment routing label switching path, and

[0163] wherein to update the forwarding equivalence class stack, the one or more processors are further configured to update the forwarding equivalence class stack by removing the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the first device, wherein the updated forwarding equivalence class stack includes an outermost forwarding equivalence class of the updated forwarding equivalence class stack that identifies the second device.

[0164] (18) The non-transitory computer-readable medium of (17),

[0165] wherein the first label stack includes a label associated with the outermost forwarding equivalence class of the forwarding equivalence class stack that identifies the first device.

[0166] (19) The non-transitory computer-readable medium of (17),

[0167] wherein to generate the respective multi-protocol label switching connection request packet, the one or more processors are further configured to generate a second multi-protocol label switching connection request packet including the updated forwarding equivalence class stack and a second label stack to direct the second multi-protocol label switching connection request packet to the second device,

[0168] wherein to send the multi-protocol label switching connection request packet to the respective device of the one or more devices, the one or more processors are further configured to send the second multi-protocol label switching connection request packet to the second device,

[0169] wherein to receive the multi-protocol label switching connection response packet verifying the connection of the respective device of the segment routing label switching path, the one or more processors are further configured to receive a second multi-protocol label switching connection response packet verifying the connection of the second device of the segment routing label switching path, and

[0170] wherein to update the forwarding equivalence class stack, the one or more processors are further configured to update the updated forwarding equivalence class stack by removing the outermost forwarding equivalence class of the updated forwarding equivalence class stack that identifies the second device.

[0171] (20) The non-transitory computer-readable medium of any of (16) to (19),

[0172] wherein the multi-protocol label switching connection request packet comprises a multi-protocol label switching echo request packet, and

[0173] wherein the multi-protocol label switching connection response packet comprises a multi-protocol label switching echo reply packet.

Claims

1. A method for segmented routing label-switched paths, comprising: A device on the segmented routing label switching path receives a connection request message originating from an ingress device on the segmented routing label switching path. The connection request message includes a forwarding equivalence class stack specifying the stack of segmented routing labels of the segmented routing label switching path. The forwarding equivalence class stack also includes information identifying one or more devices that operate as segmented endpoints along the segmented routing label switching path. The device determines whether the outermost forwarding equivalence class of the forwarding equivalence class stack recognizes the device; and The device is identified based on the outermost forwarding equivalence class of the forwarding equivalence class stack, and the device sends a connection response message to the ingress device of the segmented routing label switching path, wherein the connection response message confirms the connection of the device for the segmented routing label switching path.

2. The method according to claim 1, wherein, The connection response message includes a Multiprotocol Label Switching (MPLS) connection request message.

3. The method according to claim 1, wherein, The connection request message also includes a segmented routing label stack, which specifies the labels of the one or more devices that operate as segmented endpoints along the segmented routing label exchange path.

4. The method according to claim 3, wherein, The connection request message also includes the time-to-live (TTL) values ​​of the tags of the one or more devices, which operate as segment endpoints along the segmented route label switching path.

5. The method according to claim 1, wherein, The segmented routing label switching path includes inter-domain segmented routing label switching paths.

6. The method according to claim 1, wherein, The segmented routing label exchange path includes the segmented routing label exchange path between autonomous systems.

7. The method according to any one of claims 1 to 6, wherein, The connection request message includes a first connection request message, the first connection request message including information identifying one or more first devices, the one or more first devices operating as segment endpoints along a first segmented routing label switching path, the method further including: The device receives a second connection request message originating from the ingress device. The second connection request message includes a second forwarding equivalence class stack, which specifies a stack of second segmented routing labels for a second segmented routing label switching path. The second forwarding equivalence class stack also includes information identifying one or more devices that operate as segment endpoints along the second segmented routing label switching path. The device determines whether the outermost forwarding equivalence class of the second forwarding equivalence class stack recognizes the device; and Based on the determination that the outermost forwarding equivalence class of the second forwarding equivalence class stack does not recognize the device, the device forwards the second connection response message to the next device in the second segmented routing label switching path.

8. The method according to any one of claims 1 to 6, further comprising: in, Determining whether the outermost forwarding equivalence class of the forwarding equivalence class stack recognizes the device includes: in response to determining that the connection request message includes a routing warning object in the IP options field, determining whether the outermost forwarding equivalence class of the forwarding equivalence class stack recognizes the device.

9. A device for segmented routing label-switched paths, comprising: One or more processors operatively coupled to memory, wherein the one or more processors are configured to: Receive a connection request message originating from an ingress device of the segmented routing label switching path. The connection request message includes a forwarding equivalence class stack specifying the segmented routing label stack of the segmented routing label switching path. The forwarding equivalence class stack also includes information identifying one or more devices that operate as segmented endpoints along the segmented routing label switching path. Determine whether the outermost forwarding equivalence class of the forwarding equivalence class stack recognizes the device; and Based on the outermost forwarding equivalence class of the forwarding equivalence class stack, the device is identified, and a connection response message is sent to the ingress device of the segmented routing label switching path, wherein the connection response message confirms the device's connection to the segmented routing label switching path.

10. The device according to claim 9, wherein, The connection response message includes a Multiprotocol Label Switching (MPLS) connection request message.

11. The device according to claim 9, wherein, The connection request message also includes a segmented routing label stack, which specifies the labels of the one or more devices that operate as segmented endpoints along the segmented routing label exchange path.

12. The device according to claim 11, wherein, The connection request message also includes the time-to-live (TTL) values ​​of the tags of the one or more devices, which operate as segment endpoints along the segmented route label switching path.

13. The device according to claim 9, wherein, The segmented routing label switching path includes inter-domain segmented routing label switching paths.

14. The device according to claim 9, wherein, The segmented routing label exchange path includes the segmented routing label exchange path between autonomous systems.

15. The device according to any one of claims 9 to 14, wherein, The connection request message includes a first connection request message, which includes information identifying one or more first devices operating as segment endpoints along a first segmented routing label switching path, wherein the one or more processors are further configured to: Receive a second connection request message originating from the ingress device. The second connection request message includes a second forwarding equivalence class stack, which specifies a stack of second segmented routing labels for a second segmented routing label switching path. The second forwarding equivalence class stack also includes information identifying one or more devices that operate as segmented endpoints along the second segmented routing label switching path. Determine whether the outermost forwarding equivalence class of the second forwarding equivalence class stack recognizes the device; and Based on the determination that the outermost forwarding equivalence class of the second forwarding equivalence class stack does not recognize the device, the second connection response message is forwarded to the next device in the second segmented routing label-switched path.

16. The device according to any one of claims 9 to 14, wherein, To determine whether the outermost forwarding equivalence class of the forwarding equivalence class stack recognizes the device, the one or more processors are further configured to: In response to determining that the connection request message includes a routing warning object in the IP options field, determine whether the outermost forwarding equivalence class of the forwarding equivalence class stack recognizes the device.

17. A non-transitory computer-readable medium comprising instructions for causing one or more programmable processors of a device to perform the following operations: Receive a connection request message originating from the ingress device of the segmented route label switching path, the connection request message including a forwarding equivalence class stack specifying the segmented route label stack of the segmented route label switching path, wherein, The forwarding equivalence class stack also includes information identifying one or more devices that operate as segment endpoints along the segmented routing label-switched path; Determine whether the outermost forwarding equivalence class of the forwarding equivalence class stack recognizes the device; as well as The device is identified based on the outermost forwarding equivalence class of the forwarding equivalence class stack, and the ingress device of the segmented routing label switching path sends a connection response message, wherein the connection response message confirms the device's connection to the segmented routing label switching path.

Images