Residence Time Measurement in MPLS Networks
Extracted elements (31)
Ingress and egress timestamps should be captured as close to the physical layer as possible to avoid attributing queuing or processing jitter as propagation delay. A common free-running clock with ~4.6 ppm accuracy introduces only ~4.6 ns error per millisecond of residence time, which is acceptable for applications targeting hundreds-of-nanoseconds accuracy.
Residence time is accumulated in the Scratch Pad rather than relying on end-to-end delay measurement (RFC 6374) because PTP requires per-packet transit correction to update the correctionField — aggregate delay statistics are insufficient for making MPLS transit nodes transparent to clock synchronization.
The PTP timing packet in the Value field may be authenticated or encrypted and is carried unchanged through the LSP; only the Scratch Pad field (outside the protected payload) is updated by intermediate RTM-capable nodes. This allows end-to-end message integrity protection to coexist with MPLS-layer residence time measurement.
RTM is defined only for RSVP-TE signaled LSPs (RFC 3209) where the explicit path can be either specified or determined during signaling. Use of RTM over LDP-instantiated LSPs is explicitly outside the scope of this document.
A node MUST NOT place more than one sub-TLV with the same Value in the RTM_SET TLV; if a duplicate address is found, LSP setup MUST fail with ResvErr Error Code 42 (Duplicate sub-TLV) with Error Value encoding (Type of TLV, Type of sub-TLV).
A node supporting RTM MUST be able to act in two-step mode and MAY also support one-step mode. When advertising RTM capability in an IGP, the sub-TLV MUST reflect the actual RTM capability of the advertised interface.
A node with RTM-capable interfaces MUST be able to compute a TTL that causes expiry of an RTM packet at the next RTM-capable node downstream; this TTL-based hop-by-hop delivery is fundamental to the RTM data-plane mechanism.
A one-step-capable RTM node MAY operate in either one-step or two-step mode, but it MUST NOT update both the Scratch Pad of the event message and the Scratch Pad of the associated follow-up message.
An ingress node configured for RTM MUST verify that the selected egress node supports RTM via the RTM Capability sub-TLV advertisement before placing the RTM_SET Attribute Flag in the Path message's LSP_ATTRIBUTES object.
Each RTM-capable node MUST examine the Resv message for the RTM_SET Attribute Flag. If more than one RTM_SET TLV is found, LSP setup MUST fail with ResvErr Error Code 41 (Duplicate TLV). If no RTM_SET TLV is found, it MUST fail with Error Code 43 (RTM_SET TLV Absent).
RTM SHOULD NOT be used if it cannot be guaranteed that the RRO contains complete information; policy-based RRO pruning at provider boundaries or RRO size constraints break the TTL computation that underpins the hop-by-hop RTM delivery mechanism.
The first two-step RTM node MUST (1) mark the original event message to indicate a follow-up is forthcoming and (2) create a follow-up message with the initial correctionField value. The S bit MUST NOT be unset until the original and follow-up messages are combined by an endpoint boundary clock.
The RTM_SET Attribute Flag SHOULD NOT be set in the LSP_REQUIRED_ATTRIBUTES object unless it is known that all nodes recognize the RTM attribute, because an unrecognizing node would reject the Path message entirely.
The Type/Length/Value TLV MUST be included in the RTM message even if the length of the Value field is zero, ensuring the timing protocol type is always signaled in every RTM packet.
When a two-step RTM-capable egress finds the S bit clear, it MUST set the S bit and create a follow-up PTP Type RTM message. If S is already set, it MUST wait for the matching follow-up RTM message with matching PTP type, Port ID, and Sequence ID; the wait period MUST be reasonably bounded.
When an egress node receives a Path message with the RTM_SET Attribute Flag set in LSP_ATTRIBUTES, it MUST include an initialized RRO and LSP_ATTRIBUTES object with the RTM_SET Attribute Flag set and the RTM_SET TLV initialized in the Resv message.
One-step RTM mode updates the Scratch Pad inline while forwarding the packet; two-step RTM mode defers the Scratch Pad update to a separate follow-up message. The capability of the egress interface determines which mode applies to an ingress/egress interface pair.
RTM accumulates per-node residence time in a dedicated Scratch Pad field carried in a G-ACh message alongside the timing packet, allowing the egress node to update the PTP correctionField and making intermediate MPLS transit nodes transparent to the clock synchronization protocol.
The RTM Capability Sub-TLV uses a 3-bit bitmap advertised per interface in OSPFv2 (type 5), IS-IS (type 40), and BGP-LS (type 1105): 0b001 = one-step RTM supported, 0b010 = two-step RTM supported. It reflects the egress capability of the advertised interface.
The RTM_SET TLV, carried in RSVP-TE LSP_ATTRIBUTES (type 5 in Attributes TLV Space), contains an ordered egress-to-ingress stack of RTM-capable node address sub-TLVs. The I bit signals that some RTM-capable nodes along the LSP could not be included in the TTL hop computation.
IANA assigned G-ACh value 0x000F for Residence Time Measurement in the 'Generic Associated Channel (G-ACh) Parameters' registry.
IANA assigned RTM Capability Sub-TLV codepoints: type 5 in 'OSPFv2 Extended Link TLV Sub-TLVs', type 40 in IS-IS 'Sub-TLVs for TLVs 22, 23, 141, 222, and 223' (valid for TLVs 22, 23, 222, 223), and type 1105 in 'BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs'.
IANA assigned RTM_SET sub-object type 5 in RSVP-TE 'Attributes TLV Space' (allowed on LSP_ATTRIBUTES, not LSP_REQUIRED_ATTRIBUTES or LSP Hop Attributes), RTM_SET Attribute Flag as bit 15 in RSVP-TE 'Attribute Flags', and created the 'RTM_SET Object Sub-Object Types' registry with IPv4 (1), IPv6 (2), and Unnumbered Interface (3).
IANA assigned three new RSVP error codes: 41 (Duplicate TLV), 42 (Duplicate sub-TLV), and 43 (RTM_SET TLV Absent) in the 'Error Codes and Globally-Defined Error Value Sub-Codes' registry.
IANA created the 'MPLS RTM TLV Registry' under G-ACh Parameters with initial types: 0=Reserved, 1=No payload, 2=PTPv2/Ethernet, 3=PTPv2/IPv4, 4=PTPv2/IPv6, 5=NTP, 192-254=Private Use; and the nested 'MPLS RTM Sub-TLV Registry' with types: 0=Reserved, 1=PTP. Range 0-127 uses IETF Review; 128-191 uses First Come First Served.
A compromised node could intercept and modify G-ACh content including the Scratch Pad and timing data, corrupting residence time accumulation. This risk is inherent to all LSP-carried data and is governed by the same trust model assumed for MPLS networks per RFC 4385 and RFC 5085.
RTM requires a trusted relationship among all PTP-aware nodes on the path, since intermediate nodes must modify PTP message content (updating the Scratch Pad / correctionField). Those message portions cannot be protected by confidentiality or integrity mechanisms with current practical methods, as intermediate modifications must remain detectable and unauthenticated.
RTM_SET sub-TLVs encode RTM-capable node addresses in one of three formats: IPv4 (Type=0x01, Length=8, 32-bit address), IPv6 (Type=0x02, Length=20, 128-bit address), or Unnumbered Interface (Type=0x03, Length=12, 32-bit Node ID + 32-bit Interface ID). All sub-TLV lengths MUST be multiples of 4 and at least 8.
The PTP Packet Sub-TLV (Type=1, Length MUST be 20 octets) contains a 28-bit Flags field with a 1-bit S flag indicating two-step mode, a 4-bit PTPType, a 10-octet Port ID, and a 2-octet Sequence ID. The tuple of PTPType, Port ID, and Sequence ID uniquely identifies the associated PTP message for two-step RTM correlation.
The RTM G-ACh message begins with a 4-octet G-ACh header (Version=0, RTM G-ACh=0x000F), followed by an 8-octet Scratch Pad for accumulated residence time, then a Type/Length/Value field identifying and carrying the encapsulated timing packet (NTP or PTP). The Reserved field MUST be set to 0 on transmit and ignored on receipt.
The Scratch Pad field is 8 octets encoded as a 64-bit signed integer representing residence time in nanoseconds multiplied by 2^16. The first RTM-capable node MUST initialize it with its own residence time; each subsequent RTM-capable transit node adds its measured residence time to the accumulated value.