RFC 6424
Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels
Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels 🎀
- Document: RFC 6424, a Standards Track document
- Authors: N. Bahadur (Juniper Networks, Inc.), K. Kompella (Juniper Networks, Inc.), and G. Swallow (Cisco Systems)
- Published: November 2011, from the Internet Engineering Task Force (IETF)
- ISSN: 2070-1721
- Updates: RFC 4379 ✨
Abstract 💖
This doc is all about doing LSP ping traceroute (the RFC 4379 kind) over MPLS tunnels, and tracing stitched MPLS LSPs too 🧚 RFC 4379's techniques just aren't enough for FEC validation and path discovery when an LSP goes through other MPLS tunnels or when it's stitched. So this doc deprecates the Downstream Mapping TLV (defined in RFC 4379) and swaps in a new TLV. Paired with some other procedures in here, that new TLV is what lets you trace those tricky LSPs. Iconic 👑
Status of This Memo 📝
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6424.
Copyright Notice ⭐
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🌸
Table of Contents 🦋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Summary of Changes . . . . . . . . . . . . . . . . . . . . 5
3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Return Code per Downstream . . . . . . . . . . . . . . 6
3.2.2. Return Code for Stitched LSPs . . . . . . . . . . . . 6
3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 7
3.3.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1.1. Multipath Data Sub-TLV . . . . . . . . . . . . . . 9
3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 13
4. Performing MPLS Traceroute on Tunnels . . . . . . . . . . . . 13
4.1. Transit Node Procedure . . . . . . . . . . . . . . . . . . 13
4.1.1. Addition of a New Tunnel . . . . . . . . . . . . . . . 13
4.1.2. Transition between Tunnels . . . . . . . . . . . . . . 14
4.1.3. Modification to FEC Validation Procedure on Transit . 16
4.2. Modification to FEC Validation Procedure on Egress . . . . 16
4.3. Ingress Node Procedure . . . . . . . . . . . . . . . . . . 17
4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17
4.3.1.1. Stack Change Sub-TLV Not Present . . . . . . . . . 17
4.3.1.2. Stack Change Sub-TLV(s) Present . . . . . . . . . 17
4.3.2. Modifications to Handling a Return Code 3 Reply. . . . 19
4.3.3. Handling of New Return Codes . . . . . . . . . . . . . 19
4.4. Handling Deprecated Downstream Mapping TLV . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 221. Introduction ✨
This doc describes how to do LSP ping (specified in [RFC4379]) traceroute over MPLS tunnels. The techniques in [RFC4379] lay out a traceroute mechanism that does Forwarding Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP) path discovery 💅 But those mechanisms fall short and don't give enough detail when the FEC being traced goes through one or more MPLS tunnels, or when Label Switched Path (LSP) stitching [RFC5150] is in use. So this doc deprecates the Downstream Mapping TLV [RFC4379] and brings in a new TLV that's more extensible and can retrieve detailed info 🙈 Using that new TLV format together with the existing definitions in [RFC4379], this doc walks through procedures so a traceroute request can get through MPLS tunnels with proper FEC and label validation. Main character energy 🎀
1.1. Conventions Used in This Document 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Motivation 🧚
An LSP ping traceroute may cross multiple MPLS tunnels on its way to the destination. Let's look at a simple case first, bestie 🍓
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
Figure 1: LDP over RSVP TunnelWhen a traceroute starts at router A, router B sends back downstream mapping info for node C in the MPLS echo reply. The next MPLS echo request reaches router C with an LDP FEC. Node C is a pure RSVP node and doesn't run LDP 😭 So node C gets the MPLS echo request with two labels but only one FEC in the Target FEC stack. That means node C can't do a complete FEC validation. It will let the trace keep going by just giving next-hop info based on the incoming label and by looking up the forwarding state tied to that label. But ignoring FEC validation totally defeats the point of control-plane validations, ngl 💀 The MPLS echo request should carry enough info to let node C do FEC validations and catch any misrouted echo requests.
The problem above can be stretched to the general case of hierarchical tunnels or stitched tunnels (for example, B-C can be a separate RSVP tunnel and C-D can be a separate RSVP tunnel). The FEC validation problem for tunnels can be solved if the transit routers (router B in the example above) give the ingress some info about where a new tunnel starts 🦋
Stitched LSPs are made of two or more LSP segments stitched together. The segments can be signaled using the same or different signaling protocols. To do an end-to-end trace of a stitched LSP, the ingress needs to know the FEC info for each of the stitched LSP segments. For example, check out the figure below 👀
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
Figure 2: Stitched LSPPicture the ingress (A) tracing the end-to-end stitched LSP A--F. When an MPLS echo request reaches router C, there's a FEC stack change happening at router C. With the current LSP ping [RFC4379] mechanisms, there's no way to tell A about this 😤 So when the next echo request reaches router D, router D knows nothing about the LDP FEC that A is trying to trace.
So the procedures in [RFC4379] just don't let the ingress node do these things:
- Know that tunneling has occurred.
- Trace the path of the tunnel.
- Trace the path of stitched LSPs.
3. Packet Format 📦
3.1. Summary of Changes 🌈
In lots of cases, there's a need to attach extra data to the MPLS echo reply. Most of the time, that extra data needs to go on a per-downstream-neighbor basis. Right now, the MPLS echo reply has one Downstream Mapping TLV (DSMAP) per downstream neighbor. But the DSMAP format isn't extensible, so there's no way to attach more info to a downstream neighbor. This doc defines a new extensible format for the DSMAP and gives mechanisms for solving the tunneled LSP ping problem using that new format. In short, this doc makes the following TLV changes:
- Addition of new Downstream Detailed Mapping TLV (DDMAP).
- Deprecation of existing Downstream Mapping TLV (DSMAP).
- Addition of Downstream FEC stack change sub-TLV to DDMAP.
3.2. New Return Codes 🔥
3.2.1. Return Code per Downstream 💖
A new Return Code is being defined, "See DDM TLV for Return Code and Return Subcode" (Section 6.3), to show that the Return Code is per Downstream Detailed Mapping TLV (Section 3.3). This Return Code MUST be used only in the message header, and it MUST be set only in the MPLS echo reply message. If the Return Code is set in the MPLS echo request message, then it MUST be ignored. When this Return Code is set, each Downstream Detailed Mapping TLV MUST have an appropriate Return Code and Return Subcode. This Return Code MUST be used when there are multiple downstreams for a given node (such as Point to Multipoint (P2MP) or Equal Cost Multi-Path (ECMP)), and the node needs to return a Return Code/Return Subcode for each downstream. This Return Code MAY be used even when there is only one downstream for a given node. ✨
That's the first chunk, babe. More parts are coming, so stay tuned 🫶
3.2.2. Return Code for Stitched LSPs ✨
Okay so, when you're running a traceroute over stitched LSPs (Section 4.1.2) 🛤️, the stitching point SHOULD tell the node doing the trace what it just did 🦋. It does that by setting the Return Code to "Label switched with FEC change" (Section 6.3). Cute and clear.
And if a node is doing FEC hiding 🙈, it MAY pick a different Return Code value (from the ones in [RFC4379]) instead of "Label switched with FEC change". That's totally its call, bestie 💅.
But here's the hard no 🚫: the Return Code "Label switched with FEC change" MUST NOT be used if there's no FEC stack sub-TLV (Section 3.3.1.3) in the Downstream Detailed Mapping TLV(s). Not a vibe, not a suggestion, a whole no.
Last bit: this new Return Code MAY also be used for hierarchical LSPs, to flag the start or end of an outer LSP 🪆🌈.
3.3. Downstream Detailed Mapping TLV 🎀
Okay, this one is the main character of the section.
Type # Value Field
------ ------------
20 Downstream Detailed MappingThe Downstream Detailed Mapping object is a TLV that MAY be included in an MPLS echo request message 📨. Only one Downstream Detailed Mapping object may appear in an echo request. Including it is basically asking for Downstream Detailed Mapping objects to come back in the MPLS echo reply 🙋♀️. If the replying router is the destination (Label Edge Router) of the FEC, then a Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS echo reply, because there's nothing downstream to map 🤷♀️. Otherwise, the replying router SHOULD include a Downstream Detailed Mapping object for each interface over which this FEC could be forwarded 🧚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-tlv Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Downstream Detailed Mapping TLVThe Downstream Detailed Mapping TLV format is derived from the Downstream Mapping TLV format 🍓. The big change is that variable length and optional fields have been turned into sub-TLVs 🧩. The fields have the same use and meaning as in [RFC4379]. Here's a quick rundown of the fields taken from the Downstream Mapping TLV:
Maximum Transmission Unit (MTU): The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the Downstream Label Switching Router (LSR) 📏.
Address Type: The Address Type tells you if the interface is numbered or unnumbered. It also decides the length of the Downstream IP Address and Downstream Interface fields 🔢.
DS Flags: The DS Flags field is a bit vector of various flags 🚩.
Downstream Address and Downstream Interface Address: IPv4 addresses and interface indices are encoded in 4 octets, and IPv6 addresses are encoded in 16 octets 💜. For details on setting the address value, refer to [RFC4379].
The newly added sub-TLVs and their fields are described below 👇.
Return Code: The Return Code is set to zero by the sender. The receiver can set it to one of the values in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry 📚.
If the receiver sets a non-zero value in the Return Code field of the Downstream Detailed Mapping TLV, then the receiver MUST also set the Return Code field in the echo reply header to "See DDM TLV for Return Code and Return Subcode" (Section 6.3). There's one exception 👀: if the receiver is a bud node [RFC4461] and is replying as both an egress and a transit node, with a Return Code of 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") in the echo reply header.
If the Return Code of the echo reply message is not set to either "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Code specified in the Downstream Detailed Mapping TLV MUST be ignored 🙅♀️.
Return Subcode: The Return Subcode is set to zero by the sender. The receiver can set it to one of the values in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry. This field gets filled in with the stack-depth for those codes that specify the stack-depth 📏. For all other codes, the Return Subcode MUST be set to zero.
If the Return Code of the echo reply message is not set to either "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Subcode specified in the Downstream Detailed Mapping TLV MUST be ignored.
Sub-tlv Length: Total length in bytes of the sub-TLVs associated with this TLV 🧮.
3.3.1. Sub-TLVs 🫶
This section defines the sub-TLVs that MAY be included as part of the Downstream Detailed Mapping TLV 💖.
Sub-Type Value Field
--------- ------------
1 Multipath data
2 Label stack
3 FEC stack change3.3.1.1. Multipath Data Sub-TLV 🛣️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Multipath Sub-TLVThe multipath data sub-TLV includes Multipath Information. The sub-TLV fields and how they're used are defined in [RFC4379]. Quick summary of the fields:
Multipath Type: The type of the encoding for the Multipath Information.
Multipath Length: The length in octets of the Multipath Information.
MBZ: MUST be set to zero when sending; MUST be ignored on receipt 🧼.
Multipath Information: Encoded multipath data, according to the Multipath Type.
3.3.1.2. Label Stack Sub-TLV 🏷️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Label Stack Sub-TLVThe Label stack sub-TLV holds the set of labels in the label stack, exactly as it would look if this router were forwarding the packet out this interface 🎯. Any Implicit Null labels are explicitly included. The number of label/protocol pairs in the sub-TLV is worked out from the sub-TLV data length. The label format and protocol type are as defined in [RFC4379]. When the Downstream Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be included 🫡.
Downstream Label: A Downstream label is 24 bits, in the same format as an MPLS label minus the Time to Live (TTL) field. So the MSBit of the label is bit 0, the LSBit is bit 19, the Traffic Class (TC) field [RFC5462] is bits 20-22, and S is bit 23 ✨. The replying router SHOULD fill in the TC field and S bit, but the LSR receiving the echo reply MAY choose to ignore these 🤍.
Protocol: This specifies the label distribution protocol for the Downstream label 📡.
3.3.1.3. FEC Stack Change Sub-TLV 🦋
okay so this one is the FEC stack change sub-TLV and it's giving main character energy. 💅 A router MUST include it when the downstream node in the echo reply has a different FEC Stack than the FEC Stack the echo request came in with. You can have one or more of these in a Downstream Detailed Mapping TLV (MAY be present, so no pressure). Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address Type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: FEC Stack Change Sub-TLV
Operation Type 🌸
This tells you what happened to the FEC stack. Two types are defined:
Type # Operation
------ ---------
1 Push
2 PopAddress Type 🧚
This one says what kind of address the remote peer has. The length of the peer address depends on this type. The address type MAY be different from the address type in the Downstream Detailed Mapping TLV, which happens when the LSP goes over a tunnel of a different address family. The address type MAY also be set to Unspecified if the peer address is unavailable or the transit router just doesn't want to share it for security or admin reasons (rude, but valid 🙈).
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0
1 IPv4 4
2 IPv6 16FEC TLV Length ✨
Length in bytes of the FEC TLV. That's it, that's the tea.
Reserved 🔒
This field is reserved for future use and MUST be set to zero. No freestyling here, bestie.
Remote Peer Address 🍓
This is the remote peer that's the next-hop for the FEC currently being traced. Like, in the LDP over RSVP case in Figure 1, router B would reply with the address of router D as the remote peer address for the LDP FEC being traced. It lets the ingress node learn who the FEC peers are, which is iconic. If the operation type is Push, the remote peer address is the address of the peer the pushed FEC was learned from. If the operation type is Pop, the remote peer address MAY be set to Unspecified.
For upstream-assigned labels [RFC5331], a Pop operation will have a remote peer address (the upstream node that assigned the label), and this SHOULD be included in the FEC stack change sub-TLV. The remote peer address MAY be set to Unspecified if the address needs to be hidden. 🫶
FEC TLV 💖
The FEC TLV is only there when the FEC-tlv length field is non-zero. It names the FEC tied to the FEC stack change. This TLV MAY be included when the operation type is Pop. It MUST be included when the operation type is Push. The FEC TLV holds exactly one FEC from the list of FECs in [RFC4379]. A Nil FEC MAY go with a Push operation if the responding router wants to hide the details of the FEC being pushed. 🙈
FEC stack change sub-TLV operation rules 👑
These are the vibe checks for stacking operations:
a. A FEC stack change sub-TLV with a Push operation MUST NOT be followed by one with a Pop operation.
b. One or more Pop operations MAY be followed by one or more Push operations.
c. One FEC stack change sub-TLV MUST be included per FEC stack change. For example, if 2 labels are going to be pushed, then one FEC stack change sub-TLV MUST be included for each FEC.
d. A FEC splice operation (where one FEC ends and another FEC starts, see Figure 7) MUST be done by including a Pop type FEC stack change sub-TLV followed by a Push type FEC stack change sub-TLV. 🔥
e. A Downstream detailed mapping TLV with only one FEC stack change sub-TLV carrying a Pop operation is equivalent to IS_EGRESS (Return Code 3, [RFC4379]) for the outermost FEC in the FEC stack. The ingress router doing the MPLS traceroute MUST treat that case as an IS_EGRESS for the outermost FEC. 💀
3.4. Deprecation of Downstream Mapping TLV 🥀
okay, the Downstream Mapping TLV is officially deprecated 😭. This document says LSP ping procedures should now use the Downstream Detailed Mapping TLV instead. The detailed procedures for how the old TLV and the new TLV play together are in Section 4.4.
4. Performing MPLS Traceroute on Tunnels 🌈
this section is the tunnel glow-up 🧚✨. It describes what the LSP ingress node and the LSP transit nodes do when they run MPLS traceroute over MPLS tunnels.
4.1. Transit Node Procedure 🎀
4.1.1. Addition of a New Tunnel 🦋
a transit node (Figure 1) knows when the FEC being traced is about to enter a tunnel at that node, so it knows about the new outer FEC. Any transit node that originates a new tunnel SHOULD add the FEC stack change sub-TLV (Section 3.3.1.3) to the Downstream Detailed Mapping TLV (Figure 3) in the echo reply. It SHOULD add one FEC stack change sub-TLV of operation type Push for each new tunnel originated at that transit node.
A transit node that sends a Downstream FEC stack change sub-TLV in the echo reply SHOULD fill in the address of the remote peer, which is the peer of the current LSP being traced. If the transit node doesn't know the remote peer's address, it MUST set the address type to Unspecified. 🙈
The Label stack sub-TLV MUST contain one additional label per FEC being pushed. The label MUST be encoded as in Figure 5. The label value MUST be the value used to switch the data traffic. If the tunnel is a transparent pipe to the node (meaning the data-plane trace won't expire in the middle of the new tunnel), then a FEC stack change sub-TLV SHOULD NOT be added, and the Label stack sub-TLV SHOULD NOT contain a label for the hidden tunnel. 🫣
If the transit node wants to hide the nature of the tunnel from the ingress of the echo request, it MAY not want to send details about the new tunnel FEC to the ingress. In that case, the transit node SHOULD use the Nil FEC. The echo reply would then contain a FEC stack change sub-TLV with operation type Push and a Nil FEC. The value of the label in the Nil FEC MUST be set to zero. The remote peer address type MUST be set to Unspecified. The transit node SHOULD add one FEC stack change sub-TLV of operation type Push for each new tunnel originated at that transit node. The Label stack sub-TLV MUST contain one additional label per FEC being pushed. The label value MUST be the value used to switch the data traffic. 🕵️♀️
4.1.2. Transition between Tunnels 🌸
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVPFigure 7: Stitched LSPs
in the figure above, we've got three separate LSP segments stitched together at C and D 🧵. Node C SHOULD include two FEC stack change sub-TLVs: one with a Pop operation for the LDP FEC, and one with a Push operation for the BGP FEC. Node D is similar and SHOULD include two FEC stack change sub-TLVs, one with a Pop operation for the BGP FEC and one with a Push operation for the RSVP FEC. Nodes C and D SHOULD set the Return Code to "Label switched with FEC change" (Section 6.3) to show the FEC being traced has changed.
If node C wants to do FEC hiding, it SHOULD respond with two FEC stack change sub-TLVs, one Pop followed by one Push. The Pop operation MAY either leave out the FEC TLV (by setting the FEC TLV length to 0) or set the FEC TLV to contain the LDP FEC. The Push operation SHOULD have the FEC TLV containing the Nil FEC. The Return Code SHOULD be set to "Label switched with FEC change". 🫶
If node C does FEC hiding and node D also does FEC hiding, then node D MAY choose not to send any FEC stack change sub-TLVs in the echo reply, because the number of labels hasn't changed (for the downstream of node D) and the FEC type hasn't changed either (it's still Nil FEC). In that case, node D MUST NOT set the Return Code to "Label switched with FEC change". If node D does FEC hiding, then node F will respond as IS_EGRESS for the Nil FEC, and the ingress (node A) will know that IS_EGRESS corresponds to the end-to-end LSP. 🏁
A B C D E F
o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP
| \_______________________________/|
| RSVP-B |
\________________________________/
LDPFigure 8: Hierarchical LSPs
in this one, there's an end-to-end LDP LSP between nodes A and F 🪆. That LDP LSP rides over RSVP LSP RSVP-B, and RSVP-B itself rides over another RSVP LSP, RSVP-A. When node A starts a traceroute for the end-to-end LDP LSP, this is the sequence of FEC stack change sub-TLVs you'll see:
Node B:
Respond with two FEC stack change sub-TLVs: Push RSVP-B, Push RSVP-A.
Node D:
Respond with Return Code 3 when RSVP-A is the top of the FEC stack. When the echo request has RSVP-B as the top of the stack, respond with downstream information for node E and an appropriate Return Code.
If node B is doing tunnel hiding, then:
Node B:
Respond with two FEC stack change sub-TLVs: Push Nil FEC, Push Nil FEC.
Node D:
If D determines that the Nil FEC corresponds to RSVP-A (which terminates at D), then it SHOULD respond with Return Code 3. D can also respond with a FEC stack change sub-TLV: Pop (since D knows the number of labels towards the next-hop is going down). Both responses would be valid. ✅
A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP
\_____________/
LDPFigure 9: Stitched Hierarchical LSPs
in the case above, node D sends three FEC stack change sub-TLVs: one Pop (for the BGP FEC) followed by two Pushes (one for LDP and one for RSVP) 🎉. Nodes C and D SHOULD set the Return Code to "Label switched with FEC change" (Section 6.3) to show the FEC being traced has changed. 🌈💅
4.1.3. Modification to FEC Validation Procedure on Transit ✨
okay so Section 4.4 of [RFC4379] is where the Target FEC stack validation rules live, and this bit gives them a glow-up 💅 Specifically, if the outermost FEC of the target FEC stack is the Nil FEC, then the node MUST skip the target FEC validation completely 🙈 Why? It's all about FEC hiding, where that outer hidden FEC can be the Nil FEC 🫶
4.2. Modification to FEC Validation Procedure on Egress 🎀
same energy as 4.1.3, but for the egress node 💜 Section 4.4 of [RFC4379] is still the source of the Target FEC stack validation procedures, and this doc enhances them. If the outermost FEC of the Target FEC stack is the Nil FEC, the node MUST skip the target FEC validation completely. Again, this is so FEC hiding works, where the outer hidden FEC can be the Nil FEC 🦋
4.3. Ingress Node Procedure 👑
bestie, the ingress node has a big job. When it does an MPLS traceroute, it has to understand tunnel within tunnel semantics AND LSP stitching semantics 🧠 This section walks through what the ingress node does depending on the kind of reply it gets back from a transit node 🍓
4.3.1. Processing Downstream Detailed Mapping TLV 🌸
the Downstream Detailed Mapping TLV should be processed the same way as the Downstream Mapping TLV, which is defined in Section 4.4 of [RFC4379] ✨ This section covers the new stuff this document introduces.
4.3.1.1. Stack Change Sub-TLV Not Present 🙃
this is just the default behavior from [RFC4379] 🥱 The ingress node MUST perform MPLS echo reply processing as per the procedures in [RFC4379].
4.3.1.2. Stack Change Sub-TLV(s) Present 🔥
okay this is where it gets spicy 🌶️ If one or more FEC stack change sub-TLVs (Section 3.3.1.3) show up in the MPLS echo reply, the ingress node SHOULD process them and do some validation.
The FEC stack changes are tied to a downstream neighbor and to one particular path of the LSP. So the ingress needs to keep a FEC stack for each path it's tracing (for multipath, that's a lot of stacks 🧚). Any changes from processing the FEC stack change sub-TLV(s) should only be applied to the path along a given downstream neighbor. Here's the algorithm that should be followed:
push_seen = FALSE
fec_stack_depth = current-depth-of-fec-stack-being-traced
saved_fec_stack = current_fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
if (sub-tlv == NULL) break
if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Pop FEC from FEC stack being traced
fec_stack_depth--;
}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Figure 10: FEC Stack Change Sub-TLV Processing GuidelineThe next MPLS echo request along the same path should use the modified FEC stack you get after processing the FEC stack change sub-TLVs 💖 A non-Nil FEC guarantees that the next echo request along the same path gets its Downstream Detailed Mapping TLV validated for IP address, Interface address, and label stack mismatches 🛡️
⚠️ Nil FECs are a bit of a trap. If the top of the FEC stack is a Nil FEC and the MPLS echo reply has no FEC stack change sub-TLVs, that does NOT automatically mean the LSP stopped traversing a different tunnel 😭 The LSP tied to the Nil FEC might have ended at a transit node while a brand new LSP started at that same node. The Nil FEC would now belong to the new LSP, and the ingress has no way of knowing. So if a traceroute has Nil FECs in it, you can't build an accurate hierarchical LSP topology. Sad, but true.
4.3.2. Modifications to Handling a Return Code 3 Reply. 🎭
the procedures above let new FECs get added to the original FEC being traced. Which means a reply from a downstream node with Return Code 3 (IS_EGRESS) might not be for the FEC being traced. It could be for one of the new FECs that got added 🌀 When the LSP ingress gets an IS_EGRESS reply, it should check whether the depth of the Target FEC it sent to the node that just responded was the same as the depth of the FEC being traced. If it wasn't, the ingress should pop an entry from the Target FEC stack and resend the request with the same TTL it used before. It keeps popping FECs until either the LSP ingress gets a non-IS_EGRESS reply, or all the extra FECs that were added have already been popped 🫧 With IS_EGRESS replies, an ingress can map out the hierarchical LSP structure that a given FEC travels through 🗺️
4.3.3. Handling of New Return Codes 🆕
when the MPLS echo reply Return Code is "Label switched with FEC change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC stack according to the FEC stack change sub-TLVs inside the downstream detailed mapping TLV ✨ A transit node can use this Return Code for stitched LSPs and for hierarchical LSPs. With ECMP or P2MP, there could be several paths, and Downstream Detailed Mapping TLVs with different Return Codes (Section 3.2.1). The ingress node should build the topology based on the Return Code for each ECMP path or P2MP branch 🌈
4.4. Handling Deprecated Downstream Mapping TLV 🥀
the Downstream Mapping TLV is deprecated now, so applications should switch to the Downstream Detailed Mapping TLV 🙌 The following procedures SHOULD be used for backward compatibility with routers that don't support the Downstream Detailed Mapping TLV:
- The Downstream Mapping TLV and the Downstream Detailed Mapping TLV MUST never be sent together in the same MPLS echo request or in the same MPLS echo reply 🚫
- If the echo request has a Downstream Detailed Mapping TLV and the matching echo reply has a Return Code 2 ("One or more of the TLVs was not understood"), the sender of the echo request MAY resend it with the Downstream Mapping TLV (instead of the Downstream Detailed Mapping TLV). When a detailed reply is actually needed, the sender can choose to ignore the router that doesn't support the Downstream Detailed Mapping TLV 🤷♀️
- If the echo request has a Downstream Mapping TLV, then a Downstream Detailed Mapping TLV MUST NOT be sent in the echo reply. This covers the case where the sender of the echo request doesn't support the new TLV. The echo reply MAY contain Downstream Mapping TLV(s) 💅
- If echo request forwarding is in use (so the echo request gets processed at an intermediate LSR and then forwarded on), the intermediate router is responsible for making sure the TLVs being used among the ingress, intermediate and destination are consistent. The intermediate router MUST NOT forward an echo request or an echo reply containing a Downstream Detailed Mapping TLV if it doesn't support that TLV itself 🛑
5. Security Considerations 🔐
okay bestie, this part is serious, so let's be real 🫶
- If a network operator wants to stop tracing inside a tunnel, they can use the Pipe Model [RFC3443], i.e., hide the outer MPLS tunnel by not propagating the MPLS TTL into the outer tunnel (at the start of the outer tunnel). Doing this means MPLS traceroute packets won't expire in the outer tunnel, so the outer tunnel won't get traced 🕵️♀️
- If someone doesn't want to expose the details of the new outer LSP, the Nil FEC can hide those details 🙈 Using the Nil FEC keeps the trace going without false negatives, and all transit nodes (of the new outer tunnel) still do some minimal validations on the received MPLS echo requests 🧱
Other security considerations, as discussed in [RFC4379], are also applicable to this document.
6. IANA Considerations 📋
6.1. New TLV 🎀
IANA has assigned a TLV type value to the following TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry 💜
Downstream Detailed Mapping TLV (see Section 3.3): 20.
6.2. New Sub-TLV Types and Associated Registry 🧁
IANA has registered the Sub-Type field of Downstream Detailed Mapping TLV. The valid range is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in [RFC3692]. Assignments in the range 16384-31743 and 49162-64511 are made via Specification Required [RFC4379]. Values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. If a sub-TLV has a Type in the Vendor Private Use range, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Enterprise Code, in network octet order. The rest of the Value field is private to the vendor 🔒
IANA has assigned the following sub-TLV types (see Section 3.3.1):
- Multipath data: 1
- Label stack: 2
- FEC stack change: 3
6.3. New Return Codes 🆕
IANA has assigned new Return Code values from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry, as follows, using a Standards Action value ✨
Value Meaning
----- -------
14 See DDM TLV for Return Code and Return Subcode
15 Label switched with FEC change7. Acknowledgements 🫶
the authors want to thank Yakov Rekhter and Adrian Farrel for their suggestions on the document 💖
8. References 📚
8.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
8.2. Informative References
- [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
- [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
- [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
- [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
- [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
Authors' Addresses ✨
okay bestie, the squad behind this doc gets their own little contact cards now 💖 these are the people who wrote it, so you can reach out if you have questions 🫶
Nitin Bahadur is at Juniper Networks, 1194 N. Mathilda Avenue, Sunnyvale, CA 94089 🌸
Nitin Bahadur
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
EMail: nitinb@juniper.net
URI: www.juniper.netKireeti Kompella is also at Juniper Networks, same address, same phone number, same URI, different inbox 🦋
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
URI: www.juniper.netAnd George Swallow is over at Cisco Systems in Boxborough, MA, with no phone number listed, just email and web 🧚
George Swallow
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719
US
EMail: swallow@cisco.com
URI: www.cisco.comThat's the whole doc, bestie! 🎀💅 Three authors, two companies, zero cap. Iconic teamwork 👑
📦 where this page comes from
- ietf: rfc6424 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms