Performance measurement, telemetry, and OAM in MPLS networks using entropy labels

Abstract

This paper describes a technique for performing surveillance operations (e.g., telemetry, performance measurement, OAM, etc.) using entropy labels in a Multiprotocol Label Switching (MPLS) label stack without altering the MPLS label stack and / or packet paths (e.g., ECMP paths). This technique may involve a node in the network determining which surveillance operation to perform in relation to traffic to be transmitted along a path through the network. In some examples, the node may receive packets to be transmitted along the path and encapsulate the packets with an MPLS header. The MPLS header may include entropy labels, entropy label indicators, or other labels capable of carrying flags indicating the surveillance operation to be performed. This flag may be carried in the TTL field or traffic category field of the label, allowing the surveillance operation to be triggered without altering the MPLS label stack.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 565,823, filed December 30, 2021, which in turn claims priority to U.S. Provisional Patent Application No. 63 / 227,446, filed July 30, 2021. Additionally, this application claims priority to U.S. Provisional Patent Application No. 63 / 237,656, filed August 27, 2021. The entire contents of each of the above-cited applications are incorporated herein by reference in their entirety and are used for all purposes. Technical Field

[0003] This disclosure generally relates to techniques for performing telemetry, in-band performance measurement, and operation, administration, and maintenance (OAM) without altering the MPLS label stack, using entropy labels in the MPLS header of packets. Background Technology

[0004] To trigger certain operations in a Multiprotocol Label Switching (MPLS) network, the MPLS label stack of packets is typically modified. For example, to measure packet loss in data plane traffic, the ingress node of an MPLS network needs to color the data plane traffic. However, existing techniques for coloring data plane traffic in MPLS networks suffer from the Equal-Cost Multipath (ECMP) triggering problem because the MPLS label stack may change periodically to switch colors, thereby altering the ECMP path of packets. Similarly, to trigger other operations (such as telemetry actions, OAM, etc.), the MPLS label stack may need to be modified, leading to the same ECMP path hashing problem. Attached Figure Description

[0005] The following detailed description is given with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which the reference numeral first appears. The same reference numerals are used in different drawings to denote similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale relative to each other.

[0006] Figure 1 This is a system architecture diagram illustrating example architectures that can perform various aspects of the technologies described in this article.

[0007] Figure 2 An example tag is shown that can be used to carry one or more flags associated with a monitoring operation in an MPLS tag stack.

[0008] Figure 3A and Figure 3BTogether, they illustrate an example process by which nodes send telemetry data based on packets that include flags indicating telemetry operations.

[0009] Figure 4 This illustrates an example process in which probe packets, including one or more flags, are sent within the entropy label of an MPLS label stack.

[0010] Figure 5 An example process is shown where nodes discard time-sensitive network packets based at least in part on a flag included in the entropy label.

[0011] Figure 6 An example MPLS tag stack is shown that can be used to perform various monitoring operations.

[0012] Figure 7 This is a flowchart illustrating an example method associated with carrying an indicator flag within an entropy label in the MPLS label stack.

[0013] Figure 8 This is a computing system diagram illustrating an example configuration of a data center, which can be used to implement various aspects of the techniques disclosed herein.

[0014] Figure 9 This is a computer architecture diagram illustrating an illustrative computer hardware architecture for implementing a computing device that can be used to implement various aspects of the various technologies presented herein. Detailed Implementation

[0015] Overview

[0016] The invention is set forth in the independent claims and in the dependent claims. A feature of one aspect may be applied individually to each aspect or in combination with other aspects.

[0017] This disclosure describes various techniques associated with performing telemetry, in-band performance measurement, and OAM operations using entropy labels of the MPLS label stack without altering the MPLS label stack to change the packet path. As an example, and not a limitation, a method according to the techniques described herein may include: a first node of the network determining to perform a monitoring operation associated with traffic transmitted along a path between the first and second nodes of the network. In some cases, the monitoring operation may include telemetry operations, performance measurement operations, OAM-related operations, etc. In some examples, the first node may receive packets to be transmitted along the path to the second node, and based at least in part on the determination to perform the monitoring operation, the first node may encapsulate the packet with an MPLS header including an entropy label. The entropy label may include a flag associated with the monitoring operation to be performed. The first node may then transmit the packet, including the MPLS header, to the second node, and based at least in part on the entropy label including the flag, the packet may be transmitted along that path rather than a different path.

[0018] Furthermore, the techniques described herein can be implemented as a method and / or executed by a system having a non-transitory computer-readable medium storing computer-executable instructions that perform the techniques described above when executed by one or more processors.

[0019] Example Implementation

[0020] As mentioned above, triggering certain operations in an MPLS network (e.g., telemetry, performance measurement, OAM, etc.) may require altering the MPLS label stack of packets. For example, to measure packet loss in data plane traffic, the ingress node of the MPLS network needs to color the data plane traffic. However, existing techniques for coloring data plane traffic in MPLS networks suffer from ECMP triggering problems because the MPLS label stack may periodically change to switch colors, thereby altering the ECMP path of packets. Furthermore, other operations may be subject to similar ECMP triggering issues.

[0021] This disclosure describes techniques for performing surveillance operations (e.g., telemetry, in-band performance measurement, OAM, etc.) using entropy labels from the MPLS label stack without altering the MPLS label stack and / or changing packet paths. For example, fields of the MPLS entropy label (e.g., Time-to-Live (TTL) field, Traffic Class (TC) field, Entropy Label field, etc.) can be used to carry one or more flags associated with performing surveillance operations (e.g., in-band telemetry, OAM, performance measurement, packet loss, latency measurement, timestamp update, time synchronization, Time-Sensitive Networking (TSN) operations, In-Situ OAM (IOAM) operations, etc.). The techniques described herein for using entropy labels to carry indicator flags are backward compatible and can be deployed in existing networks (e.g., Segmented Routing (SR) networks, EVPN networks, etc.) without altering the ECMP behavior of nodes.

[0022] Various advantages can be achieved by utilizing the techniques described herein. For example, these techniques enable data flows to exhibit the same ECMP behavior. In other words, instead of changing the MPLS label stack and sending packets along different paths, the MPLS label stack remains unchanged and packets are sent along their usual paths. Furthermore, these techniques are backward compatible at intermediate nodes and can be deployed in existing networks without dropping packets with zero or non-zero TTLs, as intermediate nodes can ignore the TTL field of the entropy label. Moreover, these techniques work seamlessly with other use cases (e.g., network fragmentation) without affecting the maximum label stack depth and are applicable to all MPLS networks, including fragmented routing and EVPN. Compared to other solutions that require five additional labels in the MPLS header (e.g., extended indicator label (15), new indicator label, new flow label) along with the entropy label, these techniques also offer the advantage of requiring only a single bit from the existing standard (entropy label) when using the entropy label TTL / TC field for in-band telemetry. That is, the entropy label itself is used as the flow identifier, and no new label needs to be defined.

[0023] As an example and not a limitation, in some examples, the methods according to the various techniques described herein may include: a first node of the network determining to perform monitoring operations associated with client traffic sent along the path between the first and second nodes of the network. In some examples, the network may be an MPLS network, an SR network, an EVPN network, or another type of network. In some examples, the first node may be an ingress provider edge node of the network (e.g., an SR-MPLS policy node), the second node may be an egress provider edge node of the network, and the path between the ingress provider edge node and the egress provider edge node may include one or more additional nodes of the network (e.g., intermediate nodes). In other examples, the first and / or second nodes may be any node of the network capable of adding encapsulation to packets, such as edge nodes, intermediate nodes, etc.

[0024] In some examples, the first node may receive packets to be sent along the path to the second node, and, at least in part, based on the determination to perform a monitoring operation, the first node may encapsulate the packet in an MPLS header including an entropy label. In some examples, the entropy label may include flags indicating the monitoring operation to be performed. For example, and as discussed in further detail below, the monitoring operation may include packet loss measurement, telemetry operation, OAM operation, determining the delay between the first and second nodes, determining whether the TSN lifetime has expired, IOAM operation, etc., or associated with them. Additionally, in some examples, the flag may be included in at least one of the TTL field, traffic category field, entropy label control field, or other fields of the entropy label in the MPLS header (e.g., the MPLS stack).

[0025] In this way, the first node can send packets, including MPLS headers, to the second node along this path. This is based at least in part on the inclusion of this flag in the entropy label of the MPLS header, the MPLS stack remains unchanged, and packets can be sent to the second node along this path, rather than along a different path that client traffic packets would not normally traverse. In some examples, a controller associated with the network can configure one or more nodes of the network (e.g., the first and second nodes) to perform monitoring operations.

[0026] As described above, in some examples, the flag can indicate that the monitoring operation to be performed is a packet loss performance measurement associated with traffic sent along the path between the first and second nodes. Additionally, in some examples, bits included in the entropy label can be flipped to indicate a first coloring associated with packets of traffic, which can be distinguished from a second coloring associated with another packet of traffic. For example, the first node (e.g., the ingress node) can periodically toggle bits in the TTL or traffic category field of the entropy label to color data traffic. In some examples, the position of the bit flag can be provided by the network controller on the first and / or second nodes. Thus, in some examples, TX packets on the first node (e.g., the ingress node) and RX packets on the second node (e.g., the egress node) can be counted using an ACL (Access Control List), which can also include colors in the TTL (or TC) field. In such examples, any intermediate nodes along the path can avoid removing the Entropy Label Indicator (ELI) and Entropy Label (EL) from the MPLS header. That is, it may be important for the egress node to receive the ELI and EL in the MPLS header. In some examples, the controller can use EDT (Event-Driven Telemetry) to collect TX counters from a first node for a frozen (inactive) color, and then trigger MDT (Model-Driven Telemetry) on a second node to collect RX counters for the same color against a traffic engineering SR policy. In some examples, color changes can be used as triggers to aggregate and compute performance metrics and / or generate telemetry on nodes. In some cases, telemetry data may include traffic packet / byte counters and latency and / or change metrics for the last active color. Additionally or alternatively, probe messages such as TWAMP or STAMP can be used to collect traffic counters. In some examples, a flag triggering the telemetry operation can be carried in the entropy tag TTL or TC, ELI TTL or TC, or in a dedicated tag TTL or TC to be defined.

[0027] Using MPLS entropy label TTL or TC fields for packet coloring offers several advantages. For example, compared to using different statistical labels, when the color changes, the color in ELI and / or EL does not affect the ECMP path taken by the traffic flow, and it does not cause traffic to ping back and forth on different ECMP paths. Additionally, using MPLS entropy label TTL or TC fields for packet coloring offers the following advantages: halving the number of labels assigned to the SR policy at the egress node, and halving the expansion of the Forwarding Information Base (FIB) for the number of forwarding entries to be installed in the hardware. Changes in the color flag within the packet are also used to calculate and aggregate various performance metrics for the previous color, such as calculating the minimum or maximum latency or jitter during the phase of receiving traffic of the previous color.

[0028] In some examples, the flag can indicate that the monitoring operation to be performed includes a telemetry operation, and the flag can indicate that the telemetry operation should be performed. For example, each node receiving a packet in the network (e.g., a first node, a second node, etc.) can determine that the packet includes the flag, and in some cases, generate a copy of the packet and send (e.g., punt) the copy of the packet to at least one of the controllers or collectors associated with the network. In some examples, a path (e.g., a flow) can be identified by the entropy value carried in a 20-bit entropy tag field. Additionally, when in-band telemetry is enabled, a first node (e.g., an ingress node) can periodically set the flag in the TTL or TC field of the MPLS entropy tag and sample the data traffic. In some examples, the location of the bit flag can be provided on the nodes of the network (e.g., by the controller). In examples, nodes using this scheme to support in-band telemetry can make a copy of the data packet when the flag is set and trigger telemetry to the collector to send data. In some examples, for this purpose, a copy of the packet can first be sent up the slow path, and nodes can forward the copy of the packet downstream in the fast path. In some examples, in-band telemetry flags can also be used as triggers for calculating performance metrics and / or generating telemetry (e.g., latency metrics, change metrics, traffic packet / byte counters, etc.). In some of these examples, it may be important that no intermediate node removes the ELI and EL from the MPLS header, as the egress node may need to receive the ELI and EL from the MPLS header to allow for the collection of data samples along the path of the traffic flow. In some examples, the first node (e.g., the ingress node, encapsulation node, etc.) can set the telemetry flags at set intervals (e.g., once per million packets, once every 30 seconds, etc.). In some examples, probe packets can carry more than one EL (entropy tag) in the MPLS header tag stack. For example, when inserting a new EL / ELI into the MPLS header tag stack, the intermediate node can copy the TTL and TC fields from the received EL / ELI to the new EL / ELI. In some cases, if there is more than one set of EL / ELIs in the tag stack, the intermediate node can scan the entire tag stack to find the monitoring flag. In some cases, intermediate nodes cannot remove ELI / EL packets carrying the flag that enables egress nodes to receive them to provide edge-to-edge monitoring. In some examples, ingress nodes can add ELI / ELI tags so that they are not removed from the MPLS header along the path.

[0029] Using the MPLS entropy label's TTL or TC field to trigger in-band telemetry offers several advantages. For example, since the entropy label itself is used as the flow identifier and no new label needs to be defined, this technique may only require a single bit in existing standards (e.g., unlike adding multiple additional labels). Additionally, because the same MPLS stack is used for in-band telemetry, the node's ECMP behavior is not altered, and packets traverse their usual path. In some examples, the new flow identifier can be calculated from the received packet header and sent along with the in-band telemetry, or the entire packet header can be sent to provide context to the controller. This is also why a separate flow identifier is not carried in the packet for telemetry.

[0030] In some examples, the flag can indicate that the monitoring operation to be performed is an Operations, Administration, and Maintenance (OAM) operation. For example, when a second node receives a packet from a first node, the second node can determine that the packet includes OAM-related flags and forward the packet to the control plane node associated with the network. The control plane node can then perform an OAM operation. In some examples, OAM-related flags included in the entropy label can allow the second node to forward packets to the control plane node or a slow path (e.g., outside of a fast forwarding path) using an RX timestamp and an indication of the second node's input interface. In some examples, the controller can provide the location of the bit flags on the node. In these examples, the control plane node or slow path node can process the forwarded packet, perform one or more OAM operations, and inject the packet back (e.g., to a second node, a third node, a fast path, etc.) for downstream forwarding. For example, the SR-MPLS header can contain a label stack for the entire path, so packets can be re-injected to reach their intended destination. In some examples, the collected OAM information can be used for latency and / or packet loss use cases, including hop-by-hop or edge-to-edge use cases. In some examples, the grouping may optionally carry an IOAM data field.

[0031] In various examples, this flag can indicate that the monitoring operation to be performed is to determine the latency associated with sending packets along a path from the first node to the second node (e.g., hop-by-hop, end-to-end, etc.). For example, the flag can instruct the second node to insert / update a timestamp (e.g., an RX timestamp) at a specific location within the packet. In some examples, the timestamp location (e.g., 32-bit, 64-bit, etc.) can also be carried in the TS-LOC, TTL, or TC fields of the entropy label, or in a new field in a separate label following the entropy label. In some cases, additional flags and / or fields in the entropy label can identify the timestamp format, such as PTP, NTP, 32-bit, 64-bit, etc. In the examples, a second node (e.g., an edge node) that pops the entropy label and recognizes the timestamp flag can update the timestamp at a location specified in the TS-LOC or at a user-configured location in the hardware fast forwarding path (without sending the packet up to the slow path or control plane) and forward the packet to the next hop. This enables higher scalability for PM packets / sessions and faster fault detection intervals. In the example, the collected timestamps can then be used to measure edge-to-edge latency of packets in the network. In addition to the timestamp at a specified location in the received packets, another flag can be defined to insert / update interface or node IP addresses.

[0032] In the example, the flag could indicate that the monitoring operation to be performed includes determining whether a Time-Sensitive Network (TSN) lifetime has expired, and the TSN lifetime can be included in the packet. For example, a flag included in the packet (e.g., in the TTL or TC of an SPL, ELI, entropy label, etc.) could indicate that the label stack has a timestamp indicating the lifetime (i.e., the deadline) of the data packet in the TSN. In some cases, the flag in the entropy label or timestamp TTL can indicate a 32-bit, 64-bit, or user-defined timestamp format. In the example, the first node (e.g., the ingress node, encapsulation node, etc.) can insert a timestamp in the packet based on the maximum amount of latency that the packet (and the service it belongs to) can experience in the network before the packet (and the service it belongs to) is deemed unavailable. In some examples, the timestamp itself can be carried in the label stack or in the metadata (before the payload) after the label stack (BOS). In the example, each node identifying the TSN flag can use its local clock to check the timestamp in the packet, and if the time in the packet has expired, it can discard the packet; otherwise, if the time has not expired, it can forward the packet to the next hop. Additionally or alternatively, when the lifetime / deadline expires, the node that detects the expiration can send telemetry data associated with that packet to the network controller or collector. In this way, the controller and / or the first node can take action to switch traffic to another path in the network that satisfies the required TSN service level protocol upon detecting a failure.

[0033] In some examples, this flag can indicate that the monitoring operation to be performed includes IOAM operations. For instance, a second node can receive a packet, determine that the packet includes this flag, and record OAM-related data (e.g., 32-bit or 64-bit timestamps, interface IP addresses, node IP addresses, interface packet counters, etc.) in the packet's MPLS header or elsewhere in the packet. In some examples, this flag can indicate preferences and requirements for hop-by-hop IOAM processing or edge-to-edge IOAM processing.

[0034] In some examples, multiple different flags can be defined for different monitoring operations. For example, one or more flags can be defined specifically for packet loss performance measurement use cases, one or more flags can be defined specifically for OAM operations, one or more flags can be defined specifically for telemetry operations, and so on. As an example, and not a limitation, flags that can be defined for the specific examples described herein may include: a “C” flag (which may be one or more bits) indicating the color of the flow indicator; an “E” flag indicating the presence of an edge-to-edge IOAM data field after the bottom of the label stack; an “H” flag indicating the presence of a hop-by-hop IOAM data field after the bottom of the label stack or requiring hop-by-hop processing; an “L” flag indicating the presence of a TSN lifetime timestamp in the label stack; a “T” flag indicating that the second node should timestamp the packet at the specified position in the EL field and forward the packet in the fast forwarding path (instead of uploading it to the slow path); an “I” flag indicating the execution of an in-band telemetry action (e.g., uploading a copy of the packet and / or forwarding a copy); and an “O” flag indicating the OAM operation to be performed (e.g., uploading the packet using the received timestamp and input interface and re-injecting it into the fast forwarding path for fast downstream forwarding), etc. Additionally, a flag “R” can be defined to copy received packets to all next-hop output ECMP paths on the node, thereby enabling the monitoring and measurement of all such ECMP paths. In some examples, the flag can be carried in the TTL field or TC field of the entropy label (EL), structural entropy label (SEL), entropy label indicator (ELI), or other labels in the MPLS label stack.

[0035] Certain implementations and embodiments of this disclosure will now be described more fully below with reference to the accompanying drawings, in which aspects are illustrated. However, these aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. As stated herein, this disclosure covers variations of the embodiments. Similar reference numerals always refer to similar elements.

[0036] Figure 1This is a system architecture diagram illustrating an example architecture 100 capable of performing various aspects of the technologies described herein. Network 102 may represent an MPLS network, a segmented routing network, an EVPN network, etc. In the example, network 102 and the devices associated with network 102 may reside within one or more data centers 104. The one or more data centers 104 may be physical facilities or buildings located across geographical regions, designated as storage and computing resources. The one or more data centers 104 may include various networking devices, as well as redundant or backup components and infrastructure for power, data communication connectivity, environmental control, IoT devices, services, and various security devices. In some examples, the one or more data centers 104 may include one or more virtual data centers, which are pools or collections of cloud infrastructure resources specifically designed for enterprise needs and / or cloud-based service provider needs. Typically, the one or more (physical and / or virtual) data centers 104 may provide basic resources such as processors (CPU), memory (RAM), storage devices (disks), networking (bandwidth), security, etc. However, in some examples, the devices of network 102 may not reside in the explicitly defined one or more data centers 104, but may be located in other locations or buildings.

[0037] Network 102 may include one or more network nodes, such as nodes 106(1), 106(2), and 106(3) (collectively referred to as “node 106”), which can route packets, such as packet 108, through network 102. In some examples, node 106 may be a router, switch, server, or other physical and / or virtual computing device. In some examples, node 106 may be configured to act as an edge node, such as an ingress provider edge node or an egress provider edge node. Additionally, some of nodes 106 may be configured to act as intermediate nodes for routing traffic between edge nodes of the network.

[0038] In some examples, when node 106(1) receives packet 108, node 106(1) can be configured to encapsulate the packet with an MPLS header 110 that includes an MPLS label stack. The label stack of the MPLS header 110 may include one or more transport labels 112, one or more accounting labels 114, an entropy label indicator (ELI) 116, an entropy label (EL) 118, and a payload 120. Additionally, each label in the label stack of the MPLS header 110 may include a corresponding Traffic Category (TC) field 122 and a corresponding Time to Live (TTL) field 124. However, as described herein, the TC field 122 and / or the TTL field 124 of the entropy label 118 may be used to carry one or more flags 126 indicating monitoring operations to be performed on packet 108 and / or the packet path that packet 108 is traversing network 102. Alternatively or additionally, one or more flags 126 may be carried in the TC field 122 and / or TTL field 124 of the entropy label indicator 116.

[0039] In some examples, when node 106(2) receives packet 108, node 106(2) can be configured such that it does not remove the entropy label indicator 116 and / or entropy label 118 from the label stack of the MPLS header 110 of packet 108. This allows downstream nodes (e.g., node 106(3)) to determine whether to perform a monitoring operation upon receiving packet 108. In some examples, nodes 106(2) and 106(3) can each perform one or more monitoring operations upon receiving packet 108, depending on which flag(s) 126 can be included in packet 108. For example, one or more flags 126 that may be included in the TC field 122 and / or TTL field 124 of the entropy tag 118 or entropy tag indicator 116 may include, for example, a flag indicating the color of the flow indicator (which may be one or more bits), a flag indicating that the edge-to-edge IOAM data field exists after the bottom of the tag stack, a flag indicating that the hop-by-hop IOAM data field exists after the bottom of the tag stack, a flag indicating that the TSN lifetime timestamp exists in the tag stack, a flag indicating that the second node will timestamp the packet at a specified position in the EL field and forward the packet, a flag indicating the execution of an in-band telemetry action (e.g., punt a copy of the packet and / or forward a copy), a flag indicating the OAM operation to be performed (e.g., punt a packet using the receive timestamp and the input interface), etc.

[0040] By including one or more flags 126 in the TC field 122 and / or TTL field 124 of the entropy label 118 or entropy label indicator 116 in the label stack of the MPLS header 110 of packet 108, no ECMP behavior of node 106 can be changed when a monitoring operation is to be performed. That is, instead of including a new label in the label stack to indicate the monitoring operation to be performed (which would change the packet path of packet 108), the TC field 122 and / or TTL field 124 can be used to carry the information.

[0041] In some examples, network 102 may include controller 128 and collector 130. In some examples, controller 128 may configure node 106 to perform monitoring operations. For example, controller 128 may send instructions to one or more nodes 106 to perform a monitoring operation for a data flow (e.g., a packet path) on network 102. In some examples, collector 130 may collect information associated with the monitoring operation from node 106, such as telemetry data, OAM data, performance data, etc. In some examples, collector 130 may aggregate and / or forward the collected information to controller 128.

[0042] Figure 2 Example tags 200 and 202 of the MPLS tag stack are shown. Example tags 200 and 202 can be used to carry one or more flags 126 associated with monitoring operations. Example tag 200 includes an entropy tag 118 (bits 0 to 19 of bit 204), a TC field 122 (bits 20 to 22), an S (end of tag stack) field 206 (bit 23), and a TTL field 124 (bits 24 to 31). Figure 2 As shown, one or more flags 126 can be carried in the TC field 122 or the TTL field 124.

[0043] Example label 202 includes a network slice identifier field 208 (bits 0 to 7), a structure entropy label field 210 (bits 8 to 19), a TC field (bits 20 to 22), an S (stack end) field 206 (bit 23), and a TTL field 124 (bits 24 to 31). In the example, one or more flags 126 may be carried in the TC field 122 and / or the TTL field 124 of label 202.

[0044] Figure 3A and Figure 3BTogether, an example procedure 300 is illustrated whereby a node transmits telemetry data based on packets including flags indicating telemetry operation. At "1", controller 128 may perform operation 302, which may include configuring one or more nodes 106 to perform in-band telemetry for a traffic flow. For example, controller 128 may send an indication to node 106 of an entropy value that identifies the path (e.g., the flow) for which telemetry data 304 is to be collected. In some examples, controller 128 may provide the location of bit flags to node 106 (e.g., the location where bit flags within the MPLS header will be positioned, such as the TTL field of the entropy label, the TC field of the entropy label, and the bit positions of flags in these fields, etc.).

[0045] At point “2”, node 106(1) receives packet 108 and sends telemetry data 304 to collector 130. In some examples, node 106(1) may encapsulate packet 108 with an MPLS header based on the configuration of controller 128 and include a flag in the entropy label of the MPLS label stack. This flag may indicate that the telemetry operation is to be performed by one or more downstream nodes 106. In some examples, node 106(1) may generate a copy of packet 108, and telemetry data 304 may include a copy of packet 108. In some examples, for this purpose, a copy of packet 108 may first be sent up the slow path, and node 106(1) may forward the copy of packet 108 downstream in the fast path. In some examples, node 106(1) may set the telemetry flag at a set interval (e.g., once every million packets, once every 30 seconds, etc.).

[0046] At point “3”, node 106(2) receives packet 108, determines that packet 108 includes a flag in the entropy label of the label stack in the MPLS header of packet 108, and sends telemetry data 304 to collector 130. In some examples, node 106(2) may generate a copy of packet 108, and telemetry data 304 may include a copy of packet 108. In some examples, in order to be sent to collector 130, a copy of packet 108 may first be sent up the slow path, and node 106(2) may forward the copy of packet 108 downstream in the fast path. In some examples, it may be important that node 106(2) does not remove ELI and EL from the MPLS header, because node 106(3) may need to receive ELI and EL in the MPLS header to allow the collection of data samples along the path of the data flow.

[0047] At point “4”, node 106(3) receives packet 108, determines that packet 108 includes a flag in the entropy label of the label stack of the MPLS header of packet 108, and sends telemetry data 304 to collector 130. Node 106(3) can then forward packet 108 downstream toward its destination. In some examples, node 106(3) can create a copy of packet 108, and telemetry data 304 may include the copy of packet 108. In some examples, in order to be sent to collector 130, the copy of packet 108 may first be sent up the slow path, and node 106(3) can forward the copy of packet 108 downstream in the fast path. Additionally, in some examples, node 106(3) (e.g., an egress decapsulation node) can remove the MPLS encapsulation before sending packet 108 to its destination.

[0048] Figure 4 Example procedure 400 is illustrated, in which probe packet 402 is sent, and probe packet 402 includes one or more flags in the entropy label 118 of MPLS label stack 410. In some examples, probe packet 402 may include PM probe packet.

[0049] At “1”, node 106(1) may send probe packet 402 to node 106(2). Probe packet 402 may include MPLS label stack 410, which includes one or more transport labels 112, ELI 116, EL 118 with one or more flags 126, IPv4 / UDP label 406, and probe payload 408. In some examples, EL 118 with one or more flags 126 may indicate that a probe message is being sent and / or node 106(3) wants to insert an RX timestamp into probe payload 408 upon reception. In some examples, probe payload 408 may include a TX timestamp indicating the time when node 106(1) sent probe packet 402. IPv4 / UDP label 406 may indicate that node 106(3) is the source and node 106(1) is the destination of return packet 404.

[0050] At “2”, node 106(2) can receive probe packet 402 and forward the probe packet to node 106(3). In some examples, node 106(2) can be configured to avoid removing ELI 116 and EL 126 with one or more flags 118 from the MPLS label stack 410 of probe packet 402.

[0051] At “3”, node 106(3) can receive probe packet 402. Based on EL 118 having one or more flags 126 indicating that node 106(3) should respond with an RX timestamp, node 106(3) can generate a return packet 404 and send it to node 106(2). In some examples, IPv4 / UDP label 406 can indicate that node 106(3) is the source and node 106(1) is the destination, and probe payload 408 can include the TX timestamp when node 106(1) sends probe packet 402 and the RX timestamp when node 106(3) receives probe packet 402.

[0052] At “4”, node 106(2) can receive return packet 404 and forward return packet 404 to node 106(1). Once node 106(1) receives the return packet, node 106(1) can calculate the delay associated with sending probe packet 402 to node 106(3) by calculating the difference between the RX timestamp and the TX timestamp.

[0053] Figure 5 An example process 500 is shown in which node 106(2) discards time-sensitive network packet 108 at least in part based on a flag included in the entropy label. For example, node 106(2) may determine that the lifetime of packet 108 has expired and discard packet 108.

[0054] At "1", controller 128 can perform action 502, which includes setting a lifetime for one or more packets. For example, controller 128 can set a lifetime for a packet associated with a data stream, a client, or a traffic category (e.g., video, audio, web traffic, etc.). In some examples, controller 128 can send a packet lifetime indication to node 106(1) (e.g., an ingress or encapsulation node).

[0055] At “2”, node 106(1) can receive packet 108, encapsulate packet 108 with an MPLS header including MPLS label stack 410, and send packet 108 toward its destination by forwarding packet 108 to node 106(2). In some examples, the MPLS label stack 410 of packet 108 may include one or more transport labels 112, entropy label indicator (ELI) 116, entropy label (EL) 118 including one or more flags, one or more lifetime labels 504 (e.g., deadline timestamp), and payload 120.

[0056] At point “3”, node 106(2) can receive packet 108 and determine that the packet includes one or more flags in entropy label 118. Node 106(2) can determine that one or more entropy label 118 flags include the TSN flag, and then determine whether the lifetime of packet 108 has expired. In this case, node 106(2) determines that the lifetime has expired and performs operation 506, which includes discarding packet 108 instead of forwarding packet 108 to node 106(3). Alternatively, in some examples, node 106(2) can send telemetry data 304 to collector 130 based at least in part on discarding packet 108. Collector 130 can analyze the telemetry data and forward the result 508 to controller 128. In some examples, result 508 can be used by controller 128 to determine an alternative path for sending packet 108 over the network to meet the service level agreement.

[0057] Figure 6 Example MPLS tag stacks 600, 602, 604, and 606 are shown that can be used to perform various monitoring operations. In some examples, tag stack 600 can be used to perform TSN-related operations, tag stack 602 can be used to perform IOAM operations, and tag stacks 604 and 606 can be used to perform latency measurements (e.g., using probe messages).

[0058] The tag stack 600 may include one or more transport tags 112, one or more statistical tags 114, an entropy tag indicator 116, a timestamp location (TS-LOC) field 608, a structural entropy tag 118, one or more lifetimes 504 (e.g., the last deadline timestamp of a TSN), and a payload 120. Additionally, each tag in the tag stack 600 may include a corresponding traffic category field 122 and a lifetime field 124. In some examples, the traffic category field 122 and / or the lifetime field 124 corresponding to the structural entropy tag 118 and lifetime 504 may be used to carry other data. For example, the traffic category field 122 and / or the lifetime field 124 corresponding to the structural entropy tag 118 may be used to carry one or more flags 126. In the tag stack 600, one or more flags 126 may indicate that the packet includes a TSN lifetime 504. Furthermore, the traffic category field 122 and / or the lifetime field 124 corresponding to the lifetime 504 may include data indicating a timestamp format 610 within the lifetime 504. In some examples, the timestamp location field 608 can indicate the position of lifetime 504 in the tag stack 600 (e.g., before or after payload 120).

[0059] The label stack 602 used to perform IOAM operations may include one or more transport labels 112, one or more statistical labels 114, entropy label indicator 116, structural entropy label 118, VPN label 612, one or more IOAM data fields 614, and payload 120. Additionally, each label in the label stack 602 may include a corresponding traffic category field 122 and a time-to-live field 124. In some examples, the traffic category field 122 and / or the time-to-live field 124 corresponding to the structural entropy label 118 may be used to carry one or more flags 126. In the label stack 602, one or more flags 126 may indicate the presence of IOAM data and (one or more) IOAM data fields 614 in the packet. In some examples, a first flag 126 that can be used may indicate hop-by-hop IOAM processing, and a second flag 126 that can be used may indicate edge-to-edge IOAM processing.

[0060] The label stacks 604 and 606 used to perform latency measurements may include one or more transport labels 112, one or more statistical labels 114, an entropy label indicator 116, a timestamp location (TS-LOC) field 608, a structural entropy label 118, a network slice identifier (SLID) field 208, a payload 120, and one or more timestamp fields 616. Additionally, each label in the label stack 600 may include a corresponding traffic category field 122 and a time-to-live (TTL) field 124. In some examples, the traffic category field 122 and / or the TTL field 124 corresponding to the structural entropy label 118 may be used to carry one or more flags 126. In the label stacks 604 and 606, one or more flags 126 may instruct downstream nodes to insert their RX timestamps into one or more timestamp fields 616. In some examples, the timestamp location field 608 may be located in the same label stack layer as the structural entropy label 118, while in other examples, the timestamp location field 608 may be located in a layer below the structural entropy label 118. The timestamp position field 608 can indicate the position of one or more timestamp fields 616 and / or timestamp formats to be inserted into the tag stack 604 and 606 by downstream nodes.

[0061] Figure 7 This is a flowchart illustrating an example method 700 associated with carrying an indicator flag within an entropy label in the MPLS label stack. (References: This document references...) Figure 7 The described logical operations can be implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within a computing system.

[0062] The implementation of the various components described herein is a matter of choice, depending on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to differently as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented in software, firmware, special-purpose digital logic, and any combination of the foregoing. It should also be understood that more than... Figure 7 The operations shown and described herein may be more or fewer. These operations may also be performed in parallel or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically identified. While the techniques described in this disclosure refer to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or any configuration of components.

[0063] Method 700 begins at operation 702, which includes determining, by a first node of the network, to perform a monitoring operation associated with traffic sent along the path between the first and second nodes of the network. For example, node 106(1) may determine to perform a monitoring operation on traffic sent to either node 106(2) or node 106(3). In some examples, the network may be an MPLS network, an SR network, an EVPN network, or another type of network. In some examples, the first node may be an ingress provider edge node of the network (e.g., an SR-MPLS traffic engineering policy node or an MPLS encapsulation node), the second node may be an egress provider edge node of the network (e.g., an MPLS decapsulation node), and the path between the ingress provider edge node and the egress provider edge node may include one or more additional nodes of the network (e.g., intermediate or midpoint nodes). In other examples, the first node and / or the second node may be any node of the network capable of adding or removing encapsulations on packets, such as an edge node, intermediate node, etc.

[0064] At operation 704, method 700 includes receiving a packet at the first node to be sent along the path to the second node. For example, node 106(1) may receive packet 108 to be sent to either node 106(2) or node 106(3).

[0065] At operation 706, method 700 includes encapsulating a packet by the first node with a Multiprotocol Label Switching (MPLS) header including an entropy label that includes a flag indicating a monitoring operation to be performed. For example, node 106(1) may encapsulate packet 108 at least in part based on the determination to perform a monitoring operation. In some examples, the monitoring operation may include packet loss measurement, telemetry operation, OAM operation, determining the delay between the first and second nodes, determining whether the TSN lifetime has expired, IOAM operation, etc., or associated with them. Additionally, in some examples, the flag may be included in at least one of the entropy label or entropy label indicator in the MPLS header (e.g., the MPLS stack), or some other label's TTL field, traffic category field, entropy label control field, or other fields.

[0066] At operation 708, method 700 includes sending a packet, including an MPLS header, from the first node to the second node along the path. For example, node 106(1) may send packet 108 to nodes 106(2) and / or 106(3). Based at least in part on including the flag in the entropy label of the MPLS header, the MPLS stack is not altered, and the packet can be sent to the second node along this path, rather than along another path that the packet would not normally traverse. In some examples, a controller associated with the network may configure one or more nodes of the network (e.g., the first and second nodes) to perform monitoring operations.

[0067] Figure 8 This is a computing system diagram illustrating an example configuration of a data center 800 that can be used to implement various aspects of the techniques disclosed herein. Figure 8 The example data center 800 shown includes several server computers 802A to 802F (which may be referred to herein as "one server computer 802" in the singular or "a plurality of server computers 802") for providing computing resources. In some examples, the resources and / or server computers 802 may include or correspond to any type of networking device or node described herein. Although described as a server, server computer 802 may include any type of networking device, such as a server, switch, router, hub, bridge, gateway, modem, repeater, access point, etc.

[0068] Server computer 802 may be a standard tower, rack, or blade server computer appropriately configured to provide computing resources. In some examples, server computer 802 may provide computing resources 804, including data processing resources such as VM instances or hardware computing systems, database clusters, compute clusters, storage clusters, data storage resources, database resources, networking resources, security, packet inspection, etc. Some servers 802 may also be configured to execute resource manager 806, which is capable of instantiating and / or managing computing resources. For example, in the case of VM instances, resource manager 806 may be a hypervisor or another type of program configured to run multiple VM instances on a single server computer 802. Server computer 802 in data center 800 may also be configured to provide networking services and other types of services.

[0069] exist Figure 8 In the example data center 800 shown, server computers 802A to 802F are also interconnected using a suitable local area network (LAN) 808. It should be understood that the configuration and network topology described herein have been greatly simplified, and more computing systems, software components, networks, and networking devices can be used to interconnect the various computing systems disclosed herein and provide the aforementioned functionality. Suitable load balancing devices or other types of network infrastructure components can also be used to balance the load between data centers 800, between each server computer 802A to 802F in each data center 800, and potentially among the computing resources in each server computer 802. It should be understood that references... Figure 8 The configuration of the data center 800 described is merely illustrative and other implementations may be used.

[0070] In some examples, server computers 802 may each execute one or more application containers and / or virtual machines to perform the techniques described herein. In some instances, data center 800 may provide computing resources, such as application containers, VM instances, and storage, on a permanent or on-demand basis. Computing resources provided by a cloud computing network can be used to implement the various services and technologies described above, as well as other types of functions. Computing resources 804 provided by a cloud computing network may include various types of computing resources, such as data processing resources (e.g., application containers and VM instances), data storage resources, networking resources, data communication resources, network services, etc.

[0071] Each type of computing resource 804 provided by a cloud computing network can be general-purpose or available in several specific configurations. For example, data processing resources can be used as physical computers or VM instances in a variety of different configurations. VM instances can be configured to run applications, including web servers, application servers, media servers, database servers, some or all of the aforementioned network services, and / or other types of programs. Data storage resources can include file storage devices, block storage devices, etc. Cloud computing networks can also be configured to provide other types of computing resources 804 not specifically mentioned herein.

[0072] In one embodiment, computing resources 804 provided by a cloud computing network can be enabled by one or more data centers 800 (which may be referred to herein as "one data center 800" in the singular or "multiple data centers 800" in the plural). A data center 800 is a facility for housing and operating computer systems and related components. A data center 800 typically includes redundant and backup power, communication, cooling, and security systems. Data centers 800 may also be located in geographically distinct locations. The following will combine... Figure 9 An illustrative embodiment of a data center 800 that can be used to implement the technology disclosed herein is described.

[0073] Figure 9 This is a computer architecture diagram illustrating an illustrative computer hardware architecture for implementing a computing device that can be used to implement various aspects of the various technologies presented herein. Figure 9 The computer architecture shown illustrates conventional server computers, network nodes, routers, workstations, desktop computers, laptops, tablets, networked appliances, e-readers, smartphones, or other computing devices, and can be used to execute any of the software components presented herein.

[0074] Computer 900 includes a baseboard 902 (or “motherboard”), which is a printed circuit board to which many components or devices can be connected via a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (CPUs) 904 operate in conjunction with a chipset 906. The CPU 904 may be a standard programmable processor that performs the arithmetic and logic operations required for the operation of computer 900.

[0075] The CPU 904 performs operations by transitioning from one discrete physical state to the next, where state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include electronic circuitry, such as flip-flops, that maintains one of two binary states, and electronic circuitry, such as logic gates, that provides the output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adders / subtractors, arithmetic logic units, floating-point units, and so on.

[0076] Chipset 906 provides an interface between CPU 904 and the remaining components and devices on substrate 902. Chipset 906 may provide an interface with RAM 908, which is used as main memory in computer 900. Chipset 906 may further provide an interface with computer-readable storage media, such as read-only memory (ROM) 910 or non-volatile RAM (NVRAM), for storing basic routines that facilitate booting computer 900 and transferring information between various components and devices. ROM 910 or NVRAM may also store other software components required for the operation of computer 900 according to the configuration described herein.

[0077] Computer 900 can operate in a networked environment, using logical connections to remote computing devices and computer systems via a network (e.g., network 102). Chipset 906 may include functionality for providing network connectivity via NIC 912 (e.g., a Gigabit Ethernet adapter). NIC 912 enables computer 900 to connect to other computing devices via networks 924 and / or 102. It should be understood that multiple NICs 912 may be present in computer 900 to connect the computer to other types of networks and remote computer systems. In some examples, NIC 912 may be configured to perform at least some of the techniques described herein.

[0078] Computer 900 can be connected to storage device 918, which provides non-volatile storage for the computer. Storage device 918 can store operating system 920, programs 922, and data, which have been described in more detail herein. Storage device 918 can be connected to computer 900 via storage controller 914, which is connected to chipset 906. Storage device 918 may include one or more physical storage units. Storage controller 914 can be connected to physical storage units via a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0079] Computer 900 can store data on storage device 918 by changing the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific changes in physical state can depend on various factors. Examples of such factors include, but are not limited to, the technology used to implement the physical storage units, whether storage device 918 is characterized as primary or secondary storage, etc.

[0080] For example, computer 900 can store information in storage device 918 by issuing instructions through storage controller 914 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this specification; the foregoing examples are provided merely for convenience. Computer 900 can further read information from storage device 918 by detecting the physical state or characteristics of one or more specific locations within the physical storage unit.

[0081] In addition to the aforementioned high-capacity storage device 918, computer 900 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that computer-readable storage media are any available medium that provides non-transitory storage of data and can be accessed by computer 900. In some examples, operations performed by architecture 100 and / or any components included therein may be supported by one or more devices similar to computer 900. In other words, some or all of the operations performed by architecture 100 and / or any components included therein may be performed by one or more computer devices 900 operating in a scalable arrangement.

[0082] By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory or other solid-state storage technologies, compact disc ROM (CD-ROM), digital versatile disc (DVD), high-definition DVD (HD-DVD), Blu-ray or other optical storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0083] As briefly mentioned above, storage device 918 can store operating system 920 used to control the operation of computer 900. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system includes a MICROSOFT operating system from Redmond, Washington. The server operating system. According to another embodiment, the operating system may include a UNIX operating system or a variant thereof. It should be understood that other operating systems may also be used. Storage device 918 may store other systems, applications, and data used by computer 900.

[0084] In one embodiment, storage device 918 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 900, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 900 by specifying how CPU 904 transitions between states. According to one embodiment, computer 900 has access to a computer-readable storage medium storing computer-executable instructions that, when executed by computer 900, perform the above-described... Figures 1 to 8 The computer 900 may also include a computer-readable storage medium storing instructions for performing any other computer-implemented operations described herein.

[0085] Computer 900 may also include one or more input / output controllers 916 for receiving and processing input from various input devices, such as a keyboard, mouse, touchpad, touchscreen, stylus, or other types of input devices. Similarly, input / output controllers 916 may provide output to a display, such as a computer monitor, flat panel display, digital projector, printer, or other types of output devices. It will be understood that computer 900 may not include... Figure 9 All components shown may include Figure 9 Other components not explicitly shown, or those that can be utilized with Figure 9 The architecture shown is completely different.

[0086] Computer 900 may include one or more hardware processors (processors) configured to execute one or more stored instructions. The processors may include one or more cores. Furthermore, computer 900 may include one or more network interfaces configured to provide communication between computer 900 and other devices. The network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), etc. For example, the network interface may include devices compatible with Ethernet, Wi-Fi™, etc.

[0087] Program 922 may include any type of program or process to perform the policy-based fault handling techniques described in this disclosure, which utilize the sensitivity and criticality of received data for processing across different edge services. For example, program 922 may be an eBPF program for detecting errors associated with edge services, FaaS (Function as a Service), and other cloud-based applications hosted in the cloud, which may be invoked to perform edge service processing.

[0088] In summary, techniques are described for performing surveillance operations (e.g., telemetry, performance measurement, OAM, etc.) using entropy labels in a Multiprotocol Label Switching (MPLS) label stack without altering the MPLS label stack and / or packet paths (e.g., ECMP paths). This technique may involve a node in the network determining which surveillance operation to perform in relation to traffic to be transmitted along a path through the network. In some examples, the node may receive packets to be transmitted along that path and encapsulate the packets with an MPLS header. The MPLS header may include entropy labels, entropy label indicators, or other labels capable of carrying flags indicating the surveillance operation to be performed. This flag may be carried in the label's TTL field or traffic category field, allowing the surveillance operation to be triggered without altering the MPLS label stack.

[0089] Although the invention has been described with reference to specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and variations made to adapt to specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, and covers all variations and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0090] While this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions merely illustrate some embodiments that fall within the scope of the claims of this application.

Claims

1. A method for network communication, comprising: The first node of the network determines to perform a monitoring operation associated with traffic transmitted along an equal-cost multipath (ECMP) path between the first and second nodes of the network. The monitoring operation includes telemetry, performance measurement, operations management and maintenance (OAM), packet loss measurement, determining the delay between the first and second nodes, determining whether a time-sensitive network (TSN) lifetime has expired, or in-situ operations management and maintenance (IOAM). At the first node, receive the packet to be sent to the second node along the ECMP path; Based at least in part on the determination to perform the monitoring operation, the first node encapsulates the packet in a Multiprotocol Label Switching (MPLS) header including an entropy label that includes a bit flag indicating the monitoring operation to be performed; and The first node sends the packet, including the MPLS header, along the ECMP path to the second node, wherein the second node is configured to: Receive the packet; and The monitoring operation, indicated by the bit flag, is triggered at least in part based on the determination that the packet includes the bit flag.

2. The method according to claim 1, wherein: The first node is an MPLS encapsulation node of the network; The second node is the MPLS decapsulation node of the network; and The path between the MPLS encapsulation node and the MPLS decapsulation node includes one or more additional MPLS processing nodes in the network.

3. The method of claim 1 or 2, wherein, The bit flag is included in at least one of the Time to Live (TTL) field or Traffic Category (TC) field of the entropy tag or entropy tag indicator in the MPLS header.

4. The method according to claim 1 or 2, wherein: The monitoring operation includes packet loss measurements associated with the traffic transmitted along the ECMP path between the first node and the second node, and The bit included in the entropy label indicates a first coloring associated with the packet of the traffic, the first coloring being distinguishable from a second coloring associated with another packet of the traffic along the same ECMP path in the network.

5. The method of claim 1 or 2, wherein, The monitoring operation includes determining the delay associated with sending the packet from the first node to the second node along the ECMP path.

6. The method of claim 1 or 2, further comprising: At the first node, an instruction to perform the monitoring operation is received from a controller associated with the network, wherein the determination to perform the monitoring operation is based at least in part on receiving the instruction.

7. The method of claim 1 or 2, wherein, The monitoring operation includes telemetry operations, and the second node is configured to: Receive the packet; and The following operations are performed, at least in part, based on the determination that the packet includes the bit flag: Generate a copy of the group; and A copy of the packet is sent to at least one of the controllers or collectors associated with the network.

8. The method of claim 1 or 2, wherein, The monitoring operations include Operations, Administration and Maintenance (OAM) operations, and the second node is configured to: Receive the packet; and The packet is sent to a control plane node associated with the network, at least in part, based on the determination that the packet includes the bit flag, and the control plane node is used to perform the OAM operation.

9. The method according to claim 1 or 2, wherein, The monitoring operation includes determining whether a Time-Sensitive Networking (TSN) lifetime has expired, the TSN lifetime being included in the packet.

10. The method according to claim 1 or 2, wherein, The monitoring operations include MPLS in-situ operations, management and maintenance (IOAM) operations, and the second node is configured as follows: Receive the packet; as well as Operation, administration, and maintenance (OAM) data is recorded in the MPLS header of the packet or in the metadata of the packet, at least in part based on the determination that the packet includes the bit flag.

11. A first node of a network, the first node comprising: One or more processors; as well as One or more non-transitory computer-readable media, the one or more non-transitory computer-readable media storing instructions, the instructions causing the first node to perform operations when executed by the one or more processors, the operations including: The monitoring operation is determined to be performed in connection with traffic transmitted along the path between the first node and the second node of the network. The monitoring operation includes telemetry operation, performance measurement operation, operation management and maintenance (OAM) operation, packet loss measurement, determining the delay between the first node and the second node, determining whether the time-sensitive network (TSN) lifetime has expired, or in-situ operation management and maintenance (IOAM) operation. Receive the packet to be sent to the second node along the path at the first node; Based at least in part on the determination to perform the monitoring operation, the packet is encapsulated in a Multiprotocol Label Switching (MPLS) header including an entropy label comprising a bit flag indicating the monitoring operation to be performed; and The packet, including the MPLS header, is sent along the path to the second node, wherein the second node is configured to: Receive the packet; and The monitoring operation, indicated by the bit flag, is triggered at least in part based on the determination that the packet includes the bit flag.

12. The first node according to claim 11, wherein, The bit flag is included in at least one of the Time to Live (TTL) field or Traffic Category (TC) field of the entropy tag or entropy tag indicator in the MPLS header.

13. The first node according to claim 11 or 12, wherein: The path is an Equal Equivalent Multipath (ECMP) path; The monitoring operation includes packet loss measurements associated with the traffic transmitted along the ECMP path between the first node and the second node; and The bit included in the entropy label indicates a first coloring associated with the packet of the traffic, the first coloring being distinguishable from a second coloring associated with another packet of the traffic along the same ECMP path in the network.

14. The first node according to claim 11 or 12, wherein, The monitoring operation includes telemetry operations, and the second node is configured to: Receive the packet; and The following operations are performed, at least in part, based on the determination that the packet includes the bit flag: Generate a copy of the group; and A copy of the packet is sent to at least one of the controllers or collectors associated with the network.

15. The first node according to claim 11 or 12, wherein, The monitoring operations include Operations, Administration and Maintenance (OAM) operations, and the second node is configured to: Receive the packet; and The packet is sent to a control plane node associated with the network, at least in part, based on the determination that the packet includes the bit flag, and the control plane node is used to perform the OAM operation.

16. The first node according to claim 11 or 12, wherein, The monitoring operation includes determining the delay associated with sending the packet from the first node to the second node along the path.

17. The first node according to claim 11 or 12, wherein, The monitoring operation includes determining whether a Time-Sensitive Networking (TSN) lifetime has expired, the TSN lifetime being included in the packet.

18. One or more non-transitory computer-readable media, the one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations, the operations including: The first node of the network determines to perform a monitoring operation associated with traffic transmitted along an equal-cost multipath (ECMP) path between the first and second nodes of the network. The monitoring operation includes telemetry, performance measurement, operations management and maintenance (OAM), packet loss measurement, determining the delay between the first and second nodes, determining whether a time-sensitive network (TSN) lifetime has expired, or in-situ operations management and maintenance (IOAM). At the first node, receive the packet to be sent to the second node along the ECMP path; Based at least in part on the determination to perform the monitoring operation, the first node encapsulates the packet in a Multiprotocol Label Switching (MPLS) header including an entropy label indicator or a dedicated label, the entropy label indicator or the dedicated label including bit flags indicating the monitoring operation to be performed; and The first node sends the packet, including the MPLS header, along the ECMP path to the second node, wherein the second node is configured to: Receive the packet; and The monitoring operation, indicated by the bit flag, is triggered at least in part based on the determination that the packet includes the bit flag.

19. One or more non-transitory computer-readable media according to claim 18, wherein, The bit flag is included in at least one of the Time-to-Live (TTL) field or the Traffic Category (TC) field of the entropy label indicator in the MPLS header.

20. A first node of a network, the first node comprising: A means for determining monitoring operations associated with traffic transmitted along a path between a first node and a second node of the network, wherein the monitoring operations include telemetry operations, performance measurement operations, operations management and maintenance (OAM) operations, packet loss measurement, determining the delay between the first node and the second node, determining whether a time-sensitive network (TSN) lifetime has expired, or in-situ operations management and maintenance (IOAM) operations. A means for receiving, at the first node, a packet to be sent along the path to the second node; Means for encapsulating a packet in a Multiprotocol Label Switching (MPLS) header including an entropy label based at least in part on determining that the monitoring operation will be performed; and A means for sending the packet, including the MPLS header, along the path to the second node, wherein the second node is configured to: Receive the packet; and The monitoring operation, indicated by the bit flag, is triggered at least in part based on the determination that the packet includes the bit flag.

21. The first node of the network according to claim 20, further comprising: Apparatus for implementing the method according to any one of claims 2 to 10.

22. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 10.

23. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 10.

Images