One document matched: draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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 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 ACH-TLV SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-ach-tlv.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 BFD-MPLS-P2MP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.katz-ward-bfd-multipoint.xml">
<!ENTITY MPLS-TP-IDENTIFIERS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.swallow-mpls-tp-identifiers.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-02"
ipr="trust200902">
<front>
<title>LSP-Ping and BFD encapsulation over ACH</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 Aggarwal" initials="R.A." role="editor"
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="David Ward" initials="D.W" role="editor" surname="Ward">
<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>
<facsimile></facsimile>
<email>dward@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.co</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="16" month="February" year="2010" />
<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 ACH encapsulation for
LSP-Ping, to enable use of LSP-Ping when IP addressing is not in use.
This document also clarifies the use of BFD for MPLS LSPs using ACH
encapsulation, 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 ACH encapsulation for LSP-Ping, to enable use of
LSP-Ping when IP addressing is not in use. When IP addressing is in use,
procedures specified in <xref target="RFC4379"></xref> apply as is. This
document also clarifies the use of BFD for MPLS LSPs using ACH
encapsulation, when IP addressing may not be available and/or it may not
be desirable to encapsulate BFD packets in IP.</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 and BFD over ACH">
<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.</t>
<t>Sections <xref target="ach-header"></xref> and <xref
target="pw-ach-header"></xref> describe a new ACH code-point for
performing LSP-Ping over ACH. Section <xref
target="bfd-mpls-tp"></xref> describes procedures for using BFD over
ACH.</t>
</section>
</section>
<section title="LSP-Ping extensions" toc="default">
<section anchor="ach-header" title="LSP-Ping packet over ACH for LSPs"
toc="default">
<t><xref target="RFC5586"></xref> defines an ACH mechanism for MPLS
LSPs. This document defines a new ACH channel type for LSP-Ping, when
IP addressing is not in use, for LSP-Ping over associated
bi-directional LSPs and co-routed bi-directional LSPs.</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>
<t></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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>
</section>
<section anchor="pw-ach-header" title="LSP-Ping packet over ACH for PWs"
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="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 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> can
be carried in the ACH TLVs <xref
target="I-D.ietf-mpls-tp-ach-tlv"></xref> for identification.</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. The ACH Channel type
MUST be set to the value specified in <xref
target="I-D.ietf-pwe3-vccv-bfd"></xref>. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><xref target="I-D.ietf-pwe3-vccv-bfd"></xref> specifies how BFD can
be used over MPLS PWs.</t>
<t>BFD supports continuous fault monitoring and thus meets the
pro-active Continuity Check and verification requirement specified in
<xref target="I-D.ietf-mpls-tp-oam-requirements"></xref>. BFD SHOULD be
run pro-actively. This function SHOULD be performed between End Points
(MEPs) of PWs, LSPs and Sections. 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. Failure of a BFD session over a LSP can be
used to trigger protection switching or other fault remedial
procedures.</t>
<t>When sending BFD 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> can be carried in the
ACH TLVs <xref target="I-D.ietf-mpls-tp-ach-tlv"></xref> for
identification.</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>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4379;
&RFC4385;
</references>
<references title="Informative References">
&RFC5586;
&ACH-TLV;
&BFD-MPLS;
&VCCV-BFD;
&MPLS-TP-OAM-REQ;
&MPLS-TP-IDENTIFIERS;
&BFD-MPLS-P2MP;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:25 |