draft-ietf-mpls-tp-framework-12.txt   rfc5921.txt 
MPLS Working Group M. Bocci, Ed. Internet Engineering Task Force (IETF) M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Request for Comments: 5921 Alcatel-Lucent
Intended status: Informational S. Bryant, Ed. Category: Informational S. Bryant, Ed.
Expires: November 6, 2010 D. Frost, Ed. ISSN: 2070-1721 D. Frost, Ed.
Cisco Systems Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN LabN
May 5, 2010 July 2010
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-12
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-
(MPLS-TP) - that supports the operational models and capabilities TP) -- that supports the operational models and capabilities typical
typical of such networks, including signaled or explicitly of such networks, including signaled or explicitly provisioned
provisioned bidirectional connection-oriented paths, protection and bidirectional connection-oriented paths, protection and restoration
restoration mechanisms, comprehensive Operations, Administration and mechanisms, comprehensive Operations, Administration, and Maintenance
Maintenance (OAM) functions, and network operation in the absence of (OAM) functions, and network operation in the absence of a dynamic
a dynamic control plane or IP forwarding support. Some of these control plane or IP forwarding support. Some of these functions are
functions are defined in existing MPLS specifications, while others defined in existing MPLS specifications, while others require
require extensions to existing specifications to meet the extensions to existing specifications to meet the requirements of the
requirements of the MPLS-TP. 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 transport paths. The remaining subset, and to point-to-point transport paths. The remaining subset,
applicable specifically to point-to-multipoint transport paths, is applicable specifically to point-to-multipoint transport paths, is
outside the scope of this 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 Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
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 Pseudowire Emulation Edge-to-Edge
capabilities and functionalities of a packet transport network as (PWE3) architectures to support the capabilities and functionalities
defined by the ITU-T. of a packet transport network as defined by the ITU-T.
This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF
Last Call.
[RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published
RFC has IETF Consensus.]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on November 6, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5921.
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
skipping to change at page 2, line 45 skipping to change at page 3, line 11
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 Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . 8 1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 9 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 10
1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 9 1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 10
1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10 1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10
1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10 1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10
1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10 1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10
1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11 1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11
1.3.13. Additional Definitions and Terminology . . . . . . . . 11 1.3.13. Additional Definitions and Terminology . . . . . . . . 11
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 11 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 11 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 12 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14 3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16 3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16
3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16 3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16
3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17 3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17
3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18 3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18
3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25 3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25
3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28 3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33
3.7. Operations, Administration and Maintenance (OAM) . . . . . 35 3.7. Operations, Administration, and Maintenance (OAM) . . . . 36
3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 37 3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 38
3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 38 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 39
3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39
3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 39 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 40
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 39 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 40
3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40
3.10. Interdomain Connectivity . . . . . . . . . . . . . . . . . 42 3.10. Inter-Domain Connectivity . . . . . . . . . . . . . . . . 43
3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 42 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 43
3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 43 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 44
3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 44 3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 45
3.14. Network Management . . . . . . . . . . . . . . . . . . . . 46 3.14. Network Management . . . . . . . . . . . . . . . . . . . . 47
4. Security Considerations . . . . . . . . . . . . . . . . . . . 47 4. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 50 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . . 53 7.2. Informative References . . . . . . . . . . . . . . . . . . 51
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 transport paths. MPLS Transport Profile (MPLS-TP) for point-to-point transport paths.
The remaining MPLS-TP functions, applicable specifically to point-to- The remaining MPLS-TP functions, applicable specifically to point-to-
multipoint transport paths, are outside the 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
for reliability and operational simplicity. To achieve this, benchmark for reliability and operational simplicity. To achieve
transport technologies have been designed with specific this, 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, for example by network management and may be provisioned manually, for example, by network
systems or direct node configuration using a command line management systems or direct node configuration using a command
interface. line interface.
o A high level of availability. o A high level of availability.
o Quality of service. o Quality of service.
o Extensive Operations, Administration and Maintenance (OAM) o Extensive Operations, Administration, and Maintenance (OAM)
capabilities. 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
transport networks. transport networks.
In order to achieve these objectives, there is a need to define a In order to achieve these objectives, there is a need to define a
common set of MPLS protocol functions - an MPLS Transport Profile - common set of MPLS protocol functions -- an MPLS Transport Profile --
for the use of MPLS in transport networks and applications. Some of for the use of MPLS in transport networks and applications. Some of
the necessary functions are provided by existing MPLS specifications, the necessary functions are provided by existing MPLS specifications,
while others require additions to the MPLS tool-set. Such additions while others require additions to the MPLS tool-set. Such additions
should, wherever possible, be applicable to MPLS networks in general should, wherever possible, be applicable to MPLS networks in general
as well as those that conform strictly to the transport network as well as those that conform strictly to the transport network
model. model.
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 Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
skipping to change at page 5, line 50 skipping to change at page 6, line 10
APS Automatic Protection Switching APS Automatic Protection Switching
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
CE Customer Edge CE Customer Edge
CL-PS Connectionless - Packet Switched CL-PS Connectionless - Packet Switched
CM Configuration Management CM Configuration Management
CO-CS Connection Oriented - Circuit Switched CO-CS Connection Oriented - Circuit Switched
CO-PS Connection Oriented - Packet Switched CO-PS Connection Oriented - Packet Switched
DCN Data Communication Network DCN Data Communication Network
EMF Equipment Management Function EMF Equipment Management Function
FCAPS Fault, Configuration, Accounting, Performance and Security FCAPS Fault, Configuration, Accounting, Performance, and
Security
FM Fault Management FM Fault Management
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL G-ACh Label GAL G-ACh Label
LER Label Edge Router LER Label Edge Router
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MAC Media Access Control MAC Media Access Control
MCC Management Communication Channel MCC Management Communication Channel
ME Maintenance Entity ME Maintenance Entity
MEG Maintenance Entity Group MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
MPLS Multiprotocol Label Switching MPLS Multiprotocol Label Switching
MPLS-TP MPLS Transport Profile MPLS-TP MPLS Transport Profile
MPLS-TP P MPLS-TP Provider LSR MPLS-TP P MPLS-TP Provider LSR
MPLS-TP PE MPLS-TP Provider Edge LSR MPLS-TP PE MPLS-TP Provider Edge LSR
MS-PW Multi-Segment Pseudowire MS-PW Multi-Segment Pseudowire
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
OAM Operations, Administration and Maintenance (see OAM Operations, Administration, and Maintenance (see
[I-D.ietf-opsawg-mpls-tp-oam-def]) [OAM-DEF])
OSI Open Systems Interconnection OSI Open Systems Interconnection
OTN Optical Transport Network OTN Optical Transport Network
PDU Protocol Data Unit PDU Protocol Data Unit
PM Performance Monitoring PM Performance Monitoring
PSN Packet Switching Network PSN Packet Switching Network
PW Pseudowire PW Pseudowire
SCC Signaling Communication Channel SCC Signaling Communication Channel
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
S-PE PW Switching Provider Edge S-PE PW Switching Provider Edge
SPME Sub-Path Maintenance Element SPME Sub-Path Maintenance Element
SS-PW Single-Segment Pseudowire
T-PE PW Terminating Provider Edge T-PE PW Terminating Provider Edge
TE LSP Traffic Engineered Label Switched Path
VCCV Virtual Circuit Connectivity Verification VCCV Virtual Circuit Connectivity Verification
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 user traffic
plane traffic between attached client devices by establishing and between attached client devices by establishing and maintaining
maintaining point-to-point or point-to-multipoint connections between point-to-point or point-to-multipoint connections between such
such devices. The architecture of networks supporting point-to- devices. The architecture of networks supporting point-to-multipoint
multipoint connections is outside the scope of this document. A connections is outside the scope of this document. A Transport
Transport Network is independent of any higher-layer network that may Network is independent of any higher-layer network that may exist
exist between clients, except to the extent required to supply this 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
MPLS-TP Sections are defined in [I-D.ietf-mpls-tp-data-plane]. See MPLS-TP sections are defined in [DATA-PLANE]. See also the
also the definition of "section layer network" in Section 1.2.2 of definition of "section layer network" in Section 1.2.2 of [RFC5654].
[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 in [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 supported. point and multipoint-to-multipoint LSPs are not supported.
6. It is either unidirectional, associated bidirectional, or co- 6. It is either unidirectional, associated bidirectional, or co-
routed bidirectional (i.e. the forward and reverse components of routed bidirectional (i.e., the forward and reverse components of
a bidirectional LSP follow the same path and the intermediate a bidirectional LSP follow the same path, and the intermediate
nodes are aware of their association). These are further defined nodes are aware of their association). These are further defined
in [I-D.ietf-mpls-tp-data-plane]. in [DATA-PLANE].
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.
See [I-D.ietf-mpls-tp-data-plane] for further details on the types See [DATA-PLANE] for further details on the types and data-plane
and data-plane properties of MPLS-TP LSPs. properties of MPLS-TP LSPs.
The lowest server layer provided by MPLS-TP is an MPLS-TP LSP. The 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 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 LSPs, or PWs. The relationship of an MPLS-TP LSP to its client
layers is described in detail in Section 3.4. layers is described in detail in Section 3.4.
1.3.5. MPLS-TP Label Switching Router 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. Label Edge Router 1.3.5.1. Label Edge Router
An MPLS-TP Label Edge Router (LER) is an LSR that exists at the 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. 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 does not perform a label swap on the particular LSP under
consideration. consideration.
1.3.5.2. MPLS-TP Provider Edge Router 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
skipping to change at page 8, line 49 skipping to change at page 9, line 16
network. A provider edge router resides at the edge of a given network. A provider edge router resides at the edge of a given
MPLS-TP network domain, in which case it has links to another MPLS-TP MPLS-TP network domain, in which case it has links to another MPLS-TP
network domain or to a CE, except for the case of a pseudowire network domain or to a CE, except for the case of a pseudowire
switching provider edge (S-PE) router, which is not restricted to the switching provider edge (S-PE) router, which is not restricted to the
edge of an MPLS-TP network domain. edge of an MPLS-TP network domain.
1.3.5.3. MPLS-TP Provider 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 that carry client traffic, but does not adapt client
traffic and encapsulate it to be carried over an MPLS-TP LSP. The traffic and encapsulate it to be carried over an MPLS-TP LSP. The
term Provider Router refers to the node's role within a provider's term Provider Router refers to the node's role within a provider's
network. A provider router does not have links to other MPLS-TP network. A provider router does not have links to other MPLS-TP
network domains. network domains.
1.3.5.4. Pseudowire Switching Provider Edge Router (S-PE) 1.3.5.4. Pseudowire Switching Provider Edge Router (S-PE)
RFC5659[RFC5659] defines an S-PE as: RFC 5659 [RFC5659] defines an S-PE as:
"A PE capable of switching the control and data planes of the A PE capable of switching the control and data planes of the
preceding and succeeding PW segments in an MS-PW. The S-PE preceding and succeeding PW segments in an MS-PW. The S-PE
terminates the PSN tunnels of the preceding and succeeding terminates the PSN tunnels of the preceding and succeeding
segments of the MS-PW. It therefore includes a PW switching point segments of the MS-PW. It therefore includes a PW switching point
for an MS-PW. A PW switching point is never the S-PE and the T-PE for an MS-PW. A PW switching point is never the S-PE and the T-PE
for the same MS-PW. A PW switching point runs necessary protocols for the same MS-PW. A PW switching point runs necessary protocols
to set up and manage PW segments with other PW switching points to set up and manage PW segments with other PW switching points
and terminating PEs. An S-PE can exist anywhere a PW must be and terminating PEs. An S-PE can exist anywhere a PW must be
processed or policy applied. It is therefore not limited to the processed or policy applied. It is therefore not limited to the
edge of a provider network. edge of a provider network.
"Note that it was originally anticipated that S-PEs would only be Note that it was originally anticipated that S-PEs would only be
deployed at the edge of a provider network where they would be deployed at the edge of a provider network where they would be
used to switch the PWs of different service providers. However, used to switch the PWs of different service providers. However,
as the design of MS-PW progressed, other applications for MS-PW as the design of MS-PW progressed, other applications for MS-PW
were recognized. By this time S-PE had become the accepted term were recognized. By this time S-PE had become the accepted term
for the equipment, even though they were no longer universally for the equipment, even though they were no longer universally
deployed at the provider edge." deployed at the provider edge.
1.3.5.5. Pseudowire Terminating Provider Edge Router (T-PE) 1.3.5.5. Pseudowire Terminating Provider Edge (T-PE) Router
RFC5659[RFC5659] defines a T-PE as: RFC 5659 [RFC5659] defines a T-PE as:
"A PE where the customer- facing attachment circuits (ACs) are A PE where the customer-facing attachment circuits (ACs) are bound
bound to a PW forwarder. A terminating PE is present in the first to a PW forwarder. A terminating PE is present in the first and
and last segments of an MS-PW. This incorporates the last segments of an MS-PW. This incorporates the functionality of
functionality of a PE as defined in RFC 3985." a PE as defined in RFC 3985.
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 that sources or sinks
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 link. a single link.
1.3.7. Transport LSP 1.3.7. Transport LSP
A Transport LSP is an LSP between a pair of PEs that may transit zero A Transport LSP is an LSP between a pair of PEs that may transit zero
or more MPLS-TP provider routers. When carrying PWs, the transport or more MPLS-TP provider routers. When carrying PWs, the Transport
LSP is equivalent to the PSN tunnel LSP in [RFC3985] terminology. LSP is equivalent to the PSN tunnel LSP in [RFC3985] terminology.
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 A layer network is defined in [G.805] and described in [RFC5654]. A
layer network provides for the transfer of client information and layer network provides for the transfer of client information and
skipping to change at page 10, line 28 skipping to change at page 10, line 41
composition of physical network elements. A particular physical composition of physical network elements. A particular physical
network element may topologically belong to more than one layer network element may topologically belong to more than one layer
network, depending on the actions it takes on the encapsulation network, depending on the actions it takes on the encapsulation
associated with the logical layers (e.g., the label stack), and thus associated with the logical layers (e.g., the label stack), and thus
could be modeled as multiple logical elements. A layer network may could be modeled as multiple logical elements. A layer network may
consist of one or more sublayers. consist of one or more sublayers.
1.3.10. Network Layer 1.3.10. Network Layer
This document uses the term Network Layer in the same sense as it is This document uses the term Network Layer in the same sense as it is
used in [RFC3031] and [RFC3032]. Network layer protocols are used in [RFC3031] and [RFC3032]. Network-layer protocols are
synymous with those beloging to layer 3 of the Open System synonymous with those belonging to Layer 3 of the Open System
Interconnect (OSI) network model [X.200]. Interconnect (OSI) network model [X.200].
1.3.11. Service Interface 1.3.11. Service Interface
The packet transport service provided by MPLS-TP is provided at a The packet transport service provided by MPLS-TP is provided at a
service interface. Two types of service interfaces are defined: service interface. Two types of service interfaces are defined:
o User-Network Interface (UNI) (see Section 3.4.3.1). o User-Network Interface (UNI) (see Section 3.4.3.1).
o Network-Network Interface (NNI) (see Section 3.4.3.2). o Network-Network Interface (NNI) (see Section 3.4.3.2).
A UNI service interface may be a layer 2 interface that carries only A UNI service interface may be a Layer 2 interface that carries only
network layer clients. MPLS-TP LSPs are both necessary and network layer clients. MPLS-TP LSPs are both necessary and
sufficient to support this service interface as described in section sufficient to support this service interface as described in
3.4.3. Alternatively, it may be a layer 2 interface that carries Section 3.4.3. Alternatively, it may be a Layer 2 interface that
both network layer and non-network layer clients. To support this carries both network-layer and non-network-layer clients. To support
service interface, a PW is required to adapt the client traffic 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 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. the MPLS-TP server layer. This is described in Section 3.4.2.
An NNI service interface may be to an MPLS LSP or a PW. To support An NNI service interface may be to an MPLS LSP or a PW. To support
this case an MPLS-TP PE participates in the service interface this case, an MPLS-TP PE participates in the service interface
signaling. signaling.
1.3.12. Native Service 1.3.12. Native Service
The native service is the client layer network service that is The native service is the client layer network service that is
transported by the MPLS-TP network, whether a pseudowire or an LSP is transported by the MPLS-TP network, whether a pseudowire or an LSP is
used for the adaptation (see Section 3.4). used for the adaptation (see Section 3.4).
1.3.13. Additional Definitions and Terminology 1.3.13. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in Detailed definitions and additional terminology may be found in
[RFC5654] and [I-D.ietf-mpls-tp-rosetta-stone]. [RFC5654] and [ROSETTA-STONE].
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], [RFC5860],
[I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req]. and [NM-REQ]. This section provides a brief reminder to guide the
This section provides a brief reminder to guide the reader. It is reader. It is not normative or intended as a substitute for these
not normative or intended as a substitute for these documents. 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 bidirectional, and it Point-to-point LSPs may be unidirectional or bidirectional, and it
must be possible to construct congruent bidirectional LSPs. must be possible to construct congruent bidirectional 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.
It must be possible to forward packets solely based on switching the It must be possible to forward packets solely based on switching the
MPLS or PW label. It must also be possible to establish and maintain MPLS or PW label. It must also be possible to establish and maintain
LSPs and/or pseudowires both in the absence or presence of a dynamic LSPs and/or pseudowires both in the absence or presence of a dynamic
control plane. When static provisioning is used, there must be no control plane. When static provisioning is used, there must be no
dependency on dynamic routing or signaling. dependency on dynamic routing or signaling.
OAM, protection and forwarding of data packets must be able to OAM and protection mechanisms, and forwarding of data packets, must
operate without IP forwarding support. be able to operate without IP forwarding support.
It must be possible to monitor LSPs and pseudowires through the use It must be possible to monitor LSPs and pseudowires through the use
of OAM in the absence of control plane or routing functions. In this of OAM in the absence of control-plane or routing functions. In this
case information gained from the OAM functions is used to initiate case, information gained from the OAM functions is used to initiate
path recovery actions at either the PW or LSP layers. path recovery actions at either the PW or LSP layers.
3. MPLS Transport Profile Overview 3. MPLS Transport Profile Overview
3.1. Packet Transport Services 3.1. Packet Transport Services
One objective of MPLS-TP is to enable MPLS networks to provide packet One objective of MPLS-TP is to enable MPLS networks to provide packet
transport services with a similar degree of predictability to that transport services with a similar degree of predictability to that
found in existing transport networks. Such packet transport services found in existing transport networks. Such packet transport services
exhibit a number of characteristics, defined in [RFC5654]: exhibit a number of characteristics, defined in [RFC5654]:
o In an environment where an MPLS-TP layer network is supporting a o In an environment where an MPLS-TP layer network is supporting a
client layer network, and the MPLS-TP layer network is supported client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer by a server layer network then operation of the MPLS-TP layer
network must be possible without any dependencies on either the network must be possible without any dependencies on either the
server or client layer network. server or client layer network.
o The service provided by the MPLS-TP network to a given client will o The service provided by the MPLS-TP network to a given client will
not to fall below the agreed level as a result of the traffic not fall below the agreed level as a result of the traffic loading
loading of other clients. of other clients.
o The control and management planes of any client network layer that o The control and management planes of any client network layer that
uses the service is isolated from the control and management uses the service is isolated from the control and management
planes of the MPLS-TP layer network, where the client network planes of the MPLS-TP layer network, where the client network
layer is considered to be the native service of the MPLS-TP layer is considered to be the native service of the MPLS-TP
network. network.
o Where a client network makes use of an MPLS-TP server that o Where a client network makes use of an MPLS-TP server that
provides a packet transport service, the level of co-ordination provides a packet transport service, the level of coordination
required between the client and server layer networks is minimal required between the client and server layer networks is minimal
(preferably no co-ordination will be required). (preferably no coordination will be required).
o The complete set of packets generated by a client MPLS(-TP) layer o The complete set of packets generated by a client MPLS(-TP) layer
network using the packet transport service, which may contain network using the packet transport service, which may contain
packets that are not MPLS packets (e.g. IP or CLNS packets used packets that are not MPLS packets (e.g., IP or CLNS
by the control/management plane of the client MPLS(-TP) layer (Connectionless Network Service) packets used by the control/
network), are transported by the MPLS-TP server layer network. management plane of the client MPLS(-TP) layer network), are
transported by the MPLS-TP server layer network.
o The packet transport service enables the MPLS-TP layer network o The packet transport service enables the MPLS-TP layer network
addressing and other information (e.g. topology) to be hidden from addressing and other information (e.g., topology) to be hidden
any client layer networks using that service, and vice-versa. from 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.
3.2. Scope of the MPLS Transport Profile 3.2. Scope of the MPLS Transport Profile
Figure 1 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 when used in [RFC5654] such as Equal Cost Multi-Path (ECMP), LDP signaling when
such a way that it creates multipoint-to-point LSPs, and IP used in such a way that it creates multipoint-to-point LSPs, and IP
forwarding in the data plane are explicitly excluded from MPLS-TP by forwarding in the data plane are explicitly excluded from MPLS-TP by
that requirements specification. that requirements specification.
Note that MPLS as a whole will continue to evolve to include Note that MPLS as a whole will continue to evolve to include
additional functions that do not conform to the MPLS Transport additional functions that do not conform to the MPLS Transport
Profile or its requirements, and thus fall outside the scope of Profile or its requirements, and thus fall outside the scope of
MPLS-TP. MPLS-TP.
|<============================== MPLS ==============================>| |<============================== MPLS ==============================>|
{ Post-RFC5654 } { Post-RFC5654 }
{ non-Transport } { non-Transport }
{ Functions } { Functions }
|<========== Pre-RFC5654 MPLS ===========>| |<========== Pre-RFC5654 MPLS ===========>|
{ ECMP } { ECMP }
{ LDP/non-TE LSPs } { LDP/non-TE LSPs }
{ IP fwd } { IP forwarding }
|<======== MPLS-TP ============>| |<======== MPLS-TP ============>|
{ Additional } { Additional }
{ Transport } { Transport }
{ Functions } { Functions }
Figure 1: Scope of MPLS-TP Figure 1: Scope of MPLS-TP
MPLS-TP can be used to construct packet networks and is therefore MPLS-TP can be used to construct packet networks and is therefore
applicable in any packet network context. A subset of MPLS-TP is applicable in any packet network context. A subset of MPLS-TP is
also applicable to ITU-T defined packet transport networks, where the also applicable to ITU-T-defined packet transport networks, where the
transport network operational model is deemed attractive. transport network operational model is deemed attractive.
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 [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
a client network. for a client network.
o Proactive and on-demand Operations, Administration and Maintenance o Proactive and on-demand Operations, Administration, and
(OAM) functions to monitor and diagnose the MPLS-TP network, as Maintenance (OAM) functions to monitor and diagnose the MPLS-TP
outlined in [I-D.ietf-mpls-tp-oam-framework]. network, as outlined in [OAM-FRAMEWORK].
o Control planes for LSPs and PWs, as well as support for static o Control planes for LSPs and PWs, as well as support for static
provisioning and configuration, as outlined in provisioning and configuration, as outlined in [CP-FRAMEWORK].
[I-D.ietf-ccamp-mpls-tp-cp-framework].
o Path protection mechanisms to ensure that the packet transport o Path protection mechanisms to ensure that the packet transport
service survives anticipated failures and degradations of the service survives anticipated failures and degradations of the
MPLS-TP network, as outlined in [I-D.ietf-mpls-tp-survive-fwk]. MPLS-TP network, as outlined in [SURVIVE-FWK].
o Control plane based restoration mechanisms, as outlined in o Control-plane-based restoration mechanisms, as outlined in
[I-D.ietf-mpls-tp-survive-fwk]. [SURVIVE-FWK].
o Network management functions, as outlined in o Network management functions, as outlined in [NM-FRAMEWORK].
[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 native service adaptation o MPLS-TP native service adaptation
o MPLS-TP forwarding o MPLS-TP forwarding
The adaptation functions interface the native service (i.e. the The adaptation functions interface the native service (i.e., the
client layer network service) to MPLS-TP. This includes the case client layer network service) to MPLS-TP. This includes the case
where the native service is an MPLS-TP LSP. 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 native service traffic over an MPLS-TP forwarding the encapsulated native service traffic over an MPLS-TP
server layer network, for example PW and LSP labels. server layer network, for example, PW and LSP labels.
3.3.1. MPLS-TP Native Service 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
layer network service to MPLS-TP. For pseudowires, these adaptation layer network service to MPLS-TP. For pseudowires, these adaptation
functions are the payload encapsulation described in Section 4.4 of functions are the payload encapsulation described in Section 4.4 of
[RFC3985] and Section 6 of [RFC5659]. For network layer client [RFC3985] and Section 6 of [RFC5659]. For network layer client
services, the adaptation function uses the MPLS encapsulation format services, the adaptation function uses the MPLS encapsulation format
as defined in [RFC3032]. as defined in [RFC3032].
The purpose of this encapsulation is to abstract the client layer The purpose of this encapsulation is to abstract the data plane of
network data plane from the MPLS-TP data plane, thus contributing to the client layer network from the MPLS-TP data plane, thus
the independent operation of the MPLS-TP network. contributing to 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 therefore needs to provide the necessary QoS layer. The server layer therefore needs to provide the necessary QoS
to ensure that the MPLS-TP client QoS commitments can be satisfied. to 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 native service traffic over an MPLS-TP forwarding the encapsulated native service traffic over an MPLS-TP
server layer 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 Time-to-Live
processing procedures defined in [RFC3031], [RFC3032] and [RFC3443], (TTL) processing procedures defined in [RFC3031], [RFC3032], and
as profiled in [I-D.ietf-mpls-tp-data-plane]. These operations are [RFC3443], as profiled in [DATA-PLANE]. These operations are highly
highly optimised for performance and are not modified by the MPLS-TP optimized for performance and are not modified by the MPLS-TP
profile. profile.
In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW
forwarding operations defined in [RFC3985] and [RFC5659]. forwarding operations defined in [RFC3985] and [RFC5659].
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
for LSPs. used for LSPs.
MPLS-TP forwarding is based on the label that identifies the MPLS-TP forwarding is based on the label that identifies the
transport path (LSP or PW). The label value specifies the processing transport path (LSP or PW). The label value specifies the processing
operation to be performed by the next hop at that level of operation to be performed by the next hop at that level of
encapsulation. A swap of this label is an atomic operation in which encapsulation. A swap of this label is an atomic operation in which
the contents of the packet after the swapped label are opaque to the the contents of the packet after the swapped label are opaque to the
forwarder. The only event that interrupts a swap operation is TTL forwarder. The only event that interrupts a swap operation is TTL
expiry. This is a fundamental architectural construct of MPLS to be expiry. This is a fundamental architectural construct of MPLS to be
taken into account when designing protocol extensions (such as those taken into account when designing protocol extensions (such as those
for OAM) that require 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].
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. E-LSP and L-LSP MPLS Diffserv modes are supported.
Further details of MPLS-TP forwarding can be found in Further details of MPLS-TP forwarding can be found in [DATA-PLANE].
[I-D.ietf-mpls-tp-data-plane].
3.4. MPLS-TP Native Service Adaptation 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 LSP o An MPLS LSP
MPLS-TP uses IETF-defined pseudowires to emulate certain services, MPLS-TP uses IETF-defined pseudowires to emulate certain services,
for example Ethernet, Frame Relay, or PPP/HDLC. A list of PW types for example, Ethernet, Frame Relay, or PPP / High-Level Data Link
is maintained by IANA in the the "MPLS Pseudowire Type" registry. Control (HDLC). A list of PW types is maintained by IANA in the
When the native service adaptation is via a PW, the mechanisms "MPLS Pseudowire Type" registry. When the native service adaptation
described in Section 3.4.4 are used. is via a PW, the mechanisms described in Section 3.4.4 are used.
An MPLS LSP can also provide the adaptation, in which case any native An MPLS LSP can also provide the adaptation, in which case any native
service traffic type supported by [RFC3031] and [RFC3032] is allowed. service traffic type supported by [RFC3031] and [RFC3032] is allowed.
Examples of such traffic types include IP, and MPLS-labeled packets. Examples of such traffic types include IP packets and MPLS-labeled
Note that the latter case includes TE-LSPs [RFC3209] and LSP based packets. Note that the latter case includes TE-LSPs [RFC3209] and
applications such as PWs, Layer 2 VPNs [RFC4664], and Layer 3 VPNs LSP-based applications such as PWs, Layer 2 VPNs [RFC4664], and Layer
[RFC4364]. When the native service adaptation is via an MPLS label, 3 VPNs [RFC4364]. When the native service adaptation is via an MPLS
the mechanisms described in Section 3.4.5 are used. label, the mechanisms described in Section 3.4.5 are used.
3.4.1. MPLS-TP Client/Server Layer Relationship 3.4.1. MPLS-TP Client/Server Layer Relationship
The relationship between the client layer network and the MPLS-TP The relationship between the client layer network and the MPLS-TP
server layer network is defined by the MPLS-TP network boundary and server layer network is defined by the MPLS-TP network boundary and
the label context. It is not explicitly indicated in the packet. In the label context. It is not explicitly indicated in the packet. In
terms of the MPLS label stack, when the native service traffic type terms of the MPLS label stack, when the native service traffic type
is itself MPLS-labeled, then the S bits of all the labels in the is itself MPLS-labeled, then the S bits of all the labels in the
MPLS-TP label stack carrying that client traffic are zero; otherwise MPLS-TP label stack carrying that client traffic are zero; otherwise,
the bottom label of the MPLS-TP label stack has the S-bit set to 1. the bottom label of the MPLS-TP label stack has the S bit set to 1.
In other words, there can be only one S-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 behavior of MPLS-TP is the same as the best current
practice for MPLS. This includes the setting of the S-bit. In each practice 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., innermost) label
in the label stack that is contiguous between the MPLS-TP LSP and its in the label stack that is contiguous between the MPLS-TP LSP and its
payload, and only one LSE contains the S (Bottom of Stack) bit set to payload, and only one label stack entry (LSE) contains the S bit
1. Note that this best current practice differs slightly from (Bottom of Stack bit) set to 1. Note that this best current practice
[RFC3032] which uses the S-bit to identify when MPLS label processing differs slightly from [RFC3032], which uses the S bit to identify
stops and network layer processing starts. when 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 2. Note that the label stacks shown in the figure are divided 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 between those inside the MPLS-TP network and those within the client
network when the client network is MPLS(-TP). They illustrate the network when the client network is MPLS(-TP). They illustrate the
smallest number of labels possible. These label stacks could also smallest number of labels possible. These label stacks could also
include more labels. include more labels.
PW-Based MPLS Labelled IP PW-Based MPLS Labeled 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 |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
skipping to change at page 18, line 21 skipping to change at page 18, line 29
Transport Service Instance traffic over such transport paths. Transport Service Instance traffic over such transport paths.
3.4.3. MPLS-TP Transport Service Interfaces 3.4.3. MPLS-TP Transport Service Interfaces
An MPLS-TP PE node can provide two types of interface to the An MPLS-TP PE node can provide two types of interface to the
Transport Service layer. The MPLS-TP User-Network Interface (UNI) Transport Service layer. The MPLS-TP User-Network Interface (UNI)
provides the interface between a CE and the MPLS-TP network. The provides the interface between a CE and the MPLS-TP network. The
MPLS-TP Network-Network Interface (NNI) provides the interface MPLS-TP Network-Network Interface (NNI) provides the interface
between two MPLS-TP PEs in different administrative domains. between two MPLS-TP PEs in different administrative domains.
When MPLS-TP is used to provide a transport service for e.g. IP 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 services that are a part of a Layer 3 VPN, then packets are
transported in the same manner as specified in [RFC4364]. transported in the same manner as specified in [RFC4364].
3.4.3.1. User-Network Interface 3.4.3.1. User-Network Interface
The MPLS-TP User-Network interface (UNI) is illustrated in Figure 3. 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 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 between the CE and PE, and if signaling is used, it may or may not
traverse the same attachment circuit that supports the client flow. traverse the same attachment circuit that supports the client flow.
skipping to change at page 20, line 34 skipping to change at page 20, line 34
Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages
Figure 4 shows the logical processing steps involved in a PE both for Figure 4 shows the logical processing steps involved in a PE both for
traffic flowing from the CE to the MPLS-TP network (left to right), traffic flowing from the CE to the MPLS-TP network (left to right),
and from the network to the CE (right to left). and from the network to the CE (right to left).
In the first case, when a packet from a client flow is received by 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: the PE from the CE over the data-link, the following steps occur:
1. Link-layer specific preprocessing, if any, is performed. An 1. Link-layer-specific pre-processing, if any, is performed. An
example of such preprocessing is the PREP function illustrated in example of such pre-processing is the PREP function illustrated
Figure 3 of [RFC3985]. Such preprocessing is outside the scope in Figure 3 of [RFC3985]. Such pre-processing is outside the
of MPLS-TP. scope of MPLS-TP.
2. The packet is extracted from the data-link frame if necessary, 2. The packet is extracted from the data-link frame, if necessary,
and associated with a Transport Service Instance. At this point, and associated with a Transport Service Instance. At this point,
UNI processing has completed. UNI processing has completed.
3. A transport service encapsulation is associated with the packet, 3. A transport service encapsulation is associated with the packet,
if necessary, for transport over the MPLS-TP network. if necessary, for transport over the MPLS-TP network.
4. The packet is mapped to a transport path based on its associated 4. The packet is mapped to a transport path based on its associated
Transport Service Instance, the transport path encapsulation is Transport Service Instance, the transport path encapsulation is
added, if necessary, and the packet is transmitted over the added, if necessary, and the packet is transmitted over the
transport path. transport path.
skipping to change at page 21, line 20 skipping to change at page 21, line 23
3. At this point, UNI processing begins. A data-link encapsulation 3. At this point, UNI processing begins. A data-link encapsulation
is associated with the packet for delivery to the CE based on the is associated with the packet for delivery to the CE based on the
client flow. client flow.
4. Link-layer-specific postprocessing, if any, is performed. Such 4. Link-layer-specific postprocessing, if any, is performed. Such
postprocessing is outside the scope of MPLS-TP. postprocessing is outside the scope of MPLS-TP.
3.4.3.2. Network-Network Interface 3.4.3.2. Network-Network Interface
The MPLS-TP NNI is illustrated in Figure 5. The NNI for a particular The MPLS-TP NNI is illustrated in Figure 5. The NNI for a particular
transport service instance may or may not involve signaling between 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 the two PEs; and if signaling is used, it may or may not traverse the
same data-link that supports the service instance. same data-link that supports the service instance.
: Network-Network Interface : : Network-Network Interface :
:<--------------------------------->: :<--------------------------------->:
: : : :
------------:------------- -------------:------------ ------------:------------- -------------:------------
| Transport : | | : Transport | | Transport : | | : Transport |
| Path : Transport | | Transport : Path | | Path : Transport | | Transport : Path |
| Mux/Demux : Service | | Service : Mux/Demux | | Mux/Demux : Service | | Service : Mux/Demux |
| -- : Control | | Control : -- | | -- : Control | | Control : -- |
skipping to change at page 23, line 10 skipping to change at page 23, line 10
TP = Transport Path TP = Transport Path
TSI = Transport Service Instance TSI = Transport Service Instance
Figure 5: MPLS-TP PE Containing an NNI Figure 5: MPLS-TP PE Containing an NNI
: :
--------------From NNI-------> : --------------From NNI-------> :
--------------------------------------------:------------------ --------------------------------------------:------------------
| | Service Traffic Unit : | | | Service Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance | | Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Encapsulation | | Processing | & : Encapsulation |
| | Service Instance : Normalisation | | | Service Instance : Normalization |
| | Identification : | | | Identification : |
--------------------------------------------:------------------ --------------------------------------------:------------------
: :
: :
--------------------------------------------:------------------ --------------------------------------------:------------------
| | : Service Instance | | | : Service Instance |
| | : Identification | | | : Identification |
| Link-Layer-Specific | Service Traffic Unit : & | | Link-Layer-Specific | Service Traffic Unit : & |
| Processing | Link Encapsulation : Service Instance | | Processing | Link Encapsulation : Service Instance |
| | : Encapsulation | | | : Encapsulation |
| | : Normalisation | | | : Normalization |
--------------------------------------------:------------------ --------------------------------------------:------------------
<-------------To NNI --------- : <-------------To NNI --------- :
Figure 6: MPLS-TP NNI Service Traffic Processing Stages Figure 6: MPLS-TP NNI Service Traffic Processing Stages
Figure 6 shows the logical processing steps involved in a PE for Figure 6 shows the logical processing steps involved in a PE for
traffic flowing both from the peer PE (left to right) and to the peer traffic flowing both from the peer PE (left to right) and to the peer
PE (right to left). PE (right to left).
In the first case, when a packet from a transport service instance is 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 received by the PE from the peer PE over the data-link, the following
steps occur: steps occur:
1. Link-layer specific preprocessing, if any, is performed. Such 1. Link-layer specific pre-processing, if any, is performed. Such
preprocessing is outside the scope of MPLS-TP. pre-processing is outside the scope of MPLS-TP.
2. The packet is extracted from the data-link frame if necessary, 2. The packet is extracted from the data-link frame if necessary,
and associated with a Transport Service Instance. At this point, and associated with a Transport Service Instance. At this point,
NNI processing has completed. NNI processing has completed.
3. The transport service encapsulation of the packet is normalised 3. The transport service encapsulation of the packet is normalized
for transport over the MPLS-TP network. This step allows a for transport over the MPLS-TP network. This step allows a
different transport service encapsulation to be used over the NNI different transport service encapsulation to be used over the NNI
than that used in the internal MPLS-TP network. An example of than that used in the internal MPLS-TP network. An example of
such normalisation is a swap of a label identifying the Transport such normalization is a swap of a label identifying the Transport
Service Instance. Service Instance.
4. The packet is mapped to a transport path based on its associated 4. The packet is mapped to a transport path based on its associated
Transport Service Instance, the transport path encapsulation is Transport Service Instance, the transport path encapsulation is
added, if necessary, and the packet is transmitted over the added, if necessary, and the packet is transmitted over the
transport path. transport path.
In the second case, when a packet associated with a Transport Service In the second case, when a packet associated with a Transport Service
Instance arrives over a transport path, the following steps occur: Instance arrives over a transport path, the following steps occur:
1. The transport path encapsulation is disposed of. 1. The transport path encapsulation is disposed of.
2. The Transport Service Instance is identified from the transport 2. The Transport Service Instance is identified from the transport
service encapsulation, and this encapsulation is normalised for service encapsulation, and this encapsulation is normalized for
delivery over the NNI (see Step 3 above). delivery over the NNI (see Step 3 above).
3. At this point, NNI processing begins. A data-link encapsulation 3. At this point, NNI processing begins. A data-link encapsulation
is associated with the packet for delivery to the peer PE based is associated with the packet for delivery to the peer PE based
on the normalised Transport Service Instance. on the normalized Transport Service Instance.
4. Link-layer-specific postprocessing, if any, is performed. Such 4. Link-layer-specific postprocessing, if any, is performed. Such
postprocessing is outside the scope of MPLS-TP. postprocessing is outside the scope of MPLS-TP.
3.4.3.3. Example Interfaces 3.4.3.3. Example Interfaces
This section considers some special cases of UNI processing for This section considers some special cases of UNI processing for
particular transport service types. These are illustrative, and do particular transport service types. These are illustrative, and do
not preclude other transport service types. not preclude other transport service types.
skipping to change at page 24, line 40 skipping to change at page 24, line 44
In this example the MPLS-TP network is providing a point-to-point In this example the MPLS-TP network is providing a point-to-point
Layer 2 transport service between attached CE nodes. This service is Layer 2 transport service between attached CE nodes. This service is
provided by a Transport Service Instance consisting of a PW provided by a Transport Service Instance consisting of a PW
established between the associated PE nodes. The client flows established between the associated PE nodes. The client flows
associated with this Transport Service Instance are the sets of all associated with this Transport Service Instance are the sets of all
Layer 2 frames transmitted and received over the attachment circuits. Layer 2 frames transmitted and received over the attachment circuits.
The processing steps in this case for a frame received from the CE The processing steps in this case for a frame received from the CE
are: are:
1. Link-layer specific preprocessing, if any, is performed, 1. Link-layer specific pre-processing, if any, is performed,
corresponding to the PREP function illustrated in Figure 3 of corresponding to the PREP function illustrated in Figure 3 of
[RFC3985]. [RFC3985].
2. The frame is associated with a Transport Service Instance based 2. The frame is associated with a Transport Service Instance based
on the attachment circuit over which it was received. on the attachment circuit over which it was received.
3. A transport service encapsulation, consisting of the PW control 3. A transport service encapsulation, consisting of the PW control
word and PW label, is associated with the frame. word and PW label, is associated with the frame.
4. The resulting packet is mapped to an LSP, the LSP label is 4. The resulting packet is mapped to an LSP, the LSP label is
pushed, and the packet is transmitted over the outbound interface pushed, and the packet is transmitted over the outbound interface
associated with the LSP. associated with the LSP.
The steps in the reverse direction for PW packets received over the For PW packets received over the LSP, the steps are performed in the
LSP are analogous. reverse order.
3.4.3.3.2. IP Transport Service 3.4.3.3.2. IP Transport Service
In this example the MPLS-TP network is providing a point-to-point IP 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- transport service between CE1, CE2, and CE3, as follows. One point-
to-point transport service instance delivers IPv4 packets between CE1 to-point Transport Service Instance delivers IPv4 packets between CE1
and CE2, and another instance delivers IPv6 packets between CE1 and and CE2, and another instance delivers IPv6 packets between CE1 and
CE3. CE3.
The processing steps in this case for an IP packet received from CE1 The processing steps in this case for an IP packet received from CE1
are: are:
1. No link-layer-specific processing is performed. 1. No link-layer-specific processing is performed.
2. The IP packet is extracted from the link-layer frame and 2. The IP packet is extracted from the link-layer frame and
associated with a Service LSP based on the source MAC address associated with a Service LSP based on the source MAC address
(CE1) and the IP protocol version. (CE1) and the IP protocol version.
3. A transport service encapsulation, consisting of the Service LSP 3. A transport service encapsulation, consisting of the Service LSP
label, is associated with the packet. label, is associated with the packet.
4. The resulting packet is mapped to a tunnel LSP, the tunnel LSP 4. The resulting packet is mapped to a tunnel LSP, the tunnel LSP
label is pushed, and the packet is transmitted over the outbound label is pushed, and the packet is transmitted over the outbound
interface associated with the LSP. interface associated with the LSP.
The steps in the reverse direction, for packets received over a For packets received over a tunnel LSP carrying the Service LSP
tunnel LSP carrying the Service LSP label, are analogous. label, the steps are performed in the reverse order.
3.4.4. Pseudowire Adaptation 3.4.4. Pseudowire Adaptation
MPLS-TP uses pseudowires to provide a Virtual Private Wire Service MPLS-TP uses pseudowires to provide a Virtual Private Wire Service
(VPWS), a Virtual Private Local Area Network Service (VPLS), a (VPWS), a Virtual Private Local Area Network Service (VPLS), a
Virtual Private Multicast Service (VPMS) and an Internet Protocol Virtual Private Multicast Service (VPMS), and an Internet Protocol
Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are
described in [RFC4664]. VPMS is described in described in [RFC4664]. VPMS is described in [VPMS-REQS].
[I-D.ietf-l2vpn-vpms-frmwk-requirements].
If the MPLS-TP network provides a layer 2 interface, that can carry If the MPLS-TP network provides a layer 2 interface (that can carry
both network layer and non-network layer traffic, as a service both network-layer and non-network-layer traffic) as a service
interface, then a PW is required to support the service interface. 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 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 for an MPLS-TP network that provides such services is based on the
MPLS [RFC3031] and pseudowire [RFC3985] architectures. Multi-segment MPLS [RFC3031] and pseudowire [RFC3985] architectures. Multi-segment
pseudowires may optionally be used to provide a packet transport pseudowires may optionally be used to provide a packet transport
service, and their use is consistent with the MPLS-TP architecture. service, and their use is consistent with the MPLS-TP architecture.
The use of MS-PWs may be motivated by, for example, the requirements 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 specified in [RFC5254]. If MS-PWs are used, then the MS-PW
architecture [RFC5659] also applies. architecture [RFC5659] also applies.
skipping to change at page 27, line 26 skipping to change at page 27, line 26
|CE1| | | | | X | | | | | | |CE2| |CE1| | | | | X | | | | | | |CE2|
| |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| | | |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+ +---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ | | +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ | | | | ^ | |
| TE LSP | TE LSP | | TE LSP | TE LSP |
| P-router | | P-router |
Native Service Native 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 8: MPLS-TP Architecture (Multi-Segment PW) Figure 8: 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 9. In this figure the Transport Service Layer [RFC5654] is Figure 9. 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 Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans 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 considered Note: H(ighlighted) indicates the part of the protocol stack considered
in this document. in this document.
Figure 9: MPLS-TP label stack using pseudowires Figure 9: 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.5. Network Layer Adaptation 3.4.5. 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. Support for network layer clients follows the MPLS interfaces. Support for network-layer clients follows the MPLS
architecture for support of network layer protocols as specified in architecture for support of network-layer protocols as specified in
[RFC3031] and [RFC3032]. [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 unidirectional or bidirectional point-to-point connection between two
two PEs in order to deliver a packet transport service to attached 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 10, there is an attachment circuit MPLS-TP node. As shown in Figure 10, 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 Layer 1 / Layer 2
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.
The following figures illustrate the reference models for network The following figures illustrate the reference models for network-
layer adaptation. The details of these figures are described further layer adaptation. The details of these figures are described further
in the following paragraphs. in the following paragraphs.
|<------------- Client Network Layer --------------->| |<------------- Client Network Layer --------------->|
| | | |
| |<----------- Packet --------->| | | |<----------- Packet --------->| |
| | Transport Service | | | | Transport Service | |
| | | | | | | |
| | | | | | | |
| | Transport | | | | Transport | |
skipping to change at page 29, line 38 skipping to change at page 29, line 37
+-----+ ^ | | |=======/ \========| | | ^ +-----+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | | ^ ^ | +----+ ^ +-----+ +----+ | | ^
| | Provider | ^ Provider | | | | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | | | | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2 Edge 1 | TE LSP | Edge 2
| | | |
| | | |
Native service Native service Native service Native service
Figure 10: MPLS-TP Architecture for Network Layer Clients Figure 10: MPLS-TP Architecture for Network-Layer Clients
|<--------------------- Client Layer ------------------------>| |<--------------------- Client Layer ------------------------>|
| | | |
| | | |
| |<---------- Packet Transport Service ------------->| | | |<---------- Packet Transport Service ------------->| |
| | | | | | | |
| | Transport Transport | | | | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC | | AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | | | | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V V | +----+ +-----+ +----+ +----+ | V
skipping to change at page 30, line 29 skipping to change at page 30, line 29
| +----+ ^ +-----+ +----+ ^ +----+ | | +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ ^ | | | | ^ ^ | |
| TE LSP | | TE LSP | | TE LSP | | TE LSP |
| P-router | | | P-router | |
Native Service (LSR for | Native Service Native Service (LSR for | Native Service
T'port LSP1) | T'port LSP1) |
| |
LSR for Service LSPs LSR for Service LSPs
LER for Transport LSPs LER for Transport LSPs
Figure 11: MPLS-TP Architecture for Network Layer Adaptation, showing Figure 11: MPLS-TP Architecture for Network Layer Adaptation, Showing
Service LSP Switching Service LSP Switching
Client packets are received at the ingress service interface. The PE Client packets are received at the ingress service interface. The PE
pushes one or more labels onto the client packets which are then pushes one or more labels onto the client packets that are then label
label switched over the transport network. Correspondingly the switched over the transport network. Correspondingly, the egress PE
egress PE pops any labels added by the MPLS-TP networks and transmits pops any labels added by the MPLS-TP networks and transmits the
the packet for delivery to the attached CE via the egress service 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
skipping to change at page 31, line 26 skipping to change at page 31, line 26
| 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 considered Note: H(ighlighted) indicates the part of the protocol stack considered
in this document. in this document.
Figure 12: MPLS-TP Label Stack for IP and LSP Clients Figure 12: MPLS-TP Label Stack for IP and LSP Clients
In the figures above, the Transport Service Layer [RFC5654] is In the figures above, the Transport Service layer [RFC5654] is
identified by the Service LSP (SvcLSP) demultiplexer (Demux) label identified by the Service LSP (SvcLSP) demultiplexer (Demux) label,
and the Transport Path Layer [RFC5654] is identified by the Transport and the Transport Path layer [RFC5654] is identified by the Transport
(Trans) LSP Demux Label. Note that the functions of the (Trans) LSP Demux Label. Note that the functions of the
Encapsulation label (Encap Label) and the Service Label (SvcLSP Encapsulation Label (Encap Label) and the Service Label (SvcLSP
Demux) shown above may alternatively be represented by a single label Demux) shown above may alternatively be represented by a single label
stack entry. Note that the S-bit is always zero when the client stack entry. Note that the S bit is always zero when the client
layer is MPLS-labelled. It may be necessary to swap a service LSP layer is MPLS-labeled. It may be necessary to swap a service LSP
label at an intermediate node. This is shown in Figure 11. label at an intermediate node. This is shown in Figure 11.
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 12 shows how a client is not visible outside that network. Figure 12 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 may be used to identify the network layer protocol payload A label may be used to identify the network-layer protocol payload
type. Therefore, when multiple protocol payload types are to be type. Therefore, when multiple protocol payload types are to be
carried over a single service LSP, a unique label stack entry needs carried over a single service LSP, a unique label stack entry needs
to be present for each payload type. Such labels are referred to as to be present for each payload type. Such labels are referred to as
"Encapsulation Labels", one of which is shown in Figure 12. "Encapsulation Labels", one of which is shown in Figure 12. An
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, then two example, if both IP and MPLS are to be carried, then two
Encapsulation Labels are mapped on to a common Service Label. Encapsulation Labels are mapped on to a common Service Label.
Note: The Encapsulation Label may be omitted when the service LSP is Note: The Encapsulation Label may be omitted when the service LSP is
supporting only one network layer protocol payload type. For supporting only one network-layer protocol payload type. 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. The Encapsulation Label
cannot have any of the reserved label values [RFC3032].
Service labels are typically carried over an MPLS-TP Transport LSP Service labels are typically carried over an MPLS-TP Transport LSP
edge-to-edge (or transport path layer). An MPLS-TP Transport LSP is edge-to-edge (or transport path layer). An MPLS-TP Transport LSP is
represented as an LSP Transport Demux label, as shown in Figure 12. represented as an LSP Transport Demux label, as shown in Figure 12.
Transport LSP is commonly used when more than one service exists Transport LSP is commonly used when more than one service exists
between two PEs. between two PEs.
Note that, if only one service exists between two PEs, the functions Note that, if only one service exists between two PEs, the functions
of the Transport LSP label and the Service LSP Label may be combined of the Transport LSP label and the Service LSP Label may be combined
into a single label stack entry. For example, if only one service is into a single label stack entry. For example, if only one service is
carried between two PEs then a single label could be used to provide carried between two PEs, then a single label could be used to provide
both the service indication and the MPLS-TP transport LSP. 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
transport 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 needs to be used to At each service interface, Layer 2 addressing needs to be used to
ensure the proper delivery of a network layer packet to the adjacent ensure the proper delivery of a network-layer packet to the adjacent
node. This is typically only an issue for LAN media technologies node. This is typically only an issue for LAN media technologies
(e.g., Ethernet) which have Media Access Control (MAC) addresses. In (e.g., Ethernet) that have Media Access Control (MAC) addresses. In
cases where a MAC address is needed, the sending node sets the cases where a MAC address is needed, the sending node sets 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
address that ensures delivery to the PE, and the PE sets the an 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. will need to be configured.
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 . or signaled.
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. MPLS-TP defined two type of their associated maintenance entities. MPLS-TP defined two types of
sets of identifiers: Those that are compatible with IP, and another sets of identifiers: those that are compatible with IP, and those
set that is compatible with ITU-T transport-based operations. The that are compatible with ITU-T transport-based operations. The
definition of these sets of identifiers is outside the scope of this definition of these sets of identifiers is outside the scope of this
document and is provided by [I-D.ietf-mpls-tp-identifiers]. document and is provided by [IDENTIFIERS].
3.6. Generic Associated Channel (G-ACh) 3.6. Generic Associated Channel (G-ACh)
For correct operation of OAM mechanisms it is important that OAM For correct operation of OAM mechanisms, it is important that OAM
packets fate-share with the data packets. In addition in MPLS-TP it packets fate-share with the data packets. In addition, in MPLS-TP it
is necessary to discriminate between user data payloads and other is necessary to discriminate between user data payloads and other
types of payload. For example, a packet may be associated with a types of payload. For example, a packet may be associated with a
Signaling Communication Channel (SCC), or a channel used for a Signaling Communication Channel (SCC) or a channel used for a
protocol to coordinate path protection state. This is achieved by protocol to coordinate path protection state. This is achieved by
carrying such packets in either: carrying such packets in either:
o A generic control channel associated to the LSP, PW or section, o A generic control channel associated to the LSP, PW, or section,
with no IP encapsulation. e.g. in a similar manner to with no IP encapsulation, e.g., in a similar manner to
Bidirectional Forwarding Detection for Virtual Circuit Bidirectional Forwarding Detection for Virtual Circuit
Connectivity Verification (VCCV-BFD) with PW ACH encapsulation Connectivity Verification (VCCV-BFD) with PW ACH encapsulation
[I-D.ietf-pwe3-vccv-bfd]). [RFC5885]).
o An IP encapsulation where IP capabilities are present. e.g. PW o An IP encapsulation where IP capabilities are present, e.g., PW
ACH encapsulation with IP headers for VCCV-BFD ACH encapsulation with IP headers for VCCV-BFD [RFC5885] or IP
[I-D.ietf-pwe3-vccv-bfd], or IP encapsulation for MPLS BFD encapsulation for MPLS BFD [RFC5884].
[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, a protocol used (FCAPS) functions by carrying packets related to OAM, a protocol used
to coodinate path protection state, SCC, MCC or other packet types to coordinate path protection state, SCC, MCC or other packet types
in-band over LSPs, PWs or sections. The G-ACh is defined in in-band over LSPs, PWs, or sections. The G-ACh is defined in
[RFC5586] and is similar to the Pseudowire Associated Channel [RFC5586] and is similar to the Pseudowire Associated Channel
[RFC4385], which is used to carry OAM packets over pseudowires. The [RFC4385], which is used to carry OAM packets over pseudowires. The
G-ACh is indicated by an Associated Channel Header (ACH), similar to G-ACh is indicated by an Associated Channel Header (ACH), similar to
the Pseudowire VCCV control word; this header is present for all the Pseudowire VCCV control word; this header is present for all
sections, LSPs and PWs making use of FCAPS functions supported by the sections, LSPs, and PWs that make use of FCAPS functions supported by
G-ACh. the G-ACh.
As specified in [RFC5586], the G-ACh must only be used for channels As specified in [RFC5586], the G-ACh must only be used for channels
that are an adjunct to the data service. Examples of these are OAM, that are an adjunct to the data service. Examples of these are OAM,
a protocol used to coodinate path protection state, MCC and SCC, but a protocol used to coordinate path protection state, MCC, and SCC,
the use is not restricted to these services. The G-ACh must not to but the use is not restricted to these services. The G-ACh must not
be used to carry additional data for use in the forwarding path, i.e. be used to carry additional data for use in the forwarding path,
it must not be used as an alternative to a PW control word, or to i.e., it must not be used as an alternative to a PW control word, or
define a PW type. to define a PW 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 need to take into consideration the impact they have on the G-ACh need to take into consideration the impact they have on the
user data with which they are sharing resources. Conversely, user data with which they are sharing resources. Conversely,
capacity needs to be made available for important G-ACh uses such as capacity needs to be made available for important G-ACh uses such as
protection and OAM. In addition, the security and congestion protection and OAM. In addition, the security and congestion
considerations described in [RFC5586] apply to protocols using the considerations described in [RFC5586] apply to protocols using the
G-ACh. G-ACh.
Figure 13 shows the reference model depicting how the control channel Figure 13 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
skipping to change at page 35, line 5 skipping to change at page 35, line 27
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS-TP Network |---+ +--------| MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 13: PWE3 Protocol Stack Reference Model showing the G-ACh Figure 13: 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 14 shows the reference model depicting how the control channel Figure 14 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 |
+-------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 35, line 36 skipping to change at page 36, line 26
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS-TP Network |---+ +--------| MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 14: MPLS Protocol Stack Reference Model showing the LSP Figure 14: 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)
The MPLS-TP OAM architecture supports a wide range of OAM functions The MPLS-TP OAM architecture supports a wide range of OAM functions
to check continuity, to verify connectivity, to monitor path to check continuity, to verify connectivity, to monitor path
performance, and to generate, filter and manage local and remote performance, and to generate, filter, and manage local and remote
defect alarms. These functions are applicable to any layer defined defect alarms. These functions are applicable to any layer defined
within MPLS-TP, i.e. to MPLS-TP sections, LSPs and PWs. within MPLS-TP, i.e., to MPLS-TP sections, LSPs, and PWs.
The MPLS-TP OAM tool-set is able to operate without relying on a The MPLS-TP OAM tool-set is able to operate without relying on a
dynamic control plane or IP functionality in the datapath. In the dynamic control plane or IP functionality in the data path. In the
case of an MPLS-TP deployment in a network in which IP functionality 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 is available, all existing IP/MPLS OAM functions (e.g., LSP Ping,
and VCCV, may be used. Since MPLS-TP can operate in environments BFD, and VCCV) may be used. Since MPLS-TP can operate in
where IP is not used in the forwarding plane, the default mechanism environments where IP is not used in the forwarding plane, the
for OAM demultiplexing in MPLS-TP LSPs and PWs is the Generic default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is
Associated Channel (Section 3.6). Forwarding based on IP addresses the Generic Associated Channel (Section 3.6). Forwarding based on IP
for user or OAM packets is not required for MPLS-TP. addresses for OAM or user data 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 [RFC5884] have defined alert
alert mechanisms that enable an MPLS LSR to identify and process MPLS mechanisms that enable an MPLS LSR to identify and process MPLS OAM
OAM packets when the OAM packets are encapsulated in an IP header. packets when the OAM packets are encapsulated in an IP header. These
These alert mechanisms are based on TTL expiration and/or use an IP 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, although the mechanisms defined in [RFC5586] can MPLS OAM packets, although the mechanisms defined in [RFC5586] can
also be used. MPLS-TP is able to operate in environments where IP also be used. MPLS-TP is able to operate in environments where IP
forwarding is not supported, and thus the G-ACh/GAL is the default forwarding is not supported, and thus the G-ACh/GAL is the default
mechanism to demultiplex OAM packets in MPLS-TP in these mechanism to demultiplex OAM packets in MPLS-TP in these
environments. 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 requires [I-D.ietf-mpls-tp-oam-requirements] that a set of MPLS-TP requires [RFC5860] that a set of OAM capabilities is
OAM capabilities is available to perform fault management (e.g. fault available to perform fault management (e.g., fault detection and
detection and localisation) and performance monitoring (e.g. packet localization) and performance monitoring (e.g., packet delay and loss
delay and loss measurement) of the LSP, PW or section. The framework measurement) of the LSP, PW, or section. The framework for OAM in
for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. MPLS-TP is specified in [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 [OAM-FRAMEWORK]. A Maintenance Entity (ME)
Maintenance Entity (ME) can be viewed as the association of two can be viewed as the association of two Maintenance Entity Group End
Maintenance Entity Group End Points (MEPs). A Maintenance Entity Points (MEPs). A Maintenance Entity Group (MEG) is a collection of
Group (MEG) is a collection of one or more MEs that belongs to the one or more MEs that belongs to the same transport path and that are
same transport path and that are maintained and monitored as a group. maintained and monitored as a group. The MEPs that form an ME limit
The MEPs that form an ME limit the OAM responsibilities of an OAM the OAM responsibilities of an OAM flow to within the domain of a
flow to within the domain of a transport path or segment, in the transport path or segment, in the specific layer network that is
specific layer network that is being monitored and managed. being monitored and managed.
A MEG may also include a set of Maintenance Entity Group Intermediate A MEG may also include a set of Maintenance Entity Group Intermediate
Points (MIPs). MEPs are capable of sourcing and sinking OAM flows, Points (MIPs).
while MIPs can both react to OAM flows received from within a MEG and
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 stack an LSP or MS-PW by setting the appropriate TTL in the label stack
entry for the G-ACh packet, as per the traceroute mode of LSP Ping entry for the G-ACh packet, as per the traceroute mode of LSP Ping
[RFC4379] and the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw]. [RFC4379] and the vccv-trace mode of [SEGMENTED-PW]. Note that this
Note that this works when the location of MIPs along the LSP or PW works when the location of MIPs along the LSP or PW path is known by
path is known by the MEP. There may be circumstances where this is the MEP. There may be circumstances where this is not the case,
not the case, e.g. following restoration using a facility bypass LSP. e.g., following restoration using a facility bypass LSP. In these
In these cases, tools to trace the path of the LSP may be used to cases, tools to trace the path of the LSP may be used to determine
determine the appropriate setting for the TTL to reach a specific the appropriate setting for the TTL to reach a specific MIP.
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 MPLS architecture layer processing is performed on a packet. The MPLS architecture
mandates that MPLS layer processing occurs at least once on an LSR. mandates that MPLS layer processing occurs at least once on an LSR.
Any node on an LSP can send an OAM packet on that LSP. Likewise, any Any node on an LSP can send an OAM packet on that LSP. Likewise, any
node on a PW can send OAM packets on a PW, including S-PEs. node on a PW can send OAM packets on a PW, including S-PEs.
An OAM packet can only be received to be processed at an LSP An OAM packet can only be received to be processed at an LSP
endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the
LSP or PW label stack entry. LSP or PW label stack entry.
3.8. 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. Although this section describes the options in MPLS-TP networks. Although this section describes the
case of an MPLS-TP LSP, it is also applicable to a PW. case of an MPLS-TP LSP, it is also applicable to a PW.
In this description, U and D are LSRs that terminate MPLS-TP LSPs In this description, U and D are LSRs that terminate MPLS-TP LSPs
(i.e. LERs) and Y is an intermediate LSR along the LSP. Note that U (i.e., LERs), and Y is an intermediate LSR along the LSP. Note that
is the upstream LER and D is the downstream LER with respect to a U is the upstream LER, and D is the downstream LER with respect to a
particular direction of an LSP. This reference model is shown in particular direction of an LSP. This reference model is shown in
Figure 15. Figure 15.
LSP LSP LSP LSP
U ========= Y ========= D U ========= Y ========= D
LER LSR LER LER LSR LER
---------> Direction of user plane traffic flow ---------> Direction of user traffic flow
Figure 15: Return Path reference Model Figure 15: Return Path Reference Model
The following cases are described for the various types of LSPs: The following cases are described for the various types of LSPs:
Case 1 Return path packet transmission from D to U Case 1 Return path packet transmission from D to U
Case 2 Return path packet transmission from Y to U Case 2 Return path packet transmission from Y to U
Case 3 Return path packet transmission from D to Y Case 3 Return path packet transmission from D to Y
Note that a return path may not always exist (or may exist but be Note that a return path may not always exist (or may exist but be
disabled), and that packet transmission in one or more of the above disabled), and that packet transmission in one or more of the above
cases may not be possible. In general the existence and nature of cases may not be possible. In general, the existence and nature of
return paths for MPLS-TP LSPs is determined by operational return paths for MPLS-TP LSPs is determined by operational
provisioning. 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. The LSP between U and D is bidirectional, and therefore D has a a. The LSP between U and D is bidirectional, and therefore D has a
path via the MPLS-TP LSP to return traffic back to U, 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 If an in-band return path is required to deliver traffic from Case 1 If an in-band return path is required to deliver traffic from
D back to U, it is recommended for reasons of operational D back to U, it is recommended for reasons of operational
simplicity that point-to-point unidirectional LSPs be simplicity that point-to-point unidirectional LSPs be
provisioned as associated bidirectional LSPs (which may also provisioned as associated bidirectional LSPs (which may also
be co-routed) whenever return traffic from D to U is be co-routed) whenever return traffic from D to U is
required. Note that the two directions of such an LSP may required. Note that the two directions of such an LSP may
have differing bandwidth allocations and QoS characteristics. have differing bandwidth allocations and QoS characteristics.
The discussion for such LSPs below applies. The discussion below for such LSPs applies.
As an alternative, an out-of-band return path may be used. As an alternative, an out-of-band return path may be used.
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 D is known to have a return path to worthy of note here: if D is known to have a return path to
U, then Y can arrange to deliver return traffic to U by first U, then Y can arrange to deliver return traffic to U by first
sending it to D along the original LSP. The mechanism by sending it to D along the original LSP. The mechanism by
which D recognises the need for and performs this forwarding which D recognizes 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 D has a return path to U, then in a available. However, if D has a return path to U, then (in a
manner analogous to the previous case D can arrange to manner analogous to the previous case) D can arrange to
deliver return traffic to Y by first sending it to U along deliver return traffic to Y by first sending it to U along
that return path. The mechanism by which U recognises the that return path. The mechanism by which U recognizes 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, D has a natural in-band return path to U, 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.
skipping to change at page 40, line 10 skipping to change at page 40, line 31
the form of the LSP itself, and its use is preferred for return the form of the LSP itself, and its use is preferred for return
traffic. Out-of-band return paths, however, are also applicable, traffic. Out-of-band return paths, however, are also applicable,
primarily as an alternative means of delivery in case the in-band primarily as an alternative means of delivery in case the 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
configured and provisioned MPLS-TP services. configured and provisioned MPLS-TP services.
Figure 16 illustrates the relationship between the MPLS-TP control Figure 16 illustrates the relationship between the MPLS-TP control
plane, the forwarding plane, the management plane, and OAM for point- plane, the forwarding plane, the management plane, and OAM for point-
to-point MPLS-TP LSPs or PWs. to-point MPLS-TP LSPs or PWs.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
skipping to change at page 40, line 40 skipping to change at page 41, line 25
: |OAM| | : : |OAM| | : : |OAM| | : : |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | : : | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/ \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+-- --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
/: +----+ |ing | : : |ing | : : |ing | +----+ :\ /: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ : : +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' ''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: Note:
1) NMS may be centralised or distributed. Control plane is 1) NMS may be centralized 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., native service processing 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 16: MPLS-TP Control Plane Architecture Context Figure 16: 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, and is consistent with the Automatically Switched plane protocols, and is consistent with the Automatically Switched
Optical Networks (ASON) architecture [G.8080]. MPLS-TP uses Optical Network (ASON) architecture [G.8080]. MPLS-TP uses:
Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473])
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 control plane traffic be capable of being o Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471],
[RFC3473]) for LSPs, and
o Targeted LDP (T-LDP) signaling ([RFC4447], [SEGMENTED-PW],
[DYN-MS-PW]) for pseudowires.
MPLS-TP requires that any control-plane traffic be capable of being
carried over an out-of-band signaling network or a signaling control carried over an out-of-band signaling network or a signaling control
channel such as the one described in [RFC5718]. Note that while channel such as the one described in [RFC5718]. Note that while
T-LDP signaling is traditionally carried in-band in IP/MPLS networks, T-LDP signaling is traditionally carried in-band in IP/MPLS networks,
this does not preclude its operation over out-of-band channels. this does not preclude its operation over out-of-band channels.
References to T-LDP in this document do not preclude the definition References to T-LDP in this document do not preclude the definition
of alternative 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, need to satisfy the MPLS-TP control control planes, collectively, need to satisfy the MPLS-TP control
plane requirements reviewed in the MPLS-TP Control Plane Framework plane requirements reviewed in the MPLS-TP Control Plane Framework
[I-D.ietf-ccamp-mpls-tp-cp-framework]. When client services are [CP-FRAMEWORK]. When client services are provided directly via LSPs,
provided directly via LSPs, all requirements must be satisfied by the all requirements must be satisfied by the LSP control plane. When
LSP control plane. When client services are provided via PWs, the PW client services are provided via PWs, the PW and LSP control planes
and LSP control planes operate in combination and some functions may operate in combination, and some functions may be satisfied via the
be satisfied via the PW control plane while others are provided to PW control plane, while others are provided to PWs by the LSP control
PWs by the LSP control plane. 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
label stack to be allocated and signaled by its own control protocol. the label stack to be allocated and signaled by its own control
protocol.
The distributed MPLS-TP control plane may provide the following The distributed MPLS-TP control plane may provide the following
functions: functions:
o Signaling o Signaling
o Routing o Routing
o Traffic engineering and constraint-based path computation o Traffic engineering and constraint-based path computation
In a multi-domain environment, the MPLS-TP control plane supports In a multi-domain environment, the MPLS-TP control plane supports
different types of interfaces at domain boundaries or within the different types of interfaces at domain boundaries or within the
domains. These include the User-Network Interface (UNI), Internal domains. These include the User-Network Interface (UNI), Internal
Network-Network Interface (I-NNI), and External Network-Network Network-Network Interface (I-NNI), and External Network-Network
Interface (E-NNI). Note that different policies may be defined that Interface (E-NNI). Note that different policies may be defined that
control 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 localization 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
utilising the fast reroute backup methods as defined in [RFC4090] and Examples of the MPLS-TP data-plane connectivity patterns are LSPs
utilizing 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. In all cases, however, the control plane is plane may be achieved. In all cases, however, the control plane is
logically decoupled from the data plane such that a control plane logically decoupled from the data plane such that a control-plane
failure does not imply a failure of the existing transport paths. failure does not imply a failure of the existing transport paths.
3.10. Interdomain Connectivity 3.10. Inter-Domain 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, including the data plane, OAM and configuration aspects, for MPLS-TP, including the data-plane, OAM, and configuration aspects,
example: for example:
o Inter-domain TE LSPs [RFC4726] o Inter-domain TE LSPs [RFC4726]
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
mechanism is the degree of layer network isolation and types of OAM mechanism is the degree of layer network isolation and types of OAM
required by the operator. The selection of which technique to use in required by the operator. The selection of which technique to use in
a particular deployment scenario is outside the scope of this a particular deployment scenario is outside the scope of this
document. document.
3.11. Static Operation of LSPs and PWs 3.11. Static Operation of LSPs and PWs
A PW or LSP may be statically configured without the support of a A PW or LSP may be statically configured without the support of a
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
is independent for a specific PW or LSP instance. Thus it should be 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. Note that the path of an LSP or PW may be loops are not created. Note that the path of an LSP or PW may be
dynamically computed, while the LSP or PW itself is established dynamically computed, while the LSP or PW itself is established
through static configuration. through static configuration.
3.12. Survivability 3.12. Survivability
The survivability architecture for MPLS-TP is specified in The survivability architecture for MPLS-TP is specified in
[I-D.ietf-mpls-tp-survive-fwk]. [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 [PW-REDUNDANCY] supports scenarios where the protection
protection for the PW cannot be fully provided by the underlying LSP for the PW cannot be fully provided by the underlying LSP (i.e.,
(i.e. where the backup PW terminates on a different target PE node where the backup PW terminates on a different target PE node than the
than the working PW in dual homing scenarios, or where protection of working PW in dual-homing scenarios, or where protection of the S-PE
the S-PE is required). Additionally, GMPLS provides a well known set is required). Additionally, GMPLS provides a well-known set of
of control plane driven protection and restoration mechanisms control-plane-driven protection and restoration mechanisms [RFC4872].
[RFC4872]. MPLS-TP provides additional protection mechanisms that MPLS-TP provides additional protection mechanisms that are optimized
are optimised for both linear topologies and ring topologies, and for both linear topologies and ring topologies and that operate in
that operate in the absence of a dynamic control plane. These are the absence of a dynamic control plane. These are specified in
specified in [I-D.ietf-mpls-tp-survive-fwk]. [SURVIVE-FWK].
Different protection schemes apply to different deployment topologies Different protection schemes apply to different deployment topologies
and operational considerations. Such protection schemes may provide and operational considerations. Such protection schemes may provide
different levels of resiliency, for example: 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 of 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 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 Optimized for linear, ring, or meshed topologies.
o Use OAM mechanisms to detect and localise network faults or o Use OAM mechanisms to detect and localize 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. switching actions in the absence of a dynamic control plane.
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. section, LSP and PW), providing segment and MPLS-TP domain (i.e., section, LSP, and PW) providing segment 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 behavior.
3.13. Sub-Path Maintenance 3.13. Sub-Path Maintenance
In order to monitor, protect and manage a portion (i.e. segment or In order to monitor, protect, and manage a portion (i.e., segment or
concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
instantiated. A hierarchical LSP is instantiated for this purpose is instantiated. A hierarchical LSP instantiated for this purpose is
called a Sub-Path Maintenance Element (SPME). Note that by called a Sub-Path Maintenance Element (SPME). Note that by
definition an SPME does not carry user plane traffic as a direct definition an SPME does not carry user traffic as a direct client.
clident.
An SPME is defined between the edges of the portion of the LSP that An SPME is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. The SPME forms an needs to be monitored, protected or managed. The SPME forms an
MPLS-TP Section [I-D.ietf-mpls-tp-data-plane] that carries the MPLS-TP Section [DATA-PLANE] that carries the original LSP over this
original LSP over this portion of a network as a client. OAM portion of the network as a client. OAM messages can be initiated at
messages can be initiated at the edge of the SPME and sent to the the edge of the SPME and sent to the peer edge of the SPME or to a
peer edge of the SPME or to a MIP along the SPME by setting the TTL MIP along the SPME by setting the TTL value of the LSE at the
value of the LSE at the corresponding hierarchical LSP level. A P corresponding hierarchical LSP level. A P router only pushes or pops
router only pushes or pops a label if it is at the end of a SPME. In a label if it is at the end of a SPME. In this mode, it is an LER
this mode, it is an LER for the SPME. for the SPME.
For example in Figure 17, two SPMEs are configured to allow For example, in Figure 17, two SPMEs are configured to allow
monitoring, protection and management of the LSP concatenated monitoring, protection, and management of the LSP concatenated
segments. One SPME is defined between LER2 and LER3, and a second segments. One SPME is defined between LER2 and LER3, and a second
SPME is set up between LER4 and LER5. Each of these SPMEs may be SPME is set up between LER4 and LER5. Each of these SPMEs may be
monitored, protected, or managed independently. monitored, protected, or managed independently.
|<============================= LSP =============================>| |<============================= LSP =============================>|
|<---- Carrier 1 ---->| |<---- Carrier 2 ---->| |<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
|LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6| |LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6|
|====== SPME =========| |====== SPME =========| |====== SPME =========| |====== SPME =========|
(Carrier 1) (Carrier 2) (Carrier 1) (Carrier 2)
Note 1: LER2, LER3, LER4 and LER5 are with respect to the SPME Note 1: LER2, LER3, LER4, and LER5 are with respect to the SPME,
but LSRs with respect to the LSP.
Note 2: The LSP terminates in LERs outside of Carrier 1 and Note 2: The LSP terminates in LERs outside of Carrier 1 and
Carrier 2, for example LER1 and LER6. Carrier 2, for example, LER1 and LER6.
Figure 17: SPMEs in Inter-Carrier Network Figure 17: SPMEs 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 hierarchical LSP by means of label messages) is tunneled within the hierarchical LSP by means of label
stacking as defined in [RFC3031]. stacking as defined in [RFC3031].
The mapping between an LSP and a SPME can be 1:1, in which case it is The mapping between an LSP and a SPME 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 18 shows a SPME which is used to aggregate a set of Figure 18 shows a SPME that is used to aggregate a set of
concatenated LSP segments for the LSP from LERx to LERt and the LSP concatenated LSP segments for the LSP from LERx to LERt and the LSP
from LERa to LERd. Note that such a construct is useful, for from LERa to LERd. Note that such a construct is useful, for
example, when the LSPs traverse a common portion of the network and example, when the LSPs traverse a common portion of the network and
they have the same Traffic Class. they have the same Traffic Class.
The QoS aspects of a SPME are network specific. The QoS aspects of a SPME are network specific. [OAM-FRAMEWORK]
[I-D.ietf-mpls-tp-oam-framework] provides further considerations on provides further considerations on the QoS aspects of OAM.
the QoS aspects of OAM.
|LERx|--|LSRy|-+ +-|LSRz|--|LERt| |LERx|--|LSRy|-+ +-|LSRz|--|LERt|
| | | |
| |<---------- Carrier 1 --------->| | | |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ | | +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+ +--| |---| |---| |----| |--+
|LER1 | |LSR| |LSR| |LER2 | |LER1 | |LSR| |LSR| |LER2 |
+--| |---| |---| |----| |--+ +--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ | | +-----+ +---+ + P + +-----+ |
| |============ SPME ==============| | | |============ SPME ==============| |
|LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd| |LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
Figure 18: SPME for a Set of Concatenated LSP Segments Figure 18: SPME for a Set of Concatenated LSP Segments
SPMEs can be provisioned either statically or using control plane SPMEs 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 SPME on existing LSPs in- supported by MPLS allow the creation of a SPME on existing LSPs in-
service without traffic disruption, as described in service without traffic disruption, as described in [SURVIVE-FWK]. A
[I-D.ietf-mpls-tp-survive-fwk]. A SPME can be defined corresponding SPME can be defined corresponding to one or more end-to-end LSPs.
to one or more end-to-end LSPs. New end-to-end LSPs which are New end-to-end LSPs that are tunneled within the SPME can be set up,
tunneled within the SPME can be set up, which may require which may require coordination across administrative boundaries.
coordination across administrative boundaries. Traffic of the Traffic of the existing LSPs is switched over to the new end-to-end
existing LSPs is switched over to the new end-to-end tunneled LSPs. tunneled LSPs. The old end-to-end LSPs can then be torn down.
The old end-to-end LSPs can then be torn down.
Hierarchical label stacking, in a similar manner to that described Hierarchical label stacking, in a similar manner to that described
above, can be used to implement sub-path maintenance entities on above, can be used to implement Sub-Path Maintenance Elements on
pseudowires. pseudowires, as described in [OAM-FRAMEWORK].
3.14. Network Management 3.14. 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 [NM-FRAMEWORK] and [NM-REQ]. These derive from the
[I-D.ietf-mpls-tp-nm-req]. These derive from the generic 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. They also incorporate 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 [RFC5860] and expand
[I-D.ietf-mpls-tp-oam-requirements] and expand on those requirements on those requirements to cover the modifications necessary for fault,
to cover the modifications necessary for fault, configuration, 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), realized 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. The Network Management System (NMS) can be used to
to an MPLS-TP NE, there is no restriction on which management provision and manage an end-to-end connection across a network.
protocol is used. The Network Management System (NMS) is used to
provision and manage an end-to-end connection across a network where
some segments are created/managed by, for example, Netconf [RFC4741]
or SNMP [RFC3411] and other segments by XML or CORBA interfaces.
Maintenance operations are run on a connection (LSP or PW) in a Maintenance operations are run on a connection (LSP or PW) in a
manner that is independent of the provisioning mechanism. An MPLS-TP manner that is independent of the provisioning mechanism. Segments
NE is not required to offer more than one standard management may be created or managed by, for example, Netconf [RFC4741], SNMP
interface. In MPLS-TP, the EMF needs to support statically [RFC3411], or CORBA (Common Object Request Broker Architecture)
provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any interfaces, but not all segments need to be created or managed using
associated MEPs and MIPs, as per Section 3.11. the same type of interface. Where an MPLS-TP NE is managed by an
NMS, at least one of these standard management mechanisms is required
for interoperability, but this document imposes no restriction on
which of these standard management protocols is used. In MPLS-TP,
the EMF needs to support statically provisioning LSPs for an LSR or
LER, and PWs for a PE, as well as any associated MEPs and MIPs, as
per Section 3.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 needs to provide for the supervision of its environment. FM needs to provide for the supervision of
transmission (such as continuity, connectivity, etc.), software transmission (such as continuity, connectivity, etc.), software
processing, hardware, and environment. Alarm handling includes alarm processing, hardware, and environment. Alarm handling includes alarm
severity assignment, alarm suppression/aggregation/correlation, alarm severity assignment, alarm suppression/aggregation/correlation, alarm
reporting control, and alarm reporting. reporting control, and alarm reporting.
skipping to change at page 47, line 23 skipping to change at page 48, line 8
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 Maintenance Entity Group Endpoint (MEP) ID and identifiers (such as Maintenance Entity Group Endpoint (MEP) ID and
MEG Intermediate Point (MIP) ID). The EMF also supports the 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 behavior 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 behavior in a hybrid network that uses multiple transport
technologies. Packet loss measurement and delay measurements may be technologies. Packet loss measurement and delay measurements may be
collected and used to detect performance degradation. This is collected and used to detect performance degradation. This is
reported via fault management to enable corrective actions to be reported via fault management to enable corrective actions to be
taken (e.g. protection switching), and via performance monitoring for taken (e.g., protection switching) and via performance monitoring for
Service Level Agreement (SLA) verification and billing. Collection Service Level Agreement (SLA) verification and billing. Collection
mechanisms for performance data should be capable of operating on- mechanisms for performance data should be capable of operating on-
demand or pro-actively. demand or proactively.
4. Security Considerations 4. Security Considerations
The introduction of MPLS-TP into transport networks means that the The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS and PWE3 apply to security considerations applicable to both MPLS [RFC3031] and PWE3
those transport networks. When an MPLS function is included in the [RFC3985] apply to those transport networks. When an MPLS function
MPLS transport profile, the security considerations pertinent to that is included in the MPLS transport profile, the security
function apply to MPLS-TP. Furthermore, when general MPLS networks considerations pertinent to that function apply to MPLS-TP.
that utilise functionality outside of the strict MPLS Transport Furthermore, when general MPLS networks that utilize functionality
Profile are used to support packet transport services, the security outside of the strict MPLS Transport Profile are used to support
considerations of that additional functionality also apply. packet transport services, the security 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.
MPLS-TP nodes that implement the G-ACh create a Control Channel (CC) MPLS-TP nodes that implement the G-ACh create a Control Channel (CC)
associated with a pseudowire, LSP or section. This control channel associated with a pseudowire, LSP, or section. This control channel
can be signaled or statically configured. Over this control channel, can be signaled or statically configured. Over this control channel,
control channel messages related to network maintenance functions control channel messages related to network maintenance functions
such as OAM, signaling or network management are sent. Therefore, such as OAM, signaling, or network management are sent. Therefore,
three different areas are of concern from a security standpoint. three different areas are of concern from a security standpoint.
The first area of concern relates to control plane parameter and The first area of concern relates to control plane parameter and
status message attacks, that is, attacks that concern the signaling status message attacks, that is, attacks that concern the signaling
of G-ACh capabilities. MPLS-TP Control Plane security is discussed of G-ACh capabilities. MPLS-TP Control Plane security is discussed
in [I-D.ietf-mpls-mpls-and-gmpls-security-framework]. in [RFC5920].
A second area of concern centers on data-plane attacks, that is, A second area of concern centers on data-plane attacks, that is,
attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh
mechanisms are subject to additional data-plane denial-of- service mechanisms are subject to additional data-plane denial-of-service
attacks as follows: attacks as follows:
An intruder could intercept or inject G-ACh packets effectively An intruder could intercept or inject G-ACh packets effectively
disrupting the protocols carried over the G-ACh. disrupting the protocols carried over the G-ACh.
An intruder could deliberately flood a peer MPLS-TP node with An intruder could deliberately flood a peer MPLS-TP node with
G-ACh messages to deny services to others. G-ACh messages to deny services to others.
A misconfigured or misbehaving device could inadvertently flood a A misconfigured or misbehaving device could inadvertently flood a
peer MPLS-TP node with G-ACh messages which could result in denial peer MPLS-TP node with G-ACh messages that could result in denial
of services. In particular, if a node has either implicitly or of services. In particular, if a node has either implicitly or
explicitly indicated that it cannot support one or all of the explicitly indicated that it cannot support one or all of the
types of G-ACh protocol, but is sent those messages in sufficient types of G-ACh protocol, but is sent those messages in sufficient
quantity, it could result in a denial of service. quantity, it could result in a denial of service.
To protect against these potential (deliberate or unintentional) To protect against these potential (deliberate or unintentional)
attacks, multiple mitigation techniques can be employed: attacks, multiple mitigation techniques can be employed:
G-ACh message throttling mechanisms can be used, especially in G-ACh message throttling mechanisms can be used, especially in
distributed implementations which have a centralized control-plane distributed implementations that have a centralized control-plane
processor with various line cards attached by some control-plane processor with various line cards attached by some control-plane
data path. In these architectures, G-ACh messages may be data path. In these architectures, G-ACh messages may be
processed on the central processor after being forwarded there by processed on the central processor after being forwarded there by
the receiving line card. In this case, the path between the line the receiving line card. In this case, the path between the line
card and the control processor may become saturated if appropriate card and the control processor may become saturated if appropriate
G-ACh traffic throttling is not employed, which could lead to a G-ACh traffic throttling is not employed, which could lead to a
complete denial of service to users of the particular line card. complete denial of service to users of the particular line card.
Such filtering is also useful for preventing the processing of Such filtering is also useful for preventing the processing of
unwanted G-ACh messages, such as those which are sent on unwanted unwanted G-ACh messages, such as those which are sent on unwanted
(and perhaps unadvertised) control channel types. (and perhaps unadvertised) control channel types.
A third and last area of concern relates to the processing of the A third and last area of concern relates to the processing of the
actual contents of G-ACh messages. It is necessary that the actual contents of G-ACh messages. It is necessary that the
definition of the protocols using these messages carried over a G-ACh definition of the protocols using these messages carried over a G-ACh
include appropriate security measures. include appropriate security measures.
Additional security considerations apply to each MPLS-TP solution. Additional security considerations apply to each MPLS-TP solution.
These are discussed further in [I-D.fang-mpls-tp-security-framework]. These are discussed further in [SEC-FRAMEWORK].
The security considerations in The security considerations in [RFC5920] apply.
[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
The editors wish to thank the following for their contribution to The editors wish to thank the following for their contributions to
this document: this document:
o Rahul Aggarwal o Rahul Aggarwal
o Dieter Beller o Dieter Beller
o Malcolm Betts o Malcolm Betts
o Italo Busi o Italo Busi
skipping to change at page 50, line 4 skipping to change at page 50, line 35
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. References 7. References
7.1. Normative References 7.1. Normative References
[G.7710] "ITU-T [G.7710] ITU-T, "Common equipment management function
Recommendation requirements", ITU-T Recommendation G.7710/Y.1701,
G.7710/Y.1701 July 2007.
(07/07), "Common
equipment
management
function
requirements"",
2005.
[G.805] "ITU-T [G.805] ITU-T, "Generic Functional Architecture of Transport
Recommendation Networks", ITU-T Recommendation G.805, November
G.805 (11/95), 1995.
"Generic
Functional
Architecture of
Transport
Networks"",
November 1995.
[RFC3031] Rosen, E., [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
Viswanathan, A., "Multiprotocol Label Switching Architecture", RFC
and R. Callon, 3031, January 2001.
"Multiprotocol
Label Switching
Architecture",
RFC 3031,
January 2001.
[RFC3032] Rosen, E., Tappan, [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
D., Fedorkow, G., Farinacci, D., Li, T., and A. Conta, "MPLS Label
Rekhter, Y., Stack Encoding", RFC 3032, January 2001.
Farinacci, D., Li,
T., and A. Conta,
"MPLS Label Stack
Encoding",
RFC 3032,
January 2001.
[RFC3270] Le Faucheur, F., [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Wu, L., Davie, B., Vaananen, P., Krishnan, R., Cheval, P., and J.
Davari, S., Heinanen, "Multi-Protocol Label Switching (MPLS)
Vaananen, P., Support of Differentiated Services", RFC 3270, May
Krishnan, R., 2002.
Cheval, P., and J.
Heinanen, "Multi-
Protocol Label
Switching (MPLS)
Support of
Differentiated
Services",
RFC 3270,
May 2002.
[RFC3473] Berger, L., [RFC3473] Berger, L., "Generalized Multi-Protocol Label
"Generalized Switching (GMPLS) Signaling Resource ReserVation
Multi-Protocol Protocol-Traffic Engineering (RSVP-TE) Extensions",
Label Switching RFC 3473, January 2003.
(GMPLS) Signaling
Resource
ReserVation
Protocol-Traffic
Engineering
(RSVP-TE)
Extensions",
RFC 3473,
January 2003.
[RFC3985] Bryant, S. and P. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
Pate, "Pseudo Wire to-Edge (PWE3) Architecture", RFC 3985, March 2005.
Emulation Edge-to-
Edge (PWE3)
Architecture",
RFC 3985,
March 2005.
[RFC4090] Pan, P., Swallow, [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
G., and A. Atlas, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
"Fast Reroute May 2005.
Extensions to
RSVP-TE for LSP
Tunnels",
RFC 4090,
May 2005.
[RFC4385] Bryant, S., [RFC4385] Bryant, S., Swallow, G., Martini, L., and D.
Swallow, G., McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3)
Martini, L., and Control Word for Use over an MPLS PSN", RFC 4385,
D. McPherson, February 2006.
"Pseudowire
Emulation Edge-to-
Edge (PWE3)
Control Word for
Use over an MPLS
PSN", RFC 4385,
February 2006.
[RFC4447] Martini, L., [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
Rosen, E., El- G. Heron, "Pseudowire Setup and Maintenance Using
Aawar, N., Smith, the Label Distribution Protocol (LDP)", RFC 4447,
T., and G. Heron, April 2006.
"Pseudowire Setup
and Maintenance
Using the Label
Distribution
Protocol (LDP)",
RFC 4447,
April 2006.
[RFC4872] Lang, J., Rekhter, [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou,
Y., and D. "RSVP-TE Extensions in Support of End-to-End
Papadimitriou, Generalized Multi-Protocol Label Switching (GMPLS)
"RSVP-TE Recovery", RFC 4872, May 2007.
Extensions in
Support of End-to-
End Generalized
Multi-Protocol
Label Switching
(GMPLS) Recovery",
RFC 4872,
May 2007.
[RFC5085] Nadeau, T. and C. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual
Pignataro, Circuit Connectivity Verification (VCCV): A Control
"Pseudowire Channel for Pseudowires", RFC 5085, December 2007.
Virtual Circuit
Connectivity
Verification
(VCCV): A Control
Channel for
Pseudowires",
RFC 5085,
December 2007.
[RFC5586] Bocci, M., [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS
Vigoureux, M., and Generic Associated Channel", RFC 5586, June 2009.
S. Bryant, "MPLS
Generic Associated
Channel",
RFC 5586,
June 2009.
7.2. Informative References 7.2. Informative References
[G.8080] "ITU-T [CP-FRAMEWORK] Andersson, L., Berger, L., Fang, L., Bitar, N.,
Recommendation Takacs, A., Vigoureux, M., Bellagamba, E., and E.
G.8080/Y.1304, Gray, "MPLS-TP Control Plane Framework", Work in
"Architecture for Progress, March 2010.
the automatically
switched optical
network (ASON)"",
2005.
[I-D.fang-mpls-tp-security-framework] Fang, L. and B.
Niven-Jenkins,
"Security
Framework for
MPLS-TP", draft-
fang-mpls-tp-
security-
framework-01 (work
in progress),
March 2010.
[I-D.ietf-bfd-mpls] Aggarwal, R., [DATA-PLANE] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Kompella, K., Profile Data Plane Architecture", Work in Progress,
Nadeau, T., and G. July 2010.
Swallow, "BFD For
MPLS LSPs", draft-
ietf-bfd-mpls-07
(work in
progress),
June 2008.
[I-D.ietf-ccamp-mpls-tp-cp-framework] Andersson, L., [DYN-MS-PW] Martini, L., Bocci, M., Balus, F., Bitar, N., Shah,
Berger, L., Fang, H., Aissaoui, M., Rusmisel, J., Serbest, Y., Malis,
L., Bitar, N., A., Metz, C., McDysan, D., Sugimoto, J., Duckett,
Takacs, A., M., Loomis, M., Doolan, P., Pan, P., Pate, P.,
Vigoureux, M., Radoaca, V., Wada, Y., and Y. Seo, "Dynamic
Bellagamba, E., Placement of Multi Segment Pseudo Wires", Work in
and E. Gray, Progress, October 2009.
"MPLS-TP Control
Plane Framework",
draft-ietf-ccamp-
mpls-tp-cp-
framework-01 (work
in progress),
March 2010.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., [G.8080] ITU-T, "Architecture for the automatically switched
JOUNAY, F., Niven- optical network (ASON)", ITU-T Recommendation
Jenkins, B., G.8080/Y.1304, 2005.
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.ietf-mpls-mpls-and-gmpls-security-framework] Fang, L. and M. [IDENTIFIERS] Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
Behringer, Work in Progress, March 2010.
"Security
Framework for MPLS
and GMPLS
Networks", draft-
ietf-mpls-mpls-
and-gmpls-
security-
framework-09 (work
in progress),
March 2010.
[I-D.ietf-mpls-tp-data-plane] Frost, D., Bryant, [NM-FRAMEWORK] Mansfield, S., Ed., Gray, E., Ed., and H. Lam, Ed.,
S., and M. Bocci, "MPLS-TP Network Management Framework", Work in
"MPLS Transport Progress, February 2010.
Profile Data Plane
Architecture", dra
ft-ietf-mpls-tp-
data-plane-02
(work in
progress),
April 2010.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. [NM-REQ] Mansfield, S. and K. Lam, "MPLS TP Network
Swallow, "MPLS-TP Management Requirements", Work in Progress, October
Identifiers", draf 2009.
t-ietf-mpls-tp-
identifiers-01
(work in
progress),
March 2010.
[I-D.ietf-mpls-tp-nm-framework] Mansfield, S., [OAM-DEF] Andersson, L., Helvoort, H., Bonica, R., Romascanu,
Gray, E., and H. D., and S. Mansfield, "The OAM Acronym Soup", Work
Lam, "MPLS-TP in Progress, June 2010.
Network Management
Framework", draft-
ietf-mpls-tp-nm-
framework-05 (work
in progress),
February 2010.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and [OAM-FRAMEWORK] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan,
K. Lam, "MPLS TP Ed., "MPLS-TP OAM Framework", Work in Progress,
Network Management April 2010.
Requirements", dra
ft-ietf-mpls-tp-
nm-req-06 (work in
progress),
October 2009.
[I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, [PW-REDUNDANCY] Muley, P., "Pseudowire (PW) Redundancy", Work in
I., Niven-Jenkins, Progress, May 2010.
B., Fulignoli, A.,
Hernandez-
Valencia, E.,
Levrau, L., Mohan,
D., Sestito, V.,
Sprecher, N.,
Helvoort, H.,
Vigoureux, M.,
Weingarten, Y.,
and R. Winter,
"MPLS-TP OAM
Framework", draft-
ietf-mpls-tp-oam-
framework-06 (work
in progress),
April 2010.
[I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M. and [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
D. Ward, Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
"Requirements for to RSVP for LSP Tunnels", RFC 3209, December 2001.
OAM in MPLS
Transport
Networks", draft-
ietf-mpls-tp-oam-
requirements-06
(work in
progress),
March 2010.
[I-D.ietf-mpls-tp-rosetta-stone] Helvoort, H., [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Andersson, L., and Architecture for Describing Simple Network
N. Sprecher, "A Management Protocol (SNMP) Management Frameworks",
Thesaurus for the STD 62, RFC 3411, December 2002.
Terminology used
in Multiprotocol
Label Switching
Transport Profile
(MPLS-TP) drafts/
RFCs and ITU-T's
Transport Network
Recommendations",
draft-ietf-mpls-
tp-rosetta-stone-
01 (work in
progress),
October 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL)
A. Farrel, Processing in Multi-Protocol Label Switching (MPLS)
"Multiprotocol Networks", RFC 3443, January 2003.
Label Switching
Transport Profile
Survivability
Framework", draft-
ietf-mpls-tp-
survive-fwk-05
(work in
progress),
April 2010.
[I-D.ietf-opsawg-mpls-tp-oam-def] Andersson, L., [RFC3471] Berger, L., "Generalized Multi-Protocol Label
Helvoort, H., Switching (GMPLS) Signaling Functional Description",
Bonica, R., RFC 3471, January 2003.
Romascanu, D., and
S. Mansfield,
""The use of the
OAM Acronym in
MPLS-TP"", draft-
ietf-opsawg-mpls-
tp-oam-def-04
(work in
progress),
April 2010.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., [RFC3945] Mannie, E., "Generalized Multi-Protocol Label
Bocci, M., Balus, Switching (GMPLS) Architecture", RFC 3945, October
F., Bitar, N., 2004.
Shah, H.,
Aissaoui, M.,
Rusmisel, J.,
Serbest, Y.,
Malis, A., Metz,
C., McDysan, D.,
Sugimoto, J.,
Duckett, M.,
Loomis, M.,
Doolan, P., Pan,
P., Pate, P.,
Radoaca, V., Wada,
Y., and Y. Seo,
"Dynamic Placement
of Multi Segment
Pseudo Wires", dra
ft-ietf-pwe3-
dynamic-ms-pw-10
(work in
progress),
October 2009.
[I-D.ietf-pwe3-redundancy] Muley, P. and V. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
Place, "Pseudowire Private Networks (VPNs)", RFC 4364, February 2006.
(PW) Redundancy",
draft-ietf-pwe3-
redundancy-02
(work in
progress),
October 2009.
[I-D.ietf-pwe3-segmented-pw] Martini, L., [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and
Nadeau, T., Metz, S. Matsushima, "Operations and Management (OAM)
C., Bocci, M., Requirements for Multi-Protocol Label Switched
Aissaoui, M., (MPLS) Networks", RFC 4377, February 2006.
Balus, F., and M.
Duckett,
"Segmented
Pseudowire", draft
-ietf-pwe3-
segmented-pw-14
(work in
progress),
April 2010.
[I-D.ietf-pwe3-vccv-bfd] Nadeau, T. and C. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
Protocol Label Switched (MPLS) Data Plane Failures",
RFC 4379, February 2006.
Pignataro, [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2
"Bidirectional Virtual Private Networks (L2VPNs)", RFC 4664,
Forwarding September 2006.
Detection (BFD)
for the Pseudowire
Virtual Circuit
Connectivity
Verification
(VCCV)", draft-
ietf-pwe3-vccv-
bfd-07 (work in
progress),
July 2009.
[RFC3209] Awduche, D., [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A
Berger, L., Gan, Framework for Inter-Domain Multiprotocol Label
D., Li, T., Switching Traffic Engineering", RFC 4726, November
Srinivasan, V., 2006.
and G. Swallow,
"RSVP-TE:
Extensions to RSVP
for LSP Tunnels",
RFC 3209,
December 2001.
[RFC3411] Harrington, D., [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC
Presuhn, R., and 4741, December 2006.
B. Wijnen, "An
Architecture for
Describing Simple
Network Management
Protocol (SNMP)
Management
Frameworks",
STD 62, RFC 3411,
December 2002.
[RFC3443] Agarwal, P. and B. [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A.
Akyol, "Time To Farrel, "Label Switched Path Stitching with
Live (TTL) Generalized Multiprotocol Label Switching Traffic
Processing in Engineering (GMPLS TE)", RFC 5150, February 2008.
Multi-Protocol
Label Switching
(MPLS) Networks",
RFC 3443,
January 2003.
[RFC3471] Berger, L., [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements
"Generalized for Multi-Segment Pseudowire Emulation Edge-to-Edge
Multi-Protocol (PWE3)", RFC 5254, October 2008.
Label Switching
(GMPLS) Signaling
Functional
Description",
RFC 3471,
January 2003.
[RFC3945] Mannie, E., [RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation
"Generalized over LAN in Link State Routing Protocols", RFC 5309,
Multi-Protocol October 2008.
Label Switching
(GMPLS)
Architecture",
RFC 3945,
October 2004.
[RFC4364] Rosen, E. and Y. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS
Rekhter, "BGP/MPLS Upstream Label Assignment and Context-Specific Label
IP Virtual Private Space", RFC 5331, August 2008.
Networks (VPNs)",
RFC 4364,
February 2006.
[RFC4377] Nadeau, T., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M.,
Morrow, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS
Swallow, G., Transport Profile", RFC 5654, September 2009.
Allan, D., and S.
Matsushima,
"Operations and
Management (OAM)
Requirements for
Multi-Protocol
Label Switched
(MPLS) Networks",
RFC 4377,
February 2006.
[RFC4379] Kompella, K. and [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
G. Swallow, Segment Pseudowire Emulation Edge-to-Edge", RFC
"Detecting Multi- 5659, October 2009.
Protocol Label
Switched (MPLS)
Data Plane
Failures",
RFC 4379,
February 2006.
[RFC4664] Andersson, L. and [RFC5718] Beller, D. and A. Farrel, "An In-Band Data
E. Rosen, Communication Network For the MPLS Transport
"Framework for Profile", RFC 5718, January 2010.
Layer 2 Virtual
Private Networks
(L2VPNs)",
RFC 4664,
September 2006.
[RFC4726] Farrel, A., [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements
Vasseur, J., and for Operations, Administration, and Maintenance
A. Ayyangar, "A (OAM) in MPLS Transport Networks", RFC 5860, May
Framework for 2010.
Inter-Domain
Multiprotocol
Label Switching
Traffic
Engineering",
RFC 4726,
November 2006.
[RFC4741] Enns, R., "NETCONF [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G.
Configuration Swallow, "Bidirectional Forwarding Detection (BFD)
Protocol", for MPLS Label Switched Paths (LSPs)", RFC 5884,
RFC 4741, June 2010.
December 2006.
[RFC5150] Ayyangar, A., [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional
Kompella, K., Forwarding Detection (BFD) for the Pseudowire
Vasseur, JP., and Virtual Circuit Connectivity Verification (VCCV)",
A. Farrel, "Label RFC 5885, June 2010.
Switched Path
Stitching with
Generalized
Multiprotocol
Label Switching
Traffic
Engineering (GMPLS
TE)", RFC 5150,
February 2008.
[RFC5254] Bitar, N., Bocci, [RFC5920] Fang, L., Ed., "Security Framework for MPLS and
M., and L. GMPLS Networks", RFC 5920, July 2010.
Martini,
"Requirements for
Multi-Segment
Pseudowire
Emulation Edge-to-
Edge (PWE3)",
RFC 5254,
October 2008.
[RFC5309] Shen, N. and A. [ROSETTA-STONE] Sprecher, N., "A Thesaurus for the Terminology used
Zinin, "Point-to- in Multiprotocol Label Switching Transport Profile
Point Operation (MPLS-TP) drafts/RFCs and ITU-T's Transport Network
over LAN in Link Recommendations.", Work in Progress, May 2010.
State Routing
Protocols",
RFC 5309,
October 2008.
[RFC5331] Aggarwal, R., [SEC-FRAMEWORK] Fang, L. and B. Niven-Jenkins, "Security Framework
Rekhter, Y., and for MPLS-TP", Work in Progress, March 2010.
E. Rosen, "MPLS
Upstream Label
Assignment and
Context-Specific
Label Space",
RFC 5331,
August 2008.
[RFC5654] Niven-Jenkins, B., [SEGMENTED-PW] Martini, L., Nadeau, T., Metz, C., Bocci, M., and M.
Brungard, D., Aissaoui, "Segmented Pseudowire", Work in Progress,
Betts, M., June 2010.
Sprecher, N., and
S. Ueno,
"Requirements of
an MPLS Transport
Profile",
RFC 5654,
September 2009.
[RFC5659] Bocci, M. and S. [SURVIVE-FWK] Sprecher, N. and A. Farrel, "Multiprotocol Label
Bryant, "An Switching Transport Profile Survivability
Architecture for Framework", Work in Progress, June 2010.
Multi-Segment
Pseudowire
Emulation Edge-to-
Edge", RFC 5659,
October 2009.
[RFC5718] Beller, D. and A. [VPMS-REQS] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard,
Farrel, "An In- D., and L. Jin, "Framework and Requirements for
Band Data Virtual Private Multicast Service (VPMS)", Work in
Communication Progress, October 2009.
Network For the
MPLS Transport
Profile",
RFC 5718,
January 2010.
[X.200] "ITU-T [X.200] ITU-T, "Information Technology - Open Systems
Recommendation Interconnection - Basic reference Model: The Basic
X.200, Model", ITU-T Recommendation X.200, 1994.
"Information
Technology - Open
Systems
Interconnection -
Basic reference
Model: The Basic
Model"", 1994.
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:
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
Stewart Bryant (editor) Stewart Bryant (editor)
Cisco Systems Cisco Systems
250 Longwater Ave 250 Longwater Ave
Reading RG2 6GB Reading RG2 6GB
United Kingdom United Kingdom
Phone:
EMail: stbryant@cisco.com EMail: stbryant@cisco.com
Dan Frost (editor) Dan Frost (editor)
Cisco Systems Cisco Systems
Phone:
Fax:
EMail: danfrost@cisco.com EMail: danfrost@cisco.com
URI:
Lieven Levrau Lieven Levrau
Alcatel-Lucent Alcatel-Lucent
7-9, Avenue Morane Sulnier 7-9, Avenue Morane Sulnier
Velizy 78141 Velizy 78141
France France
Phone:
EMail: lieven.levrau@alcatel-lucent.com EMail: lieven.levrau@alcatel-lucent.com
Lou Berger Lou Berger
LabN LabN Consulting, L.L.C.
Phone: +1-301-468-9228
Fax:
EMail: lberger@labn.net EMail: lberger@labn.net
URI:
 End of changes. 296 change blocks. 
1027 lines changed or deleted 631 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/