One document matched: draft-ietf-mpls-lsp-ping-enhanced-dsmap-00.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 MPLS-UPSTREAM-LABEL SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-upstream-label.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-00"
ipr="full3978" updates="RFC4379">
<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="26" month="June" year="2008" />
<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 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="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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-tlv length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. 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>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 Detailed Downstream Mapping TLV
in sent in the echo response, this sub-TLV MUST be included.</t>
</section>
<section anchor="dsmap-fec-stack-tlv" title="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 ore 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="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 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 change. For example, if 2 labels are going to
be pushed, then 1 FEC change sub-TLV MUST be included for each
FEC. A FEC Swap operation is to be simulated by including a POP
type FEC change sub-TLV followed by a PUSH type FEC 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 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 was learned. If the operation
type is POP, the remote peer address MAY be set to
Unspecified. For upstream assigned labels <xref
target="I-D.ietf-mpls-upstream-label"></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
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>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 length MUST be set to 0 and 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.</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.</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 not include 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 contain the NIL FEC.</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 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). 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 change
sub-TLVs will be performed</t>
<t>Node B:</t>
<t>Respond with 2 FEC change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.</t>
<t>Node D:</t>
<t>Respond with 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.</t>
<t>If node B is performing tunnel hiding, then:</t>
<t>Node B:</t>
<t>Respond with 2 FEC change sub-TLVs: PUSH NIL-FEC, PUSH
NIL-FEC.</t>
<t>Node D:</t>
<t>Respond with either EGRESS_OK (if D can co-relate that the
NIL-FEC corresponds to RSVP-A which is terminating at D) or respond
with FEC 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 change sub-TLVs. One
POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for
RSVP).</t>
</section>
</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>
<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 error 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.</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 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">
<t>This document introduces a new Downstream Detailed Mapping TLV. It is
requested that IANA assign a TLV type in the range of 0-32767 from the
TLV type registry created in <xref target="RFC4379"></xref>.</t>
<t>It is requested that IANA 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 a sub-TLV types from the 0-32767
range for the sub-TLVs defined in <xref
target="dsmap-sub-tlv-list"></xref>.</t>
</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">
&MPLS-UPSTREAM-LABEL;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 22:35:52 |