draft-ietf-mpls-lsp-ping-enhanced-dsmap-01.txt   draft-ietf-mpls-lsp-ping-enhanced-dsmap-02.txt 
Network Working Group N. Bahadur Network Working Group N. Bahadur
Internet-Draft K. Kompella Internet-Draft K. Kompella
Updates: RFC4379 (if approved) Juniper Networks, Inc. Updates: RFC4379 Juniper Networks, Inc.
G. Swallow (if approved) G. Swallow
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: March 25, 2009 September 21, 2008 Expires: August 5, 2009 February 1, 2009
Mechanism for performing LSP-Ping over MPLS tunnels Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-01 draft-ietf-mpls-lsp-ping-enhanced-dsmap-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 25, 2009. This Internet-Draft will expire on August 5, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes methods for performing lsp-ping traceroute This document describes methods for performing lsp-ping traceroute
over mpls tunnels and for traceroute of stitched mpls LSPs. The over mpls tunnels and for traceroute of stitched mpls LSPs. The
techniques outlined in RFC 4379 are insufficient to perform techniques outlined in RFC 4379 are insufficient to perform
traceroute FEC validation and path discovery for a LSP that goes over traceroute FEC validation and path discovery for a 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 15 skipping to change at page 2, line 23
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 5 3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 7 3.2.1. Return code per downstream . . . . . . . . . . . . . . 5
3.2.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 7 3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 5
3.2.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 8 3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 5
3.3. Deprecation of Downstream Mapping TLV . . . . . . . . . . 10 3.3.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 7
4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 10 3.3.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 8
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 10 3.3.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 8
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 10 3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 10
4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 11
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 11
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 11
4.1.2. Transition between tunnels . . . . . . . . . . . . . . 11 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 11
4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 13 4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 13
4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 13 4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 13
4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 13 4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 14
4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 13 4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 14
4.2.2. Modifications to handling to EGRESS_OK responses. . . 15 4.2.3. Handling of new return codes . . . . . . . . . . . . . 16
4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 15 4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
This documents describes methods for performing lsp-ping traceroute This documents describes methods for performing lsp-ping traceroute
over mpls tunnels. The techniques outlined in [RFC4379] outline a over mpls tunnels. The techniques outlined in [RFC4379] outline a
traceroute mechanism that includes FEC validation and ECMP path traceroute mechanism that includes FEC validation and ECMP path
discovery. Those mechanisms are insufficient and do not provide 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 LSP stitching is in use. This document tunnels and in case where LSP stitching is in use. This document
defines enhancements to the downstream-mapping TLV [RFC4379] to make defines enhancements to the downstream-mapping TLV [RFC4379] to make
skipping to change at page 5, line 15 skipping to change at page 5, line 15
neighbor. But the DSMAP format is not extensible and hence it's not neighbor. But the DSMAP format is not extensible and hence it's not
possible to associate more information with a downstream neighbor. possible to associate more information with a downstream neighbor.
This draft defines a new extensible format for the DSMAP and provides This draft defines a new extensible format for the DSMAP and provides
mechanisms for solving the tunneled lsp-ping problem using the new mechanisms for solving the tunneled lsp-ping problem using the new
format. In summary, the draft makes the following TLV changes: 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.
o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP. o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP.
3.2. Downstream Detailed Mapping TLV 3.2. New Return Codes
3.2.1. Return code per downstream
A new return code is being defined "See DDM TLV for Return Code and
Return SubCode" (Section 6.3) to indicate that the return code is per
Detailed Downstream Mapping TLV (Section 3.3). This return code MUST
be used only in the message header and MUST be set only in the echo
response message. If the return code is set in the echo request
message, then it SHOULD be ignored. When this return code is set,
each Detailed Downstream Mapping TLV MUST have an appropriate return
code and return subcode. This return code is to be used when there
are multiple downstreams for a given node (such as P2MP or ECMP), and
the node wants to return a different return code/return subcode for
each downstream.
3.2.2. Return code for stitched LSPs
When a traceroute is being performed on stitched LSPs Figure 10, the
stitching point SHOULD indicate the stitching action to the node
performing the trace. This is done by setting the return code to
"Label switched with FEC change" (Section 6.3). If a node is
performing FEC hiding, then it MAY choose to set the return code to a
value other than "Label switched with FEC change". This return code
MUST NOT be used if no Label Stack sub-TLVs (Section 3.3.3) are
present in the Detailed Downstream Mapping TLV(s). This new return
code MAY be used for hierarchical LSPs (for indicating start or end
of an outer LSP).
3.3. Downstream Detailed Mapping TLV
A new TLV has been added to the mandatory range of TLVs. The TLV A new TLV has been added to the mandatory range of TLVs. The TLV
type is pending IANA allocation. type is pending IANA allocation.
Type # Value Field Type # Value Field
------ ------------ ------ ------------
TBD Downstream detailed mapping TBD Downstream detailed mapping
Figure 3 Figure 3
skipping to change at page 6, line 14 skipping to change at page 6, line 31
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 IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) | | Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-tlv length | Reserved | | 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 coverted 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]. The newly
added sub-TLVs and their fields are as described below. added sub-TLVs and their fields are as described below.
Return code
The Return Code and Return SubCode are 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. The notation
<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 the value of Return Code and Return SubCode
in the Downstream Detailed Mapping TLV, then the receiver MUST set
the Return Code in the echo response header to "See DDM TLV for
Return Code and Return SubCode" Section 6.3).
If the Return Code of the echo response message is not set to "See
DDM TLV for Return Code and Return SubCode" Section 6.3, then the
Return Code and 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.
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.2.1. Multipath data sub-TLV 3.3.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].
3.2.2. Label stack sub-TLV 3.3.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 5 skipping to change at page 8, line 31
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 labels present in the sub-TLV is determined
based on the sub-TLV data length. Labels are treated as numbers, based on the sub-TLV data length. Labels are treated as numbers,
i.e., they are right justified in the field. 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 Detailed protocol type are as defined in [RFC4379]. When the Detailed
Downstream Mapping TLV in sent in the echo response, this sub-TLV Downstream Mapping TLV in sent in the echo response, this sub-TLV
MUST be included. MUST be included.
3.2.3. FEC Stack change sub-TLV 3.3.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 8, line 47 skipping to change at page 9, line 26
Operation Type Values Operation Type Values
A FEC Stack change sub-TLV containing a PUSH operation MUST NOT be 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. 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 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 operations. One FEC Stack change sub-TLV MUST be included per FEC
stack change. For example, if 2 labels are going to be pushed, 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 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 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 10) 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.
A Downstream detailed mapping TLV containing only 1 FEC change A Downstream detailed mapping TLV containing only 1 FEC change
sub-TLV with Pop operation is equivalent to EGRESS_OK for the sub-TLV with Pop operation is equivalent to EGRESS_OK for the
outermost FEC in the FEC stack. The ingress router performing 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 lsp trace MUST treat such a case as an EGRESS_OK for the outermost
FEC. FEC.
The Downstream Detailed Mapping TLV MUST contain at most 1 FEC The Downstream Detailed Mapping TLV MUST contain at most 1 FEC
Stack change sub-TLV of type Swap. In a FEC Stack change sub-TLV Stack change sub-TLV of type Swap. In a FEC Stack change sub-TLV
with Swap operation, the address-type MAY be set to Unspecified with Swap operation, the address-type MAY be set to Unspecified
skipping to change at page 9, line 39 skipping to change at page 10, line 16
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 10: Remote peer address type Figure 9: Remote peer address type
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 helpful
information regarding FEC peers. If the operation type is PUSH, information regarding FEC peers. If the operation type is PUSH,
the remote peer address is the address of the peer from which the the remote peer address is the address of the peer from which the
skipping to change at page 10, line 19 skipping to change at page 10, line 43
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.
3.3. 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.3. the new tlv are specified in Section 4.3.
4. Performing lsp-ping traceroute on tunnels 4. Performing lsp-ping traceroute on tunnels
This section describes the procedures to be followed by an ingress This section describes the procedures to be followed by an ingress
node and transit nodes when performing lsp-ping traceroute over mpls node and transit nodes when performing lsp-ping 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.2.3) to the SHOULD add the a FEC Stack change sub-TLV (Section 3.3.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 MAY leave it as
unspecified. unspecified.
skipping to change at page 11, line 21 skipping to change at page 11, line 47
change sub-TLV of operation type PUSH, per new tunnel being change sub-TLV of operation type PUSH, per new tunnel being
originated at the transit node. originated at the transit node.
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 10: 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. operation for the RSVP FEC. Nodes C and D SHOULD set the return code
to "Label switched with FEC change" (Section 6.3) to indicate change
in FEC being traced.
If node C wishes to perform FEC hiding, it SHOULD respond back with 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 not include the FEC TLV (by setting FEC TLV operation MAY either exclude the FEC TLV (by setting FEC TLV length
length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation
operation SHOULD have the FEC TLV contain the NIL FEC. SHOULD have the FEC TLV containing the NIL FEC. The return code
SHOULD be set to "Label switched with FEC change".
If node C performs FEC hiding and node D also performs FEC hiding, 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). If node D performs FEC hiding, then node F will respond as FEC). In such a case, node D MUST NOT set the return code to "Label
EGRESS_OK for the NIL FEC. The ingress (node A) will know that switched with FEC change". If node D performs FEC hiding, then node
EGRESS_OK corresponds to the end-to-end LSP. F will respond as EGRESS_OK for the NIL FEC. The ingress (node A)
will know that EGRESS_OK 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 11: Hierarchical LSPs
In the above figure, the following sequence of FEC Stack change sub- In the above figure, the following sequence of FEC Stack change sub-
TLVs will be performed 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 EGRESS_OK when RSVP-A is top of FEC stack. Downstream Respond with a return code of EGRESS_OK when RSVP-A is top of FEC
information for node E when echo request contains RSVP-B as top of stack. Downstream information for node E when echo request contains
FEC stack. RSVP-B 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 EGRESS_OK (if D can co-relate that the NIL-FEC Respond with either return code of EGRESS_OK (if D can co-relate that
corresponds to RSVP-A which is terminating at D) or respond with FEC the NIL-FEC corresponds to RSVP-A which is terminating at D) or
Stack change sub-TLV: POP (since D knows that number of labels respond with FEC Stack change sub-TLV: POP (since D knows that number
towards next-hop is decreasing). of 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 12: 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). RSVP). Nodes C and D SHOULD set the return code to "Label switched
with FEC change" (Section 6.3) to indicate change in FEC being
traced.
4.2. Ingress node procedure 4.2. 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 lsp 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.2.1. Processing Downstream Detailed Mapping TLV 4.2.1. Processing Downstream Detailed Mapping TLV
skipping to change at page 13, line 32 skipping to change at page 14, line 13
[RFC4379] [RFC4379]
4.2.1.1. Stack Change sub-TLV not present 4.2.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 echo response processing as per the
procedures in [RFC4379]. procedures in [RFC4379].
4.2.1.2. Stack Change sub-TLV(s) present 4.2.1.2. Stack Change sub-TLV(s) present
If one or more FEC Stack change sub-TLVs (Section 3.2.3) are received If one or more FEC Stack change sub-TLVs (Section 3.3.3) are received
in the echo response, the ingress node SHOULD process them and in the echo response, the ingress node SHOULD process them and
perform some validation. 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.
skipping to change at page 14, line 46 skipping to change at page 15, 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 14: FEC Stack Change Sub-TLV Processing Guideline Figure 13: FEC Stack Change Sub-TLV Processing Guideline
The next echo request along the same path should use the modified FEC The next echo request along the same path should use the modified FEC
stack obtained after processing the FEC Stack change sub-TLVs. A stack obtained after processing the FEC Stack change sub-TLVs. A
non-NIL FEC guarantees that the next echo request along the same path non-NIL FEC guarantees that the next echo request along the same path
will have the Downstream Detailed Mapping TLV validated for IP will have the Downstream Detailed Mapping TLV validated for IP
address, Interface address and label stack mismatches. 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 echo response 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
skipping to change at page 15, line 33 skipping to change at page 16, line 33
EGRESS_OK response, the ingress should check if the depth of Target EGRESS_OK response, the ingress should check if the depth of Target
FEC sent to the node that just responded, was the same as the depth FEC sent to the node that just responded, was the same as the depth
of the FEC that was being traced. If it was not, then it should pop of the FEC that was being traced. If it was not, then it should pop
the an entry from the Target FEC stack and resend the request with the an entry from the Target FEC stack and resend the request with
the same TTL (as previously sent). The process of popping a FEC is the same TTL (as previously sent). The process of popping a FEC is
to be repeated until either the ingress receives a non-EGRESS_OK to be repeated until either the ingress receives a non-EGRESS_OK
response or until all the additional FECs added to the FEC stack have response or until all the additional FECs added to the FEC stack have
already been popped. Using EGRESS_OK responses, an ingress can build already been popped. Using EGRESS_OK responses, an ingress can build
a map of the hierarchical LSP structure traversed by a given FEC. a map of the hierarchical LSP structure traversed by a given FEC.
4.2.3. Handling of new return codes
When the echo response return code is "Label switched with FEC
change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC
stack as per the FEC Stack change sub-TLVs contained in the detailed
downstream mapping TLV. A transit node can use this return code for
stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP,
there could be multiple paths and detailed downstream mapping TLVs
with different return codes (Section 3.2.1). The ingress node should
build the topology based off the return code per ECMP path/P2MP
branch.
4.3. Handling deprecated Downstream Mapping TLV 4.3. 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 echo request or in the
same echo response. same echo response.
skipping to change at page 16, line 49 skipping to change at page 18, line 12
information from other domains. Detailed operation regarding the information from other domains. Detailed operation regarding the
same is outside the scope of this document. Passing of FEC stack same is outside the scope of this document. Passing of FEC stack
change information between domains MAY be done if the two AS domains change information between domains MAY be done if the two AS domains
belong to the same provider/organization. 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
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.
Downstream Detailed Mapping TLV (See Section 3.2). Suggested value: Downstream Detailed Mapping TLV (See Section 3.3). Suggested value:
20. 20.
6.2. New Sub-TLV types and associated registry
IANA is requested to create a new registry for the Sub-Type field of IANA is requested to create a new registry for the Sub-Type field of
Downstream Detailed Mapping TLV. The valid range for this is Downstream Detailed Mapping TLV. The valid range for this is
0-65535. Assignments in the range 0-16383 and 32768-49161 are made 0-65535. Assignments in the range 0-16383 and 32768-49161 are made
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
skipping to change at page 17, line 31 skipping to change at page 18, line 45
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 Figure 5).
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
IANA is requested to assign new Return Code values from the "Multi-
Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Parameters" registry, "Return Codes" sub-registry as follows using a
Standards Action value.
Value Meaning
----- -------
TBD See DDM TLV for Return Code and Return SubCode
TBD Label switched with FEC change
Suggested values: 14 and 15 respectively
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Yakov Rekhter and Adrian Farrel for The authors would like to thank Yakov Rekhter and Adrian Farrel for
their suggestions on the draft. their suggestions on the draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 19, line 4 skipping to change at line 855
URI: www.juniper.net URI: www.juniper.net
George Swallow George Swallow
Cisco Systems Cisco Systems
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
US US
Email: swallow@cisco.com Email: swallow@cisco.com
URI: www.cisco.com URI: www.cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 37 change blocks. 
62 lines changed or deleted 153 lines changed or added

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