draft-ietf-mpls-tp-framework-01.txt   draft-ietf-mpls-tp-framework-02.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track S. Bryant, Ed. Intended status: Standards Track S. Bryant, Ed.
Expires: December 31, 2009 Cisco Systems Expires: January 11, 2010 Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
June 29, 2009 July 10, 2009
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-01 draft-ietf-mpls-tp-framework-02
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2009. This Internet-Draft will expire on January 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies an archiectectural framework for the This document specifies an architectural framework for the
application of MPLS in transport networks. It describes a profile of application of MPLS in transport networks. It describes a profile of
MPLS that enables operational models typical in transport networks MPLS that enables operational models typical in transport networks ,
networks, while providing additional OAM, survivability and other while providing additional OAM, survivability and other maintenance
maintenance functions not currently supported by MPLS. functions not currently supported by MPLS.
Requirements Language Requirements Language
Although this document is not a protocol specification, the key words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document document are to be interpreted as described in RFC2119 [RFC2119].
are to be interpreted as described in RFC2119 [RFC2119] and are to be
interpreted as instructions to the protocol designers producing Although this document is not a protocol specification, these key
solutions that satisfy the architectural concepts set out in this words are to be interpreted as instructions to the protocol designers
document.. producing solutions that satisfy the architectural concepts set out
in this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Background . . . . . . . . . . . . . . . . 3 1.1. Motivation and Background . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Introduction to Requirements . . . . . . . . . . . . . . . . . 6 2. Introduction to Requirements . . . . . . . . . . . . . . . . . 6
3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 7 3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 7
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 7 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 7
3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. MPLS-TP Forwarding Domain . . . . . . . . . . . . . . . . 10 3.3. MPLS-TP Forwarding Domain . . . . . . . . . . . . . . . . 10
3.4. MPLS-TP Transport Domain . . . . . . . . . . . . . . . . . 11 3.4. MPLS-TP LSP Clients . . . . . . . . . . . . . . . . . . . 12
3.5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Network Layer Transport Service . . . . . . . . . . . 12
3.6. Operations, Administration and Maintenance (OAM) . . . . . 13 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 16
3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 17 3.6. Operations, Administration and Maintenance (OAM) . . . . . 17
3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20 3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 21
3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 22 3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 24
3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 22 3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 26
3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 23 3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 26
3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 23 3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 27
3.11. Network Management . . . . . . . . . . . . . . . . . . . . 24 3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 27
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 3.11. Network Management . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
1.1. Motivation and Background 1.1. Motivation and Background
This document describes a framework for a Multiprotocol Label This document describes a framework for a Multiprotocol Label
Switching Transport Profile (MPLS-TP). It presents the architectural Switching Transport Profile (MPLS-TP). It presents the architectural
framework for MPLS-TP, definining those elements of MPLS applicable framework for MPLS-TP, defining those elements of MPLS applicable to
to supporting the requirements in [I-D.ietf-mpls-tp-requirements] and supporting the requirements in [I-D.ietf-mpls-tp-requirements] and
what new protocol elements are required. what new protocol elements are required.
Bandwidth demand continues to grow worldwide, stimulated by the Bandwidth demand continues to grow worldwide, stimulated by the
accelerating growth and penetration of new packet based services and accelerating growth and penetration of new packet based services and
multimedia applications: multimedia applications:
o Packet-based services such as Ethernet, Voice over IP (VoIP), o Packet-based services such as Ethernet, Voice over IP (VoIP),
Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP
Television (IPTV), Radio Access Network (RAN) backhauling, etc., Television (IPTV), Radio Access Network (RAN) back-hauling, etc.,
o Applications with various bandwidth and Quality of Service (QoS) o Applications with various bandwidth and Quality of Service (QoS)
requirements. requirements.
This growth in demand has resulted in dramatic increases in access This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements. network bandwidth requirements.
Over the past two decades, the evolving optical transport Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous infrastructure (Synchronous Optical Networking (SONET)/Synchronous
skipping to change at page 4, line 21 skipping to change at page 4, line 21
1. To enable MPLS to be deployed in a transport network and operated 1. To enable MPLS to be deployed in a transport network and operated
in a similar manner to existing transport technologies. in a similar manner to existing transport technologies.
2. To enable MPLS to support packet transport services with a 2. To enable MPLS to support packet transport services with a
similar degree of predictability to that found in existing similar degree of predictability to that found in existing
transport networks. transport networks.
In order to achieve these objectives, there is a need to create a In order to achieve these objectives, there is a need to create a
common set of new functions that are applicable to both MPLS networks common set of new functions that are applicable to both MPLS networks
in general, and those blonging to the MPLS-TP profile. in general, and those belonging to the MPLS-TP profile.
MPLS-TP therefore defines a profile of MPLS targeted at transport MPLS-TP therefore defines a profile of MPLS targeted at transport
applications and networks. This profile specifies the specific MPLS applications and networks. This profile specifies the specific MPLS
characteristics and extensions required to meet transport characteristics and extensions required to meet transport
requirements. An equipment conforming to MPLS-TP MUST support this requirements. An equipment conforming to MPLS-TP MUST support this
profile. An MPLS-TP conformant equipment MAY support additional MPLS profile. An MPLS-TP conformant equipment MAY support additional MPLS
features. A carrier may deploy some of those additional features in features. A carrier may deploy some of those additional features in
the transport layer of their network if they find them to be the transport layer of their network if they find them to be
beneficial. beneficial.
1.2. Applicability 1.2. Applicability
Figure 1 illustrates the range of services that MPLS-TP is intended Figure 1 illustrates the range of services that MPLS-TP is intended
to address. MPLS-TP is intended to support a range of layer 1, layer to address. MPLS-TP is intended to support a range of layer 1, layer
2 and layer 3 services, and is not limited to layer 3 services only. 2 and layer 3 services, and is not limited to layer 3 services only.
Networks implementing MPLS-TP may choose to only support a subset of Networks implementing MPLS-TP may choose to only support a subset of
these services. these services.
MPLS-TP Solution exists MPLS-TP Solution exists
over this spectrum over this spectrum
|<-------------------------------->| |<-------------------------->|
cl-ps Multi-Service co-cs & co-ps cl-ps Multi-Service co-cs & co-ps
(cl-ps & co-ps) (Label is (cl-ps & co-ps) (Label is
| | service context) | | service context)
| | | | | |
|<------------------------------|--------------------------------->| |<--------------------------|--------------------------->|
| | | | | |
L3 Only L1, L2, L3 Services L1, L2 Services L3 Only L1, L2, L3 Services L1, L2 Services
Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP
Figure 1: MPLS-TP Applicability Figure 1: MPLS-TP Applicability
The diagram above shows the spectrum of services that can be The diagram above shows the spectrum of services that can be
supported by MPLS. MPLS-TP solutions are primarily intended for supported by MPLS. MPLS-TP solutions are primarily intended for
packet transport applications. These can be deployed using a profile packet transport applications. These can be deployed using a profile
of MPLS that is strictly connection oriented and does not rely on IP of MPLS that is strictly connection oriented and does not rely on IP
forwarding or routing (shown on the right hand side of the figure), forwarding or routing (shown on the right hand side of the figure),
or in conjunction with an MPLS network that does use IP forwarding or in conjunction with an MPLS network that does use IP forwarding
and that supports a broader range of IP services. This is the multi- and that supports a broader range of IP services. This is the multi-
service solution in the centre of the figure. service solution in the centre of the figure.
1.3. Scope 1.3. Scope
This document describes a framework for a Tranport Profile of This document describes a framework for a Transport Profile of
Multiprotocol Label Switching (MPLS-TP). It presents the Multiprotocol Label Switching (MPLS-TP). It presents the
architectural framework for MPLS-TP, definining those elements of architectural framework for MPLS-TP, defining those elements of MPLS
MPLS applicable to supporting the requirements in applicable to supporting the requirements in
[I-D.ietf-mpls-tp-requirements] and what new protocol elements are [I-D.ietf-mpls-tp-requirements] and what new protocol elements are
required. required.
This document describes the architecture for MPLS-TP when the LSP This document describes the architecture for MPLS-TP when the LSP
client is a PW. The transport of IP and MPLS, other than carried client is a pseudowire, and when the LSP is providing a network layer
over a PW, is outside the scope of this document. This does not transport service.
preclude the use of LSPs conforming to the MPLS transport profile
from being used to carry IP or other MPLS LSPs by general purpose
MPLS networks.
1.4. Terminology 1.4. Terminology
Term Definition Term Definition
------- ----------------------------------------- ------- -------------------------------------------------------------
LSP Label Switched Path LSP Label Switched Path
MPLS-TP MPLS Transport profile MPLS-TP MPLS Transport profile
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
OTN Optical Transport Network OTN Optical Transport Network
cl-ps Connectionless - Packet Switched cl-ps Connectionless - Packet Switched
co-cs Connection Oriented - Circuit Switched co-cs Connection Oriented - Circuit Switched
co-ps Connection Oriented - Packet Switched co-ps Connection Oriented - Packet Switched
OAM Operations, Adminitration and Maintenance OAM Operations, Administration and Maintenance
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL Generic Alert Label GAL Generic Alert Label
MEP Maintenance End Point MEP Maintenance End Point
MIP Maintenance Intermediate Point MIP Maintenance Intermediate Point
APS Automatic Protection Switching APS Automatic Protection Switching
SCC Signaling Communication Channel SCC Signaling Communication Channel
MCC Management Communication Channel MCC Management Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
FM Fault Management FM Fault Management
CM Configuration Management CM Configuration Management
PM Performance Management PM Performance Management
MPLS-TP MPLS Transport Profile. The set of MPLS functions that meet
the requirements in [I-D.ietf-mpls-tp-requirements].
Detailed definitions and additional terminology may be found in Detailed definitions and additional terminology may be found in
[I-D.ietf-mpls-tp-requirements]. [I-D.ietf-mpls-tp-requirements].
2. Introduction to Requirements 2. Introduction to Requirements
The requirements for MPLS-TP are specified in The requirements for MPLS-TP are specified in
[I-D.ietf-mpls-tp-requirements], [I-D.ietf-mpls-tp-oam-requirements], [I-D.ietf-mpls-tp-requirements], [I-D.ietf-mpls-tp-oam-requirements],
and [I-D.ietf-mpls-tp-nm-req]. This section provides a brief and [I-D.ietf-mpls-tp-nm-req]. This section provides a brief
reminder to guide the reader. It is not intended as a substitute for reminder to guide the reader. It is not intended as a substitute for
these documents. these documents.
MPLS-TP MUST NOT modify the MPLS forwarding architecture and MUST be MPLS-TP MUST NOT modify the MPLS forwarding architecture and MUST be
based on existing pseudowire and LSP constructs. Any new mechanisms based on existing pseudowire and LSP constructs. Any new mechanisms
and capabilities added to support transport networks and packet and capabilities added to support transport networks and packet
transport services must be able to interoperate with existing MPLS transport services must be able to inter-operate with existing MPLS
and pseudowire control and forwarding planes. and pseudowire control and forwarding planes.
Point to point LSPs MAY be unidirectional or bi-directional, and it Point to point LSPs MAY be unidirectional or bi-directional, and it
MUST be possible to construct congruent Bi-directional LSPs. Point MUST be possible to construct congruent Bi-directional LSPs. Point
to multipoint LSPs are unidirectional. to multipoint LSPs are unidirectional.
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
skipping to change at page 7, line 23 skipping to change at page 7, line 26
It MUST be possible to monitor LSPs and pseudowires through the use It MUST be possible to monitor LSPs and pseudowires through the use
of OAM in the absence of control plane or routing functions. In this of OAM in the absence of control plane or routing functions. In this
case information gained from the OAM functions is used to initiate case information gained from the OAM functions is used to initiate
path recovery actions at either the PW or LSP layers. path recovery actions at either the PW or LSP layers.
3. Transport Profile Overview 3. Transport Profile Overview
3.1. Packet Transport Services 3.1. Packet Transport Services
The types of packet transport services provided by existing transport One objective of MPLS-TP is to enable MPLS networks to provide packet
networks are similar to MPLS Layer 2 VPNs. A key characteristic of transport services with a similar degree of predictability to that
packet transport services is that the network used to provide the found in existing transport networks. Such packet transport services
service does not participate in the any IP routing protocols present inherit a number of characteristics, defined in
in the client, or use the IP addresses in client packets to forward [I-D.ietf-mpls-tp-requirements].
those packets. The network is therefore transparent to IP in the
client service.
MPLS-TP MUST use one of the Layer 2 VPN services defined in [PPVPN o In an environment where an MPLS-TP layer network is supporting a
architecture] to provide a packet transport service. client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer
network MUST be possible without any dependencies on the server or
client layer network.
MPLS-TP LSPs MAY also be used to transport traffic for which the o The service provided by the MPLS-TP network to the client is
immediate client of the MPLS-TP LSP is not a Layer 2 VPN. However, guaranteed not to fall below the agreed level regardless of other
for the purposes of this document, we do not refer to these traffic client activity.
types as belonging to a packet transport service. Such clients
include IP and MPLS LSPs. o The control and management planes of any client network layer that
uses the service is isolated from the control and management
planes of the MPLS-TP layer network.
o Where a client network makes use of an MPLS-TP server that
provides a packet transport service, the level of co-ordination
required between the client and server layer networks is minimal
(preferably no co-ordination will be required).
o The complete set of packets generated by a client MPLS(-TP) layer
network using the packet transport service, which may contain
packets that are not MPLS packets (e.g. IP or CNLS packets used
by the control/management plane of the client MPLS(-TP) layer
network), are transported by the MPLS-TP server layer network.
o The packet transport service enables the MPLS-TP layer network
addressing and other information (e.g. topology) to be hidden from
any client layer networks using that service, and vice-versa.
3.2. Architecture 3.2. Architecture
The architecture for a transport profile of MPLS (MPLS-TP) is based [Editors' Note Section 3.2 needs to generalized to include the
on the MPLS [RFC3031], pseudowire [RFC3985], and multi-segment architecture when PWs are not being transported and the client is IP,
pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as illustrated MPLS or a network layer service over MPLS-TP LSPs as described in
in Figure 2. section 3.4]
The architecture for a transport profile of MPLS (MPLS-TP) that uses
PWs is based on the MPLS [RFC3031], pseudowire [RFC3985], and multi-
segment pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as
illustrated in Figure 2.
|<-------------- Emulated Service ---------------->| |<-------------- Emulated Service ---------------->|
| | | |
| |<------- Pseudo Wire ------>| | | |<------- Pseudowire ------->| |
| | | | | | | |
| | |<-- PSN Tunnel -->| | | | | |<-- PSN Tunnel -->| | |
| V V V V | | V V V V |
V AC +----+ +----+ AC V V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+ +-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| | | |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 | | CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| | | |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+ +-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^ ^ | +----+ +----+ | | ^
skipping to change at page 8, line 27 skipping to change at page 9, line 4
^ | +----+ +----+ | | ^ ^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | | | | Provider Edge 1 Provider Edge 2 | |
| | | | | | | |
Customer | | Customer Customer | | Customer
Edge 1 | | Edge 2 Edge 1 | | Edge 2
| | | |
| | | |
Native service Native service Native service Native service
Figure 2: MPLS-TP Architecture (Single Segment PW) Figure 2: MPLS-TP Architecture (Single Segment PW)
Native |<------------Pseudowire-------------->| Native Native |<------------Pseudowire-------------->| Native
Service | PSN PSN | Service Service | PSN PSN | Service
(AC) | |<--cloud->| |<-cloud-->| | (AC) (AC) | |<--cloud->| |<-cloud-->| | (AC)
| V V V V V V | | V V V V V V |
| +----+ +-----+ +----+ | | +----+ +-----+ +----+ |
+----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+
| |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | | |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| |
| CE1| | | | | | | | | |CE2 | | CE1| | | | | | | | | |CE2 |
| |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | | |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| |
+----+ | | |===========| |==========| | | +----+ +----+ | | |===========| |==========| | | +----+
^ +----+ ^ +-----+ ^ +----+ ^ ^ +----+ ^ +-----+ ^ +----+ ^
| | | | | | | |
| TE LSP TE LSP | | TE LSP TE LSP |
| | | |
| | | |
|<---------------- Emulated Service ----------------->| |<---------------- Emulated Service ----------------->|
MPLS-TP Architecture (Multi-Segment PW) MPLS-TP Architecture (Multi-Segment PW)
skipping to change at page 9, line 15 skipping to change at page 10, line 6
This document describes the architecture for MPLS-TP when the LSP This document describes the architecture for MPLS-TP when the LSP
client is a PW. The transport of IP and MPLS, other than carried client is a PW. The transport of IP and MPLS, other than carried
over a PW, is outside the scope of this document. This does not over a PW, is outside the scope of this document. This does not
preclude the use of LSPs conforming to the MPLS transport profile preclude the use of LSPs conforming to the MPLS transport profile
from being used to carry IP or other MPLS LSPs by general purpose from being used to carry IP or other MPLS LSPs by general purpose
MPLS networks. LSP hierarchy MAY be used within the MPLS-TP network, MPLS networks. LSP hierarchy MAY be used within the MPLS-TP network,
so that more than one LSP label MAY appear in the label stack. so that more than one LSP label MAY appear in the label stack.
+---------------------------+ +---------------------------+
| PW Native service | | Native service |
/===========================\ /===========================\
H PW Encapsulation H \ <---- PW Control word H PW Encapsulation H \ <---- PW Control word
H---------------------------H \ <---- Normalised client H---------------------------H \ <---- Normalised client
H PW OAM H MPLS-TP channel H PW OAM H MPLS-TP channel
H---------------------------H / H---------------------------H /
H PW Demux (S=1) H / H PW Demux (S=1) H /
H---------------------------H \ H---------------------------H \
H LSP OAM H \ H LSP OAM H \
H---------------------------H / MPLS-TP Path(s) H---------------------------H / MPLS-TP Path(s)
H LSP Demultiplexer(s) H / H LSP Demultiplexer(s) H /
skipping to change at page 10, line 24 skipping to change at page 11, line 12
forwarding in this case and is always at the bottom of the label forwarding in this case and is always at the bottom of the label
stack. The operation of the MPLS-TP network is independent of the stack. The operation of the MPLS-TP network is independent of the
payload carried by the MPLS-TP PW packet. payload carried by the MPLS-TP PW packet.
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 bounded by a set of adaptation functions to this server layer thus bounded by a set of adaptation functions to this server layer
network. These adaptation functions provide encapsulation of the network. These adaptation functions provide encapsulation of the
MPLS-TP frames and for the transparent transport of those frames over MPLS-TP frames and for the transparent transport of those frames over
the server layer network. The MPLS-TP client inherits its QoS from the server layer network. The MPLS-TP client inherits its QoS from
the MPLS-TP network, which in turn inherits its QoS from the server the MPLS-TP network, which in turn inherits its QoS from the server
layer. The server layer must therefore provide the neccesary Quality layer. The server layer must therefore provide the necessary Quality
of Service (QoS) to ensure that the MPLS-TP client QoS commitments of Service (QoS) to ensure that the MPLS-TP client QoS commitments
are satisfied. are satisfied.
MPLS-TP LSPs use the MPLS label switching operations defined in MPLS-TP LSPs use the MPLS label switching operations defined in
[RFC3031]. These operations are highly optimized for performance and [RFC3031] for point-to-point LSPs and [RFC5332] for point to
are not modified by the MPLS-TP profile. multipoint LSPs. These operations are highly optimized for
performance and are not modified by the MPLS-TP profile.
During forwarding a label is pushed to associate a forwarding During forwarding a label is pushed to associate a forwarding
equivalence class (FEC) with the LSP or PW. This specifies the equivalence class (FEC) with the LSP or PW. This specifies the
processing operaton to be performed by the next hop at that level of processing operation to be performed by the next hop at that level of
encapsulation. A swap of this label is an atomic operation in which encapsulation. A swap of this label is an atomic operation in which
the contents of the packet after the swapped label are opaque to the the contents of the packet after the swapped label are opaque to the
forwarder. The only event that interrupts a swap operation is TTL forwarder. The only event that interrupts a swap operation is TTL
expiry, in which case the packet may be inspected and either expiry, in which case the packet may be inspected and either
discarded or subjected to further processing within the LSR. TTL discarded or subjected to further processing within the LSR. TTL
expiry causes an exception which forces a packet to be further expiry causes an exception which forces a packet to be further
inspected and processed. While this occurs, the forwarding of inspected and processed. While this occurs, the forwarding of
succeeding packets continues without interruption. Therefore, the succeeding packets continues without interruption. Therefore, the
only way to cause a P (intermediate) LSR to inspect a packet (for only way to cause a P (intermediate) LSR to inspect a packet (for
example for OAM purposes) is to set the TTL to expire at that LSR. example for OAM purposes) is to set the TTL to expire at that LSR.
skipping to change at page 11, line 28 skipping to change at page 12, line 17
on a bidirectional LSP. on a bidirectional LSP.
Per-packet equal cost multi-path (ECMP) load balancing is not Per-packet equal cost multi-path (ECMP) load balancing is not
applicable to MPLS-TP LSPs. applicable to MPLS-TP LSPs.
Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default. Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.
Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270 Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270
[RFC3270] [RFC3270]
3.4. MPLS-TP Transport Domain 3.4. MPLS-TP LSP Clients
This document specifies the architecture when the client of the This document specifies the architecture for two types of client:
MPLS-TP LSP is a PW. Note, however, that in MPLS-TP environments
where IP is used for control or OAM purposes, IP MAY be carried over
the the LSPs or directly over the server, as described in
Section 3.2. In this case, the MPLS-TP transport domain consists of
the PW encapsulation mechanisms, including the PW control word.
3.5. Addressing o A PW
Editor's note: This section will be updated after publication of the o A network layer transport service
MPLS-TP Addressing Architecture draft.
MPLS-TP distinguishes between adressing used to identify nodes in the When the client is a PW, the MPLS-TP transport domain consists of the
network, and identifiers used for demultiplexing and forwarding. PW encapsulation mechanisms, including the PW control word. When the
This distinction is illustrated in Figure 4. client is operating at the network layer the mechanism described in
Section 3.4.1 is used.
NMS Control/Signalling 3.4.1. Network Layer Transport Service
..... .....
[Address]| | [Address]
| |
+-----+---------+------+
Address = Node | | | |
ID in forwarding plane | V V |
| |
| MEP or MIP |
| dmux |
| svcid |
| src |
+--^-------------------+
|
OAM: OAM |
dmux= [GAL/GACH]...........
or ________________________________________
IP (________________________________________)
svc context=ID/FEC PWE=ID1
SRC=IP .
.
IDx
Figure 4: Addressing in MPLS-TP MPLS-TP LSPs can be used to deliver a network level transport
service. Such a network layer transport service (NLTS) can be used
to transport any network layer protocol between service interfaces.
Example of network layer protocols include IP, MPLS and even MPLS-TP.
Editor's note: The figure above arose from discussions in the MPLS-TP With network layer transport, the MPLS-TP domain provides a
design team. It will be clarified in a future verson of this draft. bidirectional point-to-point connection between two customer edge
(CE) MPLS-TP nodes. Point-to- multipoint service is for further
study. As shown in Figure 4, there is an attachment circuit between
the CE node on the left and its corresponding provider edge (PE) node
that provides the service interface, a bidirectional LSP across the
MPLS-TP service network to the corresponding PE node on the right,
and an attachment circuit between that PE node and the corresponding
CE node for this service.
IPv4 or IPv6 addresses are used to identify MPLS-TP nodes by default : +--------------------+ :
for network management and signaling purposes. : | +------------+ | :
: | | Management | | :
+------+ : | | system(s) | | : +------+
| C | : | +------------+ | : | CE | +------+
|device| : | | : |device|--| C |
+------+ : | +------+ : | of | |device|
| : | | x=:=|SVC A| +------+
| : | | | : +------+
+------+ : | | PE | :
+------+ | CE | : | |device| :
| C | |device| : +------+ +------+ | | :
|device|--| of |=:=x |--| |--| | :
+------+ |SVC A| : | | | | +------+ :
+------+ : | PE | | P | | :
+------+ : |device| |device| | :
+------+ | CE | : | | | | +------+ :
| C |--|device|=:=x |--| |--| | :
|device| | of | : +------+ +------+ | | :
+------+ |SVC B| : | | PE | :
+------+ : | |device| :
| : | | | : +------+
| : | | x=:=| CE | +------+
+------+ : | +------+ : |device| | C |
| C | : | | : | of |--|device|
|device| : | | : |SVC B| +------+
+------+ : | | : +------+
: | | :
Customer | | Customer
interface | MPLS-TP | interface
+--------------------+
|<---- Provider ---->|
| network |
In the forwarding plane, identfiers are required for the service Key: ==== attachment circuit
context (provided by the FEC), and for OAM. OAM requires both a x service interface
demultiplexer and an address for the source of the OAM packet. ---- link
For MPLS in general where IP addressing is used, IPv4 or IPv6 is used Figure 4: Network Layer Transport Service Components
by default. However, MPLS-TP must be able to operate in environments
where IP is not used in the forwarding plane. Therefore, the default
mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the
generic associated channel. Forwarding based on IP addresses for
user or OAM packets is NOT REQUIRED for MPLS-TP.
RFC 4379 [RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have At the service interface the PE transforms the ingress packet to the
defined alert mechanisms that enable a MPLS LSR to identify and format that will be carry over the transport network, and similarly
process MPLS OAM packets when the OAM packets are encapsulated in an the corresponding service interface at the egress PE transforms the
IP header. These alert mechanisms are based on TTL expiration and/or packet to the format needed by the attached CE. The attachment
use an IP destination address in the range 127/8. These mechanisms circuits may be heterogeneous (e.g., any combination of SDH, PPP,
are the default mechanisms for MPLS networks in general for frame relay etc) and network layer protocol payloads arrive at the
identifying MPLS OAM packets when the OAM packets are encapsulated in service interface encapsulated in the L1/L2 encoding defined for that
an IP header. MPLS-TP must not rely on these mechanisms, and thus access link type. It should be noted that the set of network layer
relies on the GACH/GAL to demultiplex OAM packets. protocols includes MPLS and hence MPLS encoded packets with an MPLS
label stack (the client MPLS stack), may appear at the service
interface.
Within the MPLS-TP transport network, the network layer protocols are
carried over the MPLS-TP LSP using a separate MPLS label stack (the
server stack). The server stack is entirely under the control of the
nodes within the MPLS-TP transport network and it is not visible
outside that network. In accordance with [RFC3032], the bottom
label, with the 'bottom of stack' bit set to '1', defines the network
layer protocol being transported. Figure 5 shows how an a client
network protocol stack (which may be an MPLS label stack and payload)
is carried over as a network layer transport service over an MPLS-TP
transport network.
+------------------------------------+
| MPLS-TP LSP label(s) (S=0) | n*4 octets
. . (four octets per label)
+------------------------------------+
| Service label (s=1) | 4 octets
+------------------------------------+
| Client Network |
| Layer Protocol |
| Stack. |
+------------------------------------+
Note that the Client Network Layer Protocol
Stack may include an MPLS label stack
with the S bit set (S=1).
Figure 5: Network Layer Transport Service Protocol Stack
A label per network layer protocol payload type that is to be
transported is REQUIRED. Such labels are referred to as "Service
Labels", one of which is shown in Figure 5. The mapping between
protocol payload type and Service Label is either configured or
signaled.
Service labels are typically carried over an MPLS-TP edge-to-edge
LSP, which is also shown in Figure 5. The use of an edge-to-edge LSP
is RECOMMENDED when more than one protocol payload type is to be
transported. For example, if only MPLS is carried then a single
Service Label would be used to provided both payload type indication
and the MPLS-TP edge-to-edge LSP. Alternatively, if both IP and MPLS
is to be carried then two Service Labels would be mapped on to a
common MPLS-TP edge-to-edge LSP.
As noted above, any layer 2 and layer 1 protocols used to carry the
network layer protocol over the attachment circuit is terminated at
the service interface and is not transported across the MPLS-TP
network. This enables the use of different L2/L1 technologies at two
service interfaces.
At each service interface, Layer 2 addressing must be used to ensure
the proper delivery of a network layer packet to the adjacent node.
This is typically only an issue for LAN media technologies (e.g.,
Ethernet) which have Media Access Control (MAC) addresses. In cases
where a MAC address is needed, the sending node MUST set 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
address that ensures delivery to the PE, and the PE sets the
destination MAC address to an address that ensures delivery to the
CE. The specific address used is technology type specific and is not
covered in this document. (Examples for the Ethernet case include a
configured unicast MAC address for the adjacent node, or even using
the broadcast MAC address when the CE-PE service interface is
dedicated. The configured address is then used as the MAC
destination address for all packets sent over the service interface.)
Note that when the two CEs operating over the network layer transport
service are running a routing protocol such as ISIS or OSPF some care
should be taken to configure the routing protocols to use point- to-
point adjacencies. The specifics of such configuration is outside
the scope of this document.
[Editors Note we need to confer with ISIS and OSPF WG to verify that
the cautionary note above is necessary and sufficient.]
The CE to CE service types and corresponding labels may be configured
or signaled. When they are signaled the CE to PE control channel may
be either out-of-band or in-band. An out-of-band control channel
uses standard GMPLS out-of-band signaling techniques [REF-TBD].
There are a number of methods that can be used to carry this
signalling:
o It can be carried via an out-of-band control channel. (As is
commonly done in today's GMPLS controlled transport networks.)
o It could be carried over the attachment circuit with MPLS using a
reserved label.
o It could be carried over the attachment circuit with MPLS using a
normal label that is agreed between CE and PE.
o It could be carried over the attachment circuit in an ACH.
o It could be carried over the attachment circuit in IP.
In the MPLS and ACH cases above, this label value is used to carry
LSP signaling without any further encapsulation. This signaling
channel is always point-to-point and MUST use local CE and PE
addressing.
The method(s) to be used will be described in a future version of the
document.
3.5. Identifiers
Identifiers to be used in within MPLS-TP where compatibility with
existing MPLS control plane conventions are necessary are described
in [draft-swallow-mpls-tp-identifiers-00]. The MPLS-TP requirements
[I-D.ietf-mpls-tp-requirements] require that the elements and objects
in an MPLS-TP environment are able to be configured and managed
without a control plane. In such an environment many conventions for
defining identifiers are possible. However it is also anticipated
that operational environments where MPLS-TP objects, LSPs and PWs
will be signaled via existing protocols such as the Label
Distribution Protocol [RFC4447] and the Resource Reservation Protocol
as it is applied to Generalized Multi-protocol Label Switching (
[RFC3471] and [RFC3473]) (GMPLS).
[draft-swallow-mpls-tp-identifiers-00] defines a set of identifiers
for MPLS-TP which are both compatible with those protocols and
applicable to MPLS-TP management and OAM functions.
MPLS-TP distinguishes between addressing used to identify nodes in
the network, and identifiers used for demultiplexing and forwarding.
Whilst IP addressing is used by default, MPLS-TP must be able to
operate in environments where IP is not used in the forwarding plane.
Therefore, the default mechanism for OAM demultiplexing in MPLS-TP
LSPs and PWs is the generic associated channel. Forwarding based on
IP addresses for user or OAM packets is not REQUIRED for MPLS-TP.
[RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined alert
mechanisms that enable an MPLS LSR to identify and process MPLS OAM
packets when the OAM packets are encapsulated in an IP header. These
alert mechanisms are based on TTL expiration and/or use an IP
destination address in the range 127/8. These mechanisms are the
default mechanisms for MPLS networks in general for identifying MPLS
OAM packets when the OAM packets are encapsulated in an IP header.
MPLS-TP is unable to rely on the availability of IP and thus uses the
GACH/GAL to demultiplex OAM packets.
3.6. Operations, Administration and Maintenance (OAM) 3.6. Operations, Administration and Maintenance (OAM)
MPLS-TP supports a comprehensive set of OAM capabilities for packet MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those transport applications, with equivalent capabilities to those
provided in SONET/SDH. provided in SONET/SDH.
MPLS-TP defines mechanisms to differentiate specific packets (e.g. MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the OAM, APS, MCC or SCC) from those carrying user data packets on the
same LSP. These mechanisms are described in RFC5586 [RFC5586]. same LSP. These mechanisms are described in [RFC5586].
MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of
OAM capabilities is available to perform fault management (e.g. fault OAM capabilities is available to perform fault management (e.g. fault
detection and localization) and performance monitoring (e.g. packet detection and localization) and performance monitoring (e.g. packet
delay and loss measurement) of the LSP, PW or section. The framework delay and loss measurement) of the LSP, PW or section. The framework
for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].
OAM and monitoring in MPLS-TP is based on the concept of maintenance OAM and monitoring in MPLS-TP is based on the concept of maintenance
entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A
Maintenance Entity can be viewed as the association of two (or more) Maintenance Entity can be viewed as the association of two (or more)
Maintenance End Points (MEPs) (see example in Figure 5 ). The MEPs Maintenance End Points (MEPs) (see example in Figure 6 ). The MEPs
that form an ME should be configured and managed to limit the OAM that form an ME should be configured and managed to limit the OAM
responsibilities of an OAM flow within a network or sub- network, or responsibilities of an OAM flow within a network or sub- network, or
a transport path or segment, in the specific layer network that is a transport path or segment, in the specific layer network that is
being monitored and managed. being monitored and managed.
Each OAM flow is associated with a single ME. Each MEP within an ME Each OAM flow is associated with a single ME. Each MEP within an ME
resides at the boundaries of that ME. An ME may also include a set resides at the boundaries of that ME. An ME may also include a set
of zero or more Maintenance Intermediate Points (MIPs), which reside of zero or more Maintenance Intermediate Points (MIPs), which reside
within the Maintenance Entity. Maintenance end points (MEPs) are within the Maintenance Entity. Maintenance end points (MEPs) are
capable of sourcing and sinking OAM flows, while maintenance capable of sourcing and sinking OAM flows, while maintenance
intermediate points (MIPs) can only sink or respond to OAM flows. intermediate points (MIPs) can only sink or respond to OAM flows.
========================== End to End LSP OAM ============================ ========================== End to End LSP OAM ==========================
..... ..... ..... ..... ..... ..... ..... .....
-----|MIP|---------------------|MIP|---------|MIP|------------|MIP|----- -----|MIP|---------------------|MIP|---------|MIP|------------|MIP|-----
''''' ''''' ''''' ''''' ''''' ''''' ''''' '''''
|<-------- Carrier 1 --------->| |<--- Carrier 2 ----->| |<-------- Carrier 1 --------->| |<--- Carrier 2 ----->|
---- --- --- ---- ---- --- ---- ---- --- --- ---- ---- --- ----
NNI | | | | | | | | NNI | | | | | | NNI NNI | | | | | | | | NNI | | | | | | NNI
-----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |----
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
---- --- --- ---- ---- --- ---- ---- --- --- ---- ---- --- ----
==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM === ==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM ===
(Carrier 1) LSP OAM (Carrier 2) (Carrier 1) LSP OAM (Carrier 2)
(inter-carrier) (inter-carrier)
..... ..... ..... .......... .......... ..... ..... ..... ..... ..... .......... .......... ..... .....
|MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP| |MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
''''' ''''' ''''' '''''''''' '''''''''' ''''' ''''' ''''' ''''' ''''' '''''''''' '''''''''' ''''' '''''
<------------ ME ----------><--- ME ----><------- ME --------> <------------ ME ----------><--- ME ----><------- ME -------->
Note: MEPs for End-to-end LSP OAM exist outside of the scope of this figure. Note: MEPs for End-to-end LSP OAM exist outside of the scope
of this figure.
Figure 5: Example of MPLS-TP OAM Figure 6: Example of MPLS-TP OAM
Figure 6 illustrates how the concept of Maintenance Entities can be Figure 7 illustrates how the concept of Maintenance Entities can be
mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS- mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
PWs. PWs.
Native |<-------------------- PW15 --------------------->| Native Native |<-------------------- PW15 --------------------->| Native
Layer | | Layer Layer | | Layer
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2) (AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
|CE1|--------|........PW1........|...PW3...|........PW5........|-----|CE2| |CE1|------|........PW1.....X..|...PW3...|.X......PW5........|-----|CE2|
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
|<- Subnetwork 123->| |<- Subnetwork XYZ->| |<- Subnetwork 123->| |<- Subnetwork XYZ->|
.------------------- PW15 PME -------------------. .------------------- PW15 PME -------------------.
.---- PW1 PTCME ----. .---- PW5 PTCME ---. .---- PW1 PTCME ----. .---- PW5 PTCME ---.
.---------. .---------. .---------. .---------.
PSN13 LME PSNXZ LME PSN13 LME PSNXZ LME
skipping to change at page 15, line 36 skipping to change at page 19, line 36
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
.---. ME . MEP ==== LSP .... PW .---. ME . MEP ==== LSP .... PW
SME: Section Maintenance Entity SME: Section Maintenance Entity
LME: LSP Maintenance Entity LME: LSP Maintenance Entity
PME: PW Maintenance Entity PME: PW Maintenance Entity
Figure 6: MPLS-TP OAM archtecture Figure 7: MPLS-TP OAM archtecture
The following MPLS-TP MEs are specified in The following MPLS-TP MEs are specified in
[I-D.ietf-mpls-tp-oam-framework]: [I-D.ietf-mpls-tp-oam-framework]:
o A Section Maintenance Entity (SME), allowing monitoring and o A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs). management of MPLS-TP Sections (between MPLS LSRs).
o A LSP Maintenance Entity (LME), allowing monitoring and management o A LSP Maintenance Entity (LME), allowing monitoring and management
of an end-to-end LSP (between LERs). of an end-to-end LSP (between LERs).
o A PW Maintenance Entity (PME), allowing monitoring and management o A PW Maintenance Entity (PME), allowing monitoring and management
of an end-to-end SS/MS-PWs (between T-PEs). of an end-to-end SS/MS-PWs (between T-PEs).
o An LSP Tandem Connection Maintenance Entity (LTCME), allowing o An LSP Tandem Connection Maintenance Entity (LTCME), allowing
monitoring and management of an LSP Tandem Connection (or LSP estimation of OAM fault and performance metrics of a single LSP
Segment) between any LER/LSR along the LSP. o A MS-PW Tandem segment or of an aggregate of LSP segments. It also enables any
Connection Maintenance Entity (PTCME), allows monitoring and OAM function applied to segment(s) of an LSP to be independent of
management of a SS/MS-PW Tandem Connection (or PW Segment) between the OAM function(s) operated on the end-to-end LSP. This can be
any T-PE/S-PE along the (MS-)PW. Note that the term Tandem achieved by including a label representing the LTCME on one or
Connection Monitoring has historical significance dating back to more LSP label stacks for 1:1 or N:1 monitoring of LSPs,
the early days of the telephone network, but is equally applicable respectively. Note that the term Tandem Connection Monitoring has
to the two-level hierarchal architectures commonly employed in historical significance dating back to the early days of the
todays packet networks. telephone network, but is equally applicable to the hierarchal
architectures commonly employed in todays packet networks.
Individual MIPs along the path of an LSP or PW are addressed by Individual MIPs along the path of an LSP or PW are addressed by
setting the appropriate TTL in the label for the OAM packet, as per setting the appropriate TTL in the label for the OAM packet, as per
[I-D.ietf-pwe3-segmented-pw]. Note that this works when the location [I-D.ietf-pwe3-segmented-pw]. Note that this works when the location
of MIPs along the LSP or PW path is known by the MEP. There may be of MIPs along the LSP or PW path is known by the MEP. There may be
cases where this is not the case in general MPLS networks e.g. cases where this is not the case in general MPLS networks e.g.
following restoration using a facility bypass LSP. following restoration using a facility bypass LSP. In these cases,
tools to trace the path of the LSP may be used to determine the
appropriate setting for the TTL to reach a specific MIP.
MPLS-TP OAM packets share the same fate as their corresponding data MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel packets, and are identified through the Generic Associated Channel
mechanism [RFC5586]. This uses a combination of an Associated mechanism [RFC5586]. This uses a combination of an Associated
Channel Header (ACH) and a Generic Alert Label (GAL) to create a Channel Header (ACH) and a Generic Alert Label (GAL) to create a
control channel associated to an LSP, Section or PW. control channel associated to an LSP, Section or PW.
The MPLS-TP OAM architecture support a wide range of OAM functions, The MPLS-TP OAM architecture support a wide range of OAM functions,
including the following including the following
skipping to change at page 16, line 49 skipping to change at page 20, line 52
o Remote Integrity o Remote Integrity
These are applicable to any layer defined within MPLS- TP, i.e. MPLS These are applicable to any layer defined within MPLS- TP, i.e. MPLS
Section, LSP and PW. Section, LSP and PW.
The MPLS-TP OAM toolset needs to be able to operate without relying The MPLS-TP OAM toolset needs to be able to operate without relying
on a dynamic control plane or IP functionality in the datapath. In on a dynamic control plane or IP functionality in the datapath. In
the case of MPLS-TP deployment with IP functionality, all existing the case of MPLS-TP deployment with IP functionality, all existing
IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used. IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used.
This does not preculde the use of other OAM tools in an IP This does not preclude the use of other OAM tools in an IP
addressable network. addressable network.
One use of OAM mechanisms is to detect link failures, node failures One use of OAM mechanisms is to detect link failures, node failures
and performance outside the required specification which then may be and performance outside the required specification which then may be
used to trigger recovery actions, according to the requirements of used to trigger recovery actions, according to the requirements of
the service. the service.
3.7. Generic Associated Channel (G-ACh) 3.7. Generic Associated Channel (G-ACh)
For correct operation of the OAM it is important that the OAM packets For correct operation of the OAM it is important that the OAM packets
fate share with the data packets. In addition in MPSL-TP it is fate share with the data packets. In addition in MPSL-TP it is
necessary to discriminate between user data payloads and other types necessary to discriminate between user data payloads and other types
of payload. For example the packet may contain a Signaling of payload. For example the packet may contain a Signaling
Communication Channel (SCC), or a channel used for Automatic Communication Channel (SCC), or a channel used for Automatic
Protecton Switching (APS) data. Such packetets are carried on a Protection Switching (APS) data. Such packets are carried on a
control channel associated to the LSP, Section or PW. This is control channel associated to the LSP, Section or PW. This is
achieved by carrying such packets on a generic control channel achieved by carrying such packets on a generic control channel
associated to the LSP, PW or section. associated to the LSP, PW or section.
MPLS-TP makes use of such a generic associated channel (G-ACh) to MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
or other packet types in band over LSPs or PWs. The G-ACH is defined or other packet types in band over LSPs or PWs. The G-ACH is defined
in [RFC5586]and it is similar to the Pseudowire Associated Channel in [RFC5586]and it is similar to the Pseudowire Associated Channel
[RFC4385], which is used to carry OAM packets across pseudowires. [RFC4385], which is used to carry OAM packets across pseudowires.
skipping to change at page 17, line 45 skipping to change at page 21, line 48
following the label at the bottom of stack, has a value of one, then following the label at the bottom of stack, has a value of one, then
this packet belongs to a G-ACh. The first 32 bits following the this packet belongs to a G-ACh. The first 32 bits following the
bottom of stack label then have a defined format called an associated bottom of stack label then have a defined format called an associated
channel header (ACH), which further defines the content of the channel header (ACH), which further defines the content of the
packet. The ACH is therefore both a demultiplexer for G-ACh traffic packet. The ACH is therefore both a demultiplexer for G-ACh traffic
on the PW, and a discriminator for the type of G-ACh traffic. on the PW, and a discriminator for the type of G-ACh traffic.
When the OAM, or a similar message is carried over an LSP, rather When the OAM, or a similar message is carried over an LSP, rather
than over a pseudowire, it is necessary to provide an indication in than over a pseudowire, it is necessary to provide an indication in
the packet that the payload is something other than a user data the packet that the payload is something other than a user data
packet. This is acheived by including a reserved label with a value packet. This is achieved by including a reserved label with a value
of 13 in the label stack. This reserved label is referred to as the of 13 in the label stack. This reserved label is referred to as the
'Generic Alert Label (GAL)', and is defined in [RFC5586]. When a GAL 'Generic Alert Label (GAL)', and is defined in [RFC5586]. When a GAL
is found anywhere within the label stack it indicates that the is found anywhere within the label stack it indicates that the
payload begins with an ACH. The GAL is thus a demultiplexer for payload begins with an ACH. The GAL is thus a demultiplexer for
G-ACh traffic on the LSP, and the ACH is a discriminator for the type G-ACh traffic on the LSP, and the ACH is a discriminator for the type
of traffic carried on the G-ACh. Note however that MPLS-TP of traffic carried on the G-ACh. Note however that MPLS-TP
forwarding follows the normal MPLS model, and that a GAL is invisible forwarding follows the normal MPLS model, and that a GAL is invisible
to an LSR unless it is the top label iin the label stack. The only to an LSR unless it is the top label in the label stack. The only
other circumstance under which the label stack may be inspected for a other circumstance under which the label stack may be inspected for a
GAL is when the TTL has expired. Any MPLS-TP component that GAL is when the TTL has expired. Any MPLS-TP component that
intentionally performs this inspection must assume that it is intentionally performs this inspection must assume that it is
asynchronous with respect to the forwarding of other packets. All asynchronous with respect to the forwarding of other packets. All
operations on the label stack arein accordance with [RFC3031] and operations on the label stack arein accordance with [RFC3031] and
[RFC3032]. [RFC3032].
In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1), however this does bottom of the label stack (i.e. S bit set to 1), however this does
not preclude its use elsewhere in the label stack in other not preclude its use elsewhere in the label stack in other
applications. applications.
The G-ACH MUST only be used for channels that are an adjunct to the The G-ACH MUST only be used for channels that are an adjunct to the
data service. Examples of these are OAM, APS, MCC and SCC, but the data service. Examples of these are OAM, APS, MCC and SCC, but the
use is not resticted to those names services. The G-ACH MUST NOT be use is not restricted to those names services. The G-ACH MUST NOT be
used to carry additional data for use in the forwarding path, i.e. it used to carry additional data for use in the forwarding path, i.e. it
MUST NOT be used as an alternative to a PW control word, or to define MUST NOT be used as an alternative to a PW control word, or to define
a PW type. a PW type.
Since the G-ACh traffic is indistinguishable from the user data Since the G-ACh traffic is indistinguishable from the user data
traffic at the server layer, bandwidth and QoS commitments apply to traffic at the server layer, bandwidth and QoS commitments apply to
the gross traffic on the LSP, PW or section. Protocols using the the gross traffic on the LSP, PW or section. Protocols using the
G-ACh must therefore take into consideration the impact they have on G-ACh must therefore take into consideration the impact they have on
the user data that they are sharing resources with. In addition, the user data that they are sharing resources with. In addition,
protocols using the G-ACh MUST conform to the security and congestion protocols using the G-ACh MUST conform to the security and congestion
considerations described in [RFC5586]. . considerations described in [RFC5586]. .
Figure 7 shows the reference model depicting how the control channel Figure 8 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 | < Service / FCAPS > | Payload | | Payload | < Service / FCAPS > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
| Demux / | < CW / ACH for PWs > | Demux / | | Demux / | < CW / ACH for PWs > | Demux / |
|Discriminator| |Discriminator| |Discriminator| |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
| PW | < PW > | PW | | PW | < PW > | PW |
skipping to change at page 19, line 27 skipping to change at page 23, line 27
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 7: PWE3 Protocol Stack Reference Model including the G-ACh Figure 8: PWE3 Protocol Stack Reference Model including 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 8 shows the reference model depicting how the control channel Figure 9 shows the reference model depicting how the control channel
is associated with the LSP protocol stack. is associated with the LSP protocol stack.
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < Service > | Payload | | Payload | < Service > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
|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 20, line 26 skipping to change at page 24, line 26
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 8: MPLS Protocol Stack Reference Model including the LSP Figure 9: MPLS Protocol Stack Reference Model including the LSP
Associated Control Channel Associated Control Channel
3.8. Control Plane 3.8. Control Plane
MPLS-TP should be capable of being operated with centralized Network MPLS-TP should be capable of being operated with centralized Network
Management Systems (NMS). The NMS may be supported by a distributed Management Systems (NMS). The NMS may be supported by a distributed
control plane, but MPLS-TP can operated in the absense of such a control plane, but MPLS-TP can operated in the absence of such a
control plane. A distributed control plane may be used to enable control plane. A distributed control plane may be used to enable
dynamic service provisioning in multi-vendor and multi-domain dynamic service provisioning in multi-vendor and multi-domain
environments using standardized protocols that guarantee environments using standardized protocols that guarantee
interoperability. Where the requirements specified in interoperability. Where the requirements specified in
[I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport [I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport
profile uses existing control plane protocols for LSPs and PWs. profile uses existing control plane protocols for LSPs and PWs.
Figure 9 illustrates the relationshop between the MPLS-TP control Figure 10 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|-+--
: +----------+ : : +----------+ : : +----------+ : /: +----+ |ing | : : |ing | : : |ing | +----+ :\
''''''''''''''''''''''''' ''''''''''''''''' '''''''''''''''''''''''' : +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: Note:
1) NMS may be centralised or distributed. Control plane is distributed 1) NMS may be centralised or distributed. Control plane is
2) 'Edge' functions refers to those functions present at the edge of distributed
a PSN domain, e.g. NSP or classification. 2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g. NSP or classification.
3) The control plane may be transported over the server
layer, and LSP or a G-ACh.
Figure 9: MPLS-TP Control Plane Architecture Context Figure 10: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on a combination of the LDP-based The MPLS-TP control plane is based on a combination of the LDP-based
control plane for pseudowires [RFC4447] and the RSVP-TE based control control plane for pseudowires [RFC4447] and the RSVP-TE based control
plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that
are required for LSP signaling for MPLS-TP are based on GMPLS. are required for LSP signaling for MPLS-TP are based on GMPLS.
The distributed MPLS-TP control plane provides the following The distributed MPLS-TP control plane provides the following
functions: functions:
o Signaling o Signaling
skipping to change at page 22, line 20 skipping to change at page 26, line 22
The MPLS-TP control plane supports all MPLS-TP data plane The MPLS-TP control plane supports all MPLS-TP data plane
connectivity patterns that are needed for establishing transport connectivity patterns that are needed for establishing transport
paths including protected paths as described in the survivability paths including protected paths as described in the survivability
section Section 3.10 of this document. Examples of the MPLS-TP data section Section 3.10 of this document. Examples of the MPLS-TP data
plane connectivity patterns are LSPs utilizing the fast reroute plane connectivity patterns are LSPs utilizing the fast reroute
backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or
1:1 protected LSPs. 1:1 protected LSPs.
The MPLS-TP control plane provides functions to ensure its own The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures survivability and to enable it to recover gracefully from failures
and degredations. These include graceful restart and hot redundant and degradations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported, configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data varying degrees of decoupling between the control plane and data
plane may be achieved. plane may be achieved.
3.8.1. PW Control Plane 3.8.1. PW Control Plane
An MPLS-TP network provides many of its transport services using An MPLS-TP network provides many of its transport services using
single-segment or multi-segment pseudowires, in compliance with the single-segment or multi-segment pseudowires, in compliance with the
PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). The PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). The
setup and maintenance of single-segment or multi- segment pseudowires setup and maintenance of single-segment or multi- segment pseudowires
skipping to change at page 22, line 49 skipping to change at page 26, line 51
LSPs). Applicable functions from the Generalized MPLS (GMPLS) LSPs). Applicable functions from the Generalized MPLS (GMPLS)
protocol suite supporting packet-switched capable (PSC) technologies protocol suite supporting packet-switched capable (PSC) technologies
are used as the control plane for MPLS-TP transport paths (LSPs). are used as the control plane for MPLS-TP transport paths (LSPs).
The LSP control plane includes: The LSP control plane includes:
o RSVP-TE for signalling o RSVP-TE for signalling
o OSPF-TE or ISIS-TE for routing o OSPF-TE or ISIS-TE for routing
RSVP-TE signaling in support of GMPLS, as defined in [RFC4872], is RSVP-TE signaling in support of GMPLS, as defined in [RFC3473], is
used for the setup, modification, and release of MPLS-TP transport used for the setup, modification, and release of MPLS-TP transport
paths and protection paths. It supports unidirectional, bi- paths and protection paths. It supports unidirectional, bi-
directional and multicast types of LSPs. The route of a transport directional and multicast types of LSPs. The route of a transport
path is typically calculated in the ingress node of a domain and the path is typically calculated in the ingress node of a domain and the
RSVP explicit route object (ERO) is utilized for the setup of the RSVP explicit route object (ERO) is utilized for the setup of the
transport path exactly following the given route. GMPLS based transport path exactly following the given route. GMPLS based
MPLS-TP LSPs must be able to interoperate with RSVP-TE based MPLS-TE MPLS-TP LSPs must be able to inter-operate with RSVP-TE based MPLS-TE
LSPs, as per [RFC5146] LSPs, as per [RFC5146]
OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used
for carrying link state information in a MPLS-TP network. ISIS-TE for carrying link state information in a MPLS-TP network. ISIS-TE
routing in support of GMPLS as defined in [RFC5307] is used for routing in support of GMPLS as defined in [RFC5307] is used for
carrying link state information in a MPLS-TP network. carrying link state information in a MPLS-TP network.
3.9. Static Operation of LSPs and PWs 3.9. Static Operation of LSPs and PWs
A PW or LSP may be statically configured without the support of a 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. The colateral the PEs/LSRs, or via a network management system. The collateral
damage that loops can cause during the time taken to detect the damage that loops can cause during the time taken to detect the
failure may be severe. When static configuration mechanisms are failure may be severe. When static configuration mechanisms are
used, care must be taken to ensure that loops to not form. used, care must be taken to ensure that loops to not form.
3.10. Survivability 3.10. Survivability
Survivability requirements for MPLS-TP are specified in Survivability requirements for MPLS-TP are specified in
[I-D.ietf-mpls-tp-survive-fwk]. [I-D.ietf-mpls-tp-survive-fwk].
A wide variety of resiliency schemes have been developed to meet the A wide variety of resiliency schemes have been developed to meet the
various network and service survivability objectives. For example, various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels ([RFC4090]), while pseudowire repair using back-up LSP tunnels ([RFC4090]), while pseudowire
redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
protection for the PW can not be fully provided by the PSN layer protection for the PW can not be fully provided by the PSN layer
(i.e. where the backup PW terminates on a different target PE node (i.e. where the backup PW terminates on a different target PE node
than the working PW). Additionally, GMPLS provides a well known set than the working PW). Additionally, GMPLS provides a well known set
of control plane driven protection and restoration mechanisms of control plane driven protection and restoration mechanisms
[RFC4872]. MPLS-TP provides additional protection mechansisms that [RFC4872]. MPLS-TP provides additional protection mechanisms that
are optimised for both linear topologies and ring topologies, and are optimised for both linear topologies and ring topologies, and
that operate in the absense of a dynamic control plane. These are that operate in the absence of a dynamic control plane. These are
specified in [I-D.ietf-mpls-tp-survive-fwk]. specified in [I-D.ietf-mpls-tp-survive-fwk].
Different protection schemes apply to different deployment topologies Different protection schemes apply to different deployment topologies
and operational considerations. Such protection schemes may provide and operational considerations. Such protection schemes may provide
different levels of resiliency. For example, two concurrent traffic different levels of resiliency. For example, two concurrent traffic
paths (1+1), one active and one standby path with guaranteed paths (1+1), one active and one standby path with guaranteed
bandwidth on both paths (1:1) or one active path and a standby path bandwidth on both paths (1:1) or one active path and a standby path
that is shared by one or more other active paths (shared protection). that is shared by one or more other active paths (shared protection).
The applicability of any given scheme to meet specific requirements The applicability of any given scheme to meet specific requirements
is outside the current scope of this document. is outside the current scope of this document.
The characteristics of MPLS-TP resiliency mechanisms are listed The characteristics of MPLS-TP resiliency mechanisms are listed
below. below.
o Optimised for linear, ring or meshed topologies. o Optimised for linear, ring or meshed topologies.
o Use OAM mechanisms to detect and localize network faults or o Use OAM mechanisms to detect and localize network faults or
service degenerations. service degenerations.
skipping to change at page 24, line 14 skipping to change at page 28, line 17
The characteristics of MPLS-TP resiliency mechanisms are listed The characteristics of MPLS-TP resiliency mechanisms are listed
below. below.
o Optimised for linear, ring or meshed topologies. o Optimised for linear, ring or meshed topologies.
o Use OAM mechanisms to detect and localize network faults or o Use OAM mechanisms to detect and localize network faults or
service degenerations. service degenerations.
o Include protection mechanisms to coordinate and trigger protection o Include protection mechanisms to coordinate and trigger protection
switching actions in the absense of a dynamic control plane. This switching actions in the absence of a dynamic control plane. This
is known as an Automatic Protection Switching (APS) mechanism. is known as an Automatic Protection Switching (APS) mechanism.
o MPLS-TP recovery schemes are applicable to all levels in the o MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment
and end-to- end recovery. and end-to- end recovery.
o MPLS-TP recovery mechanisms support the coordination of protection o MPLS-TP recovery mechanisms support the coordination of protection
switching at multiple levels to prevent race conditions occuring switching at multiple levels to prevent race conditions occurring
between a client and its server layer. between a client and its server layer.
o MPLS-TP recovery mechanisms can be data plane, control plane or o MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based. management plane based.
o MPLS-TP supports revertive and non-revertive behavior. o MPLS-TP supports revertive and non-revertive behavior.
3.11. Network Management 3.11. Network Management
The network management architecture and requirements for MPLS-TP are The network management architecture and requirements for MPLS-TP are
skipping to change at page 25, line 37 skipping to change at page 29, line 39
the operational mode is one-time on-demand or is periodic at a the operational mode is one-time on-demand or is periodic at a
specified frequency. specified frequency.
The Performance Management (PM) functions within the EMF of an MPLS- The Performance Management (PM) functions within the EMF of an MPLS-
TP NE support the evaluation and reporting of the behaviour of the TP NE support the evaluation and reporting of the behaviour of the
NEs and the network. One particular requirement for PM is to provide NEs and the network. One particular requirement for PM is to provide
coherent and consistent interpretation of the network behaviour in a coherent and consistent interpretation of the network behaviour in a
hybrid network that uses multiple transport technologies. Packet hybrid network that uses multiple transport technologies. Packet
loss measurement and delay measurements may be collected and used to loss measurement and delay measurements may be collected and used to
detect performance degradation. This is reported via fault detect performance degradation. This is reported via fault
management to enable corrective actions to be taken (e.g. protection management to enable corrective actions to be taken (e.g. Protection
switching), and via performance monitoring for Service Level switching), and via performance monitoring for Service Level
Agreement (SLA) verification and billing. Collection mechanisms for Agreement (SLA) verification and billing. Collection mechanisms for
performance data should be should be capable of operating on-demand performance data should be should be capable of operating on-demand
or proactively. or proactively.
4. Security Considerations 4. Security Considerations
The introduction of MPLS-TP into transport networks means that the The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS and PWE3 apply to security considerations applicable to both MPLS and PWE3 apply to
those transport networks. Furthermore, when general MPLS networks those transport networks. Furthermore, when general MPLS networks
that utilise functionality outside of the strict MPLS-TP profile are that utilise functionality outside of the strict MPLS-TP profile are
used to support packet transport services, the security used to support packet transport services, the security
considerations of that additional functionality also apply. considerations of that additional functionality also apply.
The security considerations of [RFC3985] and The security considerations of [RFC3985] and
[I-D.ietf-pwe3-ms-pw-arch] apply. [I-D.ietf-pwe3-ms-pw-arch] apply.
Each MPLS-TP solution must specify the addtional security Each MPLS-TP solution must specify the additional security
considerations that apply. considerations that apply.
5. IANA Considerations 5. IANA Considerations
IANA considerations resulting from specific elements of MPLS-TP IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that functionality will be detailed in the documents specifying that
functionality. functionality.
This document introduces no additional IANA considerations in itself. This document introduces no additional IANA considerations in itself.
6. Acknowledgements 6. Acknowledgements
The editors wish to thank the following for their contribution to The editors wish to thank the following for their contribution to
this document: this document:
o Rahul Aggarwal
o Dieter Beller o Dieter Beller
o Lou Berger
o Malcolm Betts
o Italo Busi o Italo Busi
o John E Drake
o Hing-Kam Lam o Hing-Kam Lam
o Marc Lasserre o Marc Lasserre
o Vincenzo Sestito o Vincenzo Sestito
o Martin Vigoureux o Martin Vigoureux
o Malcolm Betts
7. References 7. References
7.1. Normative References 7.1. Normative References
[G.7710] "ITU-T Recommendation G.7710/ [G.7710] "ITU-T Recommendation G.7710/
Y.1701 (07/07), "Common Y.1701 (07/07), "Common
equipment management function equipment management function
requirements"", 2005. requirements"", 2005.
[I-D.ietf-mpls-cosfield-def] Andersson, L. and R. Asati,
"Multi-Protocol Label Switching
(MPLS) label stack entry: "EXP"
field renamed to "Traffic
Class" field",
draft-ietf-mpls-cosfield-def-08
(work in progress),
December 2008.
[I-D.ietf-pwe3-ms-pw-arch] Bocci, M. and S. Bryant, "An
Architecture for Multi-Segment
Pseudowire Emulation Edge-to-
Edge",
draft-ietf-pwe3-ms-pw-arch-06
(work in progress),
February 2009.
[I-D.ietf-pwe3-redundancy] Muley, P. and M. Bocci,
"Pseudowire (PW) Redundancy",
draft-ietf-pwe3-redundancy-01
(work in progress),
September 2008.
[RFC2119] Bradner, S., "Key words for use [RFC2119] Bradner, S., "Key words for use
in RFCs to Indicate Requirement in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Levels", BCP 14, RFC 2119,
March 1997. March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and [RFC3031] Rosen, E., Viswanathan, A., and
R. Callon, "Multiprotocol Label R. Callon, "Multiprotocol Label
Switching Architecture", Switching Architecture",
RFC 3031, January 2001. RFC 3031, January 2001.
skipping to change at page 27, line 50 skipping to change at page 31, line 36
Switching (MPLS) Support of Switching (MPLS) Support of
Differentiated Services", Differentiated Services",
RFC 3270, May 2002. RFC 3270, May 2002.
[RFC3471] Berger, L., "Generalized Multi- [RFC3471] Berger, L., "Generalized Multi-
Protocol Label Switching (GMPLS) Protocol Label Switching (GMPLS)
Signaling Functional Signaling Functional
Description", RFC 3471, Description", RFC 3471,
January 2003. January 2003.
[RFC3473] Berger, L., "Generalized Multi-
Protocol Label Switching (GMPLS)
Signaling Resource ReserVation
Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC3985] Bryant, S. and P. Pate, "Pseudo [RFC3985] Bryant, S. and P. Pate, "Pseudo
Wire Emulation Edge-to-Edge Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, (PWE3) Architecture", RFC 3985,
March 2005. March 2005.
[RFC4090] Pan, P., Swallow, G., and A. [RFC4090] Pan, P., Swallow, G., and A.
Atlas, "Fast Reroute Extensions Atlas, "Fast Reroute Extensions
to RSVP-TE for LSP Tunnels", to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005. RFC 4090, May 2005.
[RFC4201] Kompella, K., Rekhter, Y., and
L. Berger, "Link Bundling in
MPLS Traffic Engineering (TE)",
RFC 4201, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, [RFC4203] Kompella, K. and Y. Rekhter,
"OSPF Extensions in Support of "OSPF Extensions in Support of
Generalized Multi-Protocol Label Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4203, Switching (GMPLS)", RFC 4203,
October 2005. October 2005.
[RFC4385] Bryant, S., Swallow, G., [RFC4385] Bryant, S., Swallow, G.,
Martini, L., and D. McPherson, Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to- "Pseudowire Emulation Edge-to-
Edge (PWE3) Control Word for Use Edge (PWE3) Control Word for Use
skipping to change at page 29, line 9 skipping to change at page 32, line 45
(VCCV): A Control Channel for (VCCV): A Control Channel for
Pseudowires", RFC 5085, Pseudowires", RFC 5085,
December 2007. December 2007.
[RFC5307] Kompella, K. and Y. Rekhter, [RFC5307] Kompella, K. and Y. Rekhter,
"IS-IS Extensions in Support of "IS-IS Extensions in Support of
Generalized Multi-Protocol Label Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 5307, Switching (GMPLS)", RFC 5307,
October 2008. October 2008.
[RFC5332] Eckert, T., Rosen, E., Aggarwal,
R., and Y. Rekhter, "MPLS
Multicast Encapsulations",
RFC 5332, August 2008.
[RFC5462] Andersson, L. and R. Asati, [RFC5462] Andersson, L. and R. Asati,
"Multiprotocol Label Switching "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" (MPLS) Label Stack Entry: "EXP"
Field Renamed to "Traffic Class" Field Renamed to "Traffic Class"
Field", RFC 5462, February 2009. Field", RFC 5462, February 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. [RFC5586] Bocci, M., Vigoureux, M., and S.
Bryant, "MPLS Generic Associated Bryant, "MPLS Generic Associated
Channel", RFC 5586, June 2009. Channel", RFC 5586, June 2009.
7.2. Informative References 7.2. Informative References
[I-D.bryant-filsfils-fat-pw] Bryant, S., Filsfils, C., Drafz,
U., Kompella, V., Regan, J., and
S. Amante, "Flow Aware Transport
of MPLS Pseudowires",
draft-bryant-filsfils-fat-pw-03
(work in progress), March 2009.
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K.,
Nadeau, T., and G. Swallow, "BFD Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", For MPLS LSPs",
draft-ietf-bfd-mpls-07 (work in draft-ietf-bfd-mpls-07 (work in
progress), June 2008. progress), June 2008.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, "MPLS [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, "MPLS
TP Network Management TP Network Management
Requirements", Requirements",
draft-ietf-mpls-tp-nm-req-02 draft-ietf-mpls-tp-nm-req-02
skipping to change at page 30, line 25 skipping to change at page 34, line 9
ietf-mpls-tp-survive-fwk-00 ietf-mpls-tp-survive-fwk-00
(work in progress), April 2009. (work in progress), April 2009.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Bitar, [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Bitar,
N., Shah, H., Aissaoui, M., and N., Shah, H., Aissaoui, M., and
F. Balus, "Dynamic Placement of F. Balus, "Dynamic Placement of
Multi Segment Pseudo Wires", Multi Segment Pseudo Wires",
draft-ietf-pwe3-dynamic-ms-pw-09 draft-ietf-pwe3-dynamic-ms-pw-09
(work in progress), March 2009. (work in progress), March 2009.
[I-D.ietf-pwe3-ms-pw-arch] Bocci, M. and S. Bryant, "An
Architecture for Multi-Segment
Pseudowire Emulation Edge-to-
Edge",
draft-ietf-pwe3-ms-pw-arch-06
(work in progress),
February 2009.
[I-D.ietf-pwe3-redundancy] Muley, P. and M. Bocci,
"Pseudowire (PW) Redundancy",
draft-ietf-pwe3-redundancy-01
(work in progress),
September 2008.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz, [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz,
C., Duckett, M., Bocci, M., C., Duckett, M., Bocci, M.,
Balus, F., and M. Aissaoui, Balus, F., and M. Aissaoui,
"Segmented Pseudowire", "Segmented Pseudowire",
draft-ietf-pwe3-segmented-pw-12 draft-ietf-pwe3-segmented-pw-12
(work in progress), June 2009. (work in progress), June 2009.
[RFC4377] Nadeau, T., Morrow, M., Swallow, [RFC4377] Nadeau, T., Morrow, M., Swallow,
G., Allan, D., and S. G., Allan, D., and S.
Matsushima, "Operations and Matsushima, "Operations and
 End of changes. 94 change blocks. 
222 lines changed or deleted 404 lines changed or added

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