MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent
Intended status: Informational S. Bryant, Ed.
Expires: July 26, 2010 D. Frost
Cisco Systems
L. Levrau
Alcatel-Lucent
L. Berger
LabN
January 22, 2010
A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-08
Abstract
This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched equivalents of traditional circuit-
switched carrier networks. It describes a common set of protocol
functions - the MPLS Transport Profile (MPLS-TP) - that supports the
operational models and capabilities typical of such networks,
including signaled or explicitly provisioned bi-directional
connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration and Maintenance (OAM)
functions, and network operation in the absence of a dynamic control
plane or IP forwarding support. Some of these functions are defined
in existing MPLS specifications, while others require extensions to
existing specifications to meet the requirements of the MPLS-TP.
This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this
document.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
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 as
defined by the ITU-T.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Bocci, et al. Expires July 26, 2010 [Page 1]
Internet-Draft MPLS Transport Profile Framework January 2010
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Bocci, et al. Expires July 26, 2010 [Page 2]
Internet-Draft MPLS Transport Profile Framework January 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router (LSR) and Label
Edge Router (LER) . . . . . . . . . . . . . . . . . . 7
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8
1.3.7. Additional Definitions and Terminology . . . . . . . . 8
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16
3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17
3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 18
3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25
3.7. Operations, Administration and Maintenance (OAM) . . . . . 28
3.7.1. OAM Architecture . . . . . . . . . . . . . . . . . . . 29
3.7.2. OAM Functions . . . . . . . . . . . . . . . . . . . . 32
3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 35
3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 35
3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 36
3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 36
3.11. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 38
3.11.1. Provisioning of PST . . . . . . . . . . . . . . . . . 39
3.12. Network Management . . . . . . . . . . . . . . . . . . . . 39
4. Security Considerations . . . . . . . . . . . . . . . . . . . 40
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Normative References . . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . . 45
Bocci, et al. Expires July 26, 2010 [Page 3]
Internet-Draft MPLS Transport Profile Framework January 2010
1. Introduction
1.1. Motivation and Background
This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that
meet the requirements in [RFC5654], and that together constitute the
MPLS Transport Profile (MPLS-TP) for point-to-point paths. The
remaining MPLS-TP functions, applicable specifically to point-to-
multipoint paths, are out of scope of this document.
Historically the optical transport infrastructure - Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical
Transport Network (OTN) - has provided carriers with a high benchmark
for reliability and operational simplicity. To achieve this,
transport technologies have been designed with specific
characteristics:
o Strictly connection-oriented connectivity, which may be long-lived
and may be provisioned manually (i.e. configuration of the node
via a command line interface) or by network management.
o A high level of availability.
o Quality of service.
o Extensive OAM capabilities.
Carriers wish to evolve such transport networks to take advantage of
the flexibility and cost benefits of packet switching technology and
to support packet based services more efficiently. While MPLS is a
maturing packet technology that already plays an important role in
transport networks and services, not all MPLS capabilities and
mechanisms are needed in or consistent with the transport network
operational model. There are also transport technology
characteristics that are not currently reflected in MPLS.
There are thus two objectives for MPLS-TP:
1. To enable MPLS to be deployed in a transport network and operated
in a similar manner to existing transport technologies.
2. To enable MPLS to support packet transport services with a
similar degree of predictability to that found in existing
transport networks.
In order to achieve these objectives, there is a need to define a
Bocci, et al. Expires July 26, 2010 [Page 4]
Internet-Draft MPLS Transport Profile Framework January 2010
common set of MPLS protocol functions - an MPLS Transport Profile -
for the use of MPLS in transport networks and applications. Some of
the necessary functions are provided by existing MPLS specifications,
while others require additions to the MPLS tool-set. Such additions
should, wherever possible, be applicable to MPLS networks in general
as well as those that conform strictly to the transport network
model.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
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 as
defined by the ITU-T.
1.2. Scope
This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that
meet the requirements in [RFC5654], and that together constitute the
MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport
paths. The remaining MPLS-TP functions, applicable specifically to
point-to-multipoint transport paths, are out of scope of this
document.
Bocci, et al. Expires July 26, 2010 [Page 5]
Internet-Draft MPLS Transport Profile Framework January 2010
1.3. Terminology
Term Definition
---------- ----------------------------------------------------------
LSP Label Switched Path
MPLS-TP MPLS Transport Profile
SDH Synchronous Digital Hierarchy
ATM Asynchronous Transfer Mode
OTN Optical Transport Network
cl-ps Connectionless - Packet Switched
co-cs Connection Oriented - Circuit Switched
co-ps Connection Oriented - Packet Switched
OAM Operations, Administration and Maintenance
G-ACh Generic Associated Channel
GAL Generic Alert Label
MEP Maintenance End Point
MIP Maintenance Intermediate Point
APS Automatic Protection Switching
SCC Signaling Communication Channel
MCC Management Communication Channel
EMF Equipment Management Function
FM Fault Management
CM Configuration Management
PM Performance Management
LSR Label Switching Router
MPLS-TP PE MPLS-TP Provider Edge LSR
MPLS-TP P MPLS-TP Provider LSR
PW Pseudowire
Adaptation The mapping of client information into a format suitable
for transport by the server layer
Native The traffic belonging to the client of the MPLS-TP network
Service
T-PE PW Terminating Provider Edge
S-PE PW Switching provider Edge
1.3.1. Transport Network
A Transport Network provides transparent transmission of client user
plane traffic between attached client devices by establishing and
maintaining point-to-point or point-to-multipoint connections between
such devices. The architecture of networks supporting point to
multipoint connections is out of scope of this document. A Transport
Network is independent of any higher-layer network that may exist
between clients, except to the extent required to supply this
transmission service. In addition to client traffic, a Transport
Network may carry traffic to facilitate its own operation, such as
that required to support connection control, network management, and
Operations, Administration and Maintenance (OAM) functions.
Bocci, et al. Expires July 26, 2010 [Page 6]
Internet-Draft MPLS Transport Profile Framework January 2010
See also the definition of Packet Transport Service in Section 3.1.
1.3.2. MPLS Transport Profile
The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions
that meet the requirements in [RFC5654]. Note that MPLS is defined
to include any present and future MPLS capability specified by the
IETF, including those capabilities specifically added to support
transport network requirements [RFC5654].
1.3.3. MPLS-TP Section
An MPLS-TP Section is defined in Section 1.2.2 of [RFC5654].
1.3.4. MPLS-TP Label Switched Path
An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a
subset of the capabilities of an MPLS LSP in order to meet the
requirements of an MPLS transport network as set out in [RFC5654].
The characteristics of an MPLS-TP LSP are primarily that it:
1. Uses a subset of the MPLS OAM tools defined as described in
[I-D.ietf-mpls-tp-oam-framework].
2. Supports 1+1, 1:1, and 1:N protection functions.
3. Is traffic engineered.
4. May be established and maintained via the management plane, or
using GMPLS protocols when a control plane is used.
5. Is either point-to-point or point-to-multipoint. Multipoint to
point and multipoint to multipoint LSPs are not permitted.
Note that an MPLS LSP is defined to include any present and future
MPLS capability, including those specifically added to support the
transport network requirements.
1.3.5. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER)
Editor's Note: These terms are here for clarity - but this is not the
authoritative definition - (need to find a definition)
An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider
Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP,
as defined below. The terms MPLS-TP PE router and MPLS-TP P router
describe logical functions; a specific node may undertake only one of
these roles on a given LSP.
Bocci, et al. Expires July 26, 2010 [Page 7]
Internet-Draft MPLS Transport Profile Framework January 2010
Note that the use of the term "router" in this context is historic
and neither requires nor precludes the ability to perform IP
forwarding.
1.3.5.1. MPLS-TP Provider Edge (PE) Router
An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts
client traffic and encapsulates it to be transported over an MPLS-TP
LSP. Encapsulation may be as simple as pushing a label, or it may
require the use of a pseudowire. An MPLS-TP PE exists at the
interface between a pair of layer networks. For an MS-PW, an MPLS-TP
PE may be either an S-PE or a T-PE, as defined in [RFC5659].
A layer network is defined in [G.805].
1.3.5.2. MPLS-TP Provider (P) Router
An MPLS-TP Provider router is an MPLS-TP LSR that does not provide
MPLS-TP PE functionality for a given LSP. An MPLS-TP P router
switches LSPs which carry client traffic, but does not adapt client
traffic and encapsulate it to be carried over an MPLS-TP LSP.
1.3.6. Customer Edge (CE)
A Customer Edge (CE) is the client function sourcing or sinking
native service traffic to or from the MPLS-TP network. CEs on either
side of the MPLS-TP network are peers and view the MPLS-TP network as
a single point-to-point or point-to-multipoint link.
1.3.7. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in
[RFC5654].
1.4. Applicability
MPLS-TP can be used to construct packet transport networks and is
therefore applicable in any packet transport network context. It is
also applicable to subsets of a packet network where the transport
network operational model is deemed attractive. The following are
examples of MPLS-TP applicability models:
1. MPLS-TP provided by a network that only supports MPLS-TP LSPs and
PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or
LSRs), acting as a server for other layer 1, layer 2 and layer 3
networks (Figure 1).
Bocci, et al. Expires July 26, 2010 [Page 8]
Internet-Draft MPLS Transport Profile Framework January 2010
2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs
and PWs (i.e. both LSPs and PWs that conform to the transport
profile and those that do not, exist between the PEs), acting as
a server for other layer 1, layer 2 and layer 3 networks
(Figure 2).
3. MPLS-TP as a server layer for client layer traffic of IP or MPLS
networks which do not use functions of the MPLS transport
profile. For MPLS traffic, the MPLS-TP server layer network uses
PW switching or LSP stitching at the PE that terminates the
MPLS-TP server layer (Figure 3). - See notes in word document -
ref = rfc5150
These models are not mutually exclusive.
MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as
a server for other layer 1, layer 2 and layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->|
Only
MPLS-TP
+---+ LSP +---+
+---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+
+---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ]
[-TP LSP ]
b) [ IP ] [ IP ] [ IP ]
[ Demux ]
[-TP LSP ]
Figure 1: MPLS-TP Server Layer Example
Bocci, et al. Expires July 26, 2010 [Page 9]
Internet-Draft MPLS Transport Profile Framework January 2010
MPLS-TP LSP, provided by a network that also supports non-MPLS-TP
functions, acting as a server for other layer 1, layer 2 and
layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->|
MPLS-TP
+---+ LSP +---+
+---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+
+---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ]
[-TP LSP ]
b) [ IP ] [ IP ] [ IP ]
[ Demux ]
[-TP LSP ]
Figure 2: MPLS-TP in MPLS Network Example
Bocci, et al. Expires July 26, 2010 [Page 10]
Internet-Draft MPLS Transport Profile Framework January 2010
MPLS-TP as a server layer for client layer traffic of IP or MPLS
networks which do not use functions of the MPLS transport
profile.
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
Only
+---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+
|CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2|
+---+ +----+ +----+ +----+ +----+ +---+
(PW switching) (PW switching)
(a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ]
[PW Seg't] [PW Seg't] [PW Seg't]
[ LSP ] [-TP LSP ] [ LSP ]
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
Only
+---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+
|CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2|
+---+ +----+ +----+ +----+ +----+ +---+
(LSP stitching) (LSP stitching)
(b) [ IP ] [ IP ] [ IP ] [ IP ] [ IP ]
[ LSP ] [-TP LSP ] [ LSP ]
Figure 3: MPLS-TP Transporting Client Service Traffic
2. MPLS Transport Profile Requirements
The requirements for MPLS-TP are specified in [RFC5654],
[I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req].
This section provides a brief reminder to guide the reader and is
therefore not normative. It is not intended as a substitute for
these documents.
MPLS-TP must not modify the MPLS forwarding architecture and must be
based on existing pseudowire and LSP constructs.
Point to point LSPs may be unidirectional or bi-directional, and it
must be possible to construct congruent Bi-directional LSPs.
MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
must be possible to detect if a merged LSP has been created.
Bocci, et al. Expires July 26, 2010 [Page 11]
Internet-Draft MPLS Transport Profile Framework January 2010
It must be possible to forward packets solely based on switching the
MPLS or PW label. It must also be possible to establish and maintain
LSPs and/or pseudowires both in the absence or presence of a dynamic
control plane. When static provisioning is used, there must be no
dependency on dynamic routing or signaling.
OAM, protection and forwarding of data packets must be able to
operate without IP forwarding support.
It must be possible to monitor LSPs and pseudowires through the use
of OAM in the absence of control plane or routing functions. In this
case information gained from the OAM functions is used to initiate
path recovery actions at either the PW or LSP layers.
3. MPLS Transport Profile Overview
3.1. Packet Transport Services
One objective of MPLS-TP is to enable MPLS networks to provide packet
transport services with a similar degree of predictability to that
found in existing transport networks. Such packet transport services
inherit a number of characteristics, defined in [RFC5654]:
o In an environment where an MPLS-TP layer network is supporting a
client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer
network must be possible without any dependencies on either the
server or client layer network.
o The service provided by the MPLS-TP network to the client is
guaranteed not to fall below the agreed level regardless of other
client activity.
o The control and management planes of any client network layer that
uses the service is isolated from the control and management
planes of the MPLS-TP layer network, where the client network
layer is considered to be the native service of the MPLS-TP
network.
o Where a client network makes use of an MPLS-TP server that
provides a packet transport service, the level of co-ordination
required between the client and server layer networks is minimal
(preferably no co-ordination will be required).
o The complete set of packets generated by a client MPLS(-TP) layer
network using the packet transport service, which may contain
packets that are not MPLS packets (e.g. IP or CNLS packets used
by the control/management plane of the client MPLS(-TP) layer
Bocci, et al. Expires July 26, 2010 [Page 12]
Internet-Draft MPLS Transport Profile Framework January 2010
network), are transported by the MPLS-TP server layer network.
o The packet transport service enables the MPLS-TP layer network
addressing and other information (e.g. topology) to be hidden from
any client layer networks using that service, and vice-versa.
These characteristics imply that a packet transport service does not
support a connectionless packet-switched forwarding mode. However,
this does not preclude it carrying client traffic associated with a
connectionless service.
Such packet transport services are very similar to Layer 2 Virtual
Private Networks as defined by the IETF.
3.2. Scope of the MPLS Transport Profile
Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are
primarily intended for packet transport applications. MPLS-TP is a
strict subset of MPLS, and comprises only those functions that are
necessary to meet the requirements of [RFC5654]. This includes MPLS
functions that were defined prior to [RFC5654] but that meet the
requirements of [RFC5654], together with additional functions defined
to meet those requirements. Some MPLS functions defined before
[RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a
way that it creates multipoint-to-point LSPs, and IP forwarding in
the data plane are explicitly excluded from MPLS-TP by that
requirements specification.
Note that MPLS as a whole will continue to evolve to include
additional functions that do not conform to the MPLS Transport
Profile or its requirements, and thus fall outside the scope of
MPLS-TP.
|<============================== MPLS ==============================>|
|<============= Pre-RFC5654 MPLS ================>|
{ ECMP }
{ LDP/non-TE LSPs }
{ IP fwd }
|<================ MPLS-TP ====================>|
{ Additional }
{ Transport }
{ Functions }
Bocci, et al. Expires July 26, 2010 [Page 13]
Internet-Draft MPLS Transport Profile Framework January 2010
Figure 4: Scope of MPLS-TP
3.3. Architecture
MPLS-TP comprises the following architectural elements:
o Sections, LSPs and PWs that provide a packet transport service for
a client network.
o Proactive and on-demand Operations, Administration and Maintenance
(OAM) functions to monitor and diagnose the MPLS-TP network, such
as connectivity check, connectivity verification, performance
monitoring and fault localisation.
o Optional control planes for LSPs and PWs, as well as support for
static provisioning and configuration.
o Optional path protection mechanisms to ensure that the packet
transport service survives anticipated failures and degradations
of the MPLS-TP network.
o Network management functions.
The MPLS-TP architecture for LSPs and PWs includes the following two
sets of functions:
o MPLS-TP client adaptation
o MPLS-TP forwarding
The adaptation functions interface the native service to MPLS-TP.
This includes the case where the native service is an MPLS-TP LSP.
The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client traffic over an MPLS-TP server
layer network, for example PW and LSP labels.
3.3.1. MPLS-TP Client Adaptation Functions
The MPLS-TP native service adaptation functions interface the client
service to MPLS-TP. For pseudowires, these adaptation functions are
the payload encapsulation described in Section 4.4 of [RFC3985] and
Section 6 of [RFC5659]. For network layer client services, the
adaptation function uses the MPLS encapsulation format as defined in
[RFC3032].
The purpose of this encapsulation is to abstract the client service
data plane from the MPLS-TP data plane, thus contributing to the
Bocci, et al. Expires July 26, 2010 [Page 14]
Internet-Draft MPLS Transport Profile Framework January 2010
independent operation of the MPLS-TP network.
MPLS-TP is itself a client of an underlying server layer. MPLS-TP is
thus also bounded by a set of adaptation functions to this server
layer network, which may itself be MPLS-TP. These adaptation
functions provide encapsulation of the MPLS-TP frames and for the
transparent transport of those frames over the server layer network.
The MPLS-TP client inherits its Quality of Service (QoS) from the
MPLS-TP network, which in turn inherits its QoS from the server
layer. The server layer must therefore provide the necessary QoS to
ensure that the MPLS-TP client QoS commitments can be satisfied.
3.3.2. MPLS-TP Forwarding Functions
The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client over an MPLS-TP server layer
network, for example PW and LSP labels.
MPLS-TP LSPs use the MPLS label switching operations and TTL
processing procedures defined in [RFC3031] and [RFC3032]. These
operations are highly optimised for performance and are not modified
by the MPLS-TP profile.
In addition, MPLS-TP PWs use the SS-PW and MS-PW forwarding
operations defined in [RFC3985] and [RFC5659]. The PW label is
processed by a PW forwarder and is always at the bottom of the label
stack for a given MPLS-TP layer network.
Per-platform label space is used for PWs. Either per-platform, per-
interface or other context-specific label space [RFC5331] may be used
for LSPs.
MPLS-TP forwarding is based on the label that identifies the
transport path (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
forwarder. The only event that interrupts a swap operation is TTL
expiry. This is a fundamental architectural construct of MPLS to be
taken into account when designing protocol extensions that require
packets (e.g. OAM packets) to be sent to an intermediate LSR.
Further processing to determine the context of a packet occurs when a
swap operation is interrupted in this manner, or a pop operation
exposes a specific reserved label at the top of the stack. Otherwise
the packet is forwarded according to the procedures in [RFC3032].
Point-to-point MPLS-TP LSPs can be either unidirectional or
Bocci, et al. Expires July 26, 2010 [Page 15]
Internet-Draft MPLS Transport Profile Framework January 2010
bidirectional.
It must be possible to configure an MPLS-TP LSP such that the forward
and backward directions of a bidirectional MPLS-TP LSP are co-routed,
i.e. follow the same path. The pairing relationship between the
forward and the backward directions must be known at each LSR or LER
on a bidirectional LSP.
In normal conditions, all the packets sent over a PW or an LSP follow
the same path through the network and those that belong to a common
ordered aggregate are delivered in order. For example per-packet
equal cost multi-path (ECMP) load balancing is not applicable to
MPLS-TP LSPs.
Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.
MPLS-TP supports Quality of Service capabilities via the MPLS
Differentiated Services (DiffServ) architecture [RFC3270]. Both
E-LSP and L-LSP MPLS DiffServ modes are supported. The Traffic Class
field (formerly the EXP field) of an MPLS label follows the
definition and processing rules of [RFC5462] and [RFC3270]. Note
that packet reordering between flows belonging to different traffic
classes may occur if more than one traffic class is supported on a
single LSP.
Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing
models described in [RFC3270] and [RFC3443] are supported in MPLS-TP.
3.4. MPLS-TP Native Services
This document describes the architecture for two types of native
service adaptation:
o A PW: PW Demultiplexer and PW encapsulation
o An MPLS Label
A PW provides any emulated service that the IETF has defined to be
provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A
registry of PW types is maintained by IANA. When the client
adaptation is via a PW, the mechanisms described in Section 3.4.2 are
used.
An MPLS LSP Label can also be used as the adaptation, in which case
any client supported by [RFC3031] is allowed, for example a MPLS LSP,
PW, or IP. When the client adaptation is via an MPLS label, the
mechanisms described in Section 3.4.3 are used.
Bocci, et al. Expires July 26, 2010 [Page 16]
Internet-Draft MPLS Transport Profile Framework January 2010
3.4.1. MPLS-TP Client/Server Relationship
The MPLS-TP client server relationship is defined by the MPLS-TP
network boundary and the label context. It is not explicitly
indicated in the packet. In terms of the MPLS label stack, when the
client traffic type of the MPLS-TP network is an MPLS LSP or a PW,
then the S bit of all the labels in the MPLS-TP label stack are zero,
otherwise the bottom label of the MPLS-TP label stack has the S bit
set to one ( i.e. there can only one S bit set in a label stack).
The data plane behaviour of MPLS-TP is the same as the best current
practise for MPLS. This includes the setting of the S-Bit. In each
case, the S-bit is set to indicate the bottom (i.e. inner-most) label
in the label stack that is contiguous between the MPLS-TP server and
the client layer. Note that this best current practise differs
slightly from [RFC3032] which uses the S-bit to identify when MPLS
label processing stops and network layer processing starts.
The relationship of MPLS-TP to its clients is illustrated in
Figure 5.
Bocci, et al. Expires July 26, 2010 [Page 17]
Internet-Draft MPLS Transport Profile Framework January 2010
PW-Based MPLS Labelled
Services Services
|-----------------------------| |----------------------------|
Emulated PW over LSP IP over LSP IP
Service
+------------+
| PW Payload |
+------------+ +------------+ (CLIENTS)
|PW Lbl(S=1) | | IP |
+------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)|
+------------+ (MPLS-TP)
~~~~~~~~~~~ = Client - MPLS-TP layer boundary
Note that in the PW over LSP case the client may omit its LSP Label if
penultimate hop popping has been agreed with its peer
Figure 5: MPLS-TP - Client Relationship
The data plane behaviour of MPLS-TP is the same as the best current
practise for MPLS. This includes the setting of the S-Bit. In each
case, the S-bit is set to indicate the bottom (i.e. inner-most) label
in the label stack that is contiguous between the MPLS-TP server and
the client layer.
Note that the label stacks shown above are divided between those
inside the MPLS-TP Network and those within the client network when
the client network is MPLS(-TP). They illustrate the smallest number
of labels possible. These label stacks could also include more
labels.
3.4.2. Pseudowire Adaptation
The architecture for an MPLS-TP network that provides PW emulated
services is based on the MPLS [RFC3031] and pseudowire [RFC3985]
architectures. If multi-segment pseudowires are used to provide a
packet transport service, motivated by, for example, the requirements
Bocci, et al. Expires July 26, 2010 [Page 18]
Internet-Draft MPLS Transport Profile Framework January 2010
specified in [RFC5254], then the MS-PW architecture [RFC5659] also
applies.
Figure 6 shows the architecture for an MPLS-TP network using single-
segment PWs.
|<--------------- Emulated Service ----------------->|
| |
| |<-------- Pseudowire -------->| |
| | encapsulated, packet | |
| | transport service | |
| | | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ +-----+ +----+ | ^
| | Provider Edge 1 ^ Provider Edge 2 | |
| | | | |
Customer | P Router | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
Figure 6: MPLS-TP Architecture (Single Segment PW)
Figure 7 shows the architecture for an MPLS-TP network when multi-
segment pseudowires are used. Note that as in the SS-PW case,
P-routers may also exist.
Bocci, et al. Expires July 26, 2010 [Page 19]
Internet-Draft MPLS Transport Profile Framework January 2010
|<----------- Pseudowire encapsulated ------------->|
| packet transport service |
| |
| |
| |
AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |---|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|---| |
|CE1| | | | | X | | | | | | |CE2|
| |---|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|---| |
+---+ | | |===============/ \=====| |==========| | | +---+
^ +----+ ^ +-----+ +----+ ^ +----+ ^
| | ^ | |
| TE LSP | TE LSP |
| P-router |
| |
|<-------------------- Emulated Service ------------------->|
PW1-segment1 and PW1-segment2 are segments of the same MS-PW,
while PW2-segment1 and PW2-segment2 are segments of another MS-PW
Figure 7: MPLS-TP Architecture (Multi-Segment PW)
The corresponding MPLS-TP protocol stacks including PWs are shown in
Figure 8. In this figure protocol the Transport Service Layer
[RFC5654] is identified by the PW demultiplexer (Demux) label and the
Transport Path Layer [RFC5654] is identified by the LSP Demux Label.
Bocci, et al. Expires July 26, 2010 [Page 20]
Internet-Draft MPLS Transport Profile Framework January 2010
+-------------------+ /===================\ /===================\
| Client Layer | H OAM PDU H H OAM PDU H
/===================\ H-------------------H H-------------------H
H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack we are
considering in this document.
Figure 8: MPLS-TP Layer Network using Pseudowires
PWs and their underlying labels may be configured or signaled. See
Section 3.9 for additional details related to configured service
types. See Section 3.8 for additional details related to signaled
service types.
3.4.2.1. Pseudowire Bases Services
When providing a Virtual Private Wire Service (VPWS) , Virtual
Private Local Area Network Service (VPLS), Virtual Private Multicast
Service (VPMS) or Internet Protocol Local Area Network Service (IPLS)
pseudowires must be used to carry the client service. VPWS, VLPS,
and IPLS are described in [RFC4664]. VPMS is described in
[I-D.ietf-l2vpn-vpms-frmwk-requirements]
3.4.3. Network Layer Adaptation
MPLS-TP LSPs can be used to transport network layer clients. The
network layer protocols supported by [RFC3031] and supported in
[RFC3032] can be transported between service interfaces. Examples
are shown in Figure 5 above. Support for network layer clients
follows the MPLS architecture for support of network layer protocols
as defined in and supported in [RFC3032][RFC3031] and supported in
[RFC3032].
With network layer adaptation, the MPLS-TP domain provides either a
uni-directional or bidirectional point-to-point connection between
two PEs in order to deliver a packet transport service to attached
customer edge (CE) nodes. For example, a CE may be an IP, MPLS or
Bocci, et al. Expires July 26, 2010 [Page 21]
Internet-Draft MPLS Transport Profile Framework January 2010
MPLS-TP node. As shown in Figure 9, there is an attachment circuit
between the CE node on the left and its corresponding provider edge
(PE) node which provides the service interface, a bidirectional LSP
across the MPLS-TP network to the corresponding PE node on the right,
and an attachment circuit between that PE node and the corresponding
CE node for this service.
The attachment circuits may be heterogeneous (e.g., any combination
of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads
arrive at the service interface encapsulated in the Layer1/Layer2
encoding defined for that access link type. It should be noted that
the set of network layer protocols includes MPLS and hence MPLS
encoded packets with an MPLS label stack (the client MPLS stack), may
appear at the service interface.
|<------------- Client Network Layer-------------->|
| |
| |<---- Pkt Xport Service --->|
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +---+ +----+ AC V
+-----+ | |PE1 | | | |PE2 | | +-----+
| | |LSP | | | | | | | | |
| CE1 |----------| |========X=========| |----------| CE2 |
| | ^ |IP | | ^ | | ^ | | | ^ | |
+-----+ | | | | | | | | | | | | +-----+
^ | +----+ | +---+ | +----+ | | ^
| | Provider | ^ | Provider | |
| | Edge | | | Edge | |
Customer | 1 | P-router | 2 | Customer
Edge 1 | TE TE | Edge 2
| LSP LSP |
| |
Native service Native service
Figure 9: MPLS-TP Architecture for Network Layer Clients
At the ingress service interface the client packets are received .
The PE pushes one or more labels onto the client packets which are
then label switched over the transport network. Correspondingly the
egress PE pops any labels added by the MPLS-TP networks and transmits
the packet for delivery to the attached CE via the egress service
interface.
Bocci, et al. Expires July 26, 2010 [Page 22]
Internet-Draft MPLS Transport Profile Framework January 2010
/===================\
H OAM PDU H
+-------------------+ H-------------------H /===================\
| Client Layer | H GACh H H OAM PDU H
/===================\ H-------------------H H-------------------H
H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic Service LSP OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack we are
considering in this document.
Figure 10: Domain of MPLS-TP Layer Network for IP and LSP Clients
In this figure the Transport Service Layer [RFC5654] is identified by
the Service LSP (SvcLSP) demultiplexer (Demux) label and the
Transport Path Layer [RFC5654] is identified by the LSP Demux Label.
Note that the functions of the Encapsulation label and the Service
Label shown above as SvcLSP Demux may be represented by a single
label stack entry. Additionally, the S-bit will always be zero when
the client layer is MPLS labelled.
Within the MPLS-TP transport network, the network layer protocols are
carried over the MPLS-TP network using a logically separate MPLS
label stack (the server stack). The server stack is entirely under
the control of the nodes within the MPLS-TP transport network and it
is not visible outside that network. Figure 10 shows how a client
network protocol stack (which may be an MPLS label stack and payload)
is carried over a network layer client service over an MPLS-TP
transport network.
A label per network layer protocol payload type that is to be
transported is required. When multiple protocol payload types are to
be carried over a single service a unique label stack entry must be
present for each payload type. Such labels are referred to as
"Encapsulation Labels", one of which is shown in A label per network
layer protocol payload type that is to be transported is required.
Such labels are referred to as "Encapsulation Labels", one of which
is shown in Figure 10. Encapsulation Label is either configured or
Bocci, et al. Expires July 26, 2010 [Page 23]
Internet-Draft MPLS Transport Profile Framework January 2010
signaled. Encapsulation Labels are either configured or signaled.
Both an Encapsulation Label and a Service Label should be present in
the label stack when a particular packet transport service is
supporting more than one network layer protocol payload type. For
example, if both IP and MPLS are to be carried, as shown in Figure 9,
then two Encapsulation Labels are mapped on to a common Service
Label.
The Encapsulation Label may be omitted when the transport service is
supporting only one network layer protocol payload type. For
example, if only MPLS labeled packets are carried over a service,
then the Service Label (stack entry) provides both the payload type
indication and service identification.
Service labels are typically carried over an MPLS-TP LSP edge-to-edge
(or transport path layer). An MPLS-TP edge-to-edge LSP is
represented as an LSP Demux label as shown in Figure 10. An edge-to-
edge LSP is commonly used when more than one service exists between
two PEs. The edge-to-edge LSP may be omitted when only one service
exists between two PEs. For example, if only one service is carried
between two PEs then a single Service Label could be used to provide
both the service indication and the MPLS-TP edge-to-edge LSP.
Alternatively, if multiple services exist between a pair of PEs then
a per-client Service Label would be mapped on to a common MPLS-TP
edge-to-edge LSP.
As noted above, the layer 2 and layer 1 protocols used to carry the
network layer protocol over the attachment circuits are not
transported across the MPLS-TP network. This enables the use of
different layer 2 and layer 1 protocols on the two attachment
circuits.
At each service interface, Layer 2 addressing must be used to ensure
the proper delivery of a network layer packet to the adjacent node.
This is typically only an issue for LAN media technologies (e.g.,
Ethernet) which have Media Access Control (MAC) addresses. In cases
where a MAC address is needed, the sending node must set the
destination MAC address to an address that ensures delivery to the
adjacent node. That is the CE sets the destination MAC address to an
address that ensures delivery to the PE, and the PE sets the
destination MAC address to an address that ensures delivery to the
CE. The specific address used is technology type specific and is not
covered in this document. In some technologies the MAC address will
need to be configured (Examples for the Ethernet case include a
configured unicast MAC address for the adjacent node, or even using
the broadcast MAC address when the CE-PE service interface is
dedicated. The configured address is then used as the MAC
Bocci, et al. Expires July 26, 2010 [Page 24]
Internet-Draft MPLS Transport Profile Framework January 2010
destination address for all packets sent over the service interface.)
Note that when two CEs, which peer with each other, operate over a
network layer transport service run a routing protocol such as IS-IS
or OSPF some care should be taken to configure the routing protocols
to use point- to-point adjacencies .The specifics of such
configuration is outside the scope of this document. See [RFC5309]
for additional details.
The CE to CE service types and corresponding labels may be configured
or signaled . See Section 3.9 for additional details related to
configured service types. See Section 3.8 for additional details
related to signaled service types.
3.5. Identifiers
Identifiers are used to uniquely distinguish entities in an MPLS-TP
network. These include operators, nodes, LSPs, pseudowires, and
their associated maintenance entities.
[I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are
compatible with existing MPLS control plane identifiers, as well as a
set of identifiers that may be used when no IP control plane is
available.
3.6. Generic Associated Channel (G-ACh)
For correct operation of the OAM it is important that the OAM packets
fate-share with the data packets. In addition in MPLS-TP it is
necessary to discriminate between user data payloads and other types
of payload. For example, a packet may be associated with a Signaling
Communication Channel (SCC), or a channel used for Automatic
Protection Switching (APS) data. This is achieved by carrying such
packets on a generic control channel associated to the LSP, PW or
section.
MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
or other packet types in-band over LSPs or PWs. The G-ACh is defined
in [RFC5586] and is similar to the Pseudowire Associated Channel
[RFC4385], which is used to carry OAM packets over pseudowires. The
G-ACh is indicated by a generic associated channel header (ACH),
similar to the Pseudowire VCCV control word; this header is present
for all Sections, LSPs and PWs making use of FCAPS functions
supported by the G-ACh.
For pseudowires, the G-ACh uses the first four bits of the pseudowire
control word to provide the initial discrimination between data
Bocci, et al. Expires July 26, 2010 [Page 25]
Internet-Draft MPLS Transport Profile Framework January 2010
packets and packets belonging to the associated channel, as described
in [RFC4385]. 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.
When the OAM or other control message is carried over an LSP, rather
than over a pseudowire, it is necessary to provide an indication in
the packet that the payload is something other than a user data
packet. This is achieved by including a reserved label with a value
of 13 in the label stack. This reserved label is referred to as the
'Generic Alert Label (GAL)', and is defined in [RFC5586]. 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 LSP, and the ACH is
a discriminator for the type of traffic carried on the G-ACh. Note
however that MPLS-TP forwarding follows the normal MPLS model, and
that 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. Any MPLS-TP
component that intentionally performs this inspection must assume
that it is asynchronous with respect to the forwarding of other
packets. All operations on the label stack are in accordance with
[RFC3031] and [RFC3032].
In MPLS-TP, the 'G-ACh Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1).
The G-ACh must only be used for channels that are an adjunct to the
data service. Examples of these are OAM, APS, MCC and SCC, but the
use is not restricted to these services. The G-ACh must not be used
to carry additional data for use in the forwarding path, i.e. it must
not be used as an alternative to a PW control word, or to define a PW
type.
At the server layer, bandwidth and QoS commitments apply to the gross
traffic on the LSP, PW or section. Since the G-ACh traffic is
indistinguishable from the user data traffic, protocols using the
G-ACh must take into consideration the impact they have on the user
data that they are sharing resources with. Conversely, capacity must
be made available for important G-ACh uses such as protection and
OAM. In addition, protocols using the G-ACh must conform to the
security and congestion considerations described in [RFC5586].
Figure 11 shows the reference model depicting how the control channel
is associated with the pseudowire protocol stack. This is based on
Bocci, et al. Expires July 26, 2010 [Page 26]
Internet-Draft MPLS Transport Profile Framework January 2010
the reference model for VCCV shown in Figure 2 of [RFC5085].
+-------------+ +-------------+
| Payload | < Service / FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < CW / ACH for PWs > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 11: PWE3 Protocol Stack Reference Model including the G-ACh
PW associated channel messages are encapsulated using the PWE3
encapsulation, so that they are handled and processed in the same
manner (or in some cases, an analogous manner) as the PW PDUs for
which they provide a control channel.
Figure 12 shows the reference model depicting how the control channel
is associated with the LSP protocol stack.
Bocci, et al. Expires July 26, 2010 [Page 27]
Internet-Draft MPLS Transport Profile Framework January 2010
+-------------+ +-------------+
| Payload | < Service > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 12: MPLS Protocol Stack Reference Model including the LSP
Associated Control Channel
3.7. Operations, Administration and Maintenance (OAM)
MPLS-TP must be able to operate in environments where IP is not used
in the forwarding plane. Therefore, the default mechanism for OAM
demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated
Channel (Section 3.6). Forwarding based on IP addresses for user or
OAM packets is not required for MPLS-TP.
[RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined
alert mechanisms that enable an 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 for IPv4 and that same range
embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the
OAM packets are encapsulated in an IP header, these mechanisms are
the default mechanisms for MPLS networks in general for identifying
MPLS OAM packets. MPLS-TP must be able to operate in an environments
where IP forwarding is not supported, and thus the GACH/GAL is the
default mechanism to demultiplex OAM packets in MPLS-TP.
MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those
provided in SONET/SDH.
Bocci, et al. Expires July 26, 2010 [Page 28]
Internet-Draft MPLS Transport Profile Framework January 2010
MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the
same transport path (i.e. section, LSP or PW). These mechanisms are
described in [RFC5586].
MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of
OAM capabilities is available to perform fault management (e.g. fault
detection and localisation) and performance monitoring (e.g. packet
delay and loss measurement) of the LSP, PW or section. The framework
for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].
MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel
mechanism [RFC5586]. This uses a combination of an Associated
Channel Header (ACH) and a Generic Alert Label (GAL) to create a
control channel associated to an LSP, Section or PW.
3.7.1. OAM Architecture
OAM and monitoring in MPLS-TP is based on the concept of maintenance
entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A
Maintenance Entity can be viewed as the association of two
Maintenance End Points (MEPs) (see example in Figure 13 ). Another
OAM construct is referred to as Maintenance Entity Group (MEG), which
is a collection of one or more MEs that belongs to the same transport
path and that are maintained and monitored as a group. The MEPs that
form an ME should be configured and managed to limit the OAM
responsibilities of an OAM flow within the domain of a transport path
or segment, in the specific layer network that is being monitored and
managed.
Each OAM flow is associated with a single ME. Each MEP within an ME
resides at the boundaries of that ME. An ME may also include a set
of zero or more Maintenance Intermediate Points (MIPs), which reside
within the Maintenance Entity. Maintenance End Points (MEPs) are
capable of sourcing and sinking OAM flows, while Maintenance
Intermediate Points (MIPs) can only sink or respond to OAM flows from
within a MEG, or originate notifications as a result of specific
network conditions.
Bocci, et al. Expires July 26, 2010 [Page 29]
Internet-Draft MPLS Transport Profile Framework January 2010
========================== End to End LSP OAM ==========================
..... ..... ..... .....
-----|MIP|---------------------|MIP|---------|MIP|------------|MIP|-----
''''' ''''' ''''' '''''
|<-------- Carrier 1 --------->| |<--- Carrier 2 ----->|
---- --- --- ---- ---- --- ----
NNI | | | | | | | | NNI | | | | | | NNI
-----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |----
| | | | | | | | | | | | | |
---- --- --- ---- ---- --- ----
==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM ===
(Carrier 1) LSP OAM (Carrier 2)
(inter-carrier)
..... ..... ..... .......... .......... ..... .....
|MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
''''' ''''' ''''' '''''''''' '''''''''' ''''' '''''
<------------ ME ----------><--- ME ----><------- ME -------->
Note: MEPs for End-to-end LSP OAM exist outside of the scope
of this figure.
Figure 13: Example of MPLS-TP OAM showing end-to-end and segment OAM
Figure 14 illustrates how the concept of Maintenance Entities can be
mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
PWs.
Bocci, et al. Expires July 26, 2010 [Page 30]
Internet-Draft MPLS Transport Profile Framework January 2010
Native |<-------------------- PW15 --------------------->| Native
Layer | | Layer
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | |
|CE1|------|........PW1.....X..|...PW3...|.X......PW5........|-----|CE2|
| | | |=========| |=========| |=========| | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+
|<- Subnetwork 123->| |<- Subnetwork XYZ->|
.------------------- PW15 PME -------------------.
.---- PW1 PTCME ----. .---- PW5 PTCME ---.
.---------. .---------.
PSN13 LME PSNXZ LME
.--. .--. .--------. .--. .--.
Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
.---. ME . MEP ==== LSP .... PW
SME: Section Maintenance Entity
LME: LSP Maintenance Entity
PME: PW Maintenance Entity
Figure 14: MPLS-TP OAM architecture showing PWs, LSPs and Sections
The following MPLS-TP MEs are specified in
[I-D.ietf-mpls-tp-oam-framework]:
o A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs).
o A LSP Maintenance Entity (LME), allowing monitoring and management
of an end-to-end LSP (between LERs).
o A PW Maintenance Entity (PME), allowing monitoring and management
of an end-to-end SS/MS-PWs (between T-PEs).
Bocci, et al. Expires July 26, 2010 [Page 31]
Internet-Draft MPLS Transport Profile Framework January 2010
o An LSP Tandem Connection Maintenance Entity (LTCME).
A G-ACH packet may be directed to an individual MIP along the path of
an LSP or MS-PW by setting the appropriate TTL in the label for the
G-ACH packet, as per the traceroute mode of LSP Ping [RFC4379] and
the vccv-trace mode of[I-D.ietf-pwe3-segmented-pw]. Note that this
works when the location of MIPs along the LSP or PW path is known by
the MEP. There may be circumstances where this is not the case, e.g.
following restoration using a facility bypass LSP. In these cases,
tools to trace the path of the LSP may be used to determine the
appropriate setting for the TTL to reach a specific MIP.
Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
layer processing is performed on a packet. The architecture mandates
that this must occur at least once.
MEPs may only act as a sink of OAM packets when the label associated
with the LSP or PW for that ME is popped. MIPs can only be placed
where an exception to the normal forwarding operation occurs. A MEP
may act as a source of OAM packets wherever a label is pushed or
swapped. For example, on an MS-PW, a MEP may source OAM within an
S-PE or a T-PE, but a MIP may only be associated with a S-PE and a
sink MEP can only be associated with a T-PE.
3.7.2. OAM Functions
The MPLS-TP OAM architecture supports a wide range of OAM functions,
including the following:
o Continuity Check
o Connectivity Verification
o Performance Monitoring (e.g. packet loss and delay measurement)
o Alarm Suppression
o Remote Integrity
These functions are applicable to any layer defined within MPLS-TP,
i.e. to MPLS-TP Sections, LSPs and PWs.
The MPLS-TP OAM tool-set must be able to operate without relying on a
dynamic control plane or IP functionality in the datapath. In the
case of an MPLS-TP deployment in a network in which IP functionality
is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD
and VCCV, may be used.
Bocci, et al. Expires July 26, 2010 [Page 32]
Internet-Draft MPLS Transport Profile Framework January 2010
One use of OAM mechanisms is to detect link failures, node failures
and performance outside the required specification which then may be
used to trigger recovery actions, according to the requirements of
the service.
3.8. Control Plane
Editors note: This section will be updated based on text supplied by
the control plane framework draft editors.
A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements
specified in [RFC5654] can be met, the MPLS Transport Profile uses
existing standard control plane protocols for LSPs and PWs.
Note that a dynamic control plane is not required in an MPLS-TP
network. See Section 3.9 for further details on statically
configured and provisioned MPLS-TP services.
Figure 15 illustrates the relationship between the MPLS-TP control
plane, the forwarding plane, the management plane, and OAM for point-
to-point MPLS-TP LSPs or PWs.
Bocci, et al. Expires July 26, 2010 [Page 33]
Internet-Draft MPLS Transport Profile Framework January 2010
+------------------------------------------------------------------+
| |
| Network Management System and/or |
| |
| Control Plane for Point to Point Connections |
| |
+------------------------------------------------------------------+
| | | | | |
.............|.....|... ....|.....|.... ....|.....|............
: +---+ | : : +---+ | : : +---+ | :
: |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
/: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note:
1) NMS may be centralised or distributed. Control plane is
distributed.
2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g. NSP or classification.
3) The control plane may be transported over the server
layer, an LSP or a G-ACh.
Figure 15: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on a combination of the LDP-based
control plane for pseudowires [RFC4447] and the RSVP-TE-based control
plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that
are required for MPLS-TP LSP signaling are based on Generalized MPLS
(GMPLS) ([RFC3945], [RFC3471], [RFC3473]).
The distributed MPLS-TP control plane may provide the following
functions:
o Signaling
o Routing
o Traffic engineering and constraint-based path computation
In a multi-domain environment, the MPLS-TP control plane supports
different types of interfaces at domain boundaries or within the
domains. These include the User-Network Interface (UNI), Internal
Bocci, et al. Expires July 26, 2010 [Page 34]
Internet-Draft MPLS Transport Profile Framework January 2010
Network Node Interface (I-NNI), and External Network Node Interface
(E-NNI). Note that different policies may be defined that control
the information exchanged across these interface types.
The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document
Section 3.7, e.g. for fault detection and localisation in the event
of a failure in order to efficiently restore failed transport paths.
The MPLS-TP control plane supports all MPLS-TP data plane
connectivity patterns that are needed for establishing transport
paths, including protected paths as described in Section 3.10.
Examples of the MPLS-TP data plane connectivity patterns are LSPs
utilising the fast reroute backup methods as defined in [RFC4090] and
ingress-to-egress 1+1 or 1:1 protected LSPs.
The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures
and degradations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data
plane may be achieved.
3.8.1. PW Control Plane
An MPLS-TP network provides many of its transport services using
single-segment or multi-segment pseudowires, in compliance with the
PWE3 architecture ([RFC3985] and [RFC5659]). The setup and
maintenance of single-segment or multi-segment pseudowires uses the
Label Distribution Protocol (LDP) as per [RFC4447] and extensions for
MS-PWs ([I-D.ietf-pwe3-segmented-pw] and
[I-D.ietf-pwe3-dynamic-ms-pw]).
3.8.2. LSP Control Plane
MPLS-TP Provider Edge LSRs aggregate multiple pseudowires and carry
them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
LSPs). Applicable functions from the Generalized MPLS (GMPLS)
([RFC3945]) protocol suite supporting packet-switched capable (PSC)
technologies are used as the control plane for MPLS-TP transport
paths (LSPs).
The LSP control plane includes:
o RSVP-TE for signaling
o OSPF-TE or ISIS-TE for routing
Bocci, et al. Expires July 26, 2010 [Page 35]
Internet-Draft MPLS Transport Profile Framework January 2010
RSVP-TE signaling in support of GMPLS, as defined in [RFC3473], is
used for the setup, modification, and release of MPLS-TP transport
paths and protection paths. It supports unidirectional and
bidirectional point-to-point LSPs as well as unidirectional point-to-
multipoint LSPs. The architecture for MPLS-TP supporting point-to-
multipoint packet transport services is out of scope of this
document.
The route of a transport path is typically calculated in the ingress
node of a domain and the RSVP explicit route object (ERO) is utilised
for the setup of the transport path exactly following the given
route. GMPLS-based MPLS-TP LSPs must be able to inter-operate with
RSVP-TE-based MPLS-TE LSPs, as per [RFC5146]
OSPF and IS-IS for GMPLS ([RFC4203] and [RFC5307]) are used for
carrying link state routing information in an MPLS-TP network.
3.9. Static Operation of LSPs and PWs
An MPLS-TP LSP or PW may be statically configured without the support
of a dynamic control plane. This may be either by direct
configuration of the LSRs, or via a network management system.
Static operation is independent of a specific PW or LSP instance -
for example it should be possible for a PW to be statically
configured, while the LSP supporting it setup by a dynamic control
plane.
Persistent forwarding loops can cause significant additional resource
utilisation, above that budgeted for the transport path. Therefore,
when static configuration mechanisms are used, care must be taken to
ensure that loops do not form.
3.10. Survivability
Editors note: This section will be updated based on text supplied by
the survivability draft editors.
Survivability requirements for MPLS-TP are specified in
[I-D.ietf-mpls-tp-survive-fwk].
A wide variety of resiliency schemes have been developed to meet the
various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels ([RFC4090]), while pseudowire
redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
protection for the PW cannot be fully provided by the PSN layer (i.e.
where the backup PW terminates on a different target PE node than the
working PW). Additionally, GMPLS provides a well known set of
Bocci, et al. Expires July 26, 2010 [Page 36]
Internet-Draft MPLS Transport Profile Framework January 2010
control plane driven protection and restoration mechanisms [RFC4872].
MPLS-TP provides additional protection mechanisms that are optimised
for both linear topologies and ring topologies, and that operate in
the absence of a dynamic control plane. These are specified in
[I-D.ietf-mpls-tp-survive-fwk].
Different protection schemes apply to different deployment topologies
and operational considerations. Such protection schemes may provide
different levels of resiliency, for example:
o Two concurrent traffic paths (1+1).
o one active and one standby path with guaranteed bandwidth on both
paths (1:1).
o one active path and a standby path the resources or which are
shared by one or more other active paths (shared protection).
The applicability of any given scheme to meet specific requirements
is outside the current scope of this document.
The characteristics of MPLS-TP resiliency mechanisms are as follows:
o Optimised for linear, ring or meshed topologies.
o Use OAM mechanisms to detect and localise network faults or
service degenerations.
o Include protection mechanisms to coordinate and trigger protection
switching actions in the absence of a dynamic control plane. This
is known as an Automatic Protection Switching (APS) mechanism.
o MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment
and end-to-end recovery.
o MPLS-TP recovery mechanisms support the coordination of protection
switching at multiple levels to prevent race conditions occurring
between a client and its server layer.
o MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based.
o MPLS-TP supports revertive and non-revertive behaviour.
Bocci, et al. Expires July 26, 2010 [Page 37]
Internet-Draft MPLS Transport Profile Framework January 2010
3.11. Path Segment Tunnels
In order to support the option to monitor, protect and manage a
portion of an LSP, a new architectural element is defined, Path
Segment Tunnel (PST). A Path Segment Tunnel is an LSP defined and
used for the purposes of OAM monitoring, protection or management of
LSP segment or concatenated LSP segments, and based on MPLS
hierarchical nested LSP defined in [RFC3031].
A PST is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. Maintenance messages
can be initiated at the edge of the PST and sent to the peer edge of
the PST or to an intermediate point along the PST setting the TTL
value at the PST level accordingly.
For example in Figure 16, three PST are configured to allow
monitoring, protection and management of the LSP concatenated
segments. One PST is defined between PE1 and PE2, the second between
PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of
these three PST may be monitored, protected, or managed
independently.
========================== End to End LSP =============================
|<--------- Carrier 1 --------->| |<----- Carrier 2 ----->|
---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |---
|============= PST =============|==PST==|========= PST =========|
(Carrier 1) (Carrier 2)
Figure 16: PSTs in inter-carrier network
The end-to-end traffic of the LSP, including data-traffic and control
traffic (OAM, PSC, management and signaling messages) is tunneled
within the PST by means of label stacking as defined in [RFC3031].
The mapping between an LSP and a PST can be 1:1 which is similar to
the IUT-T Tandem Connection element [G.805] which defines a sub layer
corresponding to a segment of a path and allows the monitoring of
that segment. The mapping can also be 1:N to allow scalable
monitoring, protection and management of a set of segments or
concatenated LSP segments traversing the same portion of a network.
Figure 2 shows a PST which is used to aggregate a set of concatenated
LSP segments of the following LSPs: LSP from PEx to PEt and LSP from
PEa to PEd. Note that such a construction may be useful if the LSPs
traverse via a common portion of the network and have the same
Bocci, et al. Expires July 26, 2010 [Page 38]
Internet-Draft MPLS Transport Profile Framework January 2010
constrains, such as the same set of requirements for QoS, etc.
|PEx|--|PEy|-+ +-|PEz|--|PEt|
| |
| |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+
| PE1 | | P | | P | | PE2 |
+--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ |
| |============= PST ==============| |
|PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd|
Figure 17: PST for a Set of Concatenated LSP Segments
3.11.1. Provisioning of PST
PSTs can be either provisioned statically or using control plane
signaling procedures. The make-before-break procedures which are
supported by MPLS allow the creation of a PST on existing LSPs in-
service without traffic disruption. A PST can be defined
corresponding to one or more end-to-end tunneled LSPs. New end-to-
end LSPs which are tunneled within the PST can be setup. Traffic of
the existing LSPs is switched over to the new end-to-end tunneled
LSPs. The old end-to-end LSPs can be tore down.
3.12. Network Management
The network management architecture and requirements for MPLS-TP are
specified in [I-D.ietf-mpls-tp-nm-framework] and
[I-D.ietf-mpls-tp-nm-req]. These derive from the generic
specifications described in ITU-T G.7710/Y.1701 [G.7710] for
transport technologies. It also incorporates the OAM requirements
for MPLS Networks [RFC4377] and MPLS-TP Networks
[I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements
to cover the modifications necessary for fault, configuration,
performance, and security in a transport network.
The Equipment Management Function (EMF) of an MPLS-TP Network Element
(NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through
which a management system manages the NE. The Management
Communication Channel (MCC), realised by the G-ACh, provides a
logical operations channel between NEs for transferring Management
information. For the management interface from a management system
to an MPLS-TP NE, there is no restriction on which management
protocol is used. The MCC is used to provision and manage an end-to-
end connection across a network where some segments are created/
Bocci, et al. Expires July 26, 2010 [Page 39]
Internet-Draft MPLS Transport Profile Framework January 2010
managed by, for example, Netconf or SNMP and other segments by XML or
CORBA interfaces. Maintenance operations are run on a connection
(LSP or PW) in a manner that is independent of the provisioning
mechanism. An MPLS-TP NE is not required to offer more than one
standard management interface. In MPLS-TP, the EMF must be capable
of statically provisioning LSPs for an LSR or LER, and PWs for a PE,
as well as any associated MEPs and MIPs, as per Section 3.9.
Fault Management (FM) functions within the EMF of an MPLS-TP NE
enable the supervision, detection, validation, isolation, correction,
and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. FM must provide for the supervision of transmission
(such as continuity, connectivity, etc.), software processing,
hardware, and environment. Alarm handling includes alarm severity
assignment, alarm suppression/aggregation/correlation, alarm
reporting control, and alarm reporting.
Configuration Management (CM) provides functions to control,
identify, collect data from, and provide data to MPLS-TP NEs. In
addition to general configuration for hardware, software protection
switching, alarm reporting control, and date/time setting, the EMF of
the MPLS-TP NE also supports the configuration of maintenance entity
identifiers (such as MEP ID and MIP ID). The EMF also supports the
configuration of OAM parameters as a part of connectivity management
to meet specific operational requirements. These may specify whether
the operational mode is one-time on-demand or is periodic at a
specified frequency.
The Performance Management (PM) functions within the EMF of an
MPLS-TP NE support the evaluation and reporting of the behaviour of
the NEs and the network. One particular requirement for PM is to
provide coherent and consistent interpretation of the network
behaviour in a hybrid network that uses multiple transport
technologies. Packet loss measurement and delay measurements may be
collected and used to detect performance degradation. This is
reported via fault management to enable corrective actions to be
taken (e.g. protection switching), and via performance monitoring for
Service Level Agreement (SLA) verification and billing. Collection
mechanisms for performance data should be capable of operating on-
demand or pro-actively.
4. Security Considerations
The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS and PWE3 apply to
those transport networks. Furthermore, when general MPLS networks
that utilise functionality outside of the strict MPLS Transport
Profile are used to support packet transport services, the security
Bocci, et al. Expires July 26, 2010 [Page 40]
Internet-Draft MPLS Transport Profile Framework January 2010
considerations of that additional functionality also apply.
For pseudowires, the security considerations of [RFC3985] and
[RFC5659] apply.
Packets that arrive on an interface with a given label value should
not be forwarded unless that label value is assigned to an LSP or PW
to a peer LSR or PE that is reachable via that interface.
Each MPLS-TP solution must specify the additional security
considerations that apply.
5. IANA Considerations
IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that
functionality.
This document introduces no additional IANA considerations in itself.
6. Acknowledgements
The editors wish to thank the following for their contribution to
this document:
o Rahul Aggarwal
o Dieter Beller
o Malcolm Betts
o Italo Busi
o John E Drake
o Hing-Kam Lam
o Marc Lasserre
o Vincenzo Sestito
o Nurit Sprecher
o Martin Vigoureux
o Yaacov Weingarten
Bocci, et al. Expires July 26, 2010 [Page 41]
Internet-Draft MPLS Transport Profile Framework January 2010
o The participants of ITU-T SG15
7. Open Issues
This section contains a list of issues that must be resolved before
last call.
o There is some text missing from the network layer clients section.
Text is invited covering the use of out of band signaling
associated with the AC.
o Need text to address how the LSR next hop MAC address is
determined for Ethernet link layers when no IP (i.e. ARP) is
available. If statically configured, what is the default? 181209:
this will be addressed in the normative data plane draft
o Need to add section (Appendix) describing stack optizations for
LSP and PWs
o Add a section clarify what options are used for interdomain
operation e.g. inter-AS TE LSPs, MS-PW, LSP stitching, back-to-
back ACs
o Text reduction for the OAM, survivability and NM sections.
o Include summarised PST text
8. References
8.1. Normative References
[G.7710] "ITU-T Recommendation
G.7710/Y.1701 (07/07),
"Common equipment
management function
requirements"", 2005.
[G.805] "ITU-T Recommendation G.805
(11/95), "Generic
Functional Architecture of
Transport Networks"",
November 1995.
[RFC3031] Rosen, E., Viswanathan, A.,
and R. Callon,
"Multiprotocol Label
Switching Architecture",
RFC 3031, January 2001.
Bocci, et al. Expires July 26, 2010 [Page 42]
Internet-Draft MPLS Transport Profile Framework January 2010
[RFC3032] Rosen, E., Tappan, D.,
Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and
A. Conta, "MPLS Label Stack
Encoding", RFC 3032,
January 2001.
[RFC3270] Le Faucheur, F., Wu, L.,
Davie, B., Davari, S.,
Vaananen, P., Krishnan, R.,
Cheval, P., and J.
Heinanen, "Multi-Protocol
Label Switching (MPLS)
Support of Differentiated
Services", RFC 3270,
May 2002.
[RFC3471] Berger, L., "Generalized
Multi-Protocol Label
Switching (GMPLS) Signaling
Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized
Multi-Protocol Label
Switching (GMPLS) Signaling
Resource ReserVation
Protocol-Traffic
Engineering (RSVP-TE)
Extensions", RFC 3473,
January 2003.
[RFC3985] Bryant, S. and P. Pate,
"Pseudo Wire Emulation
Edge-to-Edge (PWE3)
Architecture", RFC 3985,
March 2005.
[RFC4090] Pan, P., Swallow, G., and
A. Atlas, "Fast Reroute
Extensions to RSVP-TE for
LSP Tunnels", RFC 4090,
May 2005.
[RFC4203] Kompella, K. and Y.
Rekhter, "OSPF Extensions
in Support of Generalized
Multi-Protocol Label
Bocci, et al. Expires July 26, 2010 [Page 43]
Internet-Draft MPLS Transport Profile Framework January 2010
Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4385] Bryant, S., Swallow, G.,
Martini, L., and D.
McPherson, "Pseudowire
Emulation Edge-to-Edge
(PWE3) Control Word for Use
over an MPLS PSN",
RFC 4385, February 2006.
[RFC4447] Martini, L., Rosen, E., El-
Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup
and Maintenance Using the
Label Distribution Protocol
(LDP)", RFC 4447,
April 2006.
[RFC4872] Lang, J., Rekhter, Y., and
D. Papadimitriou, "RSVP-TE
Extensions in Support of
End-to-End Generalized
Multi-Protocol Label
Switching (GMPLS)
Recovery", RFC 4872,
May 2007.
[RFC5085] Nadeau, T. and C.
Pignataro, "Pseudowire
Virtual Circuit
Connectivity Verification
(VCCV): A Control Channel
for Pseudowires", RFC 5085,
December 2007.
[RFC5307] Kompella, K. and Y.
Rekhter, "IS-IS Extensions
in Support of Generalized
Multi-Protocol Label
Switching (GMPLS)",
RFC 5307, October 2008.
[RFC5462] Andersson, L. and R. Asati,
"Multiprotocol Label
Switching (MPLS) Label
Stack Entry: "EXP" Field
Renamed to "Traffic Class"
Bocci, et al. Expires July 26, 2010 [Page 44]
Internet-Draft MPLS Transport Profile Framework January 2010
Field", RFC 5462,
February 2009.
[RFC5586] Bocci, M., Vigoureux, M.,
and S. Bryant, "MPLS
Generic Associated
Channel", RFC 5586,
June 2009.
8.2. Informative References
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K.,
Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs",
draft-ietf-bfd-mpls-07
(work in progress),
June 2008.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F.,
Niven-Jenkins, B.,
Brungard, D., and L. Jin,
"Framework and Requirements
for Virtual Private
Multicast Service (VPMS)",
draft-ietf-l2vpn-vpms-
frmwk-requirements-02 (work
in progress), October 2009.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow,
"MPLS-TP Identifiers", draf
t-ietf-mpls-tp-identifiers-
00 (work in progress),
November 2009.
[I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E.,
and H. Lam, "MPLS-TP
Network Management
Framework", draft-ietf-
mpls-tp-nm-framework-04
(work in progress),
January 2010.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam,
"MPLS TP Network Management
Requirements", draft-ietf-
mpls-tp-nm-req-06 (work in
progress), October 2009.
Bocci, et al. Expires July 26, 2010 [Page 45]
Internet-Draft MPLS Transport Profile Framework January 2010
[I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and B.
Niven-Jenkins, "MPLS-TP OAM
Framework", draft-ietf-
mpls-tp-oam-framework-04
(work in progress),
December 2009.
[I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D.,
and M. Betts, "Requirements
for OAM in MPLS Transport
Networks", draft-ietf-mpls-
tp-oam-requirements-04
(work in progress),
December 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. Farrel,
"Multiprotocol Label
Switching Transport Profile
Survivability Framework", d
raft-ietf-mpls-tp-survive-
fwk-03 (work in progress),
November 2009.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M.,
Balus, F., Bitar, N., Shah,
H., Aissaoui, M., Rusmisel,
J., Serbest, Y., Malis, A.,
Metz, C., McDysan, D.,
Sugimoto, J., Duckett, M.,
Loomis, M., Doolan, P.,
Pan, P., Pate, P., Radoaca,
V., Wada, Y., and Y. Seo,
"Dynamic Placement of Multi
Segment Pseudo Wires", draf
t-ietf-pwe3-dynamic-ms-pw-
10 (work in progress),
October 2009.
[I-D.ietf-pwe3-redundancy] Muley, P. and V. Place,
"Pseudowire (PW)
Redundancy", draft-ietf-
pwe3-redundancy-02 (work in
progress), October 2009.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T.,
Metz, C., Duckett, M.,
Bocci, M., Balus, F., and
M. Aissaoui, "Segmented
Bocci, et al. Expires July 26, 2010 [Page 46]
Internet-Draft MPLS Transport Profile Framework January 2010
Pseudowire", draft-ietf-
pwe3-segmented-pw-13 (work
in progress), August 2009.
[RFC3443] Agarwal, P. and B. Akyol,
"Time To Live (TTL)
Processing in Multi-
Protocol Label Switching
(MPLS) Networks", RFC 3443,
January 2003.
[RFC3945] Mannie, E., "Generalized
Multi-Protocol Label
Switching (GMPLS)
Architecture", RFC 3945,
October 2004.
[RFC4377] Nadeau, T., Morrow, M.,
Swallow, G., Allan, D., and
S. Matsushima, "Operations
and Management (OAM)
Requirements for Multi-
Protocol Label Switched
(MPLS) Networks", RFC 4377,
February 2006.
[RFC4379] Kompella, K. and G.
Swallow, "Detecting Multi-
Protocol Label Switched
(MPLS) Data Plane
Failures", RFC 4379,
February 2006.
[RFC4664] Andersson, L. and E. Rosen,
"Framework for Layer 2
Virtual Private Networks
(L2VPNs)", RFC 4664,
September 2006.
[RFC5146] Kumaki, K., "Interworking
Requirements to Support
Operation of MPLS-TE over
GMPLS Networks", RFC 5146,
March 2008.
[RFC5254] Bitar, N., Bocci, M., and
L. Martini, "Requirements
for Multi-Segment
Bocci, et al. Expires July 26, 2010 [Page 47]
Internet-Draft MPLS Transport Profile Framework January 2010
Pseudowire Emulation Edge-
to-Edge (PWE3)", RFC 5254,
October 2008.
[RFC5309] Shen, N. and A. Zinin,
"Point-to-Point Operation
over LAN in Link State
Routing Protocols",
RFC 5309, October 2008.
[RFC5331] Aggarwal, R., Rekhter, Y.,
and E. Rosen, "MPLS
Upstream Label Assignment
and Context-Specific Label
Space", RFC 5331,
August 2008.
[RFC5654] Niven-Jenkins, B.,
Brungard, D., Betts, M.,
Sprecher, N., and S. Ueno,
"Requirements of an MPLS
Transport Profile",
RFC 5654, September 2009.
[RFC5659] Bocci, M. and S. Bryant,
"An Architecture for Multi-
Segment Pseudowire
Emulation Edge-to-Edge",
RFC 5659, October 2009.
Authors' Addresses
Matthew Bocci (editor)
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ
United Kingdom
Phone:
EMail: matthew.bocci@alcatel-lucent.com
Bocci, et al. Expires July 26, 2010 [Page 48]
Internet-Draft MPLS Transport Profile Framework January 2010
Stewart Bryant (editor)
Cisco Systems
250 Longwater Ave
Reading RG2 6GB
United Kingdom
Phone:
EMail: stbryant@cisco.com
Dan Frost
Cisco Systems
Phone:
Fax:
EMail: danfrost@cisco.com
URI:
Lieven Levrau
Alcatel-Lucent
7-9, Avenue Morane Sulnier
Velizy 78141
France
Phone:
EMail: lieven.levrau@alcatel-lucent.com
Lou Berger
LabN
Phone: +1-301-468-9228
Fax:
EMail: lberger@labn.net
URI:
Bocci, et al. Expires July 26, 2010 [Page 49]
