One document matched: draft-ietf-mpls-tp-gach-gal-01.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="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-tp-gach-gal-01" ipr="trust200811"
updates="3032, 4385, 5085">
<front>
<title abbrev="GACH and GAL">MPLS Generic Associated Channel</title>
<author fullname="Matthew Bocci" initials="M." role="editor"
surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>matthew.bocci@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Martin Vigoureux" initials="M." role="editor"
surname="Vigoureux">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>martin.vigoureux@alcatel-lucent.com</email>
</address>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>swallow@cisco.com</email>
</address>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization>Cisco</organization>
<address>
<email>dward@cisco.com</email>
</address>
</author>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization>Juniper Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>rahul@juniper.net</email>
</address>
</author>
<date day="6" month="January" year="2009" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS-TP</keyword>
<keyword>MPLS</keyword>
<keyword>Internet Draft</keyword>
<abstract>
<t>This document generalises the applicability of the pseudowire
Associated Channel Header (ACH), enabling the realization of a control
channel associated to MPLS Label Switched Paths (LSP), MPLS pseudowires
(PW) and MPLS Sections. In order to identify the presence of the Generic
ACH (G-ACH), this document also assigns of one of the reserved MPLS
label values to the 'Generic Associated channel header Label (GAL)', to
be used as a label based exception mechanism.</t>
</abstract>
<note title="Requirements Language">
<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">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>There is a need for Operations, Administration and Maintenance (OAM)
mechanisms that can be used for edge-to-edge (i.e. between originating
and terminating LSRs or T-PEs) and segment (e.g. between any two LSRs or
T-PEs/S-PEs along the path of a LSP or PW <xref
target="I-D.ietf-mpls-tp-framework"></xref>) fault detection,
diagnostics, maintenance and other functions for a PW and a LSP. Some of
these functions can be supported using tools such as VCCV <xref
target="RFC5085"></xref>, BFD <xref target="I-D.ietf-bfd-mpls"></xref>,
or LSP-Ping <xref target="RFC4379"></xref>. However, a requirement has
been indicated to augment the set of maintenance functions, in
particular where MPLS networks are used for packet transport services
and network operations <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>. Examples include
performance monitoring, automatic protection switching, and support for
management and signaling communication channels. These tools must be
applicable to, and function in essentially the same manner (from an
operational point of view) on both MPLS PWs and MPLS LSPs. They must
also operate in-band on the PW or LSP such that they do not depend on
PSN routing, user data traffic or ultimately on PSN or other dynamic
control plane functions.</t>
<t>Virtual Circuit Connectivity Verification (VCCV) can use an
associated channel to provide a control channel between a PW's ingress
and egress points and over which OAM and other control messages can be
exchanged. In this document, we propose a generic associated channel
header (G-ACH) to enable the same control channel mechanism be used for
MPLS Sections, LSPs and PWs. The associated channel header (ACH)
specified in RFC 4385 <xref target="RFC4385"></xref> is used with
additional code points to support additional MPLS maintenance
functions.</t>
<t>Generalizing the ACH mechanism to MPLS LSPs and MPLS Sections also
requires a method to identify that a packet contains a G-ACH followed by
a non-service payload. This document therefore also defines a label
based exception mechanism (the Generic Associated channel header Label,
or GAL) that serves to inform an LSR that a packet that it receives on
an LSP or section belongs to an associated channel.</t>
<t>RFC 4379 <xref target="RFC4379"></xref> and BFD for MPLS LSPs <xref
target="I-D.ietf-bfd-mpls"></xref> have defined alert mechanisms that
enable a MPLS LSR to identify and process MPLS OAM packets when the OAM
packets are encapsulated in an IP header. These alert mechanisms are
based on TTL expiration and/or use an IP destination address in the
range 127/8. These mechanisms are the default mechanisms for identifying
MPLS OAM packets when the OAM packets are encapsulated in an IP header.
However it may not always be possible to use these mechanisms in some
MPLS applications, (e.g. MPLS-TP <xref
target="I-D.ietf-mpls-tp-framework"></xref>) particularly when IP based
demultiplexing cannot be used. This document proposes an OPTIONAL
mechanism that is RECOMMENDED for identifying and demultiplexing MPLS
OAM and other maintenance messages when IP based mechanisms such as
those in <xref target="RFC4379"></xref> and <xref
target="I-D.ietf-bfd-mpls"></xref> are not available.</t>
<t>The G-ACH and GAL mechanisms are defined to work together.</t>
<t>Note that, in this document, maintenace functions and packets should
be understood in the broad sense, that is, as a set of FCAPS mechanisms
that include OAM, Automatic Protection Switching (APS), Signalling
Communication Channel (SCC) and Management Communication Channel (MCC)
messages.</t>
<t>Note that the GAL and G-ACH are applicable to MPLS in general. Their
applicability to specific applications is outside the scope of this
document. For example, the applicability of the GAL and G-ACH to MPLS-TP
is described in <xref target="I-D.ietf-mpls-tp-framework"></xref> and
<xref target="I-D.busi-mpls-tp-oam-framework"></xref>.</t>
<section title="Contributing Authors">
<t>The editors gratefully acknowledge the contibution of Stewart
Bryant, Italo Busi, Marc Lasserre, and Lieven Levrau.</t>
</section>
<section title="Objectives">
<t>This document proposes a mechanism to provide for the extended
maintenance needs of emerging applications for MPLS. It creates a
generic control channel identification mechanism that may be applied
to all MPLS LSPs, while maintaining compatibility with the PW
associated channel header (ACH) . It also normalizes the use of the
ACH for PWs in a transport context.</t>
</section>
<section title="Scope">
<t>This document defines the encapsulation header for LSP, MPLS
Section and PW associated channel messages.</t>
<t>It does not define how associated channel capabilities are signaled
or negotiated between LSRs or PEs, the operation of various OAM
functions, nor how the messages transmitted on the associated
channel.</t>
<t>This document does not deprecate existing MPLS and PW OAM
mechanisms.</t>
</section>
<section title="Terminology">
<t>G-ACH: Generic Associated Channel Header</t>
<t>GAL: Generic Associated Channel Header Label</t>
<t>MPLS Section: A network segment between two LSRs that are
immediately adjacent at the MPLS layer</t>
<t>Maintenance Packet: Any packet containing a message belonging to a
maintenace protocol that is carried on a PW, LSP or MPLS Section
associated channel. Examples of such maintenance protocols include OAM
functions, signaling communications or management communications.</t>
</section>
</section>
<section title="Generic Associated Channel Header">
<t>VCCV <xref target="RFC5085"></xref> defines three MPLS Control
Channel (CC) Types that may be used to multiplex OAM messages onto a PW:
CC Type 1 uses an associated channel header and is referred to as
"In-band VCCV"; CC Type 2 uses the MPLS Router Alert Label to indicate
VCCV packets and is referred to as "Out of Band VCCV"; CC Type 3 uses
the TTL to force the packet to be processed by the targeted router
control plane and is referred to as "MPLS PW Label with TTL == 1".</t>
<t>The use of the CC Type 1, currently limited to MPLS PWs, is here
extended to apply to MPLS LSPs as well as to MPLS Sections. This
associated channel header is called the Generic Associated Channel
Header (G- ACH). The PWE3 control word MUST be present in the
encapsulation of user packets when the G-ACH is used to demultiplex the
associated channel packet on a PW.</t>
<t>The CC Type 1 channel header is depicted in figure below:</t>
<t><figure anchor="G-ACH" title="Generic Associated Channel Header">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|A| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>In the above figure, the first nibble is set to 0001b to indicate a
channel associated with a PW, a LSP or a Section. The Version field is
set to 0, as specified in RFC 4385 <xref target="RFC4385"></xref>. This
draft allocates Bit 8 of the ACH to the ACH TLV bit. This bit is set to
1 to indicate that an object defined in the ACH TLV registry immediately
follows the G-ACH, otherwise it is set to 0. Bits 8 to 14 of the G-ACH
are reserved and MUST be set to 0..</t>
<t>Note that VCCV also includes mechanisms for negotiating the Control
Channel and Connectivity Verification (i.e. OAM functions) Types between
PEs. It is anticipated that similar mechanisms will be applied to
existing MPLS LSPs. Such application will require further specification.
However, such specification is beyond the scope of this document.</t>
<section title="Allocation of Channel Types">
<t>The Channel Type field indicates the type of message carried on the
associated channel e.g. IPv4 or IPv6 if IP demultiplexing is used for
messages on the G-ACH, or OAM or other FCAPS function if IP
demultiplexing is not used. For G-ACH packets where IP is not used as
the multiplexer, the Channel Type SHOULD indicate the specific
maintenance protocol carried in the associated channel.</t>
<t>Values for the Channel Type field currently used for VCCV are
specified in RFC 4446 <xref target="RFC4446"></xref>. The
functionality of any additional channel types will be defined in
another document. Each associated channel protocol solution document
must specify the value to use for any additional channel types.</t>
<t>Note that these values are allocated from the PW Associated Channel
Type registry, but this document modifies the existing policy to
accomodate a level of experimentation. See <xref target="IANA"></xref>
for further details.</t>
</section>
</section>
<section title="Generalised Exception Mechanism">
<t>The above mechanism enables the multiplexing of various maintenace
packets onto a PW, LSP or Section and provides information on the type
of function being performed. In the case of a PW, the use of a control
word is negotiated or configured at the time of the PW establishment. A
special case of the control word (the G-ACH) is used to identify packets
belonging to a PW associated channel.</t>
<t>Generalizing the ACH mechanism to MPLS LSPs and MPLS Sections also
requires a method to identify that a packet contains a G-ACH followed by
a non-service payload. This document specifies that a label be used and
calls this special label the 'Generic Associated channel header Label
(GAL)'. One of the reserved label values defined in RFC 3032 <xref
target="RFC3032"></xref> is assigned for this purpose. The value of the
label is to be allocated by IANA; this document suggests the value
13.</t>
<t>The GAL provides a generalised exception mechanism to:</t>
<t><list style="symbols">
<t>Differentiate specific packets (e.g. those containing OAM
messages) from others, such as normal user-plane ones,</t>
<t>Indicate that the Generic Associated Channel Header (G-ACH)
appears immediately after the bottom of the label stack.</t>
</list>The 'Generic Associated channel header Label (GAL)' MUST only
be used where both of these purposes are applicable.</t>
<section title="Relationship with Existing MPLS OAM Alert Mechanisms">
<t>RFC 4379 <xref target="RFC4379"></xref> and BFD for MPLS LSPs <xref
target="I-D.ietf-bfd-mpls"></xref> have defined alert mechanisms that
enable a MPLS LSR to identify and process MPLS OAM packets when the
OAM packets are encapsulated in an IP header. These alert mechanisms
are based on TTL expiration and/or use an IP destination address in
the range 127/8.</t>
<t>These alert mechanisms SHOULD preferably be used in non MPLS-TP
environments. The mechanism defined in this document MAY also be
used.</t>
</section>
<section title="GAL Applicability and Usage">
<t>The 'Generic Associated channel header Label (GAL)' MUST only be
used with Label Switched Paths (LSPs), with their associated Tandem
Connection Monitoring Entities (see <xref
target="I-D.busi-mpls-tp-oam-framework"></xref> for definitions of
TCMEs) and with MPLS Sections.</t>
<t>The GAL applies to both P2P and P2MP LSPs, unless otherwise
stated.</t>
<t>In MPLS-TP, the GAL MUST always be at the bottom of the label stack
(i.e. S bit set to 1). However, in other MPLS environments, this
document places no restrictions on where the GAL may appear within the
label stack.</t>
<t>The GAL MUST NOT appear in the label stack when transporting normal
user-plane packets. Furthermore, the GAL MUST only appear once in the
label stack for packets on the generic associated channel.</t>
<section title="GAL Processing">
<t>The Traffic Class (TC) field (formerly known as the EXP field) of
the label stack entry containing the GAL follows the definition and
processing rules specified and referenced in <xref
target="I-D.ietf-mpls-cosfield-def"></xref>.</t>
<t>The Time-To-Live (TTL) field of the label stack entry that
contains the GAL follows the definition and processing rules
specified in <xref target="RFC3443"></xref>.</t>
<section title="MPLS Section">
<t>The following figure (<xref target="Section-OAM"></xref>)
depicts two MPLS LSRs immediately adjacent at the MPLS layer.</t>
<t><figure anchor="Section-OAM"
title="Maintenance over an MPLS Section Associated Channel">
<artwork><![CDATA[ +---+ +---+
| A |-------------| Z |
+---+ +---+ ]]></artwork>
</figure></t>
<t>With regards to the MPLS Section, both LERs are Maintenance End
Points (see <xref target="I-D.busi-mpls-tp-oam-framework"></xref>
for definitions of MEPs).</t>
<t>The following figure (<xref
target="Section-OAM-Message"></xref>) depicts the format of a
labelled OAM packet on an associated channel when used for MPLS
Section maintenance.</t>
<t><figure anchor="Section-OAM-Message"
title="Maintenance Packet Format for MPLS Section">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generic-ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. Maintenance Message .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>To send a MPLS-TP maintenance packet on an associated channel
of the MPLS Section, the head-end LSR (A) of the MPLS Section
generates a maintenance packet with a G-ACH to which it pushes a
GAL.</t>
<t><list style="symbols">
<t>The TTL field of the GAL SHOULD be set to 1.</t>
<t>The S bit of the GAL MUST be set to 1 in MPLS-TP.</t>
</list></t>
<t>The maintenance packet, the G-ACH and the GAL SHOULD NOT be
modified towards the tail-end LSR (Z). Upon reception of the
labelled packet, the tail-end LSR (Z), after having checked the
GAL fields, SHOULD pass the whole packet to the appropriate
processing entity.</t>
</section>
<section title="Label Switched Paths">
<t>The following figure (<xref target="LSP-OAM"></xref>) depicts
four LSRs. A LSP is established from A to D and switched in B and
C.</t>
<t><figure anchor="LSP-OAM"
title="Maintenance over an LSP Associated Channel">
<artwork><![CDATA[ +---+ +---+ +---+ +---+
| A |-------------| B |-------------| C |-------------| D |
+---+ +---+ +---+ +---+
]]></artwork>
</figure></t>
<t>LERs A and D are Maintenance End Points (MEPs) with respect to
this LSP. Furthermore, LSRs B and C could also be Maintenance
Intermediate Points (MIPs) with respect to this LSP (see <xref
target="I-D.busi-mpls-tp-oam-framework"></xref> for definitions of
MEPs and MIPs).</t>
<t>The following figure (<xref target="LSP-OAM-Message"></xref>)
depicts the format of a labelled maintenance packet when used for
a MPLS-TP LSP.</t>
<t><figure anchor="LSP-OAM-Message"
title="Maintenance Packet Format for MPLS-TP LSP">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generic-ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. Maintenance Message .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure></t>
<t>Note that it is possible that the LSP MAY also be tunnelled in
another LSP (e.g. if a MPLS Tunnel exists between B and C), and as
such other labels MAY be present above it in the label stack.</t>
<t>To send a maintenance packet on the LSP associated channel, the
head-end LSR (A) generates a OAM message with a G-ACH on which it
first pushes a GAL followed by the LSP label.</t>
<t><list style="symbols">
<t>The TTL field of the GAL SHOULD be set to 1.</t>
<t>The S bit of the GAL SHOULD be set to 1 in MPLS-TP.</t>
</list>The maintenance message, the G-ACH or the GAL SHOULD NOT
be modified towards the targeted destination. Upon reception of
the labelled packet, the targeted destination, after having
checked both the LSP label and GAL fields, SHOULD pass the whole
packet to the appropriate processing entity.</t>
</section>
<section title="Tandem Connection Monitoring Entity">
<t>Tandem Connection Monitoring will be specified in a separate
document.</t>
</section>
</section>
</section>
<section title="Relationship wth RFC 3429">
<t>RFC 3429 <xref target="RFC3429"></xref> describes the assignment of
one of the reserved label values, defined in RFC 3032 <xref
target="RFC3032"></xref>, to the 'OAM Alert Label' that is used by
user-plane MPLS OAM functions for the identification of MPLS OAM
packets. The value of 14 is used for that purpose.</t>
<t>Both this document and RFC 3429 <xref target="RFC3429"></xref>
therefore describe the assignment of reserved label values for similar
purposes. The rationale for the assignment of a new reserved label can
be summarized as follows:</t>
<t><list style="symbols">
<t>Unlike the mechanisms described and referenced in RFC 3429
<xref target="RFC3429"></xref>, MPLS-TP OAM packet payloads will
not reside immediately after the GAL but instead behind the G-ACH,
which itself resides immediately after the bottom of the label
stack when the GAL is present. This ensures that OAM using the
generic associated channel complies with RFC 4928 <xref
target="RFC4928"></xref>.</t>
<t>The set of maintenance functions potentially operated in the
context of the generic associated channel is wider than the set of
OAM functions referenced in RFC 3429 <xref
target="RFC3429"></xref>.</t>
<t>It has been reported that there are existing implementations
and running deployments using the 'OAM Alert Label' as described
in RFC 3429 <xref target="RFC3429"></xref>. It is therefore not
possible to modify the 'OAM Alert Label' allocation, purpose or
usage. Nevertheless, it is RECOMMENDED by this document that no
further OAM extensions based on 'OAM Alert Label' (Label 14) usage
be specified or developed.</t>
</list></t>
</section>
</section>
<section title="Compatability">
<t>An LER, LSR or PE MUST discard received G-ACH packets if it is not G-
ACH capable, if it is not capable of processing packets on the indicated
G-ACH channel, or if it has not, through means outside the scope of this
document, indicated to the sending LSR, LER or PE that it will process
G-ACH packets received on the indicated channel. The LER, LSR or PE MAY
increment an error counter and MAY also optionally issue a system and/or
SNMP notification.</t>
</section>
<section title="Congestion Considerations">
<t>The congestion considerations detailed in RFC 5085 <xref
target="RFC5085"></xref> apply. Further generic associated
channel-specific congestion considerations will be detailed in a future
revision of this document.</t>
</section>
<section title="Security Consderations">
<t>The security considerations detailed in RFC 5085 <xref
target="RFC5085"></xref>, the MPLS architecture <xref
target="RFC3031"></xref>, the PWE3 architecture <xref
target="RFC3985"></xref> and the MPLS-TP framework <xref
target="I-D.ietf-mpls-tp-framework"></xref> apply.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests that IANA allocates a Label value, to the
'Generic Associated channel header Label (GAL)', from the pool of
reserved labels, and suggests this value to be 13.</t>
<t>Channel Types for the Generic Associated Channel are allocated from
the IANA PW Associated Channel Type registry <xref
target="RFC4446"></xref>. The PW Associated Channel Type registry is
currently allocated based on the IETF consensus process, described
in<xref target="RFC2434"></xref>. This allocation process was chosen
based on the consensus reached in the PWE3 working group that pseudowire
associated channel mechanisms should be reviewed by the IETF and only
those that are consistent with the PWE3 architecture and requirements
should be allocated a code point.</t>
<t>However, a requirement has emerged (see <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>) to allow for
optimizations or extensions to OAM and other control protocols running
in an associated channel to be experimented with without resorting to
the IETF standards process, by supporting experimental code points. This
would prevent code points used for such functions from being used from
the range allocated through the IETF standards and thus protects an
installed base of equipment from potential inadvertent overloading of
code points. In order to support this requirement, this document
requests that the code-point allocation scheme for the PW Associated
Channel Type be changed as follows:</t>
<t>0 - 32751 : IETF Consensus</t>
<t>32752 - 32767 : Experimental</t>
<t>Code points in the experimental range MUST be used according to the
guidelines of RFC 3692 <xref target="RFC3692"></xref>. Experimental OAM
functions MUST be disabled by default. The channel type value used for a
given experimental OAM function MUST be configurable, and care MUST be
taken to ensure that different OAM functions that are not interoperable
are configured to use different channel type values.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3031"?>
<?rfc include="reference.RFC.3032"?>
<?rfc include="reference.RFC.3443"?>
<?rfc include="reference.RFC.3985"?>
<?rfc include="reference.RFC.4379"?>
<?rfc include="reference.RFC.4928"?>
<?rfc include="reference.RFC.5085"?>
<?rfc include="reference.I-D.ietf-bfd-mpls"?>
<?rfc include="reference.I-D.ietf-mpls-cosfield-def"?>
<?rfc include="reference.RFC.4385"?>
<?rfc include="reference.RFC.4446"?>
<?rfc include="reference.RFC.2434"?>
<?rfc include="reference.RFC.3692"?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3429'?>
<?rfc include='reference.I-D.ietf-mpls-tp-oam-requirements'?>
<?rfc include='reference.I-D.ietf-mpls-tp-framework'?>
<?rfc include='reference.I-D.busi-mpls-tp-oam-framework'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:05:29 |