One document matched: draft-kumar-mpls-spring-lsp-ping-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category='std' ipr='trust200902' docName='draft-kumar-mpls-spring-lsp-ping-00'>
<front>
<title abbrev="LSP Ping/Trace for SR on MPLS">Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane</title>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709</code>
<country>US</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials="G." surname="Swallow" fullname="George Swallow">
<organization>Cisco Systems, Inc.</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>
</address>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="N." surname="Akiya" fullname="Nobo Akiya">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>2000 Innovation Drive</street>
<city>Kanata</city> <region>ON</region> <code>K2K 3E8</code>
<country>Canada</country>
</postal>
<email>nobo@cisco.com</email>
</address>
</author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<date year="2013" />
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>mpls</keyword>
<abstract><t>Segment Routing architecture leverages the source routing and tunneling paradigm and
can be directly applied to MPLS dataplane. A node steers a packet through a
controlled set of instructions called segments, by prepending the packet with Segment
Routing header. </t>
<t> The segment assignment and forwarding semantic nature of
Segment Routing raises additional consideration for connectivity verification and
fault isolation in LSP with SPRING architecture. This document illustrates the problem and
describe a mechanism to perform LSP Ping and Traceroute on Segment Routing network over MPLS dataplane.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.filsfils-rtgwg-segment-routing" /> introduces and explains
Segment Routing architecture
that leverages the source routing and tunneling paradigm. A node steers a packet through a
controlled set of instructions called segments, by prepending the packet with SR header. A
detailed definition about Segment Routing architecture is available in draft-filsfils-rtgwg-segment-routing
and different use-cases are discussed in draft-filsfils-rtgwg-segment-routing-use-cases.</t>
<t>The Segment Routing architecture can be directly applied to MPLS dataplane in a way that, the segment
will be of 20-bits size and SR header is the label stack. </t>
<t><xref target="RFC4379" /> describes the mechanism to perform connectivity verification
and fault isolation in Label Switched Path (LSP). Unlike LDP or RSVP which are the other
well-known MPLS control plane protocols, segment assignment in Segment Routing architecture
is not hop-by-hop basis.</t>
<t>This nature of Segment Routing raises additional consideration for connectivity verification and
fault isolation in Segment Routing network. This document illustrates the problem and
describe a mechanism to perform LSP Ping and Traceroute on Segment Routing network over MPLS dataplane.
</t>
</section>
<section title="Requirements notation">
<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"/>.
</t>
</section>
<section title="Path validation in Segment Routing networks">
<t><xref target="RFC4379" /> defines the OAM machinery that helps with connectivity
check and fault isolation in MPLS dataplane path with the use of various Target FEC
Stack Sub-TLV that are carried in MPLS Ping packets and used by the responder for
FEC validation. While it is obvious that new Sub-TLVs need to be assigned, the
unique nature of SPRING architecture raises a need for additional machinery for
path validation. This section discuss the challenges as below:
</t>
<figure>
<artwork><![CDATA[
L1
+--------+
| L2 |
R3-------R6
/ \
/ \
R1----R2 R7----R8
\ / L3
\ /
R4-------R5
Figure 1: SPRING network
500x --> Node Segment ID for Router X
(Ex: 5006 is node segment ID for R6)
9axy --> Adj Segment ID from Router X to Y over link a
(Ex: 9136 is Adj segment ID from R3 to R6 via link 1)
]]></artwork>
</figure>
<t>The forwarding semantic of Adjacency segment is to pop the segment and send the packet to a specific neighbor over a specific link. A malfunctioning node may forward packets using Adjacency segment to incorrect neighbor or over incorrect link. Exposed segment (after incorrectly forwarded Adjacency segment) might still allow such packet to traverse to intended destination, yet intended strict traversal has been broken.</t>
<t>Assume in above topology, R1 sends traffic with segment stack as {9124, 5007, 9378} so that the path taken
will be R1-R2-R4-R5-R7-R8. If the adjacency segment 9124 is misprogrammed in R2 to send the packet to R1 or R3,
it will still be delivered to R8 but is not via the expected path.
</t>
<t>MPLS traceroute may help with detecting such deviation in above mentioned scenario. However, it may not be
helpful if R3, due to misprogramming, forwards packet with adjacency segment 9236 via link L1 while it is expected
to be forwarded over Link L2.
</t>
<t>This document defines Target FEC Stack sub-TLVs and explains how they can be used to tackle above challenges.
</t>
</section>
<section title="Segment Routing Sub-TLV Format">
<t>The format of the following FEC Sub-TLVs follows the philosophy of Target FEC Stack
TLV carrying FECs corresponding to each label in the label stack.
When operated with the procedures defined in <xref target="RFC4379" />, this allows LSP
ping/traceroute operations to function when Target FEC Stack TLV
contains more FECs than received label stack at responder nodes.</t>
<figure>
<artwork><![CDATA[
Type Sub-Type Value Field
---- -------- ---------------
1 TBD1 IPv4 Prefix Node Segment ID
TBD2 IPv6 Prefix Node Segment ID
TBD3 Adjacency Segment ID
]]></artwork>
</figure>
<t>Service Segments and FRR will be considered in future version.</t>
<section title="IPv4 Prefix Node Segment ID">
<t>The format is as below:</t>
<figure>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Resv | Protocol | SID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Segment ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Advertising Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>IPv4 Prefix
<list><t>This field carries the IPv4 prefix to which the Node Segment
ID is assigned.</t>
</list>
</t>
<t>Prefix Length
<list><t>One octet of prefix length in bits.</t>
</list>
</t>
<t>Protocol
<list><t>Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS.
</t>
</list>
</t>
<t>SID Length
<list><t>Set to 3 or 4 depending on the Segment ID.</t>
</list>
</t>
<t>Node Segment ID
<list><t>This field carries the Node segment ID. If the SID Length is 3, then
the 20 rightmost bits represent the segment. If length is 4, then the value
represent a 32 bits Segment ID.</t>
</list>
</t>
<t>Advertising Node Identifier
<list><t>Specifies the advertising node identifier.When Protocol is set to 1,
then the 32 rightmost bits represent OSPF Router ID and if protocol is set to
2, this field carries 48 bit ISIS System ID.</t>
</list>
</t>
</section>
<section title="IPv6 Prefix Node Segment ID">
<t>The format is as below:</t>
<figure>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Resv | Protocol | SID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Segment ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Advertising Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>IPv6 Prefix
<list><t>This field carries the IPv6 prefix to which the Node Segment
ID is assigned.</t>
</list>
</t>
<t>Prefix Length
<list><t>One octet of prefix length in bits.</t>
</list>
</t>
<t>Protocol
<list><t>Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS.
</t>
</list>
</t>
<t>SID Length
<list><t>Set to 3 or 4 depending on the Segment ID.</t>
</list>
</t>
<t>Node Segment ID
<list><t>This field carries the Node segment ID. If the SID Length is 3, then
the 20 rightmost bits represent the segment. If length is 4, then the value
represent a 32 bits Segment ID.</t>
</list>
</t>
<t>Advertising Node Identifier
<list><t>Specifies the advertising node identifier.When Protocol is set to 1,
then the 32 rightmost bits represent OSPF Router ID and if protocol is set to
2, this field carries 48 bit ISIS System ID.</t>
</list>
</t>
</section>
<section title="IGP Adjacency Segment ID">
<t>The format is as below:
</t>
<figure>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | SID Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Advertising Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGP Adjacency Segment ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Local Interface ID
<list><t>An identifier that is assigned by local LSR for a link on which Adjacency
SID is binded. If the Adj-SID represents parallel adjacencies (Section
3.3.2.1 of <xref target="I-D.filsfils-rtgwg-segment-routing" />) this field MUST be set
to zero.
</t>
</list>
</t>
<t>Remote Interface ID
<list><t>An identifier that is assigned by remote LSR for a link on which Adjacency
SID is binded. If the Adj-SID represents parallel adjacencies (Section
3.3.2.1 of <xref target="I-D.filsfils-rtgwg-segment-routing" />) this field MUST be set
to zero.</t>
</list>
</t>
<t>Protocol
<list><t>Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS
</t>
</list>
</t>
<t>SID Length
<list><t>Set to 3 or 4 depending on the Segment ID.</t>
</list>
</t>
<t>Advertising Node Identifier
<list><t>Specifies the advertising node identifier.When Protocol is set to 1,
then the 32 rightmost bits represent OSPF Router ID and if protocol is set to
2, this field carries 48 bit ISIS System ID.</t>
</list>
</t>
<t>IGP Adjacency Segment ID
<list><t>This field carries the adjacency segment ID.</t>
</list>
</t>
</section>
</section>
<section title="Extension to Downstream Mapping TLV">
<t>In an echo reply, the Downstream Mapping TLV [RFC4379] is used to
report for each interface over which a FEC could be forwarded. For
an FEC, there are multiple protocols that may be used to distribute
label mapping. The "Protocol" field of the Downstream Mapping TLV is
used to return the protocol that is used to distribute a specific a
label. The following protocols are defined in section 3.2 of
[RFC4379]:
</t>
<figure>
<artwork><![CDATA[
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
]]></artwork>
</figure>
<t>With segment routing, OSPF or ISIS can be used for label
distribution, this document adds two new protocols as follows:
</t>
<figure>
<artwork><![CDATA[
Protocol # Signaling Protocol
---------- ------------------
5 OSPF
6 ISIS
]]></artwork>
</figure>
</section>
<section title="Procedures">
<t>This section describes aspects of LSP ping/traceroute operations that require further considerations beyond <xref target="RFC4379" />.</t>
<section title="FECs in Target FEC Stack TLV">
<t>When LSP echo request packets are generated by an initiator, FECs carried in Target FEC Stack TLV may need to or desire to have deviating contents. This document outlines expected Target FEC Stack TLV construction mechanics by initiator for known scenarios.
<list>
<t>Ping
<list>
<t>Initiator MUST include FEC(s) corresponding to the destination segment.</t>
<t>Initiator MAY include FECs corresponding to some or all of segments imposed in the label stack by the initiator to communicate the segments traversed.</t>
</list>
</t>
<t>Traceroute
<list>
<t>Initiator MUST initially include FECs corresponding to all of segments imposed in the label stack.</t>
<t>When a received echo reply contains FEC Stack Change TLV with one or more of original segment(s) being popped, initiator MAY remove corresponding FEC(s) from Target FEC Stack TLV in the next (TTL+1) traceroute request.</t>
<t>When a received echo reply does not contain FEC Stack Change TLV, initiator MUST NOT attempt to remove FEC(s) from Target FEC Stack TLV in the next (TTL+1) traceroute request. Note that Downstream Label field of DSMAP/DDMAP contains hints on how initiator may be able to update the contents of next Target FEC Stack TLV. However, such hints are ambiguous without full understanding of PHP capabilities.</t>
</list>
</t>
</list>
</t>
</section>
<section title="FEC Stack Change TLV">
<t>The network node which advertised the node segment ID is responsible for generating FEC Stack Change TLV of &pop& operation for node segment ID, regardless of if PHP is enabled or not.</t>
<t>The network node that is immediate downstream of the node which advertised the adjacency segment ID is responsible for generating FEC Stack Change TLV of &pop& operation for adjacency segment ID.</t>
</section>
<section title="PHP, Adjacency SID Pop, Implicit NULL">
<t>Forwarding behavior of node segment ID PHP is equivalent to usage of implicit Null in MPLS protocols that embraces downstream label allocation scheme. Adjacency segment ID is also similar in a sense that it can be thought as nexthop destined locally allocated segment that has PHP enabled. Procedures described in Section 4.4 of <xref target="RFC4379" /> relies on Stack-D and Stack-R explicitly having Implicit Null value. It may simplify implementations to reuse Implicit Null for node segment ID PHP and adjacency segment ID cases. However, it is technically incorrect for Implicit Null value to externally appear. Therefore, implicit Null MUST NOT be placed in Stack-D and Interface and Label Stack TLV for node segment ID PHP and adjacency segment ID cases.</t>
</section>
<section title="Segment Protocol Check">
<t>
<list>
<t>If the Target FEC Sub-TLV at FEC-stack-depth is TBD1 (IPv4 Prefix Node Segment ID), set Best return code to (error code TBD) if any below conditions fail:
<list style="symbols">
<t>Validate that Advertising Node Identifier of Protocol is a local node.</t>
<t>Validate that Node Segment ID is avertised for IPv4 Prefix by the Protocol with Advertising Node Identifier.</t>
<t>Validate that Node Segment ID is advertisement of PHP bit.</t>
</list>
</t>
<t>If the Target FEC Sub-TLV at FEC-stack-depth is TBD2 (IPv6 Prefix Node Segment ID), set Best return code to (error code TBD) if any below conditions fail:
<list style="symbols">
<t>Validate that Advertising Node Identifier of Protocol is a local node.</t>
<t>Validate that Node Segment ID is advertised for IPv6 Prefix by the Protocol with Advertising Node Identifier.</t>
<t>Validate that Node Segment ID is advertised of PHP bit.</t>
</list>
</t>
<t>If the Target FEC sub-TLV at FEC-stack-depth is TBD3 (Adjacency Segment ID), set Best return code to (error code TBD) if any below conditions fail:
<list style="symbols">
<t>Validate that Remote Interface ID matches the local identifier of the interface on which the packet was received.</t>
<t>Validate that IGP Adjacency SID is advertised by Advertising Node Identifier of Protocol in local IGP database.</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="IANA Considerations">
<t>To be Updated.</t>
</section>
<section title="Security Considerations">
<t>To be Updated.</t>
</section>
<section title="Acknowledgement">
<t> The authors would like to thank Stefano Previdi for his review
and comments.</t>
</section>
<section title="Contributing Authors">
<t>Tarek Saad
<vspace blankLines="0" />
Cisco Systems
<vspace blankLines="0" />
Email: tsaad@cisco.com</t>
<t>Siva Sivabalan
<vspace blankLines="0" />
Cisco Systems
<vspace blankLines="0" />
Email: msiva@cisco.com</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.filsfils-rtgwg-segment-routing"?>
<?rfc include="reference.RFC.4379"?>
<?rfc include="reference.RFC.6424"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6425"?>
<?rfc include="reference.RFC.6291"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:13 |