Return Path Specified Label Switched Path (LSP) Ping
updated by
- rfc-7737 — Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification
Extracted elements (26)
Existing LSP ping mechanisms require operators to independently test each direction of a bidirectional LSP, doubling operational workload and requiring out-of-band access to the far-end LSR. This document addresses this by enabling a single LSP ping message exchange to test both directions of a bidirectional LSP simultaneously.
Generic RSVP Tunnel sub-TLVs (IPv4, IPv6, Static) are defined instead of requiring a specific LSP FEC so that LSP ping can verify control-plane/data-plane consistency without being disrupted by LSP identifier changes during Make-Before-Break (MBB) operations, allowing operators to specify a tunnel rather than a particular LSP.
Reply Mode 3 (UDP with Router Alert) requires all intermediate nodes to support Router Alert and understand MPLS echo reply forwarding, which is impractical in deployed networks with legacy IP-only routers. The 'Reply via Specified Path' mode avoids this by allowing operators to explicitly specify a reliable MPLS return path instead of relying on IP forwarding.
The procedures defined in this document apply only to 'ping' mode of LSP ping. The 'traceroute' mode is explicitly out of scope. If an egress LSR does not recognize the 'Reply via Specified Path' Reply Mode, it returns 'Malformed echo request received' with Subcode zero, and the operator may fall back to one of the four Reply Modes defined in RFC 4379.
If the Reply via Specified Path mode is requested, the Reply Path TLV MUST be included in the echo request message; its absence is treated as a malformed echo request. Furthermore, if a Reply Path TLV is included in an echo request, a Reply Path TLV MUST be included in the corresponding echo reply.
The A flag and B flag in the Reply Path TLV Flags field MUST NOT both be set. If both are set, an echo reply with Reply Path return code 'Malformed Reply Path TLV was received' MUST be returned.
The P bit and S bit in the Tunnel sub-TLV Flags field MUST NOT both be set; if both are set, an echo reply with RP return code 'Malformed Reply Path TLV was received' SHOULD be returned. If neither is set, the return path may be any LSP from the specified tunnel.
The Reply Path return code field MUST be set to zero in a Reply Path TLV carried on an echo request message and MUST be ignored on receipt. The field is populated only in echo replies to report the result of return path selection.
The sub-TLV space and assignments for the Reply Path TLV (Type 21) MUST be the same as for the Target FEC Stack TLV (Type 1). Sub-types for both TLV types MUST be kept the same; any new sub-type added to Type 1 MUST apply to Type 21 as well.
When an echo reply is received with Reply Mode 'Reply via Specified Path', return code 'successfully sent via specified path', and the return path is an MPLS LSP, the ingress LSR MUST perform FEC validation based on the FEC Stack information in the Reply Path TLV, following the ping-mode FEC validation process of RFC 4379.
When receiving an echo request, if the egress LSR finds a matched return path it SHOULD send an echo reply with a Reply Path TLV identifying the return path and return code 'The echo reply was sent successfully using the specified Reply Path'. If no matching path is found, an echo reply SHOULD be sent with the appropriate return code reflecting whether an alternate LSP or IP path was used.
When sending an echo reply along a specified return path, a Reply Path TLV that identifies the return path MUST be carried, and the Reply Path return code SHOULD be set to the relevant code reflecting how the egress processed the Reply Path TLV and selected the return path.
When sending an echo request using the 'Reply via Specified Path' mode, the Reply Mode of the echo request MUST be set to 5, and a Reply Path TLV MUST be carried in the echo request message. For a bidirectional LSP, only the B bit SHOULD be set; if a non-reverse path is desired, the A bit SHOULD be set or a FEC sub-TLV SHOULD be carried, and the B bit MUST be clear.
When the return path is an MPLS path, the destination IP address of the echo reply MUST be set to numbers from the range 127/8 (IPv4) or 0:0:0:0:0:FFFF:127.0.0.0/104 (IPv6), the IP TTL MUST be set to 1, and the TTL in the outermost label MUST be set to 255 to prevent the destination IP address from being used in a forwarding decision.
A new Reply Mode value 5, 'Reply via Specified Path', is defined. This mode directs the egress LSR receiving an echo request to send the echo reply along the paths specified in the Reply Path TLV included in the echo request.
For MPLS-TP deployments without IP addressing, Non-IP encapsulation as defined in RFC 6426 applies. The LSP Ping Reply Mode in both echo request and echo reply is set to 5, and the return path of the echo reply is as specified in the Reply Path TLV.
The Reply Path TLV Flags field defines two bits: A (Alternative path) forces the egress LSR to select a non-default return path (useful to diagnose reverse path problems), and B (Bidirectional) requires the return path to follow the reverse direction of the tested bidirectional LSP. When either bit is set, specific reply path sub-TLVs SHOULD be ignored.
IANA allocated value 5 ('Reply via Specified Path') in the MPLS LSP Ping Parameters 'Reply Modes' subregistry.
IANA assigned values 21 (Reply Path TLV) and 22 (Reply TC TLV) in the MPLS LSP Ping Parameters 'TLVs' subregistry, and assigned sub-TLV types 26 (IPv4 RSVP Tunnel), 27 (IPv6 RSVP Tunnel), and 28 (Static Tunnel) in the 'Sub-TLVs for TLV Types 1, 16, and 21' subregistry.
IANA created a new 'Reply Path return codes' subregistry under the MPLS LSP Ping Parameters registry, defining codes 0x0000-0x0005 (including malformed TLV, unknown sub-TLVs, successful reply, and fallback to alternate LSP or IP path), with 0x0006-0xfffb unassigned (Standard Action) and 0xfffc-0xffff reserved for Experimental Use.
The extensions defined in this document may enable 'proxying' attacks where an echo request initiator specifies a return path whose destination differs from the initiator's address. To mitigate this, the return path LSP should have a destination to the same node where the forward path originates, and receivers may drop echo requests when they cannot verify the return path LSP destination matches the initiator.
The IPv4 RSVP Tunnel sub-TLV (Type 26) carries a 4-octet IPv4 tunnel end point address, 2-octet Flags, 2-octet Tunnel ID, 4-octet Extended Tunnel ID, and 4-octet IPv4 tunnel sender address. It is derived from the RSVP IPv4 FEC TLV in RFC 4379 but omits the LSP-ID field and adds a Flags field with P (Primary) and S (Secondary) bits.
The IPv6 RSVP Tunnel sub-TLV (Type 27) carries a 16-octet IPv6 tunnel end point address, 2-octet Flags, 2-octet Tunnel ID, 16-octet Extended Tunnel ID, and 16-octet IPv6 tunnel sender address. It is derived from the RSVP IPv6 FEC TLV in RFC 4379, omitting LSP-ID and adding P/S Flags.
The Reply Path (RP) TLV (Type 21) has a 2-octet Type field, 2-octet Length field, 2-octet Reply Path return code field, 2-octet Flags field, and a variable-length Reply Path field containing zero or more Target FEC sub-TLVs. The Flags field carries A (Alternative path) and B (Bidirectional) bits.
The Reply TC TLV (Type 22) has a 2-octet Type field, 2-octet Length field (fixed value 4), and a 4-octet value field where the top 3 bits carry the TC (Traffic Class) value and remaining bits MUST be zero. It allows the echo request originator to request a specific TC marking on the echo reply's return path LSP.
The Static Tunnel sub-TLV (Type 28) carries Source Global ID (4 octets), Source Node ID (4 octets), Destination Global ID (4 octets), Destination Node ID (4 octets), Source Tunnel Num (2 octets), Destination Tunnel Num (2 octets), and a 2-octet Flags field identical to the RSVP Tunnel sub-TLV Flags.