draft-ietf-mpls-tp-framework-11.txt   draft-ietf-mpls-tp-framework-12.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational S. Bryant, Ed. Intended status: Informational S. Bryant, Ed.
Expires: October 4, 2010 D. Frost, Ed. Expires: November 6, 2010 D. Frost, Ed.
Cisco Systems Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN LabN
April 02, 2010 May 5, 2010
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-11 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-TP) - that supports the operational models and capabilities (MPLS-TP) - that supports the operational models and capabilities
typical of such networks, including signaled or explicitly typical of such networks, including signaled or explicitly
provisioned bi-directional connection-oriented paths, protection and provisioned bidirectional connection-oriented paths, protection and
restoration mechanisms, comprehensive Operations, Administration and restoration mechanisms, comprehensive Operations, Administration and
Maintenance (OAM) functions, and network operation in the absence of Maintenance (OAM) functions, and network operation in the absence of
a dynamic control plane or IP forwarding support. Some of these a dynamic control plane or IP forwarding support. Some of these
functions are defined in existing MPLS specifications, while others functions are defined in existing MPLS specifications, while others
require extensions to existing specifications to meet the require extensions to existing specifications to meet the
requirements of the MPLS-TP. requirements of the MPLS-TP.
This document defines the subset of the MPLS-TP applicable in general This document defines the subset of the MPLS-TP applicable in general
and to point-to-point 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 Telecommunications Union Telecommunications (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 PWE3 architectures to support the
capabilities and functionalities of a packet transport network as capabilities and functionalities of a packet transport network as
defined by the ITU-T. defined by the ITU-T.
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2010. This Internet-Draft will expire on November 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 44
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the 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 . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8 1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 9
1.3.7. Edge-to-Edge LSP . . . . . . . . . . . . . . . . . . . 9 1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 9
1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 9 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 9 1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10
1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 9 1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10
1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 9 1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10
1.3.12. Additional Definitions and Terminology . . . . . . . . 9 1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 10 1.3.13. Additional Definitions and Terminology . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 10 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 10 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 11
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 11 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 11
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 12
3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 13 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 13 3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14
3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 14 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 15 3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16
3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 16 3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16
3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 17 3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17
3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 23 3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18
3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 26 3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 30 3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 30 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33
3.7. Operations, Administration and Maintenance (OAM) . . . . . 32 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33
3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 34 3.7. Operations, Administration and Maintenance (OAM) . . . . . 35
3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 35 3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 37
3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 35 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 38
3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 36 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 36 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 39
3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 36 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 39
3.10. Interdomain Connectivity . . . . . . . . . . . . . . . . . 39 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40
3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 39 3.10. Interdomain Connectivity . . . . . . . . . . . . . . . . . 42
3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 39 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 42
3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 41 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 43
3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 42 3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 44
3.15. Network Management . . . . . . . . . . . . . . . . . . . . 42 3.14. Network Management . . . . . . . . . . . . . . . . . . . . 46
4. Security Considerations . . . . . . . . . . . . . . . . . . . 44 4. Security Considerations . . . . . . . . . . . . . . . . . . . 47
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 45 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . . 48 7.2. Informative References . . . . . . . . . . . . . . . . . . 53
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.
skipping to change at page 4, line 33 skipping to change at page 4, line 33
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 management
systems or direct node configuration using a command line systems or direct node configuration using a command line
interface. interface.
o A high level of availability. o A high level of availability.
o Quality of service. o Quality of service.
o Extensive OAM capabilities. o Extensive Operations, Administration and Maintenance (OAM)
capabilities.
Carriers wish to evolve such transport networks to take advantage of Carriers wish to evolve such transport networks to take advantage of
the flexibility and cost benefits of packet switching technology and the flexibility and cost benefits of packet switching technology and
to support packet based services more efficiently. While MPLS is a to support packet based services more efficiently. While MPLS is a
maturing packet technology that already plays an important role in maturing packet technology that already plays an important role in
transport networks and services, not all MPLS capabilities and transport networks and services, not all MPLS capabilities and
mechanisms are needed in, or consistent with, the transport network mechanisms are needed in, or consistent with, the transport network
operational model. There are also transport technology operational model. There are also transport technology
characteristics that are not currently reflected in MPLS. characteristics that are not currently reflected in MPLS.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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 Telecommunications Union Telecommunications (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 PWE3 architectures to support the
capabilities and functionalities of a packet transport network as capabilities and functionalities of a packet transport network as
defined by the ITU-T. defined by the ITU-T.
1.2. Scope 1.2. Scope
This document describes an architectural framework for the This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that networks. It specifies the common set of protocol functions that
meet the requirements in [RFC5654], and that together constitute the meet the requirements in [RFC5654], and that together constitute the
MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport
paths. The remaining MPLS-TP functions, applicable specifically to paths. The remaining MPLS-TP functions, applicable specifically to
point-to-multipoint transport paths, are outside the scope of this point-to-multipoint transport paths, are outside the scope of this
document. document.
1.3. Terminology 1.3. Terminology
Term Definition Term Definition
---------- ---------------------------------------------------------- ---------- ----------------------------------------------------------
LSP Label Switched Path AC Attachment Circuit
MPLS-TP MPLS Transport Profile ACH Associated Channel Header
SDH Synchronous Digital Hierarchy Adaptation The mapping of client information into a format suitable
for transport by the server layer
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
OTN Optical Transport Network BFD Bidirectional Forwarding Detection
cl-ps Connectionless - Packet Switched CE Customer Edge
co-cs Connection Oriented - Circuit Switched CL-PS Connectionless - Packet Switched
co-ps Connection Oriented - Packet Switched CM Configuration Management
OAM Operations, Administration and Maintenance CO-CS Connection Oriented - Circuit Switched
CO-PS Connection Oriented - Packet Switched
DCN Data Communication Network
EMF Equipment Management Function
FCAPS Fault, Configuration, Accounting, Performance and Security
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
LSP Label Switched Path
LSR Label Switching Router
MAC Media Access Control
MCC Management Communication Channel
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
APS Automatic Protection Switching MPLS Multiprotocol Label Switching
SCC Signaling Communication Channel MPLS-TP MPLS Transport Profile
MCC Management Communication Channel
EMF Equipment Management Function
FM Fault Management
CM Configuration Management
PM Performance Management
LSR Label Switching Router
MPLS-TP PE MPLS-TP Provider Edge LSR
MPLS-TP P MPLS-TP Provider LSR MPLS-TP P MPLS-TP Provider LSR
PW Pseudowire MPLS-TP PE MPLS-TP Provider Edge LSR
AC Attachment Circuit MS-PW Multi-Segment Pseudowire
Adaptation The mapping of client information into a format suitable
for transport by the server layer
Native The traffic belonging to the client of the MPLS-TP network Native The traffic belonging to the client of the MPLS-TP network
Service Service
OAM Operations, Administration and Maintenance (see
[I-D.ietf-opsawg-mpls-tp-oam-def])
OSI Open Systems Interconnection
OTN Optical Transport Network
PDU Protocol Data Unit
PM Performance Monitoring
PSN Packet Switching Network
PW Pseudowire
SCC Signaling Communication Channel
SDH Synchronous Digital Hierarchy
S-PE PW Switching Provider Edge
SPME Sub-Path Maintenance Element
T-PE PW Terminating Provider Edge T-PE PW Terminating Provider Edge
S-PE PW Switching provider Edge VCCV Virtual Circuit Connectivity Verification
PST Path Segment Tunnel
1.3.1. Transport Network 1.3.1. Transport Network
A Transport Network provides transparent transmission of client user A Transport Network provides transparent transmission of client user
plane traffic between attached client devices by establishing and plane traffic between attached client devices by establishing and
maintaining point-to-point or point-to-multipoint connections between maintaining point-to-point or point-to-multipoint connections between
such devices. The architecture of networks supporting point to such devices. The architecture of networks supporting point-to-
multipoint connections is outside the scope of this document. A multipoint connections is outside the scope of this document. A
Transport Network is independent of any higher-layer network that may Transport Network is independent of any higher-layer network that may
exist between clients, except to the extent required to supply this exist between clients, except to the extent required to supply this
transmission service. In addition to client traffic, a Transport transmission service. In addition to client traffic, a Transport
Network may carry traffic to facilitate its own operation, such as Network may carry traffic to facilitate its own operation, such as
that required to support connection control, network management, and that required to support connection control, network management, and
Operations, Administration and Maintenance (OAM) functions. Operations, Administration and Maintenance (OAM) functions.
See also the definition of Packet Transport Service in Section 3.1. See also the definition of Packet Transport Service in Section 3.1.
skipping to change at page 7, line 41 skipping to change at page 7, line 36
1. Uses a subset of the MPLS OAM tools defined as described in 1. Uses a subset of the MPLS OAM tools defined as described in
[I-D.ietf-mpls-tp-oam-framework]. [I-D.ietf-mpls-tp-oam-framework].
2. Supports 1+1, 1:1, and 1:N protection functions. 2. Supports 1+1, 1:1, and 1:N protection functions.
3. Is traffic engineered. 3. Is traffic engineered.
4. May be established and maintained via the management plane, or 4. May be established and maintained via the management plane, or
using GMPLS protocols when a control plane is used. using GMPLS protocols when a control plane is used.
5. Is either point-to-point or point-to-multipoint. Multipoint-to- 5. Is either point-to-point or point-to-multipoint. multipoint-to-
point and multipoint-to-multipoint LSPs are not supported. point and multipoint-to-multipoint LSPs are not supported.
6. It is either unidirectional, associated bidirectional, or co-
routed bidirectional (i.e. the forward and reverse components of
a bidirectional LSP follow the same path and the intermediate
nodes are aware of their association). These are further defined
in [I-D.ietf-mpls-tp-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 [I-D.ietf-mpls-tp-data-plane] for further details on the types
and data-plane properties of MPLS-TP LSPs. and data-plane 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
skipping to change at page 8, line 34 skipping to change at page 8, line 34
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
PE may be either an S-PE or a T-PE, as defined in [RFC5659]. A PE PE may be either an S-PE or a T-PE, as defined in [RFC5659] (see
that pushes or pops a label is an LER. below). A PE that pushes or pops an LSP label is an LER for that
LSP.
The term Provider Edge refers to the node's role within a provider's
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
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
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 which carry client traffic, but does not adapt client
traffic and encapsulate it to be carried over an MPLS-TP LSP. traffic and encapsulate it to be carried over an MPLS-TP LSP. The
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 domains.
1.3.5.4. Pseudowire Switching Provider Edge Router (S-PE)
RFC5659[RFC5659] defines an S-PE as:
"A PE capable of switching the control and data planes of the
preceding and succeeding PW segments in an MS-PW. The S-PE
terminates the PSN tunnels of the preceding and succeeding
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 the same MS-PW. A PW switching point runs necessary protocols
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
processed or policy applied. It is therefore not limited to the
edge of a provider network.
"Note that it was originally anticipated that S-PEs would only be
deployed at the edge of a provider network where they would be
used to switch the PWs of different service providers. However,
as the design of MS-PW progressed, other applications for MS-PW
were recognized. By this time S-PE had become the accepted term
for the equipment, even though they were no longer universally
deployed at the provider edge."
1.3.5.5. Pseudowire Terminating Provider Edge Router (T-PE)
RFC5659[RFC5659] defines a T-PE as:
"A PE where the customer- facing attachment circuits (ACs) are
bound to a PW forwarder. A terminating PE is present in the first
and last segments of an MS-PW. This incorporates the
functionality of 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 sourcing or sinking
native service traffic to or from the MPLS-TP network. CEs on either native service traffic to or from the MPLS-TP network. CEs on either
side of the MPLS-TP network are peers and view the MPLS-TP network as side of the MPLS-TP network are peers and view the MPLS-TP network as
a single link. a single link.
1.3.7. Edge-to-Edge LSP 1.3.7. Transport LSP
An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit A Transport LSP is an LSP between a pair of PEs that may transit zero
zero or more provider LSRs. or more MPLS-TP provider routers. When carrying PWs, the transport
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 layer network is defined in [G.805] and described in [RFC5654]. A
layer network provides for the transfer of client information and
independent operation of the client OAM. A layer network may be
described in a service context as follows: one layer network may
provide a (transport) service to a higher client layer network and
may, in turn, be a client to a lower-layer network. A layer network
is a logical construction somewhat independent of arrangement or
composition of physical network elements. A particular physical
network element may topologically belong to more than one layer
network, depending on the actions it takes on the encapsulation
associated with the logical layers (e.g., the label stack), and thus
could be modeled as multiple logical elements. A layer network may
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]. used in [RFC3031] and [RFC3032]. Network layer protocols are
synymous with those beloging to layer 3 of the Open System
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 (see 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 section
3.4.3. Alternatively, it may be a layer 2 interface that carries 3.4.3. Alternatively, it may be a layer 2 interface that carries
both network layer and non-network layer clients. To support this both network layer and non-network layer clients. To support this
service interface, a PW is required to adapt the client traffic 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. Additional Definitions and Terminology 1.3.12. Native Service
The native service is the client layer network service that is
transported by the MPLS-TP network, whether a pseudowire or an LSP is
used for the adaptation (see Section 3.4).
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]. [RFC5654] and [I-D.ietf-mpls-tp-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],
[I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req]. [I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req].
This section provides a brief reminder to guide the reader. It is This section provides a brief reminder to guide the reader. It is
not normative or intended as a substitute for these documents. not normative or intended as a substitute for these documents.
MPLS-TP must not modify the MPLS forwarding architecture and must be MPLS-TP must not modify the MPLS forwarding architecture and must be
based on existing pseudowire and LSP constructs. based on existing pseudowire and LSP constructs.
Point to point LSPs may be unidirectional or bi-directional, and it Point-to-point LSPs may be unidirectional or bidirectional, and it
must be possible to construct congruent Bi-directional 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.
skipping to change at page 10, line 42 skipping to change at page 12, line 4
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
inherit 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 the client is o The service provided by the MPLS-TP network to a given client will
guaranteed not to fall below the agreed level regardless of other not to fall below the agreed level as a result of the traffic
client activity. loading 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 co-ordination
required between the client and server layer networks is minimal required between the client and server layer networks is minimal
skipping to change at page 11, line 40 skipping to change at page 12, line 51
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 used in such a [RFC5654] such as Equal Cost Multi-Path, LDP signaling when used in
way that it creates multipoint-to-point LSPs, and IP forwarding in such a way that it creates multipoint-to-point LSPs, and IP
the data plane are explicitly excluded from MPLS-TP by that forwarding in the data plane are explicitly excluded from MPLS-TP by
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 }
{ non-Transport }
{ Functions }
|<========== Pre-RFC5654 MPLS ===========>|
{ ECMP }
{ LDP/non-TE LSPs }
{ IP fwd }
|<============= Pre-RFC5654 MPLS ================>| |<======== MPLS-TP ============>|
{ ECMP } { Additional }
{ LDP/non-TE LSPs } { Transport }
{ IP fwd } { Functions }
|<================ MPLS-TP ====================>|
{ Additional }
{ Transport }
{ 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
applicable in any packet network context. A subset of MPLS-TP is
also applicable to ITU-T defined packet transport networks, where the
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
[I-D.ietf-mpls-tp-data-plane]. [I-D.ietf-mpls-tp-data-plane].
o Sections, LSPs and PWs that provide a packet transport service for o Sections, LSPs and PWs that provide a packet transport service for
a client network. a client network.
o Proactive and on-demand Operations, Administration and Maintenance o Proactive and on-demand Operations, Administration and Maintenance
(OAM) functions to monitor and diagnose the MPLS-TP network, as (OAM) functions to monitor and diagnose the MPLS-TP network, as
outlined in [I-D.ietf-mpls-tp-oam-framework]. outlined in [I-D.ietf-mpls-tp-oam-framework].
o Optional control planes for LSPs and PWs, as well as support for o Control planes for LSPs and PWs, as well as support for static
static provisioning and configuration. provisioning and configuration, as outlined in
o Optional path protection mechanisms to ensure that the packet [I-D.ietf-ccamp-mpls-tp-cp-framework].
transport service survives anticipated failures and degradations
of the MPLS-TP network, as outlined in o Path protection mechanisms to ensure that the packet transport
service survives anticipated failures and degradations of the
MPLS-TP network, as outlined in [I-D.ietf-mpls-tp-survive-fwk].
o Control plane based restoration mechanisms, as outlined in
[I-D.ietf-mpls-tp-survive-fwk]. [I-D.ietf-mpls-tp-survive-fwk].
o Network management functions, as outlined in o Network management functions, as outlined in
[I-D.ietf-mpls-tp-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.
skipping to change at page 13, line 34 skipping to change at page 14, line 52
network data plane from the MPLS-TP data plane, thus contributing to network data plane from the MPLS-TP data plane, thus contributing to
the independent operation of the MPLS-TP network. the independent operation of the MPLS-TP network.
MPLS-TP is itself a client of an underlying server layer. MPLS-TP is MPLS-TP is itself a client of an underlying server layer. MPLS-TP is
thus also bounded by a set of adaptation functions to this server thus also bounded by a set of adaptation functions to this server
layer network, which may itself be MPLS-TP. These adaptation layer network, which may itself be MPLS-TP. These adaptation
functions provide encapsulation of the MPLS-TP frames and for the functions provide encapsulation of the MPLS-TP frames and for the
transparent transport of those frames over the server layer network. transparent transport of those frames over the server layer network.
The MPLS-TP client inherits its Quality of Service (QoS) from the The MPLS-TP client inherits its Quality of Service (QoS) from the
MPLS-TP network, which in turn inherits its QoS from the server MPLS-TP network, which in turn inherits its QoS from the server
layer. The server layer must therefore provide the necessary QoS to layer. The server layer therefore needs to provide the necessary QoS
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 TTL
processing procedures defined in [RFC3031], [RFC3032] and [RFC3443], processing procedures defined in [RFC3031], [RFC3032] and [RFC3443],
as profiled in [I-D.ietf-mpls-tp-data-plane]. These operations are as profiled in [I-D.ietf-mpls-tp-data-plane]. These operations are
skipping to change at page 14, line 41 skipping to change at page 16, line 13
[I-D.ietf-mpls-tp-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 Label o An MPLS LSP
A PW provides any emulated service that the IETF has defined to be
provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A
list of PW types is maintained by IANA in the the "MPLS Pseudowire
Type" registry. When the native service adaptation is via a PW, the
mechanisms described in Section 3.4.4 are used.
An MPLS LSP Label can also be used as the adaptation, in which case MPLS-TP uses IETF-defined pseudowires to emulate certain services,
any native service traffic type supported by [RFC3031] and [RFC3032] for example Ethernet, Frame Relay, or PPP/HDLC. A list of PW types
is allowed. Examples of such traffic types include IP, and MPLS- is maintained by IANA in the the "MPLS Pseudowire Type" registry.
labeled packets. Note that the latter case includes TE-LSPs When the native service adaptation is via a PW, the mechanisms
described in Section 3.4.4 are used.
[RFC3209] and LSP based applications such as PWs, Layer 2 VPNs An MPLS LSP can also provide the adaptation, in which case any native
[RFC4664], and Layer 3 VPNs [RFC4364]. When the native service service traffic type supported by [RFC3031] and [RFC3032] is allowed.
adaptation is via an MPLS label, the mechanisms described in Examples of such traffic types include IP, and MPLS-labeled packets.
Section 3.4.5 are used. Note that the latter case includes TE-LSPs [RFC3209] and LSP based
applications such as PWs, Layer 2 VPNs [RFC4664], and Layer 3 VPNs
[RFC4364]. When the native service adaptation is via an MPLS 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 behaviour of MPLS-TP is the same as the best current
practise 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. inner-most) label
in the label stack that is contiguous between the MPLS-TP server in the label stack that is contiguous between the MPLS-TP LSP and its
layer and the client layer. Note that this best current practice payload, and only one LSE contains the S (Bottom of Stack) bit set to
differs slightly from [RFC3032] which uses the S-bit to identify when 1. Note that this best current practice differs slightly from
MPLS label processing stops and network layer processing starts. [RFC3032] which uses the S-bit to identify when MPLS label processing
stops and network layer processing starts.
The relationship of MPLS-TP to its clients is illustrated in 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 Labelled IP
Services Services Transport Services Services Transport
skipping to change at page 16, line 42 skipping to change at page 17, line 44
An MPLS-TP network consists logically of two layers: the Transport An MPLS-TP network consists logically of two layers: the Transport
Service layer and the Transport Path layer. Service layer and the Transport Path layer.
The Transport Service layer provides the interface between Customer The Transport Service layer provides the interface between Customer
Edge (CE) nodes and the MPLS-TP network. Each packet transmitted by Edge (CE) nodes and the MPLS-TP network. Each packet transmitted by
a CE node for transport over the MPLS-TP network is associated at the a CE node for transport over the MPLS-TP network is associated at the
receiving MPLS-TP Provider Edge (PE) node with a single logical receiving MPLS-TP Provider Edge (PE) node with a single logical
point-to-point connection at the Transport Service layer between this point-to-point connection at the Transport Service layer between this
(ingress) PE and the corresponding (egress) PE to which the peer CE (ingress) PE and the corresponding (egress) PE to which the peer CE
is attached. Such a connection is called an MPLS-TP Transport is attached. Such a connection is called an MPLS-TP Transport
Service Instance, and the set of client packets associated with such Service Instance, and the set of client packets belonging to the
an instance on a particular CE-PE link is called a client flow. native service associated with such an instance on a particular CE-PE
link is called a client flow.
The Transport Path layer provides aggregation of Transport Service The Transport Path layer provides aggregation of Transport Service
Instances over MPLS-TP transport paths (LSPs), as well as aggregation Instances over MPLS-TP transport paths (LSPs), as well as aggregation
of transport paths (via LSP hierarchy). of transport paths (via LSP hierarchy).
Awareness of the Transport Service layer need exist only at PE nodes. Awareness of the Transport Service layer need exist only at PE nodes.
MPLS-TP Provider (P) nodes need have no awareness of this layer. MPLS-TP Provider (P) nodes need have no awareness of this layer.
Both PE and P nodes participate in the Transport Path layer. A PE Both PE and P nodes participate in the Transport Path layer. A PE
terminates (i.e., is an LER with respect to) the transport paths it terminates (i.e., is an LER with respect to) the transport paths it
supports, and is responsible for multiplexing and demultiplexing of supports, and is responsible for multiplexing and demultiplexing of
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 providing a Virtual Private Wire Service (VPWS), Virtual Private
Local Area Network Service (VPLS), Virtual Private Multicast Service
(VPMS), or Internet Protocol Local Area Network Service (IPLS),
pseudowires must be used to carry the client service. VPWS, VLPS,
and IPLS are described in [RFC4664]. VPMS is described in
[I-D.ietf-l2vpn-vpms-frmwk-requirements].
When MPLS-TP is used to provide a transport service for e.g. IP 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 data-link that supports the client flow. traverse the same attachment circuit that supports the client flow.
: User-Network Interface : MPLS-TP : User-Network Interface : MPLS-TP
:<-------------------------------------->: Network <-----> :<-------------------------------------->: Network <----->
: : : :
-:------------- --------------:------------------ -:------------- --------------:------------------
: | | : Transport | : | | : Transport |
: | | Transport : Path | : | | Transport : Path |
: | | Service : Mux/Demux | : | | Service : Mux/Demux |
: | | Control : -- | : | | Control : -- |
: | | Plane : | | Transport| : | | Plane : | | Transport|
: ---------- | Signaling | ---------- : | | Path | : ---------- | Signaling | ---------- : | | Path |
:|Signaling |_|___________|_|Signaling | : | | ---------> :|Signaling |_|___________|_|Signaling | : | | --------->
skipping to change at page 18, line 23 skipping to change at page 19, line 42
: | Data Link | : | | | : | Data Link | : | | |
: | | : -- | : | | : -- |
: | | : Transport | : | | : Transport |
: | | : Service | : | | : Service |
: | | : Data Plane| : | | : Data Plane|
--------------- --------------------------------- --------------- ---------------------------------
Customer Edge Node MPLS-TP Provider Edge Node Customer Edge Node MPLS-TP Provider Edge Node
TSI = Transport Service Instance TSI = Transport Service Instance
Client/Service Traffic Processing Stages Figure 3: MPLS-TP PE Containing a UNI
: --------------From UNI-------> :
--------------From UNI-------> : -------------------------------------------:------------------
-------------------------------------------:------------------ | | Client Traffic Unit : |
| | Client Traffic Unit : | | Link-Layer-Specific | Link Decapsulation : Service Instance |
| Link-Layer-Specific | Link Decapsulation : Service Instance | | Processing | & : Transport |
| Processing | & : Transport | | | Service Instance : Encapsulation |
| | Service Instance : Encapsulation | | | Identification : |
| | Identification : | -------------------------------------------:------------------
-------------------------------------------:------------------ :
: :
: -------------------------------------------:------------------
-------------------------------------------:------------------ | | : Service Instance |
| | : Service Instance | | | : Transport |
| | : Transport | | Link-Layer-Specific | Client Traffic Unit : Decapsulation |
| Link-Layer-Specific | Client Traffic Unit : Decapsulation | | Processing | Link Encapsulation : & |
| Processing | Link Encapsulation : & | | | : Service Instance |
| | : Service Instance | | | : Identification |
| | : Identification | -------------------------------------------:------------------
-------------------------------------------:------------------ <-------------To UNI --------- :
<-------------To UNI --------- :
Figure 3: MPLS-TP PE Containing a UNI Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages
The figure shows the logical processing steps involved in a PE both Figure 4 shows the logical processing steps involved in a PE both for
for traffic flowing from the CE to the MPLS-TP network (left to traffic flowing from the CE to the MPLS-TP network (left to right),
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 preprocessing, if any, is performed. An
example of such preprocessing is the PREP function illustrated in example of such preprocessing is the PREP function illustrated in
Figure 3 of [RFC3985]. Such preprocessing is outside the scope Figure 3 of [RFC3985]. Such preprocessing is outside the scope
of MPLS-TP. 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,
skipping to change at page 19, line 46 skipping to change at page 21, line 19
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 4. 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 : -- |
| | | : Plane |Sig- | Plane : | | | | | | : Plane |Sig- | Plane : | | |
|TP | | : ---------- | naling| ---------- : | | TP| |TP | | : ---------- | naling| ---------- : | | TP|
<--- | | :|Signaling |_|_______|_|Signaling |: | | ---> <--- | | :|Signaling |_|_______|_|Signaling |: | | --->
TSI<-+- | | :|Controller| | | |Controller|: | | | TSI<-+- | | :|Controller| | | |Controller|: | | |
skipping to change at page 20, line 39 skipping to change at page 22, line 41
| | | : |______|_______|______| : | | | | | | : |______|_______|______| : | | |
| | | : | Data | : | | | | | | : | Data | : | | |
| -- : | Link | : -- | | -- : | Link | : -- |
| : | | : | | : | | : |
-------------------------- -------------------------- -------------------------- --------------------------
MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node
TP = Transport Path TP = Transport Path
TSI = Transport Service Instance TSI = Transport Service Instance
Service Traffic Processing Stages 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 : Normalisation | | | 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 |
| | : Normalisation | --------------------------------------------:------------------
--------------------------------------------:------------------ <-------------To NNI --------- :
<-------------To NNI --------- :
Figure 4: MPLS-TP PE Containing an NNI Figure 6: MPLS-TP NNI Service Traffic Processing Stages
The figure 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 preprocessing, if any, is performed. Such
preprocessing is outside the scope of MPLS-TP. preprocessing is outside the scope of MPLS-TP.
skipping to change at page 22, line 18 skipping to change at page 24, line 24
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 normalised 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 and NNI processing This section considers some special cases of UNI processing for
for particular transport service types. These are illustrative, and particular transport service types. These are illustrative, and do
do not preclude other transport service types. not preclude other transport service types.
3.4.3.3.1. Layer 2 Transport Service 3.4.3.3.1. Layer 2 Transport Service
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.
skipping to change at page 23, line 5 skipping to change at page 25, line 9
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 The steps in the reverse direction for PW packets received over the
LSP are analogous. LSP are analogous.
3.4.3.4. 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:
A1. No link-layer-specific processing is performed. 1. No link-layer-specific processing is performed.
A2. 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 (CE1) associated with a Service LSP based on the source MAC address
and the IP protocol version. (CE1) and the IP protocol version.
A3. 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.
A4. 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 The steps in the reverse direction, for packets received over a
tunnel LSP carrying the Service LSP label, are analogous. tunnel LSP carrying the Service LSP label, are analogous.
3.4.4. Pseudowire Adaptation 3.4.4. Pseudowire Adaptation
MPLS-TP uses pseudowires to provide a Virtual Private Wire Service
(VPWS), a Virtual Private Local Area Network Service (VPLS), a
Virtual Private Multicast Service (VPMS) and an Internet Protocol
Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are
described in [RFC4664]. VPMS is described in
[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.
Figure 5 shows the architecture for an MPLS-TP network using single- Figure 7 shows the architecture for an MPLS-TP network using single-
segment PWs. Note that, in this document, the client layer is segment PWs. Note that, in this document, the client layer is
equivalent to the emulated service described in [RFC3985], while the equivalent to the emulated service described in [RFC3985], while the
Transport LSP is equivalent to the Packet Switched Network (PSN) Transport LSP is equivalent to the Packet Switched Network (PSN)
tunnel of [RFC3985]. tunnel of [RFC3985].
|<----------------- Client Layer ------------------->| |<----------------- Client Layer ------------------->|
| | | |
| |<-------- Pseudowire -------->| | | |<-------- Pseudowire -------->| |
| | encapsulated, packet | | | | encapsulated, packet | |
| | transport service | | | | transport service | |
skipping to change at page 24, line 29 skipping to change at page 26, line 39
+-----+ ^ | | |=======/ \========| | | ^ +-----+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | ^ ^ | +----+ ^ +-----+ +----+ | ^
| | 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 5: MPLS-TP Architecture (Single Segment PW) Figure 7: MPLS-TP Architecture (Single Segment PW)
Figure 6 shows the architecture for an MPLS-TP network when multi- Figure 8 shows the architecture for an MPLS-TP network when multi-
segment pseudowires are used. Note that as in the SS-PW case, segment pseudowires are used. Note that as in the SS-PW case,
P-routers may also exist. P-routers may also exist.
|<--------------------- Client Layer ------------------------>| |<--------------------- Client Layer ------------------------>|
| | | |
| Pseudowire encapsulated, | | Pseudowire encapsulated, |
| |<---------- Packet Transport Service ------------->| | | |<---------- Packet Transport Service ------------->| |
| | | | | | | |
| | Transport Transport | | | | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC | | AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
skipping to change at page 25, line 23 skipping to change at page 27, line 23
V | +----+ +-----+ +----+ +----+ | V V | +----+ +-----+ +----+ +----+ | V
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| | | |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| |
|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 6: 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 7. 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 7: 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. Examples are shown in Figure 5 above. Support for interfaces. Support for network layer clients follows the MPLS
network layer clients follows the MPLS architecture for support of architecture for support of network layer protocols as specified in
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 uni-directional or bidirectional point-to-point connection between
two PEs in order to deliver a packet transport service to attached two PEs in order to deliver a packet transport service to attached
customer edge (CE) nodes. For example, a CE may be an IP, MPLS or customer edge (CE) nodes. For example, a CE may be an IP, MPLS or
MPLS-TP node. As shown in Figure 8, 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 Layer1/Layer2
encoding defined for that access link type. It should be noted that encoding defined for that access link type. It should be noted that
the set of network layer protocols includes MPLS and hence MPLS the set of network layer protocols includes MPLS and hence MPLS
encoded packets with an MPLS label stack (the client MPLS stack), may encoded packets with an MPLS label stack (the client MPLS stack), may
appear at the service interface. appear at the service interface.
The following figures illustrate the reference models for network
layer adaptation. The details of these figures are described further
in the following paragraphs.
|<------------- Client Network Layer --------------->| |<------------- Client Network Layer --------------->|
| | | |
| |<----------- Packet --------->| | | |<----------- Packet --------->| |
| | Transport Service | | | | Transport Service | |
| | | | | | | |
| | | | | | | |
| | Transport | | | | Transport | |
| | |<------ LSP ------->| | | | | |<------ LSP ------->| | |
| V V V V | | V V V V |
V AC +----+ +-----+ +----+ AC V V AC +----+ +-----+ +----+ AC V
skipping to change at page 27, line 34 skipping to change at page 29, line 38
+-----+ ^ | | |=======/ \========| | | ^ +-----+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | | ^ ^ | +----+ ^ +-----+ +----+ | | ^
| | 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 8: MPLS-TP Architecture for Network Layer Clients Figure 10: MPLS-TP Architecture for Network Layer Clients
At the ingress service interface the client packets are received. |<--------------------- Client Layer ------------------------>|
The PE pushes one or more labels onto the client packets which are | |
then label switched over the transport network. Correspondingly the | |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | | PE1|===============\ /=====| PE2|==========| PE3| | +---+
| |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ ^ | |
| TE LSP | | TE LSP |
| P-router | |
Native Service (LSR for | Native Service
T'port LSP1) |
|
LSR for Service LSPs
LER for Transport LSPs
Figure 11: MPLS-TP Architecture for Network Layer Adaptation, showing
Service LSP Switching
Client packets are received at the ingress service interface. The PE
pushes one or more labels onto the client packets which are then
label switched over the transport network. Correspondingly the
egress PE pops any labels added by the MPLS-TP networks and transmits egress PE pops any labels added by the MPLS-TP networks and transmits
the packet for delivery to the attached CE via the egress service the packet for delivery to the attached CE via the egress service
interface. interface.
/===================\ /===================\
H OAM PDU H H OAM PDU H
+-------------------+ H-------------------H /===================\ +-------------------+ H-------------------H /===================\
| Client Layer | H GACh H H OAM PDU H | Client Layer | H GACh H H OAM PDU H
/===================\ H-------------------H H-------------------H /===================\ H-------------------H H-------------------H
H Encap Label H H GAL (S=1) H H GACh H H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H 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 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 9: MPLS-TP Label Stack for IP and LSP Clients Figure 12: MPLS-TP Label Stack for IP and LSP Clients
In this figure the Transport Service Layer [RFC5654] is identified by In the figures above, the Transport Service Layer [RFC5654] is
the Service LSP (SvcLSP) demultiplexer (Demux) label and the identified by the Service LSP (SvcLSP) demultiplexer (Demux) label
Transport Path Layer [RFC5654] is identified by the Transport (Trans) and the Transport Path Layer [RFC5654] is identified by the Transport
LSP Demux Label. Note that the functions of the Encapsulation label (Trans) LSP Demux Label. Note that the functions of the
(Encap Label) and the Service Label (SvcLSP Demux) shown above may Encapsulation label (Encap Label) and the Service Label (SvcLSP
alternatively be represented by a single label stack entry. Note Demux) shown above may alternatively be represented by a single label
that the S-bit is always zero when the client layer is MPLS-labelled. 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
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 9 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 must be carried over a single service LSP, a unique label stack entry needs
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 9. "Encapsulation Labels", one of which is shown in Figure 12.
Encapsulation Label may be either configured or signaled. Encapsulation Label may be either configured or signaled.
Both an Encapsulation Label and a Service Label should be present in Both an Encapsulation Label and a Service Label should be present in
the label stack when a particular packet transport service is the label stack when a particular packet transport service is
supporting more than one network layer protocol payload type. For supporting more than one network layer protocol payload type. For
example, if both IP and MPLS are to be carried, as shown in Figure 8, example, if both IP and MPLS are to be carried, then two
then two Encapsulation Labels are mapped on to a common Service Encapsulation Labels are mapped on to a common Service Label.
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.
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 9. 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 must be used to ensure At each service interface, Layer 2 addressing needs to be used to
the proper delivery of a network layer packet to the adjacent node. ensure the proper delivery of a network layer packet to the adjacent
This is typically only an issue for LAN media technologies (e.g., node. This is typically only an issue for LAN media technologies
Ethernet) which have Media Access Control (MAC) addresses. In cases (e.g., Ethernet) which have Media Access Control (MAC) addresses. In
where a MAC address is needed, the sending node must set 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 an
address that ensures delivery to the PE, and the PE sets the address that ensures delivery to the PE, and the PE sets the
destination MAC address to an address that ensures delivery to the destination MAC address to an address that ensures delivery to the
CE. The specific address used is technology type specific and is not CE. The specific address used is technology type specific and is not
specified in this document. In some technologies the MAC address specified in this document. In some technologies the MAC address
will need to be configured. 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
skipping to change at page 30, line 18 skipping to change at page 33, line 18
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 type of
sets of identifiers: Those that are compatible with IP, and another sets of identifiers: Those that are compatible with IP, and another
set that is compatibple with ITU-T transport-based operations. The set that is 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 [I-D.ietf-mpls-tp-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 Signaling Communication Channel (SCC), or a channel used for a
Protection State Coordination (PSC) data. 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]). [I-D.ietf-pwe3-vccv-bfd]).
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
[I-D.ietf-pwe3-vccv-bfd], or IP encapsulation for MPLS BFD [I-D.ietf-pwe3-vccv-bfd], or IP encapsulation for MPLS BFD
[I-D.ietf-bfd-mpls]. [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, PSC, SCC, MCC (FCAPS) functions by carrying packets related to OAM, a protocol used
or other packet types in-band over LSPs, PWs or sections. The G-ACh to coodinate path protection state, SCC, MCC or other packet types
is defined in [RFC5586] and is similar to the Pseudowire Associated in-band over LSPs, PWs or sections. The G-ACh is defined in
Channel [RFC4385], which is used to carry OAM packets over [RFC5586] and is similar to the Pseudowire Associated Channel
pseudowires. The G-ACh is indicated by an Associated Channel Header [RFC4385], which is used to carry OAM packets over pseudowires. The
(ACH), similar to the Pseudowire VCCV control word; this header is G-ACh is indicated by an Associated Channel Header (ACH), similar to
present for all sections, LSPs and PWs making use of FCAPS functions the Pseudowire VCCV control word; this header is present for all
supported by the G-ACh. sections, LSPs and PWs making use of FCAPS functions supported by the
G-ACh.
The G-ACh must only be used for channels that are an adjunct to the As specified in [RFC5586], the G-ACh must only be used for channels
data service. Examples of these are OAM, PSC, MCC and SCC, but the that are an adjunct to the data service. Examples of these are OAM,
use is not restricted to these services. The G-ACh must not be used a protocol used to coodinate path protection state, MCC and SCC, but
to carry additional data for use in the forwarding path, i.e. it must the use is not restricted to these services. The G-ACh must not to
not be used as an alternative to a PW control word, or to define a PW be used to carry additional data for use in the forwarding path, i.e.
type. it must not be used as an alternative to a PW control word, or to
define a PW type.
At the server layer, bandwidth and QoS commitments apply to the gross At the server layer, bandwidth and QoS commitments apply to the gross
traffic on the LSP, PW or section. Since the G-ACh traffic is traffic on the LSP, PW or section. Since the G-ACh traffic is
indistinguishable from the user data traffic, protocols using the indistinguishable from the user data traffic, protocols using the
G-ACh must take into consideration the impact they have on the user G-ACh need to take into consideration the impact they have on the
data with which they are sharing resources. Conversely, capacity user data with which they are sharing resources. Conversely,
must be made available for important G-ACh uses such as protection capacity needs to be made available for important G-ACh uses such as
and OAM. In addition, protocols using the G-ACh must conform to the protection and OAM. In addition, the security and congestion
security and congestion considerations described in [RFC5586]. considerations described in [RFC5586] apply to protocols using the
G-ACh.
Figure 10 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
the reference model for VCCV shown in Figure 2 of [RFC5085]. the reference model for VCCV shown in Figure 2 of [RFC5085].
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < FCAPS > | Payload | | Payload | < FCAPS > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
| Demux / | < ACH for PW > | Demux / | | Demux / | < ACH for PW > | Demux / |
|Discriminator| |Discriminator| |Discriminator| |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
| PW | < PW > | PW | | PW | < PW > | PW |
skipping to change at page 31, line 48 skipping to change at page 35, line 5
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS-TP Network |---+ +--------| MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 10: 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 11 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 |
+-------------+ +-------------+ +-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator| |Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer| |Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < LSP > | PSN | | PSN | < LSP > | PSN |
skipping to change at page 32, line 34 skipping to change at page 35, line 36
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS-TP Network |---+ +--------| MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 11: 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 must be 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 datapath. 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, BFD
and VCCV, may be used. Since MPLS-TP must be able to operate in and VCCV, may be used. Since MPLS-TP can operate in environments
environments where IP is not used in the forwarding plane, the where IP is not used in the forwarding plane, the default mechanism
default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is for OAM demultiplexing in MPLS-TP LSPs and PWs is the Generic
the Generic Associated Channel (Section 3.6). Forwarding based on IP Associated Channel (Section 3.6). Forwarding based on IP addresses
addresses for user or OAM packets is not required for MPLS-TP. for user or OAM packets is not required for MPLS-TP.
[RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined
alert mechanisms that enable an MPLS LSR to identify and process MPLS alert mechanisms that enable an MPLS LSR to identify and process MPLS
OAM packets when the OAM packets are encapsulated in an IP header. OAM packets when the OAM packets are encapsulated in an IP header.
These alert mechanisms are based on TTL expiration and/or use an IP These alert mechanisms are based on TTL expiration and/or use an IP
destination address in the range 127/8 for IPv4 and that same range destination address in the range 127/8 for IPv4 and that same range
embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the
OAM packets are encapsulated in an IP header, these mechanisms are OAM packets are encapsulated in an IP header, these mechanisms are
the default mechanisms for MPLS networks in general for identifying the default mechanisms for MPLS networks in general for identifying
MPLS OAM packets, although the mechanisms defined in [RFC5586] can MPLS OAM packets, although the mechanisms defined in [RFC5586] can
also be used. MPLS-TP must be able to operate in environments where also be used. MPLS-TP is able to operate in environments where IP
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 [I-D.ietf-mpls-tp-oam-requirements] that a set of
OAM capabilities is available to perform fault management (e.g. fault OAM capabilities is available to perform fault management (e.g. fault
detection and localisation) and performance monitoring (e.g. packet detection and localisation) and performance monitoring (e.g. packet
skipping to change at page 33, line 51 skipping to change at page 37, line 5
Maintenance Entity (ME) can be viewed as the association of two Maintenance Entity (ME) can be viewed as the association of two
Maintenance Entity Group End Points (MEPs). A Maintenance Entity Maintenance Entity Group End Points (MEPs). A Maintenance Entity
Group (MEG) is a collection of one or more MEs that belongs to the Group (MEG) is a collection of one or more MEs that belongs to the
same transport path and that are maintained and monitored as a group. same transport path and that are maintained and monitored as a group.
The MEPs that form an ME limit the OAM responsibilities of an OAM The MEPs that form an ME limit the OAM responsibilities of an OAM
flow to within the domain of a transport path or segment, in the flow to within the domain of a transport path or segment, in the
specific layer network that is being monitored and managed. specific layer network that is 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). MEPs are capable of sourcing and sinking OAM flows,
while MIPs can both react to OAM flows received from within a MEG. 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
Intermediate nodes can also originate notifications to the MEPs as a conditions.
result of specific network conditions.
A G-ACh packet may be directed to an individual MIP along the path of A G-ACh packet may be directed to an individual MIP along the path of
an LSP or MS-PW by setting the appropriate TTL in the label for the an LSP or MS-PW by setting the appropriate TTL in the label stack
G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and entry for the G-ACh packet, as per the traceroute mode of LSP Ping
the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw]. Note that this [RFC4379] and the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw].
works when the location of MIPs along the LSP or PW path is known by Note that this works when the location of MIPs along the LSP or PW
the MEP. There may be circumstances where this is not the case, e.g. path is known by the MEP. There may be circumstances where this is
following restoration using a facility bypass LSP. In these cases, not the case, e.g. following restoration using a facility bypass LSP.
tools to trace the path of the LSP may be used to determine the In these cases, tools to trace the path of the LSP may be used to
appropriate setting for the TTL to reach a specific MIP. determine the appropriate setting for the TTL to reach a specific
MIP.
Within an LSR or PE, MEPs and MIPs can only be placed where MPLS 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 of the endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the
LSP or PW label. 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 that Y is an intermediate LSR along the LSP. In the (i.e. LERs) and Y is an intermediate LSR along the LSP. Note that U
unidirectional case, U is the upstream LER and D is the downstream is the upstream LER and D is the downstream LER with respect to a
LER with respect to the LSP. This reference model is shown in particular direction of an LSP. This reference model is shown in
Figure 12. Figure 15.
LSP LSP LSP LSP
U ========= Y ========= D U ========= Y ========= D
LER LSR LER LER LSR LER
---------> Direction of pcket flow ---------> Direction of user plane traffic flow
Figure 12: 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 Packet transmission from D to U Case 1 Return path packet transmission from D to U
Case 2 Packet transmission from Y to U Case 2 Return path packet transmission from Y to U
Case 3 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, and that packet Note that a return path may not always exist (or may exist but be
transmission in one or more of the above cases may not be possible. disabled), and that packet transmission in one or more of the above
In general the existence and nature of return paths for MPLS-TP LSPs cases may not be possible. In general the existence and nature of
is determined by operational provisioning. return paths for MPLS-TP LSPs is determined by operational
provisioning.
3.8.1. Return Path Types 3.8.1. Return Path Types
There are two types of return path that may be used for the delivery There are two types of return path that may be used for the delivery
of traffic from a downstream node D to an upstream node U. Either: of traffic from a downstream node D to an upstream node U. Either:
a. 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
skipping to change at page 35, line 44 skipping to change at page 39, line 7
case packets would be forwarded as usual to a destination IP address case packets would be forwarded as usual to a destination IP address
associated with U. In an MPLS-TP network that is also an IP/MPLS associated with U. In an MPLS-TP network that is also an IP/MPLS
network, such a forwarding path may traverse the same physical links network, such a forwarding path may traverse the same physical links
or logical transport paths used by MPLS-TP. An out-of-band return or logical transport paths used by MPLS-TP. An out-of-band return
path may also be indirect, via a distinct Data Communication Network path may also be indirect, via a distinct Data Communication Network
(DCN) (provided, for example, by the method specified in [RFC5718]); (DCN) (provided, for example, by the method specified in [RFC5718]);
or it may be via one or more other MPLS-TP LSPs. or it may be via one or more other MPLS-TP LSPs.
3.8.2. Point-to-Point Unidirectional LSPs 3.8.2. Point-to-Point Unidirectional LSPs
Case 1 In this situation, either an in-band or out-of-band return Case 1 If an in-band return path is required to deliver traffic from
path may be used to deliver traffic from D back to U. D back to U, it is recommended for reasons of operational
simplicity that point-to-point unidirectional LSPs be
provisioned as associated bidirectional LSPs (which may also
be co-routed) whenever return traffic from D to U is
required. Note that the two directions of such an LSP may
have differing bandwidth allocations and QoS characteristics.
The discussion for such LSPs below applies.
It is recommended for reasons of operational simplicity that As an alternative, an out-of-band return path may be used.
point-to-point unidirectional LSPs be provisioned as
associated bidirectional LSPs (which may also be co-routed)
whenever return traffic from D to U is required. Note that
the two directions of such an LSP may have differing
bandwidth allocations and QoS characteristics. In the in-
band case there is in essence an associated bidirectional LSP
between U and D, and the discussion for such LSPs below
applies.
Case 2 In this case only the out-of-band return path option is Case 2 In this case only the out-of-band return path option is
available. However, an additional out-of-band possibility is available. However, an additional out-of-band possibility is
worthy of note here: if 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 recognises the need for and performs this forwarding
operation is protocol-specific. operation is protocol-specific.
Case 3 In this case only the out-of-band return path option is Case 3 In this case only the out-of-band return path option is
skipping to change at page 37, line 5 skipping to change at page 40, line 16
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 13 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.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | | |
| Network Management System and/or | | Network Management System and/or |
| | | |
| Control Plane for Point to Point Connections | | Control Plane for Point-to-Point Connections |
| | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | | | | | | | | | | |
.............|.....|... ....|.....|.... ....|.....|............ .............|.....|... ....|.....|.... ....|.....|............
: +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | :
: |OAM| | : : |OAM| | : : |OAM| | : : |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | : : | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/ \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+-- --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
skipping to change at page 37, line 36 skipping to change at page 40, line 47
''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' ''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: Note:
1) NMS may be centralised or distributed. Control plane is 1) NMS may be centralised or distributed. Control plane is
distributed. distributed.
2) 'Edge' functions refers to those functions present at 2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g. NSP or classification. the edge of a PSN domain, e.g. NSP or classification.
3) The control plane may be transported over the server 3) The control plane may be transported over the server
layer, an LSP or a G-ACh. layer, an LSP or a G-ACh.
Figure 13: 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 Networks (ASON) architecture [G.8080]. MPLS-TP uses
Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473]) Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473])
for LSPs and Targeted LDP (T-LDP) [RFC4447] for LSPs and Targeted LDP (T-LDP) [RFC4447]
[I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] for [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] for
pseudowires. pseudowires.
MPLS-TP requires that any control plane traffic be capable of being MPLS-TP requires that any control plane traffic be capable of being
skipping to change at page 38, line 14 skipping to change at page 41, line 25
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, must satisfy the MPLS-TP control plane control planes, collectively, need to satisfy the MPLS-TP control
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 [I-D.ietf-ccamp-mpls-tp-cp-framework]. When client services are
provided directly via LSPs, all requirements must be satisfied by the provided directly via LSPs, all requirements must be satisfied by the
LSP control plane. When client services are provided via PWs, the PW LSP control plane. When client services are provided via PWs, the PW
and LSP control planes operate in combination and some functions may and LSP control planes operate in combination and some functions may
be satisfied via the PW control plane while others are provided to be satisfied via the PW control plane while others are provided to
PWs by the LSP control plane. PWs by the LSP control plane.
Note that if MPLS-TP is being used in a multi-layer network, a number Note that if MPLS-TP is being used in a multi-layer network, a number
of control protocol types and instances may be used. This is of control protocol types and instances may be used. This is
consistent with the MPLS architecture which permits each label in the consistent with the MPLS architecture which permits each label in the
skipping to change at page 39, line 24 skipping to change at page 42, line 34
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. Interdomain Connectivity
A number of methods exist to support inter-domain operation of A number of methods exist to support inter-domain operation of
MPLS-TP, including the data plane, OAM and configuration aspects, for MPLS-TP, including the data plane, OAM and configuration aspects, for
example: example:
o Inter-domain TE LSPs [RFC4216] 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
skipping to change at page 39, line 47 skipping to change at page 43, line 9
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 independent for a specific PW or LSP instance. Thus it should be is independent for a specific PW or LSP instance. Thus it should be
possible for a PW to be statically configured, while the LSP possible for a PW to be statically configured, while the LSP
supporting it is set up by a dynamic control plane. When static supporting it is set up by a dynamic control plane. When static
configuration mechanisms are used, care must be taken to ensure that configuration mechanisms are used, care must be taken to ensure that
loops are not created. loops are not created. Note that the path of an LSP or PW may be
dynamically computed, while the LSP or PW itself is established
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]. [I-D.ietf-mpls-tp-survive-fwk].
A wide variety of resiliency schemes have been developed to meet the A wide variety of resiliency schemes have been developed to meet the
various network and service survivability objectives. For example, various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels ([RFC4090]), while pseudowire repair using back-up LSP tunnels ([RFC4090]), while pseudowire
skipping to change at page 40, line 43 skipping to change at page 44, line 9
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 Optimised for linear, ring or meshed topologies.
o Use OAM mechanisms to detect and localise network faults or o Use OAM mechanisms to detect and localise network faults or
service degenerations. service degenerations.
o Include protection mechanisms to coordinate and trigger protection o Include protection mechanisms to coordinate and trigger protection
switching actions in the absence of a dynamic control plane. This switching actions in the absence of a dynamic control plane.
is known as a Protection State Coordination (PSC) mechanism.
o MPLS-TP recovery schemes are applicable to all levels in the o MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e. 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 behaviour.
3.13. Path Segment Tunnels 3.13. Sub-Path Maintenance
In order to monitor, protect and manage a portion of an LSP, a new In order to monitor, protect and manage a portion (i.e. segment or
architectural element is defined called the Path Segment Tunnel concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
(PST). A PST is a hierarchical LSP [RFC3031] which is defined and instantiated. A hierarchical LSP is instantiated for this purpose is
used for the purposes of OAM monitoring, protection or management of called a Sub-Path Maintenance Element (SPME). Note that by
LSP segments or concatenated LSP segments. definition an SPME does not carry user plane traffic as a direct
clident.
A PST 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. OAM messages can be needs to be monitored, protected or managed. The SPME forms an
initiated at the edge of the PST and sent to the peer edge of the PST MPLS-TP Section [I-D.ietf-mpls-tp-data-plane] that carries the
or to a MIP along the PST by setting the TTL value at the PST level original LSP over this portion of a network as a client. OAM
accordingly. A P router only pushes or pops a label if it is at the messages can be initiated at the edge of the SPME and sent to the
end of a PST. In this mode, it is an LER for the PST. peer edge of the SPME or to a MIP along the SPME by setting the TTL
value of the LSE at the corresponding hierarchical LSP level. A P
router only pushes or pops a label if it is at the end of a SPME. In
this mode, it is an LER for the SPME.
For example in Figure 14, two PSTs 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 PST is defined between LER2 and LER3, and a second PST segments. One SPME is defined between LER2 and LER3, and a second
is set up between LER4 and LER5. Each of these PSTs 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.
======================== End to End 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|
|======= PST =========| |======= PST =========| |====== SPME =========| |====== SPME =========|
(Carrier 1) (Carrier 2) (Carrier 1) (Carrier 2)
Note: LER2, LER3, LER4 and LER5 are with respect to the PST Note 1: LER2, LER3, LER4 and LER5 are with respect to the SPME
Note 2: The LSP terminates in LERs outside of Carrier 1 and
Carrier 2, for example LER1 and LER6.
Figure 14: PSTs 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 PST by means of label stacking as messages) is tunneled within the hierarchical LSP by means of label
defined in [RFC3031]. stacking as defined in [RFC3031].
The mapping between an LSP and a PST can be 1:1, in which case it is The mapping between an LSP and a 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 15 shows a PST which 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.
[I-D.ietf-mpls-tp-oam-framework] provides further considerations on
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 + +-----+ |
| |============= PST ==============| | | |============ SPME ==============| |
|LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd| |LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
Figure 15: PST for a Set of Concatenated LSP Segments Figure 18: SPME for a Set of Concatenated LSP Segments
PSTs 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 PST on existing LSPs in- supported by MPLS allow the creation of a SPME on existing LSPs in-
service without traffic disruption. A PST can be defined service without traffic disruption, as described in
corresponding to one or more end-to-end tunneled LSPs. New end-to- [I-D.ietf-mpls-tp-survive-fwk]. A SPME can be defined corresponding
end LSPs which are tunneled within the PST can be set up. Traffic of to one or more end-to-end LSPs. New end-to-end LSPs which are
the existing LSPs is switched over to the new end-to-end tunneled tunneled within the SPME can be set up, which may require
LSPs. The old end-to-end LSPs can then be torn down. coordination across administrative boundaries. Traffic of the
existing LSPs is switched over to the new end-to-end tunneled LSPs.
3.14. Pseudowire Segment Tunnels 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 path segment tunnels on pseudowires. above, can be used to implement sub-path maintenance entities on
pseudowires.
3.15. 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 [I-D.ietf-mpls-tp-nm-framework] and
[I-D.ietf-mpls-tp-nm-req]. These derive from the generic [I-D.ietf-mpls-tp-nm-req]. These derive from the generic
specifications described in ITU-T G.7710/Y.1701 [G.7710] for specifications described in ITU-T G.7710/Y.1701 [G.7710] for
transport technologies. 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
[I-D.ietf-mpls-tp-oam-requirements] and expand on those requirements [I-D.ietf-mpls-tp-oam-requirements] and expand on those requirements
to cover the modifications necessary for fault, configuration, to cover the modifications necessary for fault, configuration,
performance, and security in a transport network. performance, and security in a transport network.
skipping to change at page 43, line 16 skipping to change at page 46, line 46
logical operations channel between NEs for transferring Management logical operations channel between NEs for transferring Management
information. For the management interface from a management system information. For the management interface from a management system
to an MPLS-TP NE, there is no restriction on which management to an MPLS-TP NE, there is no restriction on which management
protocol is used. The Network Management System (NMS) is used to protocol is used. The Network Management System (NMS) is used to
provision and manage an end-to-end connection across a network where provision and manage an end-to-end connection across a network where
some segments are created/managed by, for example, Netconf [RFC4741] some segments are created/managed by, for example, Netconf [RFC4741]
or SNMP [RFC3411] and other segments by XML or CORBA interfaces. 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. An MPLS-TP
NE is not required to offer more than one standard management NE is not required to offer more than one standard management
interface. In MPLS-TP, the EMF must be capable of statically interface. 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 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. associated MEPs and MIPs, as per Section 3.11.
Fault Management (FM) functions within the EMF of an MPLS-TP NE Fault Management (FM) functions within the EMF of an MPLS-TP NE
enable the supervision, detection, validation, isolation, correction, enable the supervision, detection, validation, isolation, correction,
and alarm handling of abnormal conditions in the MPLS-TP network and and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. FM must provide for the supervision of transmission its environment. FM needs to provide for the supervision of
(such as continuity, connectivity, etc.), software processing, transmission (such as continuity, connectivity, etc.), software
hardware, and environment. Alarm handling includes alarm severity processing, hardware, and environment. Alarm handling includes alarm
assignment, alarm suppression/aggregation/correlation, alarm severity assignment, alarm suppression/aggregation/correlation, alarm
reporting control, and alarm reporting. reporting control, and alarm reporting.
Configuration Management (CM) provides functions to control, Configuration Management (CM) provides functions to control,
identify, collect data from, and provide data to MPLS-TP NEs. In identify, collect data from, and provide data to MPLS-TP NEs. In
addition to general configuration for hardware, software protection addition to general configuration for hardware, software protection
switching, alarm reporting control, and date/time setting, the EMF of switching, alarm reporting control, and date/time setting, the EMF of
the MPLS-TP NE also supports the configuration of maintenance entity the MPLS-TP NE also supports the configuration of maintenance entity
identifiers (such as 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
skipping to change at page 44, line 10 skipping to change at page 47, line 39
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 pro-actively.
4. Security Considerations 4. Security Considerations
The introduction of MPLS-TP into transport networks means that the The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS and PWE3 apply to security considerations applicable to both MPLS and PWE3 apply to
those transport networks. Furthermore, when general MPLS networks those transport networks. When an MPLS function is included in the
MPLS transport profile, the security considerations pertinent to that
function apply to MPLS-TP. Furthermore, when general MPLS networks
that utilise functionality outside of the strict MPLS Transport that utilise functionality outside of the strict MPLS Transport
Profile are used to support packet transport services, the security Profile are used to support packet transport services, the security
considerations of that additional functionality also apply. considerations of that additional functionality also apply.
For pseudowires, the security considerations of [RFC3985] and For pseudowires, the security considerations of [RFC3985] and
[RFC5659] apply. [RFC5659] apply.
Each MPLS-TP solution must specify the additional security MPLS-TP nodes that implement the G-ACh create a Control Channel (CC)
considerations that apply. This is discussed further in associated with a pseudowire, LSP or section. This control channel
[I-D.fang-mpls-tp-security-framework]. can be signaled or statically configured. Over this control channel,
control channel messages related to network maintenance functions
such as OAM, signaling or network management are sent. Therefore,
three different areas are of concern from a security standpoint.
The first area of concern relates to control plane parameter and
status message attacks, that is, attacks that concern the signaling
of G-ACh capabilities. MPLS-TP Control Plane security is discussed
in [I-D.ietf-mpls-mpls-and-gmpls-security-framework].
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
mechanisms are subject to additional data-plane denial-of- service
attacks as follows:
An intruder could intercept or inject G-ACh packets effectively
disrupting the protocols carried over the G-ACh.
An intruder could deliberately flood a peer MPLS-TP node with
G-ACh messages to deny services to others.
A misconfigured or misbehaving device could inadvertently flood a
peer MPLS-TP node with G-ACh messages which could result in denial
of services. In particular, if a node has either implicitly or
explicitly indicated that it cannot support one or all of the
types of G-ACh protocol, but is sent those messages in sufficient
quantity, it could result in a denial of service.
To protect against these potential (deliberate or unintentional)
attacks, multiple mitigation techniques can be employed:
G-ACh message throttling mechanisms can be used, especially in
distributed implementations which have a centralized control-plane
processor with various line cards attached by some control-plane
data path. In these architectures, G-ACh messages may be
processed on the central processor after being forwarded there by
the receiving line card. In this case, the path between the line
card and the control processor may become saturated if appropriate
G-ACh traffic throttling is not employed, which could lead to a
complete denial of service to users of the particular line card.
Such filtering is also useful for preventing the processing of
unwanted G-ACh messages, such as those which are sent on unwanted
(and perhaps unadvertised) control channel types.
A third and last area of concern relates to the processing of the
actual contents of G-ACh messages. It is necessary that the
definition of the protocols using these messages carried over a G-ACh
include appropriate security measures.
Additional security considerations apply to each MPLS-TP solution.
These are discussed further in [I-D.fang-mpls-tp-security-framework].
The security considerations in The security considerations in
[I-D.ietf-mpls-mpls-and-gmpls-security-framework] 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.
skipping to change at page 49, line 50 skipping to change at page 54, line 38
framework-09 (work framework-09 (work
in progress), in progress),
March 2010. March 2010.
[I-D.ietf-mpls-tp-data-plane] Frost, D., Bryant, [I-D.ietf-mpls-tp-data-plane] Frost, D., Bryant,
S., and M. Bocci, S., and M. Bocci,
"MPLS Transport "MPLS Transport
Profile Data Plane Profile Data Plane
Architecture", dra Architecture", dra
ft-ietf-mpls-tp- ft-ietf-mpls-tp-
data-plane-01 data-plane-02
(work in (work in
progress), progress),
March 2010. April 2010.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G.
Swallow, "MPLS-TP Swallow, "MPLS-TP
Identifiers", draf Identifiers", draf
t-ietf-mpls-tp- t-ietf-mpls-tp-
identifiers-01 identifiers-01
(work in (work in
progress), progress),
March 2010. March 2010.
skipping to change at page 50, line 36 skipping to change at page 55, line 25
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and
K. Lam, "MPLS TP K. Lam, "MPLS TP
Network Management Network Management
Requirements", dra Requirements", dra
ft-ietf-mpls-tp- ft-ietf-mpls-tp-
nm-req-06 (work in nm-req-06 (work in
progress), progress),
October 2009. October 2009.
[I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi,
I., and B. Niven- I., Niven-Jenkins,
Jenkins, "MPLS-TP B., Fulignoli, A.,
OAM Framework", dr Hernandez-
aft-ietf-mpls-tp- Valencia, E.,
oam-framework-05 Levrau, L., Mohan,
(work in D., Sestito, V.,
progress), Sprecher, N.,
March 2010. 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 [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M. and
D. Ward, D. Ward,
"Requirements for "Requirements for
OAM in MPLS OAM in MPLS
Transport Transport
Networks", draft- Networks", draft-
ietf-mpls-tp-oam- ietf-mpls-tp-oam-
requirements-06 requirements-06
(work in (work in
progress), progress),
March 2010. March 2010.
[I-D.ietf-mpls-tp-rosetta-stone] Helvoort, H.,
Andersson, L., and
N. Sprecher, "A
Thesaurus for the
Terminology used
in Multiprotocol
Label Switching
Transport Profile
(MPLS-TP) drafts/
RFCs and ITU-T's
Transport Network
Recommendations",
draft-ietf-mpls-
tp-rosetta-stone-
01 (work in
progress),
October 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and
A. Farrel, A. Farrel,
"Multiprotocol "Multiprotocol
Label Switching Label Switching
Transport Profile Transport Profile
Survivability Survivability
Framework", draft- Framework", draft-
ietf-mpls-tp- ietf-mpls-tp-
survive-fwk-04 survive-fwk-05
(work in (work in
progress), progress),
March 2010. April 2010.
[I-D.ietf-opsawg-mpls-tp-oam-def] Andersson, L.,
Helvoort, H.,
Bonica, R.,
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., [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L.,
Bocci, M., Balus, Bocci, M., Balus,
F., Bitar, N., F., Bitar, N.,
Shah, H., Shah, H.,
Aissaoui, M., Aissaoui, M.,
Rusmisel, J., Rusmisel, J.,
Serbest, Y., Serbest, Y.,
Malis, A., Metz, Malis, A., Metz,
C., McDysan, D., C., McDysan, D.,
skipping to change at page 52, line 10 skipping to change at page 57, line 39
Place, "Pseudowire Place, "Pseudowire
(PW) Redundancy", (PW) Redundancy",
draft-ietf-pwe3- draft-ietf-pwe3-
redundancy-02 redundancy-02
(work in (work in
progress), progress),
October 2009. October 2009.
[I-D.ietf-pwe3-segmented-pw] Martini, L., [I-D.ietf-pwe3-segmented-pw] Martini, L.,
Nadeau, T., Metz, Nadeau, T., Metz,
C., Duckett, M., C., Bocci, M.,
Bocci, M., Balus, Aissaoui, M.,
F., and M. Balus, F., and M.
Aissaoui, Duckett,
"Segmented "Segmented
Pseudowire", draft Pseudowire", draft
-ietf-pwe3- -ietf-pwe3-
segmented-pw-13 segmented-pw-14
(work in (work in
progress), progress),
August 2009. April 2010.
[I-D.ietf-pwe3-vccv-bfd] Nadeau, T. and C. [I-D.ietf-pwe3-vccv-bfd] Nadeau, T. and C.
Pignataro, Pignataro,
"Bidirectional "Bidirectional
Forwarding Forwarding
Detection (BFD) Detection (BFD)
for the Pseudowire for the Pseudowire
Virtual Circuit Virtual Circuit
Connectivity Connectivity
Verification Verification
(VCCV)", draft- (VCCV)", draft-
ietf-pwe3-vccv- ietf-pwe3-vccv-
skipping to change at page 53, line 41 skipping to change at page 59, line 22
[RFC3945] Mannie, E., [RFC3945] Mannie, E.,
"Generalized "Generalized
Multi-Protocol Multi-Protocol
Label Switching Label Switching
(GMPLS) (GMPLS)
Architecture", Architecture",
RFC 3945, RFC 3945,
October 2004. October 2004.
[RFC4216] Zhang, R. and J.
Vasseur, "MPLS
Inter-Autonomous
System (AS)
Traffic
Engineering (TE)
Requirements",
RFC 4216,
November 2005.
[RFC4364] Rosen, E. and Y. [RFC4364] Rosen, E. and Y.
Rekhter, "BGP/MPLS Rekhter, "BGP/MPLS
IP Virtual Private IP Virtual Private
Networks (VPNs)", Networks (VPNs)",
RFC 4364, RFC 4364,
February 2006. February 2006.
[RFC4377] Nadeau, T., [RFC4377] Nadeau, T.,
Morrow, M., Morrow, M.,
Swallow, G., Swallow, G.,
Allan, D., and S. Allan, D., and S.
skipping to change at page 54, line 44 skipping to change at page 60, line 14
[RFC4664] Andersson, L. and [RFC4664] Andersson, L. and
E. Rosen, E. Rosen,
"Framework for "Framework for
Layer 2 Virtual Layer 2 Virtual
Private Networks Private Networks
(L2VPNs)", (L2VPNs)",
RFC 4664, RFC 4664,
September 2006. September 2006.
[RFC4726] Farrel, A.,
Vasseur, J., and
A. Ayyangar, "A
Framework for
Inter-Domain
Multiprotocol
Label Switching
Traffic
Engineering",
RFC 4726,
November 2006.
[RFC4741] Enns, R., "NETCONF [RFC4741] Enns, R., "NETCONF
Configuration Configuration
Protocol", Protocol",
RFC 4741, RFC 4741,
December 2006. December 2006.
[RFC5150] Ayyangar, A., [RFC5150] Ayyangar, A.,
Kompella, K., Kompella, K.,
Vasseur, JP., and Vasseur, JP., and
A. Farrel, "Label A. Farrel, "Label
skipping to change at page 56, line 27 skipping to change at page 62, line 9
[RFC5718] Beller, D. and A. [RFC5718] Beller, D. and A.
Farrel, "An In- Farrel, "An In-
Band Data Band Data
Communication Communication
Network For the Network For the
MPLS Transport MPLS Transport
Profile", Profile",
RFC 5718, RFC 5718,
January 2010. January 2010.
[X.200] "ITU-T
Recommendation
X.200,
"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: Phone:
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
 End of changes. 161 change blocks. 
433 lines changed or deleted 686 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/