Continuity information included in metric data elements of non-passing attributes

Abstract

Embodiments of the present disclosure relate to continuity information included in metric data elements of non-passing attributes. In some implementations, a border gateway protocol (BGP) network device may receive a first message from an initiator BGP network device via a first other BGP network device, where the first message includes first attribute data associated with a non-passing attribute, wherein the first attribute data includes a first metric data element associated with a metric data element format and indicative of a metric type, a metric value, and continuity information. The BGP may process the first message to determine first path information associated with a first path from the BGP network device to the initiator BGP network device via a first other BGP network device.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to Indian patent application serial number 202341075094 filed on November 3, 2023 and invention name "EXTENSION TO ACCUMULATED INTERIOR GATEWAY PROTOCOL ATTRIBUTE TO CARRYENHANCED GENERIC-METRIC TYPE-LENGTH-VALUE", the disclosure of which is considered a part of this patent application and is incorporated by reference into this patent application. Background Art

[0003] Border Gateway Protocol (BGP) is a standardized exterior gateway protocol that is used to exchange routing and reachability information between different autonomous systems (AS). Summary of the invention

[0004] In some implementations, the method includes: receiving, by a BGP network device, a first message from an initiating BGP network device via a first other BGP network device, wherein the first message includes first attribute data associated with a non-transitive attribute, wherein the first attribute data includes a first metric data element associated with a metric data element format and indicating a metric type, a metric value, and continuity information; and processing, by the BGP network device, the first message to determine, via the first other BGP network device, first path information associated with a first path from the BGP network device to the initiating BGP network device.

[0005] In some implementations, a BGP network device includes one or more memories; and one or more processors to: generate a first message including first attribute data associated with a non-transitive attribute, wherein the first attribute data includes a first metric data element associated with a metric data element format and indicating a metric type, a metric value, and continuity information; and send the first message to a first other BGP network device.

[0006] In some implementations, a non-transitory computer-readable medium storing a set of instructions includes one or more instructions that, when executed by one or more processors of a BGP network device, cause the BGP network device to: receive a message from an initiator BGP network device, wherein the message includes attribute data associated with a non-transitive attribute, wherein the attribute data includes a metric data element associated with a metric data element format indicating a metric type, a metric value, and continuity information; update the metric data element of the attribute data of the message; and send the message to another BGP network device. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A to Figure 1B is an example implementation diagram associated with continuity information included in a metric data element of a non-transitive attribute.

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

[0009] Figure 3 is an example component diagram of devices associated with the systems and / or methods described herein.

[0010] Figure 4 is an example component diagram of devices associated with the systems and / or methods described herein.

[0011] Figure 5 is a flow diagram of an example process associated with continuity information included in a metric data element of a non-transitive attribute.

[0012] Figure 6 is a flow diagram of an example process associated with continuity information included in a metric data element of a non-transitive attribute.

[0013] Figure 7 is a flow diagram of an example process associated with continuity information included in a metric data element of a non-transitive attribute. DETAILED DESCRIPTION

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

[0015] There are many routing protocols designed to operate within a single administrative domain, collectively referred to as Interior Gateway Protocols (IGPs). Typically, each link is assigned a specific "metric" value. A path between two nodes can then be assigned a "distance", which is the sum of the metrics of all links belonging to that path. An IGP selects the "shortest" (e.g., minimum distance) path between any two nodes.

[0016] In contrast to IGP, Border Gateway Protocol (BGP) runs over an arbitrarily large number of administrative domains, which are often referred to as Autonomous Systems (AS). BGP does not make its path selection decisions based on metrics; there is no so-called "intra-AS metric". However, the Accumulated IGP (AIGP) attribute can be used to accumulate IGP costs across domains. This is useful for establishing end-to-end path costs across domains.

[0017] The AIGP attribute is a non-transitive attribute and can be forwarded by a BGP network device to a neighboring BGP network device when the BGP network device is enabled to advertise AIGP. However, when AIGP is enabled on a neighboring BGP network device, or is not configured to understand the AIGP attribute, the neighboring BGP network device cannot propagate the AIGP attribute, and therefore end-to-end path metric accumulation does not occur. This is known as the "continuity" problem, where the end-to-end path cost cannot be accurately determined.

[0018] Therefore, in order to obtain the end-to-end path cost, AIGP must be enabled on all network devices along the cross-domain path (e.g., on all network devices that change the "next hop" of packets transmitting the path). In addition to upgrading all network devices to support AIGP, the network devices also need to be configured to implement propagated cumulative costs. Until all network devices are upgraded and configured, the end-to-end path cost cannot be calculated, propagated, and used to influence the best path decision (e.g., because the receiver network device cannot determine whether the cumulative cost is the entire cumulative cost associated with the path, or only a portion of the cumulative cost associated with the path).

[0019] Some implementations described herein include multiple BGP network devices, such as an initiator BGP network device, multiple intermediate BGP network devices, and a receiver BGP network device. The initiator BGP network device generates a message (e.g., a BGP update message) including attribute data associated with a non-transmittal attribute (e.g., an AIGP attribute). The attribute data includes a metric data element associated with a metric data element format, such as an AIGP sub-attribute type-length-value (TLV) (which is also referred to as a "generic metric TLV"). The metric data element indicates a metric type (e.g., a "cost" parameter or a "benefit" parameter), a metric value (e.g., a "quantized value" or "quantity" of a metric type), and continuity information (e.g., a continuity bit), which indicates that the initiator BGP network device supports non-transmittal attributes for the metric type and a metric data element format.

[0020] The initiator BGP network device then sends the message so that the message is forwarded to the recipient BGP network device via one or more intermediary BGP network devices. Therefore, each time the intermediary BGP network device receives the message, the intermediary BGP network device updates the message. For example, when the intermediary BGP network device supports (e.g., is configured to read and update) non-transmittal attributes and metric data element formats, the intermediary BGP network device updates the metric value (e.g., by adding or "accumulating" the metric value associated with the intermediary BGP network device to the metric value). As another example, when the intermediary BGP network device does not support (e.g., is not configured to read and update) non-transmittal attributes and metric data element formats, the intermediary BGP network device updates the continuity information to indicate that the device does not support non-transmittal attributes and metric data element formats (and the intermediary BGP network device does not update the metric value). It is noteworthy that when the continuity information is set to indicate that the intermediate BGP network device does not support the non-transitive attribute and metric data element format (e.g., by changing the continuity bit from "0" (zero) to "1" (one)), any subsequent intermediate BGP network device cannot reset the continuity information (e.g., reset the continuity bit back to "0" (zero)). This ensures that the continuity information indicates that the cumulative metric value is a partial cumulative metric value.

[0021] Thus, when a receiving BGP network device receives a message (e.g., along a path from the receiving BGP network device to the initiating BGP network device via one or more intermediate BGP network devices), a metric value of a metric data element of the message indicates a sum of metric values ​​associated with the BGP network devices along the path that support the non-transitive attribute and the metric data element format. Additionally, continuity information of the metric data element of the message indicates whether each BGP network device along the path supports the non-transitive attribute and the metric data element format. Thus, the receiving BGP network device determines path information indicating a cumulative metric value (e.g., for a metric type and associated with the path), and whether the cumulative metric value is a fully cumulative metric value or a partially cumulative metric value.

[0022] The receiving BGP network device may then make a routing selection determination based on the path information (and based on other path information associated with other paths to the initiating BGP network device). Because the receiving BGP network device has information indicating whether the cumulative metric value for the metric type is a full cumulative metric value or a partial cumulative metric value (which is not available using current AIGP attribute practices), the receiving BGP network device may select a path that meets one or more criteria associated with the metric type. For example, the receiving BGP network device may only compare (e.g., using a metric ordering technique) paths along which each BGP network device supports a non-transitive attribute and metric data element format for the metric type, e.g., because the respective cumulative metric values ​​for the paths are believed to be accurate.

[0023] In this manner, the continuity issues described herein are resolved.In addition, some implementations ensure that an optimized path (eg, for a particular parameter metric) is selected, which may improve the performance of routing traffic from a recipient BGP network device to an initiator network device.

[0024] Figure 1A to Figure 1B is a diagram of an example implementation 100 associated with continuity information included in a metric data element of a non-transitive attribute. Figure 1A to Figure 1B As shown, the example embodiment 100 includes a plurality of network devices. The plurality of network devices may include, for example, an initiator BGP network device, a receiver BGP network device, and a plurality of intermediate BGP network devices (shown as intermediate BGP network devices 1 to N, where N≥2). Figures 2 to 4 These devices are described in more detail.

[0025] like Figure 1A, and by reference number 102, an initiator BGP network device may generate a first message. For example, the first message may be a BGP update message or another type of message that includes availability information associated with the initiator BGP network device. In some implementations, the first message may include first attribute data associated with a non-transitive attribute (e.g., an AIGP attribute or another type of non-transitive attribute). The first attribute data may include a first metric data element associated with a metric data element format, such as an AIGP sub-attribute TLV (also referred to as a "generic metric TLV") or another type of metric data element format. The first metric data element may indicate a metric type (e.g., a "cost" parameter or a "benefit" parameter for which the metric data element is associated, such as a bandwidth metric type, a delay metric type, a power metric type, or another metric type), a first metric value (e.g., a "quantitative value" or "amount" of a metric type, such as a quantity of a bandwidth metric type, a quantity of a delay metric type, a quantity of a power metric type, or another quantity, which is associated with an initiating BGP network device), and / or first continuity information (e.g., a first continuity "bit", such as a value set to "0" (zero), or another indicator indicating that the initiating BGP network device supports non-transitive attributes and metric data element formats for the metric type). Thus, the first message may include an AIGP attribute, the AIGP attribute including an AIGP sub-attribute TLV, the TLV including continuity information indicating that the initiating BGP network device supports both the AIGP attribute and the AIGP sub-attribute TLV (e.g., for the metric type indicated by the AIGP sub-attribute TLV).

[0026] It is noteworthy that the first attribute data may include one or more other first metric data elements (e.g., similar to the first metric data element, but indicating different metric types, metric values, and continuity information). For example, the first message may include an AIGP attribute, which includes one or more AIGP sub-attribute TLVs (e.g., each TLV is associated with a different metric type). Although the additional details described herein are only directed to the first metric data element, each BGP network device described may process one or more other first metric data elements in a similar manner.

[0027] As shown by reference numeral 104, the initiator BGP network device may send a first message. The initiator BGP network device may send the first message to a first other BGP network device, such as Figure 1AThe initiator BGP network device can send the first message to the first other BGP network device via the connection between the initiator BGP network device and the first other BGP network device. Therefore, the first other BGP network device can receive the first message from the initiator BGP network device (for example, via the connection between the initiator BGP network device and the first other BGP network device).

[0028] As shown by reference numeral 106, a first other BGP network device (e.g., Figure 1A The intermediate BGP network device 1 shown in the figure can update the first metric data element of the first attribute data of the first message. In some implementations, the first other BGP network device can update the first metric value and / or the first continuity information of the first metric data element. For example, when the first other BGP network device supports non-transfer attributes and metric data element formats, the first other BGP network device can update the first metric value (for example, by adding or "accumulating" the metric value for the metric type associated with the connection between the initiator BGP network device and the first other BGP network device to the first metric value). The first other BGP network device can also update the first continuity information so that the first continuity information indicates that the first other BGP network device and the initiator BGP network device each support the non-transfer attributes and metric data element format (for example, for the metric type). When the first continuity information is a first continuity bit, the first other BGP network device can update the first continuity information by resubmitting the value of the continuity bit (for example, resubmitting "0" (zero) as "0" (zero), or resubmitting "1" (one) as "1" (one)).

[0029] As another example, when the first other BGP network device does not support at least one of the non-transitive attribute or the metric data element format, the first other BGP network device may update (e.g., may only update) the first continuity information so that the first continuity information indicates that the first other BGP network device does not support the non-transitive attribute and the metric data element format (e.g., for the metric type). When the first continuity information is a second continuity bit, the first other BGP network device may update the first continuity information by changing the value of the continuity bit (e.g., changing "0" (zero) to "1" (one)).

[0030] As shown by reference number 108, a first other BGP network device (eg, intermediate BGP network device 1) may send a first message. The first other BGP network device may send the first message to a receiving BGP network device, such as Figure 1AAs shown in . The first other BGP network device can send the first message to the receiving BGP network device via the connection between the first other BGP network device and the receiving BGP network device. Therefore, the receiving BGP network device can receive the first message from the first other BGP network device (for example, via the connection between the first other BGP network device and the receiving BGP network device).

[0031] In this way, the first message can be forwarded to the recipient BGP network device. Figure 1A A first message is shown to be received and forwarded by a single first other BGP network device, but the first message may be received and forwarded by one or more additional other BGP network devices before being sent to the recipient BGP network device. Then, a first path (e.g., a service forwarding path) from the recipient BGP network device to the initiator BGP network device may include the first other BGP network device, and, when present, may include one or more additional first other BGP network devices.

[0032] Thus, each of the one or more additional first other BGP network devices may receive, update, and send the first message in a similar manner as described herein with respect to the first other BGP network device (e.g., associated with reference numbers 104, 106, and 108). In this manner, when a specific first other BGP network device of the first path receives the first message from another specific first other BGP network device of the first path, the first continuity information of the first message may indicate whether each BGP network device along the first path from the other specific first other BGP network device to the initiator BGP network device supports the metric type, the non-transitive attribute, and the metric data element format (e.g., supports the AIGP attribute and the AIGP sub-attribute TLV). For example, when the first continuity information is a first continuity bit having a value of "0" (zero), each BGP network device along the first path from the other specific first other BGP network device to the initiator BGP network device supports the non-transitive attribute and the metric data element format, and therefore resubmits the value of the first continuity bit (e.g., resubmits "0" (zero) to "0" (zero)). As an alternative example, when the first continuity information is a first continuity bit having a value of “1” (one), at least one BGP network device along the first path from another specific first other BGP network device to the initiator BGP network device does not support the non-transitive attribute and metric data element format and therefore changes the value of the first continuity bit (e.g., from “0” (zero) to “1” (one)).

[0033] In addition, when received by the receiving BGP network device, the first continuity information of the first metric data element of the first message can indicate whether each BGP network device along the first path from the first other BGP network device before the receiving BGP network device to the initiating BGP network device supports the non-transmittal attribute and the metric data element format for the metric type. For example, when the first continuity information is a first continuity bit with a value of "0" (zero), each BGP network device along the first path from the first other BGP network device (e.g., the BGP network device that sends the first message to the receiving BGP network device) to the initiating BGP network device supports the non-transmittal attribute and the metric data element format for the metric type. As an alternative example, when the first continuity information is a first continuity bit with a value of "1" (one), at least one BGP network device along the first path from the first other BGP network device (e.g., the BGP network device that sends the first message to the receiving BGP network device) to the initiating BGP network device does not support the non-transmittal attribute and the metric data element format for the metric type. Notably, when the first continuity bit is set to “1” by a BGP network device along a first path, subsequent BGP network devices along the first path resubmit the first continuity bit (e.g., as “1” (one)) to ensure that the first continuity bit indicates that at least one BGP network device along the first path does not support non-transitive attributes and metric data element formats for metric types.

[0034] As shown by reference number 110, the receiving BGP network device may determine first path information associated with a first path (e.g., from the receiving BGP network device to the initiating BGP network device, via the first other BGP network device, and, when present, one or more additional first other BGP network devices). The first path information may indicate a cumulative first metric value (e.g., cumulative cost or cumulative benefit) for a metric type associated with the first path. For example, the receiving BGP network device may process the first message (e.g., by reading and / or parsing the first message) to determine a first metric value for the first message (e.g., including the cumulative first metric values ​​of BGP network devices along the first path before the receiving BGP network device), and may add to the first metric value a metric value for the metric type associated with the connection between the receiving BGP network device and the first other BGP network device that sent the first message to the receiving BGP network device. In some implementations, the first path information may also indicate whether the first cumulative metric value is a full cumulative metric value (e.g., a full cumulative cost or a full cumulative benefit) or a partial cumulative metric value (e.g., a partial cumulative cost or a partial cumulative benefit). For example, the receiving BGP network device may process the first message (e.g., by reading and / or parsing the first message) to determine the first continuity information of the first message. Therefore, when the first continuity information indicates that each BGP network device along the first path supports the non-transmittal attribute and the metric data element format for the metric type (e.g., the first continuity bit has a value of "0" (zero)), the receiving BGP network device may cause the first path information to indicate that the first cumulative metric value is a complete cumulative metric value, and when the first continuity information indicates that at least one BGP network device along the first path does not support at least one of the non-transmittal attribute or the metric data element format for the metric type (e.g., the first continuity bit has a value of "1" (one)), the first path information may cause the first cumulative metric value to indicate that the first cumulative metric value is a partial cumulative metric value.

[0035] like Figure 1B As shown in , and by reference number 112, the initiating BGP network device can generate a second message. For example, the second message can be a BGP update message or another type of message that includes availability information associated with the initiating BGP network device. In some implementations, the second message can include second attribute data associated with a non-transitive attribute (e.g., an AIGP attribute, or another type of non-transitive attribute). The second attribute data can include a second metric data element associated with a metric data element format (e.g., an AIGP sub-attribute TLV, or another type of metric data element format). The second metric data element can indicate a metric type (e.g., a metric type associated with a non-transitive attribute described herein). Figure 1AThe second message may include an AIGP attribute including an AIGP sub-attribute TLV including continuity information indicating that the initiator BGP network device supports both the AIGP attribute and the AIGP sub-attribute TLV (e.g., for the metric type indicated by the associated first metric data element), a second metric value (e.g., a quantitative value or quantity of the metric type associated with the initiator BGP network device), and / or second continuity information (e.g., such as a second continuity "bit" set to a value of "0" (zero), or another indicator indicating that the initiator BGP network device supports the non-transitive attributes and metric data element format for the metric type). Thus, the second message may include an AIGP attribute including an AIGP sub-attribute TLV including continuity information indicating that the initiator BGP network device supports both the AIGP attribute and the AIGP sub-attribute TLV (e.g., for the metric type indicated by the AIGP sub-attribute TLV).

[0036] It is worth noting that the second attribute data may include one or more other second metric data elements (e.g., similar to the second metric data element, but indicating different metric types, metric values, and continuity information). For example, the second message may include an AIGP attribute, which includes one or more AIGP sub-attribute TLVs (e.g., each TLV is associated with a different metric type). Although the additional details described herein are only directed to the second metric data element, each BGP network device described may process one or more other second metric data elements in a similar manner.

[0037] As shown by reference numeral 114, the initiating BGP network device may send a second message. The initiating BGP network device may send the second message to a second other BGP network device, such as Figure 1B The initiator BGP network device may send the second message to the second other BGP network device via the connection between the initiator BGP network device and the second other BGP network device. Therefore, the second other BGP network device may receive the second message from the initiator BGP network device (e.g., via the connection between the initiator BGP network device and the second other BGP network device).

[0038] As shown by reference numeral 116, a second other BGP network device (e.g., Figure 1BThe intermediate BGP network device N shown in ( ) can update the second metric data element of the second attribute data of the second message. In some implementations, the second other BGP network device can update the second metric value and / or the second continuity information of the second metric data element. For example, when the second other BGP network device supports non-transfer attributes and metric data element formats, the second other BGP network device can update the second metric value (for example, by adding or "accumulating" the metric value for the metric type associated with the connection between the initiator BGP network device and the second other BGP network device to the second metric value). The second other BGP network device can also update the second continuity information so that the second continuity information indicates that the second other BGP network device and the initiator BGP network device each support non-transfer attributes and metric data element formats (for example, for metric types). When the second continuity information is a second continuity bit, the second other BGP network device can update the second continuity information by resubmitting the value of the continuity bit (for example, resubmitting "0" (zero) as "0" (zero), or resubmitting "1" (one) as "1" (one)).

[0039] As another example, when the second other BGP network device does not support at least one of the non-transitive attribute or the metric data element format, the second other BGP network device may update (e.g., may only update) the second continuity information so that the second continuity information indicates that the second other BGP network device does not support the non-transitive attribute and the metric data element format (e.g., for the metric type). When the second continuity information is a second continuity bit, the other BGP network device may update the second continuity information by changing the value of the second continuity bit (e.g., changing "0" (zero) to "1" (one)).

[0040] As shown by reference number 118, the second other BGP network device (eg, the intermediate BGP network device N) may send a second message. The second other BGP network device may send the second message to the receiving BGP network device, such as Figure 1B As shown in . The second other BGP network device can send the second message to the receiving BGP network device via the connection between the second other BGP network device and the receiving BGP network device. Therefore, the receiving BGP network device can receive the second message from the second other BGP network device (for example, via the connection between the second other BGP network device and the receiving BGP network device).

[0041] In this way, the second message can be forwarded to the receiving BGP network device. Figure 1BThe second message is shown to be received and forwarded by a single second other BGP network device, but the second message may be received and forwarded by one or more additional other BGP network devices before being sent to the recipient BGP network device. Then, the second path (e.g., the service forwarding path) from the recipient BGP network device to the initiator BGP network device may include the second other BGP network device, and when presented, may include one or more additional second other BGP network devices.

[0042] Thus, each of the one or more additional second other BGP network devices may receive, update, and send a second message in a similar manner as described herein with respect to the second other BGP network devices (e.g., associated with reference numbers 114, 116, and 118). In this manner, when a particular second other BGP network device of the second path receives the second message from another particular second other BGP network device of the second path, the second continuity information of the second message may indicate whether each BGP network device along the second path from the other particular second other BGP network device to the initiator BGP network device supports the non-transitive attribute and metric data element format for the metric type (e.g., supports the AIGP attribute and the AIGP sub-attribute TLV). For example, when the second continuity information is a second continuity bit having a value of "0" (zero), each BGP network device along the second path from the other particular second other BGP network device to the initiator BGP network device supports the non-transitive attribute and metric data element format, and therefore resubmits the value of the second continuity bit (e.g., resubmits "0" (zero) to "0" (zero)). As an alternative example, when the second continuity information is a second continuity bit having a value of "1" (one), at least one BGP network device along a second path from another specific second other BGP network device to the initiating BGP network device does not support the non-transitive attribute and metric data element format and therefore changes the value of the second continuity bit (e.g., from "0" (zero) to "1" (one)).

[0043] In addition, when received by the receiving BGP network device, the second continuity information of the second metric data element of the second message can indicate whether each BGP network device along the second path from the second other BGP network device before the receiving BGP network device to the initiating BGP network device supports the non-transmittal attribute and metric data element format for the metric type. For example, when the second continuity information is a second continuity bit with a value of "0" (zero), each BGP network device along the second path from the second other BGP network device (e.g., the BGP network device that sends the second message to the receiving BGP network device) to the initiating BGP network device supports the non-transmittal attribute and metric data element format for the metric type. As an alternative example, when the second continuity information has a second continuity bit with a value of "1" (one), at least one BGP network device along the second path from the second other BGP network device (e.g., the BGP network device that sends the second message to the receiving BGP network device) to the initiating BGP network device does not support the non-transmittal attribute and metric data element format for the metric type. Notably, when the second continuity bit is set to “1” by a BGP network device along the second path, each subsequent BGP network device along the second path resubmits the second continuity bit (e.g., as “1” (one)) to ensure that the second continuity bit indicates that at least one BGP network device along the second path does not support non-transitive attributes and metric data element formats for the metric type.

[0044] As shown by reference number 120, the receiving BGP network device may determine second path information associated with the second path (e.g., from the receiving BGP network device to the initiating BGP network device, via the second other BGP network device, and when present, one or more additional second other BGP network devices). The second path information may indicate a cumulative second metric value (e.g., cumulative cost or cumulative benefit) for a metric type associated with the second path. For example, the receiving BGP network device may process the second message (e.g., by reading and / or parsing the second message) to determine a second metric value for the second message (e.g., which includes the cumulative second metric values ​​of BGP network devices along the second path before the receiving BGP network device), and may add a metric value for a metric type to the second metric value, which is associated with the connection between the receiving BGP network device and the second BGP network device that sent the second message to the receiving BGP network device. In some implementations, the second path information may also indicate whether the second cumulative metric value is a full cumulative metric value (e.g., a full cumulative cost or a full cumulative benefit) or a partial cumulative metric value (e.g., a partial cumulative cost or a partial cumulative benefit). For example, the receiving BGP network device may process the second message (e.g., by reading and / or parsing the second message) to determine second continuity information of the second message. The receiving BGP network device may thus cause the second path information to indicate that the second cumulative metric value is a complete cumulative metric value when the second continuity information indicates that each BGP network device along the second path supports the non-transitive attribute and metric data element format for the metric type (e.g., the second continuity bit has a value of "0" (zero)), and cause the second path information to indicate that the second cumulative metric value is a partial cumulative metric value when the second continuity information indicates that at least one BGP network device along the second path does not support the non-transitive attribute and metric data element format for the metric type (e.g., the second continuity bit has a value of "1" (one)).

[0045] As shown by reference number 122, the receiving BGP network device can determine a specific path (e.g., a service forwarding path) from the receiving BGP network device to the initiating BGP network device (e.g., based on the first path information and / or the second path information). In some implementations, the receiving BGP network device can select one of the first path and the second path as the specific path. For example, when the first path information indicates a first cumulative metric value associated with the first path for a metric type, and the first cumulative metric value is a fully cumulative metric value, and the second path information indicates a second cumulative metric value associated with the second path for a metric type, and the second cumulative metric value is a partially cumulative metric value, the receiving BGP network device can select the first path as the specific path. This may be because each BGP network device along the first path supports a non-transitive attribute and a metric data element format for a metric type, and therefore the first cumulative metric value can be considered as an accumulation of metric values ​​along the entire first path (compared to the second cumulative metric value, which can be considered as an accumulation of metric values ​​only along some paths of the second path).

[0046] As another example, when the first path information indicates a first cumulative metric value associated with the first path for the metric type, and the first cumulative metric value is a complete cumulative metric value, and the second path information indicates a second cumulative metric value associated with the second path for the metric type, and the second cumulative metric value is a complete cumulative metric value, the receiving BGP network device may use a metric ranking technique to select a specific path from the first path and the second path (e.g., because the respective costs or benefits of the entire first path and the entire second path can be compared with respect to the metric type).

[0047] As an additional example, when the first path information indicates a first cumulative metric value associated with the first path for the metric type, and the first cumulative metric value is a partial cumulative metric value, and the second path information indicates a second cumulative metric value associated with the second path for the metric type, and the second cumulative metric value is a partial cumulative metric value, the receiving BGP network device may use a non-ranking technique to select a particular path from the first path and the second path (e.g., because the respective costs or benefits of the entire first path and the entire second path cannot be determined with respect to the metric type, and thus different selection criteria may be used).

[0048] As indicated above, Figure 1A to Figure 1B are provided as examples. Other examples may be related to Figure 1A to Figure 1B Different than described. Figure 1A to Figure 1B The number and arrangement of the devices shown in FIG. 1 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 in FIG. 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 in can be implemented as multiple distributed devices. Additionally or alternatively, Figure 1A to Figure 1B The device collection (e.g., one or more devices) shown in FIG. 1 may perform the operations described by Figure 1A to Figure 1B One or more functions performed by another set of devices shown in .

[0049] Figure 2 2 is a diagram of an example environment 200 in which the systems and / or methods described herein may be implemented. Figure 2 As shown in FIG. 2 , environment 200 may include a set of network devices 210 (shown as network device 210-1 through network device 210-N) and a network 220. The devices of environment 200 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0050] The network device 210 includes one or more devices capable of receiving, processing, storing, routing, and / or providing messages and / or services in the manner described herein. For example, the network device 210 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 or a provider core router), a virtual router, or another type of router. Additionally or alternatively, the network device 210 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, or a data center server), a load balancer, and / or the like. The network device 210 may be a provider edge (PE) network device, an autonomous system boundary router (ASBR) network device, or another type of network device associated with one or more ASs. The network device 210 may be a BGP network device (e.g., such as a Figure 1A to Figure 1B In some implementations, the network device 210 may be a physical device implemented in a housing (e.g., a chassis). In some implementations, the network device 210 may be a virtual device implemented by one or more computer devices in a cloud computing environment or a data center.

[0051] The network 220 includes one or more wired and / or wireless networks. For example, the network 220 may include a packet switching network, 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. The network 220 may be associated with (e.g., may include) one or more ASs.

[0052] supply Figure 2 The number and arrangement of devices and networks shown in the figure are examples. Figure 2 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 in FIG. Figure 2 Two or more of the devices shown may be implemented in a single device, or Figure 2 A single device shown in FIG. 200 may be implemented as multiple distributed devices. Additionally or alternatively, a collection of devices (eg, one or more devices) of environment 200 may perform one or more functions described as being performed by another set of devices of environment 200.

[0053] Figure 3 is a diagram of example components of a device 300 associated with the systems and / or methods described herein. Device 300 may correspond to network device 210. In some implementations, network device 210 may include one or more devices 300 and / or one or more components of device 300 of device 300. Figure 3 As shown in , device 300 may include a bus 310 , a processor 320 , a memory 330 , an input component 340 , an output component 350 , and / or a communication component 360 .

[0054] Bus 310 may include one or more components that enable wired and / or wireless communications between components of device 300. Bus 310 may include Figure 3Two or more components of a computer system may be coupled together, for example, via operational coupling, communication coupling, electronic coupling, and / or electrical coupling. For example, bus 310 may include electrical connections (e.g., wires, traces, and / or leads) and / or wireless buses. Processor 320 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 320 may be implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor 320 may include one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

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

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

[0057] The device 300 may perform one or more operations or processes described herein. For example, a non-transient computer-readable medium (e.g., memory 330) may store an instruction set (e.g., one or more instructions or codes) for execution by a processor 320. The processor 320 may execute the instruction set to perform one or more operations or processes described herein. In some implementations, execution of the instruction set by one or more processors 320 causes one or more processors 320 and / or the device 300 to perform one or more operations or processes described herein. In some implementations, a hardwired circuit device may be used instead of or in combination with an instruction to perform one or more operations or processes described herein. Additionally or alternatively, the processor 320 may be configured to perform one or more operations or processes described herein. Therefore, the implementation described herein is not limited to any particular combination of hardware circuit devices and software.

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

[0059] Figure 4 4 is a diagram of example components of a device 400 associated with the systems and / or methods described herein. Device 400 may correspond to network device 210. In some implementations, network device 210 may include one or more devices 400 and / or one or more components of device 400. Figure 4 As shown in the figure, the device 400 may include one or more input components 410-1 to 410-B (B≥1) (hereinafter collectively referred to as input component 410, and individually referred to as input component 410), a switching component 420, one or more output components 430-1 to 430-C (C≥1) (hereinafter collectively referred to as output component 430, and individually referred to as output component 430) and a controller 440.

[0060] The input component 410 can be one or more connection points for a physical link, and can be one or more entry points for incoming traffic (e.g., packets). The input component 410 can process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 410 can send and / or receive packets. In some implementations, the input component 410 can 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), packet forwarding components, line card controller components, input ports, processors, memories, and / or input queues. In some implementations, the device 400 can include one or more input components 410.

[0061] The switch component 420 can interconnect the input component 410 with the output component 430. In some implementations, the switch component 420 can be implemented via one or more crossbars, via a bus, and / or using a shared memory. The shared memory can act as a temporary buffer to store packets from the input component 410 before the packets are ultimately scheduled for delivery to the output component 430. In some implementations, the switch component 420 can enable the input component 410, the output component 430, and / or the controller 440 to communicate with each other.

[0062] Output component 430 can store packets and can schedule packets for transmission on an output physical link. Output component 430 can support data link layer encapsulation or decapsulation, and / or various high-level protocols. In some implementations, output component 430 can send packets and / or receive packets. In some implementations, output component 430 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 400 may include one or more output components 430. In some implementations, input component 410 and output component 430 may be implemented by the same set of components (e.g., an input / output component may be a combination of input component 410 and output component 430).

[0063] Controller 440 includes a processor in the form of, for example, a 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, controller 440 may include one or more processors that can be programmed to perform a function.

[0064] In some implementations, the controller 440 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 440.

[0065] In some implementations, the controller 440 can communicate with other devices, networks, and / or systems connected to the device 400 to exchange information about network topology. The controller 440 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 410 and / or the output component 430. The input component 410 and / or the output component 430 can use the forwarding table to perform routing lookups for incoming and / or outgoing packets.

[0066] The controller 440 may perform one or more processes described herein. The controller 440 may perform these processes in response to executing software instructions stored by a non-transient computer readable medium. A computer readable medium is defined herein as a non-transient memory device. A memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

[0067] The software instructions may be read into a memory and / or storage component associated with the controller 440 from another computer-readable medium or from another device via a communication interface. When executed, the software instructions stored in the memory and / or storage component associated with the controller 440 may cause the controller 440 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.

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

[0069] Figure 5 is a flow chart of an example process 500 associated with continuity information included in a metric data element of a non-transitive attribute. Figure 5 One or more process blocks of are performed by a BGP network device (e.g., network device 210 configured as a BGP network device). In some implementations, Figure 5One or more process blocks of are performed by another device or a group of devices separate from or including the BGP network device, such as another BGP network device (e.g., another network device 210 configured as another BGP network device). Additionally or alternatively, Figure 5 One or more processing blocks may be performed by one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350, and / or communication component 360; one or more components of device 400, such as input component 410, switching component 420, output component 430, and / or controller 440; and / or one or more components of another device.

[0070] like Figure 5 As shown in , process 500 may include receiving a first message, wherein the first message includes first attribute data associated with a non-transitive attribute, wherein the first attribute data includes a first metric data element, which is associated with a metric data element format to indicate a metric type, a metric value, and continuity information (box 510). For example, a BGP network device may receive a first message from an initiator BGP network device via a first other BGP network device, wherein the first message includes first attribute data associated with a non-transitive attribute, wherein the first attribute data includes a first metric data element, which is associated with a metric data element format and indicates a metric type, a metric value, and continuity information, as described above. In some implementations, the first message includes first attribute data associated with a non-transitive attribute, wherein the first attribute data includes a first metric data element, which is associated with a metric data element format and indicates a metric type, a metric value, and continuity information.

[0071] like Figure 5 As further shown in , process 500 may include processing the first message to determine first path information (block 520). For example, the BGP network device may process the first message to determine the first path information, as described above. The first path information may be associated with a first path from the BGP network device via the first other BGP network device to the initiator BGP network device.

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

[0073] In a first implementation, the non-transitive attribute is an AIGP attribute and the metrics data element format is a TLV.

[0074] In a second implementation, which is separate or combined with the first implementation, the continuity information of the first metric data element indicates whether each BGP network device of the plurality of BGP network devices includes a first other BGP network device and an initiating BGP network device, and the BGP network devices along a first path from the BGP network device to the initiating BGP network device support non-transitive attributes for the metric type and the metric data element format.

[0075] In a third implementation, which is alone or combined with one or more of the first implementation or the second implementation, the first path information indicates a cumulative metric value for a metric type associated with the first path, and whether the cumulative metric value is a full cumulative metric value or a partial cumulative metric value.

[0076] In a fourth implementation, which is alone or in combination with one or more of the first to third implementations, process 500 includes determining a specific path from the BGP network device to the initiator BGP network device based on the first path information.

[0077] In a fifth implementation, which is alone or in combination with one or more of the first to fourth implementations, process 500 includes receiving a second message from an initiating BGP network device via a second other BGP network device, wherein the second message includes second attribute data associated with a non-transitive attribute, wherein the second attribute data includes a second metric data element associated with a metric data element format; and processing the second message to determine second path information associated with a second path from the BGP network device via the second other BGP network device to the initiating BGP network device.

[0078] In a sixth implementation, which is alone or in combination with one or more implementations of the first to fifth implementations, the first path information indicates, for a specific metric type, a first cumulative metric value associated with the first path, and whether the first cumulative metric value is a complete cumulative metric value or a partial cumulative metric value, and the second path information indicates, for a specific metric type, a second cumulative metric value associated with the second path, and whether the second cumulative metric value is a complete cumulative metric value or a partial cumulative metric value.

[0079] In a seventh implementation, which is alone or combined with one or more of the first to sixth implementations, process 500 includes selecting one of the first path and the second path as a specific path from the BGP network device to the initiator BGP network device based on the first path information and the second path information.

[0080] although Figure 5 Example blocks of process 500 are shown, but in some implementations, process 500 includes Figure 5Additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in process 500. Additionally or alternatively, two or more of the blocks of process 500 may be executed in parallel.

[0081] Figure 6 is a flow chart of an example process 600 associated with continuity information included in a metric data element of a non-transitive attribute. Figure 6 One or more processing blocks of are performed by a BGP network device (e.g., a network device 210 configured as an initiator BGP network device). In some implementations, Figure 6 One or more processing blocks of are performed by another device or a group of devices separate from or including the BGP network device, such as another BGP network device (e.g., another network device 210 configured as another BGP network device). Additionally or alternatively, Figure 6 One or more processing blocks may be performed by one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350, and / or communication component 360; one or more components of device 400, such as input component 410, switching component 420, output component 430, and / or controller 440; and / or one or more components of another device.

[0082] like Figure 6 As shown in , process 600 may include generating a first message that includes first attribute data associated with a non-transitive attribute, wherein the first attribute data includes a first metric data element that is associated with a metric data element format and indicates a metric type, a metric value, and continuity information (block 610). For example, a BGP network device may generate a first message that includes first attribute data associated with a non-transitive attribute, wherein the first attribute data includes a first metric data element that is associated with a metric data element format and indicates a metric type, a metric value, and continuity information, as described above. In some implementations, the first attribute data includes a first metric data element that is associated with a metric data element format and indicates a metric type, a metric value, and continuity information.

[0083] like Figure 6 As further shown in , process 600 may include sending a first message (block 620). For example, as described above, the BGP network device may send the first message to a first other BGP network device.

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

[0085] In a first implementation, the non-transitive attribute is an AIGP attribute and the metrics data element format is a TLV.

[0086] In a second implementation, either alone or in combination with the first implementation, the continuity information of the first metric data element indicates that the BGP network device supports non-transitive attributes and metric data element formats for the metric type.

[0087] In a third implementation, which is alone or in combination with one or more of the first and second implementations, sending a first message to a first other BGP network device allows the first other BGP network device to determine first path information associated with a first path from the first other BGP network device to the BGP network device.

[0088] In a fourth implementation, alone or in combination with one or more of the first to third implementations, sending a first message to a first other BGP network device allows the first other BGP network device to update a first metric data element of first attribute data of the first message.

[0089] In a fifth implementation, which is alone or in combination with one or more of the first to fourth implementations, process 600 includes generating a second message including second attribute data associated with a non-transitive attribute, wherein the second attribute data includes a second metric data element associated with a metric data element format, and sending the second message to a second other BGP network device.

[0090] In a sixth implementation, which is alone or combined with one or more of the first to fifth implementations, each of the first metric data element and the second metric data element indicates that the BGP network device supports non-transitive attributes and metric data element formats for the metric type.

[0091] although Figure 6 Example blocks of process 600 are shown, but in some implementations, process 600 includes Figure 6 Additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in process 600. Additionally or alternatively, two or more of the blocks of process 600 may be performed in parallel.

[0092] Figure 7 is a flow chart of an example process 700 associated with continuity information included in a metric data element of a non-transitive attribute. Figure 7 One or more processing blocks of are performed by a BGP network device (e.g., network device 210 configured as a BGP network device). In some implementations, Figure 7One or more processing blocks of are performed by another device or a group of devices separate from or including the BGP network device, such as another BGP network device (e.g., another network device 210 configured as another BGP network device). Additionally or alternatively, Figure 7 One or more processing blocks may be performed by one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350, and / or communication component 360; one or more components of device 400, such as input component 410, switching component 420, output component 430, and / or controller 440; and / or one or more components of another device.

[0093] like Figure 7 , process 700 may include receiving a message, wherein the message includes attribute data associated with a non-transitive attribute, wherein the attribute data includes a metric data element associated with a metric data element format indicating a metric type, a metric value, and continuity information (block 710). For example, a BGP network device may receive a message from an initiator BGP network device, wherein the message includes attribute data associated with a non-transitive attribute, wherein the attribute data includes a metric data element associated with a metric data element format indicating a metric type, a metric value, and continuity information, as described above.

[0094] like Figure 7 As shown in FIG. 7 , process 700 may include updating a metric data element of attribute data of a message (block 720). For example, a BGP network device may update a metric data element of attribute data of a message, as described above.

[0095] like Figure 7 As further shown in , process 700 may include sending the message to another BGP network device (block 730). For example, the BGP network device may send the message to another BGP network device as described above.

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

[0097] In a first implementation, the non-transitive attribute is an AIGP attribute and the metrics data element format is a TLV.

[0098] In a second implementation, which is separate or combined with the first implementation, before updating the metric data element, the continuity information of the metric data element indicates whether each BGP network device along the path from the BGP network device to the initiator BGP network device supports the non-transitive attributes and metric data element format for the metric type.

[0099] In a third implementation, either alone or in combination with one or more of the first and second implementations, process 700 includes updating at least continuity information of the metric data element.

[0100] In a fourth implementation, which is alone or in combination with one or more of the first to third implementations, sending a message to another BGP network device allows the other BGP network device to determine path information associated with a path from the other BGP network device via the BGP network device to the initiator BGP network device.

[0101] although Figure 7 Example blocks of process 700 are shown, but in some implementations, process 700 includes Figure 7 Additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in. Additionally or alternatively, two or more of the blocks of process 700 may be performed in parallel.

[0102] The above 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.

[0103] As used herein, a service or content may include a collection of packets. A packet may refer to a communication structure for communicating 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.

[0104] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. It will be apparent that the systems and / or methods described herein can be implemented in various 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 is not limited by the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code - it will be understood that software and hardware can be used to implement the systems and / or methods based on the description herein.

[0105] Although specific combinations of features are listed in the claims and / or 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 not specifically listed in the claims and / or not 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 in combination with each other claim in the claim set. As used herein, the phrase "at least one of..." in a list of reference 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 multiple identical items.

[0106] 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 stated (either in a single claim or across multiple claims) as performing or being configured to perform multiple operations, the language is intended to broadly cover a variety of processor architectures and environments. For example, unless otherwise expressly stated (e.g., via the use of "a first processor" and "a second processor" or other language that distinguishes the processors in the claims), the language is intended to cover a single processor that performs or is configured to perform all of the operations, a group of processors that collectively perform or are configured to perform all of the 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 the operations. For example, when a claim has the word form "one or more processors to: perform X; perform Y; and perform Z," the claim should be interpreted to mean "one or more processors that perform X; one or more (possibly different) processors that perform Y; and one or more (possibly different) processors that perform Z."

[0107] Any element, behavior or indication used herein should not be interpreted as critical or necessary unless so clearly described. Also as used herein, the articles "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more". In addition, as used herein, the article "the" is intended to include one or more items quoted in relation to the article "the", and can be used interchangeably with "one or more". Further, as used herein, the term "set" is intended to include one or more items (e.g., a combination of related items, unrelated items, or related and unrelated items), and can be used interchangeably with "one or more". If only one item is intended, the phrase "only one" or similar language is used. In addition, as used herein, the term "have", "have", "just have" or similar terms are intended to be open terms. In addition, unless otherwise clearly stated, the phrase "based on" is intended to mean "based at least in part on". Furthermore, as used herein, the term "or" is intended to be inclusive when used in a series and may be used interchangeably with "and / or" unless expressly stated otherwise (e.g., if used in conjunction with "one of" or "only one of").

Claims

1. A method comprising: The Border Gateway Protocol (BGP) network device receives a first message from an initiator BGP network device via a first other BGP network device; wherein the first message includes first attribute data associated with a non-transfer attribute, wherein the first attribute data comprises a first metric data element, the first metric data element being associated with a metric data element format and indicating a metric type, a metric value, and continuity information; as well as The first message is processed by the BGP network device to determine first path information associated with a first path from the BGP network device to the initiator BGP network device via the first other BGP network device.

2. The method of claim 1, wherein the non-transitive attribute is an Accumulated Interior Gateway Protocol (AIGP) attribute and the metric data element format is a Type-Length-Value (TLV).

3. The method according to claim 1, wherein the continuity information of the first metric data element is a continuity bit, which, when set to a first value, indicates that among a plurality of BGP network devices including the first other BGP network device and the initiator BGP network device, each BGP network device along a first path from the BGP network device to the initiator BGP network device supports the non-transitive attribute and the metric data element format for the metric type; or the continuity bit, when set to a second value, indicates that at least one BGP network device along the first path does not support the non-transitive attribute and the metric data element. 4 . The method according to claim 1 , wherein the first path information indicates a cumulative metric value for the metric type associated with the first path, and whether the cumulative metric value is a full cumulative metric value or a partial cumulative metric value.

5. The method according to claim 1, further comprising: A specific path from the BGP network device to the initiator BGP network device is determined based on the first path information.

6. The method according to claim 1, further comprising: receiving a second message from the initiator BGP network device via a second other BGP network device, wherein the second message includes second attribute data associated with the non-transfer attribute, wherein the second attribute data comprises a second metric data element associated with the metric data element format; and The second message is processed to determine second path information associated with a second path from the BGP network device to the initiator BGP network device via the second other BGP network device.

7. The method according to claim 6, wherein: The first path information indicates, for a specific metric type, a first cumulative metric value associated with the first path, and whether the first cumulative metric value is a complete cumulative metric value or a partial cumulative metric value; as well as The second path information indicates, for the specific metric type, a second cumulative metric value associated with the second path, and whether the second cumulative metric value is a complete cumulative metric value or a partial cumulative metric value.

8. The method according to claim 6, further comprising: Based on the first path information and the second path information, one of the first path and the second path is selected as a specific path from the BGP network device to the initiator BGP network device.

9. A Border Gateway Protocol (BGP) network device, comprising: one or more memories; as well as One or more processors to: generating a first message including first attribute data associated with a non-transitive attribute; wherein the first attribute data comprises a first metric data element, the first metric data element being associated with a metric data element format and indicating a metric type, a metric value, and continuity information; and The first message is sent to a first other BGP network device.

10. The BGP network device of claim 9, wherein the non-transitive attribute is an Accumulated Interior Gateway Protocol (AIGP) attribute, and the metric data element format is a Type-Length-Value (TLV).

11. The BGP network device of claim 9, wherein the continuity information of the first metric data element is a continuity bit, the continuity bit indicating that the BGP network device supports the non-transitive attribute and the metric data element format for the metric type.

12. The BGP network device of claim 9, wherein sending the first message to the first other BGP network device allows the first other BGP network device to determine first path information associated with a first path from the first other BGP network device to the BGP network device.

13. The BGP network device of claim 9, wherein sending the first message to the first other BGP network device allows the first other BGP network device to update the first metric data element of the first attribute data of the first message.

14. The BGP network device according to claim 9, wherein the one or more processors are further configured to: generating a second message including second attribute data associated with the non-transitive attribute, in, The second attribute data comprises a second metric data element associated with the metric data element format; and The second message is sent to a second other BGP network device.

15. The BGP network device of claim 14, wherein each of the first metric data element and the second metric data element indicates that the BGP network device supports the non-transitive attribute and the metric data element format for the metric type.

16. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: One or more instructions, which when executed by one or more processors of a Border Gateway Protocol (BGP) network device, cause the BGP network device to: Receive messages from the initiator BGP network device, wherein the message includes attribute data associated with the non-transitive attribute; wherein the attribute data includes a metric data element in a metric data element format indicating a metric type, a metric value, and continuity information; updating the metric data element of the attribute data of the message; as well as The message is sent to another BGP network device.

17. The non-transitory computer readable medium of claim 16, wherein the non-transitive attribute is an Accumulated Interior Gateway Protocol (AIGP) attribute and the metrics data element format is a Type-Length-Value (TLV).

18. The non-transitory computer-readable medium of claim 16, wherein, prior to updating the metric data element, the continuity information of the metric data element indicates whether each BGP network device along a path from the BGP network device to the initiator BGP network device supports the non-transitive attribute for the metric type and the metric data element format.

19. The non-transitory computer-readable medium of claim 16, wherein the one or more instructions that cause the BGP network device to update the metric data element of the attribute data of the message cause the BGP network device to: At least the continuity information of the metric data element is updated.

20. The non-transitory computer-readable medium of claim 16, wherein sending the message to the other BGP network device allows the other BGP network device to determine path information associated with a path from the other BGP network device via the BGP network device to the initiator BGP network device.

Images