One document matched: draft-ietf-mpls-tp-data-plane-04.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="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-tp-data-plane-04"
ipr="trust200902">
<front>
<title abbrev="MPLS-TP Data Plane Architecture">MPLS Transport Profile
Data Plane Architecture</title>
<author fullname="Dan Frost" initials="D" role="editor" surname="Frost">
<organization>Cisco Systems</organization>
<address>
<email>danfrost@cisco.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" role="editor"
surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Matthew Bocci" initials="M" role="editor"
surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<email>matthew.bocci@alcatel-lucent.com</email>
</address>
</author>
<date year="2010" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The Multiprotocol Label Switching (MPLS) Transport Profile
(MPLS-TP) is the set of MPLS protocol functions applicable to the
construction and operation of packet-switched transport networks.
This document specifies the subset of these functions that comprises
the MPLS-TP data plane: the architectural layer concerned with the
encapsulation and forwarding of packets within an MPLS-TP
network.</t>
<t>This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) effort to include
an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of a
packet transport network.</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>The MPLS Transport Profile (MPLS-TP) is the set of functions that
meet the requirements <xref target="RFC5654" /> for the application
of MPLS to the construction and operation of packet-switched
transport networks. MPLS-based packet-switched transport networks,
and the overall architecture of the MPLS-TP, are defined and
described in <xref target="I-D.ietf-mpls-tp-framework" />. It is
assumed that the reader is familiar with that document.</t>
<t>This document defines the set of functions that comprise the
MPLS-TP data plane: the architectural layer concerned with the
encapsulation and forwarding of packets within an MPLS-TP network.
This layer is based on the data plane architectures for MPLS (<xref
target="RFC3031"></xref> and <xref target="RFC3032"></xref>) and for
pseudowires (<xref target="RFC3985"></xref>).</t>
<t>This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) effort to include
an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of a
packet transport network.</t>
<section title="Scope">
<t>This document has the following purposes:
<list style="symbols">
<t>To identify the data plane functions within the MPLS
Transport Profile;</t>
<t>To indicate which of these data plane functions an MPLS-TP
implementation is required to support.</t>
</list></t>
<t>This document defines the encapsulation and forwarding
functions applicable to packets traversing an MPLS-TP Label
Switched Path (LSP), Pseudowire (PW), or Section (see <xref
target="entities"></xref> for the definitions of these transport
entities). Encapsulation and forwarding functions for packets
outside an MPLS-TP LSP, PW, or Section, and mechanisms for
delivering packets to or from MPLS-TP LSPs, PWs, and Sections, are
outside the scope of this document.</t>
</section>
<section title="Terminology">
<texttable align="left" style="headers">
<ttcol>Term</ttcol>
<ttcol>Definition</ttcol>
<c>ACH</c>
<c>Associated Channel Header</c>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>GAL</c>
<c>G-ACh Label</c>
<c>LER</c>
<c>Label Edge Router</c>
<c>LSE</c>
<c>Label Stack Entry</c>
<c>LSP</c>
<c>Label Switched Path</c>
<c>LSR</c>
<c>Label Switching Router</c>
<c>MPLS-TP</c>
<c>MPLS Transport Profile</c>
<c>OAM</c>
<c>Operations, Administration and Maintenance</c>
<c>PW</c>
<c>Pseudowire</c>
<c>QoS</c>
<c>Quality of Service</c>
<c>S-PE</c>
<c>PW Switching Provider Edge Node</c>
<c>T-PE</c>
<c>PW Terminating Provider Edge Node</c>
<c>TTL</c>
<c>Time To Live</c>
</texttable>
<t>Additional definitions and terminology can be found in <xref
target="I-D.ietf-mpls-tp-framework"></xref> and <xref
target="RFC5654"></xref>.</t>
</section>
</section>
<section title="MPLS-TP Packet Encapsulation and Forwarding" anchor="pencap">
<t>MPLS-TP packet encapsulation and forwarding SHALL operate
according to the MPLS data plane architecture described in <xref
target="RFC3031"></xref> and <xref target="RFC3032"></xref>, and the
data plane architectures for Single-Segment Pseudowires and
Multi-Segment Pseudowires (see <xref target="pw" />), except as
noted otherwise in this document. The MPLS-TP data plane satisfies
the requirements specified in <xref target="RFC5654" />. </t>
<t>Since an MPLS-TP packet is an MPLS packet as defined in <xref
target="RFC3031"></xref> and <xref target="RFC3032"></xref>, it
will have an associated label stack, and the 'push', 'pop', and
'swap' label processing operations specified in those documents
apply. The label stack represents a hierarchy of Label Switched
Paths (LSPs). A label is pushed to introduce an additional
level of LSP hierarchy and popped to remove it. Such an
additional level may be introduced by any pair of LSRs,
whereupon they become adjacent at this new level, and are then
known as Label Edge Routers (LERs) with respect to the new
LSP.</t>
<t>In contrast to, for example, Section 3.10 of <xref
target="RFC3031" />, support for Internet Protocol (IP) host and
router data plane functionality by MPLS-TP interfaces and in
MPLS-TP networks is OPTIONAL.</t>
<t>MPLS-TP forwarding is based on the label that identifies an LSP
or PW. The label value specifies the processing operation to be
performed by the next hop at that level of encapsulation. A swap of
this label is an atomic operation in which the contents of the
packet after the swapped label are opaque to the forwarding
function. The only event that interrupts a swap operation is Time To
Live (TTL) expiry.</t>
<t>At an LSR, S-PE, or T-PE, further processing to determine the
context of a packet occurs when a swap operation is interrupted by
TTL expiry. If the TTL of an LSP label expires, then the label with
the S (Bottom of Stack) bit set is inspected to determine if it is a
reserved label. If it is a reserved label, the packet is processed
according to the rules of that reserved label. For example, if it is
a Generic Associated Channel Label (GAL), then it is processed as a
packet on the G-ACh; see <xref target="gach"></xref>. If the TTL of
a PW expires at an S-PE or T-PE, then the packet is examined to
determine if a Generic Associated Channel Header (ACH) is present
immediately below the PW label. If so, then the packet is processed
as a packet on the G-ACh.</t>
<t>Similarly, if a pop operation at an LER exposes a reserved
label at the top of the label stack, then the packet is
processed according to the rules of that reserved label.</t>
<t>If no such exception occurs, the packet is forwarded according to
the procedures in <xref target="RFC3031"></xref> and <xref
target="RFC3032"></xref>.</t>
</section>
<section anchor="entities" title="MPLS-TP Transport Entities">
<t>The MPLS Transport Profile includes the following data plane
transport entities:
<list style="symbols">
<t>Label Switched Paths (LSPs)</t>
<t>Sections</t>
<t>Pseudowires (PWs)</t>
</list>
</t>
<section title="Label Switched Paths">
<t>MPLS-TP LSPs are ordinary MPLS LSPs as defined in <xref
target="RFC3031"></xref> except as specifically noted otherwise in
this document.</t>
<section title="LSP Packet Encapsulation and Forwarding">
<t>Encapsulation and forwarding of packets traversing MPLS-TP
LSPs MUST follow standard MPLS packet encapsulation and
forwarding as defined in <xref target="RFC3031"></xref>, <xref
target="RFC3032"></xref>, <xref target="RFC5331"></xref>, and
<xref target="RFC5332"></xref>, except as explicitly stated
otherwise in this document.</t>
<t>Data plane Quality of Service capabilities are included in
the MPLS-TP in the form of Traffic Engineered (TE) LSPs <xref
target="RFC3209"></xref> and the MPLS Differentiated Services
(DiffServ) architecture <xref target="RFC3270"></xref>. Both
E-LSP and L-LSP MPLS DiffServ modes are included. The Traffic
Class field (formerly the EXP field) of an MPLS label follows
the definition of <xref target="RFC5462"></xref> and <xref
target="RFC3270"></xref> and MUST be processed according to the
rules specified in those documents.</t>
<t>Except for transient packet reordering which may occur, for
example, during fault conditions, packets are delivered in order
on L-LSPs, and on E-LSPs within a specific ordered
aggregate.</t>
<t>The Uniform, Pipe and Short Pipe DiffServ tunneling and TTL
processing models described in <xref target="RFC3270"></xref>
and <xref target="RFC3443"></xref> MAY be used for MPLS-TP LSPs.
Note however that support for the Pipe or Short Pipe models is
REQUIRED for typical transport applications, in which the
topology and QoS characteristics of the MPLS-TP server layer are
independent of the client layer. Specific applications MAY
place further requirements on the DiffServ tunneling and TTL
processing models an LSP can use.</t>
<t>Per-platform, per-interface or other context-specific label
space <xref target="RFC5331"></xref> MAY be used for MPLS-TP
LSPs. Downstream <xref target="RFC3031"></xref> or upstream
<xref target="RFC5331"></xref> label allocation schemes MAY be
used for MPLS-TP LSPs. The requirements of a particular LSP type
may, however, dictate which label spaces or allocation schemes
it can use.</t>
<t>Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be
performed on an MPLS-TP LSP. MPLS-TP LSPs as defined in this
document MAY operate over a server layer that supports
load-balancing, but this load-balancing MUST operate in such a
manner that it is transparent to MPLS-TP. This does not
preclude the future definition of new MPLS-TP LSP types which
have different requirements regarding the use of ECMP in the
server layer.</t>
<t>Penultimate Hop Popping (PHP) MUST be disabled by default on
MPLS-TP LSPs.</t>
</section>
<section title="LSP Payloads">
<t>The MPLS-TP includes support for the following LSP payload
types:
<list style="symbols">
<t>Network-layer protocol packets (including MPLS-labeled
packets)</t>
<t>Pseudowire packets</t>
</list>
</t>
<t>The rules for processing LSP payloads that are network-layer
protocol packets SHALL be as specified in <xref
target="RFC3032"></xref>.</t>
<t>The rules for processing LSP payloads that are pseudowire
packets SHALL be as defined in the data plane pseudowire
specifications (see <xref target="pw"></xref>).</t>
<t>The payload of an MPLS-TP LSP may be a packet that itself
contains an MPLS label stack. This is true, for instance, when
the payload is a pseudowire or an MPLS LSP. In such cases, the
label stack is contiguous between the MPLS-TP LSP and its
payload, and exactly one LSE in this stack SHALL have the S
(Bottom of Stack) bit set to 1. This behaviour reflects best
current practice in MPLS but differs slightly from <xref
target="RFC3032" />, which uses the S bit to identify when MPLS
label processing stops and network layer processing starts.</t>
</section>
<section anchor="lsptypes" title="LSP Types">
<t>The MPLS-TP includes the following LSP types:
<list style="symbols">
<t>Point-to-point unidirectional</t>
<t>Point-to-point associated bidirectional</t>
<t>Point-to-point co-routed bidirectional</t>
<t>Point-to-multipoint unidirectional</t>
</list>
</t>
<t>Point-to-point unidirectional LSPs are supported by the basic
MPLS architecture <xref target="RFC3031"></xref> and are
REQUIRED to function in the same manner in the MPLS-TP data
plane except as explicitly stated otherwise in this
document.</t>
<t>A point-to-point associated bidirectional LSP between LSRs A
and B consists of two unidirectional point-to-point LSPs, one
from A to B and the other from B to A, which are regarded as a
pair providing a single logical bidirectional transport
path.</t>
<t>A point-to-point co-routed bidirectional LSP is a
point-to-point associated bidirectional LSP with the additional
constraint that its two unidirectional component LSPs in each
direction follow the same path (in terms of both nodes and
links). An important property of co-routed bidirectional LSPs
is that their unidirectional component LSPs share fate.</t>
<t>A point-to-multipoint unidirectional LSP functions in the
same manner in the data plane, with respect to basic label
processing and packet-switching operations, as a point-to-point
unidirectional LSP, with one difference: an LSR may have more
than one (egress interface, outgoing label) pair associated with
the LSP, and any packet it transmits on the LSP is transmitted
out all associated egress interfaces. Point-to-multipoint LSPs
are described in <xref target="RFC4875"></xref> and <xref
target="RFC5332"></xref>. TTL processing and exception handling
for point-to-multipoint LSPs is the same as for point-to-point
LSPs and is described in <xref target="pencap" />.</t>
</section>
</section>
<section title="Sections">
<t>Two MPLS-TP LSRs are considered to be topologically adjacent at
a particular layer n >= 0 of the MPLS-TP LSP hierarchy if there
exists connectivity between them at the next lowest network layer,
and if there is no MPLS layer processing at layer n between the
two LSRs (other than at the LSRs themselves). Such connectivity,
if it exists, will be either an MPLS-TP LSP (if n > 0) or a
data-link provided by the underlying server layer network (if n =
0), and is referred to as an MPLS-TP Section at layer n of the
MPLS-TP LSP hierarchy. Thus, the links traversed by a layer n+1
MPLS-TP LSP are layer n MPLS-TP sections. Such an LSP is referred
to as a client of the section layer, and the section layer as the
server layer with respect to its clients.</t>
<t>The MPLS label stack associated with an MPLS-TP section at
layer n consists of n labels, in the absence of stack optimisation
mechanisms. In order for two LSRs to exchange non-IP MPLS-TP
control packets over a section, an additional label, the G-ACh
Label (GAL) (see <xref target="gach"></xref>) MUST appear at the
bottom of the label stack.</t>
<t>An MPLS-TP section may provide one or more of the following
types of service to its client layer:
<list style="symbols">
<t>Point-to-point bidirectional</t>
<t>Point-to-point unidirectional</t>
<t>Point-to-multipoint unidirectional</t>
</list>
The manner in which a section provides such a service is outside
the scope of the MPLS-TP.</t>
<t>An LSP of any of the types listed in <xref
target="lsptypes"></xref> may serve as a section for a
client-layer transport entity as long as it supports the type of
service the client requires.</t>
<t>A section MUST provide a means of identifying the type of
payload it carries. If the section is a data-link, link-specific
mechanisms such as a protocol type indication in the data-link
header MAY be used. If the section is an LSP, this information MAY
be implied by the LSP label or, if the LSP payload is
MPLS-labeled, by the setting of the S bit. Additional labels MAY
also be used if necessary to distinguish different payload types;
see <xref target="I-D.ietf-mpls-tp-framework" /> for examples and
further discussion.</t>
</section>
<section anchor="pw" title="Pseudowires">
<t>The data plane architectures for Single-Segment Pseudowires
<xref target="RFC3985"></xref> and Multi-Segment Pseudowires <xref
target="RFC5659"></xref> are included in the MPLS-TP.</t>
<t>Data plane processing procedures for pseudowires are defined
and described in a number of IETF documents. Some example
pseudowire data plane procedures include:
<list style="symbols">
<t>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN <xref target="RFC4385" /></t>
<t>Encapsulation Methods for Transport of Ethernet over MPLS
Networks <xref target="RFC4448" /></t>
<t>Structure-Agnostic Time Division Multiplexing (TDM) over
Packet (SAToP) <xref target="RFC4553" /></t>
<t>Encapsulation Methods for Transport of PPP/High-Level Data
Link Control (HDLC) over MPLS Networks <xref target="RFC4618"
/></t>
<t>Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks <xref
target="RFC4619" /></t>
<t>Encapsulation Methods for Transport of Asynchronous
Transfer Mode (ATM) over MPLS Networks <xref target="RFC4717"
/></t>
<t>Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous
Transfer Mode (ATM) Transparent Cell Transport Service <xref
target="RFC4816" /></t>
<t>Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation over Packet (CEP) <xref
target="RFC4842" /></t>
<t>Structure-Aware Time Division Multiplexed (TDM) Circuit
Emulation Service over Packet Switched Network (CESoPSN) <xref
target="RFC5086" /></t>
<t>Time Division Multiplexing over IP (TDMoIP) <xref
target="RFC5087" /></t>
<t>Encapsulation Methods for Transport of Fibre Channel Frames
Over MPLS Networks <xref target="I-D.ietf-pwe3-fc-encap"
/></t>
</list>
</t>
<t>This document specifies no modifications or extensions to
pseudowire data plane architectures or protocols.</t>
</section>
</section>
<section anchor="gach" title="MPLS-TP Generic Associated Channel">
<t>The MPLS Generic Associated Channel (G-ACh) mechanism is
specified in <xref target="RFC5586"></xref> and included in the
MPLS-TP. The G-ACh provides an auxiliary logical data channel
associated with MPLS-TP Sections, LSPs, and PWs in the data plane.
The primary purpose of the G-ACh in the context of MPLS-TP is to
support control, management, and Operations, Administration and
Maintenance (OAM) traffic associated with MPLS-TP transport
entities. The G-ACh MUST NOT be used to transport client layer
network traffic in MPLS-TP networks.</t>
<t>For pseudowires, the G-ACh uses the first four bits of the PW
control word to provide the initial discrimination between data
packets and packets belonging to the associated channel, as
described in <xref target="RFC4385"></xref>. When this first nibble
of a packet, immediately following the label at the bottom of stack,
has a value of '1', then this packet belongs to a G-ACh. The first
32 bits following the bottom of stack label then have a defined
format called an Associated Channel Header (ACH), which further
defines the content of the packet. The ACH is therefore both a
demultiplexer for G-ACh traffic on the PW, and a discriminator for
the type of G-ACh traffic.</t>
<t>When the control message is carried over a section or an LSP,
rather than over a PW, it is necessary to provide an indication in
the packet that the payload is something other than a client data
packet. This is achieved by including a reserved label with a value
of 13 at the bottom of the label stack. This reserved label is
referred to as the G-ACh Label (GAL), and is defined in <xref
target="RFC5586"></xref>. When a GAL is found, it indicates that the
payload begins with an ACH. The GAL is thus a demultiplexer for
G-ACh traffic on the section or the LSP, and the ACH is a
discriminator for the type of traffic carried on the G-ACh. MPLS-TP
forwarding follows the normal MPLS model, and thus a GAL is
invisible to an LSR unless it is the top label in the label
stack. The only other circumstance under which the label stack may
be inspected for a GAL is when the TTL has expired. Normal packet
forwarding MAY continue concurrently with this inspection. All
operations on the label stack are in accordance with <xref
target="RFC3031"></xref> and <xref target="RFC3032"></xref>.</t>
<t>An application processing a packet received over the G-ACh
may require packet-specific context (such as the receiving
interface or received label stack). Data plane implementations
MUST therefore provide adequate context to the application which
is to process a G-ACh packet. The definition of the context
required MUST be provided as part of the specification of the
application using the G-ACh.</t>
</section>
<section title="Server Layer Considerations">
<t>The MPLS-TP network has no awareness of the internals of the
server layer of which it is a client, requiring only that the server
layer be capable of delivering the type of service required by the
MPLS-TP transport entities that make use of it. Note that what
appears to be a single server layer link to the MPLS-TP network may
be a complicated construct underneath, such as an LSP or a
collection of underlying links operating as a bundle. Special care
may be needed in network design and operation when such constructs
are used as a server layer for MPLS-TP.</t>
<t>Encapsulation of MPLS-TP packets for transport over specific
server-layer media is outside the scope of this document.</t>
</section>
<section title="Security Considerations">
<t>The MPLS data plane (and therefore the MPLS-TP data plane) does
not provide any security mechanisms in and of itself. Client layers
that wish to secure data carried over MPLS-TP transport entities are
REQUIRED to apply their own security mechanisms.</t>
<t>Where management or control plane protocols are used to install
label switching operations necessary to establish MPLS-TP transport
paths, those protocols are equipped with security features and
network operators may use those features to securely create the
transport paths.</t>
<t>Where enhanced security is desirable, and a trust relationship
exists between an LSR and its peer, the LSR MAY choose to implement
the following policy for the processing of MPLS packets received
from one or more of its neighbours:
<list style="empty">
<t>Upon receipt of an MPLS packet, discard the packet unless one
of the following two conditions holds:
<list style="numbers">
<t>Any MPLS label in the packet's label stack processed at the
receiving LSR, such as an LSP or PW label, has a label value
that the receiving LSR has distributed to that neighbour;
or</t>
<t>Any MPLS label in the packet's label stack processed at the
receiving LSR, such as an LSP or PW label, has a label value
that the receiving LSR has previously distributed to the peer
beyond that neighbour (i.e., when it is known that the path
from the system to which the label was distributed to the
receiving system is via that neighbour).</t>
</list>
</t>
</list>
</t>
<t>Further details of MPLS and MPLS-TP security can be found in
<xref target="I-D.ietf-mpls-tp-framework" /> and <xref
target="I-D.ietf-mpls-mpls-and-gmpls-security-framework"></xref>.</t>
</section>
<section title="IANA Considerations">
<t>This document introduces no new IANA considerations.</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.5654'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.3209'?>
<?rfc include='reference.RFC.3270'?>
<?rfc include='reference.RFC.3443'?>
<?rfc include='reference.RFC.5462'?>
<?rfc include='reference.RFC.5331'?>
<?rfc include='reference.RFC.4875'?>
<?rfc include='reference.RFC.5332'?>
<?rfc include="reference.RFC.4717"?>
<?rfc include='reference.RFC.4816'?>
<?rfc include='reference.RFC.4385'?>
<?rfc include='reference.RFC.4448'?>
<?rfc include='reference.RFC.4619'?>
<?rfc include='reference.RFC.4618'?>
<?rfc include='reference.RFC.4553'?>
<?rfc include='reference.RFC.4842'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-mpls-tp-framework'?>
<?rfc include='reference.I-D.ietf-mpls-mpls-and-gmpls-security-framework'?>
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.RFC.5659'?>
<?rfc include='reference.RFC.5087'?>
<?rfc include='reference.I-D.ietf-pwe3-fc-encap'?>
<?rfc include='reference.RFC.5086'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:01 |