Intra-domain source address verification fast reroute handover using multicast signalling

Abstract

A method implemented by a network node in an Interior Gateway Protocol (IGP) domain. The method comprises: sending a first message to a second network node in the IGP domain, the first message identifying a backup path to be used by the network node when a fault in the IGP domain is detected; detecting the fault after sending the first message to the second network node; and upon detecting the failure, sending a multicast packet to the second network node, where the multicast packet notifies the second network node to use a backup port in a Source Address Verification (SAV) table to verify a packet received on the backup path.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 359,751, filed on July 8, 2022 by Futurewei Technologies, Inc., and entitled “Intra-Domain Source Address Validation Fast Reroute Switchover Signaled Using Multicast,” which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to communications using the Internet Protocol (IP), and more particularly to source address verification in IP networks with fast rerouting. Background Art

[0004] IP is a network layer communications protocol in the Internet Protocol suite that is used to relay datagrams across network boundaries. The routing function of IP enables network interconnection and essentially builds the Internet.

[0005] The task of IP is to deliver data packets from a source host to a destination host based solely on the IP address in the packet header. To do this, IP defines a packet structure that encapsulates the data to be delivered. IP also defines an addressing method for marking datagrams with source and destination information.

[0006] Source address validation (SAV) is a standard formalized in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2827, entitled "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", published by P. Ferguson et al. in May 2000. The standard aims to discard packets with spoofed source IP addresses. The lack of SAV is considered to be the root cause of reflected distributed denial-of-service (DDoS) attacks. Summary of the invention

[0007] The disclosed aspects / embodiments provide techniques for signaling a backup path to be used by a network node when a failure in an interior gateway protocol (IGP) domain is detected, and for notifying a second network node to use a backup port in a source address validation (SAV) table to validate packets received on the backup path. These techniques use existing IGPs (e.g., Open Shortest Path First (OSPF) or Intermediate System-Intermediate System (IS-IS)), in some cases, to implement source address validation (SAV) by simply extending or appending shortest path first (SPF) calculations and multicast packets carrying a switch indicator. By implementing SAV using the disclosed techniques, source address validation can be implemented during a fast reroute switch.

[0008] A first aspect relates to a method implemented by a network node in an interior gateway protocol (IGP) domain, comprising: sending a first message to a second network node in the IGP domain, wherein the first message identifies a backup path to be used by the network node when a failure in the IGP domain is detected; detecting the failure after sending the first message to the second network node; and after detecting the failure, sending a multicast data packet to the second network node, wherein the multicast data packet notifies the second network node to use a backup port in a source address validation (SAV) table to validate data packets received on the backup path.

[0009] Optionally, in any of the above aspects, another implementation of the aspect provides that the SAV table is constructed based only on the IGP without any additional protocol.

[0010] Optionally, in any of the above aspects, another implementation of the aspect provides that the multicast data packet includes a destination field including a multicast address and a payload including a switching indicator.

[0011] Optionally, in any of the above aspects, another implementation of the aspect provides that the switching indicator includes a predefined bit pattern.

[0012] Optionally, in any of the above aspects, another implementation of the aspect provides that the first message includes a source prefix field and a next hop field, wherein the source prefix field includes a value identifying the network node, and the next hop field includes a value identifying the next hop of the network node on the backup path.

[0013] Optionally, in any one of the above aspects, another implementation of the aspect provides that the first message includes a type field, and a value in the type field indicates that the first message includes the backup path.

[0014] Optionally, in any one of the above aspects, another implementation of the aspect provides that the source prefix field, the next hop field and the type field are included in a subtype length value (type length value, TLV).

[0015] Optionally, in any of the above aspects, another implementation of the aspect provides that the sub-TLV is included in an Open Shortest Path First version 2 (OSPFv2) TLV or an Open Shortest Path First version 3 (OSPFv3) TLV.

[0016] Optionally, in any of the above aspects, another implementation of the aspect provides that the OSPFv2 TLV or the OSPFv3 TLV includes an address prefix field, and the address prefix field includes a value identifying the second network node or the destination node.

[0017] Optionally, in any one of the above aspects, another implementation method of the aspect provides that the first message includes an IGP update message, and the IGP update message includes a link state update (linkstate update, LSU) corresponding to the OSPF protocol or a protocol data unit (protocol data unit, PDU) corresponding to the IS-IS protocol, and the PDU is called a link state PDU (link state PDU, LSP).

[0018] Optionally, in any of the above aspects, another implementation of the aspect provides sending a data packet on the backup path after detecting the failure.

[0019] A second aspect relates to a method implemented by a network node in an interior gateway protocol (IGP) domain, comprising: receiving a first message from a second network node in the IGP domain, wherein the first message identifies a backup path to be used by the second network node when a failure in the IGP domain is detected; updating a source address validation (SAV) table to include a backup port corresponding to the backup path; and receiving a multicast packet from the second network node, wherein the multicast packet notifies the network node to use the backup port in the SAV table to validate packets received on the backup path.

[0020] Optionally, in any of the above aspects, another implementation of the aspect provides that the multicast data packet includes a destination field including a multicast address and a payload including a switching indicator.

[0021] Optionally, in any of the above aspects, another implementation of the aspect provides that the switching indicator includes a predefined bit pattern.

[0022] Optionally, in any of the above aspects, another implementation of the aspect provides performing a shortest path first (SPF) calculation using a zero value of a metric between the second network node and the next hop of the second network node on the backup path to update the SAV table.

[0023] Optionally, in any of the above aspects, another implementation of the aspect provides performing an initial SPF calculation to generate a forwarding information base (FIB) table, wherein the initial SPF calculation is performed before the SPF calculation.

[0024] Optionally, in any one of the above aspects, another implementation of the aspect provides that the SAV table includes a backup port column identifying the backup port.

[0025] Optionally, in any of the above aspects, another implementation of the aspect provides that the first message includes a source prefix field and a next hop field, wherein the source prefix field includes a value identifying the second network node, and the next hop field includes a value identifying the next hop of the second network node on the backup path.

[0026] Optionally, in any one of the above aspects, another implementation of the aspect provides that the first message includes a type field, and a value in the type field indicates that the first message includes the backup path.

[0027] Optionally, in any one of the above aspects, another implementation of the aspect provides that the source prefix field, the next hop field and the type field are included in a subtype length value (type length value, TLV).

[0028] Optionally, in any of the above aspects, another implementation of the aspect provides that the sub-TLV is included in an Open Shortest Path First version 2 (OSPFv2) TLV, an Open Shortest Path First version 3 (OSPFv3) TLV, an extended Internet Protocol version 4 (IPv4) reachability TLV, a multi-topology IPv4 reachability TLV, an Internet Protocol version 6 (IPv6) reachability TLV or a multi-topology IPv6 reachability TLV.

[0029] Optionally, in any of the above aspects, another implementation of the aspect provides that the OSPFv2 TLV or the OSPFv3 TLV includes an address prefix field, and wherein the address prefix field includes a value identifying the network node or the destination node.

[0030] Optionally, in any of the above aspects, another implementation of the aspect provides receiving a data packet; using the SAV table to verify that the data packet is received on the backup port corresponding to the second network node; and using a forwarding information base (FIB) table to send the data packet from an egress port corresponding to a destination address.

[0031] Optionally, in any of the above aspects, another implementation of the aspect provides receiving a data packet; using the SAV table to determine that the data packet is not received on the backup port corresponding to the second network node; and discarding the data packet or sending the data packet somewhere for further inspection.

[0032] A third aspect relates to a network node in an interior gateway protocol (IGP) domain, comprising: a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions so that the network node executes the method described in any one of the disclosed embodiments.

[0033] A fourth aspect relates to a non-transitory computer-readable medium, comprising a computer program product used by a network node, wherein the computer program product comprises computer executable instructions stored on the non-transitory computer-readable medium, and when the computer executable instructions are executed by one or more processors, the network node executes the method described in any of the disclosed embodiments.

[0034] A fifth aspect relates to a network node in an interior gateway protocol (IGP) domain, comprising a device for executing the method described in any one of the disclosed embodiments.

[0035] For the sake of clarity, any of the above-described embodiments may be combined with any one or more of the other embodiments described above to create new embodiments within the scope of the present disclosure.

[0036] These and other features will become more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] For a more complete understanding of the present disclosure, reference is now made to the following brief description taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0038] Figure 1 It is a schematic diagram of the network topology including the Interior Gateway Protocol (IGP) domain.

[0039] Figure 2 is a schematic diagram of a network topology including an IGP domain.

[0040] Figure 3 is a diagram of the distributed source address validation (DSAV) workflow.

[0041] Figure 4It is a schematic diagram of the loop-free alternate (LFA) fast reroute (FRR) process.

[0042] Figure 5 It is a schematic diagram of the long-range LFA FRR process.

[0043] Figure 6 is a diagram of a SAV table constructed to accommodate an LFA FRR flow and a remote LFA FRR flow according to an embodiment of the present disclosure.

[0044] Figure 7 is an OSPFv2 extended prefix TLV according to an embodiment of the present disclosure.

[0045] Figure 8 is a sub-TLV used for prefix level encoding according to an embodiment of the present disclosure.

[0046] Fig. 9 is a sub-TLV used for prefix level encoding according to an embodiment of the present disclosure.

[0047] Fig.10 is a diagram of a data packet configured to notify a network node to implement a switch and validate a data packet received on a backup path using a backup port in a source address validation (SAV) table.

[0048] Fig.11 The invention is a method implemented by a network node in an IGP domain according to an embodiment of the present disclosure.

[0049] Fig.12 The invention is a method implemented by a network node in an IGP domain according to an embodiment of the present disclosure.

[0050] Fig.13 is a schematic diagram of a network device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0051] First, it should be understood that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods can be implemented using any number of techniques, whether currently known or existing. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques described below, including the exemplary designs and implementations illustrated and described herein, but can be modified within the scope of the appended claims and their full scope of equivalents.

[0052] An IP data packet (or simply a data packet) has a source address and a destination address. As mentioned above, IP source address spoofing is the practice of maliciously sending data packets with forged or incorrect source addresses.

[0053] Mutually Agreed Norms for Routing Security (MANRS) is a global initiative that helps reduce the most common routing threats. MANRS provides network operators with a set of best practices based on existing specifications to improve the security of the global Internet routing system. One of the best practices is related to anti-spoofing, and the goal is to implement source address validation (SAV) and implement anti-spoofing to prevent packets with incorrect source IP addresses from entering and leaving the network.

[0054] SAV is a long-standing concern of the Internet Engineering Task Force (IETF). Many IETF documents describe anti-spoofing techniques. In May 2000, P. Ferguson et al. published the Best Current Practice (BCP) 38 / Internet Engineering Task Force (IETF) Request for Comments (RFC) 2827 entitled "Network Ingress Filtering: Defeating Denial of Service Attached which employ IP Source Address Spoofing", which discloses a technique for preventing IP packets with source IP addresses forged at the edge of the Internet from entering the Internet.

[0055] IETF RFC 6959, entitled "Source Address Validation Improvement (SAVI) Threat Scope," published by D. McPherson et al. in May 2013, discloses techniques and existing solutions for threats based on source address spoofing.

[0056] IETF RFC 2267, entitled "Network Ingress Filtering: Defeating Denial of Service Attached which employ IP Source Address Spoofing", published by P. Ferguson et al. in January 1998, discloses techniques for ingress filtering and access control list (ACL)-based SAV together with RFC 2827. One problem with these techniques is that they require manual configuration of network devices.

[0057] IETF RFC 3704, entitled "Ingress Filtering for Multihomed Networks", published by F. Baker et al. in March 2004, discloses strict unicast reverse path forwarding (strict uRPF) and feasible uRPF. One problem with these techniques is that they will inappropriately block packets when there is asymmetric routing, and in some cases, they will inappropriately allow packets to be routed.

[0058] E. Nordmark et al., IETF RFC 6620, entitled “FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses”, May 2012; M. Pritikin et al., IETF RFC 7030, entitled “Enrollment over Secure Transport”, October 2013; J. Wu et al., IETF RFC 7039, entitled “Source Address Validation Improvement (SAVI) Framework”, October 2013; M. Bagnulo et al., IETF RFC 7040, entitled “SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) Framework”, May 2014. The following are IETF RFC 7219 entitled “Source Address Validation Improvement (SAVI) Framework” by J. Wu et al. in October 2013; IETF RFC 7513 entitled “Source Address Validation Improvement (SAVI) Framework” by J. Wu et al. in October 2013; IETF RFC 8074 entitled “Source Address Validation Improvement (SAVI) Solution for DHCP” by J. Bi et al. in May 2015; and IETF RFC 8074 entitled “Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario” by J. Bi et al. in February 2017, which together with RFC 6959 disclose technologies for source address validation improvement. One problem with these techniques is how they handle host-level SAV in the access network (enterprise network).

[0059] IETF RFC 6620, entitled "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses," published by E. Nordmark et al. in May 2012, discloses an enhanced feasible path (EFP) that alleviates the problems associated with strict uRPF / feasible uRPF in some cases.

[0060] Figure 1 1 is a schematic diagram of a network topology 100 including an Interior Gateway Protocol (IGP) domain 102. The IGP domain 102 includes a plurality of network nodes 104, 106, 108, 110, 112, 114, and 116. Although seven network nodes 104 to 116 are shown in the IGP domain 102, more or fewer network nodes may be included in actual applications. In one embodiment, the network nodes 104 to 116 include routers, switches, or other network devices capable of routing data packets through the IGP domain 102.

[0061] Some of the network nodes (e.g., network nodes 104, 114) are arranged at the edge of the IGP domain 102. The network nodes 104, 114 that receive data packets from outside the IGP domain 102 may be referred to as ingress network nodes. The network nodes 104, 114 that send data packets out of the IGP domain 102 may be referred to as egress network nodes. Depending on the direction of multicast data packet traffic, any one of the network nodes 104, 114 may be used as an ingress network node or an egress network node. Although not shown, the network nodes arranged at the edge of the IGP domain 102 may be coupled with nodes arranged outside the IGP domain 102. The network nodes (e.g., network nodes 108, 110, 116) that are not arranged at the edge of the IGP domain 102 may be referred to as intermediate network nodes, internal network nodes, or transit nodes.

[0062] The network nodes 104 to 116 are coupled to each other via links 118. Links 118 may be wired, wireless, or some combination thereof. As discussed more fully below, the cost of each of the links 118 is based, for example, on the length bandwidth. Links 118 also couple each of the network nodes 104 to 116 to another subnet. Figure 1The subnets in are labeled as subnet 1 (p1), subnet 2 (p2), subnet 2 (p2), subnet 3 (p3), subnet 4 (p4), subnet 5 (p5), subnet 6 (p6), and subnet 7 (p7).

[0063] Figure 1 It is shown that applying strict uRPF only at the subnet port in the intra-domain SAV can cause inappropriate permission problems. When all network devices 104 to 116 are deployed identically (e.g., deploying strict uRPF policies), there is no problem. However, when only some of the network devices (e.g., network devices 104, 106, 110 and 116 in the deployment area 130) apply strict uRPF policies at their subnet ports, deception may still occur. For example, when network device 108 (also referred to as router 3) sends a data packet to network device 116 by deceiving the source address of subnet 1 associated with network device 104, by deceiving the source address of subnet 2 associated with network device 106, or by deceiving the source address of subnet 4 associated with network device 110 (as shown by the dotted arrow), network device 116 will inappropriately allow the data packet. Therefore, the subnet outside the deployment area 130 can deceive the address of the subnet in the deployment area 130.

[0064] Figure 2 2 is a schematic diagram of a network topology 200 including an IGP domain 102. The IGP domain 102 includes a plurality of network nodes 104, 106, 108, 110, 112, 114, and 116. Although seven network nodes 104 to 116 are shown in the IGP domain 102, more or fewer network nodes may be included in actual applications. In one embodiment, the network nodes 104 to 116 include routers, switches, or other network devices capable of routing data packets through the IGP domain 102.

[0065] The network nodes 104 to 116 are coupled to each other via links 118. Links 118 may be wired, wireless, or some combination thereof. As discussed more fully below, the cost of each of the links 118 is based, for example, on the length bandwidth. Links 118 also couple each of the network nodes 104 to 116 to another subnet. Figure 2 The subnets in are labeled as subnet 1 (p1), subnet 2 (p2), subnet 2 (p2), subnet 3 (p3), subnet 4 (p4), subnet 5 (p5), subnet 6 (p6) and subnet 7 (p7). As shown in the figure, some of the network devices (for example, network devices 104, 106, 110 and 116) are set in the deployment area 130.

[0066] exist Figure 2, in intra-domain SAV, network device 116 applies strict uRPF at all subnet ports. However, this can lead to inappropriate blocking issues when asymmetric routing exists. Asymmetric routing occurs when the paths between network nodes are not the same in both directions. For example, assume that the routing path from network node 116 to network node 114 is: network node 116 → network node 112 → network node 114; and the routing path from network node 114 to network node 116 is: network node 114 → network node 108 → network node 116. In this case, when network device 114 sends valid packets to network device 116, network device 116 inappropriately blocks these packets (as shown by the dotted arrows).

[0067] When all network devices 104 to 116 are deployed identically (e.g., deploying a strict uRPF policy), there is no problem. However, when only some of the network devices (e.g., network devices 104, 106, 110, and 116 within deployment area 130) apply a strict uRPF policy at their subnet ports, spoofing may still occur. For example, when network device 108 (also referred to as router 3) sends a packet to network device 116 by spoofing the source address of subnet 1 associated with network device 104, by spoofing the source address of subnet 2 associated with network device 106, or by spoofing the source address of subnet 4 associated with network device 110 (as shown by the dotted arrow), network device 116 will inappropriately allow the packet. Therefore, a subnet outside of deployment area 130 is able to spoof the address of a subnet within deployment area 130.

[0068] One of the existing solutions that attempts to address the spoofing problem is called distributed source address validation (DSAV). DASV is discussed in detail in the IETF document (draft-li-dsav-framework-01) titled "Distributed Source Address Validation (DSAV) Framework" published by D. Li et al. on January 11, 2022. In DASV, the source address is verified using the SAV table generated by the distributed control plane protocol. That is, the DSAV framework generates an accurate SAV table based on the distributed control plane protocol instead of using uRPF. DSAV provides periodic or triggered updates (when routing information changes) to distribute SAV rules to network nodes.

[0069] Figure 3300 is a diagram of a distributed source address validation (DSAV) workflow. In the example shown, various network nodes, labeled Router 1 through Router 7, are coupled together via links. Each of the network nodes is coupled to a corresponding subnet, labeled Subnet 1 through Subnet 7. Figure 3 The network nodes, links, and subnets depicted in Figure 1 to Figure 2 For the sake of brevity, detailed descriptions of these elements are not repeated herein.

[0070] The following describes the process of prefix notification from the perspective of router 1 and subnet 1 (p1). As shown in the figure, p1 is the source prefix of router 1. Therefore, router 1 initiates the message. Router 1 stores or accesses a forwarding information base (FIB) table 302. The FIB table 302 includes the destination prefix and the corresponding next hop for each other subnet associated with the network node in the network. The FIB table 302 indicates that for destination prefixes p2, p4, p6, and p7, the next hop is router 2 (i.e., node 2). Therefore, router 1 generates a notification message and sends the notification message to router 2. The notification message includes the source prefix (e.g., p1) and the propagation range (e.g., p2, p4, p6, p7).

[0071] Still refer to Figure 3 , router 1 uses the DSAV process to build SAV table 304. Router 1 then uses SAV table 304 to verify the source of the incoming or received data packet. For example, router 1 checks to see if the data packet received at the ingress port listed in SAV table 304 has a corresponding prefix listed in SAV table 304. If the data packet does not have a corresponding prefix, router 1 determines that the data packet may have a spoofed address and discards the data packet. If the data packet has a corresponding prefix, router 1 sends the data packet from the egress port in FIB table 306 (a general representation of FIB table 302) that corresponds to the destination prefix in the data packet.

[0072] Although Figure 3 The DSAV framework depicted in can solve some of the spoofing problems, but there are still disadvantages. For example, the DSAV framework uses a completely new protocol to generate the SAV table 304. In addition, the DSAV framework makes it difficult to achieve full deployment and increases a large amount of control plane traffic and state. In addition, the DSAV framework relies on reactive convergence. That is, when a network failure occurs (e.g., a network node or link failure), forwarding can only start working after SAV converges.

[0073] Figure 44 is a schematic diagram of a loop-free alternate (LFA) fast reroute (FRR) process. In the example shown, various network nodes labeled routers A, C, D, and E are coupled together via links 418. Figure 4 The network nodes and links depicted in Figure 1 to Figure 2 For the sake of brevity, detailed descriptions of these elements will not be repeated herein.

[0074] exist Figure 4 In the example, network nodes A, C, D, and E are set in an Interior Gateway Protocol (IGP) domain. Therefore, network nodes (e.g., routers) route IP packets (or simply packets) in the IGP domain of the IP network using Open Shortest Path First (OSPF) or Intermediate System–Intermediate System (IS-IS).

[0075] OSPF uses a link state routing (LSR) algorithm and falls into the group of interior gateway protocols (IGPs) that run within a single autonomous system (AS). OSPF collects link state information from available routers and builds a topology map of the network. The topology is presented to the Internet layer in the form of a routing table, which is used to route packets according to their destination IP address. OSPF supports Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) networks. OSPF Version 2 (OSPFv2) was defined for IPv4 in RFC 2328, entitled "OSPF Version 2", published by J. Moy et al. in April 1998. OSPF Version 3 (OSPFv3) was defined for IPv6 in RFC 5340, entitled "OSPF Version 3", published by R. Coltun et al. in July 2008. OSPF is widely used in large enterprise networks.

[0076] Intermediate System to Intermediate System (IS-IS or ISIS) is a link-state routing protocol. IS-IS operates by flooding link-state information throughout a network of routers. Each IS-IS router independently builds a network topology database, aggregating the flooded network information. Similar to the OSPF protocol, IS-IS calculates the best path through the network. The packet (or datagram) is then forwarded through the network to the destination based on the calculated ideal path.

[0077] Intermediate System to Intermediate System (IS-IS or ISIS) is another LSR routing protocol designed to efficiently move information in a computer network, a group of physically connected computers or similar devices. IS-IS does this by determining the best route for data through a packet-switched network. The IS-IS protocol is defined in RFC 1142, entitled "OSI IS-IS Intra-domain Routing Protocol", published by D. Oran in February 1990. IS-IS is common in large service provider networks.

[0078] exist Figure 4 , each link in the links 418 has a metric. For example, the link 418 between router A and router C has a metric of 15, and the link 418 between router C and router E has a metric of 15. The link 418 between router A and router D has a metric of 10, and the link 418 between router D and router E has a metric of 10.

[0079] Router A performs an SPF calculation based on Figure 4 The metrics shown determine that the lowest cost path from router A to router E is through router D. Therefore, router A normally sends packets to router E via the primary path of router A→router D→router E. However, router A has detected or been informed of a failure in the IGP domain. For example, the failure may be a failure of link 418 between router A and router D or a failure of router D. Due to the failure, router A is no longer able to send packets to router E via the primary path. Therefore, router A performs the LFAFRR process.

[0080] LFA-FRR allows a router (for example, Router A) to quickly switch from the primary path to the backup path when the primary path fails until the network reconverges. Figure 4As shown, the backup path includes router A→router C→router E. The switch can occur, for example, within about 50 milliseconds (50ms). More detailed information about LFA-FRR is disclosed in IETF RFC 5286, entitled "Basic Specification for IP Fast Reroute: Loop-Free Alternates" published by A. Atlas et al. in September 2008.

[0081] Router A uses IGP to pre-calculate the backup path. That is, Router A calculates the backup path before detecting a failure. Figure 4 As shown, the next hop of Router A on the backup path is Router C. When the backup path is calculated, the next hop of Router A is installed in the FIB of Router A. Therefore, when Router A implements the backup path, the data packet is sent to Router C (as shown by the arrow) instead of Router D.

[0082] Unfortunately, Router E may not know that Router A has a backup path, has begun using the backup path, or both. Therefore, when Router E receives packets from Router A, Router E attempts to validate the packets using the SAV table on Router E. However, the SAV table indicates that packets from Router A are expected to be received on the port (also called interface) corresponding to Router D (not Router C). Therefore, Router E cannot validate the packets and the packets are discarded, even though the packets are valid and not spoofed.

[0083] Figure 5 5 is a schematic diagram of a remote LFAFRR process. In the example shown, various network nodes labeled routers A, B, C, D, and E are coupled together by links 518. Figure 5 The network nodes and links depicted in Figure 1 to Figure 2 For the sake of brevity, detailed descriptions of these elements will not be repeated herein.

[0084] exist Figure 5 In the example, network nodes A, B, C, D, and E are arranged in an IGP domain. Therefore, network nodes (eg, routers) route IP data packets (or simply referred to as data packets) in the IGP domain of the IP network using OSPF or IS-IS.

[0085] exist Figure 5, each link in the links 518 has a metric. For example, the link 518 between router A and router B has a metric of 10, the link 518 between router B and router C has a metric of 10, and the link 518 between router C and router E has a metric of 10. The link 518 between router A and router D has a metric of 5, and the link 518 between router D and router E has a metric of 10.

[0086] Router A performs an SPF calculation based on Figure 5 The metrics shown determine that the lowest cost path from router A to router E is through router D. Therefore, router A normally sends packets to router E via the primary path of router A→router D→router E. However, router A has detected or been informed of a failure in the IGP domain. For example, the failure may be a failure of link 518 between router A and router D or a failure of router D. Due to the failure, router A is no longer able to send packets to router E via the primary path. Therefore, router A performs the LFAFRR process.

[0087] Remote LFA-FRR allows a router (e.g., Router A) to quickly switch from a primary path to a backup path when the primary path fails until the network reconverges. Remote LFA-FRR allows the backup path to be more than one hop away from the router (e.g., Router A) that computes the backup path. Figure 5 As shown, the backup path includes router A→router B→router C→router E. More detailed information about remote LFA-FRR is disclosed in IETF RFC 7490, entitled "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)," published by S. Bryant et al. in September 2008.

[0088] Router A uses IGP to pre-calculate the backup path. That is, Router A calculates the backup path before detecting the failure. When the failure is detected and Router A switches to the backup path, if Router A attempts to send a packet to Router E using Router B as the next hop, Router B sends the packet back to Router A based on the FIB on Router B. That is, Router B loops the traffic back to Router A (as indicated by the small arrow). Therefore, in Remote LFA FRR, Router B is not used as the next hop. Instead, Router A tunnels the traffic to Router C to bypass the loop.

[0089] Therefore, the next hop of Router A on the backup path is Router C. When the backup path is calculated, the next hop of Router A is installed in the FIB of Router A. When Router A implements the backup path, the packet is sent to Router C (as shown by the arrow) instead of Router D or Router B.

[0090] Unfortunately, Router E may not know that Router A has a backup path, has begun using the backup path, or both. Therefore, when Router E receives packets from Router A, Router E attempts to validate the packets using the SAV table on Router E. However, the SAV table indicates that packets from Router A are expected to be received on the port (also called interface) corresponding to Router D (not Router C). Therefore, Router E cannot validate the packets and the packets are discarded, even though the packets are valid and not spoofed.

[0091] Disclosed herein are techniques for signaling a backup path to be used by a network node when a failure in an interior gateway protocol (IGP) domain is detected, and for notifying a second network node to use a backup port in a source address validation (SAV) table to validate packets received on the backup path. These techniques use existing IGPs (e.g., Open Shortest Path First (OSPF) or Intermediate System-Intermediate System (IS-IS)), in some cases, by simply extending or appending a shortest path first (SPF) calculation and a multicast packet carrying a switch indicator to implement source address validation (SAV). By implementing SAV using the disclosed techniques, source address validation can be implemented during a fast reroute switch.

[0092] Figure 6 is a diagram of a SAV table 600 constructed to accommodate the LFAFRR process and the remote LFA FRR process according to an embodiment of the present disclosure. An example of how the SAV table 600 is constructed from the perspective of router E is provided. It is worth noting that other routers in the domain can similarly use the same process to construct their own SAV tables.

[0093] First, router E receives link state advertisements from one or more of the other network nodes in the IGP domain. That is, router E receives link state advertisements from router A, router B, router C, and / or router D. In one embodiment, the link state advertisement is a link state update (LSU) corresponding to the OSPF protocol. In one embodiment, the link state advertisement is a protocol data unit (PDU) corresponding to the IS-IS protocol, called a link state PDU (LSP).

[0094] Router E performs a shortest path first (SPF) calculation based on the link state advertisements received from other network nodes. Thereafter, router E constructs a forwarding information base (FIB) table (not shown) based on the SPF calculation.

[0095] In one embodiment, router E uses information from link state advertisements and / or FIB to construct SAV table 600. As shown, SAV table 600 includes an entry corresponding to router A in the first row of the source prefix column (e.g., Prefix A), and includes an entry corresponding to router D in the ingress port column (e.g., Eth 1 / 0 (to D)). These entries ensure that packets received from router D are determined to be valid.

[0096] In one embodiment, the ingress port column in the SAV table 600 is associated with a specific destination (or destination group). For example, packet traffic destined for destination 192.168.1.0 / 24 is expected to be routed from router A to router D, and thus enter router E through router D. Because the SAV table 600 identifies a separate destination (or destination prefix) for each ingress port, the SAV table 600 may be referred to as a SAV table for prefix-level encoding.

[0097] In one embodiment, the SAV table 600 includes a backup port column. In one embodiment, when the SAV table 600 is generated, the backup port column is initially empty (i.e., does not include entries). When the router listed in the source prefix column uses the backup path, any entry in the backup port column identifies the port that will receive the data packet. The entry in the backup port column ensures that when the network node listed in the source prefix column is using the backup path, the data packet received from the router C is determined to be valid.

[0098] Although Figure 6The SAV table 600 in FIG. 6 depicts only a single row, but in actual applications, the SAV table 600 may include multiple rows. In practice, the SAV table 600 may include one or more rows corresponding to each network node in the IGP domain. For example, the SAV table 600 may include a first row corresponding to prefix A of router A, a second row corresponding to prefix B of router B, a third row corresponding to prefix C of router C, and so on.

[0099] After SAV table 600 has been generated, router E receives a first update message from router A. In one embodiment, the first update message identifies a backup path to be used by router A upon detecting a failure in the IGP domain. As will be explained more fully below, the first update message identifies a destination for a data packet, a source for the data packet, and a next hop for the source of the data packet.

[0100] In one embodiment, router E performs an SPF calculation using a zero value for the metric between the source (e.g., router A) and the next hop of the source (e.g., router B) to update the SAV table 600. Based on the SPF calculation and / or the backup path in the first message, router E is able to determine that the data packet received from router C is valid when router A is using the backup path. Router E then updates the SAV table 600 to include a backup port corresponding to the backup path (i.e., Eth 1 / 1 (to C)).

[0101] In one embodiment, router E updates the SAV table by inserting an entry for the backup port into an initially empty or unpopulated row of the backup port column. In one embodiment, router E updates SAV table 600 by replacing an existing entry in the backup port column with the backup port identified in the first update message. In one embodiment, router E updates SAV table 600 by first adding the backup port column to SAV table 600 and then inserting the entry for the backup port into the row of the backup port column.

[0102] Although the SAV table 600 has been constructed on the router E, the router E does not know when another router (e.g., router A) detects a failure and starts using the backup path. That is, before being notified, the router E does not know that the router A is using the backup path. Therefore, when the router A is using the backup path, the router E will not use the entry in the backup port column, but will use the entry in the ingress port column of the SAV table 600, resulting in valid data packets being discarded by the router E.

[0103] In order to inform router E that router A has detected a failure and has switched to the backup path, router A sends a multicast packet (also referred to as a multicast packet or a packet) with a special payload to router E. The packet informs router E to use the backup port in the SAV table to verify the data packets received on the backup path. In other words, the packet informs router E to switch from using the entries in the ingress port column in the SAV table 600 to verify the data packets.

[0104] Figure 7 is an OSPFv2 extended prefix TLV 700 according to an embodiment of the present disclosure. The OSPFv2 extended prefix TLV 1000 is described in detail in IETF RFC 7684, entitled "OSPFv2 Prefix / Link Attribute Advertisement", published by P. Psenak et al., November 2015.

[0105] As shown, OSPFv2 extended prefix TLV 700 includes an address prefix field 702 and a sub-TLV field 704. Address prefix field 702 includes a value indicating a destination prefix (or destination) that the receiving router will use when building a SAV table. For example, address prefix field 702 includes a value indicating a destination prefix, such as, Figure 6 The destination prefix 192.168.1.0 / 24 in FIG. 7 is a string containing a plurality of sub-TLVs. In one embodiment, the address prefix field 702 has a variable length. The sub-TLV field 704 is configured to carry one or more sub-TLVs, as will be explained more fully below.

[0106] Figure 8 is a sub-TLV 800 for prefix level encoding according to an embodiment of the present disclosure. The sub-TLV 800 is configured to include Figure 7 In one embodiment, a network node (eg, router A) uses sub-TLV 800 to advertise a backup path to be used after a failure in the IGP domain is detected.

[0107] As shown, sub-TLV 800 includes a type field 802, a length field 804, a prefix length field 806, a flag field 808, a source prefix field 810, and a next hop field 812. Type field 802 includes a value indicating that sub-TLV 800 is being used to transmit information associated with a backup path of a sending network node. Length field 804 includes a value specifying the length of sub-TLV 800.

[0108] The prefix length field 806 includes a value that specifies the value of a prefix (e.g., the source prefix in the source prefix field 810). The flag field 808 includes a value that indicates whether the receiving network node (e.g., router E) should switch from using the entries in the ingress port column of the SAV table 600 to verify packets received from the source (e.g., router A) to using the entries in the backup port column of the SAV table 600 to verify packets received from the source. For example, the first bit (e.g., bit 0) of the flag field 808 can be set to a first binary value (e.g., 0) to indicate that the entry in the ingress port column should be used when verifying the packet. The first bit of the flag field 808 can be set to a second binary value (e.g., 1) to indicate that the entry in the backup port column should be used when verifying the packet.

[0109] The source prefix field 810 includes a field indicating a source prefix (e.g., Figure 6 The next hop field 812 includes a value that identifies the next hop of the network node that sent the sub-TLV 800. For example, when router A sends sub-TLV 800, the next hop field includes a value that indicates that router B is the next hop on the backup path to router E.

[0110] As mentioned above, Figures 7 and 8 For OSPFv2. A similar process is used for OSPFv3. For OSPFv3, a router link TLV may be used instead of the OSPFv2 extended prefix TLV 700. A router link TLV (not shown) may be used to bear the sub-TLV 800. Thus, the encoding of OSPFv3 is similar to that of OSPFv2.

[0111] Fig. 9 IS-IS sub-TLV 900 for prefix level encoding according to an embodiment of the present disclosure. IS-IS sub-TLV 900 is configured to be included in an extended IPv4 reachability TLV, as described in IETF RFC 5305 entitled “IS-IS Extensions for Traffic Engineering” by T. Li et al., published in October 2008; and in a multi-topology IPv4 reachability TLV, as described in IETF RFC 5305 entitled “IS-IS Extensions for Traffic Engineering” by T. Przygienda et al., published in February 2008. oThe IS-IS sub-TLV 900 is described in IETF RFC 5120 entitled "Multi-Topology (MT) in Intermediate Systems (IS-ISs)" (M-ISIS: Multi-Topology (MT) in Intermediate System to Intermediate System (IS-IS)); included in an IPv6 IP reachability TLV as described in IETF RFC 5308 entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October 2008; or included in a multi-topology IPv6 reachability TLV as described in IETF RFC 5120. In one embodiment, a network node (e.g., router A) uses IS-IS sub-TLV 900 to advertise a backup path to be used after a failure in the IGP domain is detected.

[0112] As shown, IS-IS sub-TLV 900 includes a type field 902, a length field 904, a flag field 906, a prefix length field 908, a source prefix field 910, and a next hop field 912. The type field 902 includes a value indicating that the sub-TLV 900 is being used to transmit information associated with a backup path of a sending network node. The length field 904 includes a value specifying the length of the sub-TLV 900.

[0113] The flag field 906 includes a value indicating whether the receiving network node (e.g., router E) should switch from using entries in the ingress port column of the SAV table 600 to verify packets received from the source (e.g., router A) to using entries in the backup port column of the SAV table 600 to verify packets received from the source. For example, the first bit (e.g., bit 0) of the flag field 906 can be set to a first binary value (e.g., 0) to indicate that the entry in the ingress port column should be used when verifying the packet. The first bit of the flag field 906 can be set to a second binary value (e.g., 1) to indicate that the entry in the backup port column should be used when verifying the packet.

[0114] The prefix length field 908 includes a value that specifies the value of a prefix (e.g., the source prefix in the source prefix field 910). The source prefix field 910 includes a value that indicates the value of the source prefix (e.g., Figure 6 The next hop field 912 includes a value that identifies the next hop of the network node that issued the sub-TLV 900. For example, when router A sends sub-TLV 900, the next hop field includes a value that indicates that router B is the next hop on the backup path to router E.

[0115] Fig.101 is a diagram of a data packet 1000 configured to notify a network node to implement a switch and validate data packets received on a backup path using a backup port in a source address validation (SAV) table. In one embodiment, the data packet 1000 includes a source field 1002, a destination field 1004, and a payload field 1006. However, it should be appreciated that in actual applications, the data packet 1000 may include additional fields.

[0116] Source field 1002 includes a value or entry corresponding to the source of the data packet. For example, source field 1002 may include an entry indicating that router A sent data packet 1000. Destination field 1004 includes a value or entry that identifies a group of members rather than a specific receiver. For example, destination field 1004 may include an entry within a multicast address range (e.g., an IPv4 range of multicast addresses, ranging from 224.0.0.0 to 239.255.255.255, with 1110 as the most significant bit, or an IPv6 range of multicast addresses starting with FF, with 11111111 as the most significant bit).

[0117] In order to enable multicast data to be sent correctly on the local physical network, a multicast media access control (MAC) address is used at the link layer. The destination address of the multicast data indicates a group of members (which the multicast source does not know), rather than a specific receiver. Therefore, the IP multicast address is mapped to a multicast MAC address.

[0118] Payload field 1006 includes the payload of the data packet. For example, the payload of the data packet can be a part of the information of the media content, data or other requests. In one embodiment, the payload of the data packet includes a switching indicator. The switching indicator includes a value or entry indicating that the recipient (e.g., router E) of the data packet 1000 implements switching and uses the backup port in the source address validation (SAV) table to verify the data packet received on the backup path. In one embodiment, the switching indicator is a bit, a plurality of bits, a predefined bit pattern or a unique or special bit sequence. In one embodiment, the switching indicator is a bit pattern that identifies or includes each router along the backup path. For example, the switching indicator can be 128 bytes corresponding to formulas 4*A, 4*B, 4*C, 4*D, wherein A, B, C and D are each a byte (or 8 bits) that identifies or corresponds to router A, router B, router C and router D respectively.

[0119] exist Figures 4 to 6An example of how packet 1000 may be used to trigger a switch is provided in the context of FIG. 1000 . In one embodiment, packet 1000 is sent by router A with a source address of 10.10.10.0 / 24 and is destined for router E with a destination address of 192.168.1.0 / 24. In this example, assume that router D fails. When packet 1000 arrives at router E, router E attempts to verify packet 1000 using a SAV table stored on router E. However, after router E queries its own SAV table, it determines that packets from source 10.10.10.0 / 24 should be received on a port (or interface) corresponding to router D, rather than on a port or interface corresponding to router C. Therefore, packet 1000 fails source verification and would normally be discarded by router E. However, before packet 1000 is discarded, router E parses or examines the payload in payload field 1006 and discovers a switch indicator. Upon detecting the switch indicator, router E switches and begins to use the backup port in the source address validation (SAV) table to validate packets received on the backup path. In one embodiment, instead of discarding the packet 1000 with the switch indicator, router E consumes or forwards the packet 1000 (when the destination is a destination outside router E).

[0120] In one embodiment, data packet 1000 is used in the context of multicast communication. That is, data packet 1000 can be referred to as a data packet, a multicast packet, or a multicast data packet. Although unicast is a one-to-one communication mode between hosts, multicast implements one-to-many communication between hosts. Multicast enables one or more multicast sources (e.g., routers) to send a copy of a data packet to multiple receivers (e.g., other routers). Multicast data packets are sent to a specific multicast address, which, unlike a unicast address, belongs to a group of hosts (e.g., routers) rather than a single host. In order to receive a multicast data packet, a host needs to join the multicast group to which the data packet is sent.

[0121] When unicast is used on a network with a large number of users, duplicate copies of packets will be sent across the network, consuming a large amount of processor resources and excessive network bandwidth. When multicast is used, each link on the network has only one data stream (no duplicate copies of packets). The advantage of multicast over unicast is that each link has at most one copy of the same packet.

[0122] Fig.11 The method 1100 is a method implemented by a network node in an IGP domain according to an embodiment of the present disclosure. The method 1100 may be implemented by a network node (e.g., Figures 4 to 5Router A in the IGP domain) is used to identify a backup path and trigger a switch to the backup path after a failure in the IGP domain is detected.

[0123] In block 1102, the network node sends a first message to a second network node (eg, router E) in the IGP domain. In one embodiment, the first message identifies a backup path for the network node to use when a failure in the IGP domain is detected.

[0124] In block 1104, the network node detects the failure after sending the first message to the second network node. In block 1106, the network node sends a multicast packet to the second network node after detecting the failure. In one embodiment, the multicast packet notifies the second network node to use a backup port in a source address validation (SAV) table to validate packets received on the backup path.

[0125] In one embodiment, the SAV table is constructed based only on the IGP and not on any additional protocol. In one embodiment, the multicast data packet includes a destination field including a multicast address and a payload including a handover indicator. In one embodiment, the handover indicator includes a predefined bit pattern.

[0126] In one embodiment, the first message includes a source prefix field and a next hop field, the source prefix field including a value identifying the network node, and the next hop field including a value identifying the next hop of the network node on the backup path.

[0127] In one embodiment, the first message includes a type field, and a value in the type field indicates that the first message includes a backup path. In one embodiment, the source prefix field, the next hop field, and the type field are included in a subtype length value (TLV).

[0128] In one embodiment, the sub-TLV is included in an Open Shortest Path First version 2 (OSPFv2) TLV or an Open Shortest Path First version 3 (OSPFv3) TLV. In one embodiment, the address prefix field includes a value identifying the second network node or the destination node.

[0129] In one embodiment, the first message includes an IGP update message, and the IGP update message includes a link state update (LSU) corresponding to the OSPF protocol or a protocol data unit (PDU) corresponding to the IS-IS protocol, and the PDU is called a link state PDU (LSP).

[0130] In one embodiment, the method 1100 further includes: after detecting the failure, sending the data packet on the backup path.

[0131] Fig.12 The method 1200 is implemented by a network node in an IGP domain according to an embodiment of the present disclosure. The method 1200 may be implemented by a network node (e.g., Figures 4 to 5 The router E) in the embodiment is configured to receive information about the backup path used by the sending network node, update the SAV table to accommodate the backup path, and switch to using the backup path in the SAV table when instructed by the sending network node.

[0132] In block 1202, a network node receives a first message from a second network node (eg, router A) in an IGP domain. In one embodiment, the first message identifies a backup path for the second network node to use when a failure in the IGP domain is detected.

[0133] In block 1204, the network node updates a source address validation (SAV) table to include a backup port corresponding to the backup path. In block 1206, the network node receives a multicast packet from a second network node. In one embodiment, the multicast packet notifies the network node to use the backup port in the SAV table to validate packets received on the backup path.

[0134] In one embodiment, the multicast data packet includes a destination field including a multicast address and a payload including a handover indicator. In one embodiment, the handover indicator includes a predefined bit pattern.

[0135] In one embodiment, the method 1200 further includes: performing a shortest path first (SPF) calculation using a zero value of a metric between the second network node and a next hop of the second network node on the backup path to update the SAV table. In one embodiment, the method 1200 further includes: performing an initial SPF calculation to generate the SAV table, wherein the initial SPF calculation is performed before the SPF calculation. In one embodiment, the SAV table includes a backup port column identifying a backup port.

[0136] In one embodiment, the first message includes a source prefix field and a next hop field, the source prefix field including a value identifying the second network node, and the next hop field including a value identifying a next hop of the second network node on a backup path. In one embodiment, the first message includes a type field, and wherein a value in the type field indicates that the first message includes the backup path. In one embodiment, the source prefix field, the next hop field, and the type field are included in a subtype length value (TLV).

[0137] In one embodiment, the sub-TLV is included in an Open Shortest Path First version 2 (OSPFv2) TLV, an Open Shortest Path First version 3 (OSPFv3) TLV, an Extended Internet Protocol version 4 (IPv4) Reachability TLV, a Multi-Topology IPv4 Reachability TLV, an Internet Protocol version 6 (IPv6) Reachability TLV, or a Multi-Topology IPv6 Reachability TLV. In one embodiment, the OSPFv2 TLV or the OSPFv3 TLV includes an Address Prefix field, and the Address Prefix field includes a value identifying a network node or a destination node.

[0138] In one embodiment, the method 1200 further includes: receiving a data packet; using the SAV table to verify that the data packet is received on a backup port corresponding to the second network node; and using a forwarding information base (FIB) table to send the data packet from an egress port corresponding to the destination address. In one embodiment, the method 1200 further includes: receiving a data packet; using the SAV table to determine that the data packet is not received on a backup port corresponding to the second network node; and dropping the data packet or sending the data packet somewhere (e.g., another network node or a controller) for further inspection.

[0139] The disclosed embodiments provide advantages over the prior art. For example, the disclosed embodiments provide extensions to existing protocols to allow easy deployment and leverage existing information in routing protocols. The disclosed embodiments also address issues with existing RFP solutions, allow easy deployment in IP networks, and operate without upgrading network hardware. New encodings and algorithms can be used to implement the intra-domain source authentication disclosed herein.

[0140] Fig.131 is a schematic diagram of a network device 1300 (e.g., a network node, a network router, a router, etc.). The network device 1300 is suitable for implementing the disclosed embodiments described herein. The network device 1300 includes: an ingress port / ingress device 1310 (also referred to as an upstream port) and a receiver unit (Rx) / receiving device 1320 for receiving data; a processor, a logic unit or a central processing unit (CPU) / processing device 1330 for processing data; a transmitter unit (Tx) / transmitting device 1340 and an egress port / egress device 1350 (also referred to as a downstream port) for sending data; and a memory / memory device 1360 for storing data. The network device 1300 may also include optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the inlet port / inlet device 1310, the receiver unit / receiving device 1320, the transmitter unit / transmitting device 1340 and the outlet port / exit device 1350 for the entry and exit of optical or electrical signals.

[0141] Processor / processing device 1330 is implemented by hardware and software. Processor / processing device 1330 can be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). Processor / processing device 1330 communicates with inlet port / inlet device 1310, receiver unit / receiving device 1320, transmitter unit / transmitting device 1340, outlet port / exit device 1350, and memory / memory device 1360. Processor / processing device 1330 includes routing module 1370. Routing module 1370 can implement the methods disclosed herein. Therefore, the inclusion of routing module 1370 provides substantial improvements to the functionality of network device 1300 and enables the transition of network device 1300 to different states. Alternatively, routing module 1370 is implemented as instructions stored in memory / storage device 1360 and executed by processor / processing device 1330 .

[0142] The network device 1300 may also include input and / or output (I / O) devices or I / O devices 1380 for transmitting data to and from a user. The I / O devices or I / O devices 1380 may include output devices, such as a display for displaying video data, a speaker for outputting audio data, etc. The I / O devices or I / O devices 1380 may also include input devices, such as a keyboard, a mouse, a trackball, etc., and / or corresponding interfaces for interacting with these output devices.

[0143] Memory / storage device 1360 includes one or more disks, tape drives, and solid-state drives, and can be used as an overflow data storage device to store programs when such programs are selected for execution and to store instructions and data read during program execution. Memory / storage device 1360 can be volatile and / or non-volatile, and can be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and / or static random-access memory (SRAM).

[0144] Although multiple embodiments are provided in the present disclosure, it should be understood that the disclosed systems and methods may also be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. This example should be considered illustrative rather than restrictive, and the present invention is not limited to the details given in this text. For example, various elements or components may be combined or integrated in another system, or some features may be omitted or not implemented.

[0145] In addition, the techniques, systems, subsystems and methods described and shown as discrete or separate in various embodiments may be combined or integrated with other systems, components, techniques or methods without departing from the scope of the present disclosure. Other examples of changes, substitutions and modifications may be determined by those skilled in the art, and changes, substitutions and modifications may be made without departing from the spirit and scope disclosed herein.

Claims

1. A method implemented by a network node in an Interior Gateway Protocol (IGP) domain, comprising: sending a first message to a second network node in the IGP domain, wherein the first message identifies a backup path to be used by the network node upon detecting a failure in the IGP domain; detecting the failure after sending the first message to the second network node; and After detecting the failure, a multicast data packet is sent to the second network node, wherein the multicast data packet notifies the second network node to use a backup port in a source address verification (SAV) table to verify data packets received on the backup path.

2. The method according to claim 1, wherein: The SAV table is constructed based only on the IGP without any additional protocol.

3. The method according to any one of claims 1 to 2, wherein: The multicast data packet includes a destination field including a multicast address and a payload including a handoff indicator.

4. The method according to claim 3, wherein: The switching indicator comprises a predefined bit pattern.

5. The method according to any one of claims 1 to 4, wherein: The first message includes a source prefix field and a next hop field, wherein the source prefix field includes a value identifying the network node, and wherein the next hop field includes a value identifying a next hop of the network node on the backup path.

6. The method according to any one of claims 1 to 5, wherein: The first message includes a type field, and wherein a value in the type field indicates that the first message includes the backup path.

7. The method according to any one of claims 1 to 6, wherein: The source prefix field, the next hop field, and the type field are included in a subtype-length value (TLV).

8. The method according to any one of claims 1 to 7, wherein: The sub-TLV is included in an Open Shortest Path First version 2 (OSPFv2) TLV or an Open Shortest Path First version 3 (OSPFv3) TLV.

9. The method according to any one of claims 1 to 8, wherein: The OSPFv2 TLV or the OSPFv3 TLV includes an address prefix field, and wherein the address prefix field includes a value identifying the second network node or the destination node.

10. The method according to any one of claims 1 to 9, wherein: The first message includes an IGP update message, and wherein the IGP update message includes a link state update (LSU) corresponding to an OSPF protocol or a protocol data unit (PDU) corresponding to an IS-IS protocol, the PDU being referred to as a link state PDU (LSP).

11. The method according to any one of claims 1 to 10, further comprising: After detecting the failure, data packets are sent on the backup path.

12. A method implemented by a network node in an interior gateway protocol (IGP) domain, comprising: receiving a first message from a second network node in the IGP domain, wherein the first message identifies a backup path to be used by the second network node upon detecting a failure in the IGP domain; updating a source address verification (SAV) table to include a backup port corresponding to the backup path; and A multicast packet is received from the second network node, wherein the multicast packet notifies the network node to use the backup port in the SAV table to authenticate packets received on the backup path.

13. The method according to claim 12, wherein: The multicast data packet includes a destination field including a multicast address and a payload including a handoff indicator.

14. The method according to any one of claims 12 to 13, wherein: The switching indicator comprises a predefined bit pattern.

15. The method according to any one of claims 12 to 14, further comprising: A shortest path first (SPF) calculation is performed using a zero value for a metric between the second network node and a next hop of the second network node on the backup path to update the SAV table.

16. The method according to any one of claims 12 to 15, further comprising: An initial SPF calculation is performed to generate a forwarding information base (FIB) table, wherein the initial SPF calculation is performed before the SPF calculation.

17. The method according to any one of claims 12 to 16, wherein: The SAV table includes a backup port column identifying the backup port.

18. The method according to any one of claims 12 to 17, wherein: The first message includes a source prefix field and a next hop field, wherein the source prefix field includes a value identifying the second network node, and wherein the next hop field includes a value identifying a next hop of the second network node on the backup path.

19. The method according to any one of claims 12 to 18, wherein: The first message includes a type field, and wherein a value in the type field indicates that the first message includes the backup path.

20. The method according to any one of claims 12 to 19, wherein: The source prefix field, the next hop field, and the type field are included in a subtype-length value (TLV).

21. The method according to any one of claims 12 to 20, wherein: The sub-TLV is included in an Open Shortest Path First Version 2 (OSPFv2) TLV, an Open Shortest Path First Version 3 (OSPFv3) TLV, an Extended Internet Protocol Version 4 (IPv4) Reachability TLV, a Multi-Topology IPv4 Reachability TLV, an Internet Protocol Version 6 (IPv6) Reachability TLV, or a Multi-Topology IPv6 Reachability TLV.

22. The method according to any one of claims 12 to 21, wherein: The OSPFv2 TLV or the OSPFv3 TLV includes an address prefix field, and wherein the address prefix field includes a value identifying the network node or the destination node.

23. The method according to any one of claims 1 to 22, further comprising: Receive data packets; using the SAV table to verify that the data packet was received on the backup port corresponding to the second network node; as well as The data packet is sent from an egress port corresponding to the destination address using a forwarding information base (FIB) table.

24. The method according to any one of claims 1 to 22, further comprising: Receive data packets; using the SAV table to determine that the data packet was not received on the backup port corresponding to the second network node; as well as Either drop the packet or send the packet somewhere for further inspection.

25. A network node in an interior gateway protocol (IGP) domain, comprising: a memory configured to store instructions; as well as One or more processors, the one or more processors are coupled to the memory and configured to execute the instructions so that the network node performs the method of any one of claims 1 to 24.

26. A non-transitory computer-readable medium comprising a computer program product for use by a network node, the computer program product comprising computer-executable instructions stored on the non-transitory computer-readable medium, the computer-executable instructions causing the network node to perform the method of any one of claims 1 to 24 when executed by one or more processors.

27. A network node in an Interior Gateway Protocol (IGP) domain, comprising means for performing the method of any one of claims 1 to 24.

Images