ietf-corpus

rfc-6374

Packet Loss and Delay Measurement for MPLS Networks

D. Frost, S. Bryant
date2011-09 streamIETF areartg wgmpls statusPROPOSED STANDARD pages52 canonicalhttps://www.rfc-editor.org/rfc/rfc6374 doi10.17487/RFC6374 errataview
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]

updated by

Extracted elements (31)

design-rationale §2.7

Dyadic (dual-ended) measurement mode was intentionally not specified: while it halves the message count for both endpoints, the quantity of LM traffic is expected to be low (especially with 64-bit counters), and the gain does not justify the loss of independent measurement control per node and the added operational complexity.

mpls, measurement

design-rationale §1

The DM protocol is fully stateless and LM is 'almost stateless' (only the last response's counters need retention). This design enables external post-processing by forwarding complete messages to a dedicated device, allows the querier and responder to be stateless, and simplifies hardware implementation.

mpls, measurement

design-rationale §3.4

The truncated IEEE 1588v2 PTP format was chosen as the mandatory default timestamp rather than NTP because of the significant deployment of PTP-capable equipment in transport network environments. NTP has wider general Internet deployment, but PTP is more prevalent in the MPLS-TP target environment. Full rationale is in Appendix A.

mpls, measurement

design-rationale §3.1

Transmit counters/timestamps are always written at fixed offsets in both LM and DM messages (Counter/Timestamp 1 for querier transmit, Counter/Timestamp 3 for responder transmit), as are receive values (positions 2 and 4). This fixed-offset layout allows hardware to stamp fields without parsing the full message structure.

mpls, measurement

interoperability-note §4.2.6

32-bit and 64-bit counter implementations interoperate via the X flag: any interface writing 32-bit counters clears X to 0, and the loss calculation uses only the low-order 32 bits of all counter fields. This ensures backward compatibility without error signaling.

mpls, measurement

interoperability-note §4.3.5

DM timestamp format negotiation uses three per-message fields: QTF (querier's format), RTF (responder's actual format used), and RPTF (responder's preferred format). An implementation supporting only a single timestamp format sets RTF and RPTF to that format, trivially resolving negotiation without additional logic.

mpls, measurement

interoperability-note §2.9.6

When transmit and receive interfaces differ at a node, the DM protocol requires that the timestamp formats used by the receiving interface (reading the query) and the transmitting interface (writing the response) agree. Additionally, if different clocks are associated with transmit and receive processing, they must be synchronized for two-way delay computation.

mpls, measurement

normative-requirement §4.2.8 MUST

By default, direct LM MUST exclude packets transmitted and received over the Generic Associated Channel (G-ACh). An implementation MAY provide the means to alter this LM scope to include some or all G-ACh messages, but both endpoints must agree.

mpls, measurement

normative-requirement §2.9.9 MUST

Implementations MUST make their supported LM scopes clear to the user, and care must be taken to ensure that the scopes of the channel endpoints agree. The measurement point location behavior MUST also be made clear to the user.

mpls, measurement

normative-requirement §2.9.8 MUST

Protocol and application designers MUST account for the synchronization conditions that LM counters must reflect data-plane state at the exact moment of LM message transmission or reception; this applies equally to direct and inferred LM. The implementation's behavior in this respect MUST be made clear to the user.

mpls, measurement

normative-requirement §3.1 MUST

Reserved fields in LM and DM messages MUST be set to 0 on transmission and ignored upon receipt. All integer field values SHALL be encoded in network byte order.

mpls, measurement

normative-requirement §2.2 MUST NOT

The data associated with the last LM response MUST NOT be used as a basis for measurement if MaxLMInterval elapses before the next response arrives, because an unambiguous measurement cannot be made; such data MAY be discarded.

mpls, measurement

normative-requirement §3.4 MUST

The implementation MUST make clear which timestamp formats it supports and the extent of its support for computation with and reconciliation of different formats. An implementation MUST NOT generate an error response based on the value of the X (counter-size) flag.

mpls, measurement

normative-requirement §2.2 MUST

The LM query message transmission rate MUST be sufficiently high, given counter size and channel speed/minimum packet size, that counter wrap cannot cause measurement ambiguity. For a 32-bit counter on a 100-Gbps link with 64-byte minimum packets, MaxLMInterval is approximately 22 seconds.

mpls, measurement

normative-requirement §3.4 MUST

The truncated IEEE 1588v2 PTP timestamp format (format code 3) MUST be supported by all implementations. Implementations SHOULD also support reading NTPv4 64-bit format timestamps and reconciling them with PTP timestamps for measurement purposes.

mpls, measurement

normative-requirement §3.5 MUST

Upon receipt of a query message containing an unrecognized mandatory TLV object (Type 0–127), the recipient MUST respond with the Unsupported Mandatory TLV Object error code (0x17).

mpls, measurement

normative-requirement §4.2.5 MUST

When the querier receives an Error response (Control Code ≥ 0x10) or an invalid response, the LM/DM operation MUST be terminated and the user notified. Counter values from any non-success response MUST NOT be used for loss measurement.

mpls, measurement

protocol-element §3.1

Counter 1–4 in LM messages carry: Counter 1=A_TxP (querier transmit count), Counter 2=B_RxP or A_RxP (receive count), Counter 3=copy of prior Counter 1, Counter 4=copy of prior Counter 2. Transmit counters always appear at fixed packet offsets; this property facilitates hardware-assisted counter stamping.

mpls, measurement

protocol-element §3

Five ACH Channel Types are defined: MPLS Direct Loss Measurement (DLM), MPLS Inferred Loss Measurement (ILM), MPLS Delay Measurement (DM), MPLS Direct Loss and Delay Measurement (DLM+DM), and MPLS Inferred Loss and Delay Measurement (ILM+DM). For all these types, the ACH SHALL NOT be followed by an ACH TLV Header.

mpls, measurement

protocol-element §3.5.4

Session Query Interval (SQI) TLV (mandatory Type 2): a 32-bit unsigned millisecond value. The querier sends SQI=0 to request the responder's minimum interval; the responder replies with its minimum; the querier selects an interval ≥ that value, confirms it in subsequent queries, and MAY then stop including the SQI object once acknowledged.

mpls, measurement

protocol-element §3.1

The Control Code field specifies query mode (0x0: In-band Response, 0x1: Out-of-band Response, 0x2: No Response) or response outcome: 0x1 Success; 0x2–0x5 transient Notifications (Data Format Invalid, Initialization in Progress, Data Reset, Resource Temporarily Unavailable); 0x10–0x1D fatal Errors (Unspecified, Unsupported Version, Authentication Failure, Connection Mismatch, Invalid Message, Protocol Error, etc.).

mpls, measurement

protocol-element §3.1

The DFlags field carries the X bit (1 = all interfaces writing 64-bit counters; cleared to 0 by any 32-bit interface, propagated through query to response) and B bit (1 = octet counts, 0 = packet counts). The X flag governs whether 64-bit or 32-bit arithmetic is used in loss calculation.

mpls, measurement

registry §9.1

IANA is requested to allocate five PW Associated Channel Type codepoints for: MPLS Direct Loss Measurement (DLM), MPLS Inferred Loss Measurement (ILM), MPLS Delay Measurement (DM), MPLS Direct Loss and Delay Measurement (DLM+DM), and MPLS Inferred Loss and Delay Measurement (ILM+DM).

mpls, measurement, registry

registry §9.2

IANA is requested to create the Measurement Timestamp Type registry for RFC 6374, with initial entries 0=Null, 1=Sequence Number, 2=NTPv4 64-bit, 3=Truncated IEEE 1588v2 PTP. New assignments require Standards Action.

mpls, measurement, registry

registry §9.4

IANA is requested to create the MPLS Loss/Delay Measurement TLV Object registry. Mandatory types defined: 0=Padding (copy), 1=Return Address, 2=Session Query Interval, 3=Loopback Request, 127=Experimental. Optional types: 128=Padding (no copy), 129=Destination Address, 130=Source Address, 255=Experimental.

mpls, measurement, registry

security-consideration §8

LM and DM messages carried over the G-ACh are subject to the security properties of the MPLS data plane. Unauthorized injection or modification of measurement messages can corrupt SLA data or disrupt operations; the Control Code 0x14 (Authentication Failure) provides a defined error path for implementations that apply authentication to measurement sessions. Responders SHOULD employ rate-limiting to guard against excessive query traffic.

mpls, measurement, security

wire-format §3.3

Combined Loss/Delay Measurement message merges DM and LM: second word carries DFlags(4b)/QTF(4b)/RTF(4b)/RPTF(4b)/Reserved(16b), followed by Session Identifier/DS, four 8-byte Timestamp fields, four 8-byte Counter fields, and an optional TLV Block. The QTF and Timestamp 1 fields serve the roles of OTF and Origin Timestamp.

mpls, measurement

wire-format §3.2

Delay Measurement (DM) message format (after ACH): Version(4b)/Flags(4b)/Control Code(8b)/Message Length(16b); QTF(4b)/RTF(4b)/RPTF(4b)/Reserved(20b); Session Identifier(26b)/DS(6b); Timestamps 1–4 (each 64b); optional TLV Block. Transmit timestamps always appear at fixed offsets to support hardware processing.

mpls, measurement

wire-format §3.1

Loss Measurement (LM) message format (after ACH): Version(4b)/Flags(4b)/Control Code(8b)/Message Length(16b); DFlags(4b)/OTF(4b)/Reserved(24b); Session Identifier(26b)/DS(6b); Origin Timestamp(64b); Counter 1–4 (each 64b); optional TLV Block. 32-bit counter values are written to the low-order 32 bits with the high-order 32 bits set to 0.

mpls, measurement

wire-format §3.4

Timestamp formats: 0=Null (no meaningful timestamp), 1=64-bit sequence number, 2=NTPv4 64-bit (32b seconds + 32b fractional seconds), 3=truncated IEEE 1588v2 PTP (32b seconds + 32b nanoseconds). Formats of fewer than 64 bits SHALL use the n high-order bits; low-order bits SHOULD be set to 0 and MUST be ignored on reading.

mpls, measurement

wire-format §3.5

TLV object format: 8-bit Type, 8-bit Length (size of Value in bytes, maximum 255), variable-length Value. Types 0–127 are mandatory (unrecognized mandatory TLV triggers an error response); Types 128–255 are optional (unrecognized optional TLV may be ignored).

mpls, measurement