One document matched: draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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 RFC4385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4385.xml">
<!ENTITY RFC5586 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5586.xml">
<!ENTITY MPLS-TP-OAM-REQ SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-oam-requirements.xml">
<!ENTITY DDMAP-DRAFT SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-lsp-ping-enhanced-dsmap.xml">
<!ENTITY TP-FRAMEWORK SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-framework.xml">
<!ENTITY BFD-MPLS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfd-mpls.xml">
<!ENTITY VCCV-BFD SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pwe3-vccv-bfd.xml">
<!ENTITY P2MP-LSPING SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-p2mp-lsp-ping.xml">
<!ENTITY BFD-MPLS-P2MP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.katz-ward-bfd-multipoint.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-bfd-procedures-00"
ipr="trust200902">
<front>
<title>LSP-Ping and BFD for MPLS-TP</title>
<author fullname="Nitin Bahadur" initials="N.B." role="editor"
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 Agrawal" 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="Thomas D. Nadeau" initials="T.N." surname="Nadeau">
<organization>BT</organization>
<address>
<postal>
<street>BT Centre</street>
<street>81 Newgate Street</street>
<city>London</city>
<code>EC1A 7AJ</code>
<country>United Kingdom</country>
</postal>
<email>tom.nadeau@bt.com</email>
</address>
</author>
<author fullname="Nurit Sprecher" initials="N.S." surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<code>45241</code>
<country>Israel</country>
</postal>
<phone>+972-9-775 1229</phone>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Yaacov Weingarten" initials="Y.W." surname="Weingarten">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<code>45241</code>
<country>Israel</country>
</postal>
<phone>+972-9-775 1827</phone>
<email>yaacov.weingarten@nsn.com</email>
</address>
</author>
<date day="5" month="July" 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 and BFD for MPLS are existing and widely deployment OAM
mechanisms for MPLS LSPs. This document describes how LSP-Ping and BFD
for MPLS can be used to perform OAM on MPLS-TP LSPs. This document
describes extensions to LSP-Ping when IP addressing is not in use, in a
MPLS-TP deployment scenario. These extensions are also meant to be
applicable when it is desirable to avoid the use of IP encapsulation for
exchanging LSP-Ping OAM messages. This document also clarifies the use
of BFD for MPLS-TP LSPs when IP addressing may not be available and/or
it may not be desirable to encapsulate BFD packets in IP.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>LSP-Ping <xref target="RFC4379"></xref> and <xref
target="I-D.ietf-bfd-mpls"></xref> are OAM mechanisms for MPLS LSPs.
This document describes how LSP-Ping and BFD for MPLS can be used to
perform OAM on MPLS-TP LSPs. The document considers two cases. The first
is when IP addressing and host stack are available on egress and transit
LSRs. The second is when such capabilities are either not available or
it is not desirable to use them.</t>
<t>Sections <xref target="lsp-ping-ping"></xref> and <xref
target="lsp-ping-trace"></xref> describes the theory of operation for
performing LSP-Ping over MPLS-TP LSPs. Section <xref
target="ach-header"></xref> describes the new TLVs and LSP-Ping
extensions for performing LSP-Ping in the absence of IP addressing.</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="Existing LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism">
<t>LSP-Ping requires IP addressing on the egress and transit LSRs for
performing OAM on MPLS signaled LSPs and pseudowires. BFD for MPLS
LSPs also requires IP addressing. In particular, in these cases the
LSP-Ping and BFD 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 or a BFD 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>
<t>LSP-Ping and BFD for MPLS specify procedures that allow an egress
LSR to use a MPLS LSP for forwarding LSP-Ping or BFD packets to the
ingress LSR. This ensures that IP forwarding capabilities are not
required and meets the MPLS-TP requirement of not having IP forwarding
capabilities.</t>
<t><xref target="I-D.ietf-mpls-tp-framework"></xref> specifies that IP
addressing is the default addressing mechanism for MPLS-TP networks.
An IP host stack must be present when IP addressing is in use. This
implies that exisiting LSP-Ping and BFD procedures can be used as is
in MPLS-TP environments when IP addressing is in use.</t>
</section>
<section title="Non-IP LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism">
<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. To enable re-use of OAM techniques provided
by LSP-Ping and BFD in such networks, rest of this document defines
extensions to LSP-Ping and procedures for using BFD. The document
defines a new code-point for using LSP-Ping with an ACH header.
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>. This document also
clarifies the usage of BFD in the context of MPLS-TP LSPs.</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.
<xref target="ach-header"></xref> describes the new TLVs and LSP-Ping
extensions for performing LSP-Ping in the absence of IP addressing.
<xref target="bfd-mpls-tp"></xref> describes procedures for using BFD
with non-IP encapsulation."</t>
</section>
</section>
<section title="LSP-Ping extensions" toc="default">
<section anchor="ach-header" title="LSP-Ping packet over ACH"
toc="default">
<t><xref target="RFC5586"></xref> defines an ACH mechanism for MPLS
LSPs. This document defines a new ACH channel type for when IP
addressing is not in use for LSP-Ping over associated bi-directional
LSPs and co-routed bi-directional LSPs.</t>
<t>ACH TLVs CANNOT be associated with LSP-Ping channel type.</t>
<figure align="left" anchor="channel-type-fig"
title="LSP-Ping ACH Channel Type">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | LSP-Ping Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section anchor="pw-ach-header" title="LSP-Ping packet over PW-ACH"
toc="default">
<t><xref target="RFC4385"></xref> defines an PW-ACH mechanism for
pseudowires. The ACH channel type for LSP-Ping defined in <xref
target="ach-header"></xref> will be re-used for pseudowires so that IP
addressing is not needed when using LSP-Ping OAM over pseudowires.</t>
</section>
<section anchor="dsmap-addr-type"
title="New address type for Downstream Mapping TLV">
<t><xref target="RFC4379"></xref> defines the Downstream Mapping TLV.
A new type is being added to the Address Type field as follows:</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 mutlpath)
when using this address type.</t>
<t>When this address type is used, on receipt of a lsp-ping echo
request, both interface verification and label stack validation MUST
be bypassed.</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>A new optional TLV is being defined for encapsulating the source
address. The optional TLV will be part of the TLVs defined in <xref
target="RFC4379"></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 in a LSP-Ping response packet, then the packet SHOULD be
dropped without further processing. The source address TLV MUST NOT be
used if IP addressing is in use. If IP addressing is in use, then one
should use lsp-ping with IP.</t>
<t>The format of the TLV is TBD.</t>
</section>
<section anchor="dest-addr-tlv" title="Destination Address TLV">
<t>A new optional TLV is being defined for encapsulating the
destination address. The optional TLV will be part of the TLVs defined
in <xref target="RFC4379"></xref>. One or more of this TLV MAY be
included in a LSP-Ping request message. If more than 1 destination
address TLV is present in a LSP-Ping response packet, then the packet
SHOULD be dropped without further processing. 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. The destination address TLV MUST NOT be used if IP
addressing is in use. If IP addressing is in use, then one should use
lsp-ping with IP.</t>
<t>The format of the TLV is TBD.</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>.</t>
<section anchor="lsp-ping-traditional" title="Traditional LSP-Ping">
<t>Traditional LSP-Ping packets ride over the LSP and contain an
IP/UDP packet within them. The IP header is not used for forwarding
(since the LSP is forwarded 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 figure below shows an MPLS-TP
LSP-Ping OAM packet.</t>
<figure align="right" anchor="lsp-ping-ip-payload-fig"
title="LSP-Ping packet">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP/UDP Headers |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-Ping payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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 reply 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 request message. The source adderss in the IP
header 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.</t>
<t>When ACH header is used, an LSP-Ping packet will look as
follows:</t>
<figure align="left" anchor="lsp-ping-payload-fig"
title="LSP-Ping packet with ACH">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | LSP-Ping Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-Ping payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<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 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>
</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. The procedures described in
this draft apply as is irrespective of whether we use the mechanism
specified in <xref target="lsp-ping-traditional"></xref> or the
mechanism specified in <xref target="lsp-ping-ping"></xref>.</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>.</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 anchor="lsp-trace-traditional"
title="Traditional LSP Traceroute">
<t>The mechanics of LSP-Ping traceroute are similar to those described
for ping in <xref target="lsp-ping-traditional"></xref>. Traceroute
packets sent by the lsp ingress MUST adhere to the format described in
<xref target="lsp-ping-ping"></xref>.This form of LSP-Ping OAM MUST be
supported for MPLS-TP LSPs, when IP addressing is in use.</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 and Destination Address TLV 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 and the label stack 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. The procedures described in
this draft apply as is irrespective of whether we use the mechanism
specified in <xref target="lsp-trace-traditional"></xref> or the
mechanism specified in <xref target="lsp-ping-trace"></xref>.</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 modeling of path taken by data traffic.</t>
</section>
</section>
<section anchor="bfd-mpls-tp" title="Running BFD over MPLS-TP LSPs">
<t><xref target="I-D.ietf-bfd-mpls"></xref> describes how BFD can be
used for Continuity Check for MPLS LSPs. When IP addressing is in use,
the procedures described in <xref target="I-D.ietf-bfd-mpls"></xref>
apply as is. This section clarifies the usage of BFD in the context of
MPLS-TP LSPs when it is not desirable to use IP encapsulation. When
using BFD over MPLS-TP LSPs, the BFD descriminator MAY either be
signaled via LSP-Ping or be statically configured. The BFD packets MUST
be sent over ACH when IP encapsulation is not used. BFD packets, for
both directions, MUST be sent over the MPLS-TP LSP and IP forwarding
SHOULD NOT be used for the reverse path. The format of a BFD packet when
using it as an OAM tool for MPLS-TP LSPs SHOULD be as follows:</t>
<figure align="left" anchor="bfd-payload-fig"
title="BFD packet over MPLS-TP LSPs">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload depending on channel type |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><xref target="I-D.ietf-pwe3-vccv-bfd"></xref> specifies how BFD can
be used over MPLS PWs. Of specific interest are 2 modes:</t>
<t><list style="numbers">
<t>Channel type is IP and payload contains BFD packet with IP/UDP
headers.</t>
<t>Channel type is BFD and payload contains BFD packet without
IP/UDP headers.</t>
</list>The first mode MUST be supported for BFD over MPLS-TP LSPs. The
second mode MAY be supported in addition.</t>
<t>Thus, no changes in BFD and no new code-points are needed to run BFD
over MPLS-TP LSPs. BFD supports continuous fault monitoring and thus
meets the Continuity Check requirement specified in <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>. For point to
multipoint Continuity Check, there is work in progress on using BFD for
P2MP MPLS LSPs ( <xref target="I-D.katz-ward-bfd-multipoint"></xref>)
and this can be leveraged for MPLS-TP LSPs as well.</t>
</section>
<section title="Applicability">
<t>The procedures described in this document apply to MPLS LSPs and as
well as to LSPs based on the MPLS-TP profile. The LSP-Ping procedures
can be used for performing OAM on both LSPs and Pseudowires.</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">
<section title="New ACH Channel Type">
<t>A new Channel type is defined in <xref target="ach-header"></xref>.
IANA is requested to assign a new value from the "PW Associated
Channel Type" registry, as per IETF consensus policy.</t>
<figure>
<artwork><![CDATA[
Value Meaning
----- -------
TBD Associated Channel carries LSP-Ping packet
]]></artwork>
</figure>
</section>
<section title="New LSP-Ping TLV Types">
<t>New TLV types are defined in <xref target="src-addr-tlv"></xref>
and <xref target="dest-addr-tlv"></xref>. IANA is requested to assign
values from the "Multi-Protocol Label Switching (MPLS) Label Switched
Paths (LSPs) Parameters" registry, "TLVs and sub-TLVs" sub- registry
from the range of 32768-64511.</t>
<figure>
<artwork><![CDATA[
Value Meaning
----- -------
TBD Source Address
TBD Destination Address
]]></artwork>
</figure>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4379;
&RFC4385;
</references>
<references title="Informative References">
&RFC1122;
&RFC1812;
&RFC5586;
&BFD-MPLS;
&VCCV-BFD;
&TP-FRAMEWORK;
&MPLS-TP-OAM-REQ;
&DDMAP-DRAFT;
&P2MP-LSPING;
&BFD-MPLS-P2MP;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 22:58:52 |