Encapsulation for MPLS Performance Measurement with the Alternate-Marking Method
Extracted elements (25)
FLC and FRLD are introduced as direct analogs of ELC and ERLD to reuse the established entropy-label capability/depth signaling model. The only semantic difference is that FL serves flow identification while entropy labels serve load balancing.
The TC field of the FL is repurposed for loss/delay/type color-marking bits rather than traffic class because the FL is not a forwarding label, making the reuse of TC feasible and viable without affecting MPLS forwarding behavior.
The TTL of the FL is set to zero to ensure the FL is never mistakenly used as a forwarding label, since the cSPL+FL construct is purely a measurement artifact and must not influence routing decisions.
This document is expected to be declared Historic once the MPLS Network Actions (MNA) encapsulation (RFC 9613 et seq.) is published as an RFC, as MNA will provide a broader and more advanced solution for MPLS performance measurement. The MPLS WG has agreed to this lifecycle plan.
Under ECMP conditions, adding an FL to an existing flow may cause that flow to take a different path (the same problem seen with Synonymous Flow Labels per RFC 8957). Operators can resolve this by applying entropy labels (RFC 6790) or adding FL to all flows.
When PHP is in use, the penultimate LSR pops the forwarding label and therefore MUST also pop the accompanying XL, FLI, and FL per Section 4. If this is not supported, the egress LSR is excluded from measurement. PHP should be disabled unless the penultimate LSR is confirmed to support this specification.
If any XL or FLI processed by a node has the BoS bit set, the node MUST discard the packet and MAY log an error.
The FL value MUST be unique within the administrative domain; there is a one-to-one mapping between a Flow-ID and a flow. The TTL for the FL MUST be zero to prevent it from being used inadvertently for forwarding.
The ingress node MUST insert each FL at a depth where the exposed node has the FLC. The ingress node SHOULD insert each FL within the minimum FRLD of all on-path nodes that need to read and use that FL.
The NMS/controller MUST ensure that every generated Flow-ID is unique within the administrative domain and MUST NOT assign any value in the reserved label space (0–15).
The processing node MUST pop the XL, FLI, and FL from the MPLS label stack when it needs to pop the preceding forwarding label. The egress node MUST pop the whole MPLS label stack.
The TC and TTL fields of the XL and FLI MUST use the same values as the label immediately preceding the XL. The BoS bit for both XL and FLI MUST be zero.
When SR paths are used and the label stack depth makes FRLD compliance difficult, an implementation MAY allow the ingress node to place FL between SID labels, permitting multiple identical FLs at different depths interleaved with SID labels.
Flow-ID allocation supports two trigger modes: manual (operator inputs flow characteristics and NMS/controller generates Flow-IDs) and automatic (ingress node identifies the flow and exports characteristics via IPFIX to the NMS/controller, which then allocates Flow-IDs).
Flow-ID Label Capability (FLC) and Flow-ID Readable Label Depth (FRLD) are defined analogously to ELC (RFC 6790) and ERLD (RFC 8662), constraining how deep in the label stack an FL may be placed to ensure processing nodes can reach it.
If edge-to-edge measurement is applied (T bit = 1), only the MPLS ingress/egress nodes are processing nodes; otherwise all MPLS nodes along the LSP are processing nodes and must inspect labels beyond the forwarding label at the top of the stack.
The FL, preceded by a cSPL, may be placed at the bottom or middle (but never at the top) of the MPLS label stack, and MAY appear multiple times within a single label stack for simultaneous transport-layer and service-layer measurement.
The Flow-ID Label Indicator (FLI) is an Extended Special Purpose Label (eSPL) assigned value 18, combined with the Extension Label (XL, value 15) to form a Composite Special Purpose Label (cSPL) as defined in RFC 9017.
The TC field of the Flow-ID Label (FL) is repurposed for color-marking: L-bit for packet loss coloring (1=color 1, 0=color 0), D-bit for delay/jitter measurement coloring, and T-bit to distinguish edge-to-edge (T=1) from hop-by-hop (T=0) measurement.
IANA assigned value 18 with description 'Flow-ID Label Indicator (FLI)' in the 'Extended Special-Purpose MPLS Label Values' registry within the 'Special-Purpose Multiprotocol Label Switching (MPLS) Label Values' registry group.
Improper configuration that allows FL to cross administrative domain boundaries results in Flow-ID conflicts. Note that such packet leakage is neither a privacy breach nor a DoS source, but it breaks measurement integrity.
Per RFC 9341 Section 7.1, the Alternate-Marking Method MUST only be applied to controlled domains. The MPLS encapsulation and related procedures defined in this document therefore MUST only be applied to controlled domains to avoid the attacks discussed in RFC 9341 Section 10.
The FL MUST NOT be signaled or distributed outside the administrative domain. Domain boundary nodes MUST deploy policies (e.g., ACL) to filter FL-bearing packets: at the sending edge, filter outbound packets carrying FLI; at the receiving edge, drop inbound packets carrying FLI from other domains.
The Flow-based PM encapsulation consists of three 32-bit label stack entries: Extension Label (value 15), Flow-ID Label Indicator (value 18), and Flow-ID Label. The FL's TC field is repurposed to carry L (loss), D (delay), and T (type) bits rather than traffic-class markings.
When the FL is applied to both MPLS transport and MPLS service, two FL entries appear in the label stack (one above the application label, one at/near the bottom). The two FL values MUST be different and are independent of each other.