One document matched: draft-nitinb-mpls-tp-lsp-ping-extensions-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc3978.dtd" [
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC1812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1812.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4379 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY MPLS-TP-OAM-REQ SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-oam-requirements.xml">
<!ENTITY ACH-TLV SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-ach-tlv.xml">
<!ENTITY DDMAP-DRAFT SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-lsp-ping-enhanced-dsmap.xml">
<!ENTITY BFD-MPLS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfd-mpls.xml">
<!ENTITY P2MP-LSPING SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-p2mp-lsp-ping.xml">
<!ENTITY MPLS-TP-IDENTIFIERS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.swallow-mpls-tp-identifiers.xml">
<!ENTITY LSP-PING-ACH SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nitinb-mpls-tp-lsp-ping-bfd-procedures.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-nitinb-mpls-tp-lsp-ping-extensions-00"
ipr="trust200902">
<front>
<title>LSP-Ping extensions for MPLS-TP</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="Rahul Aggarwal" initials="R.A." surname="Aggarwal">
<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>rahul@juniper.net</email>
<uri>www.juniper.net</uri>
</address>
</author>
<author fullname="Sami Boutros" initials="S.B." surname="Boutros">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>3750 Cisco Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>sboutros@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Eric Gray" initials="E.G." surname="Gray">
<organization>Ericsson</organization>
<address>
<postal>
<street>900 Chelmsford Street</street>
<city>Lowell</city>
<region>MA</region>
<code>01851</code>
<country>US</country>
</postal>
<phone>+1 978 275 7470</phone>
<facsimile></facsimile>
<email>eric.gray@ericsson.com</email>
<uri></uri>
</address>
</author>
<date day="19" month="October" year="2009" />
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>MPLS-TP OAM</keyword>
<keyword>lsp ping</keyword>
<abstract>
<t>LSP-Ping is an existing and widely deployment OAM mechanism for MPLS
LSPs. This document describes extensions to LSP-Ping so that LSP-Ping
can be used to perform OAM on MPLS-TP LSPs. It also clarifies the
procedures to be used for processing the OAM packets. Further, it
describes how LSP-Ping can be used to perform Connectivity Verification,
Route Tracing and Adjacency functions in MPLS-TP networks.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>LSP-Ping <xref target="RFC4379"></xref>is an OAM mechanism for MPLS
LSPs. This document describes extensions to LSP-Ping so that LSP-Ping
can be used to perform OAM on MPLS-TP LSPs. It also clarifies the
procedures to be used for processing the OAM packets. Further, it
describes how LSP-Ping can be used to perform Connectivity Verification,
Route Tracing and Adjacency functions specified in <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>.</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 title="LSP-Ping for MPLS-TP LSPs using IP encapsulation">
<t>LSP-Ping requires IP addressing on the egress and transit LSRs for
performing OAM on MPLS signaled LSPs and pseudowires. In particular,
in these cases the LSP-Ping packets generated by an ingress LSR are
encapsulated in an IP/UDP header with the destination address from the
127/8 range and then encapsulated in the MPLS label stack (<xref
target="RFC4379"></xref> , <xref target="I-D.ietf-bfd-mpls"></xref>).
Egress LSRs use the presence of the 127/8 destination address to
identify the OAM packets and rely further on the UDP port number to
determine whether the packet is a LSP-Ping packet. It is to be noted
that this determination does not require IP forwarding capabilities.
It requires the presence of an IP host stack which enables egress LSRs
to process packets with a destination address from the 127/8 range.
<xref target="RFC1122"></xref> allocates the 127/8 range as "Internal
host loopback address" and <xref target="RFC1812"></xref> states that
"a router SHOULD NOT forward, except over a loopback interface, any
packet that has a destination address on network 127".</t>
</section>
<section title="LSP-Ping for MPLS-TP LSPs using non-IP encapsulation">
<t>In certain MPLS-TP deployment scenarios IP addressing might not be
available or it may be preferred to use non-IP encapsulation for
LSP-Ping and BFD packets. In such scenarios, LSP-Ping must be run
without IP addressing, using the ACH channel type specified in <xref
target="I-D.nitinb-mpls-tp-lsp-ping-bfd-procedures"></xref>.</t>
<t>Sections <xref target="lsp-ping-ping"></xref> and <xref
target="lsp-ping-trace"></xref> describe the theory of operation for
performing LSP-Ping over MPLS-TP LSPs with a non-IP encapsulation.</t>
</section>
</section>
<section title="LSP-Ping extensions" toc="default">
<section anchor="dsmap-addr-type"
title="New address type for Downstream Mapping TLV">
<t><xref target="RFC4379"></xref> defines the Downstream Mapping TLV.
This document defines the following new Address type which is added to
the Downstream Mapping TLV:</t>
<figure align="left" anchor="dsmap-addr-type-fig"
title="Downstream Mapping TLV new Address Type">
<artwork><![CDATA[
Type # Address Type K Octets
------ -------------- --------
0 Not Applicable 8
]]></artwork>
</figure>
<t>The new address type indicates that no address is present in the
Downstream Mapping TLV. Multipath type MAY be set to 0 (no multipath)
when using this address type.</t>
<t>When this address type is used, on receipt of a LSP-Ping echo
request, interface verification MUST be bypassed. Thus the receiving
node SHOULD only perform mpls label control-plane/data-plane
consistency checks.</t>
<t>The new address type is also applicable to the Detailed Downstream
Mapping TLV defined in <xref
target="I-D.ietf-mpls-lsp-ping-enhanced-dsmap"></xref>.</t>
</section>
<section anchor="src-addr-tlv" title="Source Address TLV">
<t>When sending LSP-Ping packets using ACH, without IP encapsulation,
there MAY be a need to identify the source address of the packet. This
source address will be specified via the Source Address TLV, being
defined in <xref target="I-D.ietf-mpls-tp-ach-tlv"></xref>. Only 1
source address TLV MUST be present in a LSP-Ping packet. The source
address MUST specify the address of the originator of the packet. If
more than 1 such TLV is present in a LSP-Ping request packet, then an
error of "Malformed echo request received" SHOULD be returned. If more
than 1 source address TLV is present, then the packet SHOULD be
dropped without further processing.</t>
</section>
<section anchor="dest-addr-tlv" title="Destination Address TLV">
<t>When sending LSP-Ping packets using ACH, without IP encapsulation,
there MAY be a need to identify the destination address of the packet.
This destination address will be specified via the Destination Address
TLV, being defined in <xref target="I-D.ietf-mpls-tp-ach-tlv"></xref>.
One or more of this TLVs MAY be included. The destination address MUST
specify the intended receipient(s) of the packet. If the destination
address specified in any of the Destination Address TLVs does not
match any address associated with the node which receives the LSP-Ping
packet, then the LSP-Ping packet SHOULD be dropped without further
processing.</t>
</section>
<section title="MEP and MIP Identifier">
<t>When sending LSP-Ping packets using ACH, there MAY be a need to
identify the maintenance end point (MEP) and/or the maintenance
intermediate point (MIP) being monitored. The MEP/MIP identifiers
defined in <xref target="I-D.swallow-mpls-tp-identifiers"></xref> MAY
be carried in the ACH TLVs <xref
target="I-D.ietf-mpls-tp-ach-tlv"></xref> for identification. Only one
identifier (MEP or MIP) may be present in a packet. The MEP/MIP
identifiers associated with the packet MUST be checked for the MPLS-TP
LSP path/section that is being monitored. If the identifier does not
match the LSP path/section, then the packet MUST be dropped.</t>
</section>
<section title="Specifications for statically provisioned LSPs">
<t>Details of LSP-Ping for statically provisioned LSPs will be
specified in a future revision of this document.</t>
</section>
</section>
<section title="Performing LSP-Ping over MPLS-TP LSPs">
<t>This section specifies how LSP-Ping ping can be used in the context
of MPLS-TP LSPs. The LSP-Ping ping function meets the Connectivity
Verification requirement specified in <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>. This function SHOULD
be performed on-demand. This function SHOULD be performed between End
Points (MEPs) and Intermediate Points (MIPs) of PWs and LSPs, and
between End Points of PWs, LSPs and Sections. In order for the LSP-Ping
packet to be processed at the desired MIP, the TTL of the MPLS label
should be set such that it expires at the MIP to be probed.</t>
<section anchor="ip-lsp-ping" title="LSP-Ping with IP encapsulation">
<t>LSP-Ping packets as specified in <xref target="RFC4379"></xref> are
sent over the MPLS LSP for which OAM is being performed and contain an
IP/UDP packet within them. The IP header is not used for forwarding
(since the LSP is forward using MPLS label switching). The IP header
is used mainly for addressing and can be used in the context of
MPLS-TP LSPs. This form of LSP-Ping OAM MUST be supported for MPLS-TP
LSPs when IP addressing is in use. The LSP-Ping Reply mode <xref
target="RFC4379"></xref> in the LSP-Ping echo request MUST be set to 4
(Reply via application level control channel).</t>
<t>The LSP-Ping echo response message MUST be sent on the reverse path
of the LSP. The reply MUST contain IP/UDP headers followed by the
LSP-Ping payload. The destination address in the IP header MUST be set
to that of the sender of the echo request message. The source address
in the IP address MUST be set to a valid address of the replying
node.</t>
</section>
<section anchor="lsp-ping-ping" title="Non-IP based LSP-Ping">
<t>The OAM procedures defined in <xref target="RFC4379"></xref>
require the use of IP addressing and in some cases IP routing to
perform OAM functions. When the ACH header is used, IP addressing and
routing is not needed. This section describes procedures for
performing lsp-ping without a dependency on IP addressing and
routing.</t>
<t>When using LSP-Ping over the ACH header, the LSP-Ping Reply mode
<xref target="RFC4379"></xref> in the LSP-Ping echo request MUST be
set to 4 (Reply via application level control channel).</t>
<t>The ingress node MAY attach a Source Address TLV (<xref
target="src-addr-tlv"></xref>) to identify the node originating the
request.</t>
<t>The LSP-Ping reply message MUST be sent on the reverse path of the
LSP using ACH. The LSP-Ping payload MUST directly follow the ACH
header (and any ACH TLVs) and no IP and/or UDP headers MUST be
attached. If the request message contained the Source Address TLV and
a response is being sent to the originator, then a Destination Address
TLV (<xref target="dest-addr-tlv"></xref>) SHOULD be added to the
reply message. The contents of the LSP-Ping request Source Address TLV
should be copied into the LSP-Ping response Destination Address TLV.
The responding node MAY attach a Source Address TLV to identify the
node sending the response.</t>
<t>If a node receives an MPLS echo request packet over ACH, without
IP/UDP headers and if that node does not have a return MPLS LSP path
to the echo request source, then the node MUST drop the echo request
packet and not attempt to send a response.</t>
</section>
<section title="P2MP Considerations">
<t><xref target="I-D.ietf-mpls-p2mp-lsp-ping"></xref> describes how
LSP-Ping can be used for OAM on P2MP LSPs with IP encapsulation. This
MUST be supported for MPLS-TP P2MP LSPs when IP addressing is used.
When IP addressing is not used, then the procedures described in <xref
target="lsp-ping-ping"></xref> can be applied to P2MP MPLS-TP LSPs as
well.</t>
</section>
</section>
<section title="Performing LSP Traceroute over MPLS-TP LSPs">
<t>This section specifies how LSP-Ping traceroute can be used in the
context of MPLS-TP LSPs. The LSP-Ping traceroute function meets the
Adjancency and Route Tracing requirement specified in <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>. This function SHOULD
be performed on-demand. This function SHOULD be performed between End
Points and Intermediate Points of PWs and LSPs, and between End Points
of PWs, LSPs and Sections.</t>
<t>When performing lsp-ping traceroute, the ingress node inserts a
Downstream Mapping TLV to get the downstream node information and to
enable LSP verification along the transit nodes. The Downstream Mapping
TLV can be used as is for performing the traceroute. If IP addressing is
not in use, then the Address Type field in the Downstream Mapping TLV
can be set to "Not applicable" (<xref target="dsmap-addr-type"></xref>).
The Downstream Mapping TLV address type field can be extended to include
other address types as need be.</t>
<section title="LSP Traceroute with IP encapsulation">
<t>The mechanics of LSP-Ping traceroute are similar to that described
for ping in <xref target="ip-lsp-ping"></xref>. Traceroute packets
sent by the LSP ingress MUST follow procedures described in <xref
target="RFC4379"></xref>. This form of LSP-Ping OAM MUST be supported
for MPLS-TP LSPs, when IP addressing is used.</t>
</section>
<section anchor="lsp-ping-trace" title="Non-IP based LSP Traceroute">
<t>This section describes the procedures for performing LSP traceroute
when using the ACH header and without any dependency on IP addressing.
The procedures specified in <xref target="lsp-ping-ping"></xref> with
regards to Source Address TLV, Destination Address TLV and MEP/MIP
identifiers apply to LSP traceroute as well.</t>
<section title="Ingress node procedure for sending echo request packets">
<t>Traceroute packets sent by the LSP ingress MUST adhere to the
format described in <xref target="lsp-ping-ping"></xref>. MPLS-TTL
expiry (as described in <xref target="RFC4379"></xref>) will be used
to direct the packets to specific nodes along the LSP path.</t>
</section>
<section title="Ingress node procedure for receiving echo response packets">
<t>The LSP-Ping traceroute responses will be received on the LSP
itself and the presence of an ACH header with channel type of
LSP-Ping is an indicator that the packet contains LSP-ping
payload.</t>
</section>
<section title="Transit and egress node procedure">
<t>When a echo request reaches the transit or egress, the presence
of the ACH channel type of LSP-Ping will indicate that the packet
contains LSP-Ping data. The LSP-Ping data, the label stack and the
MEP/MIP identifier should be able to identify the LSP associated
with the echo request packet. In case if there is an error and the
node is unable to idenfity the LSP on which the echo response should
to be sent, the node MUST drop the echo request packet and not send
any response back. All responses MUST always be sent on a LSP path
using the ACH header and ACH channel type of LSP-Ping.</t>
</section>
</section>
<section title="P2MP Considerations">
<t><xref target="I-D.ietf-mpls-p2mp-lsp-ping"></xref> describes how
LSP-Ping can be used for OAM on P2MP LSPs. This MUST be supported for
MPLS-TP P2MP LSPs when IP addressing is used. When IP addressing is
not used, then the procedures described in <xref
target="lsp-ping-trace"></xref> can be applied to P2MP MPLS-TP LSPs as
well.</t>
</section>
<section title="ECMP Considerations">
<t>LSP-Ping using ACH SHOULD NOT be used when there is ECMP (equal
cost multiple paths) for a given LSP. The addition of the additional
ACH header may modify the hashing behavior for OAM packets which may
result in incorrect monitoring of path taken by data traffic.</t>
</section>
</section>
<section title="Applicability">
<t>The non-IP addressing based procedures specified in this document
apply only to MPLS-TP LSPs. They also apply to PWs when IP encapsulation
is not desired. However, when IP addressing is used, as in non MPLS-TP
LSPs, procedures specified in <xref target="RFC4379"></xref> MUST be
used.</t>
</section>
<section title="Security Considerations">
<t>The draft does not introduce any new security considerations. Those
discussed in <xref target="RFC4379"></xref> are also applicable to this
document.</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Contributing Authors">
<t>The following individuals also contributed to this document:<list
style="symbols">
<t>Thomas D. Nadeau, BT</t>
<t>Nurit Sprecher, Nokia Siemens Networks</t>
<t>Yaacov Weingarten, Nokia Siemens Networks</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4379;
&LSP-PING-ACH;
</references>
<references title="Informative References">
&RFC1122;
&RFC1812;
&ACH-TLV;
&BFD-MPLS;
&MPLS-TP-OAM-REQ;
&DDMAP-DRAFT;
&P2MP-LSPING;
&MPLS-TP-IDENTIFIERS;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:49:17 |