Network traffic transmission based on next hop indication

Abstract

The embodiment of the invention relates to network traffic transmission based on next hop indication. In some implementations, a network device may receive an indication of a next hop of the network device and link quality information for the next hop. The network device may transmit network traffic based on the indication of the next hop and the link quality information of the next hop.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to U.S. Provisional Patent Application No. 63 / 594,202, filed on October 30, 2023, and entitled “Border Gateway Protocol Topology Discovery for Global Load Balancing in CLOS Networks.” The disclosure of the prior application is considered part of and is incorporated by reference into this patent application. Background Art

[0003] Network devices such as routers relay packets from a source device to a destination device across a network. When a network experiences congestion, network devices can drop packets, which can relieve the congestion. The destination device does not receive the dropped packets. Summary of the invention

[0004] Some implementations described herein relate to a method. The method may include receiving, by a network device, an indication of a next-next hop of the network device and link quality information of the next-next hop. The method may include transmitting, by the network device, network traffic based on the indication of the next-next hop and the link quality information of the next-next hop.

[0005] Some implementations described herein relate to a network device. The network device may include one or more memories and one or more processors. The one or more processors may receive a Border Gateway Protocol (BGP) update message that includes an indication of a next hop of the network device. The one or more processors may transmit network traffic based on the indication of the next hop.

[0006] Some implementations described herein relate to a non-transitory computer-readable medium storing an instruction set. When executed by one or more processors of a network device in a Clos network, the instruction set may enable the network device in the Clos network to receive an indication of a next hop of the network device and link quality information of a next next hop. When executed by one or more processors of a network device in a Clos network, the instruction set may enable the network device in the Clos network to transmit network services based on the indication of the next next hop and the link quality information of the next next hop. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A-1B is a diagram of an example implementation associated with next-next-hop indication-based network traffic transmission.

[0008] Figure 2 is a diagram of an example implementation associated with a Next Next Hop Node (NNHN) capability for BGP update messages.

[0009] Figure 3 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0010] Figure 4 is a diagram of example components of a device associated with next-next-hop indication-based network traffic transmission.

[0011] Figure 5 is a diagram of example components of a device associated with next-next-hop indication-based network traffic transmission.

[0012] Figure 6 is a flow diagram of an example process associated with transmission of network traffic based on a next-next-hop indication. DETAILED DESCRIPTION

[0013] The following detailed description of example implementations refers to the accompanying drawings.The same reference numbers in different drawings may identify the same or similar elements.

[0014] For load balancing purposes, a network device (e.g., a router, a switch, etc.) can forward packets along a route with multiple next hops by hashing the packet flow to the next hop. For example, a network device can hash the packet flow to different equal cost multipath (ECMP) links of the route. In a data center (DC) fabric underlay routing, a network device can use external border gateway protocol (EBGP) hop-by-hop routing to route the packet flow. For example, a network device can use hop-by-hop EBGP underlay routing in a Clos network.

[0015] Congestion may increase packet loss and latency. For example, congestion may affect artificial intelligence (AI) / machine learning (ML) services, which may have strict loss and latency requirements (e.g., according to service level agreements (SLAs) in wide area networks (WANs)). Uneven flow hashing may cause congestion anywhere in the network structure. For example, uneven flow hashing may cause congestion in a Clos structure, which may adopt a spine-leaf architecture. If a link becomes congested due to uneven hashing, the network device for which the link is the next hop link can use dynamic load balancing to adjust the hashing and thereby divert the packet flow away from the link, which can alleviate congestion. For example, in response to detecting congestion on a local ECMP link from a leaf node to a spine node, the leaf node can use dynamic load balancing to hash the packet flow to a backup ECMP link on the leaf node, which can alleviate congestion. In this example, the congestion is local to the leaf node because the congestion is on the next hop link of the leaf node.

[0016] Many cases of link congestion cannot be solved using dynamic load balancing. For example, if all of the next-hop links of a network device are congested, dynamic load balancing cannot help the network device alleviate congestion. For example, if congestion occurs on a remote link from a spine node to the first leaf node, dynamic load balancing on the spine node cannot help alleviate congestion because the spine node does not have any alternative links to reach the leaf node. In this example, other leaf nodes hash the packet stream to an alternative spine node to alleviate link congestion.

[0017] Some implementations described herein enable network devices to transmit network traffic based on the next hop of the network device. For example, the network device can determine that the link quality of the next next hop is poor (e.g., the next next hop is congested), and guide the network traffic away from the next hop that can forward the traffic to the next next hop. For example, the network device can use the combined link quality of each next hop and the next next hop corresponding to each next hop in the next hop as feedback for dynamic load balancing. In some examples, the network device can transmit network traffic in a Clos network.

[0018] The network device may use a non-link state protocol, such as BGP, to advertise and calculate topology information (e.g., network layer reachability information (NLRI), such as next hop information). In some examples, the network device (e.g., a BGP speaker) may use the NNHN capability in the next hop dependent capabilities attribute (NHC) to discover the next hop information of the BGP route. For example, the next hop information may be encoded as a capability type-length-value (TLV) in the NHC. In some examples, the network device may use an autonomous system (AS) path attribute to discover the next hop information of the BGP route. The NHC and / or AS path attributes may be attributes in a BGP update message received by the network device.

[0019] Thus, the network device can detect and alleviate remote congestion on the next-hop link, which can be referred to as global load balancing (GLB). For example, the next-hop information can enable the network device to determine how the remote congestion affects the local load balancing decision (e.g., dynamic load balancing) of the network device. For example, the network device can use GLB to alleviate congestion on the next-hop link by transferring the service to an alternative node. Therefore, GLB can reduce the amount of bandwidth occupied due to congestion on the network structure, thereby reducing packet loss and delay and / or enabling the network structure to meet SLAs.

[0020] GLB in a Clos network can reduce overhead because network devices in the Clos network can perform GLB based on the next hop and the next next hop of the network device (e.g., without using information for any further hops of the network device). Thus, the Clos network can avoid transmitting indications of any hops beyond the next next hop and / or link quality information of hops beyond the next next hop. For example, to implement GLB, each node in the Clos network can track the link congestion status of the node's next hop and the next next hop (e.g., only the next hop and the next next hop), and / or the next hop and the next next hop (e.g., only the next hop and the next next hop) for each route. For example, a node can flood link quality information toward the node's direct neighbors without propagating the link quality information beyond the direct neighbors, thereby avoiding scaling problems (e.g., scaling problems that exist in, for example, Interior Gateway Protocol (IGP) flooding).

[0021] In a Clos network, congestion on a link beyond the next-next hop does not affect the GLB because only the first two hops (e.g., the next hop and the next-next hop) of a given route are required for the GLB. For example, due to the topology (e.g., design) of the Clos network, link congestion may affect the load balancing decisions of the node experiencing the link congestion and any previous hop nodes (e.g., only the node and the previous hop node). Link congestion may affect the load balancing decisions of all previous layer nodes equally, and thus, any previous previous hop (e.g., a node on the previous previous layer of the Clos network) may refrain from attempting to alleviate link congestion by changing the load balancing decisions for traffic forwarded toward the previous hop node (e.g., a node on the previous layer of the Clos network).

[0022] Extensions to non-link state protocols, such as BGP, can enable network devices (e.g., BGP speakers) to implement GLB by determining the topology. In some examples, a BGP speaker can use BGP to determine NLRIs, such as the next hop and next-next hop of the BGP speaker. Based on the NLRI, the BGP speaker can make optimal forwarding decisions that alleviate remote congestion on the next-next hop link. The NNHC capability can enable a network device to receive next-next hop information for multiple next-next hops of a next hop. AS path attributes can avoid introducing additional overhead into BGP.

[0023] Figure 1A to Figure 1B 1 is a diagram of an example implementation 100 associated with next-next-hop indication-based network traffic transmission. Figure 1A to Figure 1B As shown, example implementations 100A and 100B include multiple network devices (eg, nodes) arranged in multiple levels in a Clos network. Figure 3-Figure 5 Describe these network devices in more detail.

[0024] Example implementation 100A relates to a three-level Clos network using a spine-leaf architecture. The three-level Clos network includes two layers of network devices. One layer includes spine nodes S1 to S3, and the other layer includes leaf nodes T1 to T4. As shown, each spine node can communicate with each leaf node via a corresponding link, and each leaf node can communicate with each spine node via a corresponding link. For example, leaf nodes T1 to T4 can forward packets to each other via spine nodes S1 to S3 via links. Leaf nodes T1 to T4 and spine nodes S1 to S3 can be BGP speakers.

[0025] Leaf nodes T1 to T4 and spine nodes S1 to S3 can announce routing information to each other, which can enable forwarding packets within a three-level Clos network. For example, leaf nodes T1 to T4 can transmit to each spine node in spine nodes S1 to S3 an indication that leaf nodes T1 to T4 are the next hop of spine nodes S1 to S3. For example, leaf nodes T2 to T4 can transmit to spine node S1 an indication that leaf nodes T2 to T4 are the next hop of spine node S1. In response to receiving an indication that leaf nodes T2 to T4 are the next hop of spine nodes S1 to S3, spine nodes S1 to S3 can transmit to leaf nodes T1 to T4 an indication that spine nodes S1 to S3 are the next hop of leaf nodes T1 to T4 and that leaf nodes T1 to T4 are the next next hop of other nodes in leaf nodes T1 to T4. For example, spine node S1 can transmit to leaf node T1 an indication of the next next hop of leaf node T1.

[0026] As shown in reference numeral 110, leaf node T1 may receive an indication of the next next hop of leaf node T1 from spine node S1. Additionally or alternatively, leaf node T1 may also receive an indication of the next hop of leaf node T1. For example, leaf node T1 may receive an indication from spine node S1 that spine node S1 is the next hop of leaf node T1.

[0027] Table 1 below shows the next hop and the next-next hop of the route on the leaf node T1. For example, the three-level Clos network can provide three possible routes from the leaf node T1 to the leaf node T2: a first route via the next hop A and the next-next hop X2; a second route via the next hop B and the next-next hop Y2; and a third route via the next hop C and the next-next hop Z2. The three-level Clos network can provide three possible routes from the leaf node T1 to the leaf node T3: a first route via the next hop A and the next-next hop X3; a second route via the next hop B and the next-next hop Y3; and a third route via the next hop C and the next-next hop Z3. The three-level Clos network can provide three possible routes from the leaf node T1 to the leaf node T4: a first route via the next hop A and the next-next hop X4; a second route via the next hop B and the next-next hop Y4; and a third route via the next hop C and the next-next hop Z4.

[0028]

[0029] Table 1

[0030] In some examples, the leaf node T1 may receive an indication of the next hop via a link state protocol. In a link state protocol, each node in the network may use a connection graph between nodes in the network to calculate the best path from the node to each other destination in the network. Examples of link state protocols may include Open Shortest Path First (OSFP), Intermediate System to Intermediate System (IS-IS), IGP, Fat Tree Routing (RIFT) protocol, etc. The leaf node T1 may use a link state protocol to calculate the next hop information and / or advertise link quality.

[0031] In some aspects, the leaf node T1 may receive an indication of the next hop via a non-link state protocol such as a distance vector routing protocol. In a distance vector routing protocol, each node in the network may use the number of hops (e.g., "distance") that a packet will traverse to determine the best path for the packet. Examples of non-link state protocols may include BGP, Routing Information Protocol (RIP), Interior Gateway Routing Protocol (IGRP), etc.

[0032] In some aspects, the non-link state routing protocol may be BGP. BGP may be an external gateway protocol that enables nodes to exchange routing information. Examples of BGP may include internal BGP (iBGP), external BGP (eBGP), etc. In some aspects, the leaf node T1 may receive a BGP update message containing an indication of a next hop. The BGP update message may carry routing information of an updated route between nodes. The BGP update message may carry the attributes of the next hop of the conveying node (e.g., leaf node T1). The leaf node T1 may receive a BGP update message in response to a change in topology and / or configuration (e.g., when a configuration for performing GLB is activated).

[0033] In some aspects, the indication of the next hop is a BGP identifier in the NNHN capability of the BGP update message. For example, the leaf node T1 can use the BGP update message to discover one or more next hops and / or next hops. Therefore, the NNHN capability can enable topology discovery (e.g., discovery of the next hop).

[0034] In some aspects, the BGP update message may be associated with an eBGP session. For example, the leaf node T1 may receive the BGP update message through one or more eBGP sessions. The leaf node T1 may use eBGP to discover the topology of the three-level Clos network based on the NNHN capability.

[0035] In some aspects, the next hop itself can be configured for the eBGP session. For example, spine node S1 can advertise one or more routes to leaf node T1 via the eBGP session with the next hop itself activated. For example, in addition to identifying leaf nodes T2 to T4 as the next next hop of leaf node T1, spine node S1 can also identify spine node S1 as the next hop of leaf node T1.

[0036] In some aspects, the NNHN capability may include multiple BGP identifiers corresponding to multiple next hops of the leaf node T1. For example, the BGP identifiers may correspond to leaf nodes T2 to T4. In some examples, the NNHN capability may carry downstream BGP identifiers of all ECMP links corresponding to the next hops of the leaf node T1.

[0037] In some aspects, the BGP update message may further include an indication of the next hop of the leaf node T1, which is associated with the next next hop. For example, the BGP update message may indicate that for a route from the leaf node T1 to another of the leaf nodes, the spine node S1 is the next hop associated with the next next hop of the route. For example, the leaf node T1 may receive an indication with a prefix of the next hop and the next next hop, and associate the next next hop information with the corresponding next hop.

[0038] In some aspects, the indication of the next next hop can be an AS number in the AS path attribute of the BGP update message. For example, leaf node T1 can retrieve the next next hop via the BGP AS path attribute, and use the BGP AS path attribute to discover the topology of the three-level Clos network (e.g., the next hop and / or the next next hop). For the three-level Clos network, the second AS number in the AS path attribute can indicate the next next hop. In the case where NNHN is not available, the BGP AS path attribute can be used.

[0039] In some aspects, leaf nodes T1 to T4 and spine nodes S1 to S3 can be arranged in a Clos network (e.g., a three-level Clos network). For example, as shown, leaf nodes T1 to T4 can be in the first level of a three-level Clos network, and spine nodes S1 to S3 can be in the second level of a three-level Clos network. Each leaf node T1 to T4 and spine node S1 to S3 can be associated with an AS number that is unique in the Clos network. For example, no two nodes can share the same AS number. Therefore, in the case where the AS path attribute is used to identify the next hop, each node in the Clos network can have an AS number that is unique to the Clos network.

[0040] Based on the indication of the next hop (e.g., received via a BGP update message), leaf node T1 can track the next hop link and / or the corresponding next hop link of each route advertised by leaf nodes T2 to T4. For example, leaf node T1 can track the information shown in Table 1 above.

[0041] Additionally or alternatively, leaf nodes T1 to T4 and / or spine nodes S1 to S3 can receive and track link quality information of the next hop. In some examples, leaf nodes T1 to T4 and / or spine nodes S1 to S3 can use the AS number in the link quality message to associate link quality with the hop. Link quality information may include the congestion status of any suitable link between nodes in the three-level Clos network. In some examples, leaf nodes T1 to T4 and spine nodes S1 to S3 can exchange congestion status in real time.

[0042] In the event that link X4 (e.g., the link from spine node S1 to leaf node T4) is congested, spine node S1 may flood link quality information to all neighboring nodes of spine node S1, indicating that link X4 is congested. For example, a packet forwarder of spine node S1 may flood link quality information, which may be received by leaf nodes T1 to T4 within a few milliseconds. For example, leaf node T1 may receive link quality information indicating that link X4 is congested.

[0043] As shown in the reference numeral 120, the leaf node T1 can transmit network traffic based on an indication of a next-next hop. For example, the leaf node T1 can transmit network traffic to the leaf node T4 based on the leaf node T4 being the next-next hop of the route followed by the network traffic. In some examples, the leaf node T1 can also transmit network traffic based on link quality information (e.g., based on an indication that the link X4 is congested). In some aspects, the leaf node T1 can transmit network traffic based on the next hop (e.g., spine node S1) being associated with the next-next hop (e.g., leaf node T4).

[0044] For example, leaf node T1 may use the link quality of the <next hop, next next hop> tuple (e.g.,<S1,T4> tuple) to make load balancing decisions. For example, in response to determining that link X4 is congested, leaf node T1 can avoid hashing network traffic (e.g., packet flow) to spine node S1 through link A. For example, leaf node T1 can transmit network traffic to spine node S2 through link B, and spine node S2 can forward the network traffic to leaf node T4 through link Y4. Additionally or alternatively, leaf node T1 can transmit network traffic to spine node S3 through link C, and spine node S3 can forward network traffic to leaf node T4 through link Z4. Avoiding hashing network traffic to spine node S1 can enable spine node S1 to avoid forwarding network traffic through link X4, thereby using GLB to alleviate congestion on link X4.

[0045] Although some of the examples described herein are discussed with respect to leaf node T1, the implementations provided herein can be applied to any suitable network device. For example, any leaf node T1 to T4, and / or any spine node S1 to S3, can perform any suitable operation similar to the operation described above as performed by leaf node T1. For example, any leaf node T1 to T4 can receive an indication of the next hop and / or transmit network traffic based on the indication of the next hop, as described above with reference to leaf node T1. Additionally or alternatively, any spine node S1 to S3 can transmit an indication of the next hop (e.g., to any leaf node T1 to T4).

[0046] refer to Figure 1B , example implementation 100B involves a five-level Clos network that employs a spine-leaf architecture. The five-level Clos network includes three layers of network devices. One layer includes leaf nodes T1.0 to T1.9, another layer includes spine nodes S2.0 to S2.5, and another layer includes super spine nodes SS3.0 and SS3.1. Leaf nodes T1.0 to T1.4 belong to a first pod ("POD-1"), and leaf nodes T1.5-T1.9 belong to a second pod ("POD-2").

[0047] As shown, each leaf node can communicate with each spine point through a corresponding link, and each leaf node can communicate with each leaf node through a corresponding link. In addition, each spine node can communicate with each super spine node through a corresponding link, and each super spine node can communicate with each spine node through a corresponding link. For example, leaf nodes T1.0 to T1.9 can forward packets to each other through links via spine nodes S2.0 to S2.5 and via super spine nodes SS3.0 and SS3.1. Leaf nodes T1.0 to T1.9, spine nodes S2.0 to S2.5, and super spine nodes SS3.0 and SS3.1 can be BGP speakers.

[0048] and Figure 1A Unlike the three-level Clos network shown, where the next-next hop may only exist on leaf nodes, the five-level Clos network may include next-next hops on spine nodes and super-spine nodes. For routes advertised by leaf nodes in the same pod as the leaf node receiving the advertisement (e.g., for routes advertised by leaf node T1.0 and received at leaf node T1.1 or leaf node T1.2), the above Figure 1A GLB may be performed in a similar manner to that described for the three-level Clos network shown in FIG. 1. For routes advertised by a leaf node in a different pod than the leaf node that receives the advertisement (e.g., for a route advertised by leaf node T1.9 and received at leaf node T1.0), nodes in a five-level Clos network may perform GLB by tracking the next hop and / or the next-next hop (e.g., only the next hop and / or the next-next hop).

[0049] Leaf nodes T1.0 to T1.9, spine nodes S2.0 to S2.5, and super spine nodes SS3.0 and SS3.1 can announce routing information to each other, which can enable forwarding packets within a five-level Clos network. For example, leaf nodes T1.0 to T1.9, spine nodes S2.0 to S2.5, and super spine nodes SS3.0 and SS3.1 can transmit and / or receive an indication of the next hop of a node. In some aspects, a node can receive an indication of the next hop, and based on the indication of the next hop, transmit another indication that does not include the indication of the next hop. For example, spine nodes S2.0 to S2.5 and / or super spine nodes SS3.0 and SS3.1 can transmit another BGP update message that does not include the NNHN capability based on a BGP update message that includes the NNHN capability. Therefore, the next hop information can be consumed by the node that receives the next hop information, and the node can refrain from further propagating the next hop information.

[0050] For example, leaf nodes T1.0 to T1.9 can transmit to each of the spine nodes S2.0 to S2.5 an indication that leaf nodes T1.0 to T1.9 are the next hops of spine nodes S2.0 to S2.5. Spine nodes S2.0 to S2.5 can transmit to each of the super spine nodes SS3.0 and SS3.1 an indication that spine nodes S2.0 to S2.5 are the next hops of super spine nodes SS3.0 and SS3.1 and leaf nodes T1.0 to T1.9 are the next next hops of super spine nodes SS3.0 and SS3.1. Super spine nodes SS3.0 and SS3.1 can transmit to each of the spine nodes S2.0 to S2.5 an indication that super spine nodes SS3.0 and SS3.1 are the next hops of spine nodes S2.0 to S2.5 and other spine nodes in spine nodes S2.0 to S2.5 are the next next hops of spine nodes S2.0 to S2.5. Spine nodes S2.0 to S2.5 may transmit to each of leaf nodes T1.0 to T1.9 an indication that spine nodes S2.0 to S2.5 are the next hops of leaf nodes T1.0 to T1.9 and super spine nodes SS3.0 and SS3.1 are the next next hops of leaf nodes T1.0 to T1.9.

[0051] For example, leaf nodes T1.5 to T1.9 may transmit to spine nodes S2.3 to S2.5 an indication that leaf nodes T1.5 to T1.9 are the next hops of spine nodes S2.3 to S2.5. For example, leaf node T1.9 may transmit to spine nodes S2.3 to S2.5 an indication that leaf node T1.9 is the next hop of spine nodes S2.3-S2.5. In response to receiving an indication that leaf node T1.9 is the next hop of spine nodes S2.3-S2.5, spine nodes S2.3 to S2.5 may transmit to super spine nodes SS3.0 and SS3.1 an indication that spine nodes S2.3 to S2.5 are the next hops of super spine nodes SS3.0 and SS3.1 and that leaf nodes T1.5 to T1.9 are the next next hops of super spine nodes SS3.0 and SS3.1. For example, spine node S2.3 can transmit to super spine node SS3.0 an indication that spine node S2.3 is the next hop of super spine node SS3.0 and leaf node T1.9 is the next next hop of super spine nodes SS3.0 and SS3.1. Super spine nodes SS3.0 and SS3.1 can transmit to each of spine nodes S2.0 to S2.2 an indication that super spine nodes SS3.0 and SS3.1 are the next hops of spine nodes S2.0 to S2.2 and spine nodes S2.3 to S2.5 are the next next hops of spine nodes S2.0 to S2.2. For example, super spine node SS3.0 can transmit to spine node S2.0 an indication that super spine node SS3.0 is the next hop of spine node S2.0 and spine node S2.3 is the next next hop of spine node S2.0. Spine nodes S2.0 to S2.2 can transmit to leaf nodes T1.0 to T1.4 an indication that spine nodes S2.0 to S2.2 are the next hops of leaf nodes T1.0 to T1.4 and that super spine nodes SS3.0 and SS3.1 are the next next hops of leaf nodes T1.0 to T1.4. For example, spine node S2.0 can transmit to leaf node T1.0 an indication that spine node S2.0 is the next hop of leaf node T1.0 and that super spine node SS3.0 is the next next hop of leaf node T1.0.

[0052] As shown in reference numeral 130, spine node S2.0 can receive an indication of the next next hop of spine node S2.0 from super spine node SS3.0. In some examples, spine node S2.0 can receive indications of multiple next next hops (e.g., spine nodes S2.3-S2.5). Additionally or alternatively, spine node S2.0 can receive an indication of the next hop of spine node S2.0. For example, spine node S2.0 can receive an indication from super spine node SS3.0 that super spine node SS3.0 is the next hop of spine node S2.0.

[0053] Table 2 below shows the next hop and next next hop of the route on spine node S2.0. For example, network traffic forwarded from spine node S2.0 and destined for leaf nodes T1.7 to T1.9 may pass through link g and then link m, n, or p, or through link j and then link q, r, or s.

[0054]

[0055] Table 2

[0056] As shown in reference numeral 140, leaf node T1.0 can receive an indication of the next next hop of leaf node T1.0 from spine node S2.0. In some examples, leaf node T1.0 can receive indications of multiple next next hops (e.g., super spine nodes SS3.0 and SS3.1). Additionally or alternatively, leaf node T1.0 can receive an indication of the next hop of leaf node T1.0. For example, leaf node S1.0 can receive an indication from spine node S2.0 that spine node 2.0 is the next hop of leaf node S1.0.

[0057] Table 3 below shows the next hop and next next hop of the route on leaf node T1.0. For example, the network traffic forwarded from leaf node T1.0 and destined for leaf node T1.4 may pass through link a and then link d, through link b and then link e, or through link c and then link f. The network traffic forwarded from leaf node T1.0 and destined for leaf node T1.8 or T1.9 may pass through link a and then link g or j, through link b and then link h or k, or through link c and then link i or l.

[0058]

[0059] Table 3

[0060] In some examples, the spine node S2.0 and / or the leaf node T1.0 may receive an indication of the next hop via a link state protocol. The spine node S2.0 and / or the leaf node T1.0 may use the link state protocol to calculate the next hop information and / or to announce the link quality. In some aspects, the spine node S2.0 and / or the leaf node T1.0 may receive an indication of the next hop via a non-link state protocol (such as a distance vector routing protocol).

[0061] In some aspects, the non-link state routing protocol may be BGP. In some aspects, the spine node S2.0 and / or the leaf node T1.0 may receive a BGP update message containing an indication of the next next hop. The BGP update message may carry the attribute of the next next hop of the conveying node. For example, the BGP message received by the spine node S2.0 may indicate that the spine nodes S2.3-S2.5 are the next next hops of the spine node 2.0. The BGP update message received by the leaf node T1.0 may carry an indication that the super spine node SS3.0 and / or SS3.1 are the next next hops of the leaf node T1.0. The spine node S2.0 and / or the leaf node T1.0 may receive a BGP update message in response to a change in topology and / or configuration (e.g., when the configuration for executing GLB is activated).

[0062] In some aspects, the indication of the next hop can be a BGP identifier in the NNHN capability of the BGP update message. For example, the spine node S2.0 can use the BGP update message received by the spine node S2.0 to discover one or more next hops and / or the next next hop. For example, the leaf node T1.0 can use the BGP update message received by the leaf node T1.0 to discover one or more next hops and / or the next next hop. Therefore, the NNHN capability can be able to achieve topology discovery (e.g., discovery of the next next hop).

[0063] In some aspects, the BGP update message can be associated with an eBGP session. For example, the spine node S2.0 and / or the leaf node T1.0 can receive the BGP update message through one or more eBGP sessions. The spine node S2.0 and / or the leaf node T1.0 can use eBGP to discover the topology of the five-level Clos network based on the NNHN capability.

[0064] In some aspects, the next hop itself can be configured for the eBGP session. For example, super spine nodes SS3.0 and / or SS3.1 can notify one or more routes to spine node S2.0 via the eBGP session with the next hop itself. For example, in addition to identifying spine nodes S2.3-S2.5 as the next next hop of spine node S2.0, super spine nodes SS3.0 and / or SS3.1 can also identify super spine nodes SS3.0 and / or SS3.1 as the next hop of spine node S2.0. Additionally or alternatively, spine node S2.0 can notify one or more routes to leaf node T1.0 via the eBGP session with the next hop itself. For example, in addition to identifying super spine nodes SS3.0 and / or SS3.1 as the next next hop of leaf node T1.0, spine node S2.0 can also identify spine node S2.0 as the next hop of leaf node T1.0.

[0065] In some aspects, the NNHN capability may include multiple BGP identifiers corresponding to multiple next hops of the spine node S2.0 and / or the leaf node T1.0. For example, the BGP identifier of the BGP update message received by the spine node S2.0 may correspond to the spine node S2.3-S2.5. Additionally or alternatively, the BGP identifier of the BGP update message received by the leaf node T1.0 may correspond to the super spine node SS3.0 and / or SS3.1. In some examples, the NNHN capability may carry the downstream BGP identifiers of all ECMP links corresponding to the next hops of the spine node S2.0 and / or the leaf node T1.0.

[0066] In some aspects, the BGP update message may further include an indication of a next hop associated with the next next hop. For example, a BGP update message received by spine node S2.0 may indicate that for a route to leaf nodes T1.5 to T1.9, super spine nodes SS3.0 and / or SS3.1 are next hops associated with the (multiple) next next hops of the route. Additionally or alternatively, a BGP update message received by leaf node T1.0 may indicate that for a route to leaf nodes T1.5 to T1.9, spine nodes S2.0 to S2.2 are next hops associated with the next next hop of the route. For example, spine node S2.0 and / or leaf node T1 may receive an indication of a prefix with a next hop and a next next hop, and associate the next next hop information with the corresponding next hop.

[0067] In some aspects, the indication of the next hop can be the AS number in the AS path attribute of the BGP update message. For example, the spine node S2.0 and / or the leaf node T1.0 can retrieve the next hop via the BGP AS path attribute, and use the BGP AS path attribute to discover the topology (e.g., next hop and / or next hop) of the five-level Clos network. Because in the five-level Clos network, each next hop can have multiple next hops, the AS path attribute can include the AS number of the next hop of the effective path (e.g., only the next hop AS number of the next hop of the effective path), and other next hop AS numbers can be included in the AS set attribute. In the case where the NNHN capability is unavailable, the BGP AS path attribute can be used.

[0068] In some aspects, leaf nodes T1.0 to T1.9, spine nodes S2.0 to S2.5, and super spine nodes SS3.0 and SS3.1 can be arranged in a Clos network (e.g., a five-level Clos network). For example, as shown, leaf nodes T1.0 to T1.9 can be in the first level of a five-level Clos network, spine nodes S2.0 to S2.5 can be in the second level of a five-level Clos network, and super spine nodes SS3.0 and SS3.1 can be in the third level of a five-level Clos network. Each leaf node T1.0 to T1.9, spine nodes S2.0 to S2.5, and super spine nodes SS3.0 and SS3.1 can be associated with an AS number that is unique in the Clos network. For example, no two nodes in a Clos network can share the same AS number. Therefore, in the case where the AS path attribute is used to identify the next hop, each node in the Clos network can have an AS number that is unique to the Clos network.

[0069] Based on the indication of the next hop (e.g., received via a BGP update message), the spine node S2.0 and / or the leaf node T1.0 can track the next hop link and / or the corresponding next hop link of each route advertised by the leaf nodes T1.0 to T1.9. For example, the spine node S2.0 and the leaf node T1.0 can track the information shown in Tables 2 and 3 above, respectively.

[0070] Additionally or alternatively, leaf nodes T1.0 to T1.9, spine nodes S2.0 to S2.5, and / or super spine nodes SS3.0 and SS3.1 can receive and track the link quality information of the next hop. In some examples, leaf nodes T1.0 to T1.9, spine nodes S2.0 to S2.5, and / or super spine nodes SS3.0 and SS3.1 can use the AS number in the link quality message to associate link quality with the hop. Link quality information may include the congestion status of any suitable link between nodes in the five-level Clos network. In some examples, leaf nodes T1.0 to T1.9, spine nodes S2.0 to S2.5, and / or super spine nodes SS3.0 and SS3.1 can exchange congestion status in real time.

[0071] In the event that link m (e.g., the link from super spine node SS3.0 to spine node S2.3) is congested, super spine node SS3.0 may flood link quality information to all neighboring nodes of super spine node SS3.0, indicating that link m is congested. For example, a packet forwarder of super spine node SS3.0 may flood link quality information, which may be received by spine nodes S2.0 to 2.5 within a few milliseconds. For example, spine node S2.0 may receive link quality information indicating that link m is congested.

[0072] In the event that link g (e.g., the link from leaf node T1.0 to spine node S2.0) is congested, spine node S2.0 may flood link quality information to all neighboring nodes of spine node S2.0, indicating that link g is congested. For example, a packet forwarder of spine node S2.0 may flood link quality information, which may be received by leaf nodes T1.0 to T1.4 within a few milliseconds. For example, leaf node T1.0 may receive link quality information indicating that link g is congested.

[0073] As shown in the reference numeral 150, the leaf node T1.0 can transmit network traffic based on the indication of the next next hop. For example, the leaf node T1.0 can transmit network traffic to any leaf node T1.5-T1.9 based on the fact that the super spine node SS3.0 is the next next hop of the route followed by the network traffic. In some examples, the leaf node T1.0 can also transmit network traffic based on link quality information (e.g., based on an indication of congestion of link g). In some aspects, the leaf node T1.0 can transmit network traffic based on the next hop (e.g., spine node S2.0) being associated with the next next hop (e.g., super spine node SS3.0).

[0074] For example, leaf node T1.0 may use the link quality of the <next hop, next next hop> tuple (e.g.,<S2.0,SS3.0> tuple) to make load balancing decisions. For example, in response to determining that link g is congested, leaf node T1.0 may avoid hashing network traffic (e.g., packet flow) to spine node S2.0 via link a. For example, leaf node T1.0 may transmit network traffic to spine node S2.1 via link b and / or to spine node S2.2 via link c. Avoiding hashing network traffic to spine node S2.0 may enable spine node S2.0 to avoid forwarding network traffic through link g, thereby using GLB to alleviate congestion on link g. In some examples, the congestion state of link m (or any other hop beyond the next-next hop) may not affect how leaf node T1.0 hashes packet flows to spine nodes S2.0 to S2.2 because the congestion state of link m (for example) equally affects the load balancing decisions of spine nodes S2.0 to S2.2.

[0075] As shown in the reference numeral 160, the spine node S2.0 can transmit network traffic based on the indication of the next next hop. For example, the spine node S2.0 can transmit network traffic to any leaf node T1.5 to T1.9 based on the spine node S2.3 being the next next hop of the route followed by the network traffic. In some examples, the spine node S2.0 can also transmit network traffic based on link quality information (e.g., based on an indication of congestion of link m). In some aspects, the spine node S2.0 can transmit network traffic based on the next hop (e.g., super spine node SS3.0) being associated with the next next hop (e.g., spine node S2.3).

[0076] For example, spine node S2.0 may use the link quality of the <next hop, next next hop> tuple (e.g.,<SS3.0,S2.3> tuple) to make load balancing decisions. For example, in response to determining that link m is congested, spine node S2.0 can avoid hashing network traffic (e.g., packet flow) to super spine node SS3.0 through link g. For example, spine node S2.0 can transmit network traffic to super spine node SS3.1 through link i. Avoiding hashing network traffic to super spine node SS3.0 can enable super spine node SS3.0 to avoid forwarding network traffic through link m, thereby using GLB to alleviate congestion on link m. In some examples, the congestion state of link d9 (or any other hop beyond the next hop) may not affect how spine node S2.0 hashes packet flows to super spine nodes SS3.0 and SS3.1 because the congestion state of link d9 (for example) equally affects the load balancing decisions of super spine nodes SS3.0 and SS3.1.

[0077] Although some of the examples described herein are discussed with respect to leaf nodes T1.0 and spine nodes 2.0, the implementations provided herein can be applied to any suitable network device. For example, any leaf node T1.0 to T1.9, spine nodes S2.0 to S2.5, and / or super spine nodes SS3.0 and SS3.1 can perform any suitable operation similar to the operations described above as performed by leaf node T1.0 or spine node 2.0. For example, any leaf node T1.0 to T1.9, spine nodes S2.0 to S2.5, and / or super spine nodes SS3.0 and SS3.1 can receive an indication of the next hop and / or transmit network services based on the indication of the next hop, as described above with reference to leaf node T1.0 or spine node 2.0.

[0078] Transmitting network traffic based on an indication of a next-next hop can enable a network device to detect and alleviate remote congestion on a next-next hop link. For example, the next-next hop information can enable a network device to determine how remote congestion affects a local load balancing decision (e.g., dynamic load balancing) of the network device. For example, a network device can use GLB to alleviate congestion on a next-hop link by transferring traffic to an alternative node. Therefore, GLB can reduce the amount of bandwidth occupied due to congestion on the network structure, thereby reducing packet loss and delay and / or enabling the network structure to meet SLAs.

[0079] The non-link state protocol is BGP, which can enable network devices (e.g., BGP speakers) to implement GLB by determining the topology. In some examples, the BGP speaker can use BGP to determine the next hop and the next next hop of the BGP speaker. Based on the next hop and the corresponding next next hop, the BGP speaker can make the best forwarding decision to alleviate the remote congestion on the next next hop link.

[0080] The indication that the next next hop is a BGP identifier in the NNHN capability of the BGP update message can enable the network device to receive next next hop information of multiple next next hops of the next hop (for example, in a five-level Clos network). The indication that the next next hop is an AS number in the AS-path attribute of the BGP update message can avoid introducing additional overhead to BGP (for example, by avoiding protocol changes to BGP).

[0081] A network device in a Clos network can reduce overhead because the network device in the Clos network can perform GLB based on the next hop and the next-next hop of the network device (e.g., without using information for any further hops of the network device). Thus, the Clos network can avoid transmitting indications of any hops beyond the next-next hop and / or link quality information for hops beyond the next-next hop.

[0082] Transmitting network services based on the association of the next hop with the next next hop can enable the link quality of the next next hop to be reflected in the load balancing weight of the corresponding next hop. Transmitting another BGP update message that does not include a BGP identifier indicating the next next hop of the network device in the NNHN capability based on the BGP update message by the network device can avoid introducing any BGP protocol changes for the GLB.

[0083] As indicated above, Figure 1A to Figure 1B Provided as an example. Other examples may differ from Figure 1A to Figure 1B Examples described. Figure 1A to Figure 1B The number and arrangement of devices shown are provided as examples. In practice, Figure 1A to Figure 1BThere may be additional devices, fewer devices, different devices, or differently arranged devices than those shown. Figure 1A to Figure 1B Two or more of the devices shown may be implemented in a single device, or Figure 1A to Figure 1B The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, Figure 1A-1B The device set shown (e.g., one or more devices) can perform the operations described as being performed by Figure 1A-1B One or more functions performed by another set of devices shown.

[0084] Figure 2 is a diagram of an example implementation 200 associated with NNHN capabilities of BGP update messages.

[0085] Example implementation 200 includes the format of NNHN capability TLV. NNHN capability includes capability code field, capability length, next hop BGP identifier field, and next next hop BGP identifier field. Capability length field can specify the remaining amount of octets in NNHN TLV. Next hop BGP identifier field can include next hop BGP identifier, which can be a 32-bit next hop BGP identifier of next hop node. Next next hop BGP identifier field can include next next hop BGP identifier, which can be one or more 32-bit BGP identifiers, each representing the next next hop node used for single path forwarding or ECMP forwarding by next hop node.

[0086] NNHN capabilities may be in the NHC, which may allow a BGP speaker to signal the forwarding capabilities associated with a given next hop. The NHC may be a container for capability TLVs, such as the NNHN capability TLV. The NNHN capability may specify the next next hop node corresponding to the next hop field in the NHC.

[0087] Using the NNHN capability, a BGP speaker may advertise a next-next-hop node associated with (e.g., corresponding to) a given next-hop of an NLRI, and an upstream BGP speaker may determine a next-next-hop node corresponding to each of the next-hop nodes of the upstream BGP speaker. For example, if a BGP speaker S is to advertise a BGP route R to a peer with the next-next-hop itself, the BGP speaker S may initiate the NNHN capability. The next-hop BGP identifier field may be set to the BGP identifier of the BGP speaker S. For all paths of the BGP route R used for forwarding (e.g., single-path forwarding or ECMP forwarding), the BGP identifiers of those BGP peers may be encoded as the next-next-hop BGP identifiers. If multiple paths come from the same BGP peer, the NNHN capability may contain only one BGP identifier of the peer BGP. If the NNHN capability contains multiple next-next-hop BGP identifiers, the next-next-hop BGP identifiers may be encoded in ascending order. NNHN capabilities without next-next-hop BGP identifiers may not be sent. In some examples, if the BGP speaker S is to advertise the BGP route R to the peers with the next hop itself, the BGP speaker S may not forward the NNHN capability received from the downstream peer (e.g., the BGP speaker S may initiate the NNHN capability as described above, or refrain from sending any NNHN capability). If the BGP speaker S is to advertise the BGP route R to the peers without the next hop change, the BGP speaker S may not initiate the NNHN capability. However, if the NNHN capability has been received and passed the NHC verification for route R, the NNHN capability may be forwarded.

[0088] Additionally or alternatively, the BGP speaker may use the NNHN capability to learn the next next hop(s) corresponding to each of the next hops of the BGP speaker. For example, a receiver of the NNHN capability may be configured to process any order of the next next hop BGP identifiers. In some examples, if there are duplicate copies of the BGP ID in the next next hop BGP identifier field, the receiver may accept only the first BGP ID and ignore the remaining BGP IDs. Because the NNHN capability is carried by the NHC attribute, the NNHN capability may follow the NHC attribute reception rules.

[0089] As indicated above, Figure 2 Provided as an example. Other examples may differ from Figure 2 Examples described.

[0090] Figure 3 is a diagram of an example environment 300 in which the systems and / or methods described herein may be implemented. Figure 3As shown, environment 300 may include one or more peer devices 310, a set of nodes 320 (shown as node 320-1 through node 320-N), and a network 330. The devices of environment 300 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0091] Peer device 310 includes one or more devices capable of receiving and / or providing network services. For example, peer device 310 may include a business transfer device, such as a router, a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a server executing a virtual machine, etc.), a security device, an intrusion detection device, a load balancer, or a device of similar types. In some implementations, peer device 310 may include an endpoint device as a source or destination of network services. For example, peer device 310 may include a computer or a device of similar types. Peer device 310 may receive network services (payload packets) from other peer devices 310 via network 330 (e.g., by using node 320 as an intermediary to route payload packets), and / or may provide network services (payload packets) to other peer devices 310. In some implementations, peer device 310 may include an edge device located at the edge of one or more networks. For example, peer device 310 may receive network traffic from devices external to network 330 and / or may provide network traffic (eg, payload packets) to devices external to network 330 .

[0092] Node 320 includes one or more devices capable of receiving, processing, storing, routing, and / or providing services (e.g., payload packets, files, etc.) in the manner described herein. For example, node 320 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, or another type of router. Additionally or alternatively, node 320 may include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a cloud server, a data center server, etc.), a load balancer, and / or the like.

[0093] In some implementations, the node 320 may be a physical device implemented within a housing, such as a rack. In some implementations, the node 320 may be a virtual device implemented by one or more computer devices in a cloud computing environment or data center.

[0094] In some implementations, the node 320 may be configured with one or more segment translation tables. In some implementations, the node 320 may receive a payload packet from a peer device 310. In some implementations, the node 320 may encapsulate the payload packet using a compressed routing header (CRH), and may use one or more techniques described elsewhere herein to route an Internet Protocol (IP) payload packet to another node 320. In some implementations, the node 320 may be an edge node in the network 330. In some implementations, the node 320 may be an intermediate node in the network 330 (i.e., a node between two or more edge nodes).

[0095] The network 330 includes one or more wired networks and / or wireless networks. For example, the network 330 may include a cellular network (e.g., a fifth generation (5G) network, a fourth generation (4G) network such as a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, a public land mobile network (PLMN)), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0096] Figure 3 The number and arrangement of devices and networks shown are provided as one or more examples. Figure 3 There may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown. Figure 3 Two or more of the devices shown may be implemented in a single device, or Figure 3 The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (eg, one or more devices) of environment 300 may perform one or more functions described as being performed by another set of devices of environment 300.

[0097] Figure 4 4 is a diagram of example components of a device 400 associated with next-hop-indication-based network traffic transmission. Device 400 may correspond to peer device 310 and / or node 320. In some implementations, peer device 310 and / or node 320 may include one or more devices 400 and / or one or more components of device 400. Figure 4 As shown, device 400 may include a bus 410 , a processor 420 , a memory 430 , an input component 440 , an output component 450 , and / or a communication component 460 .

[0098] The bus 410 may include one or more components that enable wired and / or wireless communications among the components of the device 400. The bus 410 may be connected to the device 400, such as via an operational connection, a communicative connection, an electronic connection, and / or an electrical connection. Figure 4 Two or more components of the computer system are connected together. For example, bus 410 may include electrical connections (e.g., wires, traces, and / or leads) and / or wireless buses. Processor 420 may include a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field programmable gate array, an application specific integrated circuit, and / or another type of processing component. Processor 420 may be implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor 420 may include one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

[0099] The memory 430 may include volatile memory and / or non-volatile memory. For example, the memory 430 may include random access memory (RAM), read-only memory (ROM), hard disk drive, and / or another type of memory (e.g., flash memory, magnetic memory, and / or optical memory). The memory 430 may include internal memory (e.g., RAM, ROM, or hard disk drive) and / or removable memory (e.g., removable via a universal serial bus connection). The memory 430 may be a non-transient computer-readable medium. The memory 430 may store information, one or more instructions, and / or software (e.g., one or more software applications) related to the operation of the device 400. In some implementations, the memory 430 may include one or more memories such as being connected (e.g., communicatively connected) to one or more processors (e.g., processor 420) via bus 410. The communication connection between the processor 420 and the memory 430 may enable the processor 420 to read and / or process the information stored in the memory 430 and / or store the information in the memory 430.

[0100] Input assembly 440 can enable device 400 to receive input, such as user input and / or sensor input. For example, input assembly 440 can include touch screen, keyboard, keypad, mouse, button, microphone, switch, sensor, GPS sensor, GNSS sensor, accelerometer, gyroscope, and / or actuator. Output assembly 450 can enable device 400 to provide output such as via display, loudspeaker, and / or light emitting diode. Communication assembly 460 can enable device 400 to communicate with other devices via wired connection and / or wireless connection. For example, communication assembly 460 can include receiver, transmitter, transceiver, modem, network interface card, and / or antenna.

[0101] Device 400 can perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 430) can store an instruction set (e.g., one or more instructions or codes) for execution by processor 420. Processor 420 can execute the group of instructions to perform one or more operations or processes described herein. In some implementations, the group of instructions is executed by one or more processors 420 so that one or more processors 420 and / or device 400 perform one or more operations or processes described herein. In some implementations, hard-wired circuit devices can be used instead of instructions or in combination with instructions to perform one or more operations or processes described herein. Additionally or alternatively, processor 420 can be configured to perform one or more operations or processes described herein. Therefore, the implementation described herein is not limited to any specific combination of hardware circuit devices and software.

[0102] Figure 4 The number and arrangement of components shown are provided as examples. Figure 4 The device 400 may include additional components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, a set of components (e.g., one or more components) of the device 400 may perform one or more functions described as being performed by another set of components of the device 400.

[0103] Figure 5 is a diagram of example components of a device 500 associated with next-hop-indication-based network traffic transmission. Device 500 may correspond to peer device 310 and / or node 320. In some implementations, peer device 310 and / or node 320 may include one or more devices 500 and / or one or more components of device 500. Figure 5 As shown, the device 500 may include one or more input components 510-1 to 510-B (B≥1) (hereinafter collectively referred to as input component 510, and individually referred to as input component 510), a switching component 520, one or more output components 530-1 to 530-C (C≥1) (hereinafter collectively referred to as output component 530, and individually referred to as output component 530), and a controller 540.

[0104] The input component 510 may be one or more attachment points of a physical link and may be one or more entry points for incoming traffic (such as packets). The input component 510 may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 510 may transmit and / or receive packets. In some implementations, the input component 510 may include an input line card, which includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more interface cards (IFCs), a packet forwarding component, a line card controller component, an input port, a processor, a memory, and / or an input queue. In some implementations, the device 500 may include one or more input components 510.

[0105] The switch component 520 can interconnect the input component 510 with the output component 530. In some implementations, the switch component 520 can be implemented via one or more crossbar switches, via a bus, and / or with the aid of a shared memory. The shared memory can act as a temporary buffer to store packets from the input component 510 before the packets are ultimately scheduled for delivery to the output component 530. In some implementations, the switch component 520 can enable the input component 510, the output component 530, and / or the controller 540 to communicate with each other.

[0106] Output component 530 can store packets, and can schedule packets for transmission on output physical links. Output component 530 can support data link layer encapsulation or decapsulation, and / or various higher-level protocols. In some implementations, output component 530 can transmit packets and / or receive packets. In some implementations, output component 530 may include an output line card, which includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and / or output queues. In some implementations, device 500 may include one or more output components 530. In some implementations, input component 510 and output component 530 can be implemented by components of the same group (e.g., and input component / output component can be a combination of input component 510 and output component 530).

[0107] The controller 540 includes a processor in the form of, for example, a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or another type of processor. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 540 may include one or more processors that can be programmed to perform a function.

[0108] In some implementations, the controller 540 may include RAM, ROM, and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, optical storage, etc.) that stores information and / or instructions for use by the controller 540.

[0109] In some implementations, the controller 540 can communicate with other devices, networks, and / or systems connected to the device 500 to exchange information about the network topology. The controller 540 can create a routing table based on the network topology information, can create a forwarding table based on the routing table, and can forward the forwarding table to the input component 510 and / or the output component 530. The input component 510 and / or the output component 530 can use the forwarding table to perform route lookups for incoming packets and / or outgoing packets.

[0110] The controller 540 may perform one or more processes described herein. The controller 540 may perform these processes in response to executing software instructions stored by a non-transitory computer readable medium. Computer readable media is defined herein as a non-transitory memory device. The memory device includes memory space within a single physical storage device or memory space distributed on multiple physical storage devices.

[0111] The software instructions may be read from another computer-readable medium or from another device into a memory and / or storage component associated with the controller 540 via a communication interface. When executed, the software instructions stored in the memory and / or storage component associated with the controller 540 may cause the controller 540 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Therefore, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0112] Figure 5 The number and arrangement of components shown are provided as examples. Figure 5 The device 500 may include additional components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, a set of components (e.g., one or more components) of the device 500 may perform one or more functions described as being performed by another set of components of the device 500.

[0113] Figure 6 is a flow chart of an example process 600 associated with network traffic transmission based on a next-next-hop indication. In some implementations, Figure 6 One or more process blocks are provided by a network device (e.g., Figure 1A or Figure 1B In some implementations, Figure 6 One or more process blocks of are performed by another device or group of devices separate from or including the network device, such as a peer device (e.g., peer device 310) and / or a node (e.g., node 320). Additionally or alternatively, Figure 6 One or more process blocks may be performed by one or more components of device 400, such as processor 420, memory 430, input component 440, output component 450, and / or communication component 460, and / or by one or more components of device 500, such as input component 510, switch component 520, output component 530, and / or controller 540.

[0114] like Figure 6 As shown, process 600 may include receiving an indication of a next hop of a network device and link quality information of the next hop (block 610). For example, the network device may receive an indication of a next hop of the network device and link quality information of the next hop, as described above.

[0115] like Figure 6 As further shown, process 600 may include transmitting network traffic based on the indication of the next hop and the link quality information of the next hop (block 620). For example, the network device may transmit network traffic based on the indication of the next hop and the link quality information of the next hop, as described above.

[0116] Process 600 may include additional implementations, such as any single implementation or any combination of the implementations described below and / or in conjunction with one or more other processes described elsewhere herein.

[0117] In a first implementation, receiving the indication of the next-next hop includes receiving the indication of the next-next hop via a non-link state protocol.

[0118] In a second implementation, either alone or in combination with the first implementation, the non-link-state protocol is BGP.

[0119] In a third implementation, alone or in combination with one or more of the first and second implementations, receiving the indication of the next-next hop includes receiving a BGP update message including the indication of the next-next hop.

[0120] In a fourth implementation, alone or in combination with one or more of the first to third implementations, the indication of the next next hop is a BGP identifier in the NNHN capability of the BGP update message.

[0121] In a fifth implementation, alone or in combination with one or more of the first to fourth implementations, the indication of the next hop is an AS number in an AS-path attribute of the BGP update message.

[0122] In a sixth implementation, alone or in combination with one or more of the first to fifth implementations, the network device is in a Clos network.

[0123] although Figure 6 An example block diagram of process 600 is shown, but in some implementations, Figure 6 The process 600 includes additional blocks, fewer blocks, different blocks, or differently arranged blocks than those shown. Additionally or alternatively, two or more of the blocks of the process 600 may be performed in parallel.

[0124] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the implementation.

[0125] As used herein, a service or content may include a set of packets. A packet may refer to a communication structure for transmitting information, such as a protocol data unit (PDU), a service data unit (SDU), a network packet, a datagram, a segment, a message, a block, a frame (e.g., an Ethernet frame), a portion of any of the above, and / or another type of formatted or unformatted data unit capable of being transmitted via a network.

[0126] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. It is clear that the systems and / or methods described herein can be implemented in different forms of hardware, firmware, and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software codes - it is understood that software and hardware can be used to implement the systems and / or methods based on the description herein.

[0127] Even if a specific combination of features is described in the claims and / or a specific combination of features is disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features can be combined in a manner that is not specifically described in the claims and / or not specifically disclosed in the specification. Although each dependent claim listed below can directly rely on only one claim, the disclosure of various implementations includes each dependent claim combined with each other claim in the claim set. As used herein, the phrase "at least one" referring to a list of items refers to any combination of those items, including a single member. As an example, "at least one of a, b, or c" is intended to cover a, b, c, ab, ac, bc, and abc, as well as any combination with multiples in the same item.

[0128] When a "processor" or "one or more processors" (or another device or component, such as a "controller" or "one or more controllers") is described or claimed (either within a single claim or across multiple claims) as performing or being configured to perform multiple operations, such language is intended to broadly cover a variety of processor architectures and environments. For example, unless otherwise expressly claimed (e.g., via use of "a first processor" and "a second processor" or other language in the claims that distinguishes between the processors), such language is intended to cover a single processor that performs or is configured to perform all operations, a group of processors that collectively perform or are configured to perform all operations, a first processor that performs or is configured to perform a first operation and a second processor that performs or is configured to perform a second operation, or any combination of processors that perform or are configured to perform operations. For example, when a claim is of the form "one or more processors: performs X; performs Y; and performs Z," the claim should be interpreted to mean "one or more processors perform X; one or more (possibly different) processors perform Y; and one or more (possibly different) processors perform Z."

[0129] Unless clearly described as such, any element, action or instruction used in this article should not be interpreted as critical or necessary. In addition, as used herein, the articles "a" and "an" are intended to include one or more projects, and can be used interchangeably with "one or more". In addition, as used in the text, the article "the" is intended to include one or more projects quoted in conjunction with the article "the", and can be used interchangeably with "the one or more". In addition, as used herein, the term "group" is intended to include one or more projects (for example, a combination of related projects, unrelated projects, or related projects and unrelated projects), and can be used interchangeably with "one or more". In the case of only intending a project, the phrase "only one" or similar language is used. In addition, as used herein, the terms "have", "have" and "contain" etc. are intended to be open terms. In addition, unless otherwise expressly stated, the phrase "based on" is intended to mean "at least partially based on". Furthermore, as used herein, the term "or" when used in conjunction is intended to be inclusive and may be used interchangeably with "and / or" unless expressly stated otherwise (eg, if used in combination with "either" or "only one of"),.

[0130] Additional examples are disclosed below, which may be rearranged in combinations and sub-combinations with each other.

[0131] Example 1. A method, comprising: receiving, by a network device, an indication of a next-next hop of the network device and link quality information of the next-next hop; and transmitting, by the network device, network traffic based on the indication of the next-next hop and the link quality information of the next-next hop.

[0132] Example 2. The method of example 1, wherein receiving the indication of the next-next hop comprises receiving the indication of the next-next hop via a non-link state protocol.

[0133] Example 3. The method of Example 2, wherein the non-link state protocol is Border Gateway Protocol (BGP).

[0134] Example 4. The method of Example 3, wherein receiving an indication of a next-next hop comprises: receiving a BGP update message including the indication of the next-next hop.

[0135] Example 5. The method of Example 4, wherein the indication of the next-next hop is a BGP identifier in the next-next hop node capabilities of the BGP update message.

[0136] Example 6. The method of Example 4, wherein the indication of the next hop is an AS number in an Autonomous System AS-Path attribute of the BGP update message.

[0137] Example 7. The method of Example 1, wherein the network device is in a Clos network.

[0138] Example 8. A network device, comprising: one or more memories; and one or more processors, for: receiving a Border Gateway Protocol (BGP) update message, the BGP update message including an indication of a next hop of the network device; and transmitting network services based on the indication of the next hop.

[0139] Example 9. The network device of Example 8, wherein the indication of the next-next hop is a BGP identifier in the next-next hop node capabilities of the BGP update message.

[0140] Example 10. The network device of Example 9, wherein the BGP update message is associated with an external BGP eBGP session.

[0141] Example 11. The network device of Example 10, wherein the next hop itself is configured for the eBGP session.

[0142] Example 12. The network device of Example 9, wherein the next-next-hop node capability comprises a plurality of BGP identifiers, the plurality of BGP identifiers comprising a BGP identifier, and wherein the plurality of BGP identifiers correspond to a plurality of next-next-hops of the network device, the plurality of next-next-hops comprising the next-next-hop.

[0143] Example 13. The network device of Example 9, wherein the BGP update message further comprises an indication of a next hop of the network device, the next hop being associated with a next-next hop, and wherein the one or more processors for transmitting network traffic are configured to transmit network traffic based on the association of the next hop with the next-next hop.

[0144] Example 14. The network device of Example 9, wherein the one or more processors are further configured to: transmit another BGP update message based on the BGP update message, the other BGP update message not including the BGP identifier in the next-next-hop node capabilities.

[0145] Example 15. The network device of Example 8, wherein the indication of the next next hop is an AS number in an Autonomous System AS-Path attribute of the BGP update message.

[0146] Example 16. The network device of Example 15, wherein the network device is one of a plurality of network devices in a Clos network, and wherein each of the plurality of network devices is associated with an AS number that is unique within the Clos network.

[0147] Example 17. A non-transitory computer-readable medium storing an instruction set, the instruction set comprising: one or more instructions that, when executed by one or more processors of a network device in a Clos network, cause the network device to: receive an indication of a next hop of the network device and link quality information of the next hop; and transmit network services based on the indication of the next hop and the link quality information of the next hop.

[0148] Example 18. The non-transitory computer readable medium of Example 17, wherein the one or more instructions that cause the network device to receive the indication of the next-next hop cause the network device to: receive the indication of the next-next hop via a non-link state protocol.

[0149] 19. The non-transitory computer readable medium of example 18, wherein the non-link state protocol is a Border Gateway Protocol (BGP).

[0150] 20. The non-transitory computer readable medium of example 19, wherein the one or more instructions that cause the network device to receive an indication of a next-next hop cause the network device to: receive a BGP update message including the indication of the next-next hop.

Claims

1. A method comprising: Receiving, by the network device, an indication of the next-next hop of the network device and link quality information of the next-next hop; as well as Network traffic is transmitted by the network device based on the indication of the next-next hop and the link quality information of the next-next hop.

2. The method of claim 1 , wherein receiving the indication of the next-next hop comprises: The indication of the next-next hop is received via a non-link state protocol.

3. The method of claim 2, wherein the non-link state protocol is Border Gateway Protocol (BGP).

4. The method of claim 3, wherein receiving the indication of the next-next hop comprises: A BGP update message is received including the indication of the next-next hop.

5. The method of claim 4, wherein the indication of the next-next hop is a BGP identifier in a next-next hop node capability of the BGP update message.

6. The method of claim 4, wherein the indication of the next-next hop is an AS number in an Autonomous System (AS)-Path attribute of the BGP update message. The method of claim 1 , wherein the network device is in a Clos network.

8. A network device comprising: one or more memories; as well as One or more processors to: Receiving a Border Gateway Protocol (BGP) update message, wherein the BGP update message includes an indication of a next-next hop of the network device; as well as Network traffic is transmitted based on the indication of the next-next hop.

9. The network device of claim 8, wherein the indication of the next-next hop is a BGP identifier in a next-next hop node capability of the BGP update message.

10. The network device of claim 9, wherein the BGP update message is associated with an external BGP eBGP session.

11. The network device of claim 10, wherein the next hop itself is configured for the eBGP session.

12. The network device of claim 9, wherein the next-next-hop node capabilities include a plurality of BGP identifiers, the plurality of BGP identifiers including the BGP identifier, and wherein the plurality of BGP identifiers correspond to a plurality of next-next-hops of the network device, the plurality of next-next-hops including the next-next-hop.

13. The network device of claim 9, wherein the BGP update message further comprises an indication of a next hop of the network device, the next hop being associated with the next-next hop, and wherein the one or more processors for transmitting the network service are configured to transmit the network service based on the association of the next hop with the next-next hop.

14. The network device of claim 9, wherein the one or more processors are further configured to: Another BGP update message is transmitted based on the BGP update message, the other BGP update message does not include the BGP identifier in the next-next-hop node capabilities.

15. The network device of claim 8, wherein the indication of the next-next hop is an AS number in an Autonomous System (AS)-Path attribute of the BGP update message.

16. The network device of claim 15, wherein the network device is one of a plurality of network devices in a Clos network, and wherein each of the plurality of network devices is associated with an AS number that is unique within the Clos network.

17. A non-transitory computer readable medium storing an instruction set, the instruction set comprising: One or more instructions that, when executed by one or more processors of a network device in a Clos network, cause the network device to: Receiving an indication of a next-next hop of the network device and link quality information of the next-next hop; as well as Network traffic is transmitted based on the indication of the next-next hop and the link quality information of the next-next hop.

18. The non-transitory computer-readable medium of claim 17, wherein the one or more instructions that cause the network device to receive the indication of the next-next hop cause the network device to: The indication of the next-next hop is received via a non-link state protocol.

19. The non-transitory computer readable medium of claim 18, wherein the non-link state protocol is a Border Gateway Protocol (BGP).

20. The non-transitory computer-readable medium of claim 19, wherein the one or more instructions that cause the network device to receive the indication of the next-next hop cause the network device to: A BGP update message is received including the indication of the next-next hop.

Images