Intra-domain source address verification fast rerouting using IGP

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 identifies a backup path to be used by the network node when a fault in the IGP domain is detected. The method further comprises detecting the failure after sending the first message to the second network node; upon detecting the fault, a second message is sent to the second network node. The second message notifies the second network node to verify a data packet received on the backup path using a backup port in a source address verification (SAV) table.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

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

[0005] The task of IP is to deliver 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 that tags datagrams with source and destination information.

[0006] Source address validation (SAV) is a standard in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2827, titled "Network Ingress Filtering: Protecting against Denial of Service Attacks Exploiting 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 notifying a network node of a backup path to use when a failure in an interior gateway protocol (IGP) domain is detected, and for notifying a second network node to validate packets received on the backup path using a backup port in a source address validation (SAV) table. 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 shortest path first (SPF) calculations to implement source address validation (SAV). 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 second message to the second network node, wherein the second message notifies the second network node to use a backup port in a source address validation (SAV) table on the second network node to validate packets received on the backup path.

[0009] Optionally, according to any of the above aspects, in another implementation of the aspect, the SAV table is constructed based only on the IGP but not on any additional protocol.

[0010] Optionally, according to any of the above aspects, in another implementation of the aspect, 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.

[0011] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the first message includes a type field, wherein a value in the type field indicates that the first message includes the backup path.

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

[0013] Optionally, according to any of the above aspects, in another implementation of the aspect, 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.

[0014] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the OSPFv2 TLV or the OSPFv3 TLV includes an address prefix field, wherein the address prefix field includes a value identifying the second network node or the destination node.

[0015] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the second message includes a flag field, wherein the flag field includes a value indicating that the second network node switches to the backup port.

[0016] Optionally, according to any of the above aspects, in another implementation of the aspect, the second 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.

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

[0018] Optionally, according to any of the above aspects, in another implementation manner of the aspect, after the failure is detected, a data packet is sent on the backup path.

[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 second message from the second network node, wherein the second message notifies the network node to use the backup port in the SAV table on the second network node to validate data packets received on the backup path.

[0020] Optionally, according to any of the above aspects, in another implementation of the aspect, a shortest path first (SPF) calculation is performed using a value of zero for the metric between the second network node and the next hop of the second network node to update the SAV table.

[0021] Optionally, according to any of the above aspects, in another implementation of the aspect, an initial SPF calculation is performed to generate the SAV table, wherein the initial SPF calculation is performed before the SPF calculation.

[0022] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the SAV table includes a backup port column identifying the backup port.

[0023] Optionally, according to any of the above aspects, in another implementation of the aspect, 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.

[0024] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the first message includes a type field, wherein a value in the type field indicates that the first message includes the backup path.

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

[0026] Optionally, according to any of the above aspects, in another implementation of the aspect, 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.

[0027] Optionally, according to any of the above aspects, in another implementation of the aspect, 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.

[0028] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the second message includes a flag field, wherein the flag field includes a value indicating that the network node switches to the backup port.

[0029] Optionally, according to any of the above aspects, in another implementation of the aspect, the second 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 the next hop of the second network node on the backup path.

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

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

[0032] A third aspect relates to a network node in an interior gateway protocol (IGP) domain, comprising: a memory for storing instructions; and one or more processors coupled to the memory and used 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 in 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 one 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 above-described embodiments to create a new embodiment within the scope of the present invention.

[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 invention, reference is 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 It is a schematic diagram of the distributed source address validation (DSAV) workflow.

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

[0042] Figure 5 It is a schematic diagram of the remote LFAFRR process.

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

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

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

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

[0047] Fig.10 The invention relates to a method implemented by a network node in an IGP domain according to an embodiment of the present invention.

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

[0049] Fig.12 is a schematic diagram of a network device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0050] First, it should be understood that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods may be implemented using any number of techniques, whether currently known or existing. The present invention 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 may be modified within the scope of the appended claims and their full scope of equivalents.

[0051] An IP data packet (or simply a data packet) has a source address and a destination address. As mentioned above, IP source address spoofing refers to the practice of maliciously sending a data packet with a forged or false source address.

[0052] 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, with the goal of enabling source address validation (SAV) and implementing anti-spoofing to prevent packets with false source IP addresses from entering or leaving the network.

[0053] SAV is a long-standing concern of the Internet Engineering Task Force (IETF). A large number of IETF documents describe anti-spoofing techniques. 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" published by P. Ferguson et al. in May 2000, discloses techniques for preventing IP packets with forged source IP addresses from entering the Internet at the edge of the Internet.

[0054] IETF RFC 6959, titled "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.

[0055] 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, together with RFC 2827, discloses techniques for ingress filtering and access control list (ACL)-based SAV. One problem with these techniques is that they require manual configuration of network devices.

[0056] IETF RFC 3704, titled "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 when there is asymmetric routing, packets are incorrectly blocked and, in some cases, packets are incorrectly allowed to be routed.

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

[0058] IETF RFC 6620, titled "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.

[0059] 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.

[0060] Some network nodes (e.g., network nodes 104, 114) are arranged at the edge of the IGP domain 102. Network nodes 104, 114 that receive data packets from outside the IGP domain 102 may be referred to as ingress network nodes. 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, network nodes arranged at the edge of the IGP domain 102 may be coupled with nodes arranged outside the IGP domain 102. 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.

[0061] 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 on length, bandwidth, etc. 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).

[0062] Figure 1 It is explained that in intra-domain SAV, applying strict uRPF only on subnet ports can lead to the problem of incorrect release. When all network devices 104 to 116 are deployed identically (e.g., deploying strict uRPF policies), there will be no problem. However, when only some network devices (e.g., network devices 104, 106, 110, and 116 within deployment area 130) apply strict uRPF policies at their subnet ports, spoofing may still occur. For example, when network device 108 (also known as router 3) sends a data 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 incorrectly release the data packet. Therefore, a subnet outside deployment area 130 can spoof the address of a subnet within deployment area 130.

[0063] 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.

[0064] 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 on length, bandwidth, etc. 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 network devices (e.g., network devices 104, 106, 110, and 116) are set in deployment area 130.

[0065] exist Figure 2In FIG. 1 , in intra-domain SAV, network device 116 applies strict uRPF on all subnet ports. However, this can lead to a false blocking problem 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 will mistakenly block these packets (as shown by the dotted arrow).

[0066] When all network devices 104 to 116 are deployed identically (e.g., deploying a strict uRPF policy), no problem occurs. However, when only some 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 mistakenly release the packet. Therefore, a subnet outside deployment area 130 is able to spoof the address of a subnet within deployment area 130.

[0067] 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 relies on the distributed control plane protocol (instead of using uRPF) to generate accurate SAV tables. DSAV provides periodic or triggered updates (when routing information changes) to distribute SAV rules to network nodes.

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

[0069] 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 the 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).

[0070] Still see Figure 3 , router 1 builds SAV table 304 using the DSAV process. Router 1 then uses SAV table 304 to verify the source of the incoming or received data packet. For example, router 1 checks whether 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) corresponding to the destination prefix in the data packet.

[0071] Although Figure 3 The DSAV framework described in can solve some of the spoofing problems, but it still has 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 adds 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.

[0072] Figure 4 4 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 described in Figure 1 and Figure 2 For the sake of brevity, detailed descriptions of these elements are not repeated here.

[0073] 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).

[0074] OSPF uses a link state routing (LSR) algorithm and belongs to 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 topological 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.

[0075] 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. Packets (or datagrams) are then forwarded through the network to their destination based on the calculated ideal path.

[0076] Intermediate System to Intermediate System (IS-IS or ISIS) is another LSR routing protocol designed to efficiently move information within 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 was defined in RFC 1142, titled "OSI IS-IS Intra-domain Routing Protocol," published by D. Oran in February 1990. IS-IS is common in large service provider networks.

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

[0078] 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.

[0079] 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 (50 ms). 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.

[0080] Router A uses the IGP protocol to pre-calculate the backup path. In other words, Router A calculates the backup path before detecting a fault. Figure 4 As shown, the next hop of Router A on the backup path is Router C. When calculating the backup path, the next hop of Router A is installed in the FIB of Router A. Therefore, when the backup path is implemented by Router A, the data packet is sent to Router C (as shown by the arrow) instead of Router D.

[0081] Unfortunately, Router E may not know that Router A has a backup path, has started 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 should be received on the port (also called an interface) corresponding to Router D, not on Router C. Therefore, Router E cannot validate the packets, and the packets are discarded even though they are valid and not spoofed.

[0082] Figure 5 5 is a schematic diagram of a remote LFA FRR 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 described in Figure 1 and Figure 2 For the sake of brevity, detailed descriptions of these elements are not repeated here.

[0083] 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.

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

[0085] 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.

[0086] 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, titled "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)" published by S. Bryant et al. in September 2008.

[0087] Router A pre-calculates the backup path using the IGP protocol. That is, Router A calculates the backup path before detecting a failure. When a 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 will send 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 shown by the small arrow in the figure). Therefore, in remote LFAFRR, Router B is not used as the next hop. Instead, Router A tunnels the traffic to Router C to bypass the loop.

[0088] 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 the backup path is implemented by Router A, the packet is sent to Router C (as shown by the arrow) instead of Router D or Router B.

[0089] Unfortunately, Router E may not know that Router A has a backup path, has started 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 should be received on the port (also called an interface) corresponding to Router D, not on Router C. Therefore, Router E cannot validate the packets, and the packets are discarded even though they are valid and not spoofed.

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

[0091] Figure 6 600 is a schematic diagram of a SAV table constructed to accommodate LFA FRR and remote LFAFRR processes according to an embodiment of the present invention. An example of how to construct SAV table 600 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.

[0092] First, router E receives link state advertisements from one or more 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).

[0093] 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.

[0094] 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.

[0095] 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 routed from router A to router D, and thus enters router E through router D. Since 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.

[0096] 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 a port that will receive a 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 packet received from router C is determined to be valid.

[0097] Although Figure 6The SAV table 600 in FIG. 6 only depicts 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.

[0098] 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 the destination of the data packet, the source of the data packet, and the next hop of the source of the data packet.

[0099] In one embodiment, router E performs an SPF calculation using a value of zero for the metric between the source (e.g., router A) and the next hop of the source (e.g., router B) to update 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 SAV table 600 to include a backup port corresponding to the backup path (i.e., Eth 1 / 1 (to C)).

[0100] 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 an entry for the backup port into the row of the backup port column.

[0101] 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 receiving the notification, 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 does not use the entry in the backup port column, but uses the entry in the ingress port column of the SAV table 600, resulting in valid data packets being discarded by the router E.

[0102] In order to inform router E that router A has detected the failure and has switched to the backup path, router A sends a second update message to router E. The second update message notifies 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 second update message notifies router E to switch from using the entries in the ingress port column in the SAV table 600 to verify the data packets.

[0103] Figure 7 It is an OSPFv2 extended prefix TLV 700 according to an embodiment of the present invention. 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. in November 2015.

[0104] 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) to be used when the receiving router constructs a SAV table. For example, address prefix field 702 includes a value indicating a destination prefix, such as, Figure 6 In one embodiment, the address prefix field 702 has a variable length. The sub-TLV field 704 is used to carry one or more sub-TLVs, as will be explained more fully below.

[0105] Figure 8 is a sub-TLV 800 for prefix level encoding according to an embodiment of the present invention. 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 is detected in the IGP domain, and to advertise switching to the backup path after a failure is detected.

[0106] 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.

[0107] Prefix length field 806 includes a value that specifies the value of a prefix (e.g., the source prefix in source prefix field 810). Flag field 808 includes an indication of whether the receiving network node (e.g., router E) should switch from using entries in the ingress port column of SAV table 600 to verify packets received from the source (e.g., router A) to using entries in the backup port column of SAV table 600 to verify packets received from the source. For example, the first bit (e.g., bit 0) of 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 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.

[0108] 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.

[0109] As mentioned above, Figure 7 and Figure 8 For OSPFv2. OSPFv3 uses a similar process. 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 carry the sub-TLV 800. Therefore, the encoding of OSPFv3 is similar to that of OSPFv2.

[0110] Fig. 9It is an IS-IS sub-TLV 900 for prefix level encoding according to an embodiment of the present invention. The 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," published by T. Li et al. in October 2008; in a multi-topology IPv4 reachability TLV as described in IETF RFC 5120, entitled "M-ISIS: Multi Topology (MT) in Intermediate System to Intermediate Systems (IS-ISs)," published by T. Przygienda et al. in February 2008; 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 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; Multi-topology IPv6 reachability TLV described in 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 is detected in the IGP domain, and to advertise switching to the backup path after a failure is detected.

[0111] 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.

[0112] The flag field 906 includes an indication of 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 the data 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 the data 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 data 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 data packet.

[0113] 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 identifying the next hop of the network node that sent the sub-TLV 900. For example, when router A sends sub-TLV 900, the next hop field includes a value indicating that router B is the next hop on the backup path to router E.

[0114] Fig.10 The method 1000 is implemented by a network node in an IGP domain according to an embodiment of the present invention. The method 1000 may be implemented by a network node (eg, Figure 4 and Figure 5 Router A in the IGP domain) is used to identify a backup path and trigger switching to the backup path after detecting a failure in the IGP domain.

[0115] In block 1002, a network node sends a first message to a second network node (eg, router E) in an 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.

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

[0117] In one embodiment, the SAV table is constructed based only on the IGP and not on any additional protocol. In one embodiment, 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.

[0118] In one embodiment, the first message includes a type field, wherein 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).

[0119] 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.

[0120] In one embodiment, the second message includes a flag field, wherein the flag field includes a value indicating that the second network node switches to the backup port. In one embodiment, the second 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.

[0121] In one embodiment, the first message and / or the second message includes an IGP update message, wherein 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).

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

[0123] Fig.11 The method 1100 is implemented by a network node in an IGP domain according to an embodiment of the present invention. The method 1100 may be implemented by a network node (eg, Figure 4 and Figure 5 The router E) in the embodiment is configured to receive information about the backup path used by the sending network node to 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.

[0124] In block 1102, 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.

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

[0126] In one embodiment, the method 1100 further includes: performing a shortest path first (SPF) calculation using a value of zero 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. In one embodiment, the method 1100 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.

[0127] In one embodiment, 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; the next hop field includes a value identifying the next hop of the second network node on the backup path. In one embodiment, the first message includes a type field, and wherein the 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 (typelength value, TLV).

[0128] 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, wherein the Address Prefix field includes a value identifying a network node or a destination node.

[0129] In one embodiment, the second message includes a flag field, wherein the flag field includes a value indicating that the network node switches to the backup port. In one embodiment, the second 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.

[0130] In one embodiment, method 1100 further includes: receiving a data packet; verifying using a SAV table that the data packet is received on a backup port corresponding to the second network node; and sending the data packet from an egress port corresponding to the destination address using a forwarding information base (FIB) table.

[0131] In one embodiment, method 1100 also includes: receiving a data packet; using the SAV table to determine that the data packet was not received on a backup port corresponding to the second network node; and discarding the data packet or sending the data packet somewhere (e.g., another network node or controller) for further inspection.

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

[0133] Fig.12 1 is a schematic diagram of a network device 1200 (e.g., a network node, a network router, a router, etc.). The network device 1200 is suitable for implementing the disclosed embodiments, as described herein. The network device 1200 includes: an ingress port / ingress device 1210 (also referred to as an upstream port) and a receiver unit (Rx) / receiving device 1220 for receiving data; a processor, a logic unit or a central processing unit (CPU) / processing device 1230 for processing data; a transmitter unit (Tx) / transmitting device 1240 and an egress port / egress device 1250 (also referred to as a downstream port) for sending data; a memory / memory device 1260 for storing data. The network device 1200 may also include optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to an inlet port / inlet device 1210, a receiver unit / receiving device 1220, a transmitter unit / transmitting device 1240, and an outlet port / exit device 1250 for the entry and exit of optical or electrical signals.

[0134] The processor / processing device 1230 is implemented by hardware and software. The processor / processing device 1230 can be implemented as one or more CPU chips, cores (for example, as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor / processing device 1230 communicates with the inlet port / inlet device 1210, the receiver unit / receiving device 1220, the transmitter unit / transmitting device 1240, the outlet port / exit device 1250, and the memory / memory device 1260. The processor / processing device 1230 includes a routing module 1270. The routing module 1270 is capable of implementing the method disclosed herein. Therefore, the inclusion of the routing module 1270 provides a substantial improvement in the functionality of the network device 1200 and implements the transition of the network device 1200 to different states. Alternatively, the routing module 1270 is implemented as an instruction stored in the memory / memory device 1260 and executed by the processor / processing device 1230.

[0135] The network device 1200 may also include an input and / or output (I / O) device or I / O device 1280 for data input and output with a user. The I / O device or I / O device 1280 may include an output device, such as a display for displaying video data, a speaker for outputting audio data, etc. The I / O device or I / O device 1280 may also include an input device, such as a keyboard, a mouse, a trackball, etc., and / or a corresponding interface for interacting with these output devices.

[0136] The memory / storage device 1260 includes one or more disks, one or more tape drives, and one or more solid-state hard disks, 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 the execution of the programs. The memory / storage device 1260 can be volatile and / or non-volatile, and can be a read-only memory (ROM), a random access memory (RAM), a ternary content-addressable memory (TCAM), and / or a static random-access memory (SRAM).

[0137] Although the present invention provides a plurality of specific embodiments, it should be understood that the disclosed systems and methods may also be embodied in a variety of other specific forms without departing from the spirit or scope of the present invention. The examples of the present invention 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.

[0138] 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 invention. 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 of the present invention.

Claims

1. A method implemented by a network node in an Interior Gateway Protocol (IGP) domain, characterized in that: include: 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 second message is sent to the second network node, wherein the second message notifies the second network node to use a backup port in a source address verification (SAV) table on the second network node to verify data packets received on the backup path.

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

3. The method according to any one of claims 1 and 2, characterized in 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 wherein the next hop field includes a value identifying a next hop of the network node on the backup path.

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

5. The method according to any one of claims 1 to 4, characterized in that The source prefix field, the next hop field, and the type field are included in a subtype-length value (TLV).

6. The method according to any one of claims 1 to 5, characterized in 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.

7. The method according to any one of claims 1 to 6, characterized in that 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.

8. The method according to any one of claims 1 and 2, characterized in that The second message includes a flag field, wherein the flag field includes a value indicating that the second network node switches to the backup port.

9. The method according to claim 8, characterized in that The second 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.

10. The method according to any one of claims 1 to 9, characterized in that The first message and / or the second message include an IGP update message, and wherein 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).

11. The method according to any one of claims 1 to 10, characterized in that Also includes: 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, characterized in that: include: 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 second message is received from the second network node, wherein the second message notifies the network node to use the backup port in the SAV table on the second network node to authenticate data packets received on the backup path.

13. The method according to claim 12, characterized in that Also includes: A shortest path first (SPF) calculation is performed using a value of zero 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.

14. The method according to any one of claims 12 and 13, characterized in that Also includes: An initial SPF calculation is performed to generate the SAV table, wherein the initial SPF calculation is performed before the SPF calculation.

15. The method according to any one of claims 12 to 14, characterized in that The SAV table includes a backup port column identifying the backup port.

16. The method according to any one of claims 12 to 15, characterized in 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.

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

18. The method according to any one of claims 12 to 17, characterized in that The source prefix field, the next hop field, and the type field are included in a subtype-length value (TLV).

19. The method according to any one of claims 12 to 18, characterized in 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.

20. The method according to any one of claims 12 to 19, characterized in 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.

21. The method according to any one of claims 12 to 20, characterized in that The second message includes a flag field, wherein the flag field includes a value indicating that the network node switches to the backup port.

22. The method according to claim 21, characterized in that The second 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.

23. The method according to any one of claims 1 to 22, characterized in that Also includes: Receive data packets; verifying, using the SAV table, 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, characterized in that Also includes: Receive data packets; determining, using the SAV table, 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, characterized in that: include: A memory for storing instructions; as well as One or more processors, coupled to the memory and configured to execute the instructions so that the network node performs the method according to any one of claims 1 to 24.

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

27. A network node in an interior gateway protocol (IGP) domain, characterized in that: Comprising apparatus for performing the method of any one of claims 1 to 24.

Images