One document matched: draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc3978.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3443.xml">
<!ENTITY RFC3692 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3692.xml">
<!ENTITY RFC4379 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC4461 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4461.xml">
<!ENTITY RFC5150 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5150.xml">
<!ENTITY RFC5331 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5331.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-ietf-mpls-lsp-ping-enhanced-dsmap-11"
ipr="pre5378Trust200902" updates="4379">
<front>
<title abbrev="LSP-Ping over MPLS tunnel">Mechanism for performing
LSP-Ping over MPLS tunnels</title>
<author fullname="Nitin Bahadur" initials="N.B." surname="Bahadur">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<phone>+1 408 745 2000</phone>
<email>nitinb@juniper.net</email>
<uri>www.juniper.net</uri>
</address>
</author>
<author fullname="Kireeti Kompella" initials="K.K." surname="Kompella">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<phone>+1 408 745 2000</phone>
<email>kireeti@juniper.net</email>
<uri>www.juniper.net</uri>
</address>
</author>
<author fullname="George Swallow" initials="G.S" surname="Swallow">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Ave</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>US</country>
</postal>
<email>swallow@cisco.com</email>
<uri>www.cisco.com</uri>
</address>
</author>
<date day="10" month="September" year="2011" />
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>MPLS OAM</keyword>
<keyword>lsp ping</keyword>
<abstract>
<t>This document describes methods for performing LSP-Ping (specified in
RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched
MPLS label-switched-paths (LSPs). The techniques outlined in RFC 4379
are insufficient to perform traceroute Forwarding Equivalency Class
(FEC) validation and path discovery for an LSP that goes over other MPLS
tunnels or for a stitched LSP. This document describes enhancements to
the downstream-mapping TLV (defined in RFC 4379). These enhancements
along with other procedures outlined in this document can be used to
trace such LSPs.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This documents describes methods for performing LSP-Ping (specified
in <xref target="RFC4379"></xref>) traceroute over MPLS tunnels. The
techniques in <xref target="RFC4379"></xref> outline a traceroute
mechanism that includes Forwarding Equivalency Class (FEC) validation
and Equal Cost Multi-Path (ECMP) path discovery. Those mechanisms are
insufficient and do not provide details when the FEC being traced
traverses one or more MPLS tunnels and when label-switched-path (LSP)
stitching <xref target="RFC5150"></xref> is in use. This document
defines enhancements to the downstream-mapping TLV <xref
target="RFC4379"></xref> to make it more extensible and to enable
retrieval of detailed information. Using the enhanced TLV format along
with the existing definitions of <xref target="RFC4379"></xref>, this
document describes procedures by which a traceroute request can
correctly traverse MPLS tunnels with proper FEC and label
validations.</t>
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="motivation" title="Motivation" toc="default">
<t>A LSP-Ping traceroute may cross multiple MPLS tunnels en-route the
destination. Let us consider a simple case.</t>
<figure anchor="tunnel-fig" title="LDP over RSVP tunnel">
<artwork align="left"><![CDATA[
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
]]></artwork>
</figure>
<t>When a traceroute is initiated from router A, router B returns
downstream mapping information for node C in the MPLS echo reply. The
next MPLS echo request reaches router C with a LDP FEC. Node C 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 stack.
Consequently, node C will be unable to perform FEC complete validation.
It will let the trace continue by just providing next-hop information
based on incoming label, and by looking up the forwarding state
associated with that label. However, ignoring FEC validation defeats the
purpose of control plane validatations. The MPLS echo request should
contain sufficient information to allow node C to perform FEC
validations to catch any misrouted echo-requests.</t>
<t>The above problem can be extended for a generic case of hierarchical
tunnels or stitched tunnels (e.g. B-C can be a separate RSVP tunnel and
C-D can be a separate RSVP tunnel). The problem of FEC validation for
tunnels can be solved if the transit routers (router B in the above
example) provide some information to the ingress regarding the start of
a new tunnel.</t>
<t>Stitched LSPs involve 2 or more LSP segments stitched together. The
LSP segments can be signaled using the same or different signaling
protocols. In order to perform an end-to-end trace of a stitched LSP,
the ingress needs to know FEC information regarding each of the stitched
LSP segments. For example, consider the figure below.</t>
<figure anchor="stitched-lsp-fig" title="Stitched LSP">
<artwork align="left"><![CDATA[
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
]]></artwork>
</figure>
<t>Consider ingress (A) tracing end-to-end stitched LSP A--F. When an
MPLS echo request reaches router C, there is a FEC stack change
happening at router C. With current LSP-Ping <xref
target="RFC4379"></xref> mechanisms, there is no way to convey this
information to A. Consequently, when the next echo request reaches
router D, router D will know nothing about the LDP FEC that A is trying
to trace.</t>
<t>Thus, the procedures defined in <xref target="RFC4379"></xref> do not
make it possible for the ingress node to:</t>
<t><list style="numbers">
<t>Know that tunneling has occured</t>
<t>Trace the path of the tunnel</t>
<t>Trace the path of stitched LSPs</t>
</list></t>
</section>
<section anchor="packet-format" title="Packet format" toc="include">
<t></t>
<section anchor="pkt-format-intro" title="Introduction" toc="include">
<t>In many cases there has been a need to associate additional data in
the MPLS echo reply. In most cases, the additional data needs to be
associated on a per downstream neighbor basis. Currently, the MPLS
echo reply contains one downstream map TLV (DSMAP) per downstream
neighbor. However the DSMAP format is not extensible and hence it is
not possible to associate more information with a downstream neighbor.
This draft defines a new extensible format for the DSMAP and provides
mechanisms for solving the tunneled LSP-Ping problem using the new
format. In summary, the draft makes the following TLV changes:</t>
<t><list style="symbols">
<t>Addition of new Downstream Detailed Mapping TLV (DDMAP).</t>
<t>Deprecation of existing Downstream Mapping TLV (DSMAP).</t>
<t>Addition of Downstream FEC Stack Change Sub-TLV to DDMAP.</t>
</list></t>
</section>
<section title="New Return Codes">
<section anchor="rc-per-ddmap" title="Return code per downstream">
<t>A new Return Code is being defined "See DDM TLV for Return Code
and Return SubCode" (<xref target="new-return-code"></xref>) to
indicate that the Return Code is per Downstream Detailed Mapping TLV
(<xref target="ddmap-tlv"></xref>). This Return Code MUST be used
only in the message header and MUST be set only in the MPLS echo
reply message. If the Return Code is set in the MPLS echo request
message, then it MUST be ignored. When this Return Code is set, each
Downstream Detailed Mapping TLV MUST have an appropriate Return Code
and Return SubCode. This Return Code MUST be used when there are
multiple downstreams for a given node (such as P2MP or ECMP), and
the node needs to return a Return Code/Return SubCode for each
downstream. This Return Code MAY be used even when there is only 1
downstream for a given node.</t>
</section>
<section anchor="rc-for-stitched"
title="Return code for stitched LSPs">
<t>When a traceroute is being performed on stitched LSPs (<xref
target="stitched-lsp-proc"></xref>) 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" (<xref target="new-return-code"></xref>). If a node is
performing FEC hiding, then it MAY choose to set the Return Code to
a value (specified in <xref target="RFC4379"></xref>) other than
"Label switched with FEC change". The Return Code of "Label switched
with FEC change" MUST NOT be used if no FEC Stack sub-TLV (<xref
target="dsmap-fec-stack-tlv"></xref>) is present in the Downstream
Detailed Mapping TLV(s). This new Return Code MAY be used for
hierarchical LSPs (for indicating start or end of an outer LSP).</t>
</section>
</section>
<section anchor="ddmap-tlv" title="Downstream Detailed Mapping TLV">
<figure>
<artwork><![CDATA[
Type # Value Field
------ ------------
TBD Downstream detailed mapping
]]></artwork>
</figure>
<t>The Downstream Detailed Mapping object is a TLV that MAY be
included in an MPLS echo request message. Only one Downstream Detailed
Mapping object may appear in an echo request. The presence of a
Downstream Detailed Mapping object is a request that Downstream
Detailed Mapping objects be included in the MPLS echo reply. If the
replying router is the destination (Label Edge Router) of the FEC,
then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
MPLS echo reply. Otherwise the replying router SHOULD include a
Downstream Detailed Mapping object for each interface over which this
FEC could be forwarded.</t>
<figure anchor="dsmap-detailed-format"
title="Downstream Detailed Mapping TLV">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return SubCode| Sub-tlv length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Downstream Detailed Mapping TLV format is derived from the
Downstream Mapping TLV format. The key change is that variable length
and optional fields have been converted into sub-TLVs. The fields have
the same use and meaning as in <xref target="RFC4379"></xref>. A
summary of the fields taken from Downstream Mapping TLV is as
below:</t>
<t>Maximum Transmission Unit (MTU)</t>
<t><list style="empty">
<t>The MTU is the size in octets of the largest MPLS frame
(including label stack) that fits on the interface to the
Downstream LSR.</t>
<t></t>
</list>Address Type</t>
<t><list style="empty">
<t>The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the Downstream IP
Address and Downstream Interface fields.</t>
<t></t>
</list></t>
<t>DS Flags</t>
<t><list style="empty">
<t>The DS Flags field is a bit vector of various flags.</t>
<t></t>
</list>Downstream Address and Downstream Interface Address</t>
<t><list style="empty">
<t>IPv4 addresses and interface indices are encoded in 4 octets;
IPv6 addresses are encoded in 16 octets. For details regarding
setting the address value, refer to <xref
target="RFC4379"></xref>.</t>
</list></t>
<t>The newly added sub-TLVs and their fields are as described
below.</t>
<t>Return code<list style="empty">
<t>The Return Code is set to zero by the sender. The receiver can
set it to one of the values specified in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
"Return Codes" sub-registry.</t>
<t></t>
<t>If the receiver sets a non-zero value of the Return Code field
in the Downstream Detailed Mapping TLV, then the receiver MUST
also set the Return Code field in the echo reply header to "See
DDM TLV for Return Code and Return SubCode" (<xref
target="new-return-code"></xref>). An exception to this is if the
receiver is a bud node <xref target="RFC4461"></xref> and is
replying as both an egress and a transit node with a Return Code
of 3 ("Replying router is an egress for the FEC") in the echo
reply header.</t>
<t></t>
<t>If the Return Code of the echo reply message is not set to
either "See DDM TLV for Return Code and Return SubCode" (<xref
target="new-return-code"></xref>) or "Replying router is an egress
for the FEC", then the Return Code specified in the Downstream
Detailed Mapping TLV MUST be ignored.</t>
</list></t>
<t>Return SubCode</t>
<t><list style="empty">
<t>The Return SubCode is set to zero by the sender. The receiver
can set it to one of the values specified in the "Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Parameters"
registry, "Return Codes" sub-registry. This field is filled in
with the stack-depth for those codes that specify that. For all
other codes, the Return SubCode MUST be set to zero.</t>
<t></t>
<t>If the Return Code of the echo reply message is not set to
either "See DDM TLV for Return Code and Return SubCode" (<xref
target="new-return-code"></xref>) or "Replying router is an egress
for the FEC", then the Return SubCode specified in the Downstream
Detailed Mapping TLV MUST be ignored.</t>
</list></t>
<t>Sub-tlv length<list style="empty">
<t>Total length in bytes of the sub-TLVs associated with this
TLV.</t>
</list></t>
<section anchor="ddmap-sub-tlvs" title="Sub-TLVs" toc="include">
<t>This section defines the Sub-TLVs that MAY be included as part of
the Downstream Detailed Mapping TLV.</t>
<figure>
<artwork><![CDATA[
Sub-Type Value Field
--------- ------------
TBD Multipath data
TBD Label stack
TBD FEC Stack change
]]></artwork>
</figure>
<section title="Multipath data sub-TLV" toc="include">
<figure anchor="multipath-sub-tlv" title="Multipath Sub-TLV">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The multipath data sub-TLV includes multipath information. The
sub-TLV fields and their usage is as defined in <xref
target="RFC4379"></xref>. A brief summary of the fields is as
below:</t>
<t>Multipath Type</t>
<t><list style="empty">
<t>The type of the encoding for the Multipath Information.</t>
</list></t>
<t>Multipath Length</t>
<t><list style="empty">
<t>The length in octets of the Multipath Information.</t>
</list></t>
<t>Multipath Information</t>
<t><list style="empty">
<t>Encoded multipath data, according to the Multipath
Type.</t>
</list></t>
</section>
<section title="Label stack sub-TLV">
<figure anchor="label-stack-sub-tlv" title="Label Stack Sub-TLV">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Label stack sub-TLV contains the set of labels in the label
stack as it would have appeared if this router were forwarding the
packet through this interface. Any Implicit Null labels are
explicitly included. The number of label/protocol pairs present in
the sub-TLV is determined based on the sub-TLV data length. The
label format and protocol type are as defined in <xref
target="RFC4379"></xref>. When the Downstream Detailed Mapping TLV
is sent in the echo reply, this sub-TLV MUST be included.</t>
<t>Downstream Label</t>
<t><list style="empty">
<t>A Downstream Label is 24 bits, in the same format as an
MPLS label minus the TTL field, i.e., the MSBit of the label
is bit 0, the LSBit is bit 19, the EXP bits are bits 20-22,
and bit 23 is the S bit. The replying router SHOULD fill in
the EXP and S bits; the LSR receiving the echo reply MAY
choose to ignore these bits.</t>
</list></t>
<t>Protocol</t>
<t><list style="empty">
<t>This specifies the label distribution protocol for the
downstream label.</t>
</list></t>
</section>
<section anchor="dsmap-fec-stack-tlv"
title="FEC Stack change sub-TLV">
<t>A router MUST include the FEC Stack change sub-TLV when the
downstream node in the echo reply has a different FEC Stack than
the FEC stack received in the echo request. One or more FEC Stack
change sub-TLVs MAY be present in the Downstream Detailed Mapping
TLV. The format is as below.</t>
<figure anchor="dsmap-fec-change-format"
title="FEC Stack Change Sub-TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Operation Type</t>
<t hangText="4"><list style="empty">
<t>The operation type specifies the action associated with the
FEC stack change. The following operation types are
defined.</t>
</list></t>
<figure>
<artwork><![CDATA[
Type # Operation
------ ---------
1 Push
2 Pop
]]></artwork>
</figure>
<t>Address Type</t>
<t hangText="4"><list style="empty">
<t>The Address Type indicates the remote peer's address type.
The Address Type is set to one of the following values. The
peer address length is determined based on the address type.
The address type MAY be different from the address type
included in the Downstream Detailed Mapping TLV. This can
happen when the LSP goes over a tunnel of a different address
family. The address type MAY be set to Unspecified if the
peer-address is either unavailable or the transit router does
not wish it provide it for security or administrative
reasons.</t>
</list></t>
<figure>
<artwork><![CDATA[
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0
1 IPv4 4
2 IPv6 16
]]></artwork>
</figure>
<t hangText="4">FEC tlv Length<list style="empty">
<t>Length in bytes of the FEC TLV.</t>
</list></t>
<t hangText="4">Reserved<list style="empty">
<t>This field is reserved for future use and MUST be set to
zero.</t>
</list></t>
<t hangText="4">Remote peer address</t>
<t hangText="4"><list style="empty">
<t>The remote peer address specifies the remote peer which is
the next-hop for the FEC being currently traced. E.g. in the
LDP over RSVP case <xref target="tunnel-fig"></xref>, router B
would respond back with the address of router D as the remote
peer address for the LDP FEC being traced. This allows the
ingress node to provide information regarding FEC peers. If
the operation type is PUSH, the remote peer address is the
address of the peer from which the FEC being pushed was
learnt. If the operation type is POP, the remote peer address
MAY be set to Unspecified. </t>
<t>For upstream assigned labels <xref
target="RFC5331"></xref>, an operation type of POP will have a
remote peer address (the upstream node that assigned the
label) and this SHOULD be included in the FEC Stack change
sub-TLV. The remote peer address MAY be set to Unspecified, if
the address needs to be hidden.</t>
</list></t>
<t hangText="4">FEC TLV<list style="empty">
<t>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 operation. This TLV MAY be included when the
operation type is POP. It MUST be included when the operation
type is PUSH. The FEC TLV contains exactly 1 FEC from the list
of FECs specified in <xref target="RFC4379"></xref>. A NIL FEC
MAY be associated with a PUSH operation if the responding
router wishes to hide the details of the FEC being pushed.</t>
</list></t>
<t hangText="4">FEC Stack change sub-TLV operation rules:<list
style="letters">
<t>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.</t>
<t>One or more POP operations MAY be followed by one or more
PUSH operations.</t>
<t>One FEC Stack change sub-TLV MUST be included per FEC stack
change. For example, if 2 labels are going to be pushed, then
1 FEC Stack change sub-TLV MUST be included for each FEC.</t>
<t>A FEC splice operation (an operation where 1 FEC ends and
another FEC starts, see <xref
target="multiple-tunnel-fig"></xref>) MUST be performed by
including a POP type FEC Stack change sub-TLV followed by a
PUSH type FEC Stack change sub-TLV.</t>
<t>A Downstream detailed mapping TLV containing only 1 FEC
Stack Change sub-TLV with Pop operation is equivalent to
IS_EGRESS (Return code 3, <xref target="RFC4379"></xref>) for
the outermost FEC in the FEC stack. The ingress router
performing the MPLS traceroute MUST treat such a case as an
IS_EGRESS for the outermost FEC.</t>
</list></t>
</section>
</section>
</section>
<section title="Deprecation of Downstream Mapping TLV">
<t>This document deprecates the Downstream Mapping TLV. LSP-ping
procedures should now use the Downstream Detailed Mapping TLV.
Detailed procedures regarding interoperability between the deprecated
TLV and the new TLV are specified in <xref
target="old-dsmap-procedure"></xref>.</t>
</section>
</section>
<section anchor="method" title="Performing MPLS traceroute on tunnels"
toc="include">
<t>This section describes the procedures to be followed by an LSP
ingress node and LSP transit nodes when performing MPLS traceroute over
MPLS tunnels.</t>
<section anchor="transit-proc" title="Transit node procedure">
<section title="Addition of a new tunnel" toc="include">
<t>A transit node (<xref target="tunnel-fig"></xref>) knows when the
FEC being traced is going to enter a tunnel at that node. Thus, it
knows about the new outer FEC. All transit nodes that are the
origination point of a new tunnel SHOULD add the a FEC Stack change
sub-TLV (<xref target="dsmap-fec-stack-tlv"></xref>) to the
Downstream Detailed Mapping TLV (<xref
target="dsmap-detailed-format"></xref>) in the echo reply. The
transit node SHOULD add 1 FEC Stack change sub-TLV of operation type
PUSH, per new tunnel being originated at the transit node.</t>
<t>A transit node that sends a Downstream FEC Stack change sub-TLV
in the echo reply SHOULD fill the address of the remote peer; which
is the peer of the current LSP being traced. If the transit node
does not know the address of the remote peer, it MUST set the
address type to Unspecified.</t>
<t>The Label stack sub-TLV MUST contain 1 additional label per FEC
being PUSHed. The label MUST be encoded as per <xref
target="label-stack-sub-tlv"></xref>. The label value 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 expire in the
middle of the new tunnel, then a FEC Stack change sub-TLV SHOULD NOT
be added and the Label stack sub-TLV SHOULD NOT contain a label
corresponding to the hidden tunnel.</t>
<t>If the transit node wishes to hide the nature of the tunnel from
the ingress of the echo request, then it MAY not want to send
details about the new tunnel FEC to the ingress. In such a case, the
transit node SHOULD use the NIL FEC. The echo reply would then
contain a FEC Stack change sub-TLV with operation type PUSH and a
NIL FEC. The value of the label in the NIL FEC MUST be set to zero.
The remote peer address type MUST be set to Unspecified. The transit
node SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH,
per new tunnel being originated at the transit node. The Label stack
sub-TLV MUST contain 1 additional label per FEC being PUSHed. The
label value MUST be the value used to switch the data traffic.</t>
</section>
<section anchor="stitched-lsp-proc" title="Transition between tunnels"
toc="include">
<figure anchor="multiple-tunnel-fig" title="Stitched LSPs">
<artwork align="left"><![CDATA[
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
]]></artwork>
</figure>
<t>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 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-TLVs, one with a POP operation for the BGP FEC and one with a
PUSH operation for the RSVP FEC. Nodes C and D SHOULD set the Return
Code to "Label switched with FEC change" (<xref
target="new-return-code"></xref>) to indicate change in FEC being
traced.</t>
<t>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 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 SHOULD have the FEC TLV containing the NIL FEC. The Return
Code SHOULD be set to "Label switched with FEC change".</t>
<t>If node C performs FEC hiding and node D also performs FEC
hiding, then node D MAY choose to not send any FEC Stack change
sub-TLVs in the echo reply since the number of labels has not
changed (for the downstream of node D) and the FEC type also has not
changed (NIL FEC). In such a case, node D MUST NOT set the Return
Code to "Label switched with FEC change". If node D performs FEC
hiding, then node F will respond as IS_EGRESS for the NIL FEC. The
ingress (node A) will know that IS_EGRESS corresponds to the
end-to-end LSP.</t>
<figure align="left" anchor="hierarchical-lsp-fig"
title="Hierarchical LSPs">
<artwork align="left"><![CDATA[
A B C D E F
o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP
| \_______________________________/|
| RSVP-B |
\________________________________/
LDP
]]></artwork>
</figure>
<t>In the above figure, we have an end-to-end LDP LSP between nodes
A and F. The LDP LSP goes over RSVP LSP RSVP-B. LSP RSVP-B itself
goes over another RSVP LSP RSVP-A. When node A initiates a
traceroute for the end-to-end LDP LSP, then following sequence of
FEC Stack change sub-TLVs will be performed</t>
<t>Node B:</t>
<t>Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH
RSVP-A.</t>
<t>Node D:</t>
<t>Respond with a Return Code of 3 when RSVP-A is top of FEC stack.
When the echo request contains RSVP-B as top of stack, respond with
Downstream information for node E and an appropriate Return
Code.</t>
<t>If node B is performing tunnel hiding, then:</t>
<t>Node B:</t>
<t>Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH
NIL-FEC.</t>
<t>Node D:</t>
<t>If D can co-relate that the NIL-FEC corresponds to RSVP-A, which
terminates at D, then it SHOULD Respond with Return Code of 3. D can
also respond with FEC Stack change sub-TLV: POP (since D knows that
number of labels towards next-hop is decreasing). Both responses
would be valid.</t>
<figure anchor="stitched-hierarchical-lsp-fig"
title="Stitched hierarchical LSPs">
<artwork align="left"><![CDATA[
A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP
\_____________/
LDP
]]></artwork>
</figure>
<t>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 RSVP). Nodes C and D SHOULD set the Return Code to "Label
switched with FEC change" (<xref target="new-return-code"></xref>)
to indicate change in FEC being traced.</t>
</section>
<section title="Modification to FEC Validation procedure on Transit"
toc="include">
<t><xref target="RFC4379">Section 4.4 of </xref> specifies Target
FEC stack validation procedures. This document enhances the FEC
validation procedures as follows. If the outermost FEC of the target
FEC stack is the NIL FEC, then the node MUST skip the target FEC
validation completely. This is to support FEC hiding, in which the
outer hidden FEC can be the NIL FEC.</t>
</section>
</section>
<section title="Modification to FEC Validation procedure on Egress">
<t><xref target="RFC4379">Section 4.4 of</xref> specifies Target FEC
stack validation procedures. This document enhances the FEC validation
procedures as follows. If the outermost FEC of the target FEC stack is
the NIL FEC, then the node MUST skip the target FEC validation
completely. This is to support FEC hiding, in which the outer hidden
FEC can be the NIL FEC.</t>
</section>
<section anchor="ingress-proc" title="Ingress node procedure"
toc="include">
<t>It is the responsibility of an ingress node to understand tunnel
within tunnel semantics and LSP stitching semantics when performing a
MPLS traceroute. This section describes the ingress node procedure
based on the kind of reply an ingress node receives from a transit
node.</t>
<section title="Processing Downstream Detailed Mapping TLV"
toc="include">
<t>Downstream Detailed Mapping TLV should be processed in the same
way as the Downstream Mapping TLV, defined in Section 4.4 of <xref
target="RFC4379"></xref>. This section describes the procedures for
processing the new elements introduced in this document.</t>
<section anchor="no-target-fec"
title="Stack Change sub-TLV not present" toc="include">
<t>This would be the default behavior as described in <xref
target="RFC4379"></xref>. The ingress node MUST perform MPLS echo
reply processing as per the procedures in <xref
target="RFC4379"></xref>.</t>
</section>
<section title="Stack Change sub-TLV(s) present" toc="include">
<t>If one or more FEC Stack change sub-TLVs (<xref
target="dsmap-fec-stack-tlv"></xref>) are received in the MPLS
echo reply, the ingress node SHOULD process them and perform some
validation.</t>
<t>The FEC stack changes are associated with a downstream neighbor
and along a particular path of the LSP. Consequently, the ingress
will need to maintain a FEC-stack per path being traced (in case
of multipath). All changes to the FEC stack resulting from the
processing of FEC Stack change sub-TLV(s) should be applied only
for the path along a given downstream neighbor. The following
algorithm should be followed for processing FEC Stack change
sub-TLVs.</t>
<figure align="left" anchor="fec-change-tlv-processing"
title="FEC Stack Change Sub-TLV Processing Guideline">
<artwork><![CDATA[
push_seen = FALSE
fec_stack_depth = current-depth-of-fec-stack-being-traced
saved_fec_stack = current_fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
if (sub-tlv == NULL) break
if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Pop FEC from FEC stack being traced
fec_stack_depth--;
}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
]]></artwork>
</figure>
<t>The next MPLS echo request along the same path should use the
modified FEC stack obtained after processing the FEC Stack change
sub-TLVs. A non-NIL FEC guarantees that the next echo request
along the same path will have the Downstream Detailed Mapping TLV
validated for IP address, Interface address and label stack
mismatches.</t>
<t>If the top of the FEC stack is a NIL FEC and the MPLS echo
reply does not contain any FEC Stack change sub-TLV, then it does
not necessarily mean that the LSP has not started traversing a
different tunnel. It could be that the LSP associated with the NIL
FEC terminated at a transit node and at the same time a new LSP
started at the same transit node. The NIL FEC would now be
associated with the new LSP (and the ingress has no way of knowing
this). Thus, it is not possible to build an accurate hierarchical
LSP topology if a traceroute contains NIL FECs.</t>
</section>
</section>
<section title="Modifications to handling to Return Code 3 reply."
toc="include">
<t>The procedures above allow the addition of new FECs to the
original FEC being traced. Consequently, a reply from a downstream
node with Return Code of 3 (IS_EGRESS) may not necessarily be for
the FEC being traced. It could be for one of the new FECs that was
added. On receipt of an IS_EGRESS reply, the LSP ingress should
check if the depth of Target FEC sent to the node that just
responded, was the same as the depth of the FEC that was being
traced. If it was not, then it should pop an entry from the Target
FEC stack and resend the request with the same TTL (as previously
sent). The process of popping a FEC is to be repeated until either
the LSP ingress receives a non-IS_EGRESS reply or until all the
additional FECs added to the FEC stack have already been popped.
Using IS_EGRESS reply, an ingress can build a map of the
hierarchical LSP structure traversed by a given FEC.</t>
</section>
<section title="Handling of new return codes">
<t>When the MPLS echo reply Return Code is "Label switched with FEC
change" (<xref target="rc-for-stitched"></xref>), the ingress node
SHOULD manipulate the FEC stack as per the FEC Stack change sub-TLVs
contained in the downstream detailed mapping TLV. A transit node can
use this Return Code for stitched LSPs and for hierarchical LSPs. In
case of Equal Cost Multi-Path (ECMP) or Point to Multi-Point (P2MP),
there could be multiple paths and downstream detailed mapping TLVs
with different return codes (<xref target="rc-per-ddmap"></xref>).
The ingress node should build the topology based on the Return Code
per ECMP path/P2MP branch.</t>
</section>
</section>
<section anchor="old-dsmap-procedure"
title="Handling deprecated Downstream Mapping TLV"
toc="include">
<t>The Downstream Mapping TLV has been deprecated. Applications should
now use the Downstream Detailed Mapping TLV. The following procedures
SHOULD be used for backward compatibility with routers that do not
support the Downstream Detailed Mapping TLV.</t>
<t><list style="symbols">
<t>The Downstream Mapping TLV and the Downstream Detailed Mapping
TLV MUST never be sent together in the same MPLS echo request or
in the same MPLS echo reply.</t>
<t>If the echo request contains a Downstream Detailed Mapping TLV
and the corresponding echo reply contains a Return Code of 2 (one
or more of the TLVs was not understood), then the sender of the
echo request MAY resend the echo request with the Downstream
Mapping TLV (instead of the Downstream Detailed Mapping TLV). In
cases where a detailed reply is needed, the sender can choose to
ignore the router that does not support the Downstream Detailed
Mapping TLV.</t>
<t>If the echo request contains a Downstream Mapping TLV, then a
Downstream Detailed Mapping TLV MUST NOT be sent in the echo
reply. This is to handle the case that the sender of the echo
request does not support the new TLV. The echo reply MAY contain
Downstream Mapping TLV(s).</t>
<t>If echo request forwarding is in use; such that the echo
request is processed at an intermediate label switched router
(LSR) and then forwarded on; then the intermediate router is
responsible for making sure that the TLVs being used among the
ingress, intermediate and destination are consistent. The
intermediate router MUST NOT forward an echo request or an echo
reply containing a Downstream Detailed Mapping TLV if it itself
does not support that TLV.</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t><list style="numbers">
<t>If a network operator wants to prevent tracing inside a tunnel,
one can use the pipe mode <xref target="RFC3443"></xref>, i.e. hide
the outer MPLS tunnel by not propagating the MPLS TTL into the outer
tunnel (at the start of the outer tunnel). By doing this, MPLS
traceroute packets will not expire in the outer tunnel and the outer
tunnel will not get traced.</t>
<t>If one doesn't wish to expose the details of the new outer LSP,
then the NIL FEC can be used to hide those details. Using the NIL
FEC ensures that the trace progresses without false negatives and
all transit nodes (of the new outer tunnel) perform some minimal
validations on the received MPLS echo requests.</t>
</list></t>
<t>Other security considerations, as discussed in <xref
target="RFC4379"></xref> are also applicable to this document.</t>
</section>
<section title="IANA Considerations">
<t>The suggested values in all sub-sections below have been allocated
according to the early allocation process.</t>
<section title="New TLV" toc="exclude">
<t>IANA is requested to assign TLV type value to the following TLV
from the "Multiprotocol Label Switching Architecture (MPLS) Label
Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs"
sub-registry.</t>
<t>Downstream Detailed Mapping TLV (See <xref
target="ddmap-tlv"></xref>). Suggested value: 20.</t>
</section>
<section title="New Sub-TLV types and associated registry" toc="exclude">
<t>IANA is requested to create a new registry for the Sub-Type field
of Downstream Detailed Mapping TLV. The valid range for this is
0-65535. Assignments in the range 0-16383 and 32768-49161 are made via
Standards Action as defined in <xref target="RFC3692"></xref>;
assignments in the range 16384-31743 and 49162-64511 are made via
Specification Required (<xref target="RFC4379"></xref>); values in the
range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST
NOT be allocated. If a sub-TLV has a Type that falls in the range for
Vendor Private Use, the Length MUST be at least 4, and the first four
octets MUST be that vendor's SMI Enterprise Code, in network octet
order. The rest of the Value field is private to the vendor.</t>
<t>It is requested that IANA assign sub-TLV types from this new
registry to the following sub-TLVs (See <xref
target="ddmap-sub-tlvs"></xref>).</t>
<t>Multipath data sub-TLV: Suggested value: 1</t>
<t>Label stack sub-TLV: Suggested value: 2</t>
<t>FEC Stack change sub-TLV: Suggested value: 3</t>
</section>
<section anchor="new-return-code" title="New Return Codes" toc="exclude">
<t>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.</t>
<figure align="left">
<artwork><![CDATA[
Value Meaning
----- -------
TBD See DDM TLV for Return Code and Return SubCode
TBD Label switched with FEC change
]]></artwork>
</figure>
<t>Suggested values: 14 and 15 respectively</t>
</section>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Yakov Rekhter and Adrian Farrel for
their suggestions on the draft.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3692;
&RFC4379;
</references>
<references title="Informative References">
&RFC3443;
&RFC4461;
&RFC5150;
&RFC5331;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 22:30:22 |