draft-ietf-mpls-tp-framework-00.txt   draft-ietf-mpls-tp-framework-01.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational S. Bryant, Ed. Intended status: Standards Track S. Bryant, Ed.
Expires: May 31, 2009 Cisco Systems Expires: December 31, 2009 Cisco Systems
L. Levrau, Ed. L. Levrau
Alcatel-Lucent Alcatel-Lucent
November 27, 2008 June 29, 2009
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-00 draft-ietf-mpls-tp-framework-01
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 31, 2009. This Internet-Draft will expire on December 31, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies an archiectectural framework for the This document specifies an archiectectural framework for the
application of MPLS in transport networks. It describes a profile of application of MPLS in transport networks. It describes a profile of
MPLS that enables operational models typical in transport networks MPLS that enables operational models typical in transport networks
networks, while providing additional OAM, survivability and other networks, while providing additional OAM, survivability and other
maintenance functions not currently supported by MPLS. maintenance functions not currently supported by MPLS.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Although this document is not a protocol specification, the key words
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
document are to be interpreted as described in RFC2119 [1]. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC2119 [RFC2119] and are to be
interpreted as instructions to the protocol designers producing
solutions that satisfy the architectural concepts set out in this
document..
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Background . . . . . . . . . . . . . . . . 3 1.1. Motivation and Background . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Summary of Requirements . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 5 2. Introduction to Requirements . . . . . . . . . . . . . . . . . 6
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 7
3.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 7
3.3. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Operations, Administration and Maintenance (OAM) . . . . . 9 3.3. MPLS-TP Forwarding Domain . . . . . . . . . . . . . . . . 10
3.4.1. Generic Associated Channel (G-ACH) . . . . . . . . . . 13 3.4. MPLS-TP Transport Domain . . . . . . . . . . . . . . . . . 11
3.4.2. Generic Alert Label (GAL) . . . . . . . . . . . . . . 15 3.5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Control Plane . . . . . . . . . . . . . . . . . . . . . . 16 3.6. Operations, Administration and Maintenance (OAM) . . . . . 13
3.5.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 18 3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 17
3.5.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 18 3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20
3.6. Static Operation of LSPs and PWs . . . . . . . . . . . . . 19 3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 22
3.7. Survivability . . . . . . . . . . . . . . . . . . . . . . 19 3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 22
3.8. Network Management . . . . . . . . . . . . . . . . . . . . 21 3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 23
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 3.11. Network Management . . . . . . . . . . . . . . . . . . . . 24
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
1.1. Motivation and Background 1.1. Motivation and Background
Existing transport technologies (e.g. SDH, ATM, OTN) have been This document describes a framework for a Multiprotocol Label
designed with specific characteristics: Switching Transport Profile (MPLS-TP). It presents the architectural
framework for MPLS-TP, definining those elements of MPLS applicable
to supporting the requirements in [I-D.ietf-mpls-tp-requirements] and
what new protocol elements are required.
o Strictly connection oriented Bandwidth demand continues to grow worldwide, stimulated by the
accelerating growth and penetration of new packet based services and
multimedia applications:
* Long-lived connections o Packet-based services such as Ethernet, Voice over IP (VoIP),
Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP
Television (IPTV), Radio Access Network (RAN) backhauling, etc.,
* Manually provisioned connections o Applications with various bandwidth and Quality of Service (QoS)
requirements.
o High level of protection and availability This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements.
o Quality of service Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous
Digital Hierarchy (SDH), Optical Transport Network (OTN)) has
provided carriers with a high benchmark for reliability and
operational simplicity. To achieve this, these existing transport
technologies have been designed with specific characteristics :
o Extended OAM capabilities o Strictly connection-oriented connectivity, which may be long-lived
and may be provisioned manually or by network management.
The development of MPLS-TP has been driven by the carriers needing to o A high level of protection and availability.
evolve SONET/SDH networks to support packet based services and
networks, and the desire to take advantage of the flexibility and
cost benefits of packet switching technology.
There are three objectives: o Quality of service.
o Extended OAM capabilities.
Carriers are looking to evolve such transport networks to support
packet based services and networks, and to take advantage of the
flexibility and cost benefits of packet switching technology. While
MPLS is a maturing packet technology that is already playing an
important role in transport networks and services, not all of MPLS's
capabilities and mechanisms are needed and/or consistent with
transport network operations. There are also transport technology
characteristics that are not currently reflected in MPLS.
The types of packet transport services delivered by transport
networks are very similar to Layer 2 Virtual Private Networks defined
by the IETF.
There are thus two objectives for MPLS-TP:
1. To enable MPLS to be deployed in a transport network and operated 1. To enable MPLS to be deployed in a transport network and operated
in a similar manner to existing transport technologies. in a similar manner to existing transport technologies.
2. To enable MPLS to support packet transport services with a 2. To enable MPLS to support packet transport services with a
similar degree of predictability to that found in existing similar degree of predictability to that found in existing
transport networks. transport networks.
3. To create a common set of new functions that are applicable to In order to achieve these objectives, there is a need to create a
both MPLS networks in general, and those blonging to the MPLS-TP common set of new functions that are applicable to both MPLS networks
profile. in general, and those blonging to the MPLS-TP profile.
MPLS-TP defines a profile of MPLS targeted at transport applications. MPLS-TP therefore defines a profile of MPLS targeted at transport
This profile specifies the specific MPLS characteristics and applications and networks. This profile specifies the specific MPLS
extensions required to meet transport requirements. An equipment characteristics and extensions required to meet transport
conforming to MPLS-TP must support this profile. An MPLS-TP requirements. An equipment conforming to MPLS-TP MUST support this
conformant equipment MAY support additional MPLS features. A carrier profile. An MPLS-TP conformant equipment MAY support additional MPLS
may deploy some of those additional features in the transport layer features. A carrier may deploy some of those additional features in
of their network if they find them to be beneficial. the transport layer of their network if they find them to be
beneficial.
1.2. Applicability
Figure 1 illustrates the range of services that MPLS-TP is intended Figure 1 illustrates the range of services that MPLS-TP is intended
to address. Networks supporting MPLS-TP are intended to support a to address. MPLS-TP is intended to support a range of layer 1, layer
range of layer 1,layer 2 and layer 3 services, and are not limited to 2 and layer 3 services, and is not limited to layer 3 services only.
layer 3 services only. Networks implementing MPLS-TP may choose to only support a subset of
these services.
MPLS-TP Solution exists MPLS-TP Solution exists
over this spectrum over this spectrum
|<-------------------------------->| |<-------------------------------->|
cl-ps Multi-Service co-cs & co-ps cl-ps Multi-Service co-cs & co-ps
(cl-ps & co-ps) (Label is (cl-ps & co-ps) (Label is
| | service context) | | service context)
| | | | | |
|<------------------------------|--------------------------------->| |<------------------------------|--------------------------------->|
| | | | | |
L3 Only L1, L2, L3 Services L1, L2 Services L3 Only L1, L2, L3 Services L1, L2 Services
Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP
Figure 1: MPLS-TP Service Spectrum Figure 1: MPLS-TP Applicability
1.2. Scope The diagram above shows the spectrum of services that can be
supported by MPLS. MPLS-TP solutions are primarily intended for
packet transport applications. These can be deployed using a profile
of MPLS that is strictly connection oriented and does not rely on IP
forwarding or routing (shown on the right hand side of the figure),
or in conjunction with an MPLS network that does use IP forwarding
and that supports a broader range of IP services. This is the multi-
service solution in the centre of the figure.
This document specifies the high-level functionality of MPLS-TP 1.3. Scope
required for adding transport-oriented capabilities to MPLS
1.3. Terminology This document describes a framework for a Tranport Profile of
Multiprotocol Label Switching (MPLS-TP). It presents the
architectural framework for MPLS-TP, definining those elements of
MPLS applicable to supporting the requirements in
[I-D.ietf-mpls-tp-requirements] and what new protocol elements are
required.
This document describes the architecture for MPLS-TP when the LSP
client is a PW. The transport of IP and MPLS, other than carried
over a PW, is outside the scope of this document. This does not
preclude the use of LSPs conforming to the MPLS transport profile
from being used to carry IP or other MPLS LSPs by general purpose
MPLS networks.
1.4. Terminology
Term Definition Term Definition
------- ----------------------------------------- ------- -----------------------------------------
LSP Label Switched Path LSP Label Switched Path
MPLS-TP MPLS Transport profile MPLS-TP MPLS Transport profile
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
OTN Optical Transport Network OTN Optical Transport Network
cl-ps Connectionless - Packet Switched cl-ps Connectionless - Packet Switched
co-cs Connection Oriented - Circuit Switched co-cs Connection Oriented - Circuit Switched
co-ps Connection Oriented - Packet Switched co-ps Connection Oriented - Packet Switched
OAM Operations, Adminitration and Maintenance OAM Operations, Adminitration and Maintenance
G-ACH Generic Associated Channel Header G-ACh Generic Associated Channel
GAL Generic Alert Label GAL Generic Alert Label
MEP Maintenance End Point MEP Maintenance End Point
MIP Maintenance Intermediate Point MIP Maintenance Intermediate Point
APS Automatic Protection Switching APS Automatic Protection Switching
SCC Signaling Communication Channel SCC Signaling Communication Channel
MCC Management Communication Channel MCC Management Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
FM Fault Management FM Fault Management
CM Configuration Management CM Configuration Management
PM Performance Management PM Performance Management
2. Summary of Requirements Detailed definitions and additional terminology may be found in
[I-D.ietf-mpls-tp-requirements].
This section summarizes the requirements for the MPLS transport
profile. Such requirements are specified in more detail in [20],
[21], and [22].
Solutions MUST NOT modify the MPLS forwarding architecture. 2. Introduction to Requirements
Solutions MUST be based on existing pseudowire and LSP constructs. The requirements for MPLS-TP are specified in
[I-D.ietf-mpls-tp-requirements], [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. It is not intended as a substitute for
these documents.
New mechanisms and capabilities added to support transport networks MPLS-TP MUST NOT modify the MPLS forwarding architecture and MUST be
must be able to interoperate or interwork with existing MPLS and based on existing pseudowire and LSP constructs. Any new mechanisms
pseudowire control and forwarding planes. and capabilities added to support transport networks and packet
transport services must be able to interoperate with existing MPLS
and pseudowire control and forwarding planes.
Point to point LSPs MAY be unidirectional or bi-directional. It MUST Point to point LSPs MAY be unidirectional or bi-directional, and it
be possible to construct congruent Bi-directional LSPs. Point to MUST be possible to construct congruent Bi-directional LSPs. Point
multipoint LSPs are unidirectional. to multipoint LSPs are unidirectional.
MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR. It is MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
possible to detect that a merged LSP has been created. MUST be possible to detect if a merged LSP has been created.
It MUST be possible to forward packets solely based on switching the 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 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 LSPs and/or pseudowires both in the absence or presence of a dynamic
control plane. When static provisioning is used, there MUST be no control plane. When static provisioning is used, there MUST be no
dependency on dynamic routing or signaling. dependency on dynamic routing or signaling.
OAM, protection and forwarding of data packets MUST be able to OAM, protection and forwarding of data packets MUST be able to
operate without IP forwarding support. operate without IP forwarding support.
It MUST be possible to monitor LSPs and pseudowires through the use 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 of OAM in the absence of control plane or routing functions. In this
case information gained from the OAM functions is used to initiate case information gained from the OAM functions is used to initiate
path recovery actions at either the PW or LSP layers. path recovery actions at either the PW or LSP layers.
3. Transport Profile Overview 3. Transport Profile Overview
3.1. Architecture 3.1. Packet Transport Services
The types of packet transport services provided by existing transport
networks are similar to MPLS Layer 2 VPNs. A key characteristic of
packet transport services is that the network used to provide the
service does not participate in the any IP routing protocols present
in the client, or use the IP addresses in client packets to forward
those packets. The network is therefore transparent to IP in the
client service.
MPLS-TP MUST use one of the Layer 2 VPN services defined in [PPVPN
architecture] to provide a packet transport service.
MPLS-TP LSPs MAY also be used to transport traffic for which the
immediate client of the MPLS-TP LSP is not a Layer 2 VPN. However,
for the purposes of this document, we do not refer to these traffic
types as belonging to a packet transport service. Such clients
include IP and MPLS LSPs.
3.2. Architecture
The architecture for a transport profile of MPLS (MPLS-TP) is based The architecture for a transport profile of MPLS (MPLS-TP) is based
on the MPLS-TE [2], pseudowire [3], and multi-segment pseudowire [4] on the MPLS [RFC3031], pseudowire [RFC3985], and multi-segment
architectures, as illustrated in Figure 2. The primary constructs of pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as illustrated
the transport profie for MPLS are LSPs, while PWs are the primary in Figure 2.
client layer.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
Figure 2: MPLS-TP Architecture (Single Segment PW)
Native |<------------Pseudowire-------------->| Native Native |<------------Pseudowire-------------->| Native
Service | PSN PSN | Service Service | PSN PSN | Service
(AC) | |<--cloud->| |<-cloud-->| | (AC) (AC) | |<--cloud->| |<-cloud-->| | (AC)
| V V V V V V | | V V V V V V |
| +----+ +-----+ +----+ | | +----+ +-----+ +----+ |
+----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+
| |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| |
| CE1| | | | | | | | | |CE2 | | CE1| | | | | | | | | |CE2 |
| |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| |
+----+ | | |===========| |==========| | | +----+ +----+ | | |===========| |==========| | | +----+
^ +----+ ^ +-----+ ^ +----+ ^ ^ +----+ ^ +-----+ ^ +----+ ^
| | | | | | | |
| TE LSP TE LSP | | TE LSP TE LSP |
| | | |
| | | |
|<---------------- Emulated Service ----------------->| |<---------------- Emulated Service ----------------->|
Figure 2: MPLS-TP Architecture MPLS-TP Architecture (Multi-Segment PW)
The MPLS-TP forwarding plane is a profile of the MPLS LSP PW, and The above figures illustrates the MPLS-TP architecture used to
MS-PW forwarding architecture as detailed in section Section 3.3. provide a point-to-point packet transport service, or VPWS. In this
case, the MPLS-TP forwarding plane is a profile of the MPLS LSP and
SS-PW or MS-PW forwarding architecture as detailed in section
Section 3.3.
MPLS-TP supports a comprehensive set of OAM and protection-switching This document describes the architecture for MPLS-TP when the LSP
capabilities for packet transport applications, with equivalent client is a PW. The transport of IP and MPLS, other than carried
capabilities to existing SONET/SDH OAM and protection, as described over a PW, is outside the scope of this document. This does not
in sections Section 3.4 and Section 3.7. MPLS-TP may be operated preclude the use of LSPs conforming to the MPLS transport profile
with centralized Network Management Systems with or without the from being used to carry IP or other MPLS LSPs by general purpose
support of a distributed control plane as described in sections MPLS networks. LSP hierarchy MAY be used within the MPLS-TP network,
Section 3.5 and Section 3.8. so that more than one LSP label MAY appear in the label stack.
MPLS-TP defines mechanisms to differentiate specific packets (e.g. +---------------------------+
OAM, APS, MCC or SCC) from those carrying user data packets on the | PW Native service |
same LSP. These mechanisms are described in sections /===========================\
Section 3.4.2and Section 3.4.1. H PW Encapsulation H \ <---- PW Control word
H---------------------------H \ <---- Normalised client
H PW OAM H MPLS-TP channel
H---------------------------H /
H PW Demux (S=1) H /
H---------------------------H \
H LSP OAM H \
H---------------------------H / MPLS-TP Path(s)
H LSP Demultiplexer(s) H /
\===========================/
| Server |
+---------------------------+
3.2. Addressing Figure 3: Domain of MPLS-TP Layer Network using Pseudowires
Figure (Figure 3) illustrates the protocol stack to be used when
pseudowires are carried over MPLS-TP LSPs.
When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used
to carry a client service. For compatibility with transport
nomenclature, the PW may be referred to as the MPLS-TP Channel and
the LSP may be referred to as the MPLS-TP Path.
Note that in MPLS-TP environments where IP is used for control or OAM
purposes, IP MAY be carried over the LSP demultiplexers as per
RFC3031 [RFC3031], or directly over the server.
PW OAM, PSN OAM and PW client data are mutually exclusive and never
exist in the same packet.
The MPLS-TP definition applies to the following two domains:
o MPLS-TP Forwarding Domain
o MPLS-TP Transport Domain
3.3. MPLS-TP Forwarding Domain
A set of client-to-MPLS-TP adaptation functions interface the client
to MPLS-TP. For pseudowires, this adaptation function is the PW
forwarder shown in Figure 4a of [RFC3985]. The PW label is used for
forwarding in this case and is always at the bottom of the label
stack. The operation of the MPLS-TP network is independent of the
payload carried by the MPLS-TP PW packet.
MPLS-TP is itself a client of an underlying server layer. MPLS-TP is
thus bounded by a set of adaptation functions to this server layer
network. 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 QoS from
the MPLS-TP network, which in turn inherits its QoS from the server
layer. The server layer must therefore provide the neccesary Quality
of Service (QoS) to ensure that the MPLS-TP client QoS commitments
are satisfied.
MPLS-TP LSPs use the MPLS label switching operations defined in
[RFC3031]. These operations are highly optimized for performance and
are not modified by the MPLS-TP profile.
During forwarding a label is pushed to associate a forwarding
equivalence class (FEC) with the LSP or PW. This specifies the
processing operaton 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, in which case the packet may be inspected and either
discarded or subjected to further processing within the LSR. TTL
expiry causes an exception which forces a packet to be further
inspected and processed. While this occurs, the forwarding of
succeeding packets continues without interruption. Therefore, the
only way to cause a P (intermediate) LSR to inspect a packet (for
example for OAM purposes) is to set the TTL to expire at that LSR.
MPLS-TP PWs support the PW and MS-PW forwarding operations defined
in[RFC3985] and [I-D.ietf-pwe3-ms-pw-arch].
The Traffic Class field (formerly the MPLS EXP field) follows the
definition and processing rules of [RFC5462] and [RFC3270]. Only the
pipe and short-pipe models are supported in MPLS-TP.
The MPLS encapsulation format is as defined in RFC 3032[RFC3032].
Per-platform label space is used for PWs. Either per-platform or
per-interface label space may be used for LSPs.
Point to point MPLS-TP LSPs can be either unidirectional or
bidirectional. Point-to-multipoint MPLS-TP LSPs are unidirectional.
Point-to-multipont PWs are currently being defined in the IETF and
may be incorporated in MPLS-TP if required.
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. they 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.
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.
Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270
[RFC3270]
3.4. MPLS-TP Transport Domain
This document specifies the architecture when the client of the
MPLS-TP LSP is a PW. Note, however, that in MPLS-TP environments
where IP is used for control or OAM purposes, IP MAY be carried over
the the LSPs or directly over the server, as described in
Section 3.2. In this case, the MPLS-TP transport domain consists of
the PW encapsulation mechanisms, including the PW control word.
3.5. Addressing
Editor's note: This section will be updated after publication of the
MPLS-TP Addressing Architecture draft.
MPLS-TP distinguishes between adressing used to identify nodes in the MPLS-TP distinguishes between adressing used to identify nodes in the
network, and identifiers used for demultiplexing and forwarding. network, and identifiers used for demultiplexing and forwarding.
This distinction is illustrated in Figure 3. This distinction is illustrated in Figure 4.
NMS Control/Signalling NMS Control/Signalling
..... ..... ..... .....
[Address]| | [Address] [Address]| | [Address]
| | | |
+-----+---------+------+ +-----+---------+------+
Address = Node | | | | Address = Node | | | |
ID in forwarding plane | V V | ID in forwarding plane | V V |
| | | |
| MEP or MIP | | MEP or MIP |
skipping to change at page 7, line 28 skipping to change at page 12, line 28
| |
OAM: OAM | OAM: OAM |
dmux= [GAL/GACH]........... dmux= [GAL/GACH]...........
or ________________________________________ or ________________________________________
IP (________________________________________) IP (________________________________________)
svc context=ID/FEC PWE=ID1 svc context=ID/FEC PWE=ID1
SRC=IP . SRC=IP .
. .
IDx IDx
Figure 3: Addressing in MPLS-TP Figure 4: Addressing in MPLS-TP
Ediror's note: The figure above arose from discussions in the MPLS-TP Editor's note: The figure above arose from discussions in the MPLS-TP
design team. It will be clarified in a future verson of this draft. design team. It will be clarified in a future verson of this draft.
IPv4 or IPv6 addresses are used to identify MPLS-TP nodes by default IPv4 or IPv6 addresses are used to identify MPLS-TP nodes by default
for network management and signaling purposes. for network management and signaling purposes.
In the forwarding plane, identfiers are required for the service In the forwarding plane, identfiers are required for the service
context (provided by the FEC), and for OAM. OAM requires both a context (provided by the FEC), and for OAM. OAM requires both a
demultiplexer and an address for the source of the OAM packet. demultiplexer and an address for the source of the OAM packet.
For MPLS in general where IP addressing is used, IPv4 or IPv6 is used For MPLS in general where IP addressing is used, IPv4 or IPv6 is used
by default. However, MPLS-TP must be able to operate in environments by default. However, MPLS-TP must be able to operate in environments
where IP is not used in the forwarding plane. Therefore, the default where IP is not used in the forwarding plane. Therefore, the default
mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the
generic associated channel. Forwarding based on IP addresses for generic associated channel. Forwarding based on IP addresses for
user or OAM packets is NOT REQUIRED for MPLS-TP. user or OAM packets is NOT REQUIRED for MPLS-TP.
RFC 4379 [23]and BFD for MPLS LSPs [24] have defined alert mechanisms RFC 4379 [RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have
that enable a MPLS LSR to identify and process MPLS OAM packets when defined alert mechanisms that enable a MPLS LSR to identify and
the OAM packets are encapsulated in an IP header. These alert process MPLS OAM packets when the OAM packets are encapsulated in an
mechanisms are based on TTL expiration and/or use an IP destination IP header. These alert mechanisms are based on TTL expiration and/or
address in the range 127/8. These mechanisms are the default use an IP destination address in the range 127/8. These mechanisms
mechanisms for MPLS networks in general for identifying MPLS OAM are the default mechanisms for MPLS networks in general for
packets when the OAM packets are encapsulated in an IP header. identifying MPLS OAM packets when the OAM packets are encapsulated in
MPLS-TP must not rely on these mechanisms, and thus relies on the an IP header. MPLS-TP must not rely on these mechanisms, and thus
GACH/GAL to demultiplex OAM packets. relies on the GACH/GAL to demultiplex OAM packets.
3.3. Forwarding
MPLS-TP LSPs use the MPLS label switching operations defined in [2].
These operations are highly optimized for performance and are not
modified by the MPLS-TP profile.
During forwarding a label is pushed to describe the processing
operaton to be performed at 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 circumstance that disrupts a swap operation is
TTL expiry, in which case the packet may be discarded or subjected to
further scrutinity within the LSR. Operations on a packet with an
expired TTL are asynchronous to the other packets in the LSP. Thus
the only way to cause a P (intermediate) LSR to inspect a packet (for
example for OAM purposes) is to set the TTL to expiry at that LSR.
MPLS-TP PWs support the PW and MS-PW forwarding operations defined
in[3] and [4].
The Traffic Class field (former MPLS EXP field) follows the
definition and processing rules of [5] and [6]. Only the pipe and
short-pipe models are supported in MPLS-TP.
The MPLS encapsulation format is as defined in RFC 3032[7]. Per-
platform or the per-interface label space can be selected. Standard
PW encapsulation mechanisms are applicable to the different client
layers as defined by the IETF PWE3 WG.
MPLS-TP LSPs can be unidirectional or bidirectional point-to-point.
As for MPLS, point-to-multipoint MPLS-TP LSPs are unidirectional.
Point-to-multipont PWs are currently in definition in the IETF and
may be incorporated in MPLS-TP if required.
It MUST be possible to configure an MPLS-TP LSP such that the forward
and backward directions of bidirectional MPLS-TP LSPs congruent: i.e.
they follow the same path. The pairing relationship between the
forward and the backward directions must be known at each MEP, MIP or
segment protection endpoint on a bidirectional LSP.
Per-packet equal cost multi-path (ECMP) load balancing is not 3.6. Operations, Administration and Maintenance (OAM)
applicable to MPLS-TP LSPs, however PWs or LSPs that emulate link
bundles may be employed, for example [25]
Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.
The applicability of PHP to both MPLS-TP LSPs and MPLS networks in
general providing paket transport services will be clarified in a
future version of this draft.
Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270 MPLS-TP supports a comprehensive set of OAM capabilities for packet
[6]. transport applications, with equivalent capabilities to those
provided in SONET/SDH.
3.4. Operations, Administration and Maintenance (OAM) MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the
same LSP. These mechanisms are described in RFC5586 [RFC5586].
MPLS-TP requires [21] that a set of OAM capabilities is available to MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of
perform fault management (e.g. fault detection and localization) and OAM capabilities is available to perform fault management (e.g. fault
performance monitoring (e.g. signal quality measurement) of the detection and localization) and performance monitoring (e.g. packet
MPLS-TP network and the services. These capabilities are applicable delay and loss measurement) of the LSP, PW or section. The framework
at the section, LSP and PW layer. The framework for OAM in MPLS-TP for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].
is specified in [26].
OAM and monitoring in MPLS-TP is based on the concept of maintenance OAM and monitoring in MPLS-TP is based on the concept of maintenance
entities, as described in [26]. A Maintenance Entity can be viewed entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A
as the association of two (or more) Maintenance End Points (MEPs) Maintenance Entity can be viewed as the association of two (or more)
(see example in Figure 4 ). The MEPS that form an ME should be Maintenance End Points (MEPs) (see example in Figure 5 ). The MEPs
configured and managed to limit the OAM responsibilities of an OAM that form an ME should be configured and managed to limit the OAM
flow within a network or sub-network in the specific layer network responsibilities of an OAM flow within a network or sub- network, or
that is being monitored and managed. Each OAM flow is associated to a transport path or segment, in the specific layer network that is
a unique ME. Each MEP within an ME resides at the boundaries of that being monitored and managed.
ME. An ME may also include a set of zero or more Maintenance
Intermediate Points (MIPs), which reside within the Maintenance Each OAM flow is associated with a single ME. Each MEP within an ME
Entity. Maintenance end points (MEPs) are capable of sourcing and resides at the boundaries of that ME. An ME may also include a set
sinking OAM flows, while maintenance intermediate points (MIPs) can of zero or more Maintenance Intermediate Points (MIPs), which reside
only sink or respond to OAM flows. 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.
========================== End to End LSP OAM ============================ ========================== End to End LSP OAM ============================
..... ..... ..... ..... ..... ..... ..... .....
-----|MIP|---------------------|MIP|---------|MIP|------------|MIP|----- -----|MIP|---------------------|MIP|---------|MIP|------------|MIP|-----
''''' ''''' ''''' ''''' ''''' ''''' ''''' '''''
|<-------- Carrier 1 --------->| |<----- Carrier 2 ----->| |<-------- Carrier 1 --------->| |<--- Carrier 2 ----->|
---- --- --- ---- ---- --- ---- ---- --- --- ---- ---- --- ----
NNI | | | | | | | | NNI | | | | | | NNI NNI | | | | | | | | NNI | | | | | | NNI
-----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |----- -----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |-----
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
---- --- --- ---- ---- --- ---- ---- --- --- ---- ---- --- ----
==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM === ==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM ===
(Carrier 1) LSP OAM (Carrier 2) (Carrier 1) LSP OAM (Carrier 2)
(inter-carrier) (inter-carrier)
..... ..... ..... .......... .......... ..... ..... ..... ..... ..... .......... .......... ..... .....
|MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP| |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. Note: MEPs for End-to-end LSP OAM exist outside of the scope of this figure.
Figure 4: Example of MPLS-TP OAM Figure 5: Example of MPLS-TP OAM
Editor's note: The above diagram will be clarified in the next
version of this draft.
The OAM architecture for MPLS-TP is illustrated in Figure 5. Figure 6 illustrates how the concept of Maintenance Entities can be
mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
PWs.
Native |<-------------------- PW15 --------------------->| Native Native |<-------------------- PW15 --------------------->| Native
Layer | | Layer Layer | | Layer
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2) (AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
|CE1|--------|........PW1........|...PW3...|........PW5........|-----|CE2| |CE1|--------|........PW1........|...PW3...|........PW5........|-----|CE2|
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
|<- Subnetwork 123->| |<- Subnetwork XYZ->| |<- Subnetwork 123->| |<- Subnetwork XYZ->|
.------------------- PW15 PME -------------------. .------------------- PW15 PME -------------------.
.----- PW1 TPME ----. .---- PW5 TPME -----. .---- PW1 PTCME ----. .---- PW5 PTCME ---.
.---------. .---------. .---------. .---------.
PSN13 LME PSNXZ LME PSN13 LME PSNXZ LME
.--. .--. .--------. .--. .--. .--. .--. .--------. .--. .--.
Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
.---. ME . MEP ==== LSP .... PW .---. ME . MEP ==== LSP .... PW
SME: Section Maintenance Entity SME: Section Maintenance Entity
LME: LSP Maintenance Entity LME: LSP Maintenance Entity
PME: PW Maintenance Entity PME: PW Maintenance Entity
Figure 5: MPLS-TP OAM archtecture Figure 6: MPLS-TP OAM archtecture
The following MPLS-TP MEs are specified in [26]: The following MPLS-TP MEs are specified in
[I-D.ietf-mpls-tp-oam-framework]:
o A Section Maintenance Entity (SME), allowing monitoring and o A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs). management of MPLS-TP Sections (between MPLS LSRs).
o A LSP Maintenance Entity (LME), allowing monitoring and management o A LSP Maintenance Entity (LME), allowing monitoring and management
of an end-to-end LSP (between LERs). of an end-to-end LSP (between LERs).
o A PW Maintenance Entity (PME), allowing monitoring and management o A PW Maintenance Entity (PME), allowing monitoring and management
of an end-to-end SS/MS-PWs (between T-PEs). of an end-to-end SS/MS-PWs (between T-PEs).
o An LSP Tandem Connection Maintenance Entity (TLME), allowing o An LSP Tandem Connection Maintenance Entity (LTCME), allowing
monitoring and management of an LSP Tandem Connection (or LSP monitoring and management of an LSP Tandem Connection (or LSP
Segment) between any LER/LSR along the LSP. o A MS-PW Tandem Segment) between any LER/LSR along the LSP. o A MS-PW Tandem
Connection Maintenance Entity (TPME), allows monitoring and Connection Maintenance Entity (PTCME), allows monitoring and
management of a SS/MS-PW Tandem Connection (or PW Segment) between management of a SS/MS-PW Tandem Connection (or PW Segment) between
any T-PE/S-PE along the (MS-)PW. any T-PE/S-PE along the (MS-)PW. Note that the term Tandem
Connection Monitoring has historical significance dating back to
the early days of the telephone network, but is equally applicable
to the two-level hierarchal architectures commonly employed in
todays packet networks.
Individual MIPs along the path of an LSP or PW are addressed by Individual MIPs along the path of an LSP or PW are addressed by
setting the appropriate TTL in the label for the OAM packet, as per setting the appropriate TTL in the label for the OAM packet, as per
[27]. Note that this works when the location of MIPs along the LSP [I-D.ietf-pwe3-segmented-pw]. Note that this works when the location
or PW path is known by the MEP. There may be cases where this is not of MIPs along the LSP or PW path is known by the MEP. There may be
the case in general MPLS networks e.g. following restoration using a cases where this is not the case in general MPLS networks e.g.
facility bypass LSP. following restoration using a facility bypass LSP.
The following is a high level summary of the classes of OAM functions MPLS-TP OAM packets share the same fate as their corresponding data
that MPLS-TP supports. These are intended to be applicable to any packets, and are identified through the Generic Associated Channel
layer defined within MPLS- TP, i.e. MPLS Section, LSP and PW: 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.
The MPLS-TP OAM architecture support a wide range of OAM functions,
including the following
o Continuity Check o Continuity Check
o Connectivity verification o Connectivity Verification
o Performance monitoring o Performance monitoring (e.g. loss and delay)
o Alarm suppression o Alarm suppression
o Remote Integrity o Remote Integrity
For all of the above listed functions except alarm suppression, both These are applicable to any layer defined within MPLS- TP, i.e. MPLS
"continuous" and "on-demand" operation SHOULD be supported. Section, LSP and PW.
Performance monitoring includes means for both "packet loss
measurement" and "delay measurement".
It is REQUIRED that MPLS-TP OAM packets share the same fate as their
corresponding data packets and that a means exists to identify OAM
packets. The document[8] proposes specific mechanisms relying on the
combination of the 'Generic Alert Label (GAL)' and Generic Associated
Channel Header for MPLS Sections and LSPs and using the Generic
Associated Channel Header only for MPLS PWs. This is described in
more detail elsewhere in this document Section 3.4.1 and
Section 3.4.2.
The MPLS-TP OAM toolset needs to be able to operate without relying The MPLS-TP OAM toolset needs to be able to operate without relying
on a dynamic control plane or IP functionality in the datapath. In on a dynamic control plane or IP functionality in the datapath. In
the case of MPLS-TP deployment with IP functionality, all existing the case of MPLS-TP deployment with IP functionality, all existing
IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used. IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used.
This does not preculde the use of other OAM tools in an IP This does not preculde the use of other OAM tools in an IP
addressable network. addressable network.
One use of OAM mechanisms is to detect link failures, node failures One use of OAM mechanisms is to detect link failures, node failures
and performance outside the required specification which then may be and performance outside the required specification which then may be
used to trigger recovery actions, according to the requirements of used to trigger recovery actions, according to the requirements of
the service. the service.
3.4.1. Generic Associated Channel (G-ACH) 3.7. Generic Associated Channel (G-ACh)
MPLS-TP makes use of a generic associated channel (G-ACH) to support For correct operation of the OAM it is important that the OAM packets
Fault, Configuration, Accounting, Performance and Security (FCAPS) fate share with the data packets. In addition in MPSL-TP it is
functions by carrying packets related to OAM, APS, SCC, MCC or other necessary to discriminate between user data payloads and other types
packet types in band over LSPs or PWs. The G-ACH is defined in of payload. For example the packet may contain a Signaling
[8]and it is similar to the PWE3 Associated Channel, which is used to Communication Channel (SCC), or a channel used for Automatic
carry OAM packets across pseudowires. The G-ACH is indicated by a Protecton Switching (APS) data. Such packetets are carried on a
generic associated channel header, similar to the PWE3 VCCV control control channel associated to the LSP, Section or PW. This is
word, and this is present for all LSPs and PWs making use of FCAPS achieved by carrying such packets on a generic control channel
functions supported by the G-ACH. 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 it is similar to the Pseudowire Associated Channel
[RFC4385], which is used to carry OAM packets across pseudowires.
The G-ACH is indicated by a generic associated channel header (ACH),
similar to the Pseudowire VCCV control word, and this is present for
all Sections, LSPs and PWs making use of FCAPS functions supported by
the G-ACH.
For pseudowires, the G-ACh use the first nibble of the pseudowire
control word to provide the initial discrimination between data
packets a packets belonging to the associated channel, as described
in[RFC4385]. When the first nibble of a packet, immediately
following the label at the bottom of stack, has a value of one, 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 a similar 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 acheived 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 anywhere within the label stack 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 iin 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 arein accordance with [RFC3031] and
[RFC3032].
In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1), however this does
not preclude its use elsewhere in the label stack in other
applications.
The G-ACH MUST only be used for channels that are an adjunct to the 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 data service. Examples of these are OAM, APS, MCC and SCC, but the
use is not resticted to those names services. The G-ACH MUST NOT be use is not resticted to those names services. The G-ACH MUST NOT be
used to carry additional data for use in the forwarding path, i.e. it 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 MUST NOT be used as an alternative to a PW control word, or to define
a PW type. a PW type.
The messages transfered over the G-ACH MUST conform to the security Since the G-ACh traffic is indistinguishable from the user data
and congestion considerations described in [8]. They must also take traffic at the server layer, bandwidth and QoS commitments apply to
into consideration the throughput, latency and congestion the gross traffic on the LSP, PW or section. Protocols using the
requirements of the main data channel. G-ACh must therefore take into consideration the impact they have on
the user data that they are sharing resources with. In addition,
protocols using the G-ACh MUST conform to the security and congestion
considerations described in [RFC5586]. .
Figure 1 shows the reference model depicting how the control channel Figure 7 shows the reference model depicting how the control channel
is associated with the pseudowire protocol stack, as per [9]. is associated with the pseudowire protocol stack. This is based on
the reference model for VCCV shown in Figure 2 of [RFC5085].
+-------------+ +-------------+ +-------------+ +-------------+
| Layer2 | | Layer2 | | Payload | < Service / FCAPS > | Payload |
| Emulated | < Emulated Service > | Emulated |
| Services | | Services |
+-------------+ +-------------+ +-------------+ +-------------+
| | VCCV/PW | | | Demux / | < CW / ACH for PWs > | Demux / |
|Demultiplexer| < Associated Channel > |Demultiplexer| |Discriminator| |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < PSN Tunnel > | PSN | | PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+ +-------------+ +-------------+
| Physical | | Physical | | Physical | | Physical |
+-----+-------+ +-----+-------+ +-----+-------+ +-----+-------+
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 6: PWE3 Protocol Stack Reference Model including the PW Figure 7: PWE3 Protocol Stack Reference Model including the G-ACh
Associated Control Channel
PW associated channel messages are encapsulated using the PWE3 PW associated channel messages are encapsulated using the PWE3
encapsulation, so that they are handled and processed in the same encapsulation, so that they are handled and processed in the same
manner (or in some cases, an analogous manner) as the PW PDUs for manner (or in some cases, an analogous manner) as the PW PDUs for
which they provide a control channel. which they provide a control channel.
Figure 2 shows the reference model depicting how the control channel Figure 8 shows the reference model depicting how the control channel
is associated with the LSP protocol stack. is associated with the LSP protocol stack.
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
| Payload | < Service > | Payload | | Payload | < Service > | Payload |
| Services | | |
+-------------+ +-------------+ +-------------+ +-------------+
| | LSP | | |Discriminator| < ACH on LSP > |Discriminator|
|Demultiplexer| < Associated Channel > |Demultiplexer|
+-------------+ +-------------+ +-------------+ +-------------+
| GAL | | GAL | |Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < LSP > | PSN | | PSN | < LSP > | PSN |
+-------------+ +-------------+ +-------------+ +-------------+
| Physical | | Physical | | Physical | | Physical |
+-----+-------+ +-----+-------+ +-----+-------+ +-----+-------+
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 7: MPLS Protocol Stack Reference Model including the LSP Figure 8: MPLS Protocol Stack Reference Model including the LSP
Associated Control Channel Associated Control Channel
LSP associated channel messages are encapsulated using a generic 3.8. Control Plane
associated control channel header (G-ACH). The presence of the GE-
ACH is indicated by the inclusion of an additional 'Generic Alert
Label (GAL)'. This arrangement means that both normal data packets
and packets carrying an ACH are carried over LSPs in a similar
manner.
Note that where a traffic engineered LSP is used the paths will be
identical. If for any reason a non-traffic engineered path (for
example an LDP path) were to be used the ECMP behaviour may be
modified by the presence of the GAL.
3.4.2. Generic Alert Label (GAL)
For correct operation of the OAM it is important that the OAM packets
fate share with the data packets. In addition in MPSL-TP it is
necessary to indicate that the payload carried over an LSP is not
user data. For example the packet may contain Signaling
Communication Channel (SCC), or Automatic Protecton Switching (APS)
data. The presence of the ACH indicates that the packet is not user
data and identifies its type.
PWE3 uses the first nibble of the control word to provide the initial
discrimination between data packets and "other" packets [10]. When
the first nibble of a pseudwire packet has a value of one, then the
first 32 bits that follow the bottom of stack have a defined format
called an ACH, and which further defines the content of the
pseudowire packet. For MPLS-TP this mechanism is further generalized
to apply to also apply to LSPs and MPLS sections [8].
When the OAM, or a similar 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 regular data
packet. This is acheived by including ia new reserved label in the
label stack. This reserved label is referred to as the 'Generic
Alert Label (GAL)', and is defined in [8]. When a GAL is found
anywhere within the label stack it indicates that the payload begins
with an 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
label being popped. The only circumstance under which the label
stack may be inspected for a GAL is when the TTL has expired. Any
MPLS-TP component which intentionally triggers this inspection must
assume that the inspection to be asynchronous with respect to the
forwarding of other packets.
In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1), however this does
not preclude its use elsewhere in the label stack in other
applications.
3.5. Control Plane
The MPLS-TP may utilize a distributed control plane to enable fast, MPLS-TP should be capable of being operated with centralized Network
dynamic and reliable service provisioning in multi-vendor and multi- Management Systems (NMS). The NMS may be supported by a distributed
domain environments using standardized protocols that guarantee control plane, but MPLS-TP can operated in the absense of such a
interoperability. control plane. A distributed control plane may be used to enable
dynamic service provisioning in multi-vendor and multi-domain
environments using standardized protocols that guarantee
interoperability. Where the requirements specified in
[I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport
profile uses existing control plane protocols for LSPs and PWs.
Figure 8 illustrates the relationshop between the MPLS-TP control Figure 9 illustrates the relationshop between the MPLS-TP control
plane, the forwarding plane, the management plane, and OAM. plane, the forwarding plane, the management plane, and OAM for point-
to-point MPLS-TP LSPs or PWs.
+------------------------------------------------------------------------+ +------------------------------------------------------------------------+
| | | |
| Network Management System and/or | | Network Management System and/or |
| | | |
| Control Plane for Point to Point Connections | | Control Plane for Point to Point Connections |
| | | |
+------------------------------------------------------------------------+ +------------------------------------------------------------------------+
| | | | | | | | | | | |
............|......|..... ....|.......|.... ....|....|............... ............|......|..... ....|.......|.... ....|....|...............
skipping to change at page 17, line 28 skipping to change at page 21, line 28
\: +----+ +----------+ : : +----------+ : : +----------+ +----+ :/ \: +----+ +----------+ : : +----------+ : : +----------+ +----+ :/
--+-|Edge|<->|Forwarding|<---->|Forwarding|<----->|Forwarding|<->|Edge|-+-- --+-|Edge|<->|Forwarding|<---->|Forwarding|<----->|Forwarding|<->|Edge|-+--
/: +----+ | | : : | | : : | | +----+ :\ /: +----+ | | : : | | : : | | +----+ :\
: +----------+ : : +----------+ : : +----------+ : : +----------+ : : +----------+ : : +----------+ :
''''''''''''''''''''''''' ''''''''''''''''' '''''''''''''''''''''''' ''''''''''''''''''''''''' ''''''''''''''''' ''''''''''''''''''''''''
Note: Note:
1) NMS may be centralised or distributed. Control plane is distributed 1) NMS may be centralised or distributed. Control plane is distributed
2) 'Edge' functions refers to those functions present at the edge of 2) 'Edge' functions refers to those functions present at the edge of
a PSN domain, e.g. NSP or classification. a PSN domain, e.g. NSP or classification.
3) OAM functions are described in more detail below.
Figure 8: MPLS-TP Control Plane Architecture Context Figure 9: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on a combination of the MPLS The MPLS-TP control plane is based on a combination of the LDP-based
control plane for pseudowires and the GMPLS control plane for MPLS-TP control plane for pseudowires [RFC4447] and the RSVP-TE based control
LSPs, respectively. More specifically, LDP is used for PW signaling plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that
and GMPLS based RSVP-TE for LSP signaling. The distributed MPLS-TP are required for LSP signaling for MPLS-TP are based on GMPLS.
control plane provides the following basic functions:
The distributed MPLS-TP control plane provides the following
functions:
o Signaling o Signaling
o Routing o Routing
o Traffic engineering and constraint-based path computation o Traffic engineering and constraint-based path computation
In a multi-domain environment, the MPLS-TP control plane may provide In a multi-domain environment, the MPLS-TP control plane supports
different types of interfaces at domain boundaries or within the different types of interfaces at domain boundaries or within the
domains such as UNI, I-NNI, and E-NNI where different policies are in domains. These include the User-Network Interface (UNI), Internal
place that control what kind of information is exchanged across these Network Node Interface (I-NNI), and External Network Node Interface
different types of interfaces. (E-NNI). Note that different policies may be defined that control
the information exchanged across these interface types.
Editor's note: Isn't the following a managment plane operation. I
can't think of a routing protocol triggering an OAM message. Or do
we mean that the control plane is capable of reacting to OAM events?
Control plane and OAM are independent.
The MPLS-TP control plane is capable of activating MPLS-TP OAM The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document functions as described in the OAM section of this document
Section 3.4 e.g. for fault detection and localization in the event of Section 3.6 e.g. for fault detection and localization in the event of
a failure in order to efficiently restore failed transport paths. a failure in order to efficiently restore failed transport paths.
The MPLS-TP control plane supports all MPLS-TP data plane The MPLS-TP control plane supports all MPLS-TP data plane
connectivity patterns that are needed for establishing transport connectivity patterns that are needed for establishing transport
paths including protected paths as described in the survivability paths including protected paths as described in the survivability
section Section 3.7 of this document. Examples of the MPLS-TP data section Section 3.10 of this document. Examples of the MPLS-TP data
plane connectivity patterns are LSPs utilizing the fast reroute plane connectivity patterns are LSPs utilizing the fast reroute
backup methods as defined in [11] and ingress-to-egress 1+1 or 1:1 backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or
protected LSPs. 1:1 protected LSPs.
Moreover, the MPLS-TP control plane needs to be capable of performing
fast restoration in the event of network failures.
The MPLS-TP control plane provides features to ensure its own The MPLS-TP control plane provides functions to ensure its own
survivavbility and to enable it to recover gracefully from failures survivability and to enable it to recover gracefully from failures
and degredations. These include graceful restart and hot redundant and degredations. These include graceful restart and hot redundant
configurations. The MPLS-TP control plane is largely decoupled from configurations. Depending on how the control plane is transported,
the MPLS-TP data plane such that failures in the control plane do not varying degrees of decoupling between the control plane and data
impact the data plane and vice versa. plane may be achieved.
3.5.1. PW Control Plane 3.8.1. PW Control Plane
An MPLS-TP packet transport network provides many of its transport An MPLS-TP network provides many of its transport services using
services in the form of single-segment or multi-segment pseudowires single-segment or multi-segment pseudowires, in compliance with the
following the PWE3 architecture as defined in [3] and [4] . The PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). The
setup and maintenance of single-segment or multi- segment pseudowires setup and maintenance of single-segment or multi- segment pseudowires
is based on the Label Distribution Protocol (LDP) as per [12] and the uses the Label Distribution Protocol (LDP) as per [RFC4447] and
use of LDP in this manner is applicable to PWs used to provide MPLS extensions for MS-PWs [I-D.ietf-pwe3-segmented-pw] and
transport services. [I-D.ietf-pwe3-dynamic-ms-pw].
It shall be noted that multi-segment pseudowire signaling is still
work in progress. The control plane supporting multi-segment
pseudowires is based on [13].
3.5.2. LSP Control Plane
Editors note: The following must be reviewed by a CP specialist. Lou 3.8.2. LSP Control Plane
will review and provide comments.
MPLS-TP provider edge nodes aggregate multiple pseudowires and carry MPLS-TP provider edge nodes aggregate multiple pseudowires and carry
them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
LSPs). The generalized MPLS (GMPLS) protocol suite already supports LSPs). Applicable functions from the Generalized MPLS (GMPLS)
packet-switched capable (PSC) technologies and is therefore used as protocol suite supporting packet-switched capable (PSC) technologies
control plane for MPLS-TP transport paths (LSPs). The LSP control are used as the control plane for MPLS-TP transport paths (LSPs).
plane includes:
o RSVP-TE for signalling The LSP control plane includes:
o OSPF-TE for routing o RSVP-TE for signalling
o ISIS-TE for routing o OSPF-TE or ISIS-TE for routing
RSVP-TE signaling in support of GMPLS as defined in [14]is used for RSVP-TE signaling in support of GMPLS, as defined in [RFC4872], is
the setup, modification, and release of MPLS-TP transport paths and used for the setup, modification, and release of MPLS-TP transport
protection paths. It supports unidirectional, bi-directional and paths and protection paths. It supports unidirectional, bi-
multicast types of LSPs. The route of a transport path is typically directional and multicast types of LSPs. The route of a transport
calculated in the ingress node of a domain and the RSVP explicit path is typically calculated in the ingress node of a domain and the
route object (ERO) is utilized for the setup of the transport path RSVP explicit route object (ERO) is utilized for the setup of the
exactly following the given route. GMPLS based MPLS-TP LSPs must be transport path exactly following the given route. GMPLS based
able to interoperate with RSVP-TE based MPLS-TE LSPs, as per [28] MPLS-TP LSPs must be able to interoperate with RSVP-TE based MPLS-TE
LSPs, as per [RFC5146]
OSPF-TE routing in support of GMPLS as defined in [15] is used for OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used
for carrying link state information in a MPLS-TP network. ISIS-TE
routing in support of GMPLS as defined in [RFC5307] is used for
carrying link state information in a MPLS-TP network. carrying link state information in a MPLS-TP network.
For routing scalability reasons, parallel physical links in an MPLS- 3.9. Static Operation of LSPs and PWs
TP network are typically bundled into TE-links as defined in [16]and
the OSPF-TE routing protocol disseminates link state information on a
TE-link basis.
3.6. Static Operation of LSPs and PWs
Where a control plane is not used to set up and manage PWs or LSPs, A PW or LSP may be statically configured without the support of a
the following considerations apply. Static configuration of the PW dynamic control plane. This may be either by direct configuration of
or LSP, either by direct configuration of the PEs/LSRs, or via a the PEs/LSRs, or via a network management system. The colateral
network management station must take care that loops to not form on damage that loops can cause during the time taken to detect the
an active LSP. The OAM would normally detect a break in end to end failure may be severe. When static configuration mechanisms are
connectivity as a consequence of a loop, and withdraw the LSP from used, care must be taken to ensure that loops to not form.
use. However the colateral damage that a loop can during the time
taken to detect the failure is severe. Therefore an LSP should not
be brought into operation until it certain that loops do not exist.
3.7. Survivability 3.10. Survivability
Survivability requirements for MPLS-TP are apecified in [29]. 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 A wide variety of resiliency schemes have been developed to meet the
various network and service survivability objectives. For example, various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels ([11]), while pseudowire redundancy repair using back-up LSP tunnels ([RFC4090]), while pseudowire
[17]supports scenarios where the protection for the PW can not be redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
fully provided by the PSN layer (i.e. where the backup PW terminates protection for the PW can not be fully provided by the PSN layer
on a different target PE node than the working PW). Additionally, (i.e. where the backup PW terminates on a different target PE node
GMPLS provides a set of control plane driven well known protection than the working PW). Additionally, GMPLS provides a well known set
and restoration mechanisms [14]. Finally, as part of the transport of control plane driven protection and restoration mechanisms
networks and applications paradigms, APS-based linear and ring [RFC4872]. MPLS-TP provides additional protection mechansisms that
protection mechanisms are defined in [18]and [30]. are optimised for both linear topologies and ring topologies, and
that operate in the absense of a dynamic control plane. These are
These schemes have different scopes. They are protecting against specified in [I-D.ietf-mpls-tp-survive-fwk].
link and/or node failures and can be applied end-to-end or on a
segment of the considered connection.
These protection schemes propose different levels of resiliency (e.g.
1+1, 1:1, shared).
Different protection schemes apply to different deployment topologies
and operational considerations. Such protection schemes may provide
different levels of resiliency. For example, two concurrent traffic
paths (1+1), one active and one standby path with guaranteed
bandwidth on both paths (1:1) or one active path and a standby path
that is shared by one or more other active paths (shared protection).
The applicability of any given scheme to meet specific requirements The applicability of any given scheme to meet specific requirements
is outside the current scope of this document. is outside the current scope of this document.
MPLS-TP resiliency mechanisms characteristics are listed below The characteristics of MPLS-TP resiliency mechanisms are listed
below.
o Linear, ring and meshed protection schemes are supported. o Optimised for linear, ring or meshed topologies.
o As with all network layer protection schemes, MPLS-TP recovery o Use OAM mechanisms to detect and localize network faults or
mechanisms (protection and restoration), rely on OAM mechanisms to service degenerations.
detect and localize network faults or service degenerations.
o APS-based protection mechanisms (linear and ring) rely on MPLS-TP o Include protection mechanisms to coordinate and trigger protection
APS mechanisms to coordinate and trigger protection switching switching actions in the absense of a dynamic control plane. This
actions. is known as an Automatic Protection Switching (APS) mechanism.
o MPLS-TP recovery schemes are designed to be applicable at various o MPLS-TP recovery schemes are applicable to all levels in the
levels (MPLS section, LSP and PW), providing segment and end-to- MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment
end recovery. and end-to- end recovery.
o MPLS-TP recovery mechanisms support means for avoiding race o MPLS-TP recovery mechanisms support the coordination of protection
conditions in switching activity triggered by a fault condition switching at multiple levels to prevent race conditions occuring
detected both at server layer and at MPLS-TP layer. between a client and its server layer.
o MPLS-TP recovery mechanisms can be data plane, control plane or o MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based. management plane based.
o MPLS-TP allows for revertive and non-revertive behavior o MPLS-TP supports revertive and non-revertive behavior.
o Multiple resiliency mechanisms can be applied to any connection
3.8. Network Management 3.11. Network Management
The network management architecture and requirements for MPLS-TP are The network management architecture and requirements for MPLS-TP are
specified in [22]. It derives from the generic specifications specified in [I-D.ietf-mpls-tp-nm-req]. It derives from the generic
described in ITU-T G.7710/Y.1701 [19]for transport technologies. It specifications described in ITU-T G.7710/Y.1701 [G.7710] for
also leverages on the OAM requirements for MPLS Networks [31] and transport technologies. It also incorporates the OAM requirements
MPLS-TP Networks [21]and expands on the requirements to cover the for MPLS Networks [RFC4377] and MPLS-TP Networks
modifications necessary for fault, configuration, performance, and [I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements
security. to cover the modifications necessary for fault, configuration,
performance, and security in a transport network.
The Equipment Management Function (EMF) of a MPLS-TP NE provides the The Equipment Management Function (EMF) of a MPLS-TP Network Element
means through which a management system manages the NE. The (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through
Management Communication Channel (MCC), realized by the G-ACH, which a management system manages the NE. The Management
provides a logical operations channel between NEs for transferring Communication Channel (MCC), realized by the G-ACh, provides a
Management information. For the management interface from a logical operations channel between NEs for transferring Management
management system to a MPLS-TP NE, there is no restriction on which information. For the management interface from a management system
management protocol should be used. It is allowed to provision and to a MPLS-TP NE, there is no restriction on which management protocol
manage an end-to-end connection across a network where some segments should be used. It is used to provision and manage an end-to-end
are create/managed, for examples by Netconf or SNMP and other connection across a network where some segments are create/managed,
segments by XML or CORBA interfaces. It is allowed to run for examples by Netconf or SNMP and other segments by XML or CORBA
maintenance operations on a connection which is independent of the interfaces. Maintenance operations are run on a connection (LSP or
provisioning mechanism. An MPLS-TP NE is not required to offer more PW) in a manner that is independent of the provisioning mechanism.
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 per Section 3.6.
The Fault Management (FM) functions within the EMF of an MPLS-TP NE 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
per Section 3.9.
Fault Management (FM) functions within the EMF of an MPLS-TP NE
enable the supervision, detection, validation, isolation, correction, enable the supervision, detection, validation, isolation, correction,
and alarm handling of abnormal operation of the MPLS-TP network and and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. Supervision for transmission (such as continuity, its environment. FM must provide for the supervision of transmission
connectivity, etc.), software processing, hardware, and environment (such as continuity, connectivity, etc.), software processing,
are essential for FM. Alarm handling includes alarm severity hardware, and environment. Alarm handling includes alarm severity
assignment, alarm suppression/aggregation/correlation, alarm assignment, alarm suppression/aggregation/correlation, alarm
reporting control, and alarm reporting. reporting control, and alarm reporting.
Configuration Management (CM) provides functions to exercise control Configuration Management (CM) provides functions to control,
over, identify, collect data from, and provide data to MPLS-TP NEs. identify, collect data from, and provide data to MPLS-TP NEs. In
In addition to general configuration for hardware, software addition to general configuration for hardware, software protection
protection switching, alarm reporting control, and date/time setting, switching, alarm reporting control, and date/time setting, the EMF of
the EMF of the MPLS-TP NE also supports the configuration of the MPLS-TP NE also supports the configuration of maintenance entity
maintenance entity identifiers (such as MEP ID and MIP ID). The EMF identifiers (such as MEP ID and MIP ID). The EMF also supports the
also supports configuration of the OAM parameters as part of configuration of OAM parameters as a part of connectivity management
connectivity management to meet specific operational requirements, to meet specific operational requirements. These may specify whether
such as whether one-time on-demand or periodically based on a the operational mode is one-time on-demand or is periodic at a
specified frequency. specified frequency.
The Performance Management (PM) functions within the EMF of an MPLS- The Performance Management (PM) functions within the EMF of an MPLS-
TP NE supports the evaluation and reporting upon the behaviour of the TP NE support the evaluation and reporting of the behaviour of the
equipment, NE, and network with the objective of providing coherent NEs and the network. One particular requirement for PM is to provide
and consistent interpretation of the network behaviour, in particular coherent and consistent interpretation of the network behaviour in a
for hybrid network which consists of multiple transport technologies. hybrid network that uses multiple transport technologies. Packet
Packet loss measurement and delay measurement are collected so that loss measurement and delay measurements may be collected and used to
they can be used to detect performance degradation. Performance detect performance degradation. This is reported via fault
degradation is reported via fault management for corrective actions management to enable corrective actions to be taken (e.g. protection
(e.g. protection switch) and via performance monitoring for Service switching), and via performance monitoring for Service Level
Level Agreement (SLA) verification and billing. The performance data Agreement (SLA) verification and billing. Collection mechanisms for
collection mechanisms should be flexible to be configured to operate performance data should be should be capable of operating on-demand
on-demand or proactively. or proactively.
4. Security Considerations 4. Security Considerations
The introduction of MPLS-TP into transport networks means that the The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS and PWE3 apply to security considerations applicable to both MPLS and PWE3 apply to
those transport networks. Furthermore, when general MPLS networks those transport networks. Furthermore, when general MPLS networks
that utilise functionality outside of the strict MPLS-TP profile are that utilise functionality outside of the strict MPLS-TP profile are
used to support packet transport services, the security used to support packet transport services, the security
considerations of that additional functionality also apply. considerations of that additional functionality also apply.
Specific security considerations for MPLS-TP will be detailed in The security considerations of [RFC3985] and
documents covering specific aspects on the MPLS-TP architecture. [I-D.ietf-pwe3-ms-pw-arch] apply.
Each MPLS-TP solution must specify the addtional security
considerations that apply.
5. IANA Considerations 5. IANA Considerations
IANA considerations resulting from specific elements of MPLS-TP IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that functionality will be detailed in the documents specifying that
functionality. functionality.
This document introduces no additional IANA considerations in itself. This document introduces no additional IANA considerations in itself.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 23, line 5 skipping to change at page 26, line 34
o Italo Busi o Italo Busi
o Hing-Kam Lam o Hing-Kam Lam
o Marc Lasserre o Marc Lasserre
o Vincenzo Sestito o Vincenzo Sestito
o Martin Vigoureux o Martin Vigoureux
o Malcolm Betts
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [G.7710] "ITU-T Recommendation G.7710/
Levels", BCP 14, RFC 2119, March 1997. Y.1701 (07/07), "Common
equipment management function
requirements"", 2005.
[2] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label [I-D.ietf-mpls-cosfield-def] Andersson, L. and R. Asati,
Switching Architecture", RFC 3031, January 2001. "Multi-Protocol Label Switching
(MPLS) label stack entry: "EXP"
field renamed to "Traffic
Class" field",
draft-ietf-mpls-cosfield-def-08
(work in progress),
December 2008.
[3] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge [I-D.ietf-pwe3-ms-pw-arch] Bocci, M. and S. Bryant, "An
(PWE3) Architecture", RFC 3985, March 2005. Architecture for Multi-Segment
Pseudowire Emulation Edge-to-
Edge",
draft-ietf-pwe3-ms-pw-arch-06
(work in progress),
February 2009.
[4] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment [I-D.ietf-pwe3-redundancy] Muley, P. and M. Bocci,
Pseudowire Emulation Edge-to-Edge", "Pseudowire (PW) Redundancy",
draft-ietf-pwe3-ms-pw-arch-05 (work in progress), draft-ietf-pwe3-redundancy-01
(work in progress),
September 2008. September 2008.
[5] Andersson, L. and R. Asati, ""EXP field" renamed to "Traffic [RFC2119] Bradner, S., "Key words for use
Class field"", draft-ietf-mpls-cosfield-def-07 (work in in RFCs to Indicate Requirement
progress), November 2008. Levels", BCP 14, RFC 2119,
March 1997.
[6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., [RFC3031] Rosen, E., Viswanathan, A., and
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol R. Callon, "Multiprotocol Label
Label Switching (MPLS) Support of Differentiated Services", Switching Architecture",
RFC 3270, May 2002. RFC 3031, January 2001.
[7] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, [RFC3032] Rosen, E., Tappan, D., Fedorkow,
D., Li, T., and A. Conta, "MPLS Label Stack Encoding", G., Rekhter, Y., Farinacci, D.,
RFC 3032, January 2001. Li, T., and A. Conta, "MPLS
Label Stack Encoding", RFC 3032,
January 2001.
[8] Vigoureux, M., Bocci, M., Ward, D., Swallow, G., and R. [RFC3270] Le Faucheur, F., Wu, L., Davie,
Aggarwal, "MPLS Generic Associated Channel", B., Davari, S., Vaananen, P.,
draft-bocci-mpls-tp-gach-gal-00 (work in progress), Krishnan, R., Cheval, P., and J.
October 2008. Heinanen, "Multi-Protocol Label
Switching (MPLS) Support of
Differentiated Services",
RFC 3270, May 2002.
[9] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [RFC3471] Berger, L., "Generalized Multi-
Connectivity Verification (VCCV): A Control Channel for Protocol Label Switching (GMPLS)
Pseudowires", RFC 5085, December 2007. Signaling Functional
Description", RFC 3471,
January 2003.
[10] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC3985] Bryant, S. and P. Pate, "Pseudo
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use Wire Emulation Edge-to-Edge
over an MPLS PSN", RFC 4385, February 2006. (PWE3) Architecture", RFC 3985,
March 2005.
[11] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to [RFC4090] Pan, P., Swallow, G., and A.
RSVP-TE for LSP Tunnels", RFC 4090, May 2005. Atlas, "Fast Reroute Extensions
to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[12] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, [RFC4201] Kompella, K., Rekhter, Y., and
"Pseudowire Setup and Maintenance Using the Label Distribution L. Berger, "Link Bundling in
Protocol (LDP)", RFC 4447, April 2006. MPLS Traffic Engineering (TE)",
RFC 4201, October 2005.
[13] Martini, L., Bocci, M., Bitar, N., Shah, H., Aissaoui, M., and [RFC4203] Kompella, K. and Y. Rekhter,
F. Balus, "Dynamic Placement of Multi Segment Pseudo Wires", "OSPF Extensions in Support of
draft-ietf-pwe3-dynamic-ms-pw-08 (work in progress), July 2008. Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4203,
October 2005.
[14] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE [RFC4385] Bryant, S., Swallow, G.,
Extensions in Support of End-to-End Generalized Multi-Protocol Martini, L., and D. McPherson,
Label Switching (GMPLS) Recovery", RFC 4872, May 2007. "Pseudowire Emulation Edge-to-
Edge (PWE3) Control Word for Use
over an MPLS PSN", RFC 4385,
February 2006.
[15] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of [RFC4447] Martini, L., Rosen, E., El-
Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, Aawar, N., Smith, T., and G.
October 2005. Heron, "Pseudowire Setup and
Maintenance Using the Label
Distribution Protocol (LDP)",
RFC 4447, April 2006.
[16] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in [RFC4872] Lang, J., Rekhter, Y., and D.
MPLS Traffic Engineering (TE)", RFC 4201, October 2005. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-
End Generalized Multi-Protocol
Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[17] Muley, P. and M. Bocci, "Pseudowire (PW) Redundancy", [RFC5085] Nadeau, T. and C. Pignataro,
draft-ietf-pwe3-redundancy-01 (work in progress), "Pseudowire Virtual Circuit
September 2008. Connectivity Verification
(VCCV): A Control Channel for
Pseudowires", RFC 5085,
December 2007.
[18] "ITU-T Recommendation G.8131/Y.1382 (02/07) " Linear protection [RFC5307] Kompella, K. and Y. Rekhter,
switching for Transport MPLS (T-MPLS) networks"", 2005. "IS-IS Extensions in Support of
Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 5307,
October 2008.
[19] "ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment [RFC5462] Andersson, L. and R. Asati,
management function requirements"", 2005. "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP"
Field Renamed to "Traffic Class"
Field", RFC 5462, February 2009.
7.2. Informative References [RFC5586] Bocci, M., Vigoureux, M., and S.
Bryant, "MPLS Generic Associated
Channel", RFC 5586, June 2009.
[20] Niven-Jenkins, B., Brungard, D., Betts, M., and N. Sprecher, 7.2. Informative References
"MPLS-TP Requirements",
draft-jenkins-mpls-mpls-tp-requirements-01 (work in progress),
October 2008.
[21] Vigoureux, M., Ward, D., Betts, M., Bocci, M., and I. Busi, [I-D.bryant-filsfils-fat-pw] Bryant, S., Filsfils, C., Drafz,
"Requirements for OAM in MPLS Transport Networks", U., Kompella, V., Regan, J., and
draft-vigoureux-mpls-tp-oam-requirements-01 (work in progress), S. Amante, "Flow Aware Transport
November 2008. of MPLS Pseudowires",
draft-bryant-filsfils-fat-pw-03
(work in progress), March 2009.
[22] Mansfield, S., Lam, K., and E. Gray, "MPLS TP Network [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K.,
Management Requirements", draft-gray-mpls-tp-nm-req-01 (work in Nadeau, T., and G. Swallow, "BFD
progress), October 2008. For MPLS LSPs",
draft-ietf-bfd-mpls-07 (work in
progress), June 2008.
[23] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, "MPLS
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. TP Network Management
Requirements",
draft-ietf-mpls-tp-nm-req-02
(work in progress), June 2009.
[24] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD [I-D.ietf-mpls-tp-oam-framework] Busi, I. and B. Niven-Jenkins,
For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), "MPLS-TP OAM Framework and
June 2008. Overview", draft-ietf-mpls-tp-
oam-framework-00 (work in
progress), March 2009.
[25] Bryant, S., Filsfils, C., and U. Drafz, "Load Balancing Fat [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M.
MPLS Pseudowires", draft-bryant-filsfils-fat-pw-02 (work in Betts, "Requirements for OAM in
progress), July 2008. MPLS Transport Networks", draft-
ietf-mpls-tp-oam-requirements-02
(work in progress), June 2009.
[26] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and [I-D.ietf-mpls-tp-requirements] Niven-Jenkins, B., Brungard, D.,
Overview", draft-busi-mpls-tp-oam-framework-00 (work in Betts, M., Sprecher, N., and S.
progress), October 2008. Ueno, "MPLS-TP Requirements", dr
aft-ietf-mpls-tp-requirements-09
(work in progress), June 2009.
[27] Nadeau, T., Metz, C., Duckett, M., Bocci, M., Balus, F., and L. [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N., Farrel, A., and H.
Martini, "Segmented Pseudo Wire", Shah, "Multiprotocol Label
draft-ietf-pwe3-segmented-pw-09 (work in progress), July 2008. Switching Transport Profile
Survivability Framework", draft-
ietf-mpls-tp-survive-fwk-00
(work in progress), April 2009.
[28] Kumaki, K., "Interworking Requirements to Support Operation of [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Bitar,
MPLS-TE over GMPLS Networks", RFC 5146, March 2008. N., Shah, H., Aissaoui, M., and
F. Balus, "Dynamic Placement of
Multi Segment Pseudo Wires",
draft-ietf-pwe3-dynamic-ms-pw-09
(work in progress), March 2009.
[29] Sprecher, N., Farrel, A., and V. Kompella, "Multiprotocol Label [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz,
Switching Transport Profile Survivability Framework", C., Duckett, M., Bocci, M.,
draft-sprecher-mpls-tp-survive-fwk-00 (work in progress), Balus, F., and M. Aissaoui,
July 2008. "Segmented Pseudowire",
draft-ietf-pwe3-segmented-pw-12
(work in progress), June 2009.
[30] "Draft ITU-T Recommendation G.8132/Y.1382, "T-MPLS shared [RFC4377] Nadeau, T., Morrow, M., Swallow,
protection ring", G., Allan, D., and S.
http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0501/en", 2005. Matsushima, "Operations and
Management (OAM) Requirements
for Multi-Protocol Label
Switched (MPLS) Networks",
RFC 4377, February 2006.
[31] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [RFC4379] Kompella, K. and G. Swallow,
Matsushima, "Operations and Management (OAM) Requirements for "Detecting Multi-Protocol Label
Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, Switched (MPLS) Data Plane
Failures", RFC 4379,
February 2006. February 2006.
[RFC5146] Kumaki, K., "Interworking
Requirements to Support
Operation of MPLS-TE over GMPLS
Networks", RFC 5146, March 2008.
Authors' Addresses Authors' Addresses
Matthew Bocci (editor) Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
United Kingdom United Kingdom
Phone: +44-207-254-5874 Phone: +44-207-254-5874
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
skipping to change at page 26, line 4 skipping to change at page 31, line 15
Authors' Addresses Authors' Addresses
Matthew Bocci (editor) Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
United Kingdom United Kingdom
Phone: +44-207-254-5874 Phone: +44-207-254-5874
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
Stewart Bryant (editor) Stewart Bryant (editor)
Cisco Systems Cisco Systems
250 Longwater Ave 250 Longwater Ave
Reading RG2 6GB Reading RG2 6GB
United Kingdom United Kingdom
Phone: +44-208-824-8828 Phone: +44-208-824-8828
EMail: stbryant@cisco.com EMail: stbryant@cisco.com
Lieven Levrau (editor) Lieven Levrau
Alcatel-Lucent Alcatel-Lucent
7-9, Avenue Morane Sulnier 7-9, Avenue Morane Sulnier
Velizy 78141 Velizy 78141
France France
Phone: +33-6-33-86-1916 Phone: +33-6-33-86-1916
EMail: lieven.levrau@alcatel-lucent.com EMail: lieven.levrau@alcatel-lucent.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 156 change blocks. 
554 lines changed or deleted 809 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/