draft-ietf-mpls-tp-framework-06.txt   draft-ietf-mpls-tp-framework-07.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track S. Bryant, Ed. Intended status: Informational S. Bryant, Ed.
Expires: April 19, 2010 D. Frost Expires: June 25, 2010 D. Frost
Cisco Systems Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
October 16, 2009 L. Berger
LabN
December 22, 2009
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-06 draft-ietf-mpls-tp-framework-07
Abstract
This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched equivalents of traditional circuit-
switched carrier networks. It describes a common set of protocol
functions - the MPLS Transport Profile (MPLS-TP) - that supports the
operational models and capabilities typical of such networks,
including signaled or explicitly provisioned bi-directional
connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration and Maintenance (OAM)
functions, and network operation in the absence of a dynamic control
plane or IP forwarding support. Some of these functions are defined
in existing MPLS specifications, while others require extensions to
existing specifications to meet the requirements of the MPLS-TP.
This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this
document.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 36 skipping to change at page 2, line 21
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 April 19, 2010. This Internet-Draft will expire on June 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies an architectural framework for the described in the BSD License.
application of Multi Protocol Label Switching (MPLS) in transport
networks, by enabling the construction of packet switched equivalents
to traditional circuit switched carrier networks. It describes a
common set of protocol functions - the MPLS Transport Profile
(MPLS-TP) - that supports the operational models and capabilities
typical of such networks for point-to-point paths, including signaled
or explicitly provisioned bi-directional connection-oriented paths,
protection and restoration mechanisms, comprehensive Operations,
Administration and Maintenance (OAM) functions, and network operation
in the absence of a dynamic control plane or IP forwarding support.
Some of these functions exist in existing MPLS specifications, while
others require extensions to existing specifications to meet the
requirements of the MPLS-TP.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Although this document is not a protocol specification, these key
words 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Background . . . . . . . . . . . . . . . . 4 1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. MPLS Transport Profile. . . . . . . . . . . . . . . . 6 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6
1.3.2. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 6 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Label Switched Path . . . . . . . . . . . . . 6 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switching Router (LSR) and Label 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router (LSR) and Label
Edge Router (LER) . . . . . . . . . . . . . . . . . . 7 Edge Router (LER) . . . . . . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Customer Edge (CE) . . . . . . . . . . . . . . 8 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8
1.3.6. Additional Definitions and Terminology . . . . . . . . 8 1.3.7. Additional Definitions and Terminology . . . . . . . . 8
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
2. Introduction to Requirements . . . . . . . . . . . . . . . . . 10 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 11 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 11 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of MPLS Transport Profile . . . . . . . . . . . . . 12 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Adaptation . . . . . . . . . . . . . . . . . . 13 3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 13 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Client Adaptation . . . . . . . . . . . . . . . . 15 3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16
3.4.1. Adaptation using Pseudowires . . . . . . . . . . . . . 15 3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17
3.4.2. Network Layer Clients . . . . . . . . . . . . . . . . 18 3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 17
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 20
3.6. Operations, Administration and Maintenance (OAM) . . . . . 22 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.1. OAM Architecture . . . . . . . . . . . . . . . . . . . 22 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 24
3.6.2. OAM Functions . . . . . . . . . . . . . . . . . . . . 25 3.7. Operations, Administration and Maintenance (OAM) . . . . . 27
3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 26 3.7.1. OAM Architecture . . . . . . . . . . . . . . . . . . . 28
3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 29 3.7.2. OAM Functions . . . . . . . . . . . . . . . . . . . . 31
3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 31 3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 32
3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 31 3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 34
3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 32 3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 34
3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 32 3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35
3.11. Network Management . . . . . . . . . . . . . . . . . . . . 33 3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 35
4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 3.11. Network Management . . . . . . . . . . . . . . . . . . . . 37
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 4. Security Considerations . . . . . . . . . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Normative References . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
1.1. Motivation and Background 1.1. Motivation and Background
This document describes a framework for a Multiprotocol Label This document describes an architectural framework for the
Switching Transport Profile (MPLS-TP). It presents the architectural application of MPLS to the construction of packet-switched transport
framework for MPLS-TP, defining those elements of MPLS applicable to networks. It specifies the common set of protocol functions that
supporting the requirements in [RFC5654] and what new protocol meet the requirements in [RFC5654], and that together constitute the
elements are required. MPLS Transport Profile (MPLS-TP) for point-to-point paths. The
remaining MPLS-TP functions, applicable specifically to point-to-
multipoint paths, are out of scope of this document.
Historically the optical transport infrastructure (Synchronous Historically the optical transport infrastructure - Synchronous
Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH), Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical
Optical Transport Network (OTN)) has provided carriers with a high Transport Network (OTN) - has provided carriers with a high benchmark
benchmark for reliability and operational simplicity. To achieve for reliability and operational simplicity. To achieve this,
this transport technologies have been designed with specific transport technologies have been designed with specific
characteristics : characteristics:
o Strictly connection-oriented connectivity, which may be long-lived o Strictly connection-oriented connectivity, which may be long-lived
and may be provisioned manually or by network management. and may be provisioned manually (i.e. configuration of the node
via a command line interface) or by network management.
o A high level of protection and availability. o A high level of availability.
o Quality of service. o Quality of service.
o Extended OAM capabilities. o Extensive OAM capabilities.
Carriers wish to evolve such transport networks to support packet
based services, 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 Carriers wish to evolve such transport networks to take advantage of
networks are very similar to Layer 2 Virtual Private Networks defined the flexibility and cost benefits of packet switching technology and
by the IETF. to support packet based services more efficiently. While MPLS is a
maturing packet technology that already plays an important role in
transport networks and services, not all MPLS capabilities and
mechanisms are needed in or consistent with the transport network
operational model. There are also transport technology
characteristics that are not currently reflected in MPLS.
There are thus two objectives for MPLS-TP: 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.
In order to achieve these objectives, there is a need to create a In order to achieve these objectives, there is a need to define a
common set of new functions that are applicable to both MPLS networks common set of MPLS protocol functions - an MPLS Transport Profile -
in general, and those belonging to the MPLS-TP profile. for the use of MPLS in transport networks and applications. Some of
the necessary functions are provided by existing MPLS specifications,
while others require additions to the MPLS tool-set. Such additions
should, wherever possible, be applicable to MPLS networks in general
as well as those that conform strictly to the transport network
model.
MPLS-TP therefore defines a profile of MPLS targeted at transport This document is a product of a joint Internet Engineering Task Force
applications and networks. This profile specifies the specific MPLS (IETF) / International Telecommunications Union Telecommunications
characteristics and extensions required to meet transport Standardization Sector (ITU-T) effort to include an MPLS Transport
requirements. Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.
1.2. Scope 1.2. Scope
This document describes an architectural framework for the This document describes an architectural framework for the
application of MPLS to transport networks. It specifies the common application of MPLS to the construction of packet-switched transport
set of protocol functions that meet the requirements in [RFC5654], networks. It specifies the common set of protocol functions that
and that together constitute the MPLS Transport Profile (MPLS-TP). meet the requirements in [RFC5654], and that together constitute the
The architecture for point-to-point MPLS-TP paths is described. The MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport
architecture for point-to-multipoint paths is outside the scope of paths. The remaining MPLS-TP functions, applicable specifically to
this document. point-to-multipoint transport paths, are out of scope of this
document.
1.3. Terminology 1.3. 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, Administration and Maintenance OAM Operations, Administration and Maintenance
G-ACh Generic Associated Channel 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
LSR Label Switch Router. LSR Label Switching Router
MPLS-TP PE MPLS-TP Provider Edge MPLS-TP PE MPLS-TP Provider Edge LSR
MPLS-TP P Router An MPLS-TP Provider (P) router MPLS-TP P MPLS-TP Provider LSR
PW Pseudowire PW Pseudowire
Adaptation The mapping of client information into a format suitable
for transport by the server layer
Native The traffic belonging to the client of the MPLS-TP network
Service
T-PE PW Terminating Provider Edge
S-PE PW Switching provider Edge
1.3.1. MPLS Transport Profile. 1.3.1. Transport Network
A Transport Network provides transparent transmission of client user
plane traffic between attached client devices by establishing and
maintaining point-to-point or point-to-multipoint connections between
such devices. The architecture of networks supporting point to
multipoint connections is out of scope of this document. A Transport
Network is independent of any higher-layer network that may exist
between clients, except to the extent required to supply this
transmission service. In addition to client traffic, a Transport
Network may carry traffic to facilitate its own operation, such as
that required to support connection control, network management, and
Operations, Administration and Maintenance (OAM) functions.
See also the definition of Packet Transport Service in Section 3.1.
1.3.2. MPLS Transport Profile
The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions
that meet the requirements in [RFC5654]. Note that MPLS is defined that meet the requirements in [RFC5654]. Note that MPLS is defined
to include any present and future MPLS capability specified by the to include any present and future MPLS capability specified by the
IETF, including those capabilities specifically added to support the IETF, including those capabilities specifically added to support
transport network requirement [RFC5654]. transport network requirements [RFC5654].
1.3.2. MPLS-TP Section 1.3.3. MPLS-TP Section
An MPLS-TP Section is defined in Section 1.1.2 of [RFC5654]. An MPLS-TP Section is defined in Section 1.2.2 of [RFC5654].
1.3.3. MPLS-TP Label Switched Path 1.3.4. MPLS-TP Label Switched Path
An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a
subset of the capabilities of an MPLS LSP in order to meet the subset of the capabilities of an MPLS LSP in order to meet the
requirements of an MPLS transport network as set out in [RFC5654]. requirements of an MPLS transport network as set out in [RFC5654].
The characteristics of an MPLS-TP LSP are primarily that it: The characteristics of an MPLS-TP LSP are primarily that it:
1. Uses a subset of the MPLS OAM tools defined as described in 1. Uses a subset of the MPLS OAM tools defined as described in
[I-D.ietf-mpls-tp-oam-framework]. [I-D.ietf-mpls-tp-oam-framework].
2. Supports only 1+1, 1:1, and 1:N protection functions. 2. Supports 1+1, 1:1, and 1:N protection functions.
3. Is traffic engineered. 3. Is traffic engineered.
4. Is established and maintained using GMPLS protocols when a 4. May be established and maintained via the management plane, or
control plane is used. using GMPLS protocols when a control plane is used.
5. LSPs can only be point to point or point to multipoint, i.e. the 5. Is either point-to-point or point-to-multipoint. Multipoint to
merging of LSPs is not permitted. point and multipoint to multipoint LSPs are not permitted.
Note that an MPLS LSP is defined to include any present and future Note that an MPLS LSP is defined to include any present and future
MPLS capability include those specifically added to support the MPLS capability, including those specifically added to support the
transport network requirements. transport network requirements.
1.3.4. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER) 1.3.5. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER)
An MPLS-TP Label Switching Router (MPLS-TP LSR) is either an MPLS-TP Editor's Note: These terms are here for clarity - but this is not the
Provider Edge (MPLS-TP PE) or an MPLS-TP Provider (MPLS-TP P Router) authoritative definition - (need to find a definition)
router for a given LSP, as defined below. The terms MPLS-TP PE and
MPLS-TP P router describe functions and specific node may undertake An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider
both roles. Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP,
as defined below. The terms MPLS-TP PE router and MPLS-TP P router
describe logical functions; a specific node may undertake only one of
these roles on a given LSP.
Note that the use of the term "router" in this context is historic Note that the use of the term "router" in this context is historic
and neither requires nor precludes the ability to perform IP and neither requires nor precludes the ability to perform IP
forwarding. forwarding.
1.3.4.1. MPLS-TP Provider Edge Router (PE) 1.3.5.1. MPLS-TP Provider Edge (PE) Router
An MPLS-TP Provider Edge Router is an MPLS-TP LSR that adapts client An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts
traffic and encapsulates it to be carried over an MPLS-TP LSP. client traffic and encapsulates it to be transported over an MPLS-TP
Encapsulation may be as simple as pushing a label, or it may require LSP. Encapsulation may be as simple as pushing a label, or it may
the use of a pseudowire. An MPLS-TP PE exists at the interface require the use of a pseudowire. An MPLS-TP PE exists at the
between a pair of layer networks. For an MS-PW, an MPLS-TP PE may be interface between a pair of layer networks. For an MS-PW, an MPLS-TP
either an S-PE or a T-PE. PE may be either an S-PE or a T-PE, as defined in [RFC5659].
A layer network is defined in [G.805]. A layer network is defined in [G.805].
1.3.4.2. MPLS-TP Provider Router (P) 1.3.5.2. MPLS-TP Provider (P) Router
An MPLS-TP Provider router is an MPLS-TP LSR that does not provide An MPLS-TP Provider router is an MPLS-TP LSR that does not provide
MPLS-TP PE functionality. An MPLS-TP P router switches LSPs which MPLS-TP PE functionality for a given LSP. An MPLS-TP P router
carry client traffic, but do not adapt the client traffic and switches LSPs which carry client traffic, but does not adapt client
encapsulate it to be carried over an MPLS-TP LSP. traffic and encapsulate it to be carried over an MPLS-TP LSP.
1.3.5. MPLS-TP Customer Edge (CE) 1.3.6. Customer Edge (CE)
An MPLS-TP Customer Edge is the client function sourcing or sinking A Customer Edge (CE) is the client function sourcing or sinking
client traffic to or from the MPLS-TP network. CEs on either side of native service traffic to or from the MPLS-TP network. CEs on either
the MPLS-TP network are peers and view the MPLS-TP network as a side of the MPLS-TP network are peers and view the MPLS-TP network as
single point to point or point to multi-point link. These clients a single point-to-point or point-to-multipoint link.
have no knowledge of the presence of the interveining MPLS-TP
network.
1.3.6. Additional Definitions and Terminology 1.3.7. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in Detailed definitions and additional terminology may be found in
[RFC5654]. [RFC5654].
1.4. Applicability 1.4. Applicability
MPLS-TP can be used to construct a packet transport networks and is MPLS-TP can be used to construct packet transport networks and is
therefore applicable in any packet transport network application. It therefore applicable in any packet transport network context. It is
is also as an alternative architecture for subsets of a packet also applicable to subsets of a packet network where the transport
network where the transport network model is deemed attractive. The network operational model is deemed attractive. The following are
following are examples of MPLS-TP applicability models: examples of MPLS-TP applicability models:
1. MPLS-TP provided by a network that only supports MPLS-TP, acting 1. MPLS-TP provided by a network that only supports MPLS-TP LSPs and
as a server for other layer 1, layer 2 and layer 3 networks PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or
(Figure 1). LSRs), acting as a server for other layer 1, layer 2 and layer 3
networks (Figure 1).
2. MPLS-TP provided by a network that also supports non-MPLS-TP 2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs
functions, acting as a server for other layer 1, layer 2 and and PWs (i.e. both LSPs and PWs that conform to the transport
layer 3 networks (Figure 2). profile and those that do not, exist between the PEs), acting as
a server for other layer 1, layer 2 and layer 3 networks
(Figure 2).
3. MPLS-TP as a server layer for client layer traffic of IP or MPLS 3. MPLS-TP as a server layer for client layer traffic of IP or MPLS
networks which do not use functions of the MPLS transport profile networks which do not use functions of the MPLS transport
(Figure 3). profile. For MPLS traffic, the MPLS-TP server layer network uses
PW switching or LSP stitching at the PE that terminates the
MPLS-TP server layer (Figure 3). - See notes in word document -
ref = rfc5150
These models are not mutually exclusive. These models are not mutually exclusive.
MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as a server MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as
for other layer 1, layer 2 and layer 3 networks. a server for other layer 1, layer 2 and layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->| |<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->|
Only Only
MPLS-TP MPLS-TP
+---+ LSP +---+ +---+ LSP +---+
+---+ Client | |----------| | Client +---+ +---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1| |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+ +---+ | |----------| | +---+
+---+ +---+ +---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet] Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ] layering [ PW ]
[-TP LSP ] [-TP LSP ]
b) [ IP ] [ IP ] [ IP ] b) [ IP ] [ IP ] [ IP ]
[ LSP ] [ Demux ]
[-TP LSP ] [-TP LSP ]
Figure 1: MPLS-TP Server Layer Example Figure 1: MPLS-TP Server Layer Example
MPLS-TP LSP, provided by a network that also supports non-MPLS-TP functions, MPLS-TP LSP, provided by a network that also supports non-MPLS-TP
acting as a server for other layer 1, layer 2 and layer 3 networks. functions, acting as a server for other layer 1, layer 2 and
layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->| |<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->|
MPLS-TP MPLS-TP
+---+ LSP +---+ +---+ LSP +---+
+---+ Client | |----------| | Client +---+ +---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1| |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+ +---+ | |----------| | +---+
+---+ +---+ +---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet] Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ] layering [ PW ]
[-TP LSP ] [-TP LSP ]
b) [ IP ] [ IP ] [ IP ] b) [ IP ] [ IP ] [ IP ]
[ LSP ] [ Demux ]
[-TP LSP ] [-TP LSP ]
Figure 2: MPLS-TP in MPLS Network Example Figure 2: MPLS-TP in MPLS Network Example
MPLS-TP as a server layer for client layer traffic of IP or MPLS networks which MPLS-TP as a server layer for client layer traffic of IP or MPLS
do not use functions of the MPLS transport profile. networks which do not use functions of the MPLS transport
profile.
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
Only Only
+---+ +---+ Non-TP +---+ MPLS-TP +---+ Non-TP +---+ +---+ +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+
|CE1|---|PE1|====LSP===|PE2|====LSP===|PE3|====LSP===|PE4|-----|CE2| |CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +----+ +----+ +----+ +----+ +---+
(PW switching) (PW switching)
(a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ] (a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ]
[ MS-PW ] [ MS-PW ] [ MS-PW ] [PW Seg't] [PW Seg't] [PW Seg't]
[ LSP ] [-TP LSP ] [ LSP ] [ LSP ] [-TP LSP ] [ LSP ]
(a) [ IP ] [ IP ] [ IP ] [ IP ] [ IP ] |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
[ LSP ] [-TP LSP ] [ LSP ] Only
Figure 3: MPLS-TP Transporting Client Service Traffic +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+
|CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2|
+---+ +----+ +----+ +----+ +----+ +---+
(LSP stitching) (LSP stitching)
2. Introduction to Requirements (b) [ IP ] [ IP ] [ IP ] [ IP ] [ IP ]
[ LSP ] [-TP LSP ] [ LSP ]
Figure 3: MPLS-TP Transporting Client Service Traffic
2. MPLS Transport Profile Requirements
The requirements for MPLS-TP are specified in [RFC5654], The requirements for MPLS-TP are specified in [RFC5654],
[I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req]. [I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req].
This section provides a brief reminder to guide the reader and is This section provides a brief reminder to guide the reader and is
therefore not normative. It is not intended as a substitute for therefore not normative. It is not intended as a substitute for
these documents. these documents.
MPLS-TP must not modify the MPLS forwarding architecture and must be MPLS-TP must not modify the MPLS forwarding architecture and must be
based on existing pseudowire and LSP constructs. based on existing pseudowire and LSP constructs.
skipping to change at page 11, line 7 skipping to change at page 12, line 19
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. MPLS Transport Profile Overview
3.1. Packet Transport Services 3.1. Packet Transport Services
One objective of MPLS-TP is to enable MPLS networks to provide packet One objective of MPLS-TP is to enable MPLS networks to provide packet
transport services with a similar degree of predictability to that transport services with a similar degree of predictability to that
found in existing transport networks. Such packet transport services found in existing transport networks. Such packet transport services
inherit a number of characteristics, defined in [RFC5654]: inherit a number of characteristics, defined in [RFC5654]:
o In an environment where an MPLS-TP layer network is supporting a o In an environment where an MPLS-TP layer network is supporting a
client layer network, and the MPLS-TP layer network is supported client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer by a server layer network then operation of the MPLS-TP layer
network MUST be possible without any dependencies on the server or network must be possible without any dependencies on either the
client layer network. server or client layer network.
o The service provided by the MPLS-TP network to the client is o The service provided by the MPLS-TP network to the client is
guaranteed not to fall below the agreed level regardless of other guaranteed not to fall below the agreed level regardless of other
client activity. client activity.
o The control and management planes of any client network layer that o The control and management planes of any client network layer that
uses the service is isolated from the control and management uses the service is isolated from the control and management
planes of the MPLS-TP layer network. planes of the MPLS-TP layer network, where the client network
layer is considered to be the native service of the MPLS-TP
network.
o Where a client network makes use of an MPLS-TP server that o Where a client network makes use of an MPLS-TP server that
provides a packet transport service, the level of co-ordination provides a packet transport service, the level of co-ordination
required between the client and server layer networks is minimal required between the client and server layer networks is minimal
(preferably no co-ordination will be required). (preferably no co-ordination will be required).
o The complete set of packets generated by a client MPLS(-TP) layer o The complete set of packets generated by a client MPLS(-TP) layer
network using the packet transport service, which may contain network using the packet transport service, which may contain
packets that are not MPLS packets (e.g. IP or CNLS packets used packets that are not MPLS packets (e.g. IP or CNLS packets used
by the control/management plane of the client MPLS(-TP) layer by the control/management plane of the client MPLS(-TP) layer
network), are transported by the MPLS-TP server layer network. network), are transported by the MPLS-TP server layer network.
o The packet transport service enables the MPLS-TP layer network o The packet transport service enables the MPLS-TP layer network
addressing and other information (e.g. topology) to be hidden from addressing and other information (e.g. topology) to be hidden from
any client layer networks using that service, and vice-versa. any client layer networks using that service, and vice-versa.
Therefore, a packet transport service doe not support a These characteristics imply that a packet transport service does not
connectionless packet switched forwarding mode. However, this does support a connectionless packet-switched forwarding mode. However,
not preclude it carrying client traffic associated with a this does not preclude it carrying client traffic associated with a
connectionless service. connectionless service.
3.2. Scope of MPLS Transport Profile Such packet transport services are very similar to Layer 2 Virtual
Private Networks as defined by the IETF.
3.2. Scope of the MPLS Transport Profile
Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are
primarily intended for packet transport applications. MPLS-TP is a primarily intended for packet transport applications. MPLS-TP is a
strict sub-set of MPLS, and comprises those functions that meet the strict subset of MPLS, and comprises only those functions that are
requirements of [RFC5654]. This includes MPLS functions that were necessary to meet the requirements of [RFC5654]. This includes MPLS
defined prior to [RFC5654] but that meet the requirements of functions that were defined prior to [RFC5654] but that meet the
[RFC5654], together with additional functions defined to meet those requirements of [RFC5654], together with additional functions defined
requirements. Some MPLS functions defined before [RFC5654] e.g. to meet those requirements. Some MPLS functions defined before
Equal Cost Multi-Path, LDP signaling used in such a way that it [RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a
creates multi-point to point LSPs, and IP forwarding in the data way that it creates multipoint-to-point LSPs, and IP forwarding in
plane are explicitly excluded from MPLS-TP by that requirements the data plane are explicitly excluded from MPLS-TP by that
specification. requirements specification.
Note that this does not preclude the future definition of MPLS Note that MPLS as a whole will continue to evolve to include
functions that do not meet the requirements of [RFC5654] and thus additional functions that do not conform to the MPLS Transport
fall outside the scope of MPLS-TP as defined by this document. Profile or its requirements, and thus fall outside the scope of
MPLS-TP.
{Additional Transport Functions}
|<============== MPLS-TP ==================>|
{ ECMP, mp2p LDP, IP fwd }
|<====== Pre-RFC5654 MPLS ===========>|
|<============================== MPLS ==============================>| |<============================== MPLS ==============================>|
|<============= Pre-RFC5654 MPLS ================>|
{ ECMP }
{ LDP/non-TE LSPs }
{ IP fwd }
|<================ MPLS-TP ====================>|
{ Additional }
{ Transport }
{ Functions }
Figure 4: Scope of MPLS-TP Figure 4: Scope of MPLS-TP
3.3. Architecture 3.3. Architecture
MPLS-TP comprises the following MPLS-TP comprises the following architectural elements:
o Sections, LSPs and PWs that provide a packet transport service for o Sections, LSPs and PWs that provide a packet transport service for
a client network. a client network.
o Proactive and on demand Operations Administration and Maintenance o Proactive and on-demand Operations, Administration and Maintenance
(OAM) functions to monitor and diagnose the MPLS-TP network. e.g. (OAM) functions to monitor and diagnose the MPLS-TP network, such
connectivity check, connectivity verification, and performance as connectivity check, connectivity verification, performance
monitoring. monitoring and fault localisation.
o Optional control planes for LSPs and PWs, as well as static o Optional control planes for LSPs and PWs, as well as support for
configuration. static provisioning and configuration.
o Path protection mechanisms to ensure that the packet transport o Optional path protection mechanisms to ensure that the packet
service survives anticipated failures and degradations of the transport service survives anticipated failures and degradations
MPLS-TP network. of the MPLS-TP network.
o Network management functions. o Network management functions.
The MPLS-TP architecture for LSPs and PWs includes the the following The MPLS-TP architecture for LSPs and PWs includes the following two
two sets of functions: sets of functions:
o MPLS-TP adaptation o MPLS-TP client adaptation
o MPLS-TP forwarding o MPLS-TP forwarding
The adaptation functions interface the client service to MPLS-TP. The adaptation functions interface the native service to MPLS-TP.
This includes the case where the client service is an MPLS-TP LSP. This includes the case where the native service is an MPLS-TP LSP.
The forwarding functions comprise the mechanisms required for The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client over an MPLS-TP server layer forwarding the encapsulated client traffic over an MPLS-TP server
network E.g. PW label and LSP label. layer network, for example PW and LSP labels.
3.3.1. MPLS-TP Adaptation 3.3.1. MPLS-TP Client Adaptation Functions
The MPLS-TP adaptation interfaces the client service to MPLS-TP. For The MPLS-TP native service adaptation functions interface the client
pseudowires, these adaptation functions are the payload encapsulation service to MPLS-TP. For pseudowires, these adaptation functions are
shown in Figure 7 of [RFC3985] and Figure 7 of the payload encapsulation described in Section 4.4 of [RFC3985] and
[I-D.ietf-pwe3-ms-pw-arch]. For network layer client services, the Section 6 of [RFC5659]. For network layer client services, the
adaptation function uses the MPLS encapsulation format as defined in adaptation function uses the MPLS encapsulation format as defined in
RFC 3032[RFC3032]. [RFC3032].
The purpose of this encapsulation is to abstract the client service The purpose of this encapsulation is to abstract the client service
data plane from the MPLS-TP data plane, thus contributing to the data plane from the MPLS-TP data plane, thus contributing to the
independent operation of the MPLS-TP network. independent operation of the MPLS-TP network.
MPLS-TP is itself a client of an underlying server layer. MPLS-TP is MPLS-TP is itself a client of an underlying server layer. MPLS-TP is
thus also bounded by a set of adaptation functions to this server thus also bounded by a set of adaptation functions to this server
layer network, which may itself be MPLS-TP. These adaptation layer network, which may itself be MPLS-TP. These adaptation
functions provide encapsulation of the MPLS-TP frames and for the functions provide encapsulation of the MPLS-TP frames and for the
transparent transport of those frames over the server layer network. transparent transport of those frames over the server layer network.
The MPLS-TP client inherits its QoS from the MPLS-TP network, which The MPLS-TP client inherits its Quality of Service (QoS) from the
in turn inherits its QoS from the server layer. The server layer MPLS-TP network, which in turn inherits its QoS from the server
must therefore provide the necessary Quality of Service (QoS) to layer. The server layer must therefore provide the necessary QoS to
ensure that the MPLS-TP client QoS commitments are satisfied. ensure that the MPLS-TP client QoS commitments can be satisfied.
3.3.2. MPLS-TP Forwarding Functions 3.3.2. MPLS-TP Forwarding Functions
The forwarding functions comprise the mechanisms required for The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client over an MPLS-TP server layer forwarding the encapsulated client over an MPLS-TP server layer
network E.g. PW label and LSP label. network, for example PW and LSP labels.
MPLS-TP LSPs use the MPLS label switching operations and TTL MPLS-TP LSPs use the MPLS label switching operations and TTL
processing procedures defined in [RFC3031] and [RFC3032]. These processing procedures defined in [RFC3031] and [RFC3032]. These
operations are highly optimized for performance and are not modified operations are highly optimised for performance and are not modified
by the MPLS-TP profile. by the MPLS-TP profile.
In addition, MPLS-TP PWs use the PW and MS-PW forwarding operations In addition, MPLS-TP PWs use the SS-PW and MS-PW forwarding
defined in[RFC3985] and [I-D.ietf-pwe3-ms-pw-arch]. The PW label is operations defined in [RFC3985] and [RFC5659]. The PW label is
processed by a PW forwarder and is always at the bottom of the label processed by a PW forwarder and is always at the bottom of the label
stack for a given MPLS-TP layer network. stack for a given MPLS-TP layer network.
Per-platform label space is used for PWs. Either per-platform, per- Per-platform label space is used for PWs. Either per-platform, per-
interface or other context-specific label space may be used for LSPs. interface or other context-specific label space [RFC5331] may be used
for LSPs.
MPLS-TP forwarding is based on the label that identifies the MPLS-TP forwarding is based on the label that identifies the
transport path (LSP or PW). The label value specifies the processing transport path (LSP or PW). The label value specifies the processing
operation to be performed by the next hop at that level of operation to be performed by the next hop at that level of
encapsulation. A swap of this label is an atomic operation in which 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 the contents of the packet after the swapped label are opaque to the
forwarder. The only event that interrupts a swap operation is TTL forwarder. The only event that interrupts a swap operation is TTL
expiry. This is a fundamental architectural construct of MPLS to be expiry. This is a fundamental architectural construct of MPLS to be
taken into account when design protocol extensions that requires taken into account when designing protocol extensions that require
packets (e.g. OAM packets) to be sent to an intermediate LSR. packets (e.g. OAM packets) to be sent to an intermediate LSR.
Further processing to determine the context of a packet occurs when a Further processing to determine the context of a packet occurs when a
swap operation is interrupted in this manner, or a pop operation swap operation is interrupted in this manner, or a pop operation
exposes a specific reserved label at the top of the stack. Otherwise exposes a specific reserved label at the top of the stack. Otherwise
the packet is forwarded according to the procedures in [RFC3032]. the packet is forwarded according to the procedures in [RFC3032].
Point to point MPLS-TP LSPs can be either unidirectional or Point-to-point MPLS-TP LSPs can be either unidirectional or
bidirectional. bidirectional.
It MUST be possible to configure an MPLS-TP LSP such that the forward 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 and backward directions of a bidirectional MPLS-TP LSP are co-routed,
i.e. they follow the same path. The pairing relationship between the i.e. follow the same path. The pairing relationship between the
forward and the backward directions must be known at each LSR or LER forward and the backward directions must be known at each LSR or LER
on a bidirectional LSP. on a bidirectional LSP.
In normal conditions, all the packets sent over a PW or an LSP follow In normal conditions, all the packets sent over a PW or an LSP follow
the same path through the network and those that belong to a common the same path through the network and those that belong to a common
ordered aggregate are delivered in order. For example per-packet ordered aggregate are delivered in order. For example per-packet
equal cost multi-path (ECMP) load balancing is not applicable to equal cost multi-path (ECMP) load balancing is not applicable to
MPLS-TP LSPs. MPLS-TP LSPs.
Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default. 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 MPLS-TP supports Quality of Service capabilities via the MPLS
[RFC3270]. Differentiated Services (DiffServ) architecture [RFC3270]. Both
E-LSP and L-LSP MPLS DiffServ modes are supported. The Traffic Class
The Traffic Class field (formerly the MPLS EXP field) follows the field (formerly the EXP field) of an MPLS label follows the
definition and processing rules of [RFC5462] and [RFC3270]. definition and processing rules of [RFC5462] and [RFC3270]. Note
that packet reordering between flows belonging to different traffic
classes may occur if more than one traffic class is supported on a
single LSP.
Only the pipe and short-pipe models are supported in MPLS-TP. Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing
models described in [RFC3270] and [RFC3443] are supported in MPLS-TP.
3.4. MPLS-TP Client Adaptation 3.4. MPLS-TP Native Services
This document specifies the architecture for two types of client This document specifies the architecture for two types of native
adaptation: service adaptation:
o A PW o A PW: PW Demultiplexer and PW encapsulation
o An MPLS Label o An MPLS Label
When the client is a PW, the MPLS-TP client adaptation functions A PW can carry any emulated service defined by the IETF to be
include the PW encapsulation mechanisms, including the PW control provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A
word. When the client is operating at the network layer the registry of PW types is maintained by IANA. When the client
mechanism described in Section 3.4.2 is used. adaptation is via a PW, the mechanisms described in Section 3.4.2 are
used.
3.4.1. Adaptation using Pseudowires An MPLS LSP Label can also be used as the adaptation, in which case
any network layer client supported by MPLS is allowed, for example an
MPLS LSP, PW, or IP. When the client adaptation is via an MPLS
label, the mechanisms described in Section 3.4.3 are used.
The architecture for a transport profile of MPLS (MPLS-TP) that uses 3.4.1. MPLS-TP Client/Server Relationship
PWs is based on the MPLS [RFC3031] and pseudowire [RFC3985]
architectures. If multi-segment pseudowires are used to provide a
packet transport service, motivated by, for example, the requirements
specified in [RFC5254] then the MS-PW architecture
[I-D.ietf-pwe3-ms-pw-arch] also applies.
Figure 5 shows the architecture for an MPLS-TP network using single- The relationship of MPLS-TP to its clients is illustrated in
Figure 5.
PW-Based MPLS Labelled
Services Services
Emulated PW LSP IP
Service
+------------+
| PW Payload |
+------------+ +------------+ +------------+ (CLIENTS)
| PW Payload | |PW Lbl(S=1) | | IP |
~~~~~~~~~~~~~~~~~ +------------+ +------------+ +------------+
|PW Lbl (S=1)| | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
+------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
(MPLS-TP)
~~~~~~~~~~~ = Client - MPLS-TP layer boundary
Figure 5: MPLS-TP - Client Relationship
The data plane behaviour of MPLS-TP is the same as the best current
practise for MPLS. This includes the setting of the S-Bit. In each
case, the S-bit is set to indicate the bottom (i.e. inner-most) label
in the label stack that is contiguous between the MPLS-TP server and
the client layer.
Note that this best current practise differs slightly from [RFC3032]
which uses the S-bit to identify when MPLS label processing stops and
network layer processing starts.
Note that the label stacks shown above are those inside MPLS-TP
network. They illustrate the smallest number of labels possible.
These label stacks could also include more labels.
3.4.2. Pseudowire Adaptation
The architecture for an MPLS-TP client adaptation that uses PWs is
based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures.
If multi-segment pseudowires are used to provide a packet transport
service, motivated by, for example, the requirements specified in
[RFC5254], then the MS-PW architecture [RFC5659] also applies.
Figure 6 shows the architecture for an MPLS-TP network using single-
segment PWs. segment PWs.
|<-------------- Emulated Service ---------------->| |<--------------- Emulated Service ----------------->|
| | | |
| |<------- Pseudowire ------->| | | |<-------- Pseudowire -------->| |
| | encapsulated | | | | encapsulated packet | |
| | Pkt Xport Service | | | | transport service | |
| | | | | | | |
| | |<-- PSN Tunnel -->| | | | | |<------ LSP ------->| | |
| V V V V | | V V V V |
V AC +----+ +---+ +----+ AC V V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|======:=X=:=======| PE2| | +-----+ +-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|...........:PW1:............|----------| | | |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | : | | | | CE2 | | CE1 | | | | | X | | | | | CE2 |
| |----------|...........:PW2:............|----------| | | |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |======:=X=:=======| | | ^ +-----+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ +---+ +----+ | | ^ ^ | +----+ +-----+ +----+ | ^
| | Provider Edge 1 ^ Provider Edge 2 | | | | Provider Edge 1 ^ Provider Edge 2 | |
| | | | | | | | | |
Customer | P Router | Customer Customer | P Router | Customer
Edge 1 | | Edge 2 Edge 1 | | Edge 2
| | | |
| | | |
Native service Native service Native service Native service
Figure 5: MPLS-TP Architecture (Single Segment PW) Figure 6: MPLS-TP Architecture (Single Segment PW)
Figure 6 shows the architecture for an MPLS-TP network when multi- Figure 7 shows the architecture for an MPLS-TP network when multi-
segment pseudowires are used. Note that as in the SS-PW case, segment pseudowires are used. Note that as in the SS-PW case,
P-routers may also exist. P-routers may also exist.
|<-------------------Pseudowire-------------------->| |<----------- Pseudowire encapsulated ------------->|
| encapsulated | | packet transport service |
| Pkt Xport Service |
| | | |
| PSN | | |
AC | |<------- PSN tun1------>| |<--tun2-->| | AC | |
AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC
| V V V V V V | | V V V V V V |
| +----+ +-----+ +----+ +----+ | | +----+ +-----+ +----+ +----+ |
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |---|......PW.Seg't1... | \ / | ......X...PW.Seg't3.....|---| | | |---|......PW.Seg't1... | \ / | ......X...PW.Seg't3.....|---| |
|CE1| | | | | X | | | | | | |CE2| |CE1| | | | | X | | | | | | |CE2|
| |---|......PW.Seg't2... | / \ | ......X...PW.Seg't4.....|---| | | |---|......PW.Seg't2... | / \ | ......X...PW.Seg't4.....|---| |
+---+ | | |===============/ \=====| |==========| | | +---+ +---+ | | |===============/ \=====| |==========| | | +---+
^ +----+ ^ +-----+ +----+ ^ +----+ ^ ^ +----+ ^ +-----+ +----+ ^ +----+ ^
| | ^ | | | | ^ | |
| TE LSP | TE LSP | | TE LSP | TE LSP |
| P-router | | P-router |
| | | |
|<-------------------- Emulated Service ------------------->| |<-------------------- Emulated Service ------------------->|
Figure 6: MPLS-TP Architecture (Multi-Segment PW) Figure 7: MPLS-TP Architecture (Multi-Segment PW)
The corresponding domain of the MPLS-TP protocol stack including PWs The corresponding domain of the MPLS-TP protocol stack including PWs
is shown in Figure 7. is shown in Figure 8.
+-------------------+ +-------------------+
| Client Layer | | Client Layer |
/===================\ /===================\ /===================\ /===================\
H PW Encap H H PW OAM H H PW Encap H H PW OAM H
H-------------------H H-------------------H /===================\ H-------------------H H-------------------H /===================\
H PW Demux (S=1) H H PW Demux (S=1) H H LSP OAM H H PW Demux (S=1) H H PW Demux (S=1) H H LSP OAM H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H
\===================/ \===================/ \===================/ \===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer | | Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM User Traffic PW OAM LSP OAM
Note: Transport Service Layer = PW Demux Note: Transport Service Layer = PW Demux
Transport Path Layer = LSP Demux Transport Path Layer = LSP Demux
Figure 7: MPLS-TP Layer Network using Pseudowires Figure 8: MPLS-TP Layer Network using Pseudowires
When providing a Virtual Private Wire Service (VPWS), Virtual Private When providing a Virtual Private Wire Service (VPWS), Virtual Private
Local Area Network Service (VPLS), Virtual Private Multicast Service Local Area Network Service (VPLS), Virtual Private Multicast Service
(VPMS) or Internet Protocol Local Area Network Service (IPLS), (VPMS) or Internet Protocol Local Area Network Service (IPLS),
pseudowires MUST be used to carry the client service. These PWs can pseudowires must be used to carry the client service.
be configured either statically or via the control plane defined in
[RFC4447].
Note that in MPLS-TP environments where IP is used for control or OAM [Editors' note add references for the terms in this para].
purposes, IP MAY be carried over the LSP demultiplexers as per
RFC3031 [RFC3031], or directly over the server.
3.4.2. Network Layer Clients PWs and their underlying labels may be configured or signaled. See
Section 3.9 for additional details related to configured service
types. See Section 3.8 for additional details related to signaled
service types.
3.4.3. Network Layer Adaptation
MPLS-TP LSPs can be used to transport network layer clients. Any MPLS-TP LSPs can be used to transport network layer clients. Any
network layer protocol can be transported between service interfaces. network layer protocol can be transported between service interfaces.
Examples of network layer protocols include IP, MPLS and MPLS-TP. Examples of network layer protocols include IP, MPLS and MPLS-TP.
Support for network layer clients follows the MPLS architecture for
support of network layer protocols as defined in [RFC3031] and
supported in [RFC3032].
With network layer transport, the MPLS-TP domain provides a With network layer adaptation, the MPLS-TP domain provides a
bidirectional point-to-point connection between two customer edge bidirectional point-to-point connection between two PEs in order to
(CE) nodes. Note that a CE may be an an IP, MPLS or MPLS-TP node. deliver a packet transport service to attached customer edge (CE)
As shown in Figure 8, there is an attachment circuit between the CE nodes. For example, a CE may be an IP, MPLS or MPLS-TP node. As
node on the left and its corresponding provider edge (PE) node that shown in Figure 9, there is an attachment circuit between the CE node
on the left and its corresponding provider edge (PE) node which
provides the service interface, a bidirectional LSP across the provides the service interface, a bidirectional LSP across the
MPLS-TP service network to the corresponding PE node on the right, MPLS-TP network to the corresponding PE node on the right, and an
and an attachment circuit between that PE node and the corresponding attachment circuit between that PE node and the corresponding CE node
CE node for this service. for this service.
|<------------- Client Network Layer-------------->| |<------------- Client Network Layer-------------->|
| | | |
| |<---- Pkt Xport Service --->| | |<---- Pkt Xport Service --->|
| | | | | | | |
| | |<-- PSN Tunnel -->| | | | | |<-- PSN Tunnel -->| | |
| V V V V | | V V V V |
V AC +----+ +---+ +----+ AC V V AC +----+ +---+ +----+ AC V
+-----+ | | PE1|======:=X=:=======| PE2| | +-----+ +-----+ | |PE1 | | | |PE2 | | +-----+
| |----------|...........:LSP:............|----------| | | | |LSP | | | | | | | | |
| CE1 | | | | | : | | | | CE2 | | CE1 |----------| |========X=========| |----------| CE2 |
| |----------|...........: IP:............|----------| | | | ^ |IP | | ^ | | ^ | | | ^ | |
+-----+ ^ | | |======:=X=:=======| | | ^ +-----+ +-----+ | | | | | | | | | | | | +-----+
^ | +----+ +---+ +----+ | | ^ ^ | +----+ | +---+ | +----+ | | ^
| | Provider Edge 1 ^ Provider Edge 2 | | | | Provider | ^ | Provider | |
| | | | | | | Edge | | | Edge | |
Customer | P Router | Customer Customer | 1 | P-router | 2 | Customer
Edge 1 | | Edge 2 Edge 1 | TE TE | Edge 2
| | | LSP LSP |
| | | |
Native service Native service Native service Native service
Figure 8: MPLS-TP Architecture for Network Layer Clients Figure 9: MPLS-TP Architecture for Network Layer Clients
At the ingress service interface the PE transforms the ingress packet At the ingress service interface, the PE pushes one or more labels
to the format that will be carried over the transport network, and onto the ingress packets which are label switched over the transport
similarly the corresponding service interface at the egress PE network, and similarly the corresponding service interface at the
transforms the packet to the format needed by the attached CE. The egress PE pops any labels added by the MPLS-TP networks and delivers
attachment circuits may be heterogeneous (e.g., any combination of the packets to the attached CE. The attachment circuits may be
SDH, PPP, Frame Relay etc) and network layer protocol payloads arrive heterogeneous (e.g., any combination of SDH, PPP, Frame Relay, etc.)
at the service interface encapsulated in the Layer1/Layer2 encoding and network layer protocol payloads arrive at the service interface
defined for that access link type. It should be noted that the set encapsulated in the Layer1/Layer2 encoding defined for that access
of network layer protocols includes MPLS and hence MPLS encoded link type. It should be noted that the set of network layer
packets with an MPLS label stack (the client MPLS stack), may appear protocols includes MPLS and hence MPLS encoded packets with an MPLS
at the service interface. label stack (the client MPLS stack), may appear at the service
interface.
+-------------------+ +-------------------+
| Client Layer | | Client Layer |
/===================\ /===================\ /===================\ /===================\
H Encap Label (S=1) H H SvcLSP OAM H H Encap Label H H SvcLSP OAM H
H-------------------H H-------------------H /===================\ H-------------------H H-------------------H /===================\
H SvcLSP Demux H H SvcLSP Demux (S=1)H H LSP OAM H H SvcLSP Demux H H SvcLSP Demux (S=1)H H LSP OAM H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H
\===================/ \===================/ \===================/ \===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer | | Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
User Traffic Service LSP OAM LSP OAM User Traffic Service LSP OAM LSP OAM
Note: Transport Service Layer = SvcLSP Demux Note: Transport Service Layer = SvcLSP Demux
Transport Path Layer = LSP Demux Transport Path Layer = LSP Demux
Note that the functions of the Encap label and the Service Label may represented Note that the functions of the Encap label and the Service Label may be
by a single label represented by a single label or omitted. Additionally, the S-bit will
always be zero when the client layer is MPLS labelled.
Figure 9: Domain of MPLS-TP Layer Network for IP and LSP Clients Figure 10: Domain of MPLS-TP Layer Network for IP and LSP Clients
Within the MPLS-TP transport network, the network layer protocols are Within the MPLS-TP transport network, the network layer protocols are
carried over the MPLS-TP LSP using a separate MPLS label stack (the carried over the MPLS-TP network using a logically separate MPLS
server stack). The server stack is entirely under the control of the label stack (the server stack). The server stack is entirely under
nodes within the MPLS-TP transport network and it is not visible the control of the nodes within the MPLS-TP transport network and it
outside that network. In accordance with [RFC3032], the bottom is not visible outside that network. Figure 10 shows how a client
label, with the 'bottom of stack' bit set to '1', defines the network
layer protocol being transported. Figure 9 shows how an a client
network protocol stack (which may be an MPLS label stack and payload) network protocol stack (which may be an MPLS label stack and payload)
is carried over as a network layer transport service over an MPLS-TP is carried over a network layer client service over an MPLS-TP
transport network. transport network.
A label per network layer protocol payload type that is to be A label per network layer protocol payload type that is to be
transported is REQUIRED. Such labels are referred to as "Service transported is required. Such labels are referred to as
Labels", one of which is shown in Figure 9. The mapping between "Encapsulation Labels", one of which is shown in Figure 10.
protocol payload type and Service Label is either configured or Encapsulation Label is either configured or signaled.
signaled.
Service labels are typically carried over an MPLS-TP edge-to-edge A Service Label should be used when a particular packet transport
LSP, which is also shown in Figure 9. The use of an edge-to-edge LSP service is supporting more than one network layer protocol payload
is RECOMMENDED when more than one protocol payload type is to be type (and more than one Encapsulation Label is used). An example
transported. For example, if only MPLS is carried then a single Service Label is shown in Figure 10. A Service Label may be omitted
Service Label would be used to provided both payload type indication when only one encapsulation label is used in support of a particular
and the MPLS-TP edge-to-edge LSP. Alternatively, if both IP and MPLS service. For example, if only MPLS labelled packets are carried over
is to be carried then two Service Labels would be mapped on to a a service, then a single Encapsulation Label would be used to provide
both payload type indication and service identification.
Alternatively, if both IP and MPLS is to be carried, as shown in
Figure 9, then two Encapsulation Labels could be mapped on to a
common Service Label.
Service labels are typically carried over an MPLS-TP edge-to-edge (or
transport path layer) LSP, which is also shown in Figure 10. The use
of an edge-to-edge LSP is recommended when more than one service
exists between two PEs. An edge-to-edge LSP may be omitted when only
one service label is used in between two PEs. For example, if only
one service is carried between two PEs then a single Service Label
could be used to provided both service indication and the MPLS-TP
edge-to-edge LSP. Alternatively, if multiple services exist between
a pair of PEs then a per-client Service Label would be mapped on to a
common MPLS-TP edge-to-edge LSP. common MPLS-TP edge-to-edge LSP.
As noted above, any layer 2 and layer 1 protocols used to carry the As noted above, the layer 2 and layer 1 protocols used to carry the
network layer protocol over the attachment circuit is terminated at network layer protocol over the attachment circuits are not
the service interface and is not transported across the MPLS-TP transported across the MPLS-TP network. This enables the use of
network. This enables the use of different layer 2 / layer 1 different layer 2 and layer 1 protocols on the two attachment
technologies at two service interfaces. circuits.
At each service interface, Layer 2 addressing must be used to ensure At each service interface, Layer 2 addressing must be used to ensure
the proper delivery of a network layer packet to the adjacent node. the proper delivery of a network layer packet to the adjacent node.
This is typically only an issue for LAN media technologies (e.g., This is typically only an issue for LAN media technologies (e.g.,
Ethernet) which have Media Access Control (MAC) addresses. In cases Ethernet) which have Media Access Control (MAC) addresses. In cases
where a MAC address is needed, the sending node MUST set the where a MAC address is needed, the sending node must set the
destination MAC address to an address that ensures delivery to the destination MAC address to an address that ensures delivery to the
adjacent node. That is the CE sets the destination MAC address to an adjacent node. That is the CE sets the destination MAC address to an
address that ensures delivery to the PE, and the PE sets the address that ensures delivery to the PE, and the PE sets the
destination MAC address to an address that ensures delivery to the destination MAC address to an address that ensures delivery to the
CE. The specific address used is technology type specific and is not CE. The specific address used is technology type specific and is not
covered in this document. In some technologies the MAC address will covered in this document. In some technologies the MAC address will
need to be configured (Examples for the Ethernet case include a need to be configured (Examples for the Ethernet case include a
configured unicast MAC address for the adjacent node, or even using configured unicast MAC address for the adjacent node, or even using
the broadcast MAC address when the CE-PE service interface is the broadcast MAC address when the CE-PE service interface is
dedicated. The configured address is then used as the MAC dedicated. The configured address is then used as the MAC
destination address for all packets sent over the service interface.) destination address for all packets sent over the service interface.)
Note that when the two CEs operating over the network layer transport Note that when the two CEs operating over the network layer transport
service are running a routing protocol such as ISIS or OSPF some care service are running a routing protocol such as IS-IS or OSPF some
should be taken to configure the routing protocols to use point- to- care should be taken to configure the routing protocols to use point-
point adjacencies. The specifics of such configuration is outside to-point adjacencies. The specifics of such configuration is outside
the scope of this document. the scope of this document. See [RFC5309] for additional details.
[Editors Note we need to confer with ISIS and OSPF WG to verify that
the cautionary note above is necessary and sufficient.]
The CE to CE service types and corresponding labels may be configured The CE to CE service types and corresponding labels may be configured
or signaled. When they are signaled the CE to PE control channel may or signaled. See Section 3.9 for additional details related to
be either out-of-band or in-band. An out-of-band control channel configured service types. See Section 3.8 for additional details
uses standard GMPLS out-of-band signaling techniques. There are a related to signaled service types.
number of methods that can be used to carry this signalling:
o It can be carried via an out-of-band control channel. (As is 3.5. Identifiers
commonly done in today's GMPLS controlled transport networks.)
o It could be carried over the attachment circuit with MPLS using a Identifiers are used to uniquely distinguish entities in an MPLS-TP
reserved label. network. These include operators, nodes, LSPs, pseudowires, and
their associated maintenance entities.
[I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are
compatible with existing MPLS control plane identifiers, as well as a
set of identifiers that may be used when no IP control plane is
available.
o It could be carried over the attachment circuit with MPLS using a 3.6. Generic Associated Channel (G-ACh)
normal label that is agreed between CE and PE.
o It could be carried over the attachment circuit in an ACH. For correct operation of the OAM it is important that the OAM packets
fate-share with the data packets. In addition in MPLS-TP it is
necessary to discriminate between user data payloads and other types
of payload. For example, a packet may be associated with a Signaling
Communication Channel (SCC), or a channel used for Automatic
Protection Switching (APS) data. This is achieved by carrying such
packets on a generic control channel associated to the LSP, PW or
section.
o It could be carried over the attachment circuit in IP. MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
or other packet types in-band over LSPs or PWs. The G-ACh is defined
in [RFC5586] and is similar to the Pseudowire Associated Channel
[RFC4385], which is used to carry OAM packets over pseudowires. The
G-ACh is indicated by a generic associated channel header (ACH),
similar to the Pseudowire VCCV control word; this header is present
for all Sections, LSPs and PWs making use of FCAPS functions
supported by the G-ACh.
In the MPLS and ACH cases above, this label value is used to carry For pseudowires, the G-ACh uses the first four bits of the pseudowire
LSP signaling without any further encapsulation. This signaling control word to provide the initial discrimination between data
channel is always point-to-point and MUST use local CE and PE packets and packets belonging to the associated channel, as described
addressing. in [RFC4385]. When this first nibble of a packet, immediately
following the label at the bottom of stack, has a value of '1', then
this packet belongs to a G-ACh. The first 32 bits following the
bottom of stack label then have a defined format called an associated
channel header (ACH), which further defines the content of the
packet. The ACH is therefore both a demultiplexer for G-ACh traffic
on the PW, and a discriminator for the type of G-ACh traffic.
The method(s) to be used will be described in a future version of the When the OAM or other control message is carried over an LSP, rather
document. than over a pseudowire, it is necessary to provide an indication in
the packet that the payload is something other than a user data
packet. This is achieved by including a reserved label with a value
of 13 in the label stack. This reserved label is referred to as the
'Generic Alert Label (GAL)', and is defined in [RFC5586]. When a GAL
is found, it indicates that the payload begins with an ACH. The GAL
is thus a demultiplexer for G-ACh traffic on the LSP, and the ACH is
a discriminator for the type of traffic carried on the G-ACh. Note
however that MPLS-TP forwarding follows the normal MPLS model, and
that a GAL is invisible to an LSR unless it is the top label in the
label stack. The only other circumstance under which the label stack
may be inspected for a GAL is when the TTL has expired. Any MPLS-TP
component that intentionally performs this inspection must assume
that it is asynchronous with respect to the forwarding of other
packets. All operations on the label stack are in accordance with
[RFC3031] and [RFC3032].
3.5. Identifiers In MPLS-TP, the 'G-ACh Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1).
Identifiers to be used in within MPLS-TP where compatibility with The G-ACh must only be used for channels that are an adjunct to the
existing MPLS control plane conventions are necessary are described data service. Examples of these are OAM, APS, MCC and SCC, but the
in [draft-swallow-mpls-tp-identifiers-00]. The MPLS-TP requirements use is not restricted to these services. The G-ACh must not be used
[RFC5654] require that the elements and objects in an MPLS-TP to carry additional data for use in the forwarding path, i.e. it must
environment are able to be configured and managed without a control not be used as an alternative to a PW control word, or to define a PW
plane. In such an environment many conventions for defining type.
identifiers are possible. However it is also anticipated that
operational environments where MPLS-TP objects, LSPs and PWs will be
signaled via existing protocols such as the Label Distribution
Protocol [RFC4447] and the Resource Reservation Protocol as it is
applied to Generalized Multi-protocol Label Switching ( [RFC3471] and
[RFC3473]) (GMPLS). [draft-swallow-mpls-tp-identifiers-00] defines a
set of identifiers for MPLS-TP which are both compatible with those
protocols and applicable to MPLS-TP management and OAM functions.
MPLS-TP distinguishes between addressing used to identify nodes in At the server layer, bandwidth and QoS commitments apply to the gross
the network, and identifiers used for demultiplexing and forwarding. traffic on the LSP, PW or section. Since the G-ACh traffic is
indistinguishable from the user data traffic, protocols using the
G-ACh must take into consideration the impact they have on the user
data that they are sharing resources with. Conversely, capacity must
be made available for important G-ACh uses such as protection and
OAM. In addition, protocols using the G-ACh must conform to the
security and congestion considerations described in [RFC5586].
Whilst IP addressing is used by default, MPLS-TP must be able to Figure 11 shows the reference model depicting how the control channel
operate in environments where IP is not used in the forwarding plane. is associated with the pseudowire protocol stack. This is based on
Therefore, the default mechanism for OAM demultiplexing in MPLS-TP the reference model for VCCV shown in Figure 2 of [RFC5085].
LSPs and PWs is the generic associated channel. Forwarding based on
IP addresses for user or OAM packets is not REQUIRED for MPLS-TP.
[RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined alert +-------------+ +-------------+
mechanisms that enable an MPLS LSR to identify and process MPLS OAM | Payload | < Service / FCAPS > | Payload |
packets when the OAM packets are encapsulated in an IP header. These +-------------+ +-------------+
alert mechanisms are based on TTL expiration and/or use an IP | Demux / | < CW / ACH for PWs > | Demux / |
destination address in the range 127/8. These mechanisms are the |Discriminator| |Discriminator|
default mechanisms for MPLS networks in general for identifying MPLS +-------------+ +-------------+
OAM packets when the OAM packets are encapsulated in an IP header. | PW | < PW > | PW |
MPLS-TP is unable to rely on the availability of IP and thus uses the +-------------+ +-------------+
GACH/GAL to demultiplex OAM packets. | PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
3.6. Operations, Administration and Maintenance (OAM) Figure 11: PWE3 Protocol Stack Reference Model including the G-ACh
PW associated channel messages are encapsulated using the PWE3
encapsulation, so that they are handled and processed in the same
manner (or in some cases, an analogous manner) as the PW PDUs for
which they provide a control channel.
Figure 12 shows the reference model depicting how the control channel
is associated with the LSP protocol stack.
+-------------+ +-------------+
| Payload | < Service > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 12: MPLS Protocol Stack Reference Model including the LSP
Associated Control Channel
3.7. Operations, Administration and Maintenance (OAM)
MPLS-TP must be able to operate in environments where IP is not used
in the forwarding plane. Therefore, the default mechanism for OAM
demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated
Channel (Section 3.6). Forwarding based on IP addresses for user or
OAM packets is not required for MPLS-TP.
[RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined
alert mechanisms that enable an MPLS LSR to identify and process MPLS
OAM packets when the OAM packets are encapsulated in an IP header.
These alert mechanisms are based on TTL expiration and/or use an IP
destination address in the range 127/8 for IPv4 and that same range
embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the
OAM packets are encapsulated in an IP header, these mechanisms are
the default mechanisms for MPLS networks in general for identifying
MPLS OAM packets. MPLS-TP must be able to operate in an environments
where IP forwarding is not supported, and thus the GACH/GAL is the
default mechanism to demultiplex OAM packets in MPLS-TP.
MPLS-TP supports a comprehensive set of OAM capabilities for packet MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those transport applications, with equivalent capabilities to those
provided in SONET/SDH. provided in SONET/SDH.
MPLS-TP defines mechanisms to differentiate specific packets (e.g. MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the OAM, APS, MCC or SCC) from those carrying user data packets on the
same LSP. These mechanisms are described in [RFC5586]. same transport path (i.e. section, LSP or PW). These mechanisms are
described in [RFC5586].
MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of
OAM capabilities is available to perform fault management (e.g. fault OAM capabilities is available to perform fault management (e.g. fault
detection and localization) and performance monitoring (e.g. packet detection and localisation) and performance monitoring (e.g. packet
delay and loss measurement) of the LSP, PW or section. The framework delay and loss measurement) of the LSP, PW or section. The framework
for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].
MPLS-TP OAM packets share the same fate as their corresponding data MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel packets, and are identified through the Generic Associated Channel
mechanism [RFC5586]. This uses a combination of an Associated mechanism [RFC5586]. This uses a combination of an Associated
Channel Header (ACH) and a Generic Alert Label (GAL) to create a Channel Header (ACH) and a Generic Alert Label (GAL) to create a
control channel associated to an LSP, Section or PW. control channel associated to an LSP, Section or PW.
3.6.1. OAM Architecture 3.7.1. OAM Architecture
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 [I-D.ietf-mpls-tp-oam-framework]. A entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A
Maintenance Entity can be viewed as the association of two (or more) Maintenance Entity can be viewed as the association of two
Maintenance End Points (MEPs) (see example in Figure 10 ). The MEPs Maintenance End Points (MEPs) (see example in Figure 13 ). Another
that form an ME should be configured and managed to limit the OAM OAM construct is referred to as Maintenance Entity Group (MEG), which
responsibilities of an OAM flow within a network or sub- network, or is a collection of one or more MEs that belongs to the same transport
a transport path or segment, in the specific layer network that is path and that are maintained and monitored as a group. The MEPs that
being monitored and managed. form an ME should be configured and managed to limit the OAM
responsibilities of an OAM flow within the domain of a transport path
or segment, in the specific layer network that is being monitored and
managed.
Each OAM flow is associated with a single ME. Each MEP within an ME Each OAM flow is associated with a single ME. Each MEP within an ME
resides at the boundaries of that ME. An ME may also include a set resides at the boundaries of that ME. An ME may also include a set
of zero or more Maintenance Intermediate Points (MIPs), which reside of zero or more Maintenance Intermediate Points (MIPs), which reside
within the Maintenance Entity. Maintenance end points (MEPs) are within the Maintenance Entity. Maintenance End Points (MEPs) are
capable of sourcing and sinking OAM flows, while maintenance capable of sourcing and sinking OAM flows, while Maintenance
intermediate points (MIPs) can only sink or respond to OAM flows. Intermediate Points (MIPs) can only sink or respond to OAM flows from
within a MEG, or originate notifications as a result of specific
network conditions.
========================== 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 |----
skipping to change at page 23, line 32 skipping to change at page 29, line 28
(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 --------> <------------ ME ----------><--- ME ----><------- ME -------->
Note: MEPs for End-to-end LSP OAM exist outside of the scope Note: MEPs for End-to-end LSP OAM exist outside of the scope
of this figure. of this figure.
Figure 10: Example of MPLS-TP OAM Figure 13: Example of MPLS-TP OAM showing end-to-end and segment OAM
Figure 11 illustrates how the concept of Maintenance Entities can be Figure 14 illustrates how the concept of Maintenance Entities can be
mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS- mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
PWs. 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| +---+
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
skipping to change at page 24, line 36 skipping to change at page 30, line 36
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 11: MPLS-TP OAM archtecture Figure 14: MPLS-TP OAM architecture showing PWs, LSPs and Sections
The following MPLS-TP MEs are specified in The following MPLS-TP MEs are specified in
[I-D.ietf-mpls-tp-oam-framework]: [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 (LTCME), allowing o An LSP Tandem Connection Maintenance Entity (LTCME).
estimation of OAM fault and performance metrics of a single LSP
segment or of an aggregate of LSP segments. It also enables any
OAM function applied to segment(s) of an LSP to be independent of
the OAM function(s) operated on the end-to-end LSP. This can be
achieved by including a label representing the LTCME on one or
more LSP label stacks for 1:1 or N:1 monitoring of LSPs,
respectively. 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 hierarchal
architectures commonly employed in todays packet networks.
Individual MIPs along the path of an LSP or PW are addressed by A G-ACH packet may be directed to an individual MIP along the path of
setting the appropriate TTL in the label for the OAM packet, as per an LSP or MS-PW by setting the appropriate TTL in the label for the
[I-D.ietf-pwe3-segmented-pw]. Note that this works when the location G-ACH packet, as per the traceroute mode of LSP Ping [RFC4379] and
of MIPs along the LSP or PW path is known by the MEP. There may be the vccv-trace mode of[I-D.ietf-pwe3-segmented-pw]. Note that this
cases where this is not the case in general MPLS networks e.g. works when the location of MIPs along the LSP or PW path is known by
the MEP. There may be circumstances where this is not the case, e.g.
following restoration using a facility bypass LSP. In these cases, following restoration using a facility bypass LSP. In these cases,
tools to trace the path of the LSP may be used to determine the tools to trace the path of the LSP may be used to determine the
appropriate setting for the TTL to reach a specific MIP. appropriate setting for the TTL to reach a specific MIP.
Within an LSR or PE, MEPs and MIPs can only be placed where MPLS Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
layer processing is performed on a packet. The architecture mandates layer processing is performed on a packet. The architecture mandates
that this must occur at least once. that this must occur at least once.
There is only one MIP on an LSP or PW in each node. That MIP is for
all applicable OAM functions on its associated LSP or PW. This
document does not specify the default position of the MIP within the
node. Therefore, this document does not specify where the exception
mechanism resides (i.e. at the ingress interface, the egress
interface, or some other location within the node). An optional
protocol may be developed that sets the position of a MIP along the
path of an LSP or PW within the node (and thus determines the
exception processing location).
MEPs may only act as a sink of OAM packets when the label associated MEPs may only act as a sink of OAM packets when the label associated
with the LSP or PW for that ME is popped. MIPs can only be placed with the LSP or PW for that ME is popped. MIPs can only be placed
where an exception to the normal forwarding operation occurs. A MEP where an exception to the normal forwarding operation occurs. A MEP
may act as a source of OAM packets whereever a label is pushed or may act as a source of OAM packets wherever a label is pushed or
swapped. For example, on a MS-PW, a MEP may source OAM within an swapped. For example, on an MS-PW, a MEP may source OAM within an
S-PE or a T-PE, but a MIP may only be associated with a S-PE and a S-PE or a T-PE, but a MIP may only be associated with a S-PE and a
sink MEP can only be associated with a T-PE. sink MEP can only be associated with a T-PE.
3.6.2. OAM Functions 3.7.2. OAM Functions
The MPLS-TP OAM architecture supports a wide range of OAM functions,
including the following:
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 (e.g. loss and delay) o Performance Monitoring (e.g. packet loss and delay measurement)
o Alarm suppression o Alarm Suppression
o Remote Integrity o Remote Integrity
These are applicable to any layer defined within MPLS-TP, i.e. MPLS These functions are applicable to any layer defined within MPLS-TP,
Section, LSP and PW. i.e. to MPLS-TP Sections, LSPs and PWs.
The MPLS-TP OAM toolset needs to be able to operate without relying The MPLS-TP OAM tool-set must be able to operate without relying on a
on a dynamic control plane or IP functionality in the datapath. In dynamic control plane or IP functionality in the datapath. In the
the case of MPLS-TP deployment with IP functionality, all existing case of an MPLS-TP deployment in a network in which IP functionality
IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used. is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD
This does not preclude the use of other OAM tools in an IP and VCCV, may be used.
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.7. Generic Associated Channel (G-ACh) 3.8. Control Plane
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 discriminate between user data payloads and other types
of payload. For example the packet may contain a Signaling
Communication Channel (SCC), or a channel used for Automatic
Protection Switching (APS) data. Such packets are carried on a
control channel associated to the LSP, Section or PW. This is
achieved by carrying such packets on a generic control channel
associated to the LSP, PW or section.
MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
or other packet types in band over LSPs or PWs. The G-ACH is defined
in [RFC5586] and 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 achieved by including a reserved label with a value
of 13 in the label stack. This reserved label is referred to as the
'Generic Alert Label (GAL)', and is defined in [RFC5586]. When a GAL
is found 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 in the label stack. The only
other circumstance under which the label stack may be inspected for a
GAL is when the TTL has expired. Any MPLS-TP component that
intentionally performs this inspection must assume that it is
asynchronous with respect to the forwarding of other packets. All
operations on the label stack are in accordance with [RFC3031] and
[RFC3032].
In MPLS-TP, the '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
data service. Examples of these are OAM, APS, MCC and SCC, but the
use is not restricted to those names services. The G-ACH MUST NOT be
used to carry additional data for use in the forwarding path, i.e. it
MUST NOT be used as an alternative to a PW control word, or to define
a PW type.
Since the G-ACh traffic is indistinguishable from the user data
traffic at the server layer, bandwidth and QoS commitments apply to
the gross traffic on the LSP, PW or section. Protocols using the
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 12 shows the reference model depicting how the control channel
is associated with the pseudowire protocol stack. This is based on
the reference model for VCCV shown in Figure 2 of [RFC5085].
+-------------+ +-------------+
| Payload | < Service / FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < CW / ACH for PWs > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 12: PWE3 Protocol Stack Reference Model including the G-ACh
PW associated channel messages are encapsulated using the PWE3
encapsulation, so that they are handled and processed in the same
manner (or in some cases, an analogous manner) as the PW PDUs for
which they provide a control channel.
Figure 13 shows the reference model depicting how the control channel
is associated with the LSP protocol stack.
+-------------+ +-------------+
| Payload | < Service > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 13: MPLS Protocol Stack Reference Model including the LSP Editors note: This section will be updated based on text supplied by
Associated Control Channel the control plane framework draft editors.
3.8. Control Plane A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements
specified in [RFC5654] can be met, the MPLS Transport Profile uses
existing standard control plane protocols for LSPs and PWs.
MPLS-TP should be capable of being operated with centralized Network Note that a dynamic control plane is not required in an MPLS-TP
Management Systems (NMS). The NMS may be supported by a distributed network. See Section 3.9 for further details on statically
control plane, but MPLS-TP can operated in the absence of such a configured and provisioned MPLS-TP services.
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 [RFC5654] can
be met, the MPLS transport profile uses existing control plane
protocols for LSPs and PWs.
Figure 14 illustrates the relationship between the MPLS-TP control Figure 15 illustrates the relationship between the MPLS-TP control
plane, the forwarding plane, the management plane, and OAM for point- plane, the forwarding plane, the management plane, and OAM for point-
to-point MPLS-TP LSPs or PWs. 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 30, line 26 skipping to change at page 33, line 26
: +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | : : | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/ \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+-- --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
/: +----+ |ing | : : |ing | : : |ing | +----+ :\ /: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ : : +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' ''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: Note:
1) NMS may be centralised or distributed. Control plane is 1) NMS may be centralised or distributed. Control plane is
distributed distributed.
2) 'Edge' functions refers to those functions present at 2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g. NSP or classification. the edge of a PSN domain, e.g. NSP or classification.
3) The control plane may be transported over the server 3) The control plane may be transported over the server
layer, and LSP or a G-ACh. layer, an LSP or a G-ACh.
Figure 14: MPLS-TP Control Plane Architecture Context Figure 15: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on a combination of the LDP-based The MPLS-TP control plane is based on a combination of the LDP-based
control plane for pseudowires [RFC4447] and the RSVP-TE based control control plane for pseudowires [RFC4447] and the RSVP-TE-based control
plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that
are required for LSP signaling for MPLS-TP are based on GMPLS. are required for MPLS-TP LSP signaling are based on Generalized MPLS
(GMPLS) ([RFC3945], [RFC3471], [RFC3473]).
The distributed MPLS-TP control plane provides the following The distributed MPLS-TP control plane may provide the following
functions: 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 supports 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. These include the User-Network Interface (UNI), Internal domains. These include the User-Network Interface (UNI), Internal
Network Node Interface (I-NNI), and External Network Node Interface Network Node Interface (I-NNI), and External Network Node Interface
(E-NNI). Note that different policies may be defined that control (E-NNI). Note that different policies may be defined that control
the information exchanged across these interface types. the information exchanged across these interface types.
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.6 e.g. for fault detection and localization in the event of Section 3.7, e.g. for fault detection and localisation in the event
a failure in order to efficiently restore failed transport paths. of 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 Section 3.10.
section Section 3.10 of this document. Examples of the MPLS-TP data Examples of the MPLS-TP data plane connectivity patterns are LSPs
plane connectivity patterns are LSPs utilizing the fast reroute utilising the fast reroute backup methods as defined in [RFC4090] and
backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or ingress-to-egress 1+1 or 1:1 protected LSPs.
1:1 protected LSPs.
The MPLS-TP control plane provides functions to ensure its own The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures survivability and to enable it to recover gracefully from failures
and degradations. These include graceful restart and hot redundant and degradations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported, configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data varying degrees of decoupling between the control plane and data
plane may be achieved. plane may be achieved.
3.8.1. PW Control Plane 3.8.1. PW Control Plane
An MPLS-TP network provides many of its transport services using An MPLS-TP network provides many of its transport services using
single-segment or multi-segment pseudowires, in compliance with the single-segment or multi-segment pseudowires, in compliance with the
PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). The PWE3 architecture ([RFC3985] and [RFC5659]). The setup and
setup and maintenance of single-segment or multi- segment pseudowires maintenance of single-segment or multi-segment pseudowires uses the
uses the Label Distribution Protocol (LDP) as per [RFC4447] and Label Distribution Protocol (LDP) as per [RFC4447] and extensions for
extensions for MS-PWs [I-D.ietf-pwe3-segmented-pw] and MS-PWs ([I-D.ietf-pwe3-segmented-pw] and
[I-D.ietf-pwe3-dynamic-ms-pw]. [I-D.ietf-pwe3-dynamic-ms-pw]).
3.8.2. LSP Control Plane 3.8.2. LSP Control Plane
MPLS-TP provider edge nodes aggregate multiple pseudowires and carry MPLS-TP Provider Edge LSRs 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). Applicable functions from the Generalized MPLS (GMPLS) LSPs). Applicable functions from the Generalized MPLS (GMPLS)
protocol suite supporting packet-switched capable (PSC) technologies ([RFC3945]) protocol suite supporting packet-switched capable (PSC)
are used as the control plane for MPLS-TP transport paths (LSPs). technologies are used as the control plane for MPLS-TP transport
paths (LSPs).
The LSP control plane includes: The LSP control plane includes:
o RSVP-TE for signalling o RSVP-TE for signaling
o OSPF-TE or ISIS-TE for routing o OSPF-TE or ISIS-TE for routing
RSVP-TE signaling in support of GMPLS, as defined in [RFC3473], is RSVP-TE signaling in support of GMPLS, as defined in [RFC3473], is
used for the setup, modification, and release of MPLS-TP transport used for the setup, modification, and release of MPLS-TP transport
paths and protection paths. It supports unidirectional, bi- paths and protection paths. It supports unidirectional and
directional and multicast types of LSPs. The route of a transport bidirectional point-to-point LSPs as well as unidirectional point-to-
path is typically calculated in the ingress node of a domain and the multipoint LSPs. The architecture for MPLS-TP supporting point-to-
RSVP explicit route object (ERO) is utilized for the setup of the multipoint packet transport services is out of scope of this
transport path exactly following the given route. GMPLS based document.
MPLS-TP LSPs must be able to inter-operate with RSVP-TE based MPLS-TE
LSPs, as per [RFC5146]
OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used The route of a transport path is typically calculated in the ingress
for carrying link state information in a MPLS-TP network. ISIS-TE node of a domain and the RSVP explicit route object (ERO) is utilised
routing in support of GMPLS as defined in [RFC5307] is used for for the setup of the transport path exactly following the given
carrying link state information in a MPLS-TP network. route. GMPLS-based MPLS-TP LSPs must be able to inter-operate with
RSVP-TE-based MPLS-TE LSPs, as per [RFC5146]
OSPF and IS-IS for GMPLS ([RFC4203] and [RFC5307]) are used for
carrying link state routing information in an MPLS-TP network.
3.9. Static Operation of LSPs and PWs 3.9. Static Operation of LSPs and PWs
A PW or LSP may be statically configured without the support of a An MPLS-TP LSP or PW may be statically configured without the support
dynamic control plane. This may be either by direct configuration of of a dynamic control plane. This may be either by direct
the PEs/LSRs, or via a network management system. The collateral configuration of the LSRs, or via a network management system.
damage that loops can cause during the time taken to detect the Static operation is independent of a specific PW or LSP instance -
failure may be severe. When static configuration mechanisms are for example it should be possible for a PW to be statically
used, care must be taken to ensure that loops to not form. configured, while the LSP supporting it setup by a dynamic control
plane.
Persistent forwarding loops can cause significant additional resource
utilisation, above that budgeted for the transport path. Therefore,
when static configuration mechanisms are used, care must be taken to
ensure that loops do not form.
3.10. Survivability 3.10. Survivability
Editors note: This section will be updated based on text supplied by
the survivability draft editors.
Survivability requirements for MPLS-TP are specified in Survivability requirements for MPLS-TP are specified in
[I-D.ietf-mpls-tp-survive-fwk]. [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 ([RFC4090]), while pseudowire repair using back-up LSP tunnels ([RFC4090]), while pseudowire
redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
protection for the PW can not be fully provided by the PSN layer protection for the PW cannot be fully provided by the PSN layer (i.e.
(i.e. where the backup PW terminates on a different target PE node where the backup PW terminates on a different target PE node than the
than the working PW). Additionally, GMPLS provides a well known set working PW). Additionally, GMPLS provides a well known set of
of control plane driven protection and restoration mechanisms control plane driven protection and restoration mechanisms [RFC4872].
[RFC4872]. MPLS-TP provides additional protection mechanisms that MPLS-TP provides additional protection mechanisms that are optimised
are optimised for both linear topologies and ring topologies, and for both linear topologies and ring topologies, and that operate in
that operate in the absence of a dynamic control plane. These are the absence of a dynamic control plane. These are specified in
specified in [I-D.ietf-mpls-tp-survive-fwk]. [I-D.ietf-mpls-tp-survive-fwk].
Different protection schemes apply to different deployment topologies Different protection schemes apply to different deployment topologies
and operational considerations. Such protection schemes may provide and operational considerations. Such protection schemes may provide
different levels of resiliency. For example, two concurrent traffic different levels of resiliency, for example:
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 o Two concurrent traffic paths (1+1).
that is shared by one or more other active paths (shared protection).
o one active and one standby path with guaranteed bandwidth on both
paths (1:1).
o one active path and a standby path the resources or which are
shared by one or more other active paths (shared protection).
The applicability of any given scheme to meet specific requirements 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.
The characteristics of MPLS-TP resiliency mechanisms are listed The characteristics of MPLS-TP resiliency mechanisms are as follows:
below.
o Optimised for linear, ring or meshed topologies. o Optimised for linear, ring or meshed topologies.
o Use OAM mechanisms to detect and localize network faults or o Use OAM mechanisms to detect and localise network faults or
service degenerations. service degenerations.
o Include protection mechanisms to coordinate and trigger protection o Include protection mechanisms to coordinate and trigger protection
switching actions in the absence of a dynamic control plane. This switching actions in the absence of a dynamic control plane. This
is known as an Automatic Protection Switching (APS) mechanism. is known as an Automatic Protection Switching (APS) mechanism.
o MPLS-TP recovery schemes are applicable to all levels in the o MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment
and end-to- end recovery. and end-to-end recovery.
o MPLS-TP recovery mechanisms support the coordination of protection o MPLS-TP recovery mechanisms support the coordination of protection
switching at multiple levels to prevent race conditions occurring switching at multiple levels to prevent race conditions occurring
between a client and its server 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 supports revertive and non-revertive behavior. o MPLS-TP supports revertive and non-revertive behaviour.
3.11. 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 [I-D.ietf-mpls-tp-nm-req]. It derives from the generic specified in [I-D.ietf-mpls-tp-nm-framework] and
[I-D.ietf-mpls-tp-nm-req]. These derive from the generic
specifications described in ITU-T G.7710/Y.1701 [G.7710] for specifications described in ITU-T G.7710/Y.1701 [G.7710] for
transport technologies. It also incorporates the OAM requirements transport technologies. It also incorporates the OAM requirements
for MPLS Networks [RFC4377] and MPLS-TP Networks for MPLS Networks [RFC4377] and MPLS-TP Networks
[I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements [I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements
to cover the modifications necessary for fault, configuration, to cover the modifications necessary for fault, configuration,
performance, and security in a transport network. performance, and security in a transport network.
The Equipment Management Function (EMF) of a MPLS-TP Network Element The Equipment Management Function (EMF) of an MPLS-TP Network Element
(NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through
which a management system manages the NE. The Management which a management system manages the NE. The Management
Communication Channel (MCC), realized by the G-ACh, provides a Communication Channel (MCC), realised by the G-ACh, provides a
logical operations channel between NEs for transferring Management logical operations channel between NEs for transferring Management
information. For the management interface from a management system information. For the management interface from a management system
to a MPLS-TP NE, there is no restriction on which management protocol to an MPLS-TP NE, there is no restriction on which management
should be used. It is used to provision and manage an end-to-end protocol is used. The MCC is used to provision and manage an end-to-
connection across a network where some segments are create/managed, end connection across a network where some segments are created/
for examples by Netconf or SNMP and other segments by XML or CORBA managed by, for example, Netconf or SNMP and other segments by XML or
interfaces. Maintenance operations are run on a connection (LSP or CORBA interfaces. Maintenance operations are run on a connection
PW) in a manner that is independent of the provisioning mechanism. (LSP or PW) in a manner that is independent of the provisioning
An MPLS-TP NE is not required to offer more than one standard mechanism. An MPLS-TP NE is not required to offer more than one
management interface. In MPLS-TP, the EMF must be capable of standard management interface. In MPLS-TP, the EMF must be capable
statically provisioning LSPs for an LSR or LER, and PWs for a PE, as of statically provisioning LSPs for an LSR or LER, and PWs for a PE,
per Section 3.9. as well as any associated MEPs and MIPs, as per Section 3.9.
Fault Management (FM) functions within the EMF of an MPLS-TP NE 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 conditions in the MPLS-TP network and and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. FM must provide for the supervision of transmission its environment. FM must provide for the supervision of transmission
(such as continuity, connectivity, etc.), software processing, (such as continuity, connectivity, etc.), software processing,
hardware, and environment. 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.
skipping to change at page 34, line 32 skipping to change at page 38, line 5
identify, collect data from, and provide data to MPLS-TP NEs. In identify, collect data from, and provide data to MPLS-TP NEs. In
addition to general configuration for hardware, software protection addition to general configuration for hardware, software protection
switching, alarm reporting control, and date/time setting, the EMF of switching, alarm reporting control, and date/time setting, the EMF of
the MPLS-TP NE also supports the configuration of maintenance entity the MPLS-TP NE also supports the configuration of maintenance entity
identifiers (such as MEP ID and MIP ID). The EMF also supports the identifiers (such as MEP ID and MIP ID). The EMF also supports the
configuration of OAM parameters as a part of connectivity management configuration of OAM parameters as a part of connectivity management
to meet specific operational requirements. These may specify whether to meet specific operational requirements. These may specify whether
the operational mode is one-time on-demand or is periodic at 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
TP NE support the evaluation and reporting of the behaviour of the MPLS-TP NE support the evaluation and reporting of the behaviour of
NEs and the network. One particular requirement for PM is to provide the NEs and the network. One particular requirement for PM is to
coherent and consistent interpretation of the network behaviour in a provide coherent and consistent interpretation of the network
hybrid network that uses multiple transport technologies. Packet behaviour in a hybrid network that uses multiple transport
loss measurement and delay measurements may be collected and used to technologies. Packet loss measurement and delay measurements may be
detect performance degradation. This is reported via fault collected and used to detect performance degradation. This is
management to enable corrective actions to be taken (e.g. Protection reported via fault management to enable corrective actions to be
switching), and via performance monitoring for Service Level taken (e.g. protection switching), and via performance monitoring for
Agreement (SLA) verification and billing. Collection mechanisms for Service Level Agreement (SLA) verification and billing. Collection
performance data should be should be capable of operating on-demand mechanisms for performance data should be capable of operating on-
or proactively. demand or pro-actively.
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 Transport
used to support packet transport services, the security Profile are used to support packet transport services, the security
considerations of that additional functionality also apply. considerations of that additional functionality also apply.
For pseudowires, the security considerations of [RFC3985] and For pseudowires, the security considerations of [RFC3985] and
[I-D.ietf-pwe3-ms-pw-arch] apply. [RFC5659] apply.
Packets that arrive on an interface with a given label value should Packets that arrive on an interface with a given label value should
not be forwarded unless that label value was previously assigned to not be forwarded unless that label value is assigned to an LSP or PW
an LSP or PW to a peer LSR or PE that it reachable via that to a peer LSR or PE that is reachable via that interface.
interface.
Each MPLS-TP solution must specify the additional security Each MPLS-TP solution must specify the additional security
considerations that apply. 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.
skipping to change at page 35, line 31 skipping to change at page 39, line 4
functionality. functionality.
This document introduces no additional IANA considerations in itself. This document introduces no additional IANA considerations in itself.
6. Acknowledgements 6. Acknowledgements
The editors wish to thank the following for their contribution to The editors wish to thank the following for their contribution to
this document: this document:
o Rahul Aggarwal o Rahul Aggarwal
o Dieter Beller o Dieter Beller
o Lou Berger
o Malcolm Betts o Malcolm Betts
o Italo Busi o Italo Busi
o John E Drake o John E Drake
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 The participants of ITU-T SG15
7. Open Issues 7. Open Issues
This section contains a list of issues that must be resolved before This section contains a list of issues that must be resolved before
last call. last call.
o Add addition detail on survivability architectures.
o Consider whether there is too much detail in the OAM, network
management, identifiers and control plane sections. Should this
framework document reduce the discussion on these topics in order
to minimise the dependency on other components not yet ready for
publication.
o There is some text missing from the network layer clients section. o There is some text missing from the network layer clients section.
Text is invited covering the use of out of band signaling on the Text is invited covering the use of out of band signaling
AC. associated with the AC.
o Need text to address how the LSR next hop MAC address is o Need text to address how the LSR next hop MAC address is
determined for Ethernet link layers when no IP (i.e. ARP) is determined for Ethernet link layers when no IP (i.e. ARP) is
available. If statically configured, what is the default? available. If statically configured, what is the default? 181209:
this will be addressed in the normative data plane draft
o Are there any other invariants of a typical LSR/PE architecture o Need to add section (Appendix) describing stack optizations for
that need to be clarified in the context of MPLS-TP. LSP and PWs
8. References o Add a section clarify what options are used for interdomain
operation e.g. inter-AS TE LSPs, MS-PW, LSP stitching, back-to-
back ACs
o Text reduction for the OAM, survivability and NM sections.
o Include summarised PST text
8. References
8.1. Normative References 8.1. Normative References
[G.7710] "ITU-T Recommendation G.7710/ [G.7710] "ITU-T Recommendation G.7710/
Y.1701 (07/07), "Common Y.1701 (07/07), "Common
equipment management function equipment management function
requirements"", 2005. requirements"", 2005.
[G.805] "ITU-T Recommendation G.805 [G.805] "ITU-T Recommendation G.805
(11/95), "Generic Functional (11/95), "Generic Functional
Architecture of Transport Architecture of Transport
Networks"", November 1995. Networks"", November 1995.
[RFC2119] Bradner, S., "Key words for use
in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and [RFC3031] Rosen, E., Viswanathan, A., and
R. Callon, "Multiprotocol Label R. Callon, "Multiprotocol Label
Switching Architecture", Switching Architecture",
RFC 3031, January 2001. RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, [RFC3032] Rosen, E., Tappan, D., Fedorkow,
G., Rekhter, Y., Farinacci, D., G., Rekhter, Y., Farinacci, D.,
Li, T., and A. Conta, "MPLS Li, T., and A. Conta, "MPLS
Label Stack Encoding", RFC 3032, Label Stack Encoding", RFC 3032,
January 2001. January 2001.
skipping to change at page 38, line 33 skipping to change at page 41, line 50
(VCCV): A Control Channel for (VCCV): A Control Channel for
Pseudowires", RFC 5085, Pseudowires", RFC 5085,
December 2007. December 2007.
[RFC5307] Kompella, K. and Y. Rekhter, [RFC5307] Kompella, K. and Y. Rekhter,
"IS-IS Extensions in Support of "IS-IS Extensions in Support of
Generalized Multi-Protocol Label Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 5307, Switching (GMPLS)", RFC 5307,
October 2008. October 2008.
[RFC5332] Eckert, T., Rosen, E., Aggarwal,
R., and Y. Rekhter, "MPLS
Multicast Encapsulations",
RFC 5332, August 2008.
[RFC5462] Andersson, L. and R. Asati, [RFC5462] Andersson, L. and R. Asati,
"Multiprotocol Label Switching "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" (MPLS) Label Stack Entry: "EXP"
Field Renamed to "Traffic Class" Field Renamed to "Traffic Class"
Field", RFC 5462, February 2009. Field", RFC 5462, February 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. [RFC5586] Bocci, M., Vigoureux, M., and S.
Bryant, "MPLS Generic Associated Bryant, "MPLS Generic Associated
Channel", RFC 5586, June 2009. Channel", RFC 5586, June 2009.
8.2. Informative References 8.2. Informative References
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K.,
Nadeau, T., and G. Swallow, "BFD Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", For MPLS LSPs",
draft-ietf-bfd-mpls-07 (work in draft-ietf-bfd-mpls-07 (work in
progress), June 2008. progress), June 2008.
[I-D.ietf-l2vpn-arp-mediation] Rosen, E., Shah, H., Heron, G., [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow,
and V. Kompella, "ARP Mediation "MPLS-TP Identifiers", draft-
for IP Interworking of Layer 2 ietf-mpls-tp-identifiers-00
VPN", draft-ietf-l2vpn-arp- (work in progress),
mediation-12 (work in progress), November 2009.
June 2009.
[I-D.ietf-mpls-tp-nm-req] Gray, E., Mansfield, S., and K. [I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E., and H.
Lam, "MPLS TP Network Management Lam, "MPLS-TP Network Management
Framework", draft-ietf-mpls-tp-
nm-framework-02 (work in
progress), November 2009.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, "MPLS
TP Network Management
Requirements", Requirements",
draft-ietf-mpls-tp-nm-req-05 draft-ietf-mpls-tp-nm-req-06
(work in progress), (work in progress),
September 2009. October 2009.
[I-D.ietf-mpls-tp-oam-framework] Busi, I. and B. Niven-Jenkins, [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and B.
"MPLS-TP OAM Framework and Niven-Jenkins, "MPLS-TP OAM
Overview", draft-ietf-mpls-tp- Framework", draft-ietf-mpls-tp-
oam-framework-01 (work in oam-framework-04 (work in
progress), July 2009. progress), December 2009.
[I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M. [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M.
Betts, "Requirements for OAM in Betts, "Requirements for OAM in
MPLS Transport Networks", draft- MPLS Transport Networks", draft-
ietf-mpls-tp-oam-requirements-03 ietf-mpls-tp-oam-requirements-04
(work in progress), August 2009. (work in progress),
December 2009.
[I-D.ietf-mpls-tp-rosetta-stone] Helvoort, H., Andersson, L., and
N. Sprecher, "A Thesaurus for
the Terminology used in
Multiprotocol Label Switching
Transport Profile (MPLS-TP)
drafts/RFCs and ITU-T's
Transport Network
Recommendations.", draft-ietf-
mpls-tp-rosetta-stone-00 (work
in progress), June 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N., Farrel, A., and H.
Shah, "Multiprotocol Label
Switching Transport Profile
Survivability Framework", draft-
ietf-mpls-tp-survive-fwk-00
(work in progress), April 2009.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Bitar, [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. Farrel,
N., Shah, H., Aissaoui, M., and "Multiprotocol Label Switching
F. Balus, "Dynamic Placement of Transport Profile Survivability
Multi Segment Pseudo Wires", Framework", draft-ietf-mpls-tp-
draft-ietf-pwe3-dynamic-ms-pw-09 survive-fwk-03 (work in
(work in progress), March 2009. progress), November 2009.
[I-D.ietf-pwe3-ms-pw-arch] Bocci, M. and S. Bryant, "An [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Balus,
Architecture for Multi-Segment F., Bitar, N., Shah, H.,
Pseudowire Emulation Edge-to- Aissaoui, M., Rusmisel, J.,
Edge", Serbest, Y., Malis, A., Metz,
draft-ietf-pwe3-ms-pw-arch-07 C., McDysan, D., Sugimoto, J.,
(work in progress), July 2009. Duckett, M., Loomis, M., Doolan,
P., Pan, P., Pate, P., Radoaca,
V., Wada, Y., and Y. Seo,
"Dynamic Placement of Multi
Segment Pseudo Wires",
draft-ietf-pwe3-dynamic-ms-pw-10
(work in progress),
October 2009.
[I-D.ietf-pwe3-redundancy] Muley, P. and M. Bocci, [I-D.ietf-pwe3-redundancy] Muley, P. and V. Place,
"Pseudowire (PW) Redundancy", "Pseudowire (PW) Redundancy",
draft-ietf-pwe3-redundancy-01 draft-ietf-pwe3-redundancy-02
(work in progress), (work in progress),
September 2008. October 2009.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz, [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz,
C., Duckett, M., Bocci, M., C., Duckett, M., Bocci, M.,
Balus, F., and M. Aissaoui, Balus, F., and M. Aissaoui,
"Segmented Pseudowire", "Segmented Pseudowire",
draft-ietf-pwe3-segmented-pw-13 draft-ietf-pwe3-segmented-pw-13
(work in progress), August 2009. (work in progress), August 2009.
[RFC0826] Plummer, D., "Ethernet Address [RFC3443] Agarwal, P. and B. Akyol, "Time
Resolution Protocol: Or To Live (TTL) Processing in
converting network protocol Multi-Protocol Label Switching
addresses to 48.bit Ethernet (MPLS) Networks", RFC 3443,
address for transmission on January 2003.
Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC2390] Bradley, T., Brown, C., and A.
Malis, "Inverse Address
Resolution Protocol", RFC 2390,
September 1998.
[RFC2461] Narten, T., Nordmark, E., and W.
Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3122] Conta, A., "Extensions to IPv6 [RFC3945] Mannie, E., "Generalized Multi-
Neighbor Discovery for Inverse Protocol Label Switching (GMPLS)
Discovery Specification", Architecture", RFC 3945,
RFC 3122, June 2001. October 2004.
[RFC4377] Nadeau, T., Morrow, M., Swallow, [RFC4377] Nadeau, T., Morrow, M., Swallow,
G., Allan, D., and S. G., Allan, D., and S.
Matsushima, "Operations and Matsushima, "Operations and
Management (OAM) Requirements Management (OAM) Requirements
for Multi-Protocol Label for Multi-Protocol Label
Switched (MPLS) Networks", Switched (MPLS) Networks",
RFC 4377, February 2006. RFC 4377, February 2006.
[RFC4379] Kompella, K. and G. Swallow, [RFC4379] Kompella, K. and G. Swallow,
skipping to change at page 41, line 31 skipping to change at page 44, line 25
Requirements to Support Requirements to Support
Operation of MPLS-TE over GMPLS Operation of MPLS-TE over GMPLS
Networks", RFC 5146, March 2008. Networks", RFC 5146, March 2008.
[RFC5254] Bitar, N., Bocci, M., and L. [RFC5254] Bitar, N., Bocci, M., and L.
Martini, "Requirements for Martini, "Requirements for
Multi-Segment Pseudowire Multi-Segment Pseudowire
Emulation Edge-to-Edge (PWE3)", Emulation Edge-to-Edge (PWE3)",
RFC 5254, October 2008. RFC 5254, October 2008.
[RFC5309] Shen, N. and A. Zinin, "Point-
to-Point Operation over LAN in
Link State Routing Protocols",
RFC 5309, October 2008.
[RFC5331] Aggarwal, R., Rekhter, Y., and
E. Rosen, "MPLS Upstream Label
Assignment and Context-Specific
Label Space", RFC 5331,
August 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., [RFC5654] Niven-Jenkins, B., Brungard, D.,
Betts, M., Sprecher, N., and S. Betts, M., Sprecher, N., and S.
Ueno, "Requirements of an MPLS Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, Transport Profile", RFC 5654,
September 2009. September 2009.
[RFC5659] Bocci, M. and S. Bryant, "An
Architecture for Multi-Segment
Pseudowire Emulation Edge-to-
Edge", RFC 5659, October 2009.
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: Phone:
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
skipping to change at line 1831 skipping to change at page 46, line 4
URI: URI:
Lieven Levrau Lieven Levrau
Alcatel-Lucent Alcatel-Lucent
7-9, Avenue Morane Sulnier 7-9, Avenue Morane Sulnier
Velizy 78141 Velizy 78141
France France
Phone: Phone:
EMail: lieven.levrau@alcatel-lucent.com EMail: lieven.levrau@alcatel-lucent.com
Lou Berger
LabN
Phone: +1-301-468-9228
Fax:
EMail: lberger@labn.net
URI:
 End of changes. 218 change blocks. 
863 lines changed or deleted 954 lines changed or added

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