draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt   draft-ietf-mpls-lsp-ping-enhanced-dsmap-10.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: November 14, 2011 Cisco Systems Expires: January 1, 2012 Cisco Systems
May 13, 2011 June 30, 2011
Mechanism for performing LSP-Ping over MPLS tunnels Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-09 draft-ietf-mpls-lsp-ping-enhanced-dsmap-10
Abstract Abstract
This document describes methods for performing LSP Ping (specified in This document describes methods for performing LSP-Ping (specified in
RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched
MPLS label-switched-paths (LSPs). The techniques outlined in RFC MPLS label-switched-paths (LSPs). The techniques outlined in RFC
4379 are insufficient to perform traceroute Forwarding Equivalency 4379 are insufficient to perform traceroute Forwarding Equivalency
Class (FEC) validation and path discovery for a LSP that goes over Class (FEC) validation and path discovery for an LSP that goes over
other MPLS tunnels or for a stitched LSP. This document describes 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 November 14, 2011. This Internet-Draft will expire on January 1, 2012.
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 29 skipping to change at page 3, line 29
4. Performing MPLS traceroute on tunnels . . . . . . . . . . . . 13 4. Performing MPLS traceroute on tunnels . . . . . . . . . . . . 13
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 13 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 13
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 13 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 13
4.1.2. Transition between tunnels . . . . . . . . . . . . . . 14 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 14
4.1.3. Modification to FEC Validation procedure on Transit . 16 4.1.3. Modification to FEC Validation procedure on Transit . 16
4.2. Modification to FEC Validation procedure on Egress . . . . 16 4.2. Modification to FEC Validation procedure on Egress . . . . 16
4.3. Ingress node procedure . . . . . . . . . . . . . . . . . . 16 4.3. Ingress node procedure . . . . . . . . . . . . . . . . . . 16
4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17 4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17
4.3.1.1. Stack Change sub-TLV not present . . . . . . . . . 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.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 17
4.3.2. Modifications to handling to Return Code 3 4.3.2. Modifications to handling to Return Code 3 reply. . . 19
responses. . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3. Handling of new return codes . . . . . . . . . . . . . 19 4.3.3. Handling of new return codes . . . . . . . . . . . . . 19
4.4. Handling deprecated Downstream Mapping TLV . . . . . . . . 19 4.4. Handling deprecated Downstream Mapping TLV . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This documents describes methods for performing LSP ping (specified This documents describes methods for performing LSP-Ping (specified
in [RFC4379] traceroute over MPLS tunnels. The techniques in in [RFC4379] traceroute over MPLS tunnels. The techniques in
[RFC4379] outline a traceroute mechanism that includes Forwarding [RFC4379] outline a traceroute mechanism that includes Forwarding
Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP) Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP)
path discovery. Those mechanisms are insufficient and do not provide path discovery. Those mechanisms are insufficient and do not provide
details in case the FEC being traced traverses one or more MPLS details in case the FEC being traced traverses one or more MPLS
tunnels and in case where label-switched-path (LSP) stitching is in tunnels and in case where label-switched-path (LSP) stitching
use. This document defines enhancements to the downstream-mapping [RFC5150] is in use. This document defines enhancements to the
TLV [RFC4379] to make it more extensible and to enable retrieval of downstream-mapping TLV [RFC4379] to make it more extensible and to
detailed information. Using the enhanced TLV format along with the enable retrieval of detailed information. Using the enhanced TLV
existing definitions of [RFC4379], this document describes procedures format along with the existing definitions of [RFC4379], this
by which a traceroute request can correctly traverse MPLS tunnels document describes procedures by which a traceroute request can
with proper FEC and label validations. 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
skipping to change at page 4, line 43 skipping to change at page 4, line 44
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 MPLS echo response. downstream mapping information for node C in the MPLS echo reply.
The next MPLS echo request reaches router C with a LDP FEC. Node C The next MPLS echo request reaches router C with a LDP FEC. Node C
is a pure RSVP node and does not run LDP. Node C will receive the is a pure RSVP node and does not run LDP. Node C will receive the
MPLS echo request with 2 labels but only 1 FEC in the Target FEC MPLS echo request with 2 labels but only 1 FEC in the Target FEC
stack. Consequently, node C will be unable to perform FEC complete stack. Consequently, node C will be unable to perform FEC complete
validation. It will let the trace continue by just providing next- validation. It will let the trace continue by just providing next-
hop information based on incoming label, and by looking up the hop information based on incoming label, and by looking up the
forwarding state associated with that label. However, ignoring FEC forwarding state associated with that label. However, ignoring FEC
validation defeats the purpose of control plane validatations. The validation defeats the purpose of control plane validatations. The
MPLS echo request should contain sufficient information to allow node MPLS echo request should contain sufficient information to allow node
C to perform FEC validations to catch any misrouted echo-requests. C to perform FEC validations to catch any misrouted echo-requests.
skipping to change at page 5, line 31 skipping to change at page 5, line 32
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 stitched LSP A--F. When an 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 MPLS echo request reaches router C, there is a FEC stack change
happening at router C. With current LSP Ping [[RFC4379]] mechanisms, happening at router C. With current LSP-Ping [RFC4379] mechanisms,
there is no way to convey this information to A. Consequently, when there is no way to convey this information to A. Consequently, when
the next echo request reaches router D, router D will know nothing the next echo request reaches router D, router D will know nothing
about the LDP FEC that A is trying to trace. about the LDP FEC that A is trying to trace.
Thus, the procedures defined in [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 MPLS echo response. In most cases, the additional data needs to the MPLS echo reply. In most cases, the additional data needs to be
be associated on a per downstream neighbor basis. Currently, the associated on a per downstream neighbor basis. Currently, the MPLS
MPLS echo response contains one downstream map TLV (DSMAP) per echo reply contains one downstream map TLV (DSMAP) per downstream
downstream neighbor. However the DSMAP format is not extensible and neighbor. However the DSMAP format is not extensible and hence it is
hence it is not possible to associate more information with a not possible to associate more information with a downstream
downstream neighbor. This draft defines a new extensible format for neighbor. This draft defines a new extensible format for the DSMAP
the DSMAP and provides mechanisms for solving the tunneled LSP Ping and provides mechanisms for solving the tunneled LSP-Ping problem
problem using the new format. In summary, the draft makes the using the new format. In summary, the draft makes the following TLV
following TLV changes: 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 (DSMAP). 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 MPLS be used only in the message header and MUST be set only in the MPLS
echo response message. If the Return Code is set in the MPLS echo 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 request message, then it MUST be ignored. When this Return Code is
set, each Downstream Detailed Mapping TLV MUST have an appropriate set, each Downstream Detailed Mapping TLV MUST have an appropriate
Return Code and Return SubCode. This Return Code is to be used when Return Code and Return SubCode. This Return Code MUST be used when
there are multiple downstreams for a given node (such as P2MP or there are multiple downstreams for a given node (such as P2MP or
ECMP), and the node needs to return a different Return Code/Return ECMP), and the node needs to return a different Return Code/Return
SubCode for each downstream. SubCode for each downstream. This Return Code MAY be used even when
there is only 1 downstream for a given node.
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 (Section 4.1.2) When a traceroute is being performed on stitched LSPs (Section 4.1.2)
the 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.1.3) is present MUST NOT be used if no FEC Stack sub-TLV (Section 3.3.1.3) is present
skipping to change at page 7, line 12 skipping to change at page 7, line 12
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
Type # Value Field Type # Value Field
------ ------------ ------ ------------
TBD Downstream detailed mapping TBD Downstream detailed mapping
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 MPLS echo request message. Only one Downstream Detailed in an MPLS echo request message. Only one Downstream Detailed
Mapping object may appear in an echo request. The presence of a Mapping object may appear in an echo request. The presence of a
Downstream Mapping object is a request that Downstream Detailed Downstream Detailed Mapping object is a request that Downstream
Mapping objects be included in the MPLS echo reply. If the replying Detailed Mapping objects be included in the MPLS echo reply. If the
router is the destination (Label Edge Router) of the FEC, then a replying router is the destination (Label Edge Router) of the FEC,
Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
echo reply. Otherwise the replying router SHOULD include a MPLS echo reply. Otherwise the replying router SHOULD include a
Downstream Detailed Mapping object for each interface over which this Downstream Detailed Mapping object for each interface over which this
FEC could be forwarded. 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 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 3: 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 converted 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]. A summary of fields have the same use and meaning as in [RFC4379]. A summary of
the fields taken from Downstream Mapping TLV is as below: the fields taken from Downstream Mapping TLV is as below:
Maximum Transmission Unit (MTU) Maximum Transmission Unit (MTU)
The MTU is the size in octets of the largest MPLS frame (including The MTU is the size in octets of the largest MPLS frame (including
label stack) that fits on the interface to the Downstream LSR. label stack) that fits on the interface to the Downstream LSR.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
The newly added sub-TLVs and their fields are as described below. The newly added sub-TLVs and their fields are as described below.
Return code Return code
The Return Code is set to zero by the sender. The receiver can 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 set it to one of the values specified in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
"Return Codes" sub-registry. "Return Codes" sub-registry.
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 reply header to "See DDM TLV
TLV for Return Code and Return SubCode" (Section 6.3). An for Return Code and Return SubCode" (Section 6.3). An exception
exception to this is if the receiver is a bud node [RFC4461] and to this is if the receiver is a bud node [RFC4461] and is replying
is replying as both an egress and a transit node with a Return as both an egress and a transit node with a Return Code of 3
Code of 3 ("Replying router is an egress for the FEC") in the echo ("Replying router is an egress for the FEC") in the echo reply
response header. header.
If the Return Code of the echo response message is not set to If the Return Code of the echo reply message is not set to either
either "See DDM TLV for Return Code and Return SubCode" "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or
(Section 6.3) or "Replying router is an egress for the FEC", then "Replying router is an egress for the FEC", then the Return Code
the Return Code specified in the Downstream Detailed Mapping TLV specified in the Downstream Detailed Mapping TLV SHOULD be
SHOULD be ignored. ignored.
Return SubCode Return SubCode
The Return SubCode is set to zero by the sender. The receiver can 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 set it to one of the values specified in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
"Return Codes" sub-registry. This field is filled in with the "Return Codes" sub-registry. This field is filled in with the
stack-depth for those codes that specify that. For all other stack-depth for those codes that specify that. For all other
codes, the Return SubCode MUST be set to zero. codes, the Return SubCode MUST be set to zero.
If the Return Code of the echo response message is not set to If the Return Code of the echo reply message is not set to either
either "See DDM TLV for Return Code and Return SubCode" "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or
(Section 6.3) or "Replying router is an egress for the FEC", then "Replying router is an egress for the FEC", then the Return
the Return SubCode specified in the Downstream Detailed Mapping SubCode specified in the Downstream Detailed Mapping TLV SHOULD be
TLV SHOULD be ignored. 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 3.3.1. Sub-TLVs
This section defines the Sub-TLVs that MAY be include as part of the This section defines the Sub-TLVs that MAY be include as part of the
Downstream Detailed Mapping TLV. 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
3.3.1.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 4: Multipath Sub-TLV
The multipath data sub-TLV includes information multipath The multipath data sub-TLV includes multipath information. The sub-
information. The TLV fields and their usage is as defined in TLV fields and their usage is as defined in [RFC4379]. A brief
[RFC4379]. A brief summary of the fields is as below: summary of the fields is as below:
Multipath Type Multipath Type
The type of the encoding for the Multipath Information. The type of the encoding for the Multipath Information.
Multipath Length Multipath Length
The length in octets of the Multipath Information. The length in octets of the Multipath Information.
Multipath Information Multipath Information
skipping to change at page 10, line 28 skipping to change at page 10, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Label Stack Sub-TLV Figure 5: 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 label/protocol pairs present in the sub-TLV 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 is determined based on the sub-TLV data length. 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 is sent in the echo reply, this sub-TLV MUST be
be included. included.
Downstream Label Downstream Label
A Downstream Label is 24 bits, in the same format as an MPLS 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 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 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 bit. The replying router SHOULD fill in the EXP and S bits; the
LSR receiving the echo reply MAY choose to ignore these bits. LSR receiving the echo reply MAY choose to ignore these bits.
Protocol Protocol
This specifies the label distribution protocol for the downstream This specifies the label distribution protocol for the downstream
label. label.
3.3.1.3. FEC Stack change sub-TLV 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 FEC Stack change sub-TLV when the
downstream node in the echo response has a different FEC stack than downstream node in the echo reply has a different FEC Stack than the
the FEC stack received in the echo request. One or more FEC Stack FEC stack received in the echo request. One or more FEC Stack change
change sub-TLVs MAY be present in the Downstream Detailed Mapping sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The
TLV. The format is as below. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address type | FEC-tlv length| Reserved | |Operation Type | Address type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) | | Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. FEC TLV . . FEC TLV .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FEC Stack Change Sub-TLV Figure 6: FEC Stack Change Sub-TLV
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
Figure 9: Operation Type Values
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
skipping to change at page 12, line 26 skipping to change at page 12, line 24
FEC tlv Length FEC tlv Length
Length in bytes of the FEC TLV. Length in bytes of the FEC TLV.
Reserved Reserved
This field is reserved for future use and MUST be set to zero. 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
over RSVP case Figure 1, router B would respond back with the RSVP case Figure 1, router B would respond back with the address
address of router D as the remote peer address for the LDP FEC of router D as the remote peer address for the LDP FEC being
being traced. This allows the ingress node to provide information traced. This allows the ingress node to provide information
regarding FEC peers. If the operation type is PUSH, the remote regarding FEC peers. If the operation type is PUSH, the remote
peer address is the address of the peer from which the FEC being peer address is the address of the peer from which the FEC being
pushed was learnt. If the operation type is POP, the remote peer pushed was learnt. If the operation type is POP, the remote peer
address MAY be set to Unspecified. For upstream assigned labels address MAY be set to Unspecified. For upstream assigned labels
[RFC5331], an operation type of POP will have a remote peer [RFC5331], an operation type of POP will have a remote peer
address (the upstream node that assigned the label) and this address (the upstream node that assigned the label) 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.
skipping to change at page 13, line 4 skipping to change at page 12, line 47
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: FEC Stack change sub-TLV operation rules:
a. A FEC Stack change sub-TLV containing a PUSH operation MUST NOT 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 be followed by a FEC Stack change sub-TLV containing a POP
operation. operation.
b. One or more POP operations MAY be followed by one or more PUSH b. One or more POP operations MAY be followed by one or more PUSH
operations. operations.
c. One FEC Stack change sub-TLV MUST be included per FEC stack 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 change. For example, if 2 labels are going to be pushed, then 1
FEC Stack change sub-TLV MUST be included for each FEC. FEC Stack change sub-TLV MUST be included for each FEC.
d. A FEC splice operation (an operation where 1 FEC ends and another 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 FEC starts, see Figure 7) SHOULD be performed by including a POP
type FEC Stack change sub-TLV followed by a PUSH type FEC Stack type FEC Stack change sub-TLV followed by a PUSH type FEC Stack
change sub-TLV. change sub-TLV.
e. A Downstream detailed mapping TLV containing only 1 FEC Stack e. A Downstream detailed mapping TLV containing only 1 FEC Stack
Change sub-TLV with Pop operation is equivalent to IS_EGRESS Change sub-TLV with Pop operation is equivalent to IS_EGRESS
(Return code 3, [RFC4379]) for the outermost FEC in the FEC (Return code 3, [RFC4379]) for the outermost FEC in the FEC
stack. The ingress router performing the MPLS traceroute MUST stack. The ingress router performing the MPLS traceroute MUST
treat such a case as an IS_EGRESS for the outermost FEC. 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 MPLS traceroute on tunnels 4. Performing MPLS traceroute on tunnels
This section describes the procedures to be followed by a LSP ingress This section describes the procedures to be followed by an LSP
node and LSP transit nodes when performing MPLS traceroute over MPLS ingress node and LSP transit nodes when performing MPLS traceroute
tunnels. over MPLS 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.1.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 3) in the echo reply. 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 reply SHOULD fill the address of the remote peer; which is
is the peer of the current LSP being traced. If the transit node the peer of the current LSP being traced. If the transit node does
does not know the address of the remote peer, it MUST leave it as 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 MUST be encoded as per Figure 7.The label value 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 MUST be the value used to switch the data traffic. If the tunnel is
transparent pipe to the node, i.e. the data-plane trace will not 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- 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 TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT
contain a label corresponding to the hidden tunnel. 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 reply would then contain a FEC
FEC Stack change sub-TLV with operation type PUSH and a NIL FEC. The 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 11: Stitched LSPs Figure 7: 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.
If node C wishes to perform FEC hiding, it SHOULD respond back with 2 If node C wishes to perform FEC hiding, it SHOULD respond back with 2
FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP
operation MAY either exclude the FEC TLV (by setting FEC TLV length operation MAY either exclude the FEC TLV (by setting FEC TLV length
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 reply 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 IS_EGRESS 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 IS_EGRESS 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 12: Hierarchical LSPs Figure 8: Hierarchical LSPs
In the above figure, we have an end-to-end LDP LSP between nodes A 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 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 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 the end-to-end LDP LSP, then following sequence of FEC Stack change
sub-TLVs will be performed 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.
skipping to change at page 16, line 18 skipping to change at page 16, line 14
NIL-FEC corresponds to RSVP-A which is terminating at D) or respond NIL-FEC corresponds to RSVP-A which is terminating at D) or respond
with FEC Stack change sub-TLV: POP (since D knows that number of with FEC Stack change sub-TLV: POP (since D knows that number 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 13: Stitched hierarchical LSPs Figure 9: 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 16, line 49 skipping to change at page 16, line 45
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
MPLS 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 reply 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 the same way Downstream Detailed Mapping TLV should be processed in the same way
as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379]. as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379].
This section describes the procedures for processing the new elements This section describes the procedures for processing the new elements
introduced in this document. 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 MPLS echo response processing as per the ingress node MUST perform MPLS echo reply 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.1.3) are If one or more FEC Stack change sub-TLVs (Section 3.3.1.3) are
received in the MPLS echo response, the ingress node SHOULD process received in the MPLS echo reply, the ingress node SHOULD process them
them and perform some validation. 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 18, line 17 skipping to change at page 18, line 17
saved_fec_stack = current_fec_stack saved_fec_stack = current_fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
if (sub-tlv == NULL) break if (sub-tlv == NULL) break
if (sub-tlv.type == FEC-Stack-Change) { if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.operation == POP) { if (sub-tlv.operation == POP) {
if (push_seen) { if (push_seen) {
Drop the echo response Drop the echo reply
current_fec_stack = saved_fec_stack current_fec_stack = saved_fec_stack
return return
} }
if (fec_stack_depth == 0) { if (fec_stack_depth == 0) {
Drop the echo response Drop the echo reply
current_fec_stack = saved_fec_stack current_fec_stack = saved_fec_stack
return return
} }
Pop FEC from FEC stack being traced Pop FEC from FEC stack being traced
fec_stack_depth--; fec_stack_depth--;
} }
if (sub-tlv.operation == PUSH) { if (sub-tlv.operation == PUSH) {
push_seen = 1 push_seen = 1
Push FEC on FEC stack being traced Push FEC on FEC stack being traced
fec_stack_depth++; fec_stack_depth++;
} }
} }
} }
if (fec_stack_depth == 0) { if (fec_stack_depth == 0) {
Drop the echo response Drop the echo reply
current_fec_stack = saved_fec_stack current_fec_stack = saved_fec_stack
return return
} }
Figure 14: FEC Stack Change Sub-TLV Processing Guideline Figure 10: FEC Stack Change Sub-TLV Processing Guideline
The next MPLS echo request along the same path should use the The next MPLS echo request along the same path should use the
modified FEC stack obtained after processing the FEC Stack change modified FEC stack obtained after processing the FEC Stack change
sub-TLVs. A non-NIL FEC guarantees that the next echo request along sub-TLVs. A non-NIL FEC guarantees that the next echo request along
the same path will have the Downstream Detailed Mapping TLV validated the same path will have the Downstream Detailed Mapping TLV validated
for IP 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 MPLS echo response If the top of the FEC stack is a NIL FEC and the MPLS echo reply does
does not contain any FEC Stack change sub-TLV, then it does not 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 Return Code 3 responses. 4.3.2. Modifications to handling to Return Code 3 reply.
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, a response from a downstream node FEC being traced. Consequently, a reply from a downstream node with
with Return Code of 3 (IS_EGRESS) may not necessarily be for the FEC Return Code of 3 (IS_EGRESS) may not necessarily be for the FEC being
being traced. It could be for one of the new FECs that was added. traced. It could be for one of the new FECs that was added. On
On receipt of an IS_EGRESS response, the LSP ingress should check if receipt of an IS_EGRESS reply, the LSP ingress should check if the
the depth of Target FEC sent to the node that just responded, was 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, 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 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 request with the same TTL (as previously sent). The process of
popping a FEC is to be repeated until either the LSP ingress receives popping a FEC is to be repeated until either the LSP ingress receives
a non-IS_EGRESS response or until all the additional FECs added to a non-IS_EGRESS reply or until all the additional FECs added to the
the FEC stack have already been popped. Using IS_EGRESS responses, FEC stack have already been popped. Using IS_EGRESS reply, an
an ingress can build a map of the hierarchical LSP structure ingress can build a map of the hierarchical LSP structure traversed
traversed by a given FEC. by a given FEC.
4.3.3. Handling of new return codes 4.3.3. Handling of new return codes
When the MPLS echo response Return Code is "Label switched with FEC When the MPLS echo reply 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 Equal Code for stitched LSPs and for hierarchical LSPs. In case of Equal
Cost Multi-Path (ECMP) or Point to Multi-Point (P2MP), there could be Cost Multi-Path (ECMP) or Point to Multi-Point (P2MP), there could be
multiple paths and downstream detailed mapping TLVs with different multiple paths and downstream detailed mapping TLVs with different
return codes (Section 3.2.1). The ingress node should build the return codes (Section 3.2.1). The ingress node should build the
topology based off the Return Code per ECMP path/P2MP branch. topology based on 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 MPLS echo request or in MUST never be sent together in the same MPLS echo request or in
the same MPLS echo response. the same MPLS echo reply.
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 reply contains a Return Code of 2 (one or
or more of the TLVs was not understood), then the sender of the more of the TLVs was not understood), then the sender of the echo
echo request MAY resend the echo request with the Downstream request MAY resend the echo request with the Downstream Mapping
Mapping TLV (instead of the Downstream Detailed Mapping TLV). In TLV (instead of the Downstream Detailed Mapping TLV). In cases
cases where a detailed response is needed, the sender can choose where a detailed reply is needed, the sender can choose to ignore
to ignore the router that does not support the Downstream Detailed the router that does not support the Downstream Detailed Mapping
Mapping TLV. 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 reply. 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 reply MAY contain
contain Downstream Mapping TLV(s). 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 label switched router (LSR) and is processed at an intermediate label switched router (LSR) and
then forwarded on; then the intermediate router is responsible for then forwarded on; then the intermediate router is responsible for
making sure that the TLVs being used among the ingress, making sure that the TLVs being used among the ingress,
intermediate and destination are consistent. The intermediate intermediate and destination are consistent. The intermediate
router MUST NOT forward an echo request or an echo response router MUST NOT forward an echo request or an echo reply
containing a Downstream Detailed Mapping TLV if it itself does not containing a Downstream Detailed Mapping TLV if it itself does not
support that TLV. support that TLV.
5. Security Considerations 5. Security Considerations
1. If a network operator wants to prevent tracing inside a tunnel, 1. If a network operator wants to prevent tracing inside a tunnel,
one can use the pipe mode [RFC3443], i.e. hide the outer MPLS 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 tunnel by not propagating the MPLS TTL into the outer tunnel (at
the start of the outer tunnel). By doing this, MPLS traceroute the start of the outer tunnel). By doing this, MPLS traceroute
packets will not expire in the outer tunnel and the outer tunnel packets will not expire in the outer tunnel and the outer tunnel
skipping to change at page 21, line 30 skipping to change at page 21, line 30
via Standards Action as defined in [RFC3692]; assignments in the via Standards Action as defined in [RFC3692]; assignments in the
range 16384-31743 and 49162-64511 are made via Specification Required range 16384-31743 and 49162-64511 are made via Specification Required
([RFC4379]); values in the range 31744-32767 and 64512-65535 are for ([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 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 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 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 Enterprise Code, in network octet order. The rest of the Value field
is private to the vendor. is private to the vendor.
It is requested that IANA assign sub-TLV types from this new registry It is requested that IANA assign sub-TLV types from this new registry
to the following sub-TLVs (See Figure 5). to the following sub-TLVs (See Section 3.3.1).
Multipath data sub-TLV: Suggested value: 1 Multipath data sub-TLV: Suggested value: 1
Label stack sub-TLV: Suggested value: 2 Label stack sub-TLV: Suggested value: 2
FEC Stack change sub-TLV: Suggested value: 3 FEC Stack change sub-TLV: Suggested value: 3
6.3. New Return Codes 6.3. New Return Codes
IANA is requested to assign new Return Code values from the "Multi- IANA is requested to assign new Return Code values from the "Multi-
skipping to change at page 22, line 34 skipping to change at page 22, line 34
8.2. Informative References 8.2. Informative References
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks", in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, January 2003. RFC 3443, January 2003.
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006. (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 [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. 60 change blocks. 
126 lines changed or deleted 126 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/