One document matched: draft-ietf-mpls-tp-on-demand-cv-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 RFC5003 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5003.xml">
<!ENTITY RFC5860 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5860.xml">
<!ENTITY RFC5884 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5884.xml">
<!ENTITY MPLS-TP-OAM-FRAMEWORK SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-oam-framework.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 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.ietf-mpls-tp-identifiers.xml">
<!ENTITY MPLS-TP-ROSETTA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-rosetta-stone.xml">
<!ENTITY LSP-PING-ACH SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-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-ietf-mpls-tp-on-demand-cv-00"
ipr="trust200902">
<front>
<title abbrev="MPLS on-demand Connectivity Verification">MPLS on-demand Connectivity Verification, Route Tracing and Adjacency Verification</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="27" month="July" 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 is an existing and widely deployed 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 for on-demand monitoring of MPLS-TP LSPs. It also clarifies
the procedures to be used for processing the OAM packets. This document
describes how LSP-Ping can be used to perform on-demand Connectivity
Verification, Route Tracing and Adjacency functions required in <xref
target="RFC5860"></xref> and specified in
<xref target="I-D.ietf-mpls-tp-oam-framework"></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="RFC5884"></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 SHOULD be run
without IP addressing, using the ACH channel type specified in <xref
target="I-D.ietf-mpls-tp-lsp-ping-bfd-procedures"></xref>.</t>
<t><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-new-addr-type"
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 SHOULD 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>. A LSP-Ping
packet MUST NOT include more than 1 source address TLV. 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 1 (Malformed echo request received), [ Section 3.1 <xref
target="RFC4379"></xref> ], MUST be returned, if it is possible to
unambiguously identify the source of the packet.</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 <xref
target="I-D.ietf-mpls-tp-rosetta-stone"></xref>. The MEP/MIP
identifiers defined in <xref
target="I-D.ietf-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) MUST 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 anchor="static-fecs"
title="Identifying Statically provisioned LSPs and PWs">
<t><xref target="RFC4379"></xref> specifies how an MPLS LSP under test
may be identified in an echo request. A Target FEC Stack TLV is used
to identify the LSP. In order to identify a statically provisioned LSP
and PW, new target FEC stack sub-TLVs are being defined. The new
sub-TLVs are assigned sub-type identifiers as follows, and are
described in the following sections.</t>
<figure align="left" anchor="new-fec-types"
title="New target FEC sub-types">
<artwork><![CDATA[
Sub-Type # Length Value Field
---------- ------ -----------
TBD 24 Static LSP
TBD 24 Static Pseudowire
]]></artwork>
</figure>
<section title="Static LSP Sub-TLV" toc="include">
<t>The format of the Static LSP sub-TLV value field is specified in
the following figure. The value fields are taken from the
definitions in <xref
target="I-D.ietf-mpls-tp-identifiers"></xref>.</t>
<figure align="left" anchor="static-lsp-fec"
title="Static LSP FEC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Must be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Source global ID and Destination Global ID MAY be set to 0.
When set to zero, the field is not applicable.</t>
</section>
<section title="Static Pseudowire Sub-TLV" toc="include">
<t>The format of the Static PW sub-TLV value field is specified in
the following figure.</t>
<figure anchor="static-pw-fec" title="Static PW FEC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Source global ID and Destination Global ID MAY be set to 0.
When set to zero, the field is not applicable. The Global ID and
Node ID fields are taken from the definitions in <xref
target="I-D.ietf-mpls-tp-identifiers"></xref>. The AC-ID definitions
are taken from <xref target="RFC5003"></xref>.</t>
</section>
</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="RFC5860"></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 LSP forwarding is done 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.</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 title="LSP-Ping with IP encapsulation, over ACH">
<t>IP encapsulated LSP-Ping packets MAY be sent over the MPLS LSP
using control channel (ACH). IP ACH type specified in
<xref target="RFC4385"></xref> MUST be used in such a case. The IP
header is used mainly for addressing and can be used in the context of
MPLS-TP LSPs.</t>
<t>The LSP-Ping echo response message SHOULD be sent on the reverse path
of the LSP using ACH and SHOULD be IP encapsulated.
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. 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="Reverse path Connectivity verification">
<t>For bi-directional LSPs, when the egress sends the echo response,
the egress MAY attach the target FEC stack TLV <xref
target="RFC4379"></xref> in the echo response. The ingress (on receipt
of the echo response) can use the FEC stack TLV to perform reverse
path connectivity verification. For co-routed bi-directional LSPs, the
target FEC stack used for LSP-Ping will be the same in both the
forward and reverse path of the LSP. For associated bi-directional
LSPs, the target FEC stack will be different for the reverse path.</t>
<t>On receipt of the echo response, the ingress MUST perform the
following checks:</t>
<t><list style="numbers">
<t>Perform interface and label-stack validation to ensure that the
packet is received on the reverse path of the bi-directional
LSP</t>
<t>If the target FEC stack is present in the echo response, then
perform FEC validation.</t>
</list>If any of the validations fail, then the ingress MUST drop
the echo response and report an error.</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
Adjacency and Route Tracing requirement specified in <xref
target="RFC5860"></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 those 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, 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 sufficient to identify the LSP
associated with the echo request packet. If there is an error and
the node is unable to identify the LSP on which the echo response
would 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><xref target="static-fecs"></xref> defines 2 new sub-TLV types for
inclusion within the LSP Ping <xref target="RFC4379"></xref> Target FEC
Stack TLV.</t>
<t>IANA is requested to assign sub-type values to the following sub-TLVs
from the "Multiprotocol Label Switching Architecture (MPLS) Label
Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs"
sub-registry.</t>
<figure>
<artwork><![CDATA[
- Static LSP
- Static Pseudowire
]]></artwork>
</figure>
</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;
&RFC4385;
&LSP-PING-ACH;
</references>
<references title="Informative References">
&RFC1122;
&RFC1812;
&RFC5003;
&RFC5860;
&RFC5884;
&ACH-TLV;
&MPLS-TP-OAM-FRAMEWORK;
&MPLS-TP-ROSETTA;
&DDMAP-DRAFT;
&P2MP-LSPING;
&MPLS-TP-IDENTIFIERS;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 06:40:13 |