diff options
Diffstat (limited to 'doc/rfc/rfc6424.txt')
| -rw-r--r-- | doc/rfc/rfc6424.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc6424.txt b/doc/rfc/rfc6424.txt new file mode 100644 index 0000000..28af3a2 --- /dev/null +++ b/doc/rfc/rfc6424.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Bahadur +Request for Comments: 6424 K. Kompella +Updates: 4379 Juniper Networks, Inc. +Category: Standards Track G. Swallow +ISSN: 2070-1721 Cisco Systems + November 2011 + + + Mechanism for Performing Label Switched Path Ping (LSP Ping) + over MPLS Tunnels + +Abstract + + This document describes methods for performing LSP ping (specified in + RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched + MPLS Label Switched Paths (LSPs). The techniques outlined in RFC + 4379 are insufficient to perform traceroute Forwarding Equivalency + Class (FEC) validation and path discovery for an LSP that goes over + other MPLS tunnels or for a stitched LSP. This document deprecates + the Downstream Mapping TLV (defined in RFC 4379) in favor of a new + TLV that, along with other procedures outlined in this document, can + be used to trace such LSPs. + +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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6424. + + + + + + + + + + + + + + + +Bahadur, et al. Standards Track [Page 1] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + +Bahadur, et al. Standards Track [Page 2] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +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 . . . . . . . . . . . . . . . . . . 22 + + + + + + + + + + + + + + + + + + +Bahadur, et al. Standards Track [Page 3] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +1. Introduction + + This documents describes methods for performing LSP ping (specified + in [RFC4379]) traceroute over MPLS tunnels. The techniques in + [RFC4379] outline a traceroute mechanism that includes Forwarding + Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP) + path discovery. Those mechanisms are insufficient and do not provide + details when the FEC being traced traverses one or more MPLS tunnels + and when Label Switched Path (LSP) stitching [RFC5150] is in use. + This document deprecates the Downstream Mapping TLV [RFC4379], + introducing instead a new TLV that is more extensible and that + enables retrieval of detailed information. Using the new TLV format + along with the existing definitions of [RFC4379], this document + describes procedures by which a traceroute request can correctly + traverse MPLS tunnels with proper FEC and label validations. + +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 en route to + the destination. Let us consider a simple case. + + A B C D E + o -------- o -------- o --------- o --------- o + \_____/ | \______/ \______/ | \______/ + LDP | RSVP RSVP | LDP + | | + \____________________/ + LDP + + Figure 1: LDP over RSVP Tunnel + + When a traceroute is initiated from router A, router B returns + downstream mapping information 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 does not run LDP. Node C will receive the + MPLS echo request with two labels but only one FEC in the Target FEC + stack. Consequently, node C will be unable to perform a complete FEC + validation. It will let the trace continue by just providing next- + hop information based on the incoming label, and by looking up the + forwarding state associated with that label. However, ignoring FEC + validation defeats the purpose of control-plane validations. The + + + + +Bahadur, et al. Standards Track [Page 4] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + MPLS echo request should contain sufficient information to allow node + C to perform FEC validations to catch any misrouted echo requests. + + The above problem can be extended for a generic case of hierarchical + tunnels or stitched tunnels (e.g., B-C can be a separate RSVP tunnel + and C-D can be a separate RSVP tunnel). The problem of FEC + validation for tunnels can be solved if the transit routers (router B + in the above example) provide some information to the ingress + regarding the start of a new tunnel. + + Stitched LSPs involve two or more LSP segments stitched together. + The LSP segments can be signaled using the same or different + signaling protocols. In order to perform an end-to-end trace of a + stitched LSP, the ingress needs to know FEC information regarding + each of the stitched LSP segments. For example, consider the figure + below. + + A B C D E F + o -------- o -------- o --------- o -------- o ------- o + \_____/ \______/ \______/ \______/ \_______/ + LDP LDP BGP RSVP RSVP + + Figure 2: Stitched LSP + + Consider ingress (A) tracing end-to-end stitched LSP A--F. When an + MPLS echo request reaches router C, there is a FEC stack change + happening at router C. With current LSP ping [RFC4379] mechanisms, + there is no way to convey this information to A. Consequently, when + the next echo request reaches router D, router D will know nothing + about the LDP FEC that A is trying to trace. + + Thus, the procedures defined in [RFC4379] do not make it possible for + the ingress node to: + + 1. Know that tunneling has occurred. + + 2. Trace the path of the tunnel. + + 3. Trace the path of stitched LSPs. + +3. Packet Format + +3.1. Summary of Changes + + In many cases, there is a need to associate additional data in the + MPLS echo reply. In most cases, the additional data needs to be + associated on a per-downstream-neighbor basis. Currently, the MPLS + echo reply contains one Downstream Mapping TLV (DSMAP) per downstream + + + +Bahadur, et al. Standards Track [Page 5] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + neighbor. However, the DSMAP format is not extensible; hence, it is + not possible to associate more information with a downstream + neighbor. This document defines a new extensible format for the + DSMAP and provides mechanisms for solving the tunneled LSP ping + problem using the new format. In summary, this document makes the + following TLV changes: + + o Addition of new Downstream Detailed Mapping TLV (DDMAP). + + o Deprecation of existing Downstream Mapping TLV (DSMAP). + + o 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 indicate 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 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. + +3.2.2. Return Code for Stitched LSPs + + When a traceroute is being performed on stitched LSPs + (Section 4.1.2), the stitching point SHOULD indicate the stitching + action to the node performing the trace. This is done by setting the + Return Code to "Label switched with FEC change" (Section 6.3). If a + node is performing FEC hiding, then it MAY choose to set the Return + Code to a value (specified in [RFC4379]) other than "Label switched + with FEC change". The Return Code "Label switched with FEC change" + MUST NOT be used if no FEC stack sub-TLV (Section 3.3.1.3) is present + in the Downstream Detailed Mapping TLV(s). This new Return Code MAY + be used for hierarchical LSPs (for indicating the start or end of an + outer LSP). + + + + + + + +Bahadur, et al. Standards Track [Page 6] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +3.3. Downstream Detailed Mapping TLV + + Type # Value Field + ------ ------------ + + 20 Downstream Detailed Mapping + + The 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. The presence of a + Downstream Detailed Mapping object is a request that Downstream + Detailed Mapping objects be included 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. 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 TLV + + The Downstream Detailed Mapping TLV format is derived from the + Downstream Mapping TLV format. The key change is that variable + length and optional fields have been converted into sub-TLVs. The + fields have the same use and meaning as in [RFC4379]. A summary of + the fields taken from the Downstream Mapping TLV is as below: + + 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). + + + + +Bahadur, et al. Standards Track [Page 7] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + Address Type + + The Address Type indicates if the interface is numbered or + unnumbered. It also determines 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; IPv6 + addresses are encoded in 16 octets. For details regarding setting + the address value, refer to [RFC4379]. + + The newly added sub-TLVs and their fields are as described below. + + Return Code + + The Return Code is set to zero by the sender. The receiver can + set it to one of the values specified 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 of the Return Code field in + 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). An exception + to this is 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 specified in the "Multi-Protocol Label + Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" + registry, "Return Codes" sub-registry. This field is 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. + + + +Bahadur, et al. Standards Track [Page 8] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + 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 change + +3.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-TLV + + The multipath data sub-TLV includes Multipath Information. The sub- + TLV fields and their usage is as defined in [RFC4379]. A brief + summary of the fields is as below: + + Multipath Type + + The type of the encoding for the Multipath Information. + + Multipath Length + + The length in octets of the Multipath Information. + + + + + +Bahadur, et al. Standards Track [Page 9] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + 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-TLV + + The Label stack sub-TLV contains the set of labels in the label stack + as it would have appeared if this router were forwarding the packet + through this interface. Any Implicit Null labels are explicitly + included. The number of label/protocol pairs present in the sub-TLV + is determined based on 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, i.e., 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; the LSR receiving the echo + reply MAY choose to ignore these. + + Protocol + + This specifies the label distribution protocol for the Downstream + label. + + + + + +Bahadur, et al. Standards Track [Page 10] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +3.3.1.3. FEC Stack Change Sub-TLV + + A router MUST include the FEC stack change sub-TLV when the + downstream node in the echo reply has a different FEC Stack than the + FEC Stack received in the echo request. One or more FEC stack change + sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The + format is as below. + + 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 + + The operation type specifies the action associated with the FEC + stack change. The following operation types are defined: + + + Type # Operation + ------ --------- + 1 Push + 2 Pop + + Address Type + + The Address Type indicates the remote peer's address type. The + Address Type is set to one of the following values. The length of + the peer address is determined based on the address type. The + address type MAY be different from the address type included in + the Downstream Detailed Mapping TLV. This can happen when the LSP + goes over a tunnel of a different address family. The address + type MAY be set to Unspecified if the peer address is either + unavailable or the transit router does not wish to provide it for + security or administrative reasons. + + + + + + + +Bahadur, et al. Standards Track [Page 11] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + Type # Address Type Address length + ------ ------------ -------------- + + 0 Unspecified 0 + 1 IPv4 4 + 2 IPv6 16 + + FEC TLV Length + + Length in bytes of the FEC TLV. + + Reserved + + This field is reserved for future use and MUST be set to zero. + + Remote Peer Address + + The remote peer address specifies the remote peer that is the + next-hop for the FEC being currently traced. For example, in the + LDP over RSVP case in Figure 1, router B would respond back with + the address of router D as the remote peer address for the LDP FEC + being traced. This allows the ingress node to provide information + regarding FEC peers. If the operation type is PUSH, the remote + peer address is the address of the peer from which the FEC being + pushed was learned. If the operation type is POP, the remote peer + address MAY be set to Unspecified. + + For upstream-assigned labels [RFC5331], an operation type of POP + 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 present only when the FEC-tlv length field is non- + zero. The FEC TLV specifies the FEC associated with the FEC stack + change operation. This TLV MAY be included when the operation + type is POP. It MUST be included when the operation type is PUSH. + The FEC TLV contains exactly one FEC from the list of FECs + specified in [RFC4379]. A Nil FEC MAY be associated with a PUSH + operation if the responding router wishes to hide the details of + the FEC being pushed. + + + + + + + + +Bahadur, et al. Standards Track [Page 12] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + FEC stack change sub-TLV operation rules are as follows: + + a. A FEC stack change sub-TLV containing a PUSH operation MUST NOT + be followed by a FEC stack change sub-TLV containing 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 (an operation where one FEC ends and + another FEC starts, see Figure 7) MUST be performed 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 containing only one FEC stack + change sub-TLV with Pop operation is equivalent to IS_EGRESS + (Return Code 3, [RFC4379]) for the outermost FEC in the FEC + stack. The ingress router performing the MPLS traceroute MUST + treat such a case as an IS_EGRESS for the outermost FEC. + +3.4. Deprecation of Downstream Mapping TLV + + This document deprecates the Downstream Mapping TLV. LSP ping + procedures should now use the Downstream Detailed Mapping TLV. + Detailed procedures regarding interoperability between the deprecated + TLV and the new TLV are specified in Section 4.4. + +4. Performing MPLS Traceroute on Tunnels + + This section describes the procedures to be followed by an LSP + ingress node and LSP transit nodes when performing 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 going to + enter a tunnel at that node. Thus, it knows about the new outer FEC. + All transit nodes that are the origination point of 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. The + transit node SHOULD add one FEC stack change sub-TLV of operation + type PUSH, per new tunnel being originated at the transit node. + + + +Bahadur, et al. Standards Track [Page 13] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + A transit node that sends a Downstream FEC stack change sub-TLV in + the echo reply SHOULD fill the address of the remote peer; which is + the peer of the current LSP being traced. If the transit node does + not know the address of the remote peer, 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 per 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, i.e. the data-plane trace + will not 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 corresponding to the hidden tunnel. + + If the transit node wishes to hide the nature of the tunnel from the + ingress of the echo request, then it MAY not want to send details + about the new tunnel FEC to the ingress. In such a 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, per + new tunnel being originated at the 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 RSVP + + Figure 7: Stitched LSPs + + In the above figure, we have three separate LSP segments stitched 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 the PUSH operation + for the BGP FEC. Similarly, node D 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 + indicate change in FEC being traced. + + If node C wishes to perform FEC hiding, it SHOULD respond back with + two FEC stack change sub-TLVs, one POP followed by one PUSH. The POP + operation MAY either exclude the FEC TLV (by setting the FEC TLV + length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH + + + +Bahadur, et al. Standards Track [Page 14] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + 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 performs FEC hiding and node D also performs FEC hiding, + then node D MAY choose to not send any FEC stack change sub-TLVs in + the echo reply since the number of labels has not changed (for the + downstream of node D) and the FEC type also has not changed (Nil + FEC). In such a case, node D MUST NOT set the Return Code to "Label + switched with FEC change". If node D performs FEC hiding, then node + F will respond as IS_EGRESS for the Nil FEC. 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 | + \________________________________/ + LDP + + Figure 8: Hierarchical LSPs + + In the above figure, we have an end-to-end LDP LSP between nodes A + and F. The LDP LSP goes over RSVP LSP RSVP-B. LSP RSVP-B itself + goes over another RSVP LSP RSVP-A. When node A initiates a + traceroute for the end-to-end LDP LSP, then following sequence of FEC + stack change sub-TLVs will be performed + + 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 FEC stack. When + the echo request contains RSVP-B as top of stack, respond with + Downstream information for node E and an appropriate Return Code. + + + + + + + + + + + + + +Bahadur, et al. Standards Track [Page 15] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + If node B is performing 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 FEC stack change sub-TLV: POP (since D knows that + number of labels towards next-hop is decreasing). 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 + \_____________/ + LDP + + Figure 9: Stitched Hierarchical LSPs + + In the above case, node D will send 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 indicate change in FEC + being traced. + +4.1.3. Modification to FEC Validation Procedure on Transit + + Section 4.4 of [RFC4379] specifies Target FEC stack validation + procedures. This document enhances the FEC validation procedures as + follows. If the outermost FEC of the target FEC stack is the Nil + FEC, then the node MUST skip the target FEC validation completely. + This is to support FEC hiding, in which the outer hidden FEC can be + the Nil FEC. + +4.2. Modification to FEC Validation Procedure on Egress + + Section 4.4 of [RFC4379] specifies Target FEC stack validation + procedures. This document enhances the FEC validation procedures as + follows. If the outermost FEC of the Target FEC stack is the Nil + FEC, then the node MUST skip the target FEC validation completely. + This is to support FEC hiding, in which the outer hidden FEC can be + the Nil FEC. + + + + + +Bahadur, et al. Standards Track [Page 16] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +4.3. Ingress Node Procedure + + It is the responsibility of an ingress node to understand tunnel + within tunnel semantics and LSP stitching semantics when performing a + MPLS traceroute. This section describes the ingress node procedure + based on the kind of reply an ingress node receives from a transit + node. + +4.3.1. Processing Downstream Detailed Mapping TLV + + Downstream Detailed Mapping TLV should be processed in the same way + as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379]. + This section describes the procedures for processing the new elements + introduced in this document. + +4.3.1.1. Stack Change Sub-TLV Not Present + + This would be the default behavior as described in [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 + + If one or more FEC stack change sub-TLVs (Section 3.3.1.3) are + received in the MPLS echo reply, the ingress node SHOULD process them + and perform some validation. + + The FEC stack changes are associated with a downstream neighbor and + along a particular path of the LSP. Consequently, the ingress will + need to maintain a FEC stack per path being traced (in case of + multipath). All changes to the FEC stack resulting from the + processing of FEC stack change sub-TLV(s) should be applied only for + the path along a given downstream neighbor. The following algorithm + should be followed for processing FEC stack change sub-TLVs. + + + + + + + + + + + + + + + + + +Bahadur, et al. Standards Track [Page 17] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + 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 Guideline + + + + + + + + +Bahadur, et al. Standards Track [Page 18] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + The next MPLS echo request along the same path should use the + modified FEC stack obtained after processing the FEC stack change + sub-TLVs. A non-Nil FEC guarantees that the next echo request along + the same path will have the Downstream Detailed Mapping TLV validated + for IP address, Interface address, and label stack mismatches. + + If the top of the FEC stack is a Nil FEC and the MPLS echo reply does + not contain any FEC stack change sub-TLVs, then it does not + necessarily mean that the LSP has not started traversing a different + tunnel. It could be that the LSP associated with the Nil FEC + terminated at a transit node and at the same time a new LSP started + at the same transit node. The Nil FEC would now be associated with + the new LSP (and the ingress has no way of knowing this). Thus, it + is not possible to build an accurate hierarchical LSP topology if a + traceroute contains Nil FECs. + +4.3.2. Modifications to Handling a Return Code 3 Reply. + + The procedures above allow the addition of new FECs to the original + FEC being traced. Consequently, a reply from a downstream node with + Return Code 3 (IS_EGRESS) may not necessarily be for the FEC being + traced. It could be for one of the new FECs that was added. On + receipt of an IS_EGRESS reply, the LSP ingress should check if the + depth of Target FEC sent to the node that just responded, was the + same as the depth of the FEC that was being traced. If it was not, + then it should pop an entry from the Target FEC stack and resend the + request with the same TTL (as previously sent). The process of + popping a FEC is to be repeated until either the LSP ingress receives + a non-IS_EGRESS reply or until all the additional FECs added to the + FEC stack have already been popped. Using an IS_EGRESS reply, an + ingress can build a map of the hierarchical LSP structure traversed + by a given FEC. + +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 as per the FEC stack change sub-TLVs contained in the + downstream detailed mapping TLV. A transit node can use this Return + Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or + P2MP, there could be multiple 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 per ECMP path/P2MP + branch. + + + + + + + +Bahadur, et al. Standards Track [Page 19] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +4.4. Handling Deprecated Downstream Mapping TLV + + The Downstream Mapping TLV has been deprecated. Applications should + now use the Downstream Detailed Mapping TLV. The following + procedures SHOULD be used for backward compatibility with routers + that do not support the Downstream Detailed Mapping TLV. + + o 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. + + o If the echo request contains a Downstream Detailed Mapping TLV and + the corresponding echo reply contains a Return Code 2 ("One or + more of the TLVs was not understood"), then the sender of the echo + request MAY resend the echo request with the Downstream Mapping + TLV (instead of the Downstream Detailed Mapping TLV). In cases + where a detailed reply is needed, the sender can choose to ignore + the router that does not support the Downstream Detailed Mapping + TLV. + + o If the echo request contains a Downstream Mapping TLV, then a + Downstream Detailed Mapping TLV MUST NOT be sent in the echo + reply. This is to handle the case that the sender of the echo + request does not support the new TLV. The echo reply MAY contain + Downstream Mapping TLV(s). + + o If echo request forwarding is in use (such that the echo request + is processed at an intermediate LSR and then forwarded on), then + the intermediate router is responsible for making sure that 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 itself does not support that TLV. + +5. Security Considerations + + 1. If a network operator wants to prevent tracing inside a tunnel, + one 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). By doing this, MPLS traceroute + packets will not expire in the outer tunnel and the outer tunnel + will not get traced. + + 2. If one doesn't wish to expose the details of the new outer LSP, + then the Nil FEC can be used to hide those details. Using the + Nil FEC ensures that the trace progresses without false negatives + and all transit nodes (of the new outer tunnel) perform some + minimal validations on the received MPLS echo requests. + + + +Bahadur, et al. Standards Track [Page 20] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + + 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 for this 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 that falls in the range for + Vendor Private Use, 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 change + + + + + +Bahadur, et al. Standards Track [Page 21] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +7. Acknowledgements + + The authors would like 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. + + + + + + + + + + +Bahadur, et al. Standards Track [Page 22] + +RFC 6424 LSP Ping over MPLS Tunnels November 2011 + + +Authors' Addresses + + 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.net + + + 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.net + + + George Swallow + Cisco Systems + 1414 Massachusetts Ave + Boxborough, MA 01719 + US + + EMail: swallow@cisco.com + URI: www.cisco.com + + + + + + + + + + + + + + + + + + + +Bahadur, et al. Standards Track [Page 23] + |