draft-ietf-mpls-tp-framework-10.txt   draft-ietf-mpls-tp-framework-11.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational S. Bryant, Ed. Intended status: Informational S. Bryant, Ed.
Expires: August 8, 2010 D. Frost, Ed. Expires: October 4, 2010 D. Frost, Ed.
Cisco Systems Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN LabN
February 4, 2010 April 02, 2010
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-10 draft-ietf-mpls-tp-framework-11
Abstract Abstract
This document specifies an architectural framework for the This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched transport networks. It describes a construction of packet-switched transport networks. It describes a
common set of protocol functions - the MPLS Transport Profile common set of protocol functions - the MPLS Transport Profile
(MPLS-TP) - that supports the operational models and capabilities (MPLS-TP) - that supports the operational models and capabilities
typical of such networks, including signaled or explicitly typical of such networks, including signaled or explicitly
provisioned bi-directional connection-oriented paths, protection and provisioned bi-directional connection-oriented paths, protection and
restoration mechanisms, comprehensive Operations, Administration and restoration mechanisms, comprehensive Operations, Administration and
Maintenance (OAM) functions, and network operation in the absence of Maintenance (OAM) functions, and network operation in the absence of
a dynamic control plane or IP forwarding support. Some of these a dynamic control plane or IP forwarding support. Some of these
functions are defined in existing MPLS specifications, while others functions are defined in existing MPLS specifications, while others
require extensions to existing specifications to meet the require extensions to existing specifications to meet the
requirements of the MPLS-TP. requirements of the MPLS-TP.
This document defines the subset of the MPLS-TP applicable in general This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable and to point-to-point transport paths. The remaining subset,
specifically to point-to-multipoint paths, are out of scope of this applicable specifically to point-to-multipoint transport paths, is
document. outside the scope of this document.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as capabilities and functionalities of a packet transport network as
defined by the ITU-T. 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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 4, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
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. Transport Network . . . . . . . . . . . . . . . . . . 6 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router (LSR) and Label 1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8
Edge Router (LER) . . . . . . . . . . . . . . . . . . 7
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8
1.3.7. Edge-to-Edge LSP . . . . . . . . . . . . . . . . . . . 8 1.3.7. Edge-to-Edge LSP . . . . . . . . . . . . . . . . . . . 9
1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 8 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 9
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 8 1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 9
1.3.10. Additional Definitions and Terminology . . . . . . . . 9 1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 9
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 9 1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 9
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11 1.3.12. Additional Definitions and Terminology . . . . . . . . 9
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 10
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 10
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 10
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 11
3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15 3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 13
3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 13
3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17 3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 14
3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 18 3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 15
3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21 3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 16
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 17
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25 3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 23
3.7. Operations, Administration and Maintenance (OAM) . . . . . 28 3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 26
3.8. LSP Return Path . . . . . . . . . . . . . . . . . . . . . 30 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 31 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 30
3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 31 3.7. Operations, Administration and Maintenance (OAM) . . . . . 32
3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 32 3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 32 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 35
3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 32 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 35
3.10. Inter-domain Connectivity . . . . . . . . . . . . . . . . 35 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 36
3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 36
3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 35 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 36
3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 37 3.10. Interdomain Connectivity . . . . . . . . . . . . . . . . . 39
3.13.1. Provisioning of PST . . . . . . . . . . . . . . . . . 38 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 39
3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 38 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 39
3.15. Network Management . . . . . . . . . . . . . . . . . . . . 38 3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 41
4. Security Considerations . . . . . . . . . . . . . . . . . . . 39 3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 42
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 3.15. Network Management . . . . . . . . . . . . . . . . . . . . 42
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 4. Security Considerations . . . . . . . . . . . . . . . . . . . 44
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . . 43 7.1. Normative References . . . . . . . . . . . . . . . . . . . 45
7.2. Informative References . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
1.1. Motivation and Background 1.1. Motivation and Background
This document describes an architectural framework for the This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that networks. It specifies the common set of protocol functions that
meet the requirements in [RFC5654], and that together constitute the meet the requirements in [RFC5654], and that together constitute the
MPLS Transport Profile (MPLS-TP) for point-to-point paths. The MPLS Transport Profile (MPLS-TP) for point-to-point transport paths.
remaining MPLS-TP functions, applicable specifically to point-to- The remaining MPLS-TP functions, applicable specifically to point-to-
multipoint paths, are out of scope of this document. multipoint transport paths, are outside the scope of this document.
Historically the optical transport infrastructure - Synchronous Historically the optical transport infrastructure - Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical
Transport Network (OTN) - has provided carriers with a high benchmark Transport Network (OTN) - has provided carriers with a high benchmark
for reliability and operational simplicity. To achieve this, for reliability and operational simplicity. To achieve 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 (i.e. configuration of the node and may be provisioned manually, for example by network management
via a command line interface) or by network management. systems or direct node configuration using a command line
interface.
o A high level of availability. o A high level of availability.
o Quality of service. o Quality of service.
o Extensive OAM capabilities. o Extensive OAM capabilities.
Carriers wish to evolve such transport networks to take advantage of Carriers wish to evolve such transport networks to take advantage of
the flexibility and cost benefits of packet switching technology and the flexibility and cost benefits of packet switching technology and
to support packet based services more efficiently. While MPLS is a to support packet based services more efficiently. While MPLS is a
maturing packet technology that already plays an important role in maturing packet technology that already plays an important role in
transport networks and services, not all MPLS capabilities and transport networks and services, not all MPLS capabilities and
mechanisms are needed in or consistent with the transport network mechanisms are needed in, or consistent with, the transport network
operational model. There are also transport technology operational model. There are also transport technology
characteristics that are not currently reflected in MPLS. 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
skipping to change at page 5, line 27 skipping to change at page 5, line 29
defined by the ITU-T. 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 the construction of packet-switched transport application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that networks. It specifies the common set of protocol functions that
meet the requirements in [RFC5654], and that together constitute the meet the requirements in [RFC5654], and that together constitute the
MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport
paths. The remaining MPLS-TP functions, applicable specifically to paths. The remaining MPLS-TP functions, applicable specifically to
point-to-multipoint transport paths, are out of scope of this point-to-multipoint transport paths, are outside the scope of this
document. 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 G-ACh Label GAL G-ACh Label
MEP Maintenance End Point MEG Maintenance Entity Group
MIP Maintenance Intermediate Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group 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 Switching Router LSR Label Switching Router
MPLS-TP PE MPLS-TP Provider Edge LSR MPLS-TP PE MPLS-TP Provider Edge LSR
MPLS-TP P MPLS-TP Provider LSR MPLS-TP P MPLS-TP Provider LSR
PW Pseudowire PW Pseudowire
AC Attachment Circuit AC Attachment Circuit
Adaptation The mapping of client information into a format suitable Adaptation The mapping of client information into a format suitable
for transport by the server layer for transport by the server layer
Native The traffic belonging to the client of the MPLS-TP network Native The traffic belonging to the client of the MPLS-TP network
Service Service
T-PE PW Terminating Provider Edge T-PE PW Terminating Provider Edge
S-PE PW Switching provider Edge S-PE PW Switching provider Edge
PST Path Segment Tunnel
1.3.1. Transport Network 1.3.1. Transport Network
A Transport Network provides transparent transmission of client user A Transport Network provides transparent transmission of client user
plane traffic between attached client devices by establishing and plane traffic between attached client devices by establishing and
maintaining point-to-point or point-to-multipoint connections between maintaining point-to-point or point-to-multipoint connections between
such devices. The architecture of networks supporting point to such devices. The architecture of networks supporting point to
multipoint connections is out of scope of this document. A Transport multipoint connections is outside the scope of this document. A
Network is independent of any higher-layer network that may exist Transport Network is independent of any higher-layer network that may
between clients, except to the extent required to supply this exist between clients, except to the extent required to supply this
transmission service. In addition to client traffic, a Transport transmission service. In addition to client traffic, a Transport
Network may carry traffic to facilitate its own operation, such as Network may carry traffic to facilitate its own operation, such as
that required to support connection control, network management, and that required to support connection control, network management, and
Operations, Administration and Maintenance (OAM) functions. Operations, Administration and Maintenance (OAM) functions.
See also the definition of Packet Transport Service in Section 3.1. See also the definition of Packet Transport Service in Section 3.1.
1.3.2. MPLS Transport Profile 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 IETF, including those capabilities specifically added to support
transport network requirements [RFC5654]. transport network requirements [RFC5654].
1.3.3. MPLS-TP Section 1.3.3. MPLS-TP Section
An MPLS-TP Section is defined in Section 1.2.2 of [RFC5654]. MPLS-TP Sections are defined in [I-D.ietf-mpls-tp-data-plane]. See
also the definition of "section layer network" in Section 1.2.2 of
[RFC5654].
1.3.4. 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 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. May be established and maintained via the management plane, or 4. May be established and maintained via the management plane, or
using GMPLS protocols when a control plane is used. using GMPLS protocols when a control plane is used.
5. Is either point-to-point or point-to-multipoint. Multipoint to 5. Is either point-to-point or point-to-multipoint. Multipoint-to-
point and multipoint to multipoint LSPs are not permitted. point and multipoint-to-multipoint LSPs are not supported.
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, including those specifically added to support the MPLS capability, including those specifically added to support the
transport network requirements. transport network requirements.
1.3.5. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER) See [I-D.ietf-mpls-tp-data-plane] for further details on the types
and data-plane properties of MPLS-TP LSPs.
The lowest server layer provided by MPLS-TP is an MPLS-TP LSP. The
client layers of an MPLS-TP LSP may be network layer protocols, MPLS
LSPs, or PWs. The relationship of an MPLS-TP LSP to its client
layers is described in detail in Section 3.4.
1.3.5. MPLS-TP Label Switching Router
An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider
Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP, 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 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 describe logical functions; a specific node may undertake only one of
these roles on a given LSP. 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.5.1. MPLS-TP Provider Edge (PE) Router 1.3.5.1. Label Edge Router
An MPLS-TP Label Edge Router (LER) is an LSR that exists at the
endpoints of an LSP and therefore pushes or pops the LSP label, i.e.
does not perform a label swap on the particular LSP under
consideration.
1.3.5.2. MPLS-TP Provider Edge Router
An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts
client traffic and encapsulates it to be transported over an MPLS-TP client traffic and encapsulates it to be transported over an MPLS-TP
LSP. Encapsulation may be as simple as pushing a label, or it may LSP. Encapsulation may be as simple as pushing a label, or it may
require the use of a pseudowire. An MPLS-TP PE exists at the require the use of a pseudowire. An MPLS-TP PE exists at the
interface between a pair of layer networks. For an MS-PW, an MPLS-TP interface between a pair of layer networks. For an MS-PW, an MPLS-TP
PE may be either an S-PE or a T-PE, as defined in [RFC5659]. PE may be either an S-PE or a T-PE, as defined in [RFC5659]. A PE
that pushes or pops a label is an LER.
1.3.5.2. MPLS-TP Provider (P) Router 1.3.5.3. MPLS-TP Provider 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 for a given LSP. An MPLS-TP P router MPLS-TP PE functionality for a given LSP. An MPLS-TP P router
switches LSPs which carry client traffic, but does not adapt client switches LSPs which carry client traffic, but does not adapt client
traffic and 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.3. Label Edge Router (LER)
An LSR that exists at the endpoints of an LSP and therefore pushes or
pops a label, i.e. does not perform a label swap on the particular
LSP under consideration.
1.3.6. Customer Edge (CE) 1.3.6. Customer Edge (CE)
A Customer Edge (CE) is the client function sourcing or sinking A Customer Edge (CE) is the client function sourcing or sinking
native service traffic to or from the MPLS-TP network. CEs on either native service traffic to or from the MPLS-TP network. CEs on either
side of the MPLS-TP network are peers and view the MPLS-TP network as side of the MPLS-TP network are peers and view the MPLS-TP network as
a single point-to-point or point-to-multipoint link. a single link.
1.3.7. Edge-to-Edge LSP 1.3.7. Edge-to-Edge LSP
An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit
zero or more provider LSRs. zero or more provider LSRs.
1.3.8. Service LSP 1.3.8. Service LSP
A service LSP is an LSP that carries a single client service. A service LSP is an LSP that carries a single client service.
1.3.9. Layer Network 1.3.9. Layer Network
A layer network is defined in [G.805] and described in [RFC5654]. A layer network is defined in [G.805] and described in [RFC5654].
1.3.10. Additional Definitions and Terminology 1.3.10. Network Layer
Detailed definitions and additional terminology may be found in
[RFC5654].
1.4. Applicability
MPLS-TP can be used to construct packet transport networks and is
therefore applicable in any packet transport network context. It is
also applicable to subsets of a packet network where the transport
network operational model is deemed attractive. The following are
examples of MPLS-TP applicability models:
1. MPLS-TP provided by a network that only supports MPLS-TP LSPs and
PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or
LSRs), acting as a server for other layer 1, layer 2 and layer 3
networks (Figure 1).
2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs
and PWs (i.e. both LSPs and PWs that conform to the transport
profile and those that do not, exist between the PEs), acting as
a server for other layer 1, layer 2 and layer 3 networks
(Figure 2).
3. MPLS-TP as a server layer for client layer traffic of IP or MPLS
networks which do not use functions of the MPLS transport
profile. For MPLS traffic, the MPLS-TP server layer network uses
PW switching [RFC5659] or LSP stitching [RFC5150] at the PE that
terminates the MPLS-TP server layer (Figure 3).
These models are not mutually exclusive.
MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as
a server for other layer 1, layer 2 and layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->|
Only
MPLS-TP
+---+ LSP +---+
+---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+
+---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ]
[-TP LSP ]
b) [ IP ] [ IP ] [ IP ]
[ Demux ]
[-TP LSP ]
Figure 1: MPLS-TP Server Layer Example
MPLS-TP LSP, provided by a network that also supports non-MPLS-TP
functions, acting as a server for other layer 1, layer 2 and
layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->|
MPLS-TP
+---+ LSP +---+
+---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+
+---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ]
[-TP LSP ]
b) [ IP ] [ IP ] [ IP ]
[ Demux ]
[-TP LSP ]
Figure 2: MPLS-TP in MPLS Network Example This document uses the term Network Layer in the same sense as it is
used in [RFC3031] and [RFC3032].
MPLS-TP as a server layer for client layer traffic of IP or MPLS 1.3.11. Service Interface
networks which do not use functions of the MPLS transport
profile.
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| The packet transport service provided by MPLS-TP is provided at a
Only service interface. Two types of service interfaces are defined (see
:
+---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ o User-Network Interface (UNI) (see Section 3.4.3.1).
|CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2|
+---+ +----+ +----+ +----+ +----+ +---+
(PW switching) (PW switching)
(a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ] o Network-Network Interface (NNI) (see Section 3.4.3.2).
[ PW Seg ] [ PW Seg ] [ PW Seg ]
[ LSP ] [-TP LSP ] [ LSP ]
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| A UNI service interface may be a layer 2 interface that carries only
Only network layer clients. MPLS-TP LSPs are both necessary and
sufficient to support this service interface as described in section
3.4.3. Alternatively, it may be a layer 2 interface that carries
both network layer and non-network layer clients. To support this
service interface, a PW is required to adapt the client traffic
received over the service interface. This PW in turn is a client of
the MPLS-TP server layer. This is described in section 3.4.2.
+---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ An NNI service interface may be to an MPLS LSP or a PW. To support
|CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2| this case an MPLS-TP PE participates in the service interface
+---+ +----+ +----+ +----+ +----+ +---+ signaling.
(LSP stitching) (LSP stitching)
(b) [ IP ] [ IP ] [ IP ] [ IP ] [ IP ] 1.3.12. Additional Definitions and Terminology
[ LSP ] [-TP LSP ] [ LSP ]
Figure 3: MPLS-TP Transporting Client Service Traffic Detailed definitions and additional terminology may be found in
[RFC5654].
2. MPLS Transport Profile Requirements 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. It is
therefore not normative. It is not intended as a substitute for not normative or 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.
Point to point LSPs may be unidirectional or bi-directional, and it Point to point LSPs may be unidirectional or bi-directional, and it
must be possible to construct congruent Bi-directional LSPs. must be possible to construct congruent Bi-directional LSPs.
MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
must be possible to detect if a merged LSP has been created. must be possible to detect if a merged LSP has been created.
skipping to change at page 13, line 15 skipping to change at page 11, line 31
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.
These characteristics imply that a packet transport service does not These characteristics imply that a packet transport service does not
support a connectionless packet-switched forwarding mode. However, support a connectionless packet-switched forwarding mode. However,
this does not preclude it carrying client traffic associated with a this does not preclude it carrying client traffic associated with a
connectionless service. connectionless service.
Such packet transport services are very similar to Layer 2 Virtual
Private Networks as defined by the IETF.
3.2. Scope of the MPLS Transport Profile 3.2. Scope of the MPLS Transport Profile
Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are Figure 1 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 subset of MPLS, and comprises only those functions that are strict subset of MPLS, and comprises only those functions that are
necessary to meet the requirements of [RFC5654]. This includes MPLS necessary to meet the requirements of [RFC5654]. This includes MPLS
functions that were defined prior to [RFC5654] but that meet the functions that were defined prior to [RFC5654] but that meet the
requirements of [RFC5654], together with additional functions defined requirements of [RFC5654], together with additional functions defined
to meet those requirements. Some MPLS functions defined before to meet those requirements. Some MPLS functions defined before
[RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a [RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a
way that it creates multipoint-to-point LSPs, and IP forwarding in way that it creates multipoint-to-point LSPs, and IP forwarding in
the data plane are explicitly excluded from MPLS-TP by that the data plane are explicitly excluded from MPLS-TP by that
requirements specification. requirements specification.
skipping to change at page 14, line 5 skipping to change at page 12, line 17
|<============= Pre-RFC5654 MPLS ================>| |<============= Pre-RFC5654 MPLS ================>|
{ ECMP } { ECMP }
{ LDP/non-TE LSPs } { LDP/non-TE LSPs }
{ IP fwd } { IP fwd }
|<================ MPLS-TP ====================>| |<================ MPLS-TP ====================>|
{ Additional } { Additional }
{ Transport } { Transport }
{ Functions } { Functions }
Figure 4: Scope of MPLS-TP Figure 1: Scope of MPLS-TP
3.3. Architecture 3.3. Architecture
MPLS-TP comprises the following architectural elements: MPLS-TP comprises the following architectural elements:
o A standard MPLS data plane [RFC3031] as profiled in o A standard MPLS data plane [RFC3031] as profiled in
[I-D.fbb-mpls-tp-data-plane]. [I-D.ietf-mpls-tp-data-plane].
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, such (OAM) functions to monitor and diagnose the MPLS-TP network, as
as connectivity check, connectivity verification, performance outlined in [I-D.ietf-mpls-tp-oam-framework].
monitoring and fault localisation.
o Optional control planes for LSPs and PWs, as well as support for o Optional control planes for LSPs and PWs, as well as support for
static provisioning and configuration. static provisioning and configuration.
o Optional path protection mechanisms to ensure that the packet o Optional path protection mechanisms to ensure that the packet
transport service survives anticipated failures and degradations transport service survives anticipated failures and degradations
of the MPLS-TP network. of the MPLS-TP network, as outlined in
[I-D.ietf-mpls-tp-survive-fwk].
o Network management functions. o Network management functions, as outlined in
[I-D.ietf-mpls-tp-nm-framework].
The MPLS-TP architecture for LSPs and PWs includes the following two The MPLS-TP architecture for LSPs and PWs includes the following two
sets of functions: sets of functions:
o MPLS-TP client adaptation o MPLS-TP native service adaptation
o MPLS-TP forwarding o MPLS-TP forwarding
The adaptation functions interface the native service to MPLS-TP. The adaptation functions interface the native service (i.e. the
This includes the case where the native service is an MPLS-TP LSP. client layer network service) to MPLS-TP. This includes the case
where the native service is an MPLS-TP LSP.
The forwarding functions comprise the mechanisms required for The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client traffic over an MPLS-TP server forwarding the encapsulated native service traffic over an MPLS-TP
layer network, for example PW and LSP labels. server layer network, for example PW and LSP labels.
3.3.1. MPLS-TP Client Adaptation Functions 3.3.1. MPLS-TP Native Service Adaptation Functions
The MPLS-TP native service adaptation functions interface the client The MPLS-TP native service adaptation functions interface the client
service to MPLS-TP. For pseudowires, these adaptation functions are layer network service to MPLS-TP. For pseudowires, these adaptation
the payload encapsulation described in Section 4.4 of [RFC3985] and functions are the payload encapsulation described in Section 4.4 of
Section 6 of [RFC5659]. For network layer client services, the [RFC3985] and Section 6 of [RFC5659]. For network layer client
adaptation function uses the MPLS encapsulation format as defined in services, the adaptation function uses the MPLS encapsulation format
[RFC3032]. as defined in [RFC3032].
The purpose of this encapsulation is to abstract the client service The purpose of this encapsulation is to abstract the client layer
data plane from the MPLS-TP data plane, thus contributing to the network data plane from the MPLS-TP data plane, thus contributing to
independent operation of the MPLS-TP network. the 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 Quality of Service (QoS) from the The MPLS-TP client inherits its Quality of Service (QoS) from the
MPLS-TP network, which in turn inherits its QoS from the server MPLS-TP network, which in turn inherits its QoS from the server
layer. The server layer must therefore provide the necessary QoS to layer. The server layer must therefore provide the necessary QoS to
ensure that the MPLS-TP client QoS commitments can be 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 native service traffic over an MPLS-TP
network, for example PW and LSP labels. server layer 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], [RFC3032] and [RFC3443],
operations are highly optimised for performance and are not modified as profiled in [I-D.ietf-mpls-tp-data-plane]. These operations are
by the MPLS-TP profile. highly optimised for performance and are not modified by the MPLS-TP
profile.
In addition, MPLS-TP PWs use the SS-PW and MS-PW forwarding In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW
operations defined in [RFC3985] and [RFC5659]. The PW label is forwarding operations defined in [RFC3985] and [RFC5659].
processed by a PW forwarder and is always at the bottom of the label
stack for a given MPLS-TP layer network.
Per-platform label space is used for PWs. Either per-platform, per- Per-platform label space is used for PWs. Either per-platform, per-
interface or other context-specific label space [RFC5331] may be used interface or other context-specific label space [RFC5331] may be used
for LSPs. 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 designing protocol extensions that require taken into account when designing protocol extensions (such as those
packets (e.g. OAM packets) to be sent to an intermediate LSR. for OAM) that require 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, or the exposes a specific reserved label at the top of the stack, or the
packet is received with the GAL (Section 3.6) at the top of stack. packet is received with the GAL (Section 3.6) at the top of stack.
Otherwise the packet is forwarded according to the procedures in Otherwise the packet is forwarded according to the procedures in
[RFC3032]. [RFC3032].
Point-to-point MPLS-TP LSPs can be either unidirectional or
bidirectional.
It must be possible to configure an MPLS-TP LSP such that the forward
and backward directions of a bidirectional MPLS-TP LSP are co-routed,
i.e. follow the same path. The pairing relationship between the
forward and the backward directions must be known at each LSR or LER
on a bidirectional LSP.
In normal conditions, all the packets sent over a PW or an LSP follow
the same path through the network and those that belong to a common
ordered aggregate are delivered in order. For example per-packet
equal cost multi-path (ECMP) load balancing is not applicable to
MPLS-TP LSPs.
Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.
MPLS-TP supports Quality of Service capabilities via the MPLS MPLS-TP supports Quality of Service capabilities via the MPLS
Differentiated Services (DiffServ) architecture [RFC3270]. Both Differentiated Services (DiffServ) architecture [RFC3270]. Both
E-LSP and L-LSP MPLS DiffServ modes are supported. The Traffic Class E-LSP and L-LSP MPLS DiffServ modes are supported.
field (formerly the EXP field) of an MPLS label follows the
definition and processing rules of [RFC5462] and [RFC3270]. Note
that packet reordering between flows belonging to different traffic
classes may occur if more than one traffic class is supported on a
single LSP.
Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing Further details of MPLS-TP forwarding can be found in
models described in [RFC3270] and [RFC3443] are supported in MPLS-TP. [I-D.ietf-mpls-tp-data-plane].
3.4. MPLS-TP Native Services 3.4. MPLS-TP Native Service Adaptation
This document describes the architecture for two native service This document describes the architecture for two native service
adaptation mechanisms, which provide encapsulation and demultiplexing adaptation mechanisms, which provide encapsulation and demultiplexing
for native service traffic traversing an MPLS-TP network: for native service traffic traversing an MPLS-TP network:
o A PW o A PW
o An MPLS Label o An MPLS Label
A PW provides any emulated service that the IETF has defined to be A PW provides any emulated service that the IETF has defined to be
provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A
registry of PW types is maintained by IANA. When the native service list of PW types is maintained by IANA in the the "MPLS Pseudowire
adaptation is via a PW, the mechanisms described in Section 3.4.2 are Type" registry. When the native service adaptation is via a PW, the
used. mechanisms described in Section 3.4.4 are used.
An MPLS LSP Label can also be used as the adaptation, in which case An MPLS LSP Label can also be used as the adaptation, in which case
any native service traffic type supported by [RFC3031] and [RFC3032] any native service traffic type supported by [RFC3031] and [RFC3032]
is allowed. Examples of such traffic types include IP, and MPLS- is allowed. Examples of such traffic types include IP, and MPLS-
labeled packets. Note that the latter case includes TE-LSPs labeled packets. Note that the latter case includes TE-LSPs
[RFC3209] and LSP based applications such as PWs, Layer 2 VPNs [RFC3209] and LSP based applications such as PWs, Layer 2 VPNs
[RFC4664], and Layer 3 VPNs [RFC4364]. When the native service [RFC4664], and Layer 3 VPNs [RFC4364]. When the native service
adaptation is via an MPLS label, the mechanisms described in adaptation is via an MPLS label, the mechanisms described in
Section 3.4.3 are used. Section 3.4.5 are used.
3.4.1. MPLS-TP Client/Server Relationship 3.4.1. MPLS-TP Client/Server Layer Relationship
The MPLS-TP client server relationship is defined by the MPLS-TP The relationship between the client layer network and the MPLS-TP
network boundary and the label context. It is not explicitly server layer network is defined by the MPLS-TP network boundary and
indicated in the packet. In terms of the MPLS label stack, when the the label context. It is not explicitly indicated in the packet. In
client traffic type of the MPLS-TP network is an MPLS LSP or a PW, terms of the MPLS label stack, when the native service traffic type
then the S bits of all the labels in the MPLS-TP label stack carrying is itself MPLS-labeled, then the S bits of all the labels in the
that client traffic are zero; otherwise the bottom label of the MPLS-TP label stack carrying that client traffic are zero; otherwise
MPLS-TP label stack has the S bit set to 1 (i.e. there can only one S the bottom label of the MPLS-TP label stack has the S-bit set to 1.
bit set in a label stack). In other words, there can be only one S-bit set in a label stack.
The data plane behaviour of MPLS-TP is the same as the best current 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 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 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 in the label stack that is contiguous between the MPLS-TP server
the client layer. Note that this best current practise differs layer and the client layer. Note that this best current practice
slightly from [RFC3032] which uses the S-bit to identify when MPLS differs slightly from [RFC3032] which uses the S-bit to identify when
label processing stops and network layer processing starts. MPLS label processing stops and network layer processing starts.
The relationship of MPLS-TP to its clients is illustrated in The relationship of MPLS-TP to its clients is illustrated in
Figure 5. Figure 2. Note that the label stacks shown in the figure are divided
between those inside the MPLS-TP Network and those within the client
network when the client network is MPLS(-TP). They illustrate the
smallest number of labels possible. These label stacks could also
include more labels.
PW-Based MPLS Labelled IP PW-Based MPLS Labelled IP
Services Services Transport Services Services Transport
|------------| |-----------------------------| |------------| |------------| |-----------------------------| |------------|
Emulated PW over LSP IP over LSP IP Emulated PW over LSP IP over LSP IP
Service Service
+------------+ +------------+
| PW Payload | | PW Payload |
+------------+ +------------+ (CLIENTS) +------------+ +------------+ (CLIENTS)
|PW Lbl(S=1) | | IP | |PW Lbl(S=1) | | IP |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP | | PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)| |PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)| |LSP Lbl(S=0)| . . .
+------------+ (MPLS-TP) +------------+ . . . (MPLS-TP)
. . . .
.
.
~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary ~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary
Note that in the PW over LSP case the client may omit its LSP Label if Figure 2: MPLS-TP - Client Relationship
penultimate hop popping has been agreed with its peer 3.4.2. MPLS-TP Transport Layers
Figure 5: MPLS-TP - Client Relationship An MPLS-TP network consists logically of two layers: the Transport
Service layer and the Transport Path layer.
The data plane behaviour of MPLS-TP is the same as the best current The Transport Service layer provides the interface between Customer
practise for MPLS. This includes the setting of the S-Bit. In each Edge (CE) nodes and the MPLS-TP network. Each packet transmitted by
case, the S-bit is set to indicate the bottom (i.e. inner-most) label a CE node for transport over the MPLS-TP network is associated at the
in the label stack that is contiguous between the MPLS-TP server and receiving MPLS-TP Provider Edge (PE) node with a single logical
the client layer. point-to-point connection at the Transport Service layer between this
(ingress) PE and the corresponding (egress) PE to which the peer CE
is attached. Such a connection is called an MPLS-TP Transport
Service Instance, and the set of client packets associated with such
an instance on a particular CE-PE link is called a client flow.
Note that the label stacks shown above are divided between those The Transport Path layer provides aggregation of Transport Service
inside the MPLS-TP Network and those within the client network when Instances over MPLS-TP transport paths (LSPs), as well as aggregation
the client network is MPLS(-TP). They illustrate the smallest number of transport paths (via LSP hierarchy).
of labels possible. These label stacks could also include more
labels.
3.4.2. Pseudowire Adaptation Awareness of the Transport Service layer need exist only at PE nodes.
MPLS-TP Provider (P) nodes need have no awareness of this layer.
Both PE and P nodes participate in the Transport Path layer. A PE
terminates (i.e., is an LER with respect to) the transport paths it
supports, and is responsible for multiplexing and demultiplexing of
Transport Service Instance traffic over such transport paths.
The architecture for an MPLS-TP network that provides PW emulated 3.4.3. MPLS-TP Transport Service Interfaces
services is based on the MPLS [RFC3031] and pseudowire [RFC3985]
architectures. Multi-segment pseudowires may optionally be used to
provide a packet transport service, and their use is consistent with
the MPLS-TP architecture. The use of MS-PWs may be motivated by, for
example, the requirements specified in [RFC5254]. If MS-PWs are
used, then the MS-PW architecture [RFC5659] also applies.
Figure 6 shows the architecture for an MPLS-TP network using single- An MPLS-TP PE node can provide two types of interface to the
segment PWs. Transport Service layer. The MPLS-TP User-Network Interface (UNI)
provides the interface between a CE and the MPLS-TP network. The
MPLS-TP Network-Network Interface (NNI) provides the interface
between two MPLS-TP PEs in different administrative domains.
|<--------------- Emulated Service ----------------->| When providing a Virtual Private Wire Service (VPWS), Virtual Private
Local Area Network Service (VPLS), Virtual Private Multicast Service
(VPMS), or Internet Protocol Local Area Network Service (IPLS),
pseudowires must be used to carry the client service. VPWS, VLPS,
and IPLS are described in [RFC4664]. VPMS is described in
[I-D.ietf-l2vpn-vpms-frmwk-requirements].
When MPLS-TP is used to provide a transport service for e.g. IP
services that are a part of a Layer 3 VPN, then packets are
transported in the same manner as specified in [RFC4364].
3.4.3.1. User-Network Interface
The MPLS-TP User-Network interface (UNI) is illustrated in Figure 3.
The UNI for a particular client flow may or may not involve signaling
between the CE and PE, and if signaling is used, it may or may not
traverse the same data-link that supports the client flow.
: User-Network Interface : MPLS-TP
:<-------------------------------------->: Network <----->
: :
-:------------- --------------:------------------
: | | : Transport |
: | | Transport : Path |
: | | Service : Mux/Demux |
: | | Control : -- |
: | | Plane : | | Transport|
: ---------- | Signaling | ---------- : | | Path |
:|Signaling |_|___________|_|Signaling | : | | --------->
:|Controller| | | |Controller| : | | |
: ---------- | | ---------- : | | --------->
: :......|...........|......: : | | |
: | Control | : | | Transport|
: | Channel | : | | Path |
: | | : | | --------->
: | | : | | -+----------->TSI
: | | Transport : | | | --------->
: | Client | Service : | | | |
: | Traffic | Data Plane : | | | |
: ---------- | Flows | -------------- | | |Transport|
:|Signaling |-|-----------|-|Client/Service|-| |- Path |
:|Controller|=|===========|=| Traffic | | | --------->
: ---------- | | | Processing |=| |===+===========>TSI
: | | | -------------- | | --------->
: |______|___________|______| : | | |
: | Data Link | : | | |
: | | : -- |
: | | : Transport |
: | | : Service |
: | | : Data Plane|
--------------- ---------------------------------
Customer Edge Node MPLS-TP Provider Edge Node
TSI = Transport Service Instance
Client/Service Traffic Processing Stages
:
--------------From UNI-------> :
-------------------------------------------:------------------
| | Client Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Transport |
| | Service Instance : Encapsulation |
| | Identification : |
-------------------------------------------:------------------
:
:
-------------------------------------------:------------------
| | : Service Instance |
| | : Transport |
| Link-Layer-Specific | Client Traffic Unit : Decapsulation |
| Processing | Link Encapsulation : & |
| | : Service Instance |
| | : Identification |
-------------------------------------------:------------------
<-------------To UNI --------- :
Figure 3: MPLS-TP PE Containing a UNI
The figure shows the logical processing steps involved in a PE both
for traffic flowing from the CE to the MPLS-TP network (left to
right), and from the network to the CE (right to left).
In the first case, when a packet from a client flow is received by
the PE from the CE over the data-link, the following steps occur:
1. Link-layer specific preprocessing, if any, is performed. An
example of such preprocessing is the PREP function illustrated in
Figure 3 of [RFC3985]. Such preprocessing is outside the scope
of MPLS-TP.
2. The packet is extracted from the data-link frame if necessary,
and associated with a Transport Service Instance. At this point,
UNI processing has completed.
3. A transport service encapsulation is associated with the packet,
if necessary, for transport over the MPLS-TP network.
4. The packet is mapped to a transport path based on its associated
Transport Service Instance, the transport path encapsulation is
added, if necessary, and the packet is transmitted over the
transport path.
In the second case, when a packet associated with a Transport Service
Instance arrives over a transport path, the following steps occur:
1. The transport path encapsulation is disposed of.
2. The transport service encapsulation is disposed of and the
Transport Service Instance and client flow identified.
3. At this point, UNI processing begins. A data-link encapsulation
is associated with the packet for delivery to the CE based on the
client flow.
4. Link-layer-specific postprocessing, if any, is performed. Such
postprocessing is outside the scope of MPLS-TP.
3.4.3.2. Network-Network Interface
The MPLS-TP NNI is illustrated in Figure 4. The NNI for a particular
transport service instance may or may not involve signaling between
the two PEs, and if signaling is used, it may or may not traverse the
same data-link that supports the service instance.
: Network-Network Interface :
:<--------------------------------->:
: :
------------:------------- -------------:------------
| Transport : | | : Transport |
| Path : Transport | | Transport : Path |
| Mux/Demux : Service | | Service : Mux/Demux |
| -- : Control | | Control : -- |
| | | : Plane |Sig- | Plane : | | |
|TP | | : ---------- | naling| ---------- : | | TP|
<--- | | :|Signaling |_|_______|_|Signaling |: | | --->
TSI<-+- | | :|Controller| | | |Controller|: | | |
<--- | | | : ---------- | | ---------- : | | --->
| | | | : :......|.......|......: : | | |
| | | | : |Control| : | | |
|TP | | | : |Channel| : | | TP|
<--- | | | : | | : | | --->
| | | | : | | : | | -+->TSI
<--- | | | : Transport | | Transport : | | | --->
| | | | : Service |Service| Service : | | | |
| | | | : Data Plane |Traffic| Data Plane : | | | |
| | | | ------------- | Flows | ------------- | | | |
|TP -| |-| Service |-|-------|-| Service |-| |- TP|
<--- | | | Traffic | | | | Traffic | | | --->
TSI<=+===| |=| Processing |=|=======|=| Processing |=| |===+=>TSI
<--- | | ------------- | | ------------- | | --->
| | | : |______|_______|______| : | | |
| | | : | Data | : | | |
| -- : | Link | : -- |
| : | | : |
-------------------------- --------------------------
MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node
TP = Transport Path
TSI = Transport Service Instance
Service Traffic Processing Stages
:
--------------From NNI-------> :
--------------------------------------------:------------------
| | Service Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Encapsulation |
| | Service Instance : Normalisation |
| | Identification : |
--------------------------------------------:------------------
:
:
--------------------------------------------:------------------
| | : Service Instance |
| | : Identification |
| Link-Layer-Specific | Service Traffic Unit : & |
| Processing | Link Encapsulation : Service Instance |
| | : Encapsulation |
| | : Normalisation |
--------------------------------------------:------------------
<-------------To NNI --------- :
Figure 4: MPLS-TP PE Containing an NNI
The figure shows the logical processing steps involved in a PE for
traffic flowing both from the peer PE (left to right) and to the peer
PE (right to left).
In the first case, when a packet from a transport service instance is
received by the PE from the peer PE over the data-link, the following
steps occur:
1. Link-layer specific preprocessing, if any, is performed. Such
preprocessing is outside the scope of MPLS-TP.
2. The packet is extracted from the data-link frame if necessary,
and associated with a Transport Service Instance. At this point,
NNI processing has completed.
3. The transport service encapsulation of the packet is normalised
for transport over the MPLS-TP network. This step allows a
different transport service encapsulation to be used over the NNI
than that used in the internal MPLS-TP network. An example of
such normalisation is a swap of a label identifying the Transport
Service Instance.
4. The packet is mapped to a transport path based on its associated
Transport Service Instance, the transport path encapsulation is
added, if necessary, and the packet is transmitted over the
transport path.
In the second case, when a packet associated with a Transport Service
Instance arrives over a transport path, the following steps occur:
1. The transport path encapsulation is disposed of.
2. The Transport Service Instance is identified from the transport
service encapsulation, and this encapsulation is normalised for
delivery over the NNI (see Step 3 above).
3. At this point, NNI processing begins. A data-link encapsulation
is associated with the packet for delivery to the peer PE based
on the normalised Transport Service Instance.
4. Link-layer-specific postprocessing, if any, is performed. Such
postprocessing is outside the scope of MPLS-TP.
3.4.3.3. Example Interfaces
This section considers some special cases of UNI and NNI processing
for particular transport service types. These are illustrative, and
do not preclude other transport service types.
3.4.3.3.1. Layer 2 Transport Service
In this example the MPLS-TP network is providing a point-to-point
Layer 2 transport service between attached CE nodes. This service is
provided by a Transport Service Instance consisting of a PW
established between the associated PE nodes. The client flows
associated with this Transport Service Instance are the sets of all
Layer 2 frames transmitted and received over the attachment circuits.
The processing steps in this case for a frame received from the CE
are:
1. Link-layer specific preprocessing, if any, is performed,
corresponding to the PREP function illustrated in Figure 3 of
[RFC3985].
2. The frame is associated with a Transport Service Instance based
on the attachment circuit over which it was received.
3. A transport service encapsulation, consisting of the PW control
word and PW label, is associated with the frame.
4. The resulting packet is mapped to an LSP, the LSP label is
pushed, and the packet is transmitted over the outbound interface
associated with the LSP.
The steps in the reverse direction for PW packets received over the
LSP are analogous.
3.4.3.4. IP Transport Service
In this example the MPLS-TP network is providing a point-to-point IP
transport service between CE1, CE2, and CE3, as follows. One point-
to-point transport service instance delivers IPv4 packets between CE1
and CE2, and another instance delivers IPv6 packets between CE1 and
CE3.
The processing steps in this case for an IP packet received from CE1
are:
A1. No link-layer-specific processing is performed.
A2. The IP packet is extracted from the link-layer frame and
associated with a Service LSP based on the source MAC address (CE1)
and the IP protocol version.
A3. A transport service encapsulation, consisting of the Service LSP
label, is associated with the packet.
A4. The resulting packet is mapped to a tunnel LSP, the tunnel LSP
label is pushed, and the packet is transmitted over the outbound
interface associated with the LSP.
The steps in the reverse direction, for packets received over a
tunnel LSP carrying the Service LSP label, are analogous.
3.4.4. Pseudowire Adaptation
If the MPLS-TP network provides a layer 2 interface, that can carry
both network layer and non-network layer traffic, as a service
interface, then a PW is required to support the service interface.
The PW is a client of the MPLS-TP LSP server layer. The architecture
for an MPLS-TP network that provides such services is based on the
MPLS [RFC3031] and pseudowire [RFC3985] architectures. Multi-segment
pseudowires may optionally be used to provide a packet transport
service, and their use is consistent with the MPLS-TP architecture.
The use of MS-PWs may be motivated by, for example, the requirements
specified in [RFC5254]. If MS-PWs are used, then the MS-PW
architecture [RFC5659] also applies.
Figure 5 shows the architecture for an MPLS-TP network using single-
segment PWs. Note that, in this document, the client layer is
equivalent to the emulated service described in [RFC3985], while the
Transport LSP is equivalent to the Packet Switched Network (PSN)
tunnel of [RFC3985].
|<----------------- Client Layer ------------------->|
| | | |
| |<-------- Pseudowire -------->| | | |<-------- Pseudowire -------->| |
| | encapsulated, packet | | | | encapsulated, packet | |
| | transport service | | | | transport service | |
| | | | | | | |
| | Transport | |
| | |<------ LSP ------->| | | | | |<------ LSP ------->| | |
| V V V V | | V V V V |
V AC +----+ +-----+ +----+ AC V V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+ +-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|.......PW1.| \ / |............|----------| | | |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 | | CE1 | | | | | X | | | | | CE2 |
| |----------|.......PW2.| / \ |............|----------| | | |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ +-----+ +----+ | ^ ^ | +----+ ^ +-----+ +----+ | ^
| | Provider Edge 1 ^ Provider Edge 2 | | | | Provider | ^ Provider | |
| | | | | | | Edge 1 | | Edge 2 | |
Customer | P Router | Customer Customer | | P Router | Customer
Edge 1 | | Edge 2 Edge 1 | TE LSP | Edge 2
| | | |
| | | |
Native service Native service Native service Native service
Figure 6: MPLS-TP Architecture (Single Segment PW) Figure 5: MPLS-TP Architecture (Single Segment PW)
Figure 7 shows the architecture for an MPLS-TP network when multi- Figure 6 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 encapsulated ------------->| |<--------------------- Client Layer ------------------------>|
| packet transport service | | |
| | | Pseudowire encapsulated, |
| | | |<---------- Packet Transport Service ------------->| |
| | | | | |
AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC | | Transport Transport | |
| V V V V V V | | AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| +----+ +-----+ +----+ +----+ | | | V V V V V V | |
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ V | +----+ +-----+ +----+ +----+ | V
| |---|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|---| | +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
|CE1| | | | | X | | | | | | |CE2| | |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| |
| |---|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|---| | |CE1| | | | | X | | | | | | |CE2|
+---+ | | |===============/ \=====| |==========| | | +---+ | |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| |
^ +----+ ^ +-----+ +----+ ^ +----+ ^ +---+ ^ | |===============/ \=====| |==========| | | ^+---+
| | ^ | | | +----+ ^ +-----+ +----+ ^ +----+ |
| TE LSP | TE LSP | | | ^ | |
| P-router | | TE LSP | TE LSP |
| | | P-router |
|<-------------------- Emulated Service ------------------->| Native Service Native Service
PW1-segment1 and PW1-segment2 are segments of the same MS-PW, PW1-segment1 and PW1-segment2 are segments of the same MS-PW,
while PW2-segment1 and PW2-segment2 are segments of another MS-PW while PW2-segment1 and PW2-segment2 are segments of another MS-PW
Figure 7: MPLS-TP Architecture (Multi-Segment PW) Figure 6: MPLS-TP Architecture (Multi-Segment PW)
The corresponding MPLS-TP protocol stacks including PWs are shown in The corresponding MPLS-TP protocol stacks including PWs are shown in
Figure 8. In this figure the Transport Service Layer [RFC5654] is Figure 7. In this figure the Transport Service Layer [RFC5654] is
identified by the PW demultiplexer (Demux) label and the Transport identified by the PW demultiplexer (Demux) label and the Transport
Path Layer [RFC5654] is identified by the LSP Demux Label. Path Layer [RFC5654] is identified by the LSP Demux Label.
+-------------------+ /===================\ /===================\ +-------------------+ /===================\ /===================\
| Client Layer | H OAM PDU H H OAM PDU H | Client Layer | H OAM PDU H H OAM PDU H
/===================\ H-------------------H H-------------------H /===================\ H-------------------H H-------------------H
H PW Encap H H GACh H H GACh H H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) 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 Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans 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: H(ighlighted) indicates the part of the protocol stack we are Note: H(ighlighted) indicates the part of the protocol stack considered
considering in this document. in this document.
Figure 8: MPLS-TP Layer Network using Pseudowires Figure 7: MPLS-TP label stack using pseudowires
PWs and their associated labels may be configured or signaled. See PWs and their associated labels may be configured or signaled. See
Section 3.11 for additional details related to configured service Section 3.11 for additional details related to configured service
types. See Section 3.9 for additional details related to signaled types. See Section 3.9 for additional details related to signaled
service types. service types.
3.4.2.1. Pseudowire Based Services 3.4.5. Network Layer Adaptation
When providing a Virtual Private Wire Service (VPWS) , Virtual
Private Local Area Network Service (VPLS), Virtual Private Multicast
Service (VPMS) or Internet Protocol Local Area Network Service
(IPLS), pseudowires must be used to carry the client service. VPWS,
VLPS, and IPLS are described in [RFC4664]. VPMS is described in
[I-D.ietf-l2vpn-vpms-frmwk-requirements].
3.4.3. Network Layer Adaptation
MPLS-TP LSPs can be used to transport network layer clients. This MPLS-TP LSPs can be used to transport network layer clients. This
document uses the term Network Layer in the same sense as it is used document uses the term Network Layer in the same sense as it is used
in [RFC3031] and [RFC3032]. The network layer protocols supported by in [RFC3031] and [RFC3032]. The network layer protocols supported by
[RFC3031] and [RFC3032] can be transported between service [RFC3031] and [RFC3032] can be transported between service
interfaces. Examples are shown in Figure 5 above. Support for interfaces. Examples are shown in Figure 5 above. Support for
network layer clients follows the MPLS architecture for support of network layer clients follows the MPLS architecture for support of
network layer protocols as specified in [RFC3031] and [RFC3032]. network layer protocols as specified in [RFC3031] and [RFC3032].
With network layer adaptation, the MPLS-TP domain provides either a With network layer adaptation, the MPLS-TP domain provides either a
uni-directional or bidirectional point-to-point connection between uni-directional or bidirectional point-to-point connection between
two PEs in order to deliver a packet transport service to attached two PEs in order to deliver a packet transport service to attached
customer edge (CE) nodes. For example, a CE may be an IP, MPLS or customer edge (CE) nodes. For example, a CE may be an IP, MPLS or
MPLS-TP node. As shown in Figure 9, there is an attachment circuit MPLS-TP node. As shown in Figure 8, there is an attachment circuit
between the CE node on the left and its corresponding provider edge between the CE node on the left and its corresponding provider edge
(PE) node which provides the service interface, a bidirectional LSP (PE) node which provides the service interface, a bidirectional LSP
across the MPLS-TP network to the corresponding PE node on the right, across the MPLS-TP network to the corresponding PE node on the right,
and an attachment circuit between that PE node and the corresponding and an attachment circuit between that PE node and the corresponding
CE node for this service. CE node for this service.
The attachment circuits may be heterogeneous (e.g., any combination The attachment circuits may be heterogeneous (e.g., any combination
of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads
arrive at the service interface encapsulated in the Layer1/Layer2 arrive at the service interface encapsulated in the Layer1/Layer2
encoding defined for that access link type. It should be noted that encoding defined for that access link type. It should be noted that
the set of network layer protocols includes MPLS and hence MPLS the set of network layer protocols includes MPLS and hence MPLS
encoded packets with an MPLS label stack (the client MPLS stack), may encoded packets with an MPLS label stack (the client MPLS stack), may
appear at the service interface. appear at the service interface.
|<------------- Client Network Layer ------------->| |<------------- Client Network Layer --------------->|
| | | |
| |<---- Pkt Xport Service --->| | | |<----------- Packet --------->| |
| | | | | | Transport Service | |
| | |<-- PSN Tunnel -->| | | | | | |
| V V V V | | | | |
V AC +----+ +---+ +----+ AC V | | Transport | |
+-----+ | |PE1 | | | |PE2 | | +-----+ | | |<------ LSP ------->| | |
| | |LSP | | | | | | | | | | V V V V |
| CE1 |----------| |========X=========| |----------| CE2 | V AC +----+ +-----+ +----+ AC V
| | ^ |IP | | ^ | | ^ | | | ^ | | +-----+ | | PE1|=======\ /========| PE2| | +-----+
+-----+ | | | | | | | | | | | | +-----+ | |----------|..Svc LSP1.| \ / |............|----------| |
^ | +----+ | +---+ | +----+ | | ^ | CE1 | | | | | X | | | | | CE2 |
| | Provider | ^ | Provider | | | |----------|..Svc LSP2.| / \ |............|----------| |
| | Edge | | | Edge | | +-----+ ^ | | |=======/ \========| | | ^ +-----+
Customer | 1 | P-router | 2 | Customer ^ | +----+ ^ +-----+ +----+ | | ^
Edge 1 | TE TE | Edge 2 | | Provider | ^ Provider | |
| LSP LSP | | | Edge 1 | | Edge 2 | |
| | Customer | | P Router | Customer
Native service Native service Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
Figure 9: MPLS-TP Architecture for Network Layer Clients Figure 8: MPLS-TP Architecture for Network Layer Clients
At the ingress service interface the client packets are received . At the ingress service interface the client packets are received.
The PE pushes one or more labels onto the client packets which are The PE pushes one or more labels onto the client packets which are
then label switched over the transport network. Correspondingly the then label switched over the transport network. Correspondingly the
egress PE pops any labels added by the MPLS-TP networks and transmits egress PE pops any labels added by the MPLS-TP networks and transmits
the packet for delivery to the attached CE via the egress service the packet for delivery to the attached CE via the egress service
interface. interface.
/===================\ /===================\
H OAM PDU H H OAM PDU H
+-------------------+ H-------------------H /===================\ +-------------------+ H-------------------H /===================\
| Client Layer | H GACh H H OAM PDU H | Client Layer | H GACh H H OAM PDU H
/===================\ H-------------------H H-------------------H /===================\ H-------------------H H-------------------H
H Encap Label H H GAL (S=1) H H GACh H H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) 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 Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans 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: H(ighlighted) indicates the part of the protocol stack we are Note: H(ighlighted) indicates the part of the protocol stack considered
considering in this document. in this document.
Figure 10: Domain of MPLS-TP Layer Network for IP and LSP Clients Figure 9: MPLS-TP Label Stack for IP and LSP Clients
In this figure the Transport Service Layer [RFC5654] is identified by In this figure the Transport Service Layer [RFC5654] is identified by
the Service LSP (SvcLSP) demultiplexer (Demux) label and the the Service LSP (SvcLSP) demultiplexer (Demux) label and the
Transport Path Layer [RFC5654] is identified by the LSP Demux Label. Transport Path Layer [RFC5654] is identified by the Transport (Trans)
Note that the functions of the Encapsulation label and the Service LSP Demux Label. Note that the functions of the Encapsulation label
Label shown above as SvcLSP Demux may be represented by a single (Encap Label) and the Service Label (SvcLSP Demux) shown above may
label stack entry. Additionally, the S-bit will always be zero when alternatively be represented by a single label stack entry. Note
the client layer is MPLS labelled. that the S-bit is always zero when the client layer is MPLS-labelled.
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 network using a logically separate MPLS carried over the MPLS-TP network using a logically separate MPLS
label stack (the server stack). The server stack is entirely under label stack (the server stack). The server stack is entirely under
the control of the nodes within the MPLS-TP transport network and it the control of the nodes within the MPLS-TP transport network and it
is not visible outside that network. Figure 10 shows how a client is not visible outside that network. Figure 9 shows how 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 a network layer client 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 may be used to identify the network layer protocol payload
transported is required. When multiple protocol payload types are to type. Therefore, when multiple protocol payload types are to be
be carried over a single service a unique label stack entry must be carried over a single service LSP, a unique label stack entry must be
present for each payload type. Such labels are referred to as present for each payload type. Such labels are referred to as
"Encapsulation Labels", one of which is shown in Figure 10. "Encapsulation Labels", one of which is shown in Figure 9.
Encapsulation Label may be either configured or signaled. Encapsulation Label may be either configured or signaled.
Both an Encapsulation Label and a Service Label should be present in Both an Encapsulation Label and a Service Label should be present in
the label stack when a particular packet transport service is the label stack when a particular packet transport service is
supporting more than one network layer protocol payload type. For supporting more than one network layer protocol payload type. For
example, if both IP and MPLS are to be carried, as shown in Figure 9, example, if both IP and MPLS are to be carried, as shown in Figure 8,
then two Encapsulation Labels are mapped on to a common Service then two Encapsulation Labels are mapped on to a common Service
Label. Label.
Note: The Encapsulation Label may be omitted when the transport Note: The Encapsulation Label may be omitted when the service LSP is
service is supporting only one network layer protocol payload type. supporting only one network layer protocol payload type. For
For example, if only MPLS labeled packets are carried over a service, example, if only MPLS labeled packets are carried over a service,
then the Service Label (stack entry) provides both the payload type then the Service Label (stack entry) provides both the payload type
indication and service identification. indication and service identification.
Service labels are typically carried over an MPLS-TP LSP edge-to-edge Service labels are typically carried over an MPLS-TP Transport LSP
(or transport path layer). An MPLS-TP edge-to-edge LSP is edge-to-edge (or transport path layer). An MPLS-TP Transport LSP is
represented as an LSP Demux label as shown in Figure 10. An edge-to- represented as an LSP Transport Demux label, as shown in Figure 9.
edge LSP is commonly used when more than one service exists between Transport LSP is commonly used when more than one service exists
two PEs. between two PEs.
Note that the edge-to-edge LSP may be omitted when only one service Note that, if only one service exists between two PEs, the functions
exists between two PEs. For example, if only one service is carried of the Transport LSP label and the Service LSP Label may be combined
between two PEs then a single Service Label could be used to provide into a single label stack entry. For example, if only one service is
both the service indication and the MPLS-TP edge-to-edge LSP. carried between two PEs then a single label could be used to provide
both the service indication and the MPLS-TP transport LSP.
Alternatively, if multiple services exist between a pair of PEs then 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 a per-client Service Label would be mapped on to a common MPLS-TP
edge-to-edge LSP. transport LSP.
As noted above, the 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 circuits are not network layer protocol over the attachment circuits are not
transported across the MPLS-TP network. This enables the use of transported across the MPLS-TP network. This enables the use of
different layer 2 and layer 1 protocols on the two attachment different layer 2 and layer 1 protocols on the two attachment
circuits. 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
specified in this document. In some technologies the MAC address specified in this document. In some technologies the MAC address
will need to be configured. (Examples for the Ethernet case include will need to be configured.
a configured unicast MAC address for the adjacent node, or even using
the broadcast MAC address when the CE-PE service interface is
dedicated. The configured address is then used as the destination
MAC address for all packets sent over the service interface.)
Note that when two CEs, which peer with each other, operate over a Note that when two CEs, which peer with each other, operate over a
network layer transport service and run a routing protocol such as network layer transport service and run a routing protocol such as
IS-IS or OSPF, some care should be taken to configure the routing IS-IS or OSPF, some care should be taken to configure the routing
protocols to use point-to-point adjacencies. The specifics of such protocols to use point-to-point adjacencies. The specifics of such
configuration is outside the scope of this document. See [RFC5309] configuration is outside the scope of this document. See [RFC5309]
for additional details. for additional details.
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 . See Section 3.11 for additional details related to or signaled .
configured service types. See Section 3.9 for additional details
related to signaled service types.
3.5. Identifiers 3.5. Identifiers
Identifiers are used to uniquely distinguish entities in an MPLS-TP Identifiers are used to uniquely distinguish entities in an MPLS-TP
network. These include operators, nodes, LSPs, pseudowires, and network. These include operators, nodes, LSPs, pseudowires, and
their associated maintenance entities. their associated maintenance entities. MPLS-TP defined two type of
[I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are sets of identifiers: Those that are compatible with IP, and another
compatible with existing MPLS control plane identifiers, as well as a set that is compatibple with ITU-T transport-based operations. The
set of identifiers that may be used when no IP control plane is definition of these sets of identifiers is outside the scope of this
available. document and is provided by [I-D.ietf-mpls-tp-identifiers].
3.6. Generic Associated Channel (G-ACh) 3.6. Generic Associated Channel (G-ACh)
For correct operation of the OAM it is important that the OAM packets For correct operation of OAM mechanisms it is important that OAM
fate-share with the data packets. In addition in MPLS-TP it is packets fate-share with the data packets. In addition in MPLS-TP it
necessary to discriminate between user data payloads and other types is necessary to discriminate between user data payloads and other
of payload. For example, a packet may be associated with a Signaling types of payload. For example, a packet may be associated with a
Communication Channel (SCC), or a channel used for Automatic Signaling Communication Channel (SCC), or a channel used for
Protection Switching (APS) data. This is achieved by carrying such Protection State Coordination (PSC) data. This is achieved by
packets on a generic control channel associated to the LSP, PW or carrying such packets in either:
section.
o A generic control channel associated to the LSP, PW or section,
with no IP encapsulation. e.g. in a similar manner to
Bidirectional Forwarding Detection for Virtual Circuit
Connectivity Verification (VCCV-BFD) with PW ACH encapsulation
[I-D.ietf-pwe3-vccv-bfd]).
o An IP encapsulation where IP capabilities are present. e.g. PW
ACH encapsulation with IP headers for VCCV-BFD
[I-D.ietf-pwe3-vccv-bfd], or IP encapsulation for MPLS BFD
[I-D.ietf-bfd-mpls].
MPLS-TP makes use of such a generic associated channel (G-ACh) to MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC (FCAPS) functions by carrying packets related to OAM, PSC, SCC, MCC
or other packet types in-band over LSPs or PWs. The G-ACh is defined or other packet types in-band over LSPs, PWs or sections. The G-ACh
in [RFC5586] and is similar to the Pseudowire Associated Channel is defined in [RFC5586] and is similar to the Pseudowire Associated
[RFC4385], which is used to carry OAM packets over pseudowires. The Channel [RFC4385], which is used to carry OAM packets over
G-ACh is indicated by a generic associated channel header (ACH), pseudowires. The G-ACh is indicated by an Associated Channel Header
similar to the Pseudowire VCCV control word; this header is present (ACH), similar to the Pseudowire VCCV control word; this header is
for all Sections, LSPs and PWs making use of FCAPS functions present for all sections, LSPs and PWs making use of FCAPS functions
supported by the G-ACh. supported by the G-ACh.
For pseudowires, the G-ACh uses the first four bits of the pseudowire
control word to provide the initial discrimination between data
packets and packets belonging to the associated channel, as described
in [RFC4385]. When this first nibble of a packet, immediately
following the label at the bottom of stack, has a value of '1', then
this packet belongs to a G-ACh. The first 32 bits following the
bottom of stack label then have a defined format called an associated
channel header (ACH), which further defines the content of the
packet. The ACH is therefore both a demultiplexer for G-ACh traffic
on the PW, and a discriminator for the type of G-ACh traffic.
When the OAM or other control message is carried over an LSP, rather
than over a pseudowire, it is necessary to provide an indication in
the packet that the payload is something other than a user data
packet. This is achieved by including a reserved label with a value
of 13 in the label stack. This reserved label is referred to as the
'G-ACh Label (GAL)', and is defined in [RFC5586]. When a GAL is
found, it indicates that the payload begins with an ACH. The GAL is
thus a demultiplexer for G-ACh traffic on the LSP, and the ACH is a
discriminator for the type of traffic carried on the G-ACh. Note
however that MPLS-TP forwarding follows the normal MPLS model, and
that a GAL is invisible to an LSR unless it is the top label in the
label stack. The only other circumstance under which the label stack
may be inspected for a GAL is when the TTL has expired. Any MPLS-TP
component that intentionally performs this inspection must assume
that it is asynchronous with respect to the forwarding of other
packets. All operations on the label stack are in accordance with
[RFC3031] and [RFC3032].
In MPLS-TP, the 'G-ACh Label (GAL)' always appears at the bottom of
the label stack (i.e. its S bit is set to 1).
The G-ACh must only be used for channels that are an adjunct to the The G-ACh must only be used for channels that are an adjunct to the
data service. Examples of these are OAM, APS, MCC and SCC, but the data service. Examples of these are OAM, PSC, MCC and SCC, but the
use is not restricted to these services. The G-ACh must not be used use is not restricted to these services. The G-ACh must not be used
to carry additional data for use in the forwarding path, i.e. it must 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 not be used as an alternative to a PW control word, or to define a PW
type. type.
At the server layer, bandwidth and QoS commitments apply to the gross At the server layer, bandwidth and QoS commitments apply to the gross
traffic on the LSP, PW or section. Since the G-ACh traffic is traffic on the LSP, PW or section. Since the G-ACh traffic is
indistinguishable from the user data traffic, protocols using the indistinguishable from the user data traffic, protocols using the
G-ACh must take into consideration the impact they have on the user G-ACh must take into consideration the impact they have on the user
data that they are sharing resources with. Conversely, capacity must data with which they are sharing resources. Conversely, capacity
be made available for important G-ACh uses such as protection and must be made available for important G-ACh uses such as protection
OAM. In addition, protocols using the G-ACh must conform to the and OAM. In addition, protocols using the G-ACh must conform to the
security and congestion considerations described in [RFC5586]. security and congestion considerations described in [RFC5586].
Figure 11 shows the reference model depicting how the control channel Figure 10 shows the reference model depicting how the control channel
is associated with the pseudowire protocol stack. This is based on is associated with the pseudowire protocol stack. This is based on
the reference model for VCCV shown in Figure 2 of [RFC5085]. the reference model for VCCV shown in Figure 2 of [RFC5085].
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < FCAPS > | Payload | | Payload | < FCAPS > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
| Demux / | < ACH for PW > | Demux / | | Demux / | < ACH for PW > | Demux / |
|Discriminator| |Discriminator| |Discriminator| |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
| PW | < PW > | PW | | PW | < PW > | PW |
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < LSP > | PSN | | PSN | < LSP > | PSN |
+-------------+ +-------------+ +-------------+ +-------------+
| Physical | | Physical | | Physical | | Physical |
+-----+-------+ +-----+-------+ +-----+-------+ +-----+-------+
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 11: PWE3 Protocol Stack Reference Model showing the G-ACh Figure 10: PWE3 Protocol Stack Reference Model showing the G-ACh
PW associated channel messages are encapsulated using the PWE3 PW associated channel messages are encapsulated using the PWE3
encapsulation, so that they are handled and processed in the same encapsulation, so that they are handled and processed in the same
manner (or in some cases, an analogous manner) as the PW PDUs for manner (or in some cases, an analogous manner) as the PW PDUs for
which they provide a control channel. which they provide a control channel.
Figure 12 shows the reference model depicting how the control channel Figure 11 shows the reference model depicting how the control channel
is associated with the LSP protocol stack. is associated with the LSP protocol stack.
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < FCAPS > | Payload | | Payload | < FCAPS > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator| |Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer| |Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < LSP > | PSN | | PSN | < LSP > | PSN |
+-------------+ +-------------+ +-------------+ +-------------+
| Physical | | Physical | | Physical | | Physical |
+-----+-------+ +-----+-------+ +-----+-------+ +-----+-------+
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 12: MPLS Protocol Stack Reference Model showing the LSP Figure 11: MPLS Protocol Stack Reference Model showing the LSP
Associated Control Channel Associated Control Channel
3.7. Operations, Administration and Maintenance (OAM) 3.7. Operations, Administration and Maintenance (OAM)
MPLS-TP must be able to operate in environments where IP is not used The MPLS-TP OAM architecture supports a wide range of OAM functions
in the forwarding plane. Therefore, the default mechanism for OAM to check continuity, to verify connectivity, to monitor path
demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated performance, and to generate, filter and manage local and remote
Channel (Section 3.6). Forwarding based on IP addresses for user or defect alarms. These functions are applicable to any layer defined
OAM packets is not required for MPLS-TP. within MPLS-TP, i.e. to MPLS-TP sections, LSPs and PWs.
The MPLS-TP OAM tool-set must be able to operate without relying on a
dynamic control plane or IP functionality in the datapath. In the
case of an MPLS-TP deployment in a network in which IP functionality
is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD
and VCCV, may be used. Since MPLS-TP must be able to operate in
environments where IP is not used in the forwarding plane, 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 [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 alert mechanisms that enable an MPLS LSR to identify and process MPLS
OAM packets when the OAM packets are encapsulated in an IP header. 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 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 destination address in the range 127/8 for IPv4 and that same range
embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the
OAM packets are encapsulated in an IP header, these mechanisms are OAM packets are encapsulated in an IP header, these mechanisms are
the default mechanisms for MPLS networks in general for identifying the default mechanisms for MPLS networks in general for identifying
MPLS OAM packets. MPLS-TP must be able to operate in an environments MPLS OAM packets, although the mechanisms defined in [RFC5586] can
where IP forwarding is not supported, and thus the G-ACh/GAL is the also be used. MPLS-TP must be able to operate in environments where
default mechanism to demultiplex OAM packets in MPLS-TP. IP forwarding is not supported, and thus the G-ACh/GAL is the default
mechanism to demultiplex OAM packets in MPLS-TP in these
environments.
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.
OAM, APS, MCC or SCC) from those carrying user data packets on the
same transport path (i.e. section, LSP or PW). These mechanisms are
described in [RFC5586].
MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of 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 localisation) 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 G-ACh Label (GAL) to create a control Channel Header (ACH) and a G-ACh Label (GAL) to create a control
channel associated to an LSP, Section or PW. channel associated to an LSP, Section or PW.
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 Maintenance Entity (ME) can be viewed as the association of two
Maintenance End Points (MEPs). A Maintenance Entity Group (MEG) is a Maintenance Entity Group End Points (MEPs). A Maintenance Entity
collection of one or more MEs that belongs to the same transport path Group (MEG) is a collection of one or more MEs that belongs to the
and that are maintained and monitored as a group. The MEPs that form same transport path and that are maintained and monitored as a group.
an ME limit the OAM responsibilities of an OAM flow to within the The MEPs that form an ME limit the OAM responsibilities of an OAM
domain of a transport path or segment, in the specific layer network flow to within the domain of a transport path or segment, in the
that is being monitored and managed. specific layer network that is being monitored and managed.
An ME may also include a set of Maintenance Intermediate Points
(MIPs). Maintenance End Points (MEPs) are capable of sourcing and
sinking OAM flows, while Maintenance Intermediate Points (MIPs) can
only sink or respond to OAM flows from within a MEG, or originate
notifications as a result of specific network conditions.
The following MPLS-TP MEs are specified in
[I-D.ietf-mpls-tp-oam-framework]:
o A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs).
o A LSP Maintenance Entity (LME), allowing monitoring and management
of an edge-to-edge LSP (between LERs).
o A PW Maintenance Entity (PME), allowing monitoring and management A MEG may also include a set of Maintenance Entity Group Intermediate
of an edge-to-edge SS/MS-PWs (between T-PEs). Points (MIPs). MEPs are capable of sourcing and sinking OAM flows,
while MIPs can both react to OAM flows received from within a MEG.
o An LSP Tandem Connection Maintenance Entity (LTCME). Intermediate nodes can also originate notifications to the MEPs as a
result of specific network conditions.
A G-ACh packet may be directed to an individual MIP along the path of A G-ACh packet may be directed to an individual MIP along the path of
an LSP or MS-PW by setting the appropriate TTL in the label for the an LSP or MS-PW by setting the appropriate TTL in the label for the
G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and
the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw]. Note that this the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw]. Note that this
works when the location of MIPs along the LSP or PW path is known by 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. 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 MPLS architecture
that this must occur at least once. mandates that MPLS layer processing occurs at least once on an LSR.
MEPs may only act as a sink of OAM packets when the label associated
with the LSP or PW for that ME is popped. MIPs can only be placed
where an exception to the normal forwarding operation occurs. A MEP
may act as a source of OAM packets wherever a label is pushed or
swapped. For example, on an MS-PW, a MEP may source OAM within an
S-PE or a T-PE, but a MIP may only be associated with a S-PE and a
sink MEP can only be associated with a T-PE.
The MPLS-TP OAM architecture supports a wide range of OAM functions Any node on an LSP can send an OAM packet on that LSP. Likewise, any
to check continuity, to verify connectivity and to monitor the node on a PW can send OAM packets on a PW, including S-PEs.
preformance of the path, to generate, filter and manage local and
remote defect alarms. These functions are applicable to any layer
defined within MPLS-TP, i.e. to MPLS-TP Sections, LSPs and PWs.
The MPLS-TP OAM tool-set must be able to operate without relying on a An OAM packet can only be received to be processed at an LSP
dynamic control plane or IP functionality in the datapath. In the endpoint, a PW endpoint (T-PE), or on the expiry of the TTL of the
case of an MPLS-TP deployment in a network in which IP functionality LSP or PW label.
is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD
and VCCV, may be used.
3.8. LSP Return Path 3.8. Return Path
Management, control and OAM protocol functions may require response Management, control and OAM protocol functions may require response
packets to be delivered from the receiver back to the originator of a packets to be delivered from the receiver back to the originator of a
message exchange. This section provides a summary of the return path message exchange. This section provides a summary of the return path
options in MPLS-TP networks. options in MPLS-TP networks. Although this section describes the
case of an MPLS-TP LSP, it is also applicable to a PW.
In this discussion we assume that A and B are terminal LSRs (i.e. In this description, U and D are LSRs that terminate MPLS-TP LSPs
LERs) for an MPLS-TP LSP and that Y is an intermediate LSR along the (i.e. LERs) and that Y is an intermediate LSR along the LSP. In the
LSP. In the unidirectional case, A is taken to be the upstream and B unidirectional case, U is the upstream LER and D is the downstream
the downstream LSR with respect to the LSP. We consider the LER with respect to the LSP. This reference model is shown in
following cases for the various types of LSPs: Figure 12.
1. Packet transmission from B to A LSP LSP
2. Packet transmission from Y to A U ========= Y ========= D
3. Packet transmission from B to Y LER LSR LER
---------> Direction of pcket flow
Figure 12: Return Path reference Model
The following cases are described for the various types of LSPs:
Case 1 Packet transmission from D to U
Case 2 Packet transmission from Y to U
Case 3 Packet transmission from D to Y
Note that a return path may not always exist, and that packet Note that a return path may not always exist, and that packet
transmission in one or more of the above cases may not be possible. transmission in one or more of the above cases may not be possible.
In general the existence and nature of return paths for MPLS-TP LSPs In general the existence and nature of return paths for MPLS-TP LSPs
is determined by operational provisioning. is determined by operational provisioning.
3.8.1. Return Path Types 3.8.1. Return Path Types
There are two types of return path that may be used for the delivery There are two types of return path that may be used for the delivery
of traffic from a downstream node D to an upstream node U either: of traffic from a downstream node D to an upstream node U. Either:
a. D maintains an MPLS-TP LSP back to U which is specifically a. The LSP between U and D is bidirectional, and therefore D has a
designated to carry return traffic for the original LSP, or path via the MPLS-TP LSP to return traffic back to U, or
b. D has some other unspecified means of directing traffic back to b. D has some other unspecified means of directing traffic back to
U. U.
The first option is referred to as an "in-band" return path, the The first option is referred to as an "in-band" return path, the
second as an "out-of-band" return path. second as an "out-of-band" return path.
There are various possibilities for "out-of-band" return paths. Such There are various possibilities for "out-of-band" return paths. Such
a path may, for example, be based on ordinary IP routing. In this a path may, for example, be based on ordinary IP routing. In this
case packets would be forwarded as usual to a destination IP address case packets would be forwarded as usual to a destination IP address
associated with U. In an MPLS-TP network that is also an IP/MPLS associated with U. In an MPLS-TP network that is also an IP/MPLS
network, such a forwarding path may traverse the same physical links network, such a forwarding path may traverse the same physical links
or logical transport paths used by MPLS-TP. An out-of-band return or logical transport paths used by MPLS-TP. An out-of-band return
path may also be indirect, via a distinct Data Communication Network path may also be indirect, via a distinct Data Communication Network
(DCN) (provided, for example, by the method specified in [RFC5718]); (DCN) (provided, for example, by the method specified in [RFC5718]);
or it may be via one or more other MPLS-TP LSPs. or it may be via one or more other MPLS-TP LSPs.
3.8.2. Point-to-Point Unidirectional LSPs 3.8.2. Point-to-Point Unidirectional LSPs
Case 1 In this situation, either an in-band or out-of-band return Case 1 In this situation, either an in-band or out-of-band return
path may be used to deliver traffic from B back to A. path may be used to deliver traffic from D back to U.
In the in-band case there is in essence an associated It is recommended for reasons of operational simplicity that
bidirectional LSP between A and B, and the discussion for point-to-point unidirectional LSPs be provisioned as
such LSPs below applies. It is therefore recommended for associated bidirectional LSPs (which may also be co-routed)
reasons of operational simplicity that point-to-point whenever return traffic from D to U is required. Note that
unidirectional LSPs be provisioned as associated the two directions of such an LSP may have differing
bidirectional LSPs (which may also be co-routed) whenever bandwidth allocations and QoS characteristics. In the in-
return traffic from B to A is required. Note that the two band case there is in essence an associated bidirectional LSP
directions of such an LSP may have differing bandwidth between U and D, and the discussion for such LSPs below
allocations and QoS characteristics. applies.
Case 2 In this case only the out-of-band return path option is Case 2 In this case only the out-of-band return path option is
available. However, an additional out-of-band possibility is available. However, an additional out-of-band possibility is
worthy of note here: if B is known to have a return path to worthy of note here: if D is known to have a return path to
A, then Y can arrange to deliver return traffic to A by first U, then Y can arrange to deliver return traffic to U by first
sending it to B along the original LSP. The mechanism by sending it to D along the original LSP. The mechanism by
which B recognises the need for and performs this forwarding which D recognises the need for and performs this forwarding
operation is protocol-specific. operation is protocol-specific.
Case 3 In this case only the out-of-band return path option is Case 3 In this case only the out-of-band return path option is
available. However, if B has a return path to A, then in a available. However, if D has a return path to U, then in a
manner analogous to the previous case B can arrange to manner analogous to the previous case D can arrange to
deliver return traffic to Y by first sending it to A along deliver return traffic to Y by first sending it to U along
that return path. The mechanism by which A recognises the that return path. The mechanism by which U recognises the
need for and performs this forwarding operation is protocol- need for and performs this forwarding operation is protocol-
specific. specific.
3.8.3. Point-to-Point Associated Bidirectional LSPs 3.8.3. Point-to-Point Associated Bidirectional LSPs
For Case 1, B has a natural in-band return path to A, the use of For Case 1, D has a natural in-band return path to U, the use of
which is typically preferred for return traffic, although out-of-band which is typically preferred for return traffic, although out-of-band
return paths are also applicable. return paths are also applicable.
For Cases 2 and 3, the considerations are the same as those for For Cases 2 and 3, the considerations are the same as those for
point-to-point unidirectional LSPs. point-to-point unidirectional LSPs.
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs
For all of Cases 1, 2, and 3, a natural in-band return path exists in For all of Cases 1, 2, and 3, a natural in-band return path exists in
the form of the LSP itself, and its use is typically preferred for the form of the LSP itself, and its use is preferred for return
return traffic. Out-of-band return paths, however, are also traffic. Out-of-band return paths, however, are also applicable,
applicable, primarily as an alternative means of delivery in case the primarily as an alternative means of delivery in case the in-band
in-band return path has failed. return path has failed.
3.9. Control Plane 3.9. Control Plane
A distributed dynamic control plane may be used to enable dynamic A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements service provisioning in an MPLS-TP network. Where the requirements
specified in [RFC5654] can be met, the MPLS Transport Profile uses specified in [RFC5654] can be met, the MPLS Transport Profile uses
existing standard control plane protocols for LSPs and PWs. existing standard control plane protocols for LSPs and PWs.
Note that a dynamic control plane is not required in an MPLS-TP Note that a dynamic control plane is not required in an MPLS-TP
network. See Section 3.11 for further details on statically network. See Section 3.11 for further details on statically
skipping to change at page 33, line 36 skipping to change at page 37, line 39
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, an LSP or a G-ACh. layer, an LSP or a G-ACh.
Figure 13: MPLS-TP Control Plane Architecture Context Figure 13: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on existing MPLS and PW control The MPLS-TP control plane is based on existing MPLS and PW control
plane protocols. MPLS-TP uses Generalized MPLS (GMPLS) signaling plane protocols, and is consistent with the Automatically Switched
([RFC3945], [RFC3471], [RFC3473]) for LSPs and Targeted LDP (T-LDP) Optical Networks (ASON) architecture [G.8080]. MPLS-TP uses
[RFC4447] [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473])
for pseudowires. for LSPs and Targeted LDP (T-LDP) [RFC4447]
[I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] for
pseudowires.
MPLS-TP requires that any signaling be capable of being carried over MPLS-TP requires that any control plane traffic be capable of being
an out-of-band signaling network or a signaling control channel such carried over an out-of-band signaling network or a signaling control
as the one described in [RFC5718]. Note that while T-LDP signaling channel such as the one described in [RFC5718]. Note that while
is traditionally carried in-band in IP/MPLS networks, this does not T-LDP signaling is traditionally carried in-band in IP/MPLS networks,
preclude its operation over out-of-band channels. References to this does not preclude its operation over out-of-band channels.
T-LDP in this document do not preclude the definition of alternative References to T-LDP in this document do not preclude the definition
PW control protocols for use in MPLS-TP. of alternative PW control protocols for use in MPLS-TP.
PW control (and maintenance) takes place separately from LSP tunnel PW control (and maintenance) takes place separately from LSP tunnel
signaling. The main coordination between LSP and PW control will signaling. The main coordination between LSP and PW control will
occur within the nodes that terminate PWs. The control planes for occur within the nodes that terminate PWs. The control planes for
PWs and LSPs may be used independently, and one may be employed PWs and LSPs may be used independently, and one may be employed
without the other. This translates into the four possible scenarios: without the other. This translates into the four possible scenarios:
(1) no control plane is employed; (2) a control plane is used for (1) no control plane is employed; (2) a control plane is used for
both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs; both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs;
(4) a control plane is used for PWs, but not LSPs. The PW and LSP (4) a control plane is used for PWs, but not LSPs. The PW and LSP
control planes, collectively, must satisfy the MPLS-TP control plane control planes, collectively, must satisfy the MPLS-TP control plane
requirements reviewed in the MPLS-TP Control Plane Framework requirements reviewed in the MPLS-TP Control Plane Framework
[I-D.abfb-mpls-tp-control-plane-framework]. When client services are [I-D.ietf-ccamp-mpls-tp-cp-framework]. When client services are
provided directly via LSPs, all requirements must be satisfied by the provided directly via LSPs, all requirements must be satisfied by the
LSP control plane. When client services are provided via PWs, the PW LSP control plane. When client services are provided via PWs, the PW
and LSP control planes operate in combination and some functions may and LSP control planes operate in combination and some functions may
be satisfied via the PW control plane while others are provided to be satisfied via the PW control plane while others are provided to
PWs by the LSP control plane. PWs by the LSP control plane.
Note that if MPLS-TP is being used in a multi-layer network, a number Note that if MPLS-TP is being used in a multi-layer network, a number
of control protocol types and instances may be used. This is of control protocol types and instances may be used. This is
consistent with the MPLS architecture which permits each label in the consistent with the MPLS architecture which permits each label in the
label stack to be allocated and signaled by its own control protocol. label stack to be allocated and signaled by its own control protocol.
skipping to change at page 34, line 36 skipping to change at page 38, line 40
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-Network Interface (I-NNI), and External Network-Network
(E-NNI). Note that different policies may be defined that control Interface (E-NNI). Note that different policies may be defined that
the information exchanged across these interface types. control 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.7, e.g. for fault detection and localisation in the event Section 3.7, e.g. for fault detection and localisation in the event
of 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 Section 3.12. paths, including protected paths as described in Section 3.12.
Examples of the MPLS-TP data plane connectivity patterns are LSPs Examples of the MPLS-TP data plane connectivity patterns are LSPs
utilising the fast reroute backup methods as defined in [RFC4090] and utilising the fast reroute backup methods as defined in [RFC4090] and
ingress-to-egress 1+1 or 1:1 protected LSPs. ingress-to-egress 1+1 or 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. In all cases, however, the control plane is
logically decoupled from the data plane such that a control plane
failure does not imply a failure of the existing transport paths.
3.10. Inter-domain Connectivity 3.10. Interdomain Connectivity
A number of methods exist to support inter-domain operation of A number of methods exist to support inter-domain operation of
MPLS-TP, for example: MPLS-TP, including the data plane, OAM and configuration aspects, for
example:
o Inter-domain TE LSPs [RFC4216] o Inter-domain TE LSPs [RFC4216]
o Multi-segment Pseudowires [RFC5659] o Multi-segment Pseudowires [RFC5659]
o LSP stitching [RFC5150] o LSP stitching [RFC5150]
o back-to-back attachment circuits [RFC5659] o back-to-back attachment circuits [RFC5659]
An important consideration in selecting an inter-domain connectivity An important consideration in selecting an inter-domain connectivity
skipping to change at page 35, line 44 skipping to change at page 39, line 51
dynamic control plane. This may be either by direct configuration of dynamic control plane. This may be either by direct configuration of
the PEs/LSRs, or via a network management system. Static operation the PEs/LSRs, or via a network management system. Static operation
is independent for a specific PW or LSP instance. Thus it should be is independent for a specific PW or LSP instance. Thus it should be
possible for a PW to be statically configured, while the LSP possible for a PW to be statically configured, while the LSP
supporting it is set up by a dynamic control plane. When static supporting it is set up by a dynamic control plane. When static
configuration mechanisms are used, care must be taken to ensure that configuration mechanisms are used, care must be taken to ensure that
loops are not created. loops are not created.
3.12. Survivability 3.12. Survivability
Survivability requirements for MPLS-TP are specified in The survivability architecture for MPLS-TP is 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 cannot be fully provided by the underlying LSP protection for the PW cannot be fully provided by the underlying LSP
(i.e. where the backup PW terminates on a different target PE node (i.e. where the backup PW terminates on a different target PE node
than the working PW in dual homing scenarios, or where protection of than the working PW in dual homing scenarios, or where protection of
skipping to change at page 36, line 22 skipping to change at page 40, line 29
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: different levels of resiliency, for example:
o Two concurrent traffic paths (1+1). o Two concurrent traffic paths (1+1).
o one active and one standby path with guaranteed bandwidth on both o one active and one standby path with guaranteed bandwidth on both
paths (1:1). paths (1:1).
o one active path and a standby path the resources or which are o one active path and a standby path the resources of which are
shared by one or more other active paths (shared protection). 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 scope of this document.
The characteristics of MPLS-TP resiliency mechanisms are as follows: The characteristics of MPLS-TP resiliency mechanisms are as follows:
o Optimised for linear, ring or meshed topologies. o Optimised for linear, ring or meshed topologies.
o Use OAM mechanisms to detect and localise 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 a Protection State Coordination (PSC) 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. section, LSP and PW), providing segment and
and end-to-end recovery. 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 behaviour. o MPLS-TP supports revertive and non-revertive behaviour.
3.13. Path Segment Tunnels 3.13. Path Segment Tunnels
In order to monitor, protect and manage a portion of an LSP, a new In order to monitor, protect and manage a portion of an LSP, a new
architectural element is defined called the Path Segment Tunnel architectural element is defined called the Path Segment Tunnel
(PST). A PST is a hierarchical LSP [RFC3031] which is defined and (PST). A PST is a hierarchical LSP [RFC3031] which is defined and
used for the purposes of OAM monitoring, protection or management of used for the purposes of OAM monitoring, protection or management of
LSP segments or concatenated LSP segments. LSP segments or concatenated LSP segments.
A PST is defined between the edges of the portion of the LSP that A PST is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. Maintenance messages needs to be monitored, protected or managed. OAM messages can be
can be initiated at the edge of the PST and sent to the peer edge of initiated at the edge of the PST and sent to the peer edge of the PST
the PST or to an intermediate point along the PST by setting the TTL or to a MIP along the PST by setting the TTL value at the PST level
value at the PST level accordingly. accordingly. A P router only pushes or pops a label if it is at the
end of a PST. In this mode, it is an LER for the PST.
For example in Figure 14, three PSTs are configured to allow For example in Figure 14, two PSTs are configured to allow
monitoring, protection and management of the LSP concatenated monitoring, protection and management of the LSP concatenated
segments. One PST is defined between PE1 and PE2, the second between segments. One PST is defined between LER2 and LER3, and a second PST
PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of is set up between LER4 and LER5. Each of these PSTs may be
these three PSTs may be monitored, protected, or managed monitored, protected, or managed independently.
independently.
========================== End to End LSP ============================= ======================== End to End LSP ===========================
|<--------- Carrier 1 --------->| |<----- Carrier 2 ----->| |<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |--- [LER1]---[LER2]---[LSR]---[LER3]-------[LER4]---[LSR]---[LER5]---[LER6]
|============= PST =============|==PST==|========= PST =========| |======= PST =========| |======= PST =========|
(Carrier 1) (Carrier 2) (Carrier 1) (Carrier 2)
Note: LER2, LER3, LER4 and LER5 are with respect to the PST
Figure 14: PSTs in inter-carrier network Figure 14: PSTs in inter-carrier network
The end-to-end traffic of the LSP, including data traffic and control The end-to-end traffic of the LSP, including data traffic and control
traffic (OAM, Protection Switching Control, management and signaling traffic (OAM, Protection Switching Control, management and signaling
messages) is tunneled within the PST by means of label stacking as messages) is tunneled within the PST by means of label stacking as
defined in [RFC3031]. defined in [RFC3031].
The mapping between an LSP and a PST can be 1:1, in which case it is The mapping between an LSP and a PST can be 1:1, in which case it is
similar to the ITU-T Tandem Connection element [G.805]. The mapping similar to the ITU-T Tandem Connection element [G.805]. The mapping
skipping to change at page 37, line 46 skipping to change at page 42, line 4
The end-to-end traffic of the LSP, including data traffic and control The end-to-end traffic of the LSP, including data traffic and control
traffic (OAM, Protection Switching Control, management and signaling traffic (OAM, Protection Switching Control, management and signaling
messages) is tunneled within the PST by means of label stacking as messages) is tunneled within the PST by means of label stacking as
defined in [RFC3031]. defined in [RFC3031].
The mapping between an LSP and a PST can be 1:1, in which case it is The mapping between an LSP and a PST can be 1:1, in which case it is
similar to the ITU-T Tandem Connection element [G.805]. The mapping similar to the ITU-T Tandem Connection element [G.805]. The mapping
can also be 1:N to allow aggregated monitoring, protection and can also be 1:N to allow aggregated monitoring, protection and
management of a set of LSP segments or concatenated LSP segments. management of a set of LSP segments or concatenated LSP segments.
Figure 15 shows a PST which is used to aggregate a set of Figure 15 shows a PST which is used to aggregate a set of
concatenated LSP segments for the LSP from PEx to PEt and the LSP concatenated LSP segments for the LSP from LERx to LERt and the LSP
from PEa to PEd. Note that such a construct is useful, for example, from LERa to LERd. Note that such a construct is useful, for
when the LSPs traverse a common portion of the network and they have example, when the LSPs traverse a common portion of the network and
the same Traffic Class. they have the same Traffic Class.
|PEx|--|PEy|-+ +-|PEz|--|PEt| |LERx|--|LSRy|-+ +-|LSRz|--|LERt|
| | | |
| |<---------- Carrier 1 --------->| | | |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ | | +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+ +--| |---| |---| |----| |--+
| PE1 | | P | | P | | PE2 | |LER1 | |LSR| |LSR| |LER2 |
+--| |---| |---| |----| |--+ +--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ | | +-----+ +---+ + P + +-----+ |
| |============= PST ==============| | | |============= PST ==============| |
|PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd| |LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
Figure 15: PST for a Set of Concatenated LSP Segments Figure 15: PST for a Set of Concatenated LSP Segments
3.13.1. Provisioning of PST
PSTs can be provisioned either statically or using control plane PSTs can be provisioned either statically or using control plane
signaling procedures. The make-before-break procedures which are signaling procedures. The make-before-break procedures which are
supported by MPLS allow the creation of a PST on existing LSPs in- supported by MPLS allow the creation of a PST on existing LSPs in-
service without traffic disruption. A PST can be defined service without traffic disruption. A PST can be defined
corresponding to one or more end-to-end tunneled LSPs. New end-to- corresponding to one or more end-to-end tunneled LSPs. New end-to-
end LSPs which are tunneled within the PST can be set up. Traffic of end LSPs which are tunneled within the PST can be set up. Traffic of
the existing LSPs is switched over to the new end-to-end tunneled the existing LSPs is switched over to the new end-to-end tunneled
LSPs. The old end-to-end LSPs can then be torn down. LSPs. The old end-to-end LSPs can then be torn down.
3.14. Pseudowire Segment Tunnels 3.14. Pseudowire Segment Tunnels
Pseudowire segment tunnels are for further study. Hierarchical label stacking, in a similar manner to that described
above, can be used to implement path segment tunnels on pseudowires.
3.15. Network Management 3.15. 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-framework] and specified in [I-D.ietf-mpls-tp-nm-framework] and
[I-D.ietf-mpls-tp-nm-req]. These derive from the generic [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. They also incorporate 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 expand 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 an 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), realised 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 an MPLS-TP NE, there is no restriction on which management to an MPLS-TP NE, there is no restriction on which management
protocol is used. The MCC is used to provision and manage an end-to- protocol is used. The Network Management System (NMS) is used to
end connection across a network where some segments are created/ provision and manage an end-to-end connection across a network where
managed by, for example, Netconf [RFC4741] or SNMP [RFC3411] and some segments are created/managed by, for example, Netconf [RFC4741]
other segments by XML or CORBA interfaces. Maintenance operations or SNMP [RFC3411] and other segments by XML or CORBA interfaces.
are run on a connection (LSP or PW) in a manner that is independent Maintenance operations are run on a connection (LSP or PW) in a
of the provisioning mechanism. An MPLS-TP NE is not required to manner that is independent of the provisioning mechanism. An MPLS-TP
offer more than one standard management interface. In MPLS-TP, the NE is not required to offer more than one standard management
EMF must be capable of statically provisioning LSPs for an LSR or interface. In MPLS-TP, the EMF must be capable of statically
LER, and PWs for a PE, as well as any associated MEPs and MIPs, as provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any
per Section 3.11. associated MEPs and MIPs, as per Section 3.11.
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.
Configuration Management (CM) provides functions to control, Configuration Management (CM) provides functions to control,
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 Maintenance Entity Group Endpoint (MEP) ID and
MEG Intermediate Point (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 The Performance Management (PM) functions within the EMF of an
MPLS-TP NE support the evaluation and reporting of the behaviour of MPLS-TP NE support the evaluation and reporting of the behaviour of
the NEs and the network. One particular requirement for PM is to the NEs and the network. One particular requirement for PM is to
provide coherent and consistent interpretation of the network provide coherent and consistent interpretation of the network
behaviour in a hybrid network that uses multiple transport behaviour in a hybrid network that uses multiple transport
skipping to change at page 40, line 12 skipping to change at page 44, line 18
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 Transport that utilise functionality outside of the strict MPLS Transport
Profile are 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
[RFC5659] apply. [RFC5659] apply.
Packets that arrive on an interface with a given label value should
not be forwarded unless that label value is assigned to an LSP or PW
to a peer LSR or PE that is reachable via that interface.
Each MPLS-TP solution must specify the additional security Each MPLS-TP solution must specify the additional security
considerations that apply. This is discussed further in considerations that apply. This is discussed further in
[I-D.fang-mpls-tp-security-framework]. [I-D.fang-mpls-tp-security-framework].
The security considerations in
[I-D.ietf-mpls-mpls-and-gmpls-security-framework] apply.
5. IANA Considerations 5. IANA Considerations
IANA considerations resulting from specific elements of MPLS-TP IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that functionality will be detailed in the documents specifying that
functionality. functionality.
This document introduces no additional IANA considerations in itself. This document introduces no additional IANA considerations in itself.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 40, line 46 skipping to change at page 45, line 4
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 Nurit Sprecher o Nurit Sprecher
o Martin Vigoureux o Martin Vigoureux
o Yaacov Weingarten o Yaacov Weingarten
o The participants of ITU-T SG15 o The participants of ITU-T SG15
7. Open Issues 7. References
This section contains a list of issues that must be resolved before 7.1. Normative References
last call.
o [G.7710] "ITU-T
Recommendation
G.7710/Y.1701
(07/07), "Common
equipment
management
function
requirements"",
2005.
8. References [G.805] "ITU-T
Recommendation
G.805 (11/95),
"Generic
Functional
Architecture of
Transport
Networks"",
November 1995.
8.1. Normative References [RFC3031] Rosen, E.,
Viswanathan, A.,
and R. Callon,
"Multiprotocol
Label Switching
Architecture",
RFC 3031,
January 2001.
[G.7710] "ITU-T Recommendation [RFC3032] Rosen, E., Tappan,
G.7710/Y.1701 (07/07), D., Fedorkow, G.,
"Common equipment Rekhter, Y.,
management function Farinacci, D., Li,
requirements"", 2005. T., and A. Conta,
"MPLS Label Stack
Encoding",
RFC 3032,
January 2001.
[G.805] "ITU-T Recommendation [RFC3270] Le Faucheur, F.,
G.805 (11/95), "Generic Wu, L., Davie, B.,
Functional Architecture Davari, S.,
of Transport Networks"", Vaananen, P.,
November 1995. Krishnan, R.,
Cheval, P., and J.
Heinanen, "Multi-
Protocol Label
Switching (MPLS)
Support of
Differentiated
Services",
RFC 3270,
May 2002.
[RFC3031] Rosen, E., Viswanathan, [RFC3473] Berger, L.,
A., and R. Callon, "Generalized
"Multiprotocol Label Multi-Protocol
Switching Architecture", Label Switching
RFC 3031, January 2001. (GMPLS) Signaling
Resource
ReserVation
Protocol-Traffic
Engineering
(RSVP-TE)
Extensions",
RFC 3473,
January 2003.
[RFC3032] Rosen, E., Tappan, D., [RFC3985] Bryant, S. and P.
Fedorkow, G., Rekhter, Pate, "Pseudo Wire
Y., Farinacci, D., Li, Emulation Edge-to-
T., and A. Conta, "MPLS Edge (PWE3)
Label Stack Encoding", Architecture",
RFC 3032, January 2001. RFC 3985,
March 2005.
[RFC3270] Le Faucheur, F., Wu, L., [RFC4090] Pan, P., Swallow,
Davie, B., Davari, S., G., and A. Atlas,
Vaananen, P., Krishnan, "Fast Reroute
R., Cheval, P., and J. Extensions to
Heinanen, "Multi-Protocol RSVP-TE for LSP
Label Switching (MPLS) Tunnels",
Support of Differentiated RFC 4090,
Services", RFC 3270, May 2005.
May 2002.
[RFC3471] Berger, L., "Generalized [RFC4385] Bryant, S.,
Multi-Protocol Label Swallow, G.,
Switching (GMPLS) Martini, L., and
Signaling Functional D. McPherson,
Description", RFC 3471, "Pseudowire
January 2003. Emulation Edge-to-
Edge (PWE3)
Control Word for
Use over an MPLS
PSN", RFC 4385,
February 2006.
[RFC3473] Berger, L., "Generalized [RFC4447] Martini, L.,
Multi-Protocol Label Rosen, E., El-
Switching (GMPLS) Aawar, N., Smith,
Signaling Resource T., and G. Heron,
ReserVation Protocol- "Pseudowire Setup
Traffic Engineering and Maintenance
(RSVP-TE) Extensions", Using the Label
RFC 3473, January 2003. Distribution
Protocol (LDP)",
RFC 4447,
April 2006.
[RFC3985] Bryant, S. and P. Pate, [RFC4872] Lang, J., Rekhter,
"Pseudo Wire Emulation Y., and D.
Edge-to-Edge (PWE3) Papadimitriou,
Architecture", RFC 3985, "RSVP-TE
March 2005. Extensions in
Support of End-to-
End Generalized
Multi-Protocol
Label Switching
(GMPLS) Recovery",
RFC 4872,
May 2007.
[RFC4090] Pan, P., Swallow, G., and [RFC5085] Nadeau, T. and C.
A. Atlas, "Fast Reroute Pignataro,
Extensions to RSVP-TE for "Pseudowire
LSP Tunnels", RFC 4090, Virtual Circuit
May 2005. Connectivity
Verification
(VCCV): A Control
Channel for
Pseudowires",
RFC 5085,
December 2007.
[RFC4385] Bryant, S., Swallow, G., [RFC5586] Bocci, M.,
Martini, L., and D. Vigoureux, M., and
McPherson, "Pseudowire S. Bryant, "MPLS
Emulation Edge-to-Edge Generic Associated
(PWE3) Control Word for Channel",
Use over an MPLS PSN", RFC 5586,
RFC 4385, February 2006. June 2009.
[RFC4447] Martini, L., Rosen, E., 7.2. Informative References
El-Aawar, N., Smith, T.,
and G. Heron, "Pseudowire
Setup and Maintenance
Using the Label
Distribution Protocol
(LDP)", RFC 4447,
April 2006.
[RFC4872] Lang, J., Rekhter, Y., [G.8080] "ITU-T
and D. Papadimitriou, Recommendation
"RSVP-TE Extensions in G.8080/Y.1304,
Support of End-to-End "Architecture for
Generalized Multi- the automatically
Protocol Label Switching switched optical
(GMPLS) Recovery", network (ASON)"",
RFC 4872, May 2007. 2005.
[RFC5085] Nadeau, T. and C. [I-D.fang-mpls-tp-security-framework] Fang, L. and B.
Pignataro, "Pseudowire Niven-Jenkins,
Virtual Circuit "Security
Connectivity Verification Framework for
(VCCV): A Control Channel MPLS-TP", draft-
for Pseudowires", fang-mpls-tp-
RFC 5085, December 2007. security-
framework-01 (work
in progress),
March 2010.
[RFC5462] Andersson, L. and R. [I-D.ietf-bfd-mpls] Aggarwal, R.,
Asati, "Multiprotocol Kompella, K.,
Label Switching (MPLS) Nadeau, T., and G.
Label Stack Entry: "EXP" Swallow, "BFD For
Field Renamed to "Traffic MPLS LSPs", draft-
Class" Field", RFC 5462, ietf-bfd-mpls-07
February 2009. (work in
progress),
June 2008.
[RFC5586] Bocci, M., Vigoureux, M., [I-D.ietf-ccamp-mpls-tp-cp-framework] Andersson, L.,
and S. Bryant, "MPLS Berger, L., Fang,
Generic Associated L., Bitar, N.,
Channel", RFC 5586, Takacs, A.,
June 2009. Vigoureux, M.,
Bellagamba, E.,
and E. Gray,
"MPLS-TP Control
Plane Framework",
draft-ietf-ccamp-
mpls-tp-cp-
framework-01 (work
in progress),
March 2010.
8.2. Informative References [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y.,
JOUNAY, F., Niven-
Jenkins, B.,
Brungard, D., and
L. Jin, "Framework
and Requirements
for Virtual
Private Multicast
Service (VPMS)", d
raft-ietf-l2vpn-
vpms-frmwk-
requirements-02
(work in
progress),
October 2009.
[I-D.abfb-mpls-tp-control-plane-framework] Andersson, L., Berger, [I-D.ietf-mpls-mpls-and-gmpls-security-framework] Fang, L. and M.
L., Fang, L., Bitar, N., Behringer,
Takacs, A., and M. "Security
Vigoureux, "MPLS-TP Framework for MPLS
Control Plane Framework", and GMPLS
draft-abfb-mpls-tp- Networks", draft-
control-plane-framework- ietf-mpls-mpls-
01 (work in progress), and-gmpls-
July 2009. security-
framework-09 (work
in progress),
March 2010.
[I-D.fang-mpls-tp-security-framework] Fang, L. and B. Niven- [I-D.ietf-mpls-tp-data-plane] Frost, D., Bryant,
Jenkins, "Security S., and M. Bocci,
Framework for MPLS-TP", d "MPLS Transport
raft-fang-mpls-tp- Profile Data Plane
security-framework-00 Architecture", dra
(work in progress), ft-ietf-mpls-tp-
July 2009. data-plane-01
(work in
progress),
March 2010.
[I-D.fbb-mpls-tp-data-plane] Frost, D., Bryant, S., [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G.
and M. Bocci, "MPLS Swallow, "MPLS-TP
Transport Profile Data Identifiers", draf
Plane Architecture", draf t-ietf-mpls-tp-
t-fbb-mpls-tp-data-plane- identifiers-01
00 (work in progress), (work in
February 2010. progress),
March 2010.
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, [I-D.ietf-mpls-tp-nm-framework] Mansfield, S.,
K., Nadeau, T., and G. Gray, E., and H.
Swallow, "BFD For MPLS Lam, "MPLS-TP
LSPs", Network Management
draft-ietf-bfd-mpls-07 Framework", draft-
(work in progress), ietf-mpls-tp-nm-
June 2008. framework-05 (work
in progress),
February 2010.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F., [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and
Niven-Jenkins, B., K. Lam, "MPLS TP
Brungard, D., and L. Jin, Network Management
"Framework and Requirements", dra
Requirements for Virtual ft-ietf-mpls-tp-
Private Multicast Service nm-req-06 (work in
(VPMS)", draft-ietf- progress),
l2vpn-vpms-frmwk- October 2009.
requirements-02 (work in
progress), October 2009.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi,
"MPLS-TP Identifiers", dr I., and B. Niven-
aft-ietf-mpls-tp- Jenkins, "MPLS-TP
identifiers-00 (work in OAM Framework", dr
progress), November 2009. aft-ietf-mpls-tp-
oam-framework-05
(work in
progress),
March 2010.
[I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E., [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M. and
and H. Lam, "MPLS-TP D. Ward,
Network Management "Requirements for
Framework", draft-ietf- OAM in MPLS
mpls-tp-nm-framework-04 Transport
(work in progress), Networks", draft-
January 2010. ietf-mpls-tp-oam-
requirements-06
(work in
progress),
March 2010.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and
"MPLS TP Network A. Farrel,
Management Requirements", "Multiprotocol
draft-ietf-mpls-tp-nm- Label Switching
req-06 (work in Transport Profile
progress), October 2009. Survivability
Framework", draft-
ietf-mpls-tp-
survive-fwk-04
(work in
progress),
March 2010.
[I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L.,
B. Niven-Jenkins, Bocci, M., Balus,
"MPLS-TP OAM Framework", F., Bitar, N.,
draft-ietf-mpls-tp-oam- Shah, H.,
framework-04 (work in Aissaoui, M.,
progress), December 2009. Rusmisel, J.,
Serbest, Y.,
Malis, A., Metz,
C., McDysan, D.,
Sugimoto, J.,
Duckett, M.,
Loomis, M.,
Doolan, P., Pan,
P., Pate, P.,
Radoaca, V., Wada,
Y., and Y. Seo,
"Dynamic Placement
of Multi Segment
Pseudo Wires", dra
ft-ietf-pwe3-
dynamic-ms-pw-10
(work in
progress),
October 2009.
[I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., [I-D.ietf-pwe3-redundancy] Muley, P. and V.
and M. Betts, Place, "Pseudowire
"Requirements for OAM in (PW) Redundancy",
MPLS Transport Networks", draft-ietf-pwe3-
draft-ietf-mpls-tp-oam- redundancy-02
requirements-04 (work in (work in
progress), December 2009. progress),
October 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. [I-D.ietf-pwe3-segmented-pw] Martini, L.,
Farrel, "Multiprotocol Nadeau, T., Metz,
Label Switching Transport C., Duckett, M.,
Profile Survivability Bocci, M., Balus,
Framework", draft-ietf- F., and M.
mpls-tp-survive-fwk-03 Aissaoui,
(work in progress), "Segmented
November 2009. Pseudowire", draft
-ietf-pwe3-
segmented-pw-13
(work in
progress),
August 2009.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., [I-D.ietf-pwe3-vccv-bfd] Nadeau, T. and C.
Balus, F., Bitar, N., Pignataro,
Shah, H., Aissaoui, M., "Bidirectional
Rusmisel, J., Serbest, Forwarding
Y., Malis, A., Metz, C., Detection (BFD)
McDysan, D., Sugimoto, for the Pseudowire
J., Duckett, M., Loomis, Virtual Circuit
M., Doolan, P., Pan, P., Connectivity
Pate, P., Radoaca, V., Verification
Wada, Y., and Y. Seo, (VCCV)", draft-
"Dynamic Placement of ietf-pwe3-vccv-
Multi Segment Pseudo bfd-07 (work in
Wires", draft-ietf-pwe3- progress),
dynamic-ms-pw-10 (work in July 2009.
progress), October 2009.
[I-D.ietf-pwe3-redundancy] Muley, P. and V. Place, [RFC3209] Awduche, D.,
"Pseudowire (PW) Berger, L., Gan,
Redundancy", draft-ietf- D., Li, T.,
pwe3-redundancy-02 (work Srinivasan, V.,
in progress), and G. Swallow,
October 2009. "RSVP-TE:
Extensions to RSVP
for LSP Tunnels",
RFC 3209,
December 2001.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., [RFC3411] Harrington, D.,
Metz, C., Duckett, M., Presuhn, R., and
Bocci, M., Balus, F., and B. Wijnen, "An
M. Aissaoui, "Segmented Architecture for
Pseudowire", draft-ietf- Describing Simple
pwe3-segmented-pw-13 Network Management
(work in progress), Protocol (SNMP)
August 2009. Management
Frameworks",
STD 62, RFC 3411,
December 2002.
[RFC3209] Awduche, D., Berger, L., [RFC3443] Agarwal, P. and B.
Gan, D., Li, T., Akyol, "Time To
Srinivasan, V., and G. Live (TTL)
Swallow, "RSVP-TE: Processing in
Extensions to RSVP for Multi-Protocol
LSP Tunnels", RFC 3209, Label Switching
December 2001. (MPLS) Networks",
RFC 3443,
January 2003.
[RFC3411] Harrington, D., Presuhn, [RFC3471] Berger, L.,
R., and B. Wijnen, "An "Generalized
Architecture for Multi-Protocol
Describing Simple Network Label Switching
Management Protocol (GMPLS) Signaling
(SNMP) Management Functional
Frameworks", STD 62, Description",
RFC 3411, December 2002. RFC 3471,
January 2003.
[RFC3443] Agarwal, P. and B. Akyol, [RFC3945] Mannie, E.,
"Time To Live (TTL) "Generalized
Processing in Multi- Multi-Protocol
Protocol Label Switching Label Switching
(MPLS) Networks", (GMPLS)
RFC 3443, January 2003. Architecture",
RFC 3945,
October 2004.
[RFC3945] Mannie, E., "Generalized [RFC4216] Zhang, R. and J.
Multi-Protocol Label Vasseur, "MPLS
Switching (GMPLS) Inter-Autonomous
Architecture", RFC 3945, System (AS)
October 2004. Traffic
Engineering (TE)
Requirements",
RFC 4216,
November 2005.
[RFC4216] Zhang, R. and J. Vasseur, [RFC4364] Rosen, E. and Y.
"MPLS Inter-Autonomous
System (AS) Traffic
Engineering (TE)
Requirements", RFC 4216,
November 2005.
[RFC4364] Rosen, E. and Y. Rekhter, Rekhter, "BGP/MPLS
"BGP/MPLS IP Virtual IP Virtual Private
Private Networks (VPNs)", Networks (VPNs)",
RFC 4364, February 2006. RFC 4364,
February 2006.
[RFC4377] Nadeau, T., Morrow, M., [RFC4377] Nadeau, T.,
Swallow, G., Allan, D., Morrow, M.,
and S. Matsushima, Swallow, G.,
"Operations and Allan, D., and S.
Management (OAM) Matsushima,
Requirements for Multi- "Operations and
Protocol Label Switched Management (OAM)
(MPLS) Networks", Requirements for
RFC 4377, February 2006. Multi-Protocol
Label Switched
(MPLS) Networks",
RFC 4377,
February 2006.
[RFC4379] Kompella, K. and G. [RFC4379] Kompella, K. and
Swallow, "Detecting G. Swallow,
Multi-Protocol Label "Detecting Multi-
Switched (MPLS) Data Protocol Label
Plane Failures", Switched (MPLS)
RFC 4379, February 2006. Data Plane
Failures",
RFC 4379,
February 2006.
[RFC4664] Andersson, L. and E. [RFC4664] Andersson, L. and
Rosen, "Framework for E. Rosen,
Layer 2 Virtual Private "Framework for
Networks (L2VPNs)", Layer 2 Virtual
RFC 4664, September 2006. Private Networks
(L2VPNs)",
RFC 4664,
September 2006.
[RFC4741] Enns, R., "NETCONF [RFC4741] Enns, R., "NETCONF
Configuration Protocol", Configuration
RFC 4741, December 2006. Protocol",
RFC 4741,
December 2006.
[RFC5150] Ayyangar, A., Kompella, [RFC5150] Ayyangar, A.,
K., Vasseur, JP., and A. Kompella, K.,
Farrel, "Label Switched Vasseur, JP., and
Path Stitching with A. Farrel, "Label
Generalized Multiprotocol Switched Path
Label Switching Traffic Stitching with
Engineering (GMPLS TE)", Generalized
RFC 5150, February 2008. Multiprotocol
Label Switching
Traffic
Engineering (GMPLS
TE)", RFC 5150,
February 2008.
[RFC5254] Bitar, N., Bocci, M., and [RFC5254] Bitar, N., Bocci,
L. Martini, "Requirements M., and L.
for Multi-Segment Martini,
Pseudowire Emulation "Requirements for
Edge-to-Edge (PWE3)", Multi-Segment
RFC 5254, October 2008. Pseudowire
Emulation Edge-to-
Edge (PWE3)",
RFC 5254,
October 2008.
[RFC5309] Shen, N. and A. Zinin, [RFC5309] Shen, N. and A.
"Point-to-Point Operation Zinin, "Point-to-
over LAN in Link State Point Operation
Routing Protocols", over LAN in Link
RFC 5309, October 2008. State Routing
Protocols",
RFC 5309,
October 2008.
[RFC5331] Aggarwal, R., Rekhter, [RFC5331] Aggarwal, R.,
Y., and E. Rosen, "MPLS Rekhter, Y., and
Upstream Label Assignment E. Rosen, "MPLS
and Context-Specific Upstream Label
Label Space", RFC 5331, Assignment and
August 2008. Context-Specific
Label Space",
RFC 5331,
August 2008.
[RFC5654] Niven-Jenkins, B., [RFC5654] Niven-Jenkins, B.,
Brungard, D., Betts, M., Brungard, D.,
Sprecher, N., and S. Betts, M.,
Ueno, "Requirements of an Sprecher, N., and
MPLS Transport Profile", S. Ueno,
RFC 5654, September 2009. "Requirements of
an MPLS Transport
Profile",
RFC 5654,
September 2009.
[RFC5659] Bocci, M. and S. Bryant, [RFC5659] Bocci, M. and S.
"An Architecture for Bryant, "An
Multi-Segment Pseudowire Architecture for
Emulation Edge-to-Edge", Multi-Segment
RFC 5659, October 2009. Pseudowire
Emulation Edge-to-
Edge", RFC 5659,
October 2009.
[RFC5718] Beller, D. and A. Farrel, [RFC5718] Beller, D. and A.
"An In-Band Data Farrel, "An In-
Communication Network For Band Data
the MPLS Transport Communication
Profile", RFC 5718, Network For the
January 2010. MPLS Transport
Profile",
RFC 5718,
January 2010.
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:
 End of changes. 226 change blocks. 
937 lines changed or deleted 1320 lines changed or added

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