Intra-domain source address verification using IGP

Abstract

A method implemented by a network node in an Interior Gateway Protocol (IGP) domain. The method includes receiving link state advertisements from one or more other network nodes in the IGP domain, performing shortest path first (SPF) based on the link state advertisements received from the one or more other network nodes to determine a path through the domain, constructing a forwarding information base (FIB) table based on the SPF, and transmitting the FIB table to the IGP domain based on the FIB table. Determining that the path through the domain is symmetric, and replicating the FIB to generate 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,592, 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 generally relates to communications using the Internet Protocol (IP), and more particularly, to source address verification. 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 verifying the source of a data packet. By using the disclosed techniques for SAV, data packets with invalid or suspicious source Internet protocol (IP) addresses are prevented from entering or exiting the network. This can reduce the risk of source address spoofing and related security threats, such as distributed denial-of-service (DDoS) attacks, etc.

[0008] A first aspect relates to a method implemented by a network node in an interior gateway protocol (IGP) domain, comprising: receiving link state advertisements from one or more other network nodes in the IGP domain; performing a shortest path first (SPF) calculation based on the link state advertisements received from the one or more other network nodes to determine one or more paths from the network node through the domain; constructing a forwarding information base (FIB) table based on the SPF calculation; determining that the path through the domain is symmetric; and replicating the FIB table to generate a source address validation (SAV) table.

[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 FIB table includes a destination prefix column and an egress port column; and the SAV table includes a source prefix column and an ingress port column.

[0011] Optionally, according to any of the above aspects, in another implementation of the aspect, the value in the destination prefix column is the same as the value in the source prefix column; the value in the egress port column is the same as the value in the ingress port column.

[0012] Optionally, according to any of the above aspects, in another implementation of the aspect, a data packet identifying a source address and a destination address is received; the SAV table is used to verify that the data packet is received on an input port corresponding to the source address; and the FIB table is used to send the data packet from an output port corresponding to the destination address.

[0013] Optionally, according to any of the above aspects, in another implementation of the aspect, a data packet identifying a source address and a destination address is received; the SAV table is used to determine that the data packet is not received on an ingress port corresponding to the source address; and the data packet is discarded or sent to somewhere for further inspection.

[0014] A second aspect relates to a method implemented by a network node in an interior gateway protocol (IGP) domain, comprising: receiving link state advertisements from one or more other network nodes in the IGP domain; performing a first shortest path first (SPF) calculation based on the link state advertisements received from the one or more other network nodes to determine one or more paths from the network node through the domain; constructing a forwarding information base (FIB) table based on the first SPF calculation; determining that one of the paths through the domain includes an asymmetric link; performing a second SPF calculation using a reverse metric of the asymmetric link; and generating a source address validation (SAV) table based on the first SPF calculation and the second SPF calculation.

[0015] Optionally, according to any of the above aspects, in another implementation of the aspect, the link metrics including the reverse link metrics are stored in a link state database (LSDB) of the network node.

[0016] Optionally, according to any of the above aspects, in another implementation of the aspect, during the first SPF calculation, the link metrics are compared in the forward and reverse directions to determine that the path through the domain includes the asymmetric link.

[0017] Optionally, according to any of the above aspects, in another implementation of the aspect, when the link state announcement is received from the one or more other network nodes, the link metrics are compared in the forward and reverse directions to determine that the path through the domain includes the asymmetric link.

[0018] Optionally, according to any of the above aspects, in another implementation manner of the aspect, a message is received from the one or more other network nodes, wherein the links connected to the one or more other network nodes are asymmetric.

[0019] A third aspect relates to a method implemented by a network node in an interior gateway protocol (IGP) domain, comprising: receiving link state advertisements from one or more other network nodes in the IGP domain, wherein the link state advertisement received from a first network node among the one or more network nodes specifies a static route or a routing policy for routing a data packet from the first network node to the network node; performing a first shortest path first (SPF) calculation based on the link state advertisement received from the one or more other network nodes to determine one or more paths from the network node through the domain; constructing a forwarding information base (FIB) table based on the first SPF calculation; performing a second SPF calculation on a metric between the first network node and a second network node using a value of zero according to the static route or the routing policy; and generating a source address validation (SAV) table based on the FIB and the second SPF calculation.

[0020] Optionally, according to any of the above aspects, in another implementation of the aspect, it is determined that one of the paths through the domain includes an asymmetric link; the second SPF calculation is performed using the following items: a reverse metric of the asymmetric link; and based on the static route or the routing policy, the value of zero for the metric between the first network node and the second network node.

[0021] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the second network node is the next hop of the first network node.

[0022] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the SAV table includes a destination port corresponding to a source prefix.

[0023] Optionally, according to any of the above aspects, in another implementation of the aspect, the link state announcement received from the first network node includes a type length value (TLV) field, wherein the TLV in the TLV field includes a flag field and a next hop field, wherein the value in the flag field is zero, and wherein the value in the next hop field identifies the second network node.

[0024] Optionally, according to any of the above aspects, in another implementation of the aspect, the link state advertisement is an Open Shortest Path First version 2 (OSPFv2) router information opaque link state advertisement or an Open Shortest Path First version 3 (OSPFv3) router information link state advertisement.

[0025] Optionally, according to any of the above aspects, in another implementation of the aspect, the link state announcement received from the first network node includes a type length value (TLV) field, wherein the TLV in the TLV field includes an address prefix field and a sub-type length value (TLV) field, wherein the address prefix field identifies the destination prefix; the sub-TLV in the sub-TLV field includes a flag field, a source prefix field, and a next hop field, wherein the value in the flag field is 1, wherein the value in the source prefix field identifies the source, and wherein the value in the next hop field identifies the second network node.

[0026] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the link state advertisement is an extended prefix opaque link state advertisement, and the TLV is an extended prefix TLV or a router link TLV.

[0027] Optionally, according to any of the above aspects, in another implementation of the aspect, the link state announcement received from the first network node includes a type length value (TLV) field, wherein the TLV in the TLV field includes a sub-TLV field, wherein the sub-TLV in the sub-TLV field includes a flag field and a next hop field, wherein the value in the flag field is zero, and wherein the value in the next hop field identifies the second network node.

[0028] Optionally, according to any of the above aspects, in another implementation manner of the aspect, the TLV is an IS-IS router capability TLV.

[0029] Optionally, according to any of the above aspects, in another implementation of the aspect, the link state announcement received from the first network node includes a type length value (TLV) field, wherein the TLV in the TLV field includes a sub-TLV field, wherein the sub-TLV in the sub-TLV field includes a flag field, a source prefix field, and a next hop field, wherein the value in the flag field is zero, wherein the value in the source prefix field identifies the source, and wherein the value in the next hop field identifies the second network node.

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

[0031] The fourth 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.

[0032] A fifth 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 aspects.

[0033] A sixth 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 aspects.

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

[0035] 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

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

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

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

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

[0040] Figure 4 4 is a schematic diagram of a SAV table constructed for a symmetric path according to an embodiment of the present invention.

[0041] Figure 5 is a schematic diagram of a SAV table constructed when a path passing through a domain includes an asymmetric link according to an embodiment of the present invention.

[0042] Figure 6 is a schematic diagram of a SAV table constructed when there is a static route or routing policy for routing data packets through a domain according to an embodiment of the present invention.

[0043] Figure 7 It is an opaque Link State Announcement (LSA) of Open Shortest Path First version 2 (OSPFv2) router information according to an embodiment of the present invention.

[0044] Figure 8 It is an Open Shortest Path First version 3 (OSPFv3) router information LSA according to an embodiment of the present invention.

[0045] Fig. 9 It is a type length value (Type Length Value, TLV) used for router level encoding according to an embodiment of the present invention.

[0046] Fig.10 It is an OSPFv2 extended prefix TLV according to an embodiment of the present invention.

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

[0048] Fig.12 It is a schematic diagram of an Intermediate System-Intermediate System (IS-IS) sub-TLV for router-level encoding according to an embodiment of the present invention.

[0049] Fig.13 4 is a schematic diagram of an IS-IS sub-TLV for prefix level encoding according to an embodiment of the present invention.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0076] Disclosed herein are techniques for verifying the source of a data packet. These techniques use information already available in existing interior gateway protocols (e.g., Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS)) and link state databases (LSDBs), 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, packets with incorrect source Internet Protocol (IP) addresses are prevented from entering or exiting a network.

[0077] Figure 4 4 is a schematic diagram 400 of a SAV table 404 constructed for a symmetric path (indicated by arrows) in accordance with an embodiment of the present invention. In the example shown, various network nodes labeled routers A, B, C, D, and E are coupled together by 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.

[0078] exist Figure 4 In the example, network nodes A, B, 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).

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

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

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

[0082] like Figure 4 As shown, the path through the domain from Router A to Router E is symmetric (indicated by the arrows). The path is symmetric when the links 418 between the routers have the same value in both directions and / or there is no routing policy in place. For example, the path is symmetric when the links 418 on the path of Router A → Router B → Router C → Router E have the same cost as the links 418 on the path of Router E → Router C → Router B → Router E. The path is also symmetric when there is no routing policy that supersedes or takes precedence over the path calculated by OSPF, for example.

[0083] An example is provided of how to construct SAV table 404 from the perspective of router A when the paths through the IGP domain are symmetric. It is worth noting that other routers in the domain may similarly use the same process to construct their own SAV tables.

[0084] First, router A receives link state advertisements from one or more other network nodes in the IGP domain. That is, router A receives link state advertisements from router B, router C, router D, and / or router E. 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).

[0085] Router A performs a shortest path first (SPF) calculation based on link state advertisements received from other network nodes to determine a path through the domain. Thereafter, router A constructs a forwarding information base (FIB) table 406 based on the SPF calculation. In one embodiment, FIB 406 includes a destination prefix column and an egress port column. Figure 4 As shown, the entry in the destination prefix column corresponds to one of the routers in the IGP domain. For example, the destination prefix column includes prefix B corresponding to router B, prefix C corresponding to router C, prefix E corresponding to router E, and prefix D corresponding to router D. The egress port identified for each prefix indicates the port used by router A when sending a data packet with the corresponding prefix. For example, a data packet with a destination prefix (or destination) of prefix C is sent from egress port B.

[0086] Router A determines that the path through the domain is symmetric. In one embodiment, Router A makes this determination based on an SPF calculation. For example, during the SPF calculation, Router A discovers that links 418 along the path have the same cost in both directions (i.e., forward and reverse, or downstream and upstream). That is, Router A determines that the cost of sending a packet from Router A→Router B→Router C→Router E is the same as the cost of sending a packet from Router E→Router C→Router B→Router E.

[0087] In one embodiment, router A determines that the paths through the domain are symmetric after building FIB table 406. In one embodiment, router A determines that the paths through the domain are symmetric before building FIB table 406. In one embodiment, router A determines that the paths through the domain are symmetric at or about the same time as building FIB table 406.

[0088] Next, router A copies FIB table 406 to generate SAV table 404. In this way, the entries in the destination prefix column of FIB table 406 are copied or otherwise input into the source prefix column of SAV table 404. In addition, the entries in the egress port column of FIB table 406 are copied or otherwise input into the ingress port column of SAV table 404. In this way, the value in the destination prefix column of FIB table 406 is the same as the value in the source prefix column of SAV table 404, and the value in the egress port column of FIB table 406 is the same as the value in the ingress port column of SAV table 404, as shown in FIG. Figure 4 shown.

[0089] Unlike DSAV, which uses new or additional protocols to build the SAV table, Figure 4 The process shown is implemented using the existing IGP framework. That is, Figure 4 The SAV table 404 in may be constructed using existing OSPF or IS-IS solutions, which is simpler and less cumbersome than DSAV.

[0090] Figure 5 5 is a schematic diagram 500 of a SAV table 504 constructed when a path through a domain includes asymmetric links (indicated by dashed arrows) according to an embodiment of the present invention. 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.

[0091] exist Figure 5In 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.

[0092] exist Figure 5 , each link in link 518 has a metric. For example, the metric of link 518 between router A and router B is 10, the metric of link 518 between router B and router C is 10, and the metric of link 518 between router C and router E is 10. The metric of link 518 between router A and router D is 5. Link 518 between router D and router E has a metric in the direction from router D to router E, which is the forward metric, and has a metric in the other direction from router E to router D, which is the reverse metric. Figure 5 As shown, the forward metric between router D and router E is 30, and the reverse metric between router E and router D is 5.

[0093] An example is provided of how to construct SAV table 504 from the perspective of router A when the paths through the IGP domain are asymmetric. It is worth noting that other routers in the domain may similarly use the same process to construct their own SAV tables.

[0094] First, router A receives link state advertisements from one or more other network nodes in the IGP domain. That is, router A receives link state advertisements from router B, router C, router D, and / or router E. In one embodiment, the link state advertisement is an LSU corresponding to the OSPF protocol or an LSP corresponding to the IS-IS protocol.

[0095] Router A performs SPF calculations based on link state advertisements received from other network nodes to determine the path through the domain. When Router A performs SPF calculations, the path from Router A to Router E is determined as: Router A → Router B → Router C → Router E (as shown by the arrow above); the path from Router E to Router A is determined as: Router E → Router D → Router A (as shown by the arrow below). Because the path from Router A to Router E is different from the path from Router E to Router A, the routing is asymmetric.

[0096] Thereafter, router A constructs FIB table 506 based on the SPF calculation. In one embodiment, FIB 506 includes a destination prefix column and an egress port column. Figure 5As shown, the entry in the destination prefix column corresponds to one of the routers in the IGP domain. For example, the destination prefix column includes prefix B corresponding to router B, prefix C corresponding to router C, prefix E corresponding to router E, and prefix D corresponding to router D. The egress port identified for each prefix indicates the port used by router A when sending a data packet with the corresponding prefix. For example, a data packet with a destination prefix of prefix C is sent from egress port B.

[0097] Router A determines that the path through the domain includes an asymmetric link (e.g., link 518 between router D and router E). In one embodiment, router A compares the metrics of each link in both directions during the SPF calculation. For example, during the SPF calculation, router A discovers that link 518 between router D and router E has different metrics in different directions. That is, router A determines that the cost of sending a packet from router D→router E is different from the cost of sending a packet from router E→router D. If any asymmetric links are detected, router A performs additional SPF calculations (which will be explained more fully below) to account for the asymmetric links. In one embodiment, the metrics are stored in a link state database (LSDB) of a network node (e.g., router A).

[0098] In one embodiment, router A receives a link state advertisement with a flag set to indicate that additional SPF calculations are needed to account for asymmetric links. In one embodiment, router A determines whether any of links 518 are asymmetric, and if so, notifies other network nodes in the IGP domain accordingly. In one embodiment, router A determines that the domain includes asymmetric links based on SPF calculations, link state advertisements, or some combination thereof.

[0099] In the example shown, the total cost of sending a data packet from router E → router D → router A is 10 (i.e., 5+5), and the total cost of sending a data packet from router E → router C → router B → router A is 30 (i.e., 10+10+10). Thus, router A determines that the best path for a data packet to be sent from router E to router A is router E → router D → router A. Since the path from router A to router E through the IGP domain is different from the path from router E to router A, asymmetric routing occurs.

[0100] In one embodiment, router A determines that the path through the domain is asymmetric after building FIB table 506. In one embodiment, router A determines that the path through the domain is asymmetric before building FIB table 506. In one embodiment, router A determines that the path through the domain is asymmetric at or about the same time as building FIB table 506.

[0101] Since the link 518 between router D and router E has different metrics in different directions, router A performs an additional SPF calculation using the reverse metric of link 518. That is, router A performs the second SPF calculation using metric 5 instead of metric 30, as shown in FIG. Figure 5 The second SPF may refer to another SPF calculation, an additional SPF calculation, a subsequent SPF calculation, or the like.

[0102] Next, router A generates SAV table 504 based on FIB table 506 and the second SPF calculation. In one embodiment, router A copies FIB table 506 but updates entries to account for asymmetric links to generate SAV table 504. For example, router A updates SAV table 504 to indicate that packets with a source prefix of prefix E will be received from router D but not from router B due to asymmetric routing.

[0103] Figure 6 6 is a schematic diagram 600 of a SAV table 604 constructed when there are static routes or routing policies for routing packets through a domain according to an embodiment of the present invention. In the example shown, various network nodes labeled routers A, B, C, D, and E are coupled together by links 618. Figure 6 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.

[0104] exist Figure 6 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.

[0105] Static routing or routing policy is a form of routing that occurs when a router uses manually configured routing entries or rules to route packets. In many cases, static routing is manually configured on a router by a network administrator. For example, a network administrator can change or update entries in a router's routing table to implement static routing or install a routing policy on a router. Static routing is the opposite of dynamic routing, also known as adaptive routing. In dynamic routing, a router determines the current conditions or metrics within a domain using, for example, an IGP, and then performs routing based on the determined conditions or metrics. Unlike dynamic routing, static routing is fixed and does not change when the network is changed or reconfigured. Static routing and dynamic routing are not mutually exclusive. Dynamic routing and static routing can be used simultaneously on a router to maximize routing efficiency and provide backup in the event that dynamic routing information exchange fails.

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

[0107] When Router A performs SPF calculation based on the above metrics, Router A determines that the best path from Router A to Router E is: Router A → Router D → Router E. This is because the total cost of the path from Router A to Router E via Router D is 20 (i.e., 10+10), which is less than the total cost of the path from Router A to Router E via Router B and Router C, which is 30 (i.e., 10+10+10). However, due to the static routes on Router A, Router A does not install the routing path from Router A to Router E via Router B and Router C into the FIB table, even though the cost of the path is the smallest. In addition, Router R does not route packets along the path that includes Router B and Router C. Instead, Router A routes packets on the path of Router A → Router B → Router C → Router E according to the static policy installed in Router A's FIB table.

[0108] In one embodiment, router A notifies other routers in the network that router A is using static routing and is subject to a routing policy that replaces SPF calculations, that SPF-calculated routing has been replaced with static routing, that routing parameters determined based on SPF calculations have not yet been installed in router A's FIB, or some combination thereof. In one embodiment, the notification sent by router A to other routers in the network is an update message, an OSPF message, an IS-IS message, or some other type of routing message. As used herein, each of these messages may be referred to as a link state advertisement.

[0109] An example is provided of how to construct SAV table 604 from the perspective of Router E when the path through the IGP domain is based on static routes or routing policies are provided. It is worth noting that other routers in the domain can similarly use the same process to construct their own SAV tables.

[0110] 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 an LSU corresponding to the OSPF protocol or an LSP corresponding to the IS-IS protocol. As an example, it is assumed that the link state advertisement received from router A specifies a static route or routing policy for routing a data packet from router A to router E.

[0111] Router E performs SPF calculations based on link state advertisements received from other network nodes to determine the path through the domain. Thereafter, Router E builds a FIB table based on the SPF calculations. The FIB built on Router E may be similar to Figure 4 and Figure 5 Therefore, a detailed description of the process will not be repeated here.

[0112] Next, Router E performs a second SPF calculation to take into account the static routes or routing policies implemented at Router A and reported in the link state advertisement by Router A. In one embodiment, Router E performs an additional SPF calculation using a value of zero (instead of a value of 10) for the metric between Router A and Router B, as shown in FIG. Figure 6 As shown. Figure 6 As shown, Router B is the next hop of Router A.

[0113] Next, router E generates a SAV table 604 based on the FIB table and the second SPF calculation. In one embodiment, the SAV table 604 includes entries of router C and router D in the ingress port column, thereby determining that the data packet received from router C or router D is valid. In one embodiment, the entry in the ingress port column of router C is Eth 1 / 0 (to C), and the entry in the ingress port column of router D is Eth1 / 1 (to D). Since the SAV table 604 does not identify a separate destination (or destination prefix) for each ingress port, the SAV table 604 can be referred to as a SAV table for router-level encoding.

[0114] In one embodiment, router E generates a SAV table 654 based on the FIB table and the second SPF calculation. In one embodiment, the SAV table 654 includes an entry for router C in one row of the ingress port column and an entry for router D in another row of the ingress port column. As before, these entries ensure that packets received from router C or router D are determined to be valid. However, the separate entries in the SAV table 654 allow each entry in the ingress port column to be associated with a specific destination (or destination group). For example, packet traffic destined for destination 192.168.1.0 / 24 would be routed from router A to router B and thus enter router E through router C, while packet traffic destined for other places (e.g., destination 192.168.2.0 / 24) would be routed from router A to router D and thus enter router E through router D. Since the SAV table 654 identifies a separate destination (or destination prefix) for each ingress port, the SAV table 654 can be referred to as a SAV table for prefix-level encoding.

[0115] Figure 7 It is an OSPFv2 router information opaque LSA 700 according to an embodiment of the present invention. OSPFv2 router information opaque LSA 700 is described in detail in IETF RFC 7770 entitled "Extensions to OSPF for Advertising Optional Router Capabilities" published by A. Lindem et al. in February 2016.

[0116] As shown, OSPFv2 Router Information Opaque LSA 700 includes an Advertisement Router field 702 and a TLV field 704. Advertisement Router field 702 includes a value indicating the router that sent OSPFv2 Router Information Opaque LSA 700. For example, Advertisement Router field 702 may include a value indicating that Router A sent OSPFv2 Router Information Opaque LSA 700. TLV field 704 is used to carry one or more TLVs, as will be explained more fully below.

[0117] Figure 8 It is the OSPFv3 router information LSA 800 according to an embodiment of the present invention. The OSPFv3 router information LSA 800 is described in detail in IETF RFC7770 entitled "Extensions to OSPF for Advertising Optional Router Capabilities" published by A. Lindem et al. in February 2016.

[0118] As shown, OSPFv3 Router Information LSA 800 includes an Advertisement Router field 802 and a TLV field 804. Advertisement Router field 802 includes a value indicating the router that sent OSPFv3 Router Information LSA 800. For example, Advertisement Router field 802 may include a value indicating that Router A sent OSPFv3 Router Information LSA 800. TLV field 804 is used to carry one or more TLVs, as will be explained more fully below.

[0119] Fig. 9 is a TLV 900 for router level encoding according to an embodiment of the present invention. TLV 900 is configured to include Figure 7 and Figure 8 In the TLV fields 704 and 804 in . In one embodiment, a network node (eg, router A) uses TLV 900 to advertise a static policy or a routing policy of the network node.

[0120] As shown, TLV 900 includes a type field 902, a length field 904, a flag field 906, and a next hop field 908. Type field 902 includes a value indicating that TLV 900 is being used to convey a static policy or a routing policy of a sending network node. Length field 904 includes a value specifying the length of TLV 900.

[0121] The flag field 906 includes a value that specifies whether traffic will be received from one network node or from different network nodes. 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 traffic will be received from multiple paths (e.g., Figure 4 The first bit of the flag field 906 may be set to a second binary value (e.g., 1) to indicate that traffic will be received from a single path (e.g., Figure 4 The network node on the top arrow in the figure receives the traffic.

[0122] Next Hop field 908 includes a value identifying the next hop of the network node that sent TLV 900. For example, when Router A sends TLV 900, the Next Hop field includes a value indicating that Router B is the next hop on the backup path to Router E.

[0123] Fig.10It is an OSPFv2 extended prefix TLV 1000 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.

[0124] As shown, OSPFv2 extended prefix TLV 1000 includes an address prefix field 1002 and a sub-TLV field 1004. Address prefix field 1002 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 1002 includes a value indicating a destination prefix, such as, Figure 6 In one embodiment, the address prefix field 1002 has a variable length. The sub-TLV field 1004 is used to carry one or more sub-TLVs, as will be explained more fully below.

[0125] Fig.11 is a sub-TLV 1100 for prefix level encoding according to an embodiment of the present invention. The sub-TLV 1100 is configured to include Fig.10 In the sub-TLV field 1004 in. In one embodiment, a network node (eg, router A) uses sub-TLV 1100 to advertise a static policy or a routing policy of the network node.

[0126] As shown, sub-TLV 1100 includes a type field 1102, a length field 1104, a prefix length field 1106, a flag field 1108, a source prefix field 1110, and a next hop field 1112. Type field 1102 includes a value indicating that sub-TLV 1100 is being used to transmit a static policy or a routing policy of a sending network node. Length field 1104 includes a value specifying the length of sub-TLV 1100.

[0127] Prefix length field 1106 includes a value that specifies the value of a prefix (e.g., the source prefix in source prefix field 1110). Flags field 1108 includes a value that specifies whether traffic is to be received from one network node or from different network nodes. For example, the first bit (e.g., bit 0) of flags field 1108 may be set to a first binary value (e.g., 0) to indicate that traffic is to be received from multiple paths (e.g., Figure 4 The first bit of the flag field 1108 may be set to a second binary value (e.g., 1) to indicate that traffic will be received from a single path (e.g., Figure 4 The network node on the top arrow in the figure receives the traffic.

[0128] Source prefix field 1110 includes a field indicating a source prefix (e.g., Figure 6 The next hop field 1112 includes a value identifying the next hop of the network node that sent the sub-TLV 1100. For example, when router A sends the sub-TLV 1100, the next hop field includes a value indicating that router B is the next hop.

[0129] As mentioned above, Fig.10 and Fig.11 For OSPFv2. OSPFv3 uses a similar process. For OSPFv3, a router link TLV may be used instead of the OSPFv2 extended prefix TLV 1000. A router link TLV (not shown) may be used to bear the sub-TLV 1100. Therefore, the encoding of OSPFv3 is similar to that of OSPFv2.

[0130] Fig.12 1 is a schematic diagram of an IS-IS sub-TLV 1200 for router-level encoding according to an embodiment of the present invention. The IS-IS sub-TLV 1200 is configured to be included in an IS-IS router capability TLV (type 242) (not shown). In one embodiment, a network node (e.g., router A) uses the IS-IS sub-TLV 1200 to advertise a static policy or a routing policy of the network node.

[0131] As shown, the IS-IS sub-TLV 1200 includes a type field 1202, a length field 1204, a flag field 1206, and a next hop field 1208. The type field 1202 includes a value indicating that the IS-IS sub-TLV 1200 is being used to transmit a static policy or a routing policy of a sending network node. The length field 1204 includes a value specifying the length of the IS-IS sub-TLV 1200.

[0132] The flag field 1206 includes a value that specifies whether traffic will be received from one network node or from different network nodes. For example, the first bit (e.g., bit 0) of the flag field 1206 can be set to a first binary value (e.g., 0) to indicate that traffic will be received from multiple paths (e.g., Figure 4 The first bit of the flag field 1206 may be set to a second binary value (e.g., 1) to indicate that traffic will be received from a single path (e.g., Figure 4 The network node on the top arrow in the figure receives the traffic.

[0133] Next Hop field 1208 includes a value identifying the next hop of the network node that sent IS-IS sub-TLV 1200. For example, when router A sends IS-IS sub-TLV 1200, the Next Hop field includes a value indicating that router B is the next hop.

[0134] Fig.13 is a schematic diagram of an IS-IS sub-TLV 1300 for prefix level encoding according to an embodiment of the present invention. The IS-IS sub-TLV 1300 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; included in a multi-topology IPv4 reachability TLV as described in IETF RFC 5120, entitled "M-ISIS: MultiTopology (MT) in Intermediate System to Intermediate Systems (IS-ISs)" published by T. Przygienda et al. in February 2008; 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 an IETF RFC 5310, entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October 2008; or included in an IETF RFC 5311, entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October 2008; or included in an IETF RFC 5312, entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October 2008; or included in an IETF RFC 5313, entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October 2008; or included in an IETF RFC 5314, entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October 2008; or included in an IETF RFC 5315, entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October 2008; or included in an IETF RFC 5316, entitled "Routing IPv6 with IS-IS" published by C. Hopps et al. in October Multi-Topology IPv6 Reachability TLV described in RFC 5120. In one embodiment, a network node (eg, router A) uses IS-IS sub-TLV 1300 to advertise the static policy or routing policy of the network node.

[0135] As shown, IS-IS sub-TLV 1300 includes a type field 1302, a length field 1304, a flag field 1306, a prefix length field 1308, a source prefix field 1310, and a next hop field 1312. Type field 1302 includes a value indicating that sub-TLV 1300 is being used to transmit a static policy or a routing policy of a sending network node. Length field 1304 includes a value specifying the length of sub-TLV 1300.

[0136] Flags field 1306 includes a value that specifies whether traffic will be received from one network node or from different network nodes. For example, the first bit (e.g., bit 0) of flags field 1306 may be set to a first binary value (e.g., 0) to indicate that traffic will be received from multiple paths (e.g., Figure 4The first bit of the flag field 1306 may be set to a second binary value (e.g., 1) to indicate that traffic will be received from a single path (e.g., Figure 4 The network node on which the traffic is received (eg, the top arrow in FIG. 14 ) is located is a network node that receives the traffic. The prefix length field 1308 includes a value that specifies the value of a prefix (eg, the source prefix in the source prefix field 1310).

[0137] Source prefix field 1310 includes a field indicating a source prefix (e.g., Figure 6 The next hop field 1312 includes a value identifying the next hop of the network node that sent the sub-TLV 1300. For example, when router A sends sub-TLV 1300, the next hop field includes a value indicating that router B is the next hop on the backup path to router E.

[0138] The disclosed embodiments are compatible with a variety of different tunnel or overlay interfaces. For example, the disclosed embodiments are compatible with Generic Routing Encapsulation (GRE). GRE is a tunneling protocol that can encapsulate a variety of network layer protocols in a virtual point-to-point link or point-to-multipoint link on an Internet Protocol network. For the embodiments disclosed herein, the underlying path follows the shortest path from router A to router E based on existing metrics without additional work. Using GRE, the source address and destination address are encapsulated for the data packet from router A to router E.

[0139] The disclosed embodiments are compatible with Multiprotocol Label Switching (MPLS). MPLS is a routing technology in telecommunications networks that directs data from one node to the next based on labels rather than network addresses. An MPLS traffic engineering (TE) tunnel routes packets from router A → router B → router C → router E, where router B is the next hop of router A. Since this is a label-switched path based on existing metrics, no additional work is required.

[0140] The disclosed embodiments are compatible with Segment Routing over IPv6 (SRv6). SRv6 is a next-generation IP bearer protocol that combines Segment Routing (SR) and IPv6. SRv6 leverages existing IPv6 forwarding technology and implements network programming through flexible IPv6 extension headers. For each segment encapsulation, the shortest path calculated by SPF is based on the use of existing metrics without additional work.

[0141] In one embodiment, a link bundling interface may be used with the disclosed embodiments. Link bundling may combine multiple point-to-point links into a single logical link to provide higher bidirectional bandwidth, redundancy, and load balancing between two routers. Virtual interfaces are assigned to the bundled links. When such link bundling is used, all underlying physical interfaces and logical layer 3 (L3) interfaces are added to the SAV table for verification.

[0142] Fig.14 The method 1400 implemented by a network node in an IGP domain according to an embodiment of the present invention. When symmetric routing exists, the method 1400 may be performed by the network node, for example, Figure 4 Router A in.

[0143] In block 1402, a network node receives a link state advertisement from one or more other network nodes in an IGP domain. In one embodiment, the network node is router A, and the other network nodes are routers B, C, D, and E.

[0144] In block 1404, the network node performs a shortest path first (SPF) calculation based on link state advertisements received from one or more other network nodes to determine one or more paths from the network node through the domain. In block 1406, the network node builds a forwarding information base (FIB) table based on the SPF calculation. In block 1408, the network node determines that the paths through the domain are symmetric. In block 1410, the network node replicates the FIB table to generate a source address validation (SAV) table.

[0145] In one embodiment, the SAV table is constructed based on IGP only and not on any additional protocol. For example, the SAV table is constructed based on IGP only, that is, based on OSPF or IS-IS protocol only, without using any additional protocol, such as a new protocol introduced or used in DSAV.

[0146] In one embodiment, the FIB table includes a destination prefix column and an egress port column; the SAV table includes a source prefix column and an ingress port column. In one embodiment, the value in the destination prefix column is the same as the value in the source prefix column; the value in the egress port column is the same as the value in the ingress port column.

[0147] In one embodiment, method 1400 further includes: receiving a data packet identifying a source address and a destination address; verifying using a SAV table that the data packet is received on an ingress port corresponding to the source address; and sending the data packet from an egress port corresponding to the destination address using a FIB table.

[0148] In one embodiment, method 1400 further includes: receiving a data packet identifying a source address and a destination address; using the SAV table to determine that the data packet was not received on an ingress port corresponding to the source address; and discarding the data packet.

[0149] Fig.15 This is a method implemented by a network node in an IGP domain according to an embodiment of the present invention. When asymmetric routing exists, the method 1500 may be performed by a network node, for example, Figure 5 Router A in.

[0150] In block 1502, the network node receives link state advertisements from one or more other network nodes in the IGP domain. In block 1504, the network node performs a first shortest path first (SPF) calculation based on the link state advertisements received from the one or more other network nodes to determine a path from the network node through the domain. In block 1506, the network node constructs a forwarding information base (FIB) table based on the first SPF calculation.

[0151] In block 1508, the network node determines that the path through the domain includes an asymmetric link. In block 1510, the network node performs a second SPF calculation using a reverse metric for the asymmetric link. In block 1512, the network node generates a source address validation (SAV) table based on the FIB and the second SPF calculation.

[0152] In one embodiment, link metrics including reverse link metrics are stored in a link state database (LSDB) of the network node. In one embodiment, the network node compares link metrics in the forward and reverse directions during a first SPF calculation to determine that a path through the domain includes an asymmetric link. In one embodiment, when receiving link state advertisements from one or more other network nodes, the network node compares link metrics in the forward and reverse directions to determine that a path through the domain includes an asymmetric link.

[0153] In one embodiment, a network node receives a message from one or more other network nodes, wherein a link connected to the one or more other network nodes is asymmetric. That is, one of the other network nodes detects the lack of symmetry and reports the situation to the network node.

[0154] Fig.16The method 1600 is implemented by a network node in an IGP domain according to an embodiment of the present invention. When the first network node (eg, router A) is subject to routing policy constraints or uses static routing, the method 1600 may be executed by the network node (eg, Figure 6 Router E).

[0155] In block 1602, a network node receives a link state advertisement from one or more other network nodes in an IGP domain. In one embodiment, the link state advertisement received from a first network node among the one or more network nodes specifies a static route or routing policy for routing packets from the first network node to the network node.

[0156] In block 1604, the network node performs a first shortest path first (SPF) calculation based on link state advertisements received from one or more other network nodes to determine one or more paths from the network node through the domain. In block 1606, the network node constructs a forwarding information base (FIB) table based on the first SPF calculation.

[0157] In block 1608, the network node performs a second SPF calculation on the metric between the first network node and the second network node using a value of zero according to the static route or routing policy. In block 1610, the network node generates a source address validation (SAV) table based on the FIB and the second SPF calculation.

[0158] In one embodiment, the method further comprises: determining that one of the paths through the domain includes an asymmetric link; performing a second SPF calculation using: a reverse metric of the asymmetric link; and a value of zero for the metric between the first network node and the second network node according to a static route or a routing policy.

[0159] In one embodiment, the second network node is the next hop of the first network node. Figure 6 In one embodiment, the SAV table includes a destination port corresponding to a source prefix.

[0160] In one embodiment, the link state advertisement received from the first network node includes a type length value (TLV) field. In one embodiment, the TLV in the TLV field includes a flag field and a next hop field. In one embodiment, the value in the flag field is zero and the value in the next hop field identifies the second network node. In one embodiment, the link state advertisement is an Open Shortest Path First version 2 (OSPFv2) Router Information Opaque Link State Advertisement or an Open Shortest Path First version 3 (OSPFv3) Router Information Link State Advertisement.

[0161] In one embodiment, the link state advertisement received from the first network node includes a type length value (TLV) field. In one embodiment, the TLV in the TLV field includes an address prefix field and a sub-type length value (TLV) field. In one embodiment, the address prefix field identifies a destination prefix, and the sub-TLV in the sub-TLV field includes a flag field, a source prefix field, and a next hop field. In one embodiment, the value in the flag field is 1, the value in the source prefix field identifies the source, and the value in the next hop field identifies the second network node. In one embodiment, the link state advertisement is an extended prefix opaque link state advertisement, and the TLV is an extended prefix TLV or a router link TLV.

[0162] In one embodiment, the link state advertisement received from the first network node includes a type length value (TLV) field. In one embodiment, the TLV in the TLV field includes a sub-TLV field, and the sub-TLV in the sub-TLV field includes a flag field and a next hop field. In one embodiment, the value in the flag field is zero, and wherein the value in the next hop field identifies the second network node. In one embodiment, the TLV is an IS-IS router capability TLV.

[0163] In one embodiment, the link state advertisement received from the first network node includes a type length value (TLV) field, and the TLV in the TLV field includes a sub-TLV field. In one embodiment, the sub-TLV in the sub-TLV field includes a flag field, a source prefix field, and a next hop field. In one embodiment, the value in the flag field is zero, the value in the source prefix field identifies the source, and the value in the next hop field identifies the second network node. In one embodiment, the TLV is 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.

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

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

[0166] Processor / processing device 1730 is implemented by hardware and software. Processor / processing device 1730 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 1730 communicates with inlet port / inlet device 1710, receiver unit / receiving device 1720, transmitter unit / transmitting device 1740, outlet port / exit device 1750, and memory / memory device 1760. Processor / processing device 1730 includes routing module 1770. Routing module 1770 is capable of implementing the methods disclosed herein. Therefore, the inclusion of routing module 1770 provides substantial improvements to the functionality of network device 1700 and implements the transition of network device 1700 to different states. Alternatively, routing module 1770 is implemented as instructions stored in memory / memory device 1760 and executed by processor / processing device 1730.

[0167] The network device 1700 may also include an input and / or output (I / O) device or I / O device 1780 for data transmission to and from a user. The I / O device or I / O device 1780 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 1780 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.

[0168] Memory / storage device 1760 includes one or more magnetic 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. Memory / storage device 1760 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).

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

[0170] 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: receiving link state advertisements from one or more other network nodes in the IGP domain; performing a shortest path first (SPF) calculation based on the link state advertisements received from the one or more other network nodes to determine one or more paths from the network node through the domain; Constructing a forwarding information base (FIB) table based on the SPF calculation; determining that the path through the domain is symmetric; and The FIB table is replicated to generate a source address verification (SAV) table.

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 FIB table includes a destination prefix column and an egress port column, and wherein the SAV table includes a source prefix column and an egress port column.

4. The method according to any one of claims 1 to 3, characterized in that The value in the destination prefix column is the same as the value in the source prefix column, and wherein the value in the egress port column is the same as the value in the ingress port column.

5. The method according to any one of claims 1 to 4, characterized in that Also includes: receiving a data packet identifying a source address and a destination address; verifying, using the SAV table, that the packet was received on an ingress port corresponding to the source address; as well as The data packet is sent from an egress port corresponding to the destination address using the FIB table.

6. The method according to any one of claims 1 to 4, characterized in that Also includes: receiving a data packet identifying a source address and a destination address; determining, using the SAV table, that the packet was not received on an ingress port corresponding to the source address; as well as Either drop the packet or send the packet somewhere for further inspection.

7. A method implemented by a network node in an Interior Gateway Protocol (IGP) domain, characterized in that: include: receiving link state advertisements from one or more other network nodes in the IGP domain; performing a first shortest path first (SPF) calculation based on the link state advertisements received from the one or more other network nodes to determine one or more paths from the network node through the domain; Constructing a forwarding information base (FIB) table based on the first SPF calculation; determining that one of the paths through the domain includes an asymmetric link; performing a second SPF calculation using the reverse metric of the asymmetric link; and A source address verification (SAV) table is generated based on the first SPF calculation and the second SPF calculation.

8. The method according to claim 7, characterized in that Link metrics including the reverse link metric are stored in a link state database (LSDB) of the network node.

9. The method according to any one of claims 7 and 8, characterized in that Also includes: During the first SPF calculation, the link metrics are compared in a forward and reverse direction to determine that the path through the domain includes the asymmetric link.

10. The method according to any one of claims 7 and 8, characterized in that Also includes: When the link state advertisements are received from the one or more other network nodes, the link metrics are compared in a forward direction and a reverse direction to determine that the path through the domain includes the asymmetric link.

11. The method according to any one of claims 7 and 8, characterized in that Also includes: A message is received from the one or more other network nodes, wherein links connected to the one or more other network nodes are asymmetric.

12. A method implemented by a network node in an Interior Gateway Protocol (IGP) domain, characterized in that: include: receiving a link state advertisement from one or more other network nodes in the IGP domain, wherein the link state advertisement received from a first network node among the one or more network nodes specifies a static route or a routing policy for routing a data packet from the first network node to the network node; performing a first shortest path first (SPF) calculation based on the link state advertisements received from the one or more other network nodes to determine one or more paths from the network node through the domain; Constructing a forwarding information base (FIB) table based on the first SPF calculation; performing a second SPF calculation on a metric between the first network node and a second network node using a value of zero according to the static route or the routing policy; and A source address verification (SAV) table is generated based on the FIB and the second SPF calculation.

13. The method according to claim 12, characterized in that Also includes: determining that one of the paths through the domain includes an asymmetric link; The second SPF calculation is performed using: a reverse metric of the asymmetric link; as well as According to the static route or the routing policy, the value of the metric used between the first network node and the second network node is zero.

14. The method according to any one of claims 12 and 13, characterized in that The second network node is a next hop of the first network node.

15. The method according to any one of claims 12 and 13, characterized in that The SAV table includes a destination port corresponding to a source prefix.

16. The method according to any one of claims 12 to 15, characterized in that The link state advertisement received from the first network node includes a type-length-value (TLV) field, wherein the TLV in the TLV field includes a flag field and a next hop field, wherein the value in the flag field is zero, and wherein the value in the next hop field identifies the second network node.

17. The method according to claim 16, characterized in that The link state advertisement is an Open Shortest Path First Version 2 (OSPFv2) router information opaque link state advertisement or an Open Shortest Path First Version 3 (OSPFv3) router information link state advertisement.

18. The method according to any one of claims 12 to 15, characterized in that The link state advertisement received from the first network node includes a type-length-value (TLV) field, wherein the TLV in the TLV field includes an address prefix field and a sub-type-length-value (TLV) field, wherein the address prefix field identifies a destination prefix; the sub-TLV in the sub-TLV field includes a flag field, a source prefix field, and a next hop field, wherein the value in the flag field is 1, wherein the value in the source prefix field identifies a source, and wherein the value in the next hop field identifies the second network node.

19. The method according to claim 18, characterized in that The link state advertisement is an extended prefix opaque link state advertisement, and the TLV is an extended prefix TLV or a router link TLV.

20. The method according to any one of claims 12 to 15, characterized in that The link state advertisement received from the first network node includes a type-length-value (TLV) field, wherein a TLV in the TLV field includes a sub-TLV field, wherein the sub-TLV in the sub-TLV field includes a flag field and a next hop field, wherein a value in the flag field is zero, and wherein a value in the next hop field identifies the second network node.

21. The method according to claim 20, characterized in that The TLV is an Intermediate System to Intermediate System (IS-IS) router capabilities TLV.

22. The method according to any one of claims 12 to 15, characterized in that The link state advertisement received from the first network node includes a type-length-value (TLV) field, wherein a TLV in the TLV field includes a sub-TLV field, wherein the sub-TLV in the sub-TLV field includes a flag field, a source prefix field, and a next hop field, wherein a value in the flag field is zero, wherein a value in the source prefix field identifies a source, and wherein a value in the next hop field identifies the second network node.

23. The method according to claim 22, characterized in that The TLV is 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.

24. 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 23.

25. 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 23.

26. 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 23.

Images