One document matched: draft-ietf-mpls-lsp-ping-enhanced-dsmap-06.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 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 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-06"
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="August" year="2010" />
<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 traceroute
over mpls tunnels and for traceroute of stitched mpls LSPs. The
techniques outlined in RFC 4379 are insufficient to perform traceroute
FEC validation and path discovery for a LSP that goes over other mpls
tunnels or for a stitched LSP. This document describes enhancements to
the downstream-mapping TLV (defined in RFC 4379). 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 traceroute
over mpls tunnels. The techniques outlined in <xref
target="RFC4379"></xref> outline a traceroute mechanism that includes
FEC validation and ECMP path discovery. Those mechanisms are
insufficient and do not provide details in case the FEC being traced
traverses one or more mpls tunnels and in case where LSP stitching 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 echo-response. The next
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 packet 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 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 tunnel over
tunnel or multiple 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 hint or 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, conside 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 LSP A--F. When an echo
request reaches router C, there is a FEC stack change happening at
router C. With current lsp-ping 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 outlined <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 lsping echo response. In most cases, the additional data needs to
be associated on a per downstream neighbor basis. Currently, the echo
response contains 1 downstream map TLV (DSMAP) per downstream
neighbor. But the DSMAP format is not extensible and hence it's 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.</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 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 Downstream
Detailed 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.</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="multiple-tunnel-fig"></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 other than "Label switched with FEC change". This Return
Code 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">
<t>A new TLV has been added to the mandatory range of TLVs. The TLV
type is pending IANA allocation.</t>
<figure align="left" anchor="dsmap-detailed-type">
<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 echo request message. Only one Downstream Detailed
Mapping object may appear in an echo request. The presence of a
Downstream Mapping object is a request that Downstream Detailed
Mapping objects be included in the echo reply. If the replying router
is the destination of the FEC, then a Downstream Detailed Mapping TLV
SHOULD NOT be included in the 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 IP 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 coverted into sub-TLVs. The fields have
the same use and meaning as in <xref target="RFC4379"></xref>. The
newly added sub-TLVs and their fields are as described below.</t>
<t>Return code<list style="empty">
<t>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.</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 response 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 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 response header.</t>
<t></t>
<t>If the Return Code of the echo response 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 and Return SubCode specified in
the Downstream Detailed Mapping TLV SHOULD 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>
<figure anchor="dsmap-sub-tlv-list"
title="Downstream Detailed Mapping Sub-TLV List">
<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 information multipath
information. The TLV fields and their usage is as defined in <xref
target="RFC4379"></xref>.</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 labels present in the sub-TLV is
determined 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 protocol type are as defined in <xref
target="RFC4379"></xref>. When the Downstream Detailed Mapping TLV
in sent in the echo response, this sub-TLV MUST be included.</t>
</section>
<section anchor="dsmap-fec-stack-tlv" title="FEC Stack change sub-TLV">
<t>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
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 align="left" title="Operation Type Values">
<artwork><![CDATA[
Type # Operation
------ ---------
1 Push
2 Pop
]]></artwork>
</figure>
<t hangText="4"><list style="empty">
<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. One or more POP operations MAY be followed by one or
more PUSH operations. One FEC Stack change sub-TLV MUST be
included per FEC stack change. For example, if 2 labels are
going to be pushed, then 1 FEC Stack change sub-TLV MUST be
included for each FEC. A FEC splice operation (an operation
where 1 FEC ends and another FEC starts, see <xref
target="multiple-tunnel-fig"></xref>) SHOULD 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
change sub-TLV with Pop operation is equivalent to EGRESS_OK
(Return code 3, <xref target="RFC4379"></xref>) for the
outermost FEC in the FEC stack. The ingress router performing
the lsp trace MUST treat such a case as an EGRESS_OK for the
outermost FEC.</t>
</list></t>
<t>FEC tlv Length</t>
<t hangText="4"><list style="empty">
<t>Length in bytes of the FEC TLV.</t>
</list></t>
<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 in case 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 anchor="remote-peer-address-format"
title="Remote peer address type">
<artwork><![CDATA[
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0
1 IPv4 4
2 IPv6 16
]]></artwork>
</figure>
<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 helpful 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. 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.</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 SHOULD 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>
</section>
</section>
<section title="Deprecation of Downstream Mapping TLV">
<t>The Downstream Mapping TLV has been deprecated. 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 lsp-ping traceroute on tunnels"
toc="include">
<t>This section describes the procedures to be followed by an ingress
node and transit nodes when performing lsp-ping 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-response. 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 response 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 MAY leave it
as unspecified.</t>
<t>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. If the tunnel is transparent 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 response 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 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 response 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 EGRESS_OK for the NIL FEC. The
ingress (node A) will know that EGRESS_OK 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, the 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 EGRESS_OK when RSVP-A is top of FEC
stack. Downstream information for node E when echo request contains
RSVP-B as top of FEC stack 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>Respond with either Return Code of EGRESS_OK (if D can co-relate
that the 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 labels towards next-hop is decreasing).</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
lsp traceroute. This section describes the ingress node procedure
based on the kind of response 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 procedures
similar to those of Downstream Mapping TLV, defined in Section 4.4
of <xref target="RFC4379"></xref></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 echo
response 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 echo
response, 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 response
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo response
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 response
current_fec_stack = saved_fec_stack
return
}
]]></artwork>
</figure>
<t>The next 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 echo response
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 EGRESS_OK responses."
toc="include">
<t>The procedures above allow the addition of new FECs to the
original FEC being traced. Consequently, the EGRESS_OK response from
a downstream node 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
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
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 same TTL (as previously sent). The process of popping a FEC is
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 already been popped. Using EGRESS_OK responses, 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 echo response 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 ECMP or 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 off 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 echo request or in the
same echo response.</t>
<t>If the echo request contains a Downstream Detailed Mapping TLV
and the corresponding echo response contains an 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 response 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
response. This is to handle the case that the sender of the echo
request does not support the new TLV. The echo response 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 router 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 response containing a
Downstream Detailed Mapping TLV if it itself does not support that
TLV.</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>Tracing inside a tunnel might have some security implications. There
are different ways to prevent tracing tunnel details.</t>
<t><list style="numbers">
<t>If one wants to prevent tracing inside a tunnel, one can 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, lsp-ping
packets will not expire in the outer tunnel and the outer tunnel
will not get traced. TTL hiding can be imposed on a per LSP basis,
as need be.</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 echo requests.</t>
</list></t>
<t>In inter-AS (autonomous system) scenarios, information regarding the
LSP FEC change(s) SHOULD NOT be passed across domains. A NIL FEC MAY be
used to make the trace go through without false positives. An ASBR
(autonomous system border router) may choose to intercept all echo
requests and echo responses and change them to hide FEC information from
other domains. Detailed operation regarding the same is outside the
scope of this document. Passing of FEC stack change information between
domains MAY be done if the two AS domains belong to the same
provider/organization.</t>
<t>Other security considerations, as discussed in <xref
target="RFC4379"></xref> are also applicable to this document.</t>
</section>
<section title="IANA Considerations">
<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="dsmap-sub-tlv-list"></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">
&RFC5331;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 22:26:13 |