draft-ietf-mpls-lsp-ping-enhanced-dsmap-08.txt   draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt 
Network Working Group N. Bahadur Network Working Group N. Bahadur
Internet-Draft K. Kompella Internet-Draft K. Kompella
Updates: 4379 (if approved) Juniper Networks, Inc. Updates: 4379 (if approved) Juniper Networks, Inc.
Intended status: Standards Track G. Swallow Intended status: Standards Track G. Swallow
Expires: August 2, 2011 Cisco Systems Expires: November 14, 2011 Cisco Systems
January 29, 2011 May 13, 2011
Mechanism for performing LSP-Ping over MPLS tunnels Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-08 draft-ietf-mpls-lsp-ping-enhanced-dsmap-09
Abstract Abstract
This document describes methods for performing lsp-ping traceroute This document describes methods for performing LSP Ping (specified in
over mpls tunnels and for traceroute of stitched mpls LSPs. The RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched
techniques outlined in RFC 4379 are insufficient to perform MPLS label-switched-paths (LSPs). The techniques outlined in RFC
traceroute FEC validation and path discovery for a LSP that goes over 4379 are insufficient to perform traceroute Forwarding Equivalency
other mpls tunnels or for a stitched LSP. This document describes Class (FEC) validation and path discovery for a LSP that goes over
other MPLS tunnels or for a stitched LSP. This document describes
enhancements to the downstream-mapping TLV (defined in RFC 4379). enhancements to the downstream-mapping TLV (defined in RFC 4379).
These enhancements along with other procedures outlined in this These enhancements along with other procedures outlined in this
document can be used to trace such LSPs. document can be used to trace such LSPs.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2011. This Internet-Draft will expire on November 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6 3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Return code per downstream . . . . . . . . . . . . . . 6 3.2.1. Return code per downstream . . . . . . . . . . . . . . 6
3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 6 3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 6
3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 6 3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 7
3.3.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 8 3.3.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 9 3.3.1.1. Multipath data sub-TLV . . . . . . . . . . . . . . 9
3.3.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 9 3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 13
3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 12 4. Performing MPLS traceroute on tunnels . . . . . . . . . . . . 13
4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 12 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 13
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 12 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 13
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 12 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 14
4.1.2. Transition between tunnels . . . . . . . . . . . . . . 13 4.1.3. Modification to FEC Validation procedure on Transit . 16
4.1.3. Modification to FEC Validation procedure on Transit . 15 4.2. Modification to FEC Validation procedure on Egress . . . . 16
4.2. Modification to FEC Validation procedure on Egress . . . . 15 4.3. Ingress node procedure . . . . . . . . . . . . . . . . . . 16
4.3. Ingress node procedure . . . . . . . . . . . . . . . . . . 15 4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17
4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 15 4.3.1.1. Stack Change sub-TLV not present . . . . . . . . . 17
4.3.1.1. Stack Change sub-TLV not present . . . . . . . . . 15 4.3.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 17
4.3.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 16 4.3.2. Modifications to handling to Return Code 3
4.3.2. Modifications to handling to EGRESS_OK responses. . . 18 responses. . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3. Handling of new return codes . . . . . . . . . . . . . 18 4.3.3. Handling of new return codes . . . . . . . . . . . . . 19
4.4. Handling deprecated Downstream Mapping TLV . . . . . . . . 18 4.4. Handling deprecated Downstream Mapping TLV . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This documents describes methods for performing lsp-ping traceroute This documents describes methods for performing LSP ping (specified
over mpls tunnels. The techniques outlined in [RFC4379] outline a in [RFC4379] traceroute over MPLS tunnels. The techniques in
traceroute mechanism that includes FEC validation and ECMP path [RFC4379] outline a traceroute mechanism that includes Forwarding
discovery. Those mechanisms are insufficient and do not provide Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP)
details in case the FEC being traced traverses one or more mpls path discovery. Those mechanisms are insufficient and do not provide
tunnels and in case where LSP stitching is in use. This document details in case the FEC being traced traverses one or more MPLS
defines enhancements to the downstream-mapping TLV [RFC4379] to make tunnels and in case where label-switched-path (LSP) stitching is in
it more extensible and to enable retrieval of detailed information. use. This document defines enhancements to the downstream-mapping
Using the enhanced TLV format along with the existing definitions of TLV [RFC4379] to make it more extensible and to enable retrieval of
[RFC4379], this document describes procedures by which a traceroute detailed information. Using the enhanced TLV format along with the
request can correctly traverse mpls tunnels with proper FEC and label existing definitions of [RFC4379], this document describes procedures
validations. by which a traceroute request can correctly traverse MPLS tunnels
with proper FEC and label validations.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Motivation 2. Motivation
A LSP-Ping traceroute may cross multiple mpls tunnels en-route the A LSP-Ping traceroute may cross multiple MPLS tunnels en-route the
destination. Let us consider a simple case. destination. Let us consider a simple case.
A B C D E A B C D E
o -------- o -------- o --------- o --------- o o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/ \_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP LDP | RSVP RSVP | LDP
| | | |
\____________________/ \____________________/
LDP LDP
Figure 1: LDP over RSVP tunnel Figure 1: LDP over RSVP tunnel
When a traceroute is initiated from router A, router B returns When a traceroute is initiated from router A, router B returns
downstream mapping information for node C in the echo-response. The downstream mapping information for node C in the MPLS echo response.
next echo request reaches router C with a LDP FEC. Node C is a pure The next MPLS echo request reaches router C with a LDP FEC. Node C
RSVP node and does not run LDP. Node C will receive the packet with is a pure RSVP node and does not run LDP. Node C will receive the
2 labels but only 1 FEC in the Target FEC stack. Consequently, node MPLS echo request with 2 labels but only 1 FEC in the Target FEC
C will be unable to perform FEC complete validation. It will let the stack. Consequently, node C will be unable to perform FEC complete
trace continue by just providing next-hop information based on validation. It will let the trace continue by just providing next-
incoming label, and by looking up the forwarding state associated hop information based on incoming label, and by looking up the
with that label. However, ignoring FEC validation defeats the forwarding state associated with that label. However, ignoring FEC
purpose of control plane validatations. The echo request should validation defeats the purpose of control plane validatations. The
contain sufficient information to allow node C to perform FEC MPLS echo request should contain sufficient information to allow node
validations to catch any misrouted echo-requests. C to perform FEC validations to catch any misrouted echo-requests.
The above problem can be extended for a generic case of tunnel over The above problem can be extended for a generic case of hierarchical
tunnel or multiple tunnels (e.g. B-C can be a separate RSVP tunnel 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 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 validation for tunnels can be solved if the transit routers (router B
in the above example) provide some hint or information to the ingress in the above example) provide some information to the ingress
regarding the start of a new tunnel. regarding the start of a new tunnel.
Stitched LSPs involve 2 or more LSP segments stitched together. The Stitched LSPs involve 2 or more LSP segments stitched together. The
LSP segments can be signaled using the same or different signaling LSP segments can be signaled using the same or different signaling
protocols. In order to perform an end-to-end trace of a stitched 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 LSP, the ingress needs to know FEC information regarding each of the
stitched LSP segments. For example, conside the figure below. stitched LSP segments. For example, consider the figure below.
A B C D E F A B C D E F
o -------- o -------- o --------- o -------- o ------- o o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/ \_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP LDP LDP BGP RSVP RSVP
Figure 2: Stitched LSP Figure 2: Stitched LSP
Consider ingress (A) tracing end-to-end LSP A--F. When an echo Consider ingress (A) tracing end-to-end stitched LSP A--F. When an
request reaches router C, there is a FEC stack change happening at MPLS echo request reaches router C, there is a FEC stack change
router C. With current lsp-ping mechanisms, there is no way to convey happening at router C. With current LSP Ping [[RFC4379]] mechanisms,
this information to A. Consequently, when the next echo request there is no way to convey this information to A. Consequently, when
reaches router D, router D will know nothing about the LDP FEC that A the next echo request reaches router D, router D will know nothing
is trying to trace. about the LDP FEC that A is trying to trace.
Thus, the procedures outlined [RFC4379] do not make it possible for Thus, the procedures defined in [RFC4379] do not make it possible for
the ingress node to: the ingress node to:
1. Know that tunneling has occured 1. Know that tunneling has occured
2. Trace the path of the tunnel 2. Trace the path of the tunnel
3. Trace the path of stitched LSPs 3. Trace the path of stitched LSPs
3. Packet format 3. Packet format
3.1. Introduction 3.1. Introduction
In many cases there has been a need to associate additional data in In many cases there has been a need to associate additional data in
the lsping echo response. In most cases, the additional data needs the MPLS echo response. In most cases, the additional data needs to
to be associated on a per downstream neighbor basis. Currently, the be associated on a per downstream neighbor basis. Currently, the
echo response contains 1 downstream map TLV (DSMAP) per downstream MPLS echo response contains one downstream map TLV (DSMAP) per
neighbor. But the DSMAP format is not extensible and hence it's not downstream neighbor. However the DSMAP format is not extensible and
possible to associate more information with a downstream neighbor. hence it is not possible to associate more information with a
This draft defines a new extensible format for the DSMAP and provides downstream neighbor. This draft defines a new extensible format for
mechanisms for solving the tunneled lsp-ping problem using the new the DSMAP and provides mechanisms for solving the tunneled LSP Ping
format. In summary, the draft makes the following TLV changes: problem using the new format. In summary, the draft makes the
following TLV changes:
o Addition of new Downstream Detailed Mapping TLV (DDMAP). o Addition of new Downstream Detailed Mapping TLV (DDMAP).
o Deprecation of existing Downstream Mapping TLV. o Deprecation of existing Downstream Mapping TLV (DSMAP).
o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP. o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP.
3.2. New Return Codes 3.2. New Return Codes
3.2.1. Return code per downstream 3.2.1. Return code per downstream
A new Return Code is being defined "See DDM TLV for Return Code and 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 Return SubCode" (Section 6.3) to indicate that the Return Code is per
Downstream Detailed Mapping TLV (Section 3.3). This Return Code MUST 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 echo be used only in the message header and MUST be set only in the MPLS
response message. If the Return Code is set in the echo request echo response message. If the Return Code is set in the MPLS echo
message, then it SHOULD be ignored. When this Return Code is set, request message, then it MUST be ignored. When this Return Code is
each Downstream Detailed Mapping TLV MUST have an appropriate Return set, each Downstream Detailed Mapping TLV MUST have an appropriate
Code and Return SubCode. This Return Code is to be used when there Return Code and Return SubCode. This Return Code is to be used when
are multiple downstreams for a given node (such as P2MP or ECMP), and there are multiple downstreams for a given node (such as P2MP or
the node wants to return a different Return Code/Return SubCode for ECMP), and the node needs to return a different Return Code/Return
each downstream. SubCode for each downstream.
3.2.2. Return code for stitched LSPs 3.2.2. Return code for stitched LSPs
When a traceroute is being performed on stitched LSPs, Figure 10, the When a traceroute is being performed on stitched LSPs (Section 4.1.2)
stitching point SHOULD indicate the stitching action to the node the stitching point SHOULD indicate the stitching action to the node
performing the trace. This is done by setting the Return Code to performing the trace. This is done by setting the Return Code to
"Label switched with FEC change" (Section 6.3). If a node is "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 performing FEC hiding, then it MAY choose to set the Return Code to a
value other than "Label switched with FEC change". This Return Code value other than "Label switched with FEC change". This Return Code
MUST NOT be used if no FEC Stack sub-TLV (Section 3.3.3) is present 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 in the Downstream Detailed Mapping TLV(s). This new Return Code MAY
be used for hierarchical LSPs (for indicating start or end of an be used for hierarchical LSPs (for indicating start or end of an
outer LSP). outer LSP).
3.3. Downstream Detailed Mapping TLV 3.3. Downstream Detailed Mapping TLV
A new TLV has been added to the mandatory range of TLVs. The TLV
type is pending IANA allocation.
Type # Value Field Type # Value Field
------ ------------ ------ ------------
TBD Downstream detailed mapping TBD Downstream detailed mapping
Figure 3 Figure 3
The Downstream Detailed Mapping object is a TLV that MAY be included The Downstream Detailed Mapping object is a TLV that MAY be included
in an echo request message. Only one Downstream Detailed Mapping in an MPLS echo request message. Only one Downstream Detailed
object may appear in an echo request. The presence of a Downstream Mapping object may appear in an echo request. The presence of a
Mapping object is a request that Downstream Detailed Mapping objects Downstream Mapping object is a request that Downstream Detailed
be included in the echo reply. If the replying router is the Mapping objects be included in the MPLS echo reply. If the replying
destination of the FEC, then a Downstream Detailed Mapping TLV SHOULD router is the destination (Label Edge Router) of the FEC, then a
NOT be included in the echo reply. Otherwise the replying router Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS
SHOULD include a Downstream Detailed Mapping object for each echo reply. Otherwise the replying router SHOULD include a
interface over which this FEC could be forwarded. Downstream Detailed Mapping object for each interface over which this
FEC could be forwarded.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags | | MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) | | Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) | | Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return SubCode| Sub-tlv length | | Return Code | Return SubCode| Sub-tlv length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. List of Sub TLVs . . List of Sub TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Downstream Detailed Mapping TLV Figure 4: Downstream Detailed Mapping TLV
The Downstream Detailed Mapping TLV format is derived from the The Downstream Detailed Mapping TLV format is derived from the
Downstream Mapping TLV format. The key change is that variable Downstream Mapping TLV format. The key change is that variable
length and optional fields have been coverted into sub-TLVs. The length and optional fields have been converted into sub-TLVs. The
fields have the same use and meaning as in [RFC4379]. The newly fields have the same use and meaning as in [RFC4379]. A summary of
added sub-TLVs and their fields are as described below. the fields taken from 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 LSR.
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 Return code
The Return Code and Return SubCode are set to zero by the sender. The Return Code is set to zero by the sender. The receiver can
The receiver can set it to one of the values specified in the set it to one of the values specified in the "Multi-Protocol Label
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
Parameters" registry, "Return Codes" sub-registry. The notation "Return Codes" sub-registry.
<RSC> refers to the Return SubCode. This field is filled in with
the stack-depth for those codes that specify that. For all other
codes, the Return SubCode MUST be set to zero.
If the receiver sets a non-zero value of the Return Code field in If the receiver sets a non-zero value of the Return Code field in
the Downstream Detailed Mapping TLV, then the receiver MUST also the Downstream Detailed Mapping TLV, then the receiver MUST also
set the Return Code field in the echo response header to "See DDM set the Return Code field in the echo response header to "See DDM
TLV for Return Code and Return SubCode" (Section 6.3). An TLV for Return Code and Return SubCode" (Section 6.3). An
exception to this is if the receiver is a bud node and is replying exception to this is if the receiver is a bud node [RFC4461] and
as both an egress and a transit node with a Return Code of 3 is replying as both an egress and a transit node with a Return
("Replying router is an egress for the FEC") in the echo response Code of 3 ("Replying router is an egress for the FEC") in the echo
header. response header.
If the Return Code of the echo response message is not set to If the Return Code of the echo response message is not set to
either "See DDM TLV for Return Code and Return SubCode" either "See DDM TLV for Return Code and Return SubCode"
(Section 6.3) or "Replying router is an egress for the FEC", then (Section 6.3) or "Replying router is an egress for the FEC", then
the Return Code and Return SubCode specified in the Downstream the Return Code specified in the Downstream Detailed Mapping TLV
Detailed Mapping TLV SHOULD be ignored. SHOULD 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) Parameters" registry,
"Return Codes" sub-registry. This field is filled in with the
stack-depth for those codes that specify that. For all other
codes, the Return SubCode MUST be set to zero.
If the Return Code of the echo response 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", then
the Return SubCode specified in the Downstream Detailed Mapping
TLV SHOULD be ignored.
Sub-tlv length Sub-tlv length
Total length in bytes of the sub-TLVs associated with this TLV. 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 include as part of the
Downstream Detailed Mapping TLV.
Sub-Type Value Field Sub-Type Value Field
--------- ------------ --------- ------------
TBD Multipath data TBD Multipath data
TBD Label stack TBD Label stack
TBD FEC Stack change TBD FEC Stack change
Figure 5: Downstream Detailed Mapping Sub-TLV List Figure 5: Downstream Detailed Mapping Sub-TLV List
3.3.1. Multipath data sub-TLV 3.3.1.1. Multipath data sub-TLV
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) | |Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| (Multipath Information) | | (Multipath Information) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multipath Sub-TLV Figure 6: Multipath Sub-TLV
The multipath data sub-TLV includes information multipath The multipath data sub-TLV includes information multipath
information. The TLV fields and their usage is as defined in information. The TLV fields and their usage is as defined in
[RFC4379]. [RFC4379]. A brief summary of the fields is as below:
3.3.2. Label stack sub-TLV Multipath Type
The type of the encoding for the Multipath Information.
Multipath Length
The length in octets of the Multipath Information.
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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Label Stack Sub-TLV Figure 7: Label Stack Sub-TLV
The Label stack sub-TLV contains the set of labels in the label stack 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 as it would have appeared if this router were forwarding the packet
through this interface. Any Implicit Null labels are explicitly through this interface. Any Implicit Null labels are explicitly
included. The number of labels present in the sub-TLV is determined included. The number of label/protocol pairs present in the sub-TLV
based on the sub-TLV data length. Labels are treated as numbers, is determined based on the sub-TLV data length. The label format and
i.e., they are right justified in the field. The label format and
protocol type are as defined in [RFC4379]. When the Downstream protocol type are as defined in [RFC4379]. When the Downstream
Detailed Mapping TLV in sent in the echo response, this sub-TLV MUST Detailed Mapping TLV in sent in the echo response, this sub-TLV MUST
be included. be included.
3.3.3. FEC Stack change sub-TLV Downstream Label
A Downstream Label is 24 bits, in the same format as an MPLS label
minus the TTL field, i.e., the MSBit of the label is bit 0, the
LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S
bit. The replying router SHOULD fill in the EXP and S bits; the
LSR receiving the echo reply MAY choose to ignore these bits.
Protocol
This specifies the label distribution protocol for the downstream
label.
3.3.1.3. FEC Stack change sub-TLV
A router SHOULD include the the FEC Stack change sub-TLV when the A router SHOULD include the the FEC Stack change sub-TLV when the
downstream node in the echo response has a different FEC stack than downstream node in the echo response has a different FEC stack than
the FEC stack received in the echo request. One or more FEC Stack the FEC stack received in the echo request. One or more FEC Stack
change sub-TLVs MAY be present in the Downstream Detailed Mapping change sub-TLVs MAY be present in the Downstream Detailed Mapping
TLV. The format is as below. TLV. The format is as below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 29 skipping to change at page 11, line 39
Operation Type Operation Type
The operation type specifies the action associated with the FEC The operation type specifies the action associated with the FEC
stack change. The following operation types are defined. stack change. The following operation types are defined.
Type # Operation Type # Operation
------ --------- ------ ---------
1 Push 1 Push
2 Pop 2 Pop
Operation Type Values Figure 9: Operation Type Values
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.
One or more POP operations MAY be followed by one or more PUSH
operations. One FEC Stack change sub-TLV MUST be included per FEC
stack change. For example, if 2 labels are going to be pushed,
then 1 FEC Stack change sub-TLV MUST be included for each FEC. A
FEC splice operation (an operation where 1 FEC ends and another
FEC starts, see Figure 10) SHOULD be performed by including a POP
type FEC Stack change sub-TLV followed by a PUSH type FEC Stack
change sub-TLV.
A Downstream detailed mapping TLV containing only 1 FEC change
sub-TLV with Pop operation is equivalent to EGRESS_OK (Return code
3, [RFC4379]) for the outermost FEC in the FEC stack. The ingress
router performing the lsp trace MUST treat such a case as an
EGRESS_OK for the outermost FEC.
FEC tlv Length
Length in bytes of the FEC TLV.
Address Type Address Type
The Address Type indicates the remote peer's address type. The The Address Type indicates the remote peer's address type. The
Address Type is set to one of the following values. The peer Address Type is set to one of the following values. The peer
address length is determined based on the address type. The address length is determined based on the address type. The
address type MAY be different from the address type included in address type MAY be different from the address type included in
the Downstream Detailed Mapping TLV. This can happen in case the the Downstream Detailed Mapping TLV. This can happen in case the
LSP goes over a tunnel of a different address family. The address LSP goes over a tunnel of a different address family. The address
type MAY be set to Unspecified if the peer-address is either type MAY be set to Unspecified if the peer-address is either
unavailable or the transit router does not wish it provide it for unavailable or the transit router does not wish it provide it for
security or administrative reasons. security or administrative reasons.
Type # Address Type Address length Type # Address Type Address length
------ ------------ -------------- ------ ------------ --------------
0 Unspecified 0 0 Unspecified 0
1 IPv4 4 1 IPv4 4
2 IPv6 16 2 IPv6 16
Figure 9: Remote peer address type 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 Remote peer address
The remote peer address specifies the remote peer which is the The remote peer address specifies the remote peer which is the
next-hop for the FEC being currently traced. E.g. In the LDP next-hop for the FEC being currently traced. E.g. In the LDP
over RSVP case Figure 1, router B would respond back with the over RSVP case Figure 1, router B would respond back with the
address of router D as the remote peer address for the LDP FEC address of router D as the remote peer address for the LDP FEC
being traced. This allows the ingress node to provide helpful being traced. This allows the ingress node to provide information
information regarding FEC peers. If the operation type is PUSH, regarding FEC peers. If the operation type is PUSH, the remote
the remote peer address is the address of the peer from which the peer address is the address of the peer from which the FEC being
FEC being pushed was learnt. If the operation type is POP, the pushed was learnt. If the operation type is POP, the remote peer
remote peer address MAY be set to Unspecified. For upstream address MAY be set to Unspecified. For upstream assigned labels
assigned labels [RFC5331], an operation type of POP will have a [RFC5331], an operation type of POP will have a remote peer
remote peer address (the upstream node that assigned the label) address (the upstream node that assigned the label) and this
and this SHOULD be included in the FEC Stack change sub-TLV. SHOULD be included in the FEC Stack change sub-TLV.
FEC TLV FEC TLV
The FEC TLV is present only when FEC-tlv length field is non-zero. The FEC TLV is present only when FEC-tlv length field is non-zero.
The FEC TLV specifies the FEC associated with the FEC stack change The FEC TLV specifies the FEC associated with the FEC stack change
operation. This TLV MAY be included when the operation type is operation. This TLV MAY be included when the operation type is
POP. It SHOULD be included when the operation type is PUSH. The POP. It SHOULD be included when the operation type is PUSH. The
FEC TLV contains exactly 1 FEC from the list of FECs specified in FEC TLV contains exactly 1 FEC from the list of FECs specified in
[RFC4379]. A NIL FEC MAY be associated with a PUSH operation if [RFC4379]. A NIL FEC MAY be associated with a PUSH operation if
the responding router wishes to hide the details of the FEC being the responding router wishes to hide the details of the FEC being
pushed. pushed.
FEC Stack change sub-TLV operation rules:
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 1
FEC Stack change sub-TLV MUST be included for each FEC.
d. A FEC splice operation (an operation where 1 FEC ends and another
FEC starts, see Figure 11) SHOULD 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 1 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 3.4. Deprecation of Downstream Mapping TLV
The Downstream Mapping TLV has been deprecated. LSP-ping procedures The Downstream Mapping TLV has been deprecated. LSP-ping procedures
should now use the Downstream Detailed Mapping TLV. Detailed should now use the Downstream Detailed Mapping TLV. Detailed
procedures regarding interoperability between the deprecated TLV and procedures regarding interoperability between the deprecated TLV and
the new tlv are specified in Section 4.4. the new TLV are specified in Section 4.4.
4. Performing lsp-ping traceroute on tunnels 4. Performing MPLS traceroute on tunnels
This section describes the procedures to be followed by an ingress This section describes the procedures to be followed by a LSP ingress
node and transit nodes when performing lsp-ping traceroute over mpls node and LSP transit nodes when performing MPLS traceroute over MPLS
tunnels. tunnels.
4.1. Transit node procedure 4.1. Transit node procedure
4.1.1. Addition of a new tunnel 4.1.1. Addition of a new tunnel
A transit node (Figure 1) knows when the FEC being traced is going to 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. 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 All transit nodes that are the origination point of a new tunnel
SHOULD add the a FEC Stack change sub-TLV (Section 3.3.3) to the SHOULD add the a FEC Stack change sub-TLV (Section 3.3.1.3) to the
Downstream Detailed Mapping TLV (Figure 4) in the echo-response. The Downstream Detailed Mapping TLV (Figure 4) in the echo response. The
transit node SHOULD add 1 FEC Stack change sub-TLV of operation type transit node SHOULD add 1 FEC Stack change sub-TLV of operation type
PUSH, per new tunnel being originated at the transit node. PUSH, per new tunnel being originated at the transit node.
A transit node that sends a Downstream FEC Stack change sub-TLV in A transit node that sends a Downstream FEC Stack change sub-TLV in
the echo response SHOULD fill the address of the remote peer; which the echo response SHOULD fill the address of the remote peer; which
is the peer of the current LSP being traced. If the transit node is the peer of the current LSP being traced. If the transit node
does not know the address of the remote peer, it MAY leave it as does not know the address of the remote peer, it MUST leave it as
unspecified. unspecified.
The Label stack sub-TLV MUST contain 1 additional label per FEC being The Label stack sub-TLV MUST contain 1 additional label per FEC being
PUSHed. The label value MUST be the value used to switch the data PUSHed. The label MUST be encoded as per Figure 7.The label value
traffic. If the tunnel is transparent to the node, i.e. the data- MUST be the value used to switch the data traffic. If the tunnel is
plane trace will not expire in the middle of the new tunnel, then a transparent pipe to the node, i.e. the data-plane trace will not
FEC Stack change sub-TLV SHOULD NOT be added and the Label stack sub- expire in the middle of the new tunnel, then a FEC Stack change sub-
TLV SHOULD NOT contain a label corresponding to the hidden tunnel. 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 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 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 about the new tunnel FEC to the ingress. In such a case, the transit
node SHOULD use the NIL FEC. The echo response would then contain a node SHOULD use the NIL FEC. The echo response would then contain a
FEC Stack change sub-TLV with operation type PUSH and a NIL FEC. The 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 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 peer address type MUST be set to Unspecified. The transit node
SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH, per new SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH, per new
tunnel being originated at the transit node. The Label stack sub-TLV tunnel being originated at the transit node. The Label stack sub-TLV
MUST contain 1 additional label per FEC being PUSHed. The label MUST contain 1 additional label per FEC being PUSHed. The label
value MUST be the value used to switch the data traffic. value MUST be the value used to switch the data traffic.
4.1.2. Transition between tunnels 4.1.2. Transition between tunnels
A B C D E F A B C D E F
o -------- o -------- o --------- o -------- o ------- o o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/ \_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP LDP LDP BGP RSVP RSVP
Figure 10: Stitched LSPs Figure 11: Stitched LSPs
In the above figure, we have 3 seperate LSP segments stitched at C In the above figure, we have 3 seperate LSP segments stitched at C
and D. Node C SHOULD include 2 FEC Stack change sub-TLVs. One with a and D. Node C SHOULD include 2 FEC Stack change sub-TLVs. One with a
POP operation for the LDP FEC and one with the PUSH operation for the POP operation for the LDP FEC and one with the PUSH operation for the
BGP FEC. Similarly, node D SHOULD include 2 FEC Stack change sub- BGP FEC. Similarly, node D SHOULD include 2 FEC Stack change sub-
TLVs, one with a POP operation for the BGP FEC and one with a PUSH 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 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 to "Label switched with FEC change" (Section 6.3) to indicate change
in FEC being traced. in FEC being traced.
skipping to change at page 13, line 38 skipping to change at page 15, line 12
to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation 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 have the FEC TLV containing the NIL FEC. The Return Code
SHOULD be set to "Label switched with FEC change". SHOULD be set to "Label switched with FEC change".
If node C performs FEC hiding and node D also performs FEC hiding, 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 then node D MAY choose to not send any FEC Stack change sub-TLVs in
the echo response since the number of labels has not changed (for the the echo response since the number of labels has not changed (for the
downstream of node D) and the FEC type also has not changed (NIL 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 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 switched with FEC change". If node D performs FEC hiding, then node
F will respond as EGRESS_OK for the NIL FEC. The ingress (node A) F will respond as IS_EGRESS for the NIL FEC. The ingress (node A)
will know that EGRESS_OK corresponds to the end-to-end LSP. will know that IS_EGRESS corresponds to the end-to-end LSP.
A B C D E F A B C D E F
o -------- o -------- o --------- o --------- o --------- o o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/ \_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP LDP |\ RSVP-A | LDP
| \_______________________________/| | \_______________________________/|
| RSVP-B | | RSVP-B |
\________________________________/ \________________________________/
LDP LDP
Figure 11: Hierarchical LSPs Figure 12: Hierarchical LSPs
In the above figure, the following sequence of FEC Stack change sub- In the above figure, we have an end-to-end LDP LSP between nodes A
TLVs will be performed 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: Node B:
Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A. Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
Node D: Node D:
Respond with a Return Code of EGRESS_OK when RSVP-A is top of FEC Respond with a Return Code of 3 when RSVP-A is top of FEC stack.
stack. Downstream information for node E when echo request contains Downstream information for node E when echo request contains RSVP-B
RSVP-B as top of FEC stack and an appropriate Return Code. as top of FEC stack and an appropriate Return Code.
If node B is performing tunnel hiding, then: If node B is performing tunnel hiding, then:
Node B: Node B:
Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC. Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC.
Node D: Node D:
Respond with either Return Code of EGRESS_OK (if D can co-relate that Respond with either Return Code of 3 (if D can co-relate that the
the NIL-FEC corresponds to RSVP-A which is terminating at D) or NIL-FEC corresponds to RSVP-A which is terminating at D) or respond
respond with FEC Stack change sub-TLV: POP (since D knows that number with FEC Stack change sub-TLV: POP (since D knows that number of
of labels towards next-hop is decreasing). labels towards next-hop is decreasing).
A B C D E F G A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP LDP LDP BGP \ RSVP RSVP / LDP
\_____________/ \_____________/
LDP LDP
Figure 12: Stitched hierarchical LSPs Figure 13: Stitched hierarchical LSPs
In the above case, node D will send 3 FEC Stack change sub-TLVs. One In the above case, node D will send 3 FEC Stack change sub-TLVs. One
POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for
RSVP). Nodes C and D SHOULD set the Return Code to "Label switched 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 with FEC change" (Section 6.3) to indicate change in FEC being
traced. traced.
4.1.3. Modification to FEC Validation procedure on Transit 4.1.3. Modification to FEC Validation procedure on Transit
Section 4.4 of [RFC4379] specifies Target FEC stack validation Section 4.4 of [RFC4379] specifies Target FEC stack validation
skipping to change at page 15, line 34 skipping to change at page 16, line 47
Section 4.4 of [RFC4379] specifies Target FEC stack validation Section 4.4 of [RFC4379] specifies Target FEC stack validation
procedures. This document enhances the FEC validation procedures as procedures. This document enhances the FEC validation procedures as
follows. If the outermost FEC of the target FEC stack is the NIL follows. If the outermost FEC of the target FEC stack is the NIL
FEC, then the node MUST skip the target FEC validation completely. 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 This is to support FEC hiding, in which the outer hidden FEC can be
the NIL FEC. the NIL FEC.
4.3. Ingress node procedure 4.3. Ingress node procedure
It is the responsibility of an ingress node to understand tunnel It is the responsibility of an ingress node to understand tunnel
within tunnel semantics and lsp stitching semantics when performing a within tunnel semantics and LSP stitching semantics when performing a
lsp traceroute. This section describes the ingress node procedure MPLS traceroute. This section describes the ingress node procedure
based on the kind of response an ingress node receives from a transit based on the kind of response an ingress node receives from a transit
node. node.
4.3.1. Processing Downstream Detailed Mapping TLV 4.3.1. Processing Downstream Detailed Mapping TLV
Downstream Detailed Mapping TLV should be processed in procedures Downstream Detailed Mapping TLV should be processed in the same way
similar to those of Downstream Mapping TLV, defined in Section 4.4 of as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379].
[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 4.3.1.1. Stack Change sub-TLV not present
This would be the default behavior as described in [RFC4379]. The This would be the default behavior as described in [RFC4379]. The
ingress node MUST perform echo response processing as per the ingress node MUST perform MPLS echo response processing as per the
procedures in [RFC4379]. procedures in [RFC4379].
4.3.1.2. Stack Change sub-TLV(s) present 4.3.1.2. Stack Change sub-TLV(s) present
If one or more FEC Stack change sub-TLVs (Section 3.3.3) are received If one or more FEC Stack change sub-TLVs (Section 3.3.1.3) are
in the echo response, the ingress node SHOULD process them and received in the MPLS echo response, the ingress node SHOULD process
perform some validation. them and perform some validation.
The FEC stack changes are associated with a downstream neighbor and The FEC stack changes are associated with a downstream neighbor and
along a particular path of the LSP. Consequently, the ingress will along a particular path of the LSP. Consequently, the ingress will
need to maintain a FEC-stack per path being traced (in case of need to maintain a FEC-stack per path being traced (in case of
multipath). All changes to the FEC stack resulting from the multipath). All changes to the FEC stack resulting from the
processing of FEC Stack change sub-TLV(s) should be applied only for processing of FEC Stack change sub-TLV(s) should be applied only for
the path along a given downstream neighbor. The following algorithm the path along a given downstream neighbor. The following algorithm
should be followed for processing FEC Stack change sub-TLVs. should be followed for processing FEC Stack change sub-TLVs.
push_seen = FALSE push_seen = FALSE
skipping to change at page 17, line 46 skipping to change at page 18, line 46
} }
} }
} }
if (fec_stack_depth == 0) { if (fec_stack_depth == 0) {
Drop the echo response Drop the echo response
current_fec_stack = saved_fec_stack current_fec_stack = saved_fec_stack
return return
} }
Figure 13: FEC Stack Change Sub-TLV Processing Guideline Figure 14: FEC Stack Change Sub-TLV Processing Guideline
The next echo request along the same path should use the modified FEC The next MPLS echo request along the same path should use the
stack obtained after processing the FEC Stack change sub-TLVs. A modified FEC stack obtained after processing the FEC Stack change
non-NIL FEC guarantees that the next echo request along the same path sub-TLVs. A non-NIL FEC guarantees that the next echo request along
will have the Downstream Detailed Mapping TLV validated for IP the same path will have the Downstream Detailed Mapping TLV validated
address, Interface address and label stack mismatches. for IP address, Interface address and label stack mismatches.
If the top of the FEC stack is a NIL FEC and the echo response does If the top of the FEC stack is a NIL FEC and the MPLS echo response
not contain any FEC Stack change sub-TLV, then it does not does not contain any FEC Stack change sub-TLV, then it does not
necessarily mean that the LSP has not started traversing a different necessarily mean that the LSP has not started traversing a different
tunnel. It could be that the LSP associated with the NIL FEC 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 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 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 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 is not possible to build an accurate hierarchical LSP topology if a
traceroute contains NIL FECs. traceroute contains NIL FECs.
4.3.2. Modifications to handling to EGRESS_OK responses. 4.3.2. Modifications to handling to Return Code 3 responses.
The procedures above allow the addition of new FECs to the original The procedures above allow the addition of new FECs to the original
FEC being traced. Consequently, the EGRESS_OK response from a FEC being traced. Consequently, a response from a downstream node
downstream node may not necessarily be for the FEC being traced. It with Return Code of 3 (IS_EGRESS) may not necessarily be for the FEC
could be for one of the new FECs that was added. On receipt of an being traced. It could be for one of the new FECs that was added.
EGRESS_OK response, the ingress should check if the depth of Target On receipt of an IS_EGRESS response, the LSP ingress should check if
FEC sent to the node that just responded, was the same as the depth the depth of Target FEC sent to the node that just responded, was the
of the FEC that was being traced. If it was not, then it should pop same as the depth of the FEC that was being traced. If it was not,
the an entry from the Target FEC stack and resend the request with then it should pop an entry from the Target FEC stack and resend the
the same TTL (as previously sent). The process of popping a FEC is request with the same TTL (as previously sent). The process of
to be repeated until either the ingress receives a non-EGRESS_OK popping a FEC is to be repeated until either the LSP ingress receives
response or until all the additional FECs added to the FEC stack have a non-IS_EGRESS response or until all the additional FECs added to
already been popped. Using EGRESS_OK responses, an ingress can build the FEC stack have already been popped. Using IS_EGRESS responses,
a map of the hierarchical LSP structure traversed by a given FEC. an ingress can build a map of the hierarchical LSP structure
traversed by a given FEC.
4.3.3. Handling of new return codes 4.3.3. Handling of new return codes
When the echo response Return Code is "Label switched with FEC When the MPLS echo response Return Code is "Label switched with FEC
change" (Section 3.2.2), the ingress node SHOULD manipulate the 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 stack as per the FEC Stack change sub-TLVs contained in the
downstream detailed mapping TLV. A transit node can use this Return downstream detailed mapping TLV. A transit node can use this Return
Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or Code for stitched LSPs and for hierarchical LSPs. In case of Equal
P2MP, there could be multiple paths and downstream detailed mapping Cost Multi-Path (ECMP) or Point to Multi-Point (P2MP), there could be
TLVs with different return codes (Section 3.2.1). The ingress node multiple paths and downstream detailed mapping TLVs with different
should build the topology based off the Return Code per ECMP path/ return codes (Section 3.2.1). The ingress node should build the
P2MP branch. topology based off the Return Code per ECMP path/P2MP branch.
4.4. Handling deprecated Downstream Mapping TLV 4.4. Handling deprecated Downstream Mapping TLV
The Downstream Mapping TLV has been deprecated. Applications should The Downstream Mapping TLV has been deprecated. Applications should
now use the Downstream Detailed Mapping TLV. The following now use the Downstream Detailed Mapping TLV. The following
procedures SHOULD be used for backward compatibility with routers procedures SHOULD be used for backward compatibility with routers
that do not support the Downstream Detailed Mapping TLV. that do not support the Downstream Detailed Mapping TLV.
o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV
MUST never be sent together in the same echo request or in the MUST never be sent together in the same MPLS echo request or in
same echo response. the same MPLS echo response.
o If the echo request contains a Downstream Detailed Mapping TLV and o If the echo request contains a Downstream Detailed Mapping TLV and
the corresponding echo response contains an Return Code of 2 (one the corresponding echo response contains an Return Code of 2 (one
or more of the TLVs was not understood), then the sender of the or more of the TLVs was not understood), then the sender of the
echo request MAY resend the echo request with the Downstream echo request MAY resend the echo request with the Downstream
Mapping TLV (instead of the Downstream Detailed Mapping TLV). In Mapping TLV (instead of the Downstream Detailed Mapping TLV). In
cases where a detailed response is needed, the sender can choose cases where a detailed response is needed, the sender can choose
to ignore the router that does not support the Downstream Detailed to ignore the router that does not support the Downstream Detailed
Mapping TLV. Mapping TLV.
o If the echo request contains a Downstream Mapping TLV, then a o If the echo request contains a Downstream Mapping TLV, then a
Downstream Detailed Mapping TLV MUST NOT be sent in the echo Downstream Detailed Mapping TLV MUST NOT be sent in the echo
response. This is to handle the case that the sender of the echo response. This is to handle the case that the sender of the echo
request does not support the new TLV. The echo response MAY request does not support the new TLV. The echo response MAY
contain Downstream Mapping TLV(s). contain Downstream Mapping TLV(s).
o If echo request forwarding is in use; such that the echo request o If echo request forwarding is in use; such that the echo request
is processed at an intermediate router and then forwarded on; then is processed at an intermediate label switched router (LSR) and
the intermediate router is responsible for making sure that the then forwarded on; then the intermediate router is responsible for
TLVs being used among the ingress, intermediate and destination making sure that the TLVs being used among the ingress,
are consistent. The intermediate router MUST NOT forward an echo intermediate and destination are consistent. The intermediate
request or an echo response containing a Downstream Detailed router MUST NOT forward an echo request or an echo response
Mapping TLV if it itself does not support that TLV. containing a Downstream Detailed Mapping TLV if it itself does not
support that TLV.
5. Security Considerations 5. Security Considerations
Tracing inside a tunnel might have some security implications. There 1. If a network operator wants to prevent tracing inside a tunnel,
are different ways to prevent tracing tunnel details. one can use the pipe mode [RFC3443], i.e. hide the outer MPLS
tunnel by not propagating the MPLS TTL into the outer tunnel (at
1. If one wants to prevent tracing inside a tunnel, one can hide the the start of the outer tunnel). By doing this, MPLS traceroute
outer MPLS tunnel by not propagating the MPLS TTL into the outer packets will not expire in the outer tunnel and the outer tunnel
tunnel (at the start of the outer tunnel). By doing this, lsp- will not get traced.
ping packets will not expire in the outer tunnel and the outer
tunnel will not get traced. TTL hiding can be imposed on a per
LSP basis, as need be.
2. If one doesn't wish to expose the details of the new outer LSP, 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 then the NIL FEC can be used to hide those details. Using the
NIL FEC ensures that the trace progresses without false negatives NIL FEC ensures that the trace progresses without false negatives
and all transit nodes (of the new outer tunnel) perform some and all transit nodes (of the new outer tunnel) perform some
minimal validations on the received echo requests. minimal validations on the received MPLS echo requests.
In inter-AS (autonomous system) scenarios, information regarding the
LSP FEC change(s) SHOULD NOT be passed across domains. A NIL FEC MAY
be used to make the trace go through without false positives. An
ASBR (autonomous system border router) may choose to intercept all
echo requests and echo responses and change them to hide FEC
information from other domains. Detailed operation regarding the
same is outside the scope of this document. Passing of FEC stack
change information between domains MAY be done if the two AS domains
belong to the same provider/organization.
Other security considerations, as discussed in [RFC4379] are also Other security considerations, as discussed in [RFC4379] are also
applicable to this document. applicable to this document.
6. IANA Considerations 6. IANA Considerations
Editors note: To be removed by RFC-Editor.
The suggested values in all sub-sections below have been allocated The suggested values in all sub-sections below have been allocated
according to the early allocation process. according to the early allocation process.
6.1. New TLV 6.1. New TLV
IANA is requested to assign TLV type value to the following TLV from IANA is requested to assign TLV type value to the following TLV from
the "Multiprotocol Label Switching Architecture (MPLS) Label Switched the "Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-
registry. registry.
skipping to change at page 21, line 40 skipping to change at page 22, line 26
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
8.2. Informative References 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.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, August 2008. RFC 5331, August 2008.
Authors' Addresses Authors' Addresses
Nitin Bahadur Nitin Bahadur
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
 End of changes. 69 change blocks. 
247 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/