Convergence optimization in network

Abstract

The invention relates to convergence optimization in a network. Systems and methods herein are for a network having a recipient network device and a source network device. A source network device may be configured to advertise a route containing an attribute and at least one network address representative of the source network device. The attribute may include an identifier of the source network device, the at least one network address having a prefix associated with a host of the source network device. The receiving network device may determine convergence for routing data packets from the receiving network device based in part on a determination that the identifier matches at least the prefix of the route advertised by the source network device. When the convergence determination is performed using only one routing update having an identifier at least matching the prefix, the convergence determination may be performed more quickly, which allows the receiving network device to identify and use only one routing update.

Description

[0001] Cross-references to related applications

[0002] This is a non-provisional patent application that relates to and claims priority to U.S. Provisional Patent Application 63 / 712,333, filed October 25, 2024, entitled "CONVERGENCE OPTIMIZATION IN NETWORKS", the entire contents of which are hereby incorporated herein by reference for all intents and purposes. Technical Field

[0003] This disclosure generally relates to convergence optimization in networks, and more particularly to convergence using routing packets in networks. Background Technology

[0004] As used in this article, "convergence" can refer to the process by which network devices use shared routing information or updates to determine their consistent state relative to the network topology, ensuring that packets from each network device are correctly routed and reach their intended network devices and / or hosts. Optimization of convergence determinations can refer to the speed at which network devices can adapt to changes (such as network failures). When a failure occurs in the network, multiple routing updates may be provided to network devices, potentially requiring more convergence determinations. This can lead to network device congestion and packet loss (or dropped packets). Packet loss can cause significant performance degradation and increase the Job Completion Time (JCT) of certain workloads (such as artificial intelligence / machine learning (AI / ML) workloads), which can use JCT as a performance metric. Attached Figure Description

[0005] Figure 1 A network is shown as an example of a network undergoing convergence optimization.

[0006] Figure 2 A leaf-spine network undergoing route updates according to at least one embodiment is illustrated;

[0007] Figure 3 Aspects of convergence optimization for faults based on usage attributes and at least one network address according to at least one embodiment are illustrated;

[0008] Figure 4 Computer and processor aspects of a system for convergence optimization based on usage attributes and at least one network address according to at least one embodiment are illustrated.

[0009] Figure 5A process flow is shown in a system for convergence optimization based on usage attributes and at least one network address according to at least one embodiment;

[0010] Figure 6 Another process flow is shown in a system for convergence optimization based on usage attributes and at least one network address according to at least one embodiment; and

[0011] Figure 7 Another process flow is shown in a system that performs convergence optimization based on usage attributes and at least one network address according to at least one embodiment. Detailed Implementation

[0012] Figure 1 A network is illustrated as an example of convergence optimization in the network detailed herein. In one example, network 100 is constrained by the Border Gateway Protocol (BGP). Convergence determination in network devices (such as routers, switches 106, 114, gateway 108, or other interconnecting devices 120) may use network information including a source identifier. To support the optimization of convergence determination in network 100 (such as a leaf-backbone network that may conform to BGP), source network devices (such as first leaf switches or other network devices) may be configured to advertise routes with shared attributes (e.g., route origin extended community provided in BGP under RFC 4360, see Section 5). The route advertising the route source may be an anchor route. The advertised route may also include at least one network address that may represent the source network device. This attribute may be a source identifier (also called an identifier) ​​and may be the Internet Protocol (IP) address of the source network device. In at least BGP, this identifier may be a route identifier or a route initiator identifier (ID). At least one network address may be a prefix associated with a host located behind or represented by the source network device. For example, these hosts may be represented by only one leaf switch.

[0013] The IP address of the source network device can be matched with a prefix, at least because the IP address can be used for internal management within the source network device, and the prefix can represent the root of all hosts behind the source network device. The IP address can be advertised via attributes to support the convergence determination in this paper. In the example using BGP, when a failure may occur in network 100, one or more network devices 106, 108, 114, and 120 of network 100 can provide frequent route updates. The failure may be related to the links between the failed devices, or it may be related to the individual failed devices, where the failure may be the inability to correctly route packets. During a failure to update its routing information, the receiving network device can use the matching of the advertised IP address with the prefix by only identifying the source network device (according to attributes) and ignoring all other route updates from the source network device.

[0014] In some examples, at least for BGP, there may be latency or time requirements driving convergence after a failure or change in the network. In some examples, latency or time requirements can be at least partly attributed to the process required to determine routes and advertise new routes to network devices in the network after a failure. Latency or time requirements are proportional to the number of routes, as it is performed route-by-route and is computationally intensive. The convergence performed here can be an optimization for the computational demands associated with route-by-route operations, also known as convergence optimization. For example, routes can be grouped instead of being changed route-by-route. Route grouping can be performed so that routes (including any network devices associated with the routes, such as leaves, backbones, and superbranches within the routes) can be grouped or associated together using identifiers such as route initiator identifiers. Grouping can allow changes to be propagated to individual groups instead of route-by-route. In some examples, when routes are determined to be associated together to form a group, a single next-hop group (NHG) change can be performed on the entire group instead of route-by-route changes.

[0015] Because routing updates within the receiving network device may require convergence determination for each update, multiple routing updates may need to be performed within the receiving network device (e.g., each host behind the source network device only advertises the route once). This could be a route-by-route process, which could lead to significant latency or excessive processing in the receiving network device without considering the routing packets. However, because the receiving network device can apply convergence determination only to routing updates where an IP address matches its prefix, it can ignore all other routing updates from the same source network device. This is at least because a failure associated with the source network device could affect all hosts behind it; therefore, convergence determination using a single routing update can be applied to all hosts behind the source network device. Thus, convergence determination could be faster, and the network device could be freed up to perform packet routing.

[0016] Furthermore, to support route updates used for convergence determination, the receiving network device can also be configured to assign an NHG to the source network device. Individual NHGs can be provided for each network device. When a failure occurs associated with the source network device, the NHG can perform replacement operations on all prefixes previously associated with the source network device, regardless of individual route updates from the source network device. Moreover, at least one NHG from a different source network device that is not part of the failure in the network remains unchanged. This also reduces latency and delay in network 100 after a failure and reduces the need for propagating and applying route updates within network 100.

[0017] The convergence optimization described in this paper can be implemented in two steps. First, at least one NHG can be assigned to each source, and then the leaves in the leaf-backbone network can, for example, advertise the identifier of the source network device. The identifier provided in the attribute section of the advertisement can be the logical IP address of the router identifier advertised from the leaf (such as the router identifier loopback route). When BGP is used with the leaf-backbone network, the leaves can additionally use the route source extended community to label the prefix routes. This allows other leaves to identify the advertised source. Furthermore, the router identifier logical IP address can be sent and received first in the routing update communication, which allows the receiving network device to perform convergence determination during a failure, regardless of how many subsequent routing updates are received from the source network device. In one instance, instead of a failure, when the network topology changes, the leaf acting as the receiving network device can utilize the updated Enhanced Multipath Control Protocol (ECMP) to receive the router identifier logical IP address as a routing update. The updated ECMP or weighted ECMP portion can allow the NHG to accept all prefix replacement operations from the source network device without waiting for individual routing updates.

[0018] In one example, network 100 may include at least one circuit, which may be an execution unit of a processor located within switches 106; 114, any different interconnect device 120, or the first or second group of nodes 1-N 104A-N; 1-N 112A-N. The interconnect device may allow communication across wider network groups and may include different switches and / or gateways 108, while communication within or within a narrower network group may be implemented by at least one switch 106, 114. Furthermore, the switches may communicate with each other independently of the nodes to share configuration information for various routes within network 100.

[0019] Switches 106 and 114 may be associated with a corresponding rack, chassis, or other physical set of network groups 2102 and 1110, illustrated as nodes or other endpoints 1-N 104A-N and 1-N 112A-N. Convergence optimization using attributes and at least one network address can be performed for one or more of network devices 106, 108, 114, and 120. Network 100 may include at least one switch or gateway 108 as part of one or more interconnect devices 120 to provide communication 116 between multiple switches 106 and 114, thus providing communication 116 across a wider network group between nodes 1-N 104A-N and 1-N 112A-N in the first or second group. The method of convergence optimization using attributes and at least one network address can be performed within or between network groups. Therefore, the description of interconnect device 120 herein can be understood to apply to the use of any of the switches 106, 114, or gateway 108 shown.

[0020] In one example, communication 116 could be Ethernet, (IB) Or any suitable communication that can benefit from the convergence optimization of the usage attributes and at least one network address described herein. Furthermore, any communication network supporting BGP (including Transmission Control Protocol (TCP) or TCP-based Internet Protocol (IP)) can be used with the convergence optimization of the usage attributes and at least one network address described herein. When communication 116 is IB or NVLink, at least one of the multiple switches 106, 114, or at least one of the first or second group of nodes 1-N 104A-N; 1-N 112A-N, can be able to host a subnet manager (SM) or any functionality required by the associated IB or NVLink protocol. Similarly, when communication 116 is Ethernet communication, at least one of the multiple switches 106, 114 can be able to host or act as a switch manager (SM).

[0021] In at least one embodiment, when network 100 is BGP adapted, switches 106 and 114 can be backbone switches or leaf switches. Therefore, nodes or other endpoints 1-N 104A-N; 1-N112A-N in each network group 2 102; 1 110 can communicate within the group using leaf switches 106 and 114, and can communicate across groups using backbone switches or gateway 108. For Figure 1 In network 100, convergence optimization using attributes and at least one network address can overcome the technical constraints and limitations associated with convergence determination using multiple route updates for each host behind the source network device.

[0022] In at least one embodiment, within the context of the data plane and control plane, the convergence determination described herein can be extended in response to network topology changes to also include the speed at which the network is updated with the correct control plane and data plane states. Therefore, convergence optimization can encompass individual network devices and extend to the entire network. When the network is a single-hop bidirectional forwarding detection (BFD) network, local link failures can be resolved through route updates. In BFD, in certain situations, including when the physical layer is not faulty but the IP layer is faulty, BFD can achieve faster fault detection, resulting in faster convergence. This provides better route convergence for BFD-enabled networks. This may not be applicable to remote link failures in network 100 where the link distance exceeds a single hop. For example, in a Clos network topology using external BGP (eBGP), unicast convergence determination can be affected by a variety of factors, including BGP convergence time, network latency, and processing latency within the network devices associated with the control plane (e.g., providing free-range routing (FRR)) and the data plane (including associated hardware).

[0023] There are more than one hop between the host and network devices, and fault convergence optimization is performed using attributes and at least one network address. Figure 1 Network 100 in the context of network 100 can address issues that may arise during remote link failures. In a leaf-backbone network, from the perspective of a local leaf, a remote link can refer to a link between the backbone and a remote leaf, or between the backbone and a superbackbone. For example, when a remote link failure occurs, the new ECMP path may not be programmed in the hardware quickly enough after receiving routing updates due to network changes. This could be because routing updates are provided as per-routing updates within switches and their components (e.g., from the BGP side to...). From routing platform to kernel to This includes daemons (or background processes), software development kits (SDKs), and other hardware. Once a routing update is received, a network device can switch or redirect packets to the new route or the same route, but with different weights, and can perform the switch or redirection faster, regardless of the number of routes (or hosts behind the source network device, where independence can be called prefix-independent convergence).

[0024] Using attributes and at least one network address for fault-based convergence optimization can resolve or improve unicast traffic convergence in a prefix-independent manner (such as prefix-independent convergence, or PIC for short). For switches employing PIC, updates to new ECMP routes may be caused by changes in network topology, such as link failures. This approach can be applied to high-performance Ethernet for artificial intelligence (AI) / machine learning (ML) topologies, where convergence determinations made during link failures can be critical.

[0025] In at least one embodiment, the convergence optimization described herein can be applied to Layer 3 (L3) BGP, adaptive and non-adaptive routing traffic, remote link disconnection and reconnection convergence triggers, 2CLOS or 3CLOS topologies, and links between devices with single or multiple links (including Weighted Equal Cost Multipath (W-ECMP) routes). In one example, the convergence optimization described herein can be applied to 80,000 or more routes. Although the convergence optimization described herein may be hardware-independent for network devices of type 106, 108, 114, or 120, all of these hardware devices may need to have the following capabilities: identify attributes; determine matches using attributes and prefixes in advertised routes in the event of a failure; and perform internal route updates using a single route update with that attribute, while any subsequent route updates from the same source and for the same failure will be treated as null.

[0026] Figure 2 A leaf-backbone network 200 for route updates according to at least one embodiment is illustrated. The leaf-backbone network 200 can be for... Figure 1 The specific configuration of network 100 in the diagram. Leaf-backbone network 200 may include leaves 11, 12, 21, 22 (202), backbones 11, 12, 21, 22 (204), and superbackbones 11, 12, 21, 22 (206). Leaves, backbones, and superbackbones can be combined. Figure 1One of the network devices 106, 108, 114, and 120 is described. The leaf-backbone network 200 can be a network topology commonly found in high-performance computing (HPC) systems, used to support high-bandwidth and low-latency communication between hosts 208. This leaf-backbone network 200 can be used in applications with data-intensive processing and parallel computing, which may include distributed computing workloads.

[0027] Leaf nodes 202 can be end nodes or switches 106 or 114 connected to host 208. Host 208 can be a complete computing system or a separate processor or storage device. They can also be referred to as edge devices. Leaf nodes 202 can be responsible for routing traffic from the backbone 204 and super backbone 206 to host 208. Leaf nodes 202 can also be responsible for advertising prefixes learned from host 208 to the backbone 204. Backbone 204 can represent the core of network 200 because it can be connected to super backbone 206, but provides connectivity for leaf nodes 202 and exchanges routing updates or information between them. Backbone 204 can be responsible for receiving and distributing routing updates 212 from leaf nodes 202 using provided link 210. Super backbone 206 can be an intermediate endpoint connecting backbone 204 and supporting connections to leaf nodes 202. Super backbone 206 can provide traffic aggregation and additional redundancy when needed. Leaf nodes 202 can be interconnected through backbone 204, and backbones can be interconnected through super backbone 206.

[0028] Each leaf 11, 12, 21, 22 202 may include a corresponding set of hosts X1-100, Y1-100, Z1-100, and P1-100, which may be located after the leaf. In some examples, hosts X1-100, Y1-100, Z1-100, and P1-100 may be selected from one or more GPUs, servers, or virtual machines (VMs). In some examples, without an announcement from one or more leaves (e.g., leaves 11, 12, 21, 22), each leaf may not know the location of hosts not located after it. For example, leaf 11 may not know the location of host Y1-100, which is located after leaf 12. Leaves may have tables or other registry entries for the hosts associated with them (e.g., hosts located after the leaf). Relative to network 200, leaves may have IP addresses and may have prefixes associated with them. For example, an IP address can have the format AAA.BBB.CCC.DDD, while a prefix or subnet mask can have the format OOO.XXX.YYY.ZZZ / PPP. Each letter can represent a number. The PPP part of the prefix can represent multiple bits defining the prefix. For example, at least for... Figure 3To support information about hosts following different leaves, network protocols (such as BGP) can use attributes as extensions of the network protocol's routing source community. The routing source may rely on labels or tags from individual leaves and may also include identifiers of at least one leaf to which a host can be coupled, which may be part of a routing change (including a change in network topology). In aspect 200, a host is located behind or is represented by a source network device (such as a leaf switch (such as one of leaves 202)). For example, a host may be represented by only one leaf switch.

[0029] Figure 3 Aspect 300 for convergence optimization for faults is illustrated based on usage attributes and at least one network address according to at least one embodiment. First, the network shown may come from... Figure 2 The leaf-backbone network 200 in the middle, or it could be Figure 1 Another suitable variant of network 100 is capable of providing route updates that have an attribute that may contain an identifier as a potential match to a prefix of the IP address from the source network device. Aspect 300 illustrates that such networks 100, 200 may include receiving network device 202 (leaf 11) and source network device 304 (leaf 21). Source network device 304 may be configured to advertise route 306 (as part of a route update). This route may be a route update relative to the network devices it connects to in the backbone 204, other leaves 202, and / or relative to its hosts (nodes Z1-100). In aspect 300, hosts are located after or are represented by the source network device (such as a leaf switch, such as one of leaves 11, 12, 21, or 22). For example, a host may be represented by only one leaf switch.

[0030] The route may include an attribute (attr.) 308 and at least one network address (N / W addr.) 310, which may represent the source network device 304. Attribute 308 may include an identifier of the source network device 304, and at least one network address 310 may include a prefix associated with a host (node ​​Z1-100) of the source network device 304. The receiving network device 302 may then be configured to determine the convergence of packets routed from the receiving network device, in part, based on the determination that the identifier at least matches the prefix of the route advertised by the source network device 304. A route with such a match may represent a router-identifier logical IP address advertised from a leaf (such as the source network device 304).

[0031] In some examples, the network protocol implements attribute 308 as a route source extended community to support NHGs. For example, an NHG can be assigned to each route source (see reference). Figure 3Each source NHG 320 is shown in the diagram. This allows remote leaves acting as source network devices to prompt, permit, or support the advertising of identifiers for advertised routes (e.g., by providing route identifiers). Advertised routes can include loopback routes or can be based on loopback routes. For example, remote leaves can tag or label prefix routes as part of the advertised identifier. Prefix routes can be referenced by identifiers within the route-source extension community so that local leaves can recognize them. Furthermore, identifiers can be sent and received within the network prior to convergence determination to allow or support rapid convergence determination during failures. In some examples, when the network topology changes, local leaves can receive loopback route identifiers with updated ECMP. This can allow an NHG to replace all prefixes from remote leaves without waiting for individual BGP updates that may apply to a per-route process.

[0032] In some examples, each backbone and each leaf can receive and update routes using identifiers received from remote leaves. Therefore, each backbone and each leaf can receive and update routes in hash tables, routing tables, or other suitable references faster and more efficiently to support convergence of changes that may occur within the network. In some examples, each leaf and backbone (such as those from source network devices) can contain identifiers (such as route initiator IDs, which can be unique to the source network device). At the receiving end, when a leaf or backbone receives an identifier indicating a network topology change, that leaf or backbone (which may include the receiving network device) can create an NHG to associate with that identifier as part of the configuration within the receiving network device. In some examples, route updates can also be performed... Figure 2 The super backbone shown is available for use.

[0033] At least in Figure 3In this context, each source NHG 320 can be created or applied at the route origin. This allows NHG replacement operations to be performed using FRR when a remote link (route) within the network fails and, as mapped in the network topology. NHG replacement operations can apply only to the affected routes behind the affected remote leaves. In some examples, the route initiator ID is associated with an NHG representing two or more routes. These two or more routes can include one or more leaf-to-host, leaf-to-backbone, or backbone-to-superbone routes. Therefore, each source NHG 320 is created only for the NHG, not for individual next hops (e.g., next hop IDs). Changes in network topology can cause changes to the NHG. Changes in the NHG allow changing two or more routes under the NHG to use different network devices in the network device associated with the NHG, instead of the initial network device in the network device. Figure 3 In the example, routes Y1-100, Z1-100, and P1-100 can originate from leaves 12, 21, and 22, respectively. The BGP protocols on these leaves can advertise their routes via the route initiator ID or the source site (SOO) included in the BGP route source extension community. Similar advertisements can be made using other network protocols capable of advertising routes and using extension communities or other messaging mechanisms. Changes to route origins can be performed by attaching a route source extension community. At the receiving node or network device (such as leaf 11), each source NHG 320 can be assigned to receive and apply any changes, such as using convergence module 316A and routing table 316B.

[0034] In some examples, each backbone 11-22 and each leaf 11-22 can be a network device, such as a switch. This network device may include one or more circuits. These one or more circuits may include processors, such as... Figure 1 and Figure 4The processor described. This one or more circuits can perform convergence within the BGP protocol. This convergence can follow changes in network topology and can group two or more routes in the network topology together using identifiers such as route initiator IDs. The route initiator ID can be used as the basis for routing configurations associated with network devices and linked to two or more routes in the group. This configuration can include creating or associating an NHG from a source network device within the receiving network device. This one or more circuits can allow the route initiator ID to be associated with an NHG to represent two or more routes. Changes in network topology may lead to changes in the NHG. Changes in the NHG can allow changes to two or more routes under the NHG using routing configurations attached to network devices (such as source and receiving network devices) and associated with the NHG. In some examples, Figure 2 The super backbone shown can also be a network device with one or more circuits for performing the aspects described in this paper in combination with the backbone and leaves.

[0035] like Figure 3 As shown, as a continuous requirement in networks 100 and 200, an initial route with convergence 312 enabled by link 210 may exist. However, when a failure 314 occurs (one or more links 210 fail or a network device (backbone 21) fails), a route update can be provided to indicate for each host 208 (such as node Z1-100) for each leaf 202 (such as the leaf 21 constituting the source network device 304). Since the receiving network device 302 may have already received the advertised route 306 from the source network device 304 (this route may be a router-identifier logical IP address), the receiving network device 302 can determine the match within the route. The receiving network device 302 can perform its convergence optimization in the convergence module (convg.module) 316A to skip failure 314 using the received advertised single route 306. Although the receiving network device 302 can receive routing updates on behalf of each host, it can ignore these updates or execute empty processes that do not consume other computing components of the receiving network device 302's processor.

[0036] Figure 3The two-line link in the diagram represents an alternative (Alt.) route after failure convergence 318, where convergence represents convergence optimization based at least on the single advertised route 306. These alternative routes after failure convergence 318 may be able to reach hosts (nodes Z1-100) behind backbone 21 and its associated leaves 21 via other unaffected backbones 12 and / or unaffected superbackbones 1, 4 (instead of affected backbones 21 and superbackbones 2). Indeed, it is evident from the discussion here that traffic allocation can be partially based on the determination made by convergence module 316A and adjusted via unaffected routes using advertised routes 306 with matching identifiers and prefixes from source network device 304.

[0037] Similar to networks 100 and 200, aspect 300 can be applied to networks that conform to BGP, such that the attribute is a BGP route source extension community. The network in aspect 300 can be configured such that receiving network device 302 can be configured to receive indications of fault 314 in the network and perform convergence determination for routing packets in part based on these indications. This fault can be indicated by source network device 304 or any other network device in the network.

[0038] The network in aspect 300 can be configured such that receiving network device 302 can be further configured to receive additional advertisements of routes associated with hosts (such as node Z1-100) of source network device 304. Receiving network device 302 can be further configured to perform a null procedure for additional advertisements from the source network device following an advertisement 306 having routes advertised by source network device 304. In one instance, the null procedure could be maintaining the routes associated with the advertised routes 306 without updating the additional advertisements of routes in convergence module 316A.

[0039] The network in aspect 300 can be further configured to assign an NHG to the source network device 304. The network in aspect 300 can support individual NHGs for the various network devices represented by leaf 202, backbone 204, and superbackbone 206. When a failure associated with the source network device 304 (such as at backbone 21) occurs, the receiving network device 302 can be further configured to perform a replacement operation on the NHG and all prefixes previously associated with the source network device 304. The replacement operation can be independent of individual routing updates from the source network device 304.

[0040] In aspect 300, other source network devices' NHGs may also exist in the leaf 202 of the network. In the event of a failure 314, the NHG created or assigned to source network device 304 may not affect other source network devices in the non-failed portion of the network. Therefore, other NHGs assigned to other source network devices in leaf 202 may remain unchanged after failure 314. Each assigned source NHG can be executed at the backbone 204 and can be executed in each source NHG module 320 of each backbone 204 (such as backbone 11).

[0041] Figure 3 Aspect 300 also illustrates that each source network device 304 in the network can be configured, in part, at least by software, to advertise a route having attributes and at least one network address representing the source network device 304. The attributes may include an identifier of the source network device 304 and at least one network address, the at least one network address containing a prefix associated with a host (node ​​Z1-100) of the source network device 304. This attribute and at least one network address enable a receiving network device 302 in the network to determine, in part, convergence (e.g., for a backup route 318 after convergence in the event of a failure) for routing packets from the receiving network device 302, based on a determination that the identifier at least matches the prefix of the route advertised by the source network device.

[0042] in addition, Figure 3 Aspect 300 also illustrates that each receiving network device 302 in the network can be configured, at least by software, to receive a route 306 advertised by a source network device 304. The route may include attributes and at least one network address that may represent the source network device 304. The attributes may include an identifier of the source network device 304, and the at least one network address may include a prefix associated with a host (node ​​Z1-100) of the source network device 304. The receiving network device 302 can also be configured to determine convergence for routing packets from the receiving network device 302 (e.g., for a backup route 318 after convergence in the event of a failure) based in part on a determination that the identifier at least matches the prefix of the route advertised by the source network device 304. The receiving network device 302 can also be configured to receive an indication of a failure 314 in the network and to perform the determination of convergence for routing packets based in part on the indication of a failure in the network.

[0043] The receiving network device 302 can also be configured to receive additional advertisements of routes associated with hosts of the source network device, and can also be configured to perform a null procedure for additional advertisements from the source network device following an advertisement of routes advertised by the source network device 306. The receiving network device can also be configured to assign NHGs to the source network device 302. In one example, each source NHG module 320 can be enabled with leaf 202 to perform NHG assignment. Therefore, at least any network device in leaf 202, backbone 204, and superbackbone 206 can be able to perform each source NHG determination using the corresponding each source NHG module 320. A network with receiving network device 302 can support individual NHGs for each network device. When a fault 314 associated with source network device 304 occurs, receiving network device 302 can also be configured to perform a replacement operation on the NHG and all prefixes previously associated with the source network device. The replacement operation can be independent of individual updates from the source network device. There may be other NHGs in the network from other source network devices (other leaves 202), which are not part of the fault in the network, and these other NHGs can remain unchanged.

[0044] Therefore, BGP's route source extension community can be used to provide router-identifier logical IP addresses for other leaf nodes 202 in the network. A router-identifier logical IP address with an additional route source extension community encodes the IP address of the source network device within the route source extension community, and this IP address can match the prefix of an advertised route 306, thus making that route a router-identifier logical IP address. Other advertised routes may exist that contain route source extension communities, but the IP address encoded within the route source extension community may differ from the prefix of this route.

[0045] When a BGP-compatible network identifies a new attribute as part of a route source extension community, BGP can enable individual leaf, backbone, and / or other network devices to provide an attribute entry in hash table 316B, regardless of whether the attribute matches the IP address of an advertised route. Routes in hash table 316B can be indexed by this attribute. Whenever an attribute entry is created in hash table 316B, after processing routes with matching or non-matching attributes, a destination entry for that route can be maintained under that attribute entry so that all prefixes sharing the same attribute are centralized in one location. This can be used to compute ECMP path comparisons for NHG-related operations.

[0046] Whenever a routing protocol (such as convergence module 316A) compiles routes without assigning an NHG, an NHG can be created as part of each source NHG module 320. Each source NHG can then be created, and routes can be compiled into the kernel of the underlying network device that is part of the NHG. When the network is BGP-compatible, an NHG can be created at least in part based on an identifier in a received attribute. The key for the NHG is the value of the received identifier. In one example, BGP is the owner of the NHG assigned by BGP, rather than the NHG provided by each source NHG module 320. BGP can assign one NHG for each route, and at least one NHG for each route that has an identifier in an attribute, regardless of whether there is a match in that attribute. BGP can receive routes in the form of route updates and can perform a replacement operation immediately using the identifier in the attribute (in the example of ECMP reduction or ECMP weight change), or after a period that may be a predetermined period (in the case of ECMP extension). Furthermore, BGP can enable the revocation of routes with that attribute, in which case the NHG associated with such a route or source can be deleted. In a steady state, the size of the NHG on a switch (which can be a leaf or a backbone) can be proportional to the number of received router-identifier logical IP addresses. This proportion can be limited by the order of several leaves in the network capable of exchanging route updates.

[0047] This article Figures 1 to 3 The aspects described herein can provide convergence optimizations to improve route convergence in the event of network events, which may include updates, changes, or failures. Network events can include events that may cause software or system restarts of network devices (such as switches, routers, etc.). Network events can include events such as power failures, hardware failures, or catastrophic software failures, which may cause link 210 between network devices to fail. Such network events have a potential impact on traffic flowing through various parts of the network and may require traffic to be rerouted to support backup routes after convergence 318 in the event of a failure. Furthermore, the convergence optimizations described herein can be performed independently of several routes that may be affected by network events. In one instance, since convergence can be measured by the duration of data traffic lost for traffic to destinations affected by network events, a shorter duration results in better convergence.

[0048] Figures 1 to 3 The various aspects can include specific applications of BGP used as the routing protocol in networks 100 and 200, but can also be broadly applied to other routing protocols and other types of networks compatible with other routing protocols. In one example, Figures 1 to 3The modules within can be used by switches or routers to self-identify as the source of advertised routes; in addition to self-advertising, they are also used to indicate routes as sources and to construct the software and hardware state of network devices using received information that may be related to self-identification and self-advertising. These states can be unique to each source network device. In turn, these states or related information can be used to forward received traffic to routes associated with that source network device (and the receiving network device). In one example, the traffic can be data packets.

[0049] Figures 1 to 3 The system also supports the ability for switches or routers to prioritize the publication of announcements. For example, initial and subsequent network events can be subject to the self-identification of routing information, rather than other routing information from the same source network device. Figures 1 to 3 The system also supports the following capabilities: switches or routers can use routing information from another switch or router to identify self-identified changes and quickly and efficiently update their software and hardware status, as well as make changes immediately effective for all routes (receivers) associated with that routing source.

[0050] All of these aspects can be implemented using BGP, or provided in BGP-compliant networks; therefore, the convergence optimizations described in this paper are fully compliant with at least the BGP specification. This enables the convergence optimizations described in this paper to interoperate in networks that may contain network devices that do not explicitly support the convergence optimizations described in this paper. Other network devices that can support the convergence optimizations can improve subnets or groups within the network, as well as the network as a whole. The convergence optimizations described in this paper can be applied to network devices running regular workloads or artificial intelligence / machine learning (AI / ML) workloads in modern data centers, as all such workloads may require traffic to be handled by dedicated hardware components such as application-specific integrated circuits (ASICs). References to hardware states in this paper are intended to support such functionality in ASICs and other hardware, rather than to limit the convergence optimizations to specific types of network devices or specific hardware variants within such network devices.

[0051] In some examples, such as Figure 3As shown, when the backbone (such as backbone 21) withdraws host Z1-100 from leaf 21, leaf 21 may receive a BGP deletion of the loopback routing for leaf 21. This could be done using the identifier associated with that leaf. The BGP deletion triggers an NHG replacement associated with that identifier. In this case, leaf 21NHG1{backbone 11, backbone 21} can be replaced by {backbone 11}, causing all host Z1-100 prefixes to point to leaf 21NHG1{backbone 11}. For host Y1-100 in leaf 12 with NHG2{backbone 12, backbone 22} or host P1-100 in leaf 22 with NHG3{backbone 22}, there may be no change. Therefore, an update is applied to the routing, including leaf 21 and backbone 21. This solution is applicable to 2CLOS multi-links between network devices, 3CLOS single-link or multi-links between network devices, and link failures at the leaf layer, backbone layer, or superbackbone layer.

[0052] In some examples, the link failures described in this paper can be resolved when these failures occur in Clos network topologies (such as 2CLOS or 3CLOS), on single or multiple links between network devices, in W-ECMP-based or ECMP-based networks, and at different layers (such as leaves, backbones, and superbackbone). The methods described in this paper address convergence issues to repair ECMP routes. For prefixes previously learned on the failed links, ECMP can be quickly adjusted on all relevant network devices to reflect changes in forwarding, at least in part, based on changes reflected in the new network topology. Furthermore, in some examples, advertisements can be configured to be made only on leaves. This can be viewed as a stipulation from the source network device, as the BGP protocol allows special handling of advertised routes under certain configurations (including those described in this paper). A SOO can be appended only to routes from the source network device where the route originated. Once configured, the BGP protocol can append the SOO to the route source extension community for all routes advertised to its peers.

[0053] In some examples, the redistribution of route initiator IDs can be performed from the source network device under the BGP protocol via a loopback connection. For example, redistribution can be advertised via the BGP protocol using a loopback connection. The loopback connection can be configured with an IPv4 or IPv6 address matching the route initiator ID. Loopback connections can be used to create NHG 320s for each source to achieve faster convergence. Configuration using loopback connections can be performed on all switches at all levels, including two or more routes, such as leaves, backbones, and superbacklines. For example, when the BGP protocol receives a "route with SOO appended" indication (such as via an extended community), the BGP protocol can assign NHG 320s for each source, which can allow or support the BGP protocol to perform next-hop replacement when links or nodes change as part of a network topology change. Therefore, the approach presented in this paper allows for route programming using NHGs, where ECMP routes can contain only advertised routes. When updating ECMP routes to the forwarding plane, a surge in the number of NHGs may not occur. In the event of a failure, prefix-independent convergence is performed to update the forwarding plane (such as all network devices on two or more routes) with new ECMP paths independent of the existing number of prefixes.

[0054] In some examples, the SOO can be encoded into the route source extended community using the IPAddress:NN format, where the high octets of the extended community type field are provided together with the low octets of the extended community type field. When the BGP protocol includes an advertised source configuration, the IP address portion of the SOO can be derived from the router ID within the network. The last two bytes of the SOO can be a fixed, hard-coded value in the code. In some examples, whenever the BGP protocol learns of a new SOO (such as through a route source extended community), an entry can be created in a hash table or other routing table (such as route table 316B). In some examples, route table 316B can be configured for the new SOO. Whenever an SOO entry is created in hash table 316B, a destination entry for that route can be maintained under the SOO entry so that all prefixes sharing the same SOO are located in the same position. This is used to calculate the ECMP path for NHG-related operations.

[0055] Figure 4A computer and processor aspect 400 of a system for convergence optimization based on usage attributes and at least one network address according to at least one embodiment is illustrated. According to at least one embodiment, the computer and processor aspect 400 may be executed by one or more processors, including systems-on-a-chip (SoCs) or some combination thereof, comprising a single processor that may include an execution unit for executing instructions. Such one or more processors may include a CPU, a data processing unit (DPU), and a graphics processing unit (GPU), and may be located within switches 106; 114, any different interconnect device 120, or a first or second set of nodes 1-N 104A-N, 1-N 112A-N, as described throughout this document.

[0056] In at least one embodiment, according to this disclosure (e.g., the embodiments described herein), the computer and processor aspect 400 may include, but is not limited to, components such as processor 402 for executing algorithms for processing data using an execution unit containing logic. In at least one embodiment, the computer and processor aspect 400 may include a processor, such as those provided by Intel Corporation (Santa Clara, California). Processor series, Xeon TM , XScale TM and / or StrongARM TM , Core TM or Nervana TM A microprocessor, although other systems (including PCs, engineering workstations, set-top boxes, etc.) may also be used. In at least one embodiment, the computer and processor aspect 400 can perform... A version available in Redmond, Washington. Operating system, although other operating systems can also be used (e.g. and Embedded software and / or graphical user interface.

[0057] The embodiments can be used in other devices, such as handheld devices and embedded applications. Some examples of handheld devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (“PDAs”), and handheld PCs. In at least one embodiment, the embedded application may include a microcontroller, a digital signal processor (“DSP”), a system-on-a-chip, a network computer (“NetPC”), a set-top box, a network hub, a wide area network (“WAN”) switch, or any other system that can execute one or more instructions according to at least one embodiment.

[0058] In at least one embodiment, the computer and processor aspect 400 may include, but is not limited to, a processor 402, which may include, but is not limited to, one or more execution units 408, which are used in accordance with the provisions herein. Figures 1 to 3 and Figures 5 to 7 The technologies described in at least one or more of the above implement various aspects. In at least one embodiment, the computer and processor aspect 400 is a single-processor desktop or server system, but in another embodiment, the computer and processor aspect 400 may be a multiprocessor system.

[0059] In at least one embodiment, processor 402 may include, but is not limited to, a Complex Instruction Set Computer (“CISC”) microprocessor, a Reduced Instruction Set Computing (“RISC”) microprocessor, a Very Long Instruction Word (“VLIW”) microprocessor, a processor implementing a combination of instruction sets, or any other processor device, such as a digital signal processor. In at least one embodiment, processor 402 may be coupled to processor bus 410, which can transmit data signals between processor 402 and other components in the computer and processor aspect 400.

[0060] In at least one embodiment, processor 402 may include, but is not limited to, a Level 1 (“L1”) internal cache memory (“cache”) 404. In at least one embodiment, processor 402 may have a single internal cache or multiple internal cache levels. In at least one embodiment, cache 404 may be located external to processor 402. Other embodiments may also include a combination of both internal and external caches, depending on the specific implementation and requirements. In at least one embodiment, register file 406 may store different types of data in various registers, including but not limited to integer registers, floating-point registers, status registers, and instruction pointer registers.

[0061] In at least one embodiment, execution unit 408 (including, but not limited to, logic for performing integer and floating-point operations) also resides in processor 402. In at least one embodiment, processor 402 may also include microcode (“ucode”) read-only memory (“ROM”) storing microcode of certain macro instructions. In at least one embodiment, execution unit 408 may also include logic for processing packaged instruction set 409.

[0062] In at least one embodiment, by including a packet instruction set 409 and associated circuitry for executing instructions in the instruction set of the general-purpose processor, operations used by a variety of multimedia applications can be performed using the packet data in the processor 402. In at least one embodiment, a variety of multimedia applications can be accelerated and performed more efficiently by using the entire width of the processor's data bus to perform operations on the packet data, which eliminates the need to transfer smaller units of data on the processor's data bus to perform one or more operations on a data element at a time.

[0063] In at least one embodiment, execution unit 408 may also be used for a microcontroller, embedded processor, graphics device, DSP, and other types of logic circuitry. In at least one embodiment, computer and processor aspect 400 may include, but is not limited to, memory 420. In at least one embodiment, memory 420 may be a dynamic random access memory (“DRAM”) device, a static random access memory (“SRAM”) device, a flash memory device, or another memory device. In at least one embodiment, memory 420 may store instructions 419 and / or data 421 represented by data signals, which may be executed by processor 402.

[0064] In at least one embodiment, the system logic chip may be coupled to processor bus 410 and memory 420. In at least one embodiment, the system logic chip may include, but is not limited to, a memory controller hub (“MCH”) 416, and processor 402 may communicate with MCH 416 via processor bus 410. In at least one embodiment, MCH 416 may provide a high-bandwidth memory path 418 to memory 420 for storing instructions and data, and for storing graphics commands, data, and textures. In at least one embodiment, MCH 416 may direct data signals between processor 402, memory 420, and other components in the computer and processor aspect 400, and bridge data signals between processor bus 410, memory 420, and system I / O interface 422. In at least one embodiment, the system logic chip may provide a graphics port for coupling to a graphics controller. In at least one embodiment, MCH 416 may be coupled to memory 420 via high-bandwidth memory path 418, and graphics / video card 412 may be coupled to MCH 416 via Accelerated Graphics Port (“AGP”) interconnect 414.

[0065] In at least one embodiment, the computer and processor aspect 400 may use system I / O interface 422 as a proprietary hub interface bus to couple MCH 416 to I / O controller hub (“ICH”) 430. In at least one embodiment, ICH 430 may provide direct connectivity to certain I / O devices via a local I / O bus. In at least one embodiment, the local I / O bus may include, but is not limited to, a high-speed I / O bus for connecting peripheral devices to memory 420, chipset, and processor 402. Examples may include, but are not limited to, an audio controller 429, a firmware hub (“flash BIOS”) 428, a wireless transceiver 426, a data storage device 424, a conventional I / O controller 423 including a user input and keyboard interface 425, a serial expansion port 427 (such as a Universal Serial Bus (“USB”) port), and a network controller 434. In at least one embodiment, data storage device 424 may include a hard disk drive, floppy disk drive, CD-ROM device, flash memory device, or other mass storage device.

[0066] In at least one embodiment, Figure 4 The illustration shows a computer and processor aspect 400, which includes interconnected hardware devices or "chips," while in other embodiments, Figure 4 An exemplary SoC can be shown. In at least one embodiment, Figure 4 The devices shown can be connected via proprietary interconnects or standardized interconnects (e.g.) The components of the computer and processor aspect 400 are interconnected using either a compute fast link (CXL) interconnect or some combination thereof. In at least one embodiment, one or more components of the computer and processor aspect 400 are interconnected using a compute fast link (CXL) interconnect.

[0067] Therefore, in at least one embodiment, Figures 1 to 4 The system therefore includes one or more execution units 408 within switches 106; 114, any different interconnect device 120, or the first group of nodes 1-N 104A-N or the second group of nodes 1-N 112A-N to support convergence optimization. For example, at least one execution unit 408 supports convergence optimization in other processing units of other host machines (or nodes). At least one execution unit 408 is part of one or more circuits in the network that will be associated as a node. For example, at least one execution unit 408 of a processor may be a circuit that, together with another circuit of another processor in a different node, forms part of a node.

[0068] Figure 5A process flow or method 500 is illustrated in a system for convergence optimization using attributes and at least one network address according to at least one embodiment. Method 500 may include: generating 502 attributes containing a source network device identifier by a source network device. Method 500 may include: generating 504 at least one network address representing the source network device and containing a prefix associated with a host of the source network device. Steps 502 and 504 may be performed simultaneously or not simultaneously. Method 500 may include: verifying or determining whether the source network device is ready to advertise a route 506. Method 500 may include: advertising 508 a route having the attribute and at least one network address by the source network device. Method 500 may include: determining 510 that the identifier matches at least the prefix of the route advertised by the source network device by a receiving network device receiving the route. Method 500 may include determining 512 convergence for routing packets from the receiving network device by the receiving network device.

[0069] Figure 6 Another process flow or method 600 is shown in a system for convergence optimization based on usage attributes and at least one network address according to at least one embodiment. Method 600 may support Figure 5 Method 500. For example, method 600 may include receiving, in the receiving network device, an indication of a fault in the network at 602. Method 600 may include receiving, at 604, an indication from... Figure 5 The route advertisement in step 508 includes attributes and network address identifiers. Method 600 may include determining or verifying whether the prefix of the attributes and network address matches 606. Method 600 may include performing the empty procedure 608 for additional advertisements from the source network device after determining a match 606. Method 600 may include performing convergence 610 to support... Figure 5 Step 512 in the process. Thus, only routes with matching identifiers in their attributes (representing router-identifier logical IP addresses) can be used for convergence, and this process supports the convergence optimization here.

[0070] Figure 7 Another process flow or method 700 is illustrated in a system for convergence optimization based on usage attributes and at least one network address according to at least one embodiment. Method 700 may support... Figure 5 Method 500 or Figure 6Method 700 may include one or more of the following methods: For example, method 700 may include enabling 702 the network to support individual NHGs for each network device. Method 700 may include assigning 704 NHGs to the source network device by the receiving network device. Method 700 may include determining or verifying whether a fault has occurred in the network 706. This can be achieved by providing instructions to the network device, by polling performed by the network device, or by a service subscription performed by the network device. Method 700 may include performing 708 a replacement operation on the NHG and all prefixes previously associated with the source network device by the receiving network device. Method 700 may include leaving 710 additional NHGs of other source network devices that are not part of a fault in the network unchanged.

[0071] All other variations are within the spirit and scope of this disclosure. Therefore, although the disclosed technology can be modified and alternatively constructed in various ways, certain illustrated embodiments have been shown in the accompanying drawings and described in detail above. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents that conform to the spirit and scope of this disclosure, as defined in the appended claims.

[0072] In the context of describing the disclosed embodiments (especially in the context of the following claims), the use of the terms “a,” “an,” and “the,” and similar pronouns, should be interpreted to cover both singular and plural forms unless otherwise stated herein or the context clearly contradicts it, and should not be construed as a definition of the terms. The terms “comprising,” “having,” “including,” and “containing” should be interpreted as open-ended terms (meaning “including but not limited to”) unless otherwise indicated. “Connection,” when unmodified and referring to a physical connection, should be interpreted as partially or wholly contained within, attached to, or combined with, even in the presence of intermediates. The enumeration of numerical ranges herein is intended only as a shorthand method for individually referring to each individual value within a range, unless otherwise stated herein, and each individual value is incorporated into the specification as if it were individually enumerated herein. In at least one embodiment, unless otherwise stated or contradicted by the context, the use of the terms “set” (e.g., “set of items”) or “subset” should be understood as a non-empty set containing one or more members. Furthermore, unless otherwise stated or contradicted by the context, the term "subset" of a corresponding set does not necessarily mean a proper subset of the corresponding set, but a subset and a corresponding set can be considered equivalent.

[0073] Unless explicitly stated otherwise or clearly contradicted by the context, connective language, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C," should be understood in context as generally used to indicate that an item, term, etc., can be A, B, or C, or any non-empty subset of the set of A, B, and C. For example, in an illustrative example of a set containing three members, the connective phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Therefore, such connective language generally does not imply that some embodiments require the presence of at least one of A, at least one of B, and at least one of C. Furthermore, unless explicitly stated otherwise or contradicted by the context, the term "multiple" indicates a plural state (e.g., "multiple items" means multiple items). In at least one embodiment, the number of multiple items is at least two, but the number of items may be more when explicitly stated or indicated by the context. Furthermore, unless otherwise stated or the context clearly indicates otherwise, the phrase “based on” means “at least partially based on”, not “based on only”.

[0074] Unless otherwise stated herein or where the context clearly contradicts it, the operations of the processes described herein may be performed in any suitable order. In at least one embodiment, processes such as those described herein (or variations and / or combinations thereof) are executed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more application programs) that executes jointly on one or more processors via hardware or a combination thereof. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program containing a plurality of instructions executable by one or more processors.

[0075] In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that does not include transient signals (e.g., propagation of transient electrical or electromagnetic transmissions), but includes non-transitory data storage circuitry (e.g., buffers, caches, and queues) within the transceiver of the transient signals. In at least one embodiment, code (e.g., executable code or source code) is stored in a collection of one or more non-transitory computer-readable storage media, on which executable instructions (or other memory for storing executable instructions) are stored, which, when executed by one or more processors of a computer system (i.e., as a result of execution), cause the computer system to perform the operations described herein. In at least one embodiment, a set of non-transitory computer-readable storage media comprises multiple non-transitory computer-readable storage media, and one or more individual non-transitory storage media lack all the code, while the multiple non-transitory computer-readable storage media collectively store all the code. In at least one embodiment, the executable instructions are executed such that different instructions are executed by different processors—for example, instructions are stored on a non-transitory computer-readable storage medium, the main central processing unit (“CPU”) executes some instructions, and the graphics processing unit (“GPU”) executes other instructions. In at least one embodiment, different components of the computer system have independent processors, and different processors execute different subsets of instructions.

[0076] In at least one embodiment, an arithmetic logic unit is a set of combinational logic circuits that receives one or more inputs to produce a result. In at least one embodiment, a processor uses arithmetic logic units to implement mathematical operations, such as addition, subtraction, or multiplication. In at least one embodiment, arithmetic logic units are used to implement logical operations, such as logical AND / OR or XOR. In at least one embodiment, an arithmetic logic unit is stateless and consists of physical switching elements, such as semiconductor transistors arranged to form logic gates. In at least one embodiment, an arithmetic logic unit may operate internally as a stateful logic circuit with an associated clock. In at least one embodiment, an arithmetic logic unit may be constructed as an asynchronous logic circuit whose internal state is not maintained in an associated register set. In at least one embodiment, a processor uses arithmetic logic units to combine operands stored in one or more registers of the processor and produce an output that can be stored by the processor in another register or memory location.

[0077] In at least one embodiment, as a result of processing instructions retrieved by the processor, the processor provides one or more inputs or operands to the arithmetic logic unit (ALU), causing the ALU to produce a result at least in part based on instruction code provided to the inputs. In at least one embodiment, the instruction code provided by the processor to the ALU is at least in part based on instructions executed by the processor. In at least one embodiment, combinational logic in the ALU processes the inputs and produces an output placed on a bus within the processor. In at least one embodiment, the processor selects a destination register, memory location, output device, or output storage location on the output bus so that clock control of the processor causes the result produced by the ALU to be sent to the desired location.

[0078] Therefore, in at least one embodiment, the computer system is configured to implement one or more services that individually or collectively perform the operations of the processes described herein, and such computer systems are configured with suitable hardware and / or software that allow the operations to be performed. Furthermore, the computer system implementing at least one embodiment of this disclosure is a single device, while in another embodiment it is a distributed computer system comprising multiple devices operating in different ways, such that the distributed computer system performs the operations described herein, and the single device does not perform all the operations.

[0079] The use of any and all examples or exemplary language (such as "such as") provided herein is intended only to better illustrate implementations of this disclosure and, unless otherwise stated, does not constitute a limitation on the scope of this disclosure. No language in the specification should be construed as indicating that any unstated element is essential to the practice of this disclosure.

[0080] In the specification and claims, the terms “coupled” and “connected” and their derivatives may be used. It should be understood that these terms are not intended to be synonymous with each other. Rather, in certain examples, “connected” or “coupled” can be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. “Coupled” can also indicate that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0081] Unless otherwise expressly stated, it will be understood that throughout this specification, terms such as “processing,” “calculating,” “estimating,” and “determining” refer to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulate and / or convert data represented as physical quantities (such as electronic quantities) in the registers and / or memory of the computing system into other data similarly represented as physical quantities in the memory, registers, or other such information storage, transmission, or display devices of the computing system.

[0082] Similarly, the term "processor" can refer to any device or part of a device that processes electronic data from registers and / or memory and converts that electronic data into other electronic data that can be stored in registers and / or memory. As a non-limiting example, a "processor" can be a CPU or a GPU. A "computing platform" can contain one or more processors. As used herein, a "software" process can include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Furthermore, each process can refer to multiple processes for executing instructions sequentially or in parallel, continuously or intermittently. In at least one embodiment, the terms "system" and "method" are used interchangeably herein, provided that a system can embody one or more methods, and a method can be considered a system.

[0083] This document may relate to acquiring, collecting, receiving, or inputting analog or digital data into a subsystem, computer system, or computer-implemented machine. In at least one embodiment, the process of acquiring, collecting, receiving, or inputting analog and digital data can be accomplished in various ways, such as by receiving data as a parameter to a function call or a call to an application programming interface (API). In at least one embodiment, the process of acquiring, collecting, receiving, or inputting analog or digital data can be accomplished by transmitting data via a serial or parallel interface. In at least one embodiment, the process of acquiring, collecting, receiving, or inputting analog or digital data can be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. It may also involve providing, outputting, transmitting, sending, or presenting analog or digital data. In at least one embodiment, the process of providing, outputting, transmitting, sending, or presenting analog or digital data can be accomplished by transmitting data as an input or output parameter to a function call, an API, or an inter-process communication mechanism.

[0084] While the description herein illustrates example implementations of the described technologies, other architectures may also be used to implement the described functionality, and these architectures are intended to fall within the scope of this disclosure. Furthermore, although specific assignments of responsibilities may have been defined above for descriptive purposes, various functions and responsibilities may be assigned and divided in different ways depending on the specific circumstances.

[0085] Furthermore, although the subject matter has been described using language specific to structural features and / or methodological actions, it should be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or actions described. Rather, the specific features and actions are disclosed as exemplary forms of implementing the claims.

Claims

1. A network comprising a receiving network device and a source network device, the source network device being configured to advertise a route including attributes and at least one network address representing the source network device, wherein the attributes include an identifier of the source network device, and the at least one network address includes a prefix associated with a host restricted by the source network device in a representation, and wherein the receiving network device is configured to determine convergence for routing packets from the receiving network device, in part based on a determination that the identifier at least matches the prefix of the route advertised by the source network device.

2. The network according to claim 1, wherein, The network is compatible with the Border Gateway Protocol (BGP), wherein the attribute is a BGP route source extension community.

3. The network according to claim 1, wherein, The receiving network device is configured to receive an indication of a fault in the network, and to perform the convergence determination for routing the data packets based at least in part on the indication of the fault in the network.

4. The network according to claim 1, wherein, The receiving network device is further configured to receive additional announcements of routes associated with the host of the source network device, and is further configured to perform a null procedure for additional announcements from the source network device following an announcement containing the routes announced by the source network device, wherein the null procedure is used to maintain the routes associated with the routes containing the attributes and the at least one network address without updating the additional announcements of the routes.

5. The network according to claim 1, wherein, The receiving network device is also configured to assign a next-hop group (NHG) to the source network device, and wherein the network supports individual NHGs for each network device.

6. The network according to claim 5, wherein, In the event of a failure associated with the source network device, the receiving network device is also configured to perform a replacement operation on the NHG and all prefixes previously associated with the source network device, regardless of any individual updates from the source network device.

7. The network according to claim 6, wherein, The additional NHGs of other source network devices in the network that are not part of the fault in the network remain unchanged.

8. The network according to claim 1, wherein, The source network device and the receiving network device are leaf network devices, backbone network devices, or super backbone network devices.

9. A source network device in a network, the source network device being configured to advertise a route including attributes and at least one network address representing the source network device, wherein, The attribute includes an identifier of the source network device, and the at least one network address includes a prefix associated with a host restricted by the source network device in its representation, and wherein the attribute and the at least one network address are used to enable a receiving network device in the network to determine convergence for routing packets from the receiving network device, in part based on a determination that the identifier at least matches the prefix of the route advertised by the source network device.

10. The source network device according to claim 9, wherein, The source network device is part of a network compatible with Border Gateway Protocol (BGP), and the attribute is a routing source extension community of the BGP.

11. The source network device according to claim 9, wherein, The source network device is a leaf network device, backbone network device, or super backbone network device in the network.

12. A receiving network device in a network, the receiving network device being configured to receive a route advertised by a source network device, the route including attributes and at least one network address representing the source network device, wherein, The attribute includes an identifier of the source network device, and the at least one network address includes a prefix associated with a host restricted by the source network device in the representation, and wherein the receiving network device is further configured to determine convergence for routing packets from the receiving network device, in part based on a determination that the identifier at least matches the prefix of the route advertised by the source network device.

13. The receiving network device according to claim 12, wherein, The receiving network device is also configured to receive an indication of a fault in the network, and to perform the convergence determination for routing the data packets based at least in part on the indication of the fault in the network.

14. The receiving network device according to claim 12, wherein, The receiving network device is also configured to receive additional announcements of routes associated with the host of the source network device, and is further configured to perform a null procedure for the additional announcements from the source network device following an announcement including the routes announced by the source network device.

15. The receiving network device according to claim 12, wherein, The receiving network device is also configured to assign a next-hop group NHG to the source network device, wherein the network supports individual NHGs for each network device, wherein when a fault associated with the source network device occurs, the receiving network device is also configured to perform a replacement operation on the NHG and all prefixes previously associated with the source network device, independently of individual updates from the source network device, and wherein additional NHGs of other source network devices in the network that are not part of the fault in the network remain unchanged.

16. A method for a network, comprising: The source network device generates attributes and at least one network address, the attributes including an identifier of the source network device, the at least one network address representing the source network device and including a prefix associated with a host restricted by the source network device in the representation; The route, including the attribute and the at least one network address, is announced by the source network device; as well as The convergence for routing packets from the receiving network device is determined by the receiving network device in part based on the determination that the identifier at least matches the prefix of the route announced by the source network device.

17. The method of claim 16, wherein the network is compatible with Border Gateway Protocol (BGP), wherein the attribute is a routing source extension community of the BGP, and wherein the source network device and the receiving network device are leaf network devices, backbone network devices, or super backbone network devices in the network.

18. The method of claim 16, further comprising: The receiving network device receives an indication of a fault in the network. as well as The determination of convergence for routing the data packets is performed at least in part based on the indication of the fault in the network.

19. One or more circuits for performing convergence within a Border Gateway Protocol (BGP) protocol, the convergence being used to follow changes in network topology and group two or more routes for a host together using a route initiator identifier (RIOID), the host being represented by a single leaf switch among a plurality of network devices in the network topology, wherein the RIOID serves as the basis for updating the routing configuration associated with the plurality of network devices and associated with the two or more routes in the group.

20. One or more circuits according to claim 19, wherein, The route initiator ID is associated with a next-hop group (NHG) representing the two or more routes, wherein a change in the network topology will cause a change in the NHG, and wherein the change in the NHG allows the two or more routes under the NHG to be changed to use a network device in the network devices associated with the NHG that is different from the initial network device in the network devices.

Images