draft-ietf-ccamp-mpls-tp-cp-framework-05.txt   draft-ietf-ccamp-mpls-tp-cp-framework-06.txt 
Internet Draft Loa Andersson, Ed. (Ericsson) Internet Draft Loa Andersson, Ed. (Ericsson)
Category: Informational Lou Berger, Ed. (LabN) Category: Informational Lou Berger, Ed. (LabN)
Expiration Date: July 7, 2011 Luyuan Fang, Ed. (Cisco) Expiration Date: August 7, 2011 Luyuan Fang, Ed. (Cisco)
Nabil Bitar, Ed. (Verizon) Nabil Bitar, Ed. (Verizon)
Eric Gray, Ed. (Ericsson) Eric Gray, Ed. (Ericsson)
January 7, 2011 February 7, 2011
MPLS-TP Control Plane Framework MPLS-TP Control Plane Framework
draft-ietf-ccamp-mpls-tp-cp-framework-05.txt draft-ietf-ccamp-mpls-tp-cp-framework-06.txt
Abstract Abstract
The MPLS Transport Profile (MPLS-TP) supports static provisioning The MPLS Transport Profile (MPLS-TP) supports static provisioning
of transport paths via a Network Management System (NMS), and of transport paths via a Network Management System (NMS), and
dynamic provisioning of transport paths via a control plane. This dynamic provisioning of transport paths via a control plane. This
document provides the framework for MPLS-TP dynamic provisioning, document provides the framework for MPLS-TP dynamic provisioning,
and covers control plane addressing, routing, path computation, and covers control plane addressing, routing, path computation,
signaling, traffic engineering, and path recovery. MPLS-TP uses signaling, traffic engineering, and path recovery. MPLS-TP uses
GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses GMPLS as the control plane for MPLS-TP Label Switched Paths
the Pseudowire (PW) control plane for Pseudowires (PWs). (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for
Management plane functions are out of scope of this document. Pseudowires (PWs). Management plane functions are out of scope of
this document.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities (PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T. of a packet transport network as defined by the ITU-T.
This Informational Internet-Draft is aimed at achieving IETF This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF Consensus before publication as an RFC and will be subject to an IETF
skipping to change at page 2, line 13 skipping to change at page 2, line 16
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 July 7, 2011 This Internet-Draft will expire on August 7, 2011
Copyright and License Notice Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 3, line 4
2.5 Identifier Requirements ................................ 24 2.5 Identifier Requirements ................................ 24
3 Relationship of PWs and TE LSPs ........................ 25 3 Relationship of PWs and TE LSPs ........................ 25
4 TE LSPs ................................................ 26 4 TE LSPs ................................................ 26
4.1 GMPLS Functions and MPLS-TP LSPs ....................... 26 4.1 GMPLS Functions and MPLS-TP LSPs ....................... 26
4.1.1 In-Band and Out-Of-Band Control ........................ 26 4.1.1 In-Band and Out-Of-Band Control ........................ 26
4.1.2 Addressing ............................................. 28 4.1.2 Addressing ............................................. 28
4.1.3 Routing ................................................ 28 4.1.3 Routing ................................................ 28
4.1.4 TE LSPs and Constraint-Based Path Computation .......... 28 4.1.4 TE LSPs and Constraint-Based Path Computation .......... 28
4.1.5 Signaling .............................................. 29 4.1.5 Signaling .............................................. 29
4.1.6 Unnumbered Links ....................................... 29 4.1.6 Unnumbered Links ....................................... 29
4.1.7 Link Bundling .......................................... 30 4.1.7 Link Bundling .......................................... 29
4.1.8 Hierarchical LSPs ...................................... 30 4.1.8 Hierarchical LSPs ...................................... 30
4.1.9 LSP Recovery ........................................... 31 4.1.9 LSP Recovery ........................................... 30
4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 31 4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 31
4.2 OAM, MEP (Hierarchy), MIP Configuration and Control .... 31 4.2 OAM, MEP (Hierarchy), MIP Configuration and Control .... 31
4.2.1 Management Plane Support ............................... 32 4.2.1 Management Plane Support ............................... 32
4.3 GMPLS and MPLS-TP Requirements Table ................... 33 4.3 GMPLS and MPLS-TP Requirements Table ................... 33
4.4 Anticipated MPLS-TP Related Extensions and Definitions . 36 4.4 Anticipated MPLS-TP Related Extensions and Definitions . 36
4.4.1 MPLS-TE to MPLS-TP LSP Control Plane Interworking ...... 36 4.4.1 MPLS-TE to MPLS-TP LSP Control Plane Interworking ...... 36
4.4.2 Associated Bidirectional LSPs .......................... 36 4.4.2 Associated Bidirectional LSPs .......................... 36
4.4.3 Asymmetric Bandwidth LSPs .............................. 37 4.4.3 Asymmetric Bandwidth LSPs .............................. 37
4.4.4 Recovery for P2MP LSPs ................................. 37 4.4.4 Recovery for P2MP LSPs ................................. 37
4.4.5 Test Traffic Control and other OAM functions ........... 37 4.4.5 Test Traffic Control and other OAM functions ........... 37
4.4.6 DiffServ Object usage in GMPLS ......................... 38 4.4.6 DiffServ Object usage in GMPLS ......................... 37
4.4.7 Support for MPLS-TP LSP Identifiers .................... 38 4.4.7 Support for MPLS-TP LSP Identifiers .................... 38
4.4.8 Support for MPLS-TP Maintenance Identifiers ............ 38 4.4.8 Support for MPLS-TP Maintenance Identifiers ............ 38
5 Pseudowires ............................................ 38 5 Pseudowires ............................................ 38
5.1 LDP Functions and Pseudowires .......................... 38 5.1 LDP Functions and Pseudowires .......................... 38
5.1.1 Management Plane Support ............................... 39
5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 39 5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 39
5.3 Anticipated MPLS-TP Related Extensions ................. 41 5.3 Anticipated MPLS-TP Related Extensions ................. 42
5.3.1 Extensions to Support Out-of-Band PW Control ........... 42 5.3.1 Extensions to Support Out-of-Band PW Control ........... 42
5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 42 5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 43
5.3.3 Support for Dynamic Transfer of PW Control/Ownership ... 43 5.3.3 Support for Dynamic Transfer of PW Control/Ownership ... 43
5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 43 5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 44
5.3.5 Support for PW Protection and PW OAM Configuration ..... 44 5.3.5 Support for PW Protection and PW OAM Configuration ..... 44
5.3.6 Client Layer and Cross-Provider Interfaces to PW Control.. 45 5.3.6 Client Layer and Cross-Provider Interfaces to PW Control ...45
5.4 ASON Architecture Considerations ....................... 45 5.4 ASON Architecture Considerations ....................... 45
6 Security Considerations ................................ 45 6 Security Considerations ................................ 45
7 IANA Considerations .................................... 46 7 IANA Considerations .................................... 46
8 Acknowledgments ........................................ 46 8 Acknowledgments ........................................ 46
9 References ............................................. 46 9 References ............................................. 46
9.1 Normative References ................................... 46 9.1 Normative References ................................... 46
9.2 Informative References ................................. 49 9.2 Informative References ................................. 49
10 Authors' Addresses ..................................... 54 10 Authors' Addresses ..................................... 54
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) is being defined in a joint The Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP)
effort between the International Telecommunications Union (ITU) and is defined as a joint effort between the International
the IETF. The requirements for MPLS-TP are defined in the Telecommunications Union (ITU) and the IETF. The requirements for
requirements document, see [RFC5654]. These requirements state that MPLS-TP are defined in the requirements document, see [RFC5654].
"A solution MUST be provided to support dynamic provisioning of MPLS- These requirements state that "A solution MUST be provided to support
TP transport paths via a control plane." This document provides the dynamic provisioning of MPLS-TP transport paths via a control plane."
framework for such dynamic provisioning. This document provides the framework for such dynamic provisioning.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and Pseudo Wire Emulation Edge-to-Edge
capabilities and functions of a packet transport network as defined (PWE3) architectures to support the capabilities and functions of a
by the ITU-T. packet transport network as defined by the ITU-T.
1.1. Scope 1.1. Scope
This document covers the control plane functions involved in This document covers the control plane functions involved in
establishing MPLS-TP Label Switched Paths (LSPs) and Pseudowires establishing MPLS-TP Label Switched Paths (LSPs) and Pseudowires
(PWs). The control plane requirements for MPLS-TP are defined in the (PWs). The control plane requirements for MPLS-TP are defined in the
MPLS-TP requirements document [RFC5654]. These requirements define MPLS-TP requirements document [RFC5654]. These requirements define
the role of the control plane in MPLS-TP. In particular, Section 2.4 the role of the control plane in MPLS-TP. In particular, Section 2.4
of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] of [RFC5654] and portions of the remainder of Section 2 of [RFC5654]
provide specific control plane requirements. provide specific control plane requirements.
skipping to change at page 4, line 29 skipping to change at page 4, line 32
The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS
and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to
carry client signals other than IP or MPLS. The relationship between carry client signals other than IP or MPLS. The relationship between
PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs
in an MPLS Packet Switched Network (PSN). The PW encapsulation over in an MPLS Packet Switched Network (PSN). The PW encapsulation over
MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs
over MPLS in an MPLS network. MPLS-TP also defines protection and over MPLS in an MPLS network. MPLS-TP also defines protection and
restoration (or, collectively, recovery) functions, see [RFC5654] and restoration (or, collectively, recovery) functions, see [RFC5654] and
[RFC4427]. The MPLS-TP control plane provides methods to establish, [RFC4427]. The MPLS-TP control plane provides methods to establish,
remove and control MPLS-TP LSPs and PWs. This includes control of remove and control MPLS-TP LSPs and PWs. This includes control of
data plane, OAM and recovery functions. Operations, Administration and Maintenance (OAM), data plane, and
recovery functions.
A general framework for MPLS-TP has been defined in [RFC5921], and a A general framework for MPLS-TP has been defined in [RFC5921], and a
survivability framework for MPLS-TP has been defined in [TP-SURVIVE]. survivability framework for MPLS-TP has been defined in [TP-SURVIVE].
These documents scope the approaches and protocols that are the These documents scope the approaches and protocols that are the
foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the
IETF protocols that serve as the foundation of the MPLS-TP control IETF protocols that serve as the foundation of the MPLS-TP control
plane. The PW control plane is based on the existing PW control plane. The PW control plane is based on the existing PW control
plane, see [RFC4447], and the PW end-to-end (PWE3) architecture, see plane, see [RFC4447], and the PW end-to-end (PWE3) architecture, see
[RFC3985]. The LSP control plane is based on Generalized MPLS [RFC3985]. The LSP control plane is based on Generalized MPLS
(GMPLS), see [RFC3945], which is built on MPLS Traffic Engineering (GMPLS), see [RFC3945], which is built on MPLS Traffic Engineering
(TE) and its numerous extensions. [TP-SURVIVE] focuses on the (TE) and its numerous extensions. [TP-SURVIVE] focuses on the
recovery functions that must be supported within MPLS-TP. It does not recovery functions that must be supported within MPLS-TP. It does not
specify which control plane mechanisms are to be used. specify which control plane mechanisms are to be used.
The remainder of this document discusses the impact of the MPLS-TP The remainder of this document discusses the impact of the MPLS-TP
requirements on the GMPLS signaling and routing protocols that are requirements on the GMPLS signaling and routing protocols that are
used to control MPLS-TP LSPs, and on the control of PWs as specified used to control MPLS-TP LSPs, and on the control of PWs as specified
in [RFC4447], [SEGMENTED-PW], and [MS-PW-DYNAMIC]. in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].
1.2. Basic Approach 1.2. Basic Approach
The basic approach taken in defining the MPLS-TP Control Plane The basic approach taken in defining the MPLS-TP Control Plane
framework is: framework includes the following:
1) MPLS technology as defined by the IETF is the foundation for 1) MPLS technology as defined by the IETF is the foundation for
the MPLS Transport Profile. the MPLS Transport Profile.
2) The data plane for MPLS-TP is a standard MPLS data plane 2) The data plane for MPLS-TP is a standard MPLS data plane
[RFC3031] as profiled in [RFC5960]. [RFC3031] as profiled in [RFC5960].
3) MPLS PWs are used by MPLS-TP including the use of targeted LDP
as the foundation for PW signaling [RFC4447]; and OSPF-TE, 3) MPLS PWs are used by MPLS-TP including the use of targeted
ISIS-TE or MP-BGP as they apply for Multi-Segment(MS)-PW Label Distribution Protocol (LDP) as the foundation for PW
routing. However, the PW can be encapsulated over an MPLS-TP signaling [RFC4447]; and Open Shortest Path First with Traffic
LSP (established using methods and procedures for MPLS-TP LSP Engineering (OSPF-TE), Intermediate System to Intermediate
establishment) in addition to the presently defined methods of System (IS-IS) with Traffic Engineering (ISIS-TE) or
carrying PWs over LSP based packet switched networks (PSNs). Multiprotocol Border Gateway Protocol (MP-BGP) as they apply
That is, the MPLS-TP domain is a packet switched network from a for Multi-Segment Pseudowire (MS-PW) routing. However, the PW
PWE3 architecture perspective [RFC3985]. can be encapsulated over an MPLS-TP LSP (established using
methods and procedures for MPLS-TP LSP establishment) in
addition to the presently defined methods of carrying PWs over
LSP-based packet switched networks (PSNs). That is, the MPLS-TP
domain is a packet switched network from a PWE3 architecture
perspective [RFC3985].
4) The MPLS-TP LSP control plane builds on the GMPLS control plane 4) The MPLS-TP LSP control plane builds on the GMPLS control plane
as defined by the IETF for transport LSPs. The protocols as defined by the IETF for transport LSPs. The protocols
within scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392], within scope are Resource Reservation Protocol with Traffic
and ISIS-TE [RFC5307][RFC5316]. ASON signaling and routing Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203][RFC5392],
requirements in the context of GMPLS can be found in [RFC4139] and ISIS-TE [RFC5307][RFC5316]. Automatically Switched Optical
and [RFC4258]. Network (ASON) signaling and routing requirements in the
context of GMPLS can be found in [RFC4139] and [RFC4258].
5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group 5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group
Internet-Drafts should be reused wherever possible. Internet-Drafts should be reused wherever possible.
6) If needed, extensions for the MPLS-TP control plane should 6) If needed, extensions for the MPLS-TP control plane should
first be based on the existing and evolving IETF work, secondly first be based on the existing and evolving IETF work, secondly
based on work by other standard bodies only when IETF decides based on work by other standard bodies only when IETF decides
that the work is out of the IETF's scope. New extensions may be that the work is out of the IETF's scope. New extensions may be
defined otherwise. defined otherwise.
7) Extensions to the control plane may be required in order to 7) Extensions to the control plane may be required in order to
fully automate MPLS-TP LSP and PW related functions. fully automate MPLS-TP LSP and PW related functions.
8) Control plane software upgrades to existing equipment is 8) Control plane software upgrades to existing equipment is
acceptable and expected. acceptable and expected.
9) It is permissible for functions present in the GMPLS and PW 9) It is permissible for functions present in the GMPLS and PW
control planes to not be used in MPLS-TP networks. control planes to not be used in MPLS-TP networks.
10) One possible use of the control plane is to configure, enable 10) One possible use of the control plane is to configure, enable
and generally control OAM functionality. This will require and generally control OAM functionality. This will require
extensions to existing control plane specifications which will extensions to existing control plane specifications which will
be usable in MPLS-TP as well as MPLS networks. be usable in MPLS-TP as well as MPLS networks.
11) The foundation for MPLS-TP control plane requirements is 11) The foundation for MPLS-TP control plane requirements is
primarily found in Section 2.4 of [RFC5654] and relevant primarily found in Section 2.4 of [RFC5654] and relevant
portions of the remainder Section 2 of [RFC5654]. portions of the remainder Section 2 of [RFC5654].
1.3. Reference Model 1.3. Reference Model
The control plane reference model is based on the general MPLS-TP The control plane reference model is based on the general MPLS-TP
reference model as defined in the MPLS-TP framework [RFC5921]. Per reference model as defined in the MPLS-TP framework [RFC5921] and
the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based further refined in MPLS-TP User-to-Network and Network-to-Network
on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP
signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions framework [RFC5921], the MPLS-TP control plane is based on GMPLS with
is used for dynamic routing within an MPLS-TP domain. RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both
cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic
routing within an MPLS-TP domain.
Note that in this context, "targeted LDP" (or T-LDP) means LDP as Note that in this context, "targeted LDP" (or T-LDP) means LDP as
defined in RFC 5036, using Targeted Hello messages. See Section defined in RFC 5036, using Targeted Hello messages. See Section
2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the 2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the
extended discovery mechanism is specified in [RFC4447] Section 5 extended discovery mechanism is specified in [RFC4447] Section 5
("LDP"). ("LDP").
From a service perspective, MPLS-TP client services may be supported From a service perspective, MPLS-TP client services may be supported
via both PWs and LSPs. PW client interfaces, or adaptations, are via both PWs and LSPs. PW client interfaces, or adaptations, are
defined on an interface technology basis, e.g., Ethernet over PW defined on an interface technology basis, e.g., Ethernet over PW
[RFC4448]. In the context of MPLS-TP LSP, the client interface is [RFC4448]. In the context of MPLS-TP LSP, the client interface is
provided at the network layer and may be controlled via a GMPLS based provided at the network layer and may be controlled via a GMPLS based
UNI, see [RFC4208], or statically provisioned. As discussed in UNI, see [RFC4208], or statically provisioned. As discussed in
[RFC5921], MPLS-TP also presumes an LSP NNI reference point. [RFC5921] and [TP-UNI], MPLS-TP also presumes an NNI reference point.
The MPLS-TP end-to-end control plane reference model is shown in The MPLS-TP end-to-end control plane reference model is shown in
Figure 1. The Figure shows the control plane protocols used by MPLS- Figure 1. The Figure shows the control plane protocols used by MPLS-
TP, as well as the UNI and NNI reference points, in the case of a TP, as well as the UNI and NNI reference points, in the case of a
single segment PW supported by an end-to-end LSP without any single segment PW supported by an end-to-end LSP without any
hierarchical LSPs. (The MS-PW case is not shown.) Each service hierarchical LSPs. (The MS-PW case is not shown.) Each service
provider node's participation in routing and signaling (both GMPLS provider node's participation in routing and signaling (both GMPLS
RSVP-TE and PW LDP) is represented. Note that only the service end RSVP-TE and PW LDP) is represented. Note that only the service end
points participate in PW LDP signaling, while all service provider points participate in PW LDP signaling, while all service provider
nodes participate in GMPLS TE LSP routing and signaling. nodes participate in GMPLS TE LSP routing and signaling.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
PW LDP |< ---------------------------------------- >| PW LDP |< ---------------------------------------- >|
Figure 1. End-to-End MPLS-TP Control Plane Reference Model Figure 1. End-to-End MPLS-TP Control Plane Reference Model
Legend: Legend:
CE: Customer Edge CE: Customer Edge
Client signal: defined in MPLS-TP Requirements Client signal: defined in MPLS-TP Requirements
L2: Any layer 2 signal that may be carried L2: Any layer 2 signal that may be carried
over a PW, e.g. Ethernet. over a PW, e.g. Ethernet.
NNI: Network to Network Interface NNI: Network to Network Interface
P: Provider
PE: Provider Edge PE: Provider Edge
SP: Service Provider SP: Service Provider
TE-RTG: GMPLS OSPF-TE or ISIS-TE TE-RTG: GMPLS OSPF-TE or ISIS-TE
UNI: User to Network Interface UNI: User to Network Interface
Note: The MS-PW case is not shown. Note: The MS-PW case is not shown.
Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs".
These segments are present to support scaling, OAM and Maintenance These segments are present to support scaling, OAM and Maintenance
End Points (MEPs), see [TP-OAM], within each provider domain and Entity End Points (MEPs), see [TP-OAM], within each provider domain
across the inter-provider NNI. (H-LSPs are used to implement Sub- and across the inter-provider NNI. (H-LSPs are used to implement
Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The MEPs Sub-Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The
are used to collect performance information, support diagnostic and MEPs are used to collect performance information, support diagnostic
fault management functions, and support OAM triggered survivability and fault management functions, and support OAM triggered
schemes as discussed in [TP-SURVIVE]. Each H-LSP may be protected or survivability schemes as discussed in [TP-SURVIVE]. Each H-LSP may be
restored using any of the schemes discussed in [TP-SURVIVE]. End-to- protected or restored using any of the schemes discussed in [TP-
end monitoring is supported via MEPs at the End-to-End LSP and PW end SURVIVE]. End-to-end monitoring is supported via MEPs at the End-to-
points. Note that segment MEPs may be collocated with MIPs of the End LSP and PW end points. Note that segment MEPs may be collocated
next higher-layer (e.g., end-to-end) LSPs. (The MS-PW case is not with MIPs of the next higher-layer (e.g., end-to-end) LSPs. (The MS-
shown.) PW case is not shown.)
|< ------- client signal (e.g., IP / MPLS / L2) ----- >| |< ------- client signal (e.g., IP / MPLS / L2) ----- >|
|< -------- SP1 ----------- >|< ------- SP2 ----- >| |< -------- SP1 ----------- >|< ------- SP2 ----- >|
|< ----------- MPLS-TP End-to-End PW -------- >| |< ----------- MPLS-TP End-to-End PW -------- >|
|< ------- MPLS-TP End-to-End LSP ------- >| |< ------- MPLS-TP End-to-End LSP ------- >|
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI UNI NNI UNI
skipping to change at page 8, line 43 skipping to change at page 8, line 43
Figure 2. MPLS-TP Control Plane Reference Model with OAM Figure 2. MPLS-TP Control Plane Reference Model with OAM
Legend: Legend:
CE: Customer Edge CE: Customer Edge
Client signal: defined in MPLS-TP Requirements Client signal: defined in MPLS-TP Requirements
E2E: End-to-end E2E: End-to-end
L2: Any layer 2 signal that may be carried L2: Any layer 2 signal that may be carried
over a PW, e.g. Ethernet. over a PW, e.g. Ethernet.
H-LSP: Hierarchical LSP H-LSP: Hierarchical LSP
MEP: Maintenance end point MEP: Maintenance entity end point
MIP: Maintenance intermediate point MIP: Maintenance intermediate point
NNI: Network to Network Interface NNI: Network to Network Interface
P: Provider
PE: Provider Edge PE: Provider Edge
SP: Service Provider SP: Service Provider
TE-RTG: GMPLS OSPF-TE or ISIS-TE TE-RTG: GMPLS OSPF-TE or ISIS-TE
Note: The MS-PW case is not shown. Note: The MS-PW case is not shown.
While not shown in the Figures above, the MPLS-TP control plane must While not shown in the Figures above, the MPLS-TP control plane must
support the addressing separation and independence between the data, support the addressing separation and independence between the data,
control and management planes. Address separation between the planes control and management planes. Address separation between the planes
is already included in GMPLS. Such separation is also already is already included in GMPLS. Such separation is also already
skipping to change at page 10, line 52 skipping to change at page 10, line 52
of the control plane from the management and data plane, and no of the control plane from the management and data plane, and no
assumptions should be made about the state of the data plane assumptions should be made about the state of the data plane
channels from information about the control or management plane channels from information about the control or management plane
channels when they are running out-of-band [RFC5654, channels when they are running out-of-band [RFC5654,
requirement 16]. requirement 16].
16. A control plane must be defined to support dynamic provisioning 16. A control plane must be defined to support dynamic provisioning
and restoration of MPLS-TP transport paths, but its use is a and restoration of MPLS-TP transport paths, but its use is a
network operator's choice [RFC5654, requirement 18]. network operator's choice [RFC5654, requirement 18].
17. A control plane must not be required to support the static 17. The presence of a control plane must not be required for static
provisioning of MPLS-TP transport paths. [RFC5654, requirement provisioning of MPLS-TP transport paths. [RFC5654, requirement
19]. 19].
18. The MPLS-TP control plane must permit the coexistence of 18. The MPLS-TP control plane must permit the coexistence of
statically and dynamically provisioned/managed MPLS-TP statically and dynamically provisioned/managed MPLS-TP
transport paths within the same layer network or domain transport paths within the same layer network or domain
[RFC5654, requirement 20]. [RFC5654, requirement 20].
19. The MPLS-TP control plane should be operable in a way that is 19. The MPLS-TP control plane should be operable in a way that is
similar to the way the control plane operates in other similar to the way the control plane operates in other
transport-layer technologies [RFC5654, requirement 21]. transport-layer technologies [RFC5654, requirement 21].
20. The MPLS-TP control plane must avoid or minimize traffic impact 20. The MPLS-TP control plane must avoid or minimize traffic impact
(e.g. packet delay, reordering and loss) during network (e.g. packet delay, reordering and loss) during network
reconfiguration [RFC5654, requirement 24]. reconfiguration [RFC5654, requirement 24].
21. The MPLS-TP control plane must work across multiple homogeneous 21. The MPLS-TP control plane must work across multiple homogeneous
domains [RFC5654, requirement 25]. domains [RFC5654, requirement 25], i.e., all domains use the
same MPLS-TP control plane.
22. The MPLS-TP control plane should work across multiple non- 22. The MPLS-TP control plane should work across multiple non-
homogeneous domains [RFC5654, requirement 26]. homogeneous domains [RFC5654, requirement 26], i.e., some
domains use the same control plane and other domains use static
provisioning at the domain boundary.
23. The MPLS-TP control plane must not dictate any particular 23. The MPLS-TP control plane must not dictate any particular
physical or logical topology [RFC5654, requirement 27]. physical or logical topology [RFC5654, requirement 27].
24. The MPLS-TP control plane must include support of ring 24. The MPLS-TP control plane must include support of ring
topologies which may be deployed with arbitrarily topologies which may be deployed with arbitrarily
interconnection, support rings of at least 16 nodes [RFC5654, interconnection, support rings of at least 16 nodes [RFC5654,
requirement 27.A. and 27.B]. requirement 27.A, 27.B and 27.C].
25. The MPLS-TP control plane must scale gracefully to support a 25. The MPLS-TP control plane must scale gracefully to support a
large number of transport paths, nodes and links. That is it large number of transport paths, nodes and links. That is it
must be able to scale at least as well as control planes in must be able to scale at least as well as control planes in
existing transport technologies with growing and increasingly existing transport technologies with growing and increasingly
complex network topologies as well as with increasing bandwidth complex network topologies as well as with increasing bandwidth
demands, number of customers, and number of services [RFC 5654, demands, number of customers, and number of services [RFC 5654,
requirements 53 and 28]. requirements 53 and 28].
26. The MPLS-TP control plane should not provision transport paths 26. The MPLS-TP control plane should not provision transport paths
skipping to change at page 12, line 24 skipping to change at page 12, line 24
MPLS-TP layer network [RFC5654, requirement 33]. MPLS-TP layer network [RFC5654, requirement 33].
31. The MPLS-TP control plane must allow the autonomous operation 31. The MPLS-TP control plane must allow the autonomous operation
of the layers of a multi-layer network that includes an MPLS-TP of the layers of a multi-layer network that includes an MPLS-TP
layer [RFC5654, requirement 34]. layer [RFC5654, requirement 34].
32. The MPLS-TP control plane must allow the hiding of MPLS-TP 32. The MPLS-TP control plane must allow the hiding of MPLS-TP
layer network addressing and other information (e.g. topology) layer network addressing and other information (e.g. topology)
from client layer networks. However, it should be possible, at from client layer networks. However, it should be possible, at
the option of the operator, to leak a limited amount of the option of the operator, to leak a limited amount of
summarized information (such as SRLGs or reachability) between summarized information, such as Shared Risk Link Groups (SRLGs)
layers [RFC5654, requirement 35]. or reachability, between layers [RFC5654, requirement 35].
33. The MPLS-TP control plane must allow for the identification of 33. The MPLS-TP control plane must allow for the identification of
a transport path on each link within and at the destination a transport path on each link within and at the destination
(egress) of the transport network. [RFC5654, requirement 38 and (egress) of the transport network. [RFC5654, requirement 38 and
39]. 39].
34. The MPLS-TP control plane must allow for the use of P2MP server 34. The MPLS-TP control plane must allow for the use of P2MP server
(sub)layer capabilities as well as P2P server (sub)layer (sub)layer capabilities as well as P2P server (sub)layer
capabilities when supporting P2MP MPLS-TP transport paths capabilities when supporting P2MP MPLS-TP transport paths
[RFC5654, requirement 40]. [RFC5654, requirement 40].
skipping to change at page 12, line 52 skipping to change at page 12, line 52
associated with a transport path to be increased without associated with a transport path to be increased without
impacting the existing traffic on that transport path provided impacting the existing traffic on that transport path provided
enough resources are available [RFC5654, requirement 42]. enough resources are available [RFC5654, requirement 42].
37. The MPLS-TP control plane should support the reserved bandwidth 37. The MPLS-TP control plane should support the reserved bandwidth
of a transport path to be decreased without impacting the of a transport path to be decreased without impacting the
existing traffic on that transport path, provided that the existing traffic on that transport path, provided that the
level of existing traffic is smaller than the reserved level of existing traffic is smaller than the reserved
bandwidth following the decrease [RFC5654, requirement 43]. bandwidth following the decrease [RFC5654, requirement 43].
38. Requirement removed. 38. The control plane for MPLS-TP must fit within the ASON (control
plane) architecture. The ITU-T has defined an architecture for
39. The control plane for MPLS-TP must fit within the ASON
architecture. The ITU-T has defined an architecture for
Automatically Switched Optical Networks (ASON) in G.8080 Automatically Switched Optical Networks (ASON) in G.8080
[ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An
interpretation of the ASON signaling and routing requirements interpretation of the ASON signaling and routing requirements
in the context of GMPLS can be found in [RFC4139] and [RFC4258] in the context of GMPLS can be found in [RFC4139] and [RFC4258]
[RFC5654, Section 2.4., Paragraph 2 and 3]. [RFC5654, Section 2.4., Paragraph 2 and 3].
40. The MPLS-TP control plane must support control plane topology 39. The MPLS-TP control plane must support control plane topology
and data plane topology independence [RFC5654, requirement 47]. and data plane topology independence [RFC5654, requirement 47].
41. A failure of the MPLS-TP control plane must not interfere with 40. A failure of the MPLS-TP control plane must not interfere with
the delivery of service or recovery of established transport the delivery of service or recovery of established transport
paths [RFC5654, requirement 47]. paths [RFC5654, requirement 47].
42. The MPLS-TP control plane must be able to operate independent 41. The MPLS-TP control plane must be able to operate independent
of any particular client or server layer control plane of any particular client or server layer control plane
[RFC5654, requirement 48]. [RFC5654, requirement 48].
43. The MPLS-TP control plane should support, but not require, an 42. The MPLS-TP control plane should support, but not require, an
integrated control plane encompassing MPLS-TP together with its integrated control plane encompassing MPLS-TP together with its
server and client layer networks when these layer networks server and client layer networks when these layer networks
belong to the same administrative domain [RFC5654, requirement belong to the same administrative domain [RFC5654, requirement
49]. 49].
44. The MPLS-TP control plane must support configuration of 43. The MPLS-TP control plane must support configuration of
protection functions and any associated maintenance (OAM) protection functions and any associated maintenance (OAM)
functions [RFC5654, requirement 50 and 7]. functions [RFC5654, requirement 50 and 7].
45. The MPLS-TP control plane must support the configuration and 44. The MPLS-TP control plane must support the configuration and
modification of OAM maintenance points as well as the modification of OAM maintenance points as well as the
activation/deactivation of OAM when the transport path or activation/deactivation of OAM when the transport path or
transport service is established or modified [RFC5654, transport service is established or modified [RFC5654,
requirement 51]. requirement 51].
46. The MPLS-TP control plane must be capable of restarting and 45. The MPLS-TP control plane must be capable of restarting and
relearning its previous state without impacting forwarding relearning its previous state without impacting forwarding
[RFC5654, requirement 54]. [RFC5654, requirement 54].
47. The MPLS-TP control plane must provide a mechanism for dynamic 46. The MPLS-TP control plane must provide a mechanism for dynamic
ownership transfer of the control of MPLS-TP transport paths ownership transfer of the control of MPLS-TP transport paths
from the management plane to the control plane and vice versa. from the management plane to the control plane and vice versa.
The number of reconfigurations required in the data plane must The number of reconfigurations required in the data plane must
be minimized (preferably no data plane reconfiguration will be be minimized (preferably no data plane reconfiguration will be
required) [RFC5654, requirement 55]. Note, such transfers cover required) [RFC5654, requirement 55]. Note, such transfers cover
all transport path control functions including control of all transport path control functions including control of
recovery and OAM. recovery and OAM.
48. The MPLS-TP control plane must support protection and 47. The MPLS-TP control plane must support protection and
restoration mechanisms, i.e., recovery [RFC5654, requirement restoration mechanisms, i.e., recovery [RFC5654, requirement
52]. 52].
Note that the MPLS-TP Survivability Framework document, [TP- Note that the MPLS-TP Survivability Framework document, [TP-
SURVIVE], provides additional useful information related to SURVIVE], provides additional useful information related to
recovery. recovery.
49. The MPLS-TP control plane mechanisms should be identical (or as 48. The MPLS-TP control plane mechanisms should be identical (or as
similar as possible) to those already used in existing similar as possible) to those already used in existing
transport networks to simplify implementation and operations. transport networks to simplify implementation and operations.
However, this must not override any other requirement [RFC5654, However, this must not override any other requirement [RFC5654,
requirement 56 A]. requirement 56 A].
50. The MPLS-TP control plane mechanisms used for P2P and P2MP 49. The MPLS-TP control plane mechanisms used for P2P and P2MP
recovery should be identical to simplify implementation and recovery should be identical to simplify implementation and
operation. However, this must not override any other operation. However, this must not override any other
requirement [RFC5654, requirement 56 B]. requirement [RFC5654, requirement 56 B].
51. The MPLS-TP control plane must support recovery mechanisms that 50. The MPLS-TP control plane must support recovery mechanisms that
are applicable at various levels throughout the network are applicable at various levels throughout the network
including support for link, transport path, segment, including support for link, transport path, segment,
concatenated segment and end-to-end recovery [RFC5654, concatenated segment and end-to-end recovery [RFC5654,
requirement 57]. requirement 57].
52. The MPLS-TP control plane must support recovery paths that meet 51. The MPLS-TP control plane must support recovery paths that meet
the SLA protection objectives of the service [RFC5654, the SLA protection objectives of the service [RFC5654,
requirement 58]. Including: requirement 58]. Including:
a. Guarantee 50ms recovery times from the moment of fault a. Guarantee 50ms recovery times from the moment of fault
detection in networks with spans less than 1200 km. detection in networks with spans less than 1200 km.
b. Protection of up to 100% of the traffic on the protected b. Protection of 100% of the traffic on the protected path.
path.
c. Recovery must meet SLA requirements over multiple c. Recovery must meet SLA requirements over multiple
domains. domains.
53. The MPLS-TP control plane should support per transport path 52. The MPLS-TP control plane should support per transport path
Recovery objectives [RFC5654, requirement 59]. Recovery objectives [RFC5654, requirement 59].
54. The MPLS-TP control plane must support recovery mechanisms that 53. The MPLS-TP control plane must support recovery mechanisms that
are applicable to any topology [RFC5654, requirement 60]. are applicable to any topology [RFC5654, requirement 60].
55. The MPLS-TP control plane must operate in synergy with 54. The MPLS-TP control plane must operate in synergy with
(including coordination of timing/timer settings) the recovery (including coordination of timing/timer settings) the recovery
mechanisms present in any client or server transport networks mechanisms present in any client or server transport networks
(for example, Ethernet, SDH, OTN, WDM) to avoid race conditions (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
between the layers [RFC5654, requirement 61]. between the layers [RFC5654, requirement 61].
56. The MPLS-TP control plane must support recovery and reversion 55. The MPLS-TP control plane must support recovery and reversion
mechanisms that prevent frequent operation of recovery in the mechanisms that prevent frequent operation of recovery in the
event of an intermittent defect [RFC5654, requirement 62]. event of an intermittent defect [RFC5654, requirement 62].
57. The MPLS-TP control plane must support revertive and non- 56. The MPLS-TP control plane must support revertive and non-
revertive protection behavior [RFC5654, requirement 64]. revertive protection behavior [RFC5654, requirement 64].
58. The MPLS-TP control plane must support 1+1 bidirectional 57. The MPLS-TP control plane must support 1+1 bidirectional
protection for P2P transport paths [RFC5654, requirement 65 A]. protection for P2P transport paths [RFC5654, requirement 65 A].
59. The MPLS-TP control plane must support 1+1 unidirectional 58. The MPLS-TP control plane must support 1+1 unidirectional
protection for P2P transport paths [RFC5654, requirement 65 B]. protection for P2P transport paths [RFC5654, requirement 65 B].
60. The MPLS-TP control plane must support 1+1 unidirectional 59. The MPLS-TP control plane must support 1+1 unidirectional
protection for P2MP transport paths [RFC5654, requirement 65 protection for P2MP transport paths [RFC5654, requirement 65
C]. C].
61. The MPLS-TP control plane must support the ability to share 60. The MPLS-TP control plane must support the ability to share
protection resources amongst a number of transport paths protection resources amongst a number of transport paths
[RFC5654, requirement 66]. [RFC5654, requirement 66].
62. The MPLS-TP control plane must support 1:n bidirectional 61. The MPLS-TP control plane must support 1:n bidirectional
protection for P2P transport paths, and this should be the protection for P2P transport paths. Bidirectional 1:n
default for 1:n protection [RFC5654, requirement 67 A]. protection should be the default for 1:n protection [RFC5654,
requirement 67 A].
63. The MPLS-TP control plane must support 1:n unidirectional 62. The MPLS-TP control plane must support 1:n unidirectional
protection for P2MP transport paths [RFC5654, requirement 67 protection for P2MP transport paths [RFC5654, requirement 67
B]. B].
64. The MPLS-TP control plane may support 1:n unidirectional 63. The MPLS-TP control plane may support 1:n unidirectional
protection for P2P transport paths [RFC5654, requirement 65 C]. protection for P2P transport paths [RFC5654, requirement 65 C].
65. The MPLS-TP control plane may support extra-traffic [RFC5654, 64. The MPLS-TP control plane may support the control of extra-
note after requirement 67]. traffic type traffic [RFC5654, note after requirement 67].
66. The MPLS-TP control plane should support 1:n (including 1:1) 65. The MPLS-TP control plane should support 1:n (including 1:1)
shared mesh recovery [RFC5654, requirement 68]. shared mesh recovery [RFC5654, requirement 68].
67. The MPLS-TP control plane must support sharing of protection 66. The MPLS-TP control plane must support sharing of protection
resources such that protection paths that are known not to be resources such that protection paths that are known not to be
required concurrently can share the same resources [RFC5654, required concurrently can share the same resources [RFC5654,
requirement 69]. requirement 69].
68. The MPLS-TP control plane must support the sharing of resources 67. The MPLS-TP control plane must support the sharing of resources
between a restoration transport path and the transport path between a restoration transport path and the transport path
being replaced [RFC5654, requirement 70]. being replaced [RFC5654, requirement 70].
69. The MPLS-TP control plane must support restoration priority so 68. The MPLS-TP control plane must support restoration priority so
that an implementation can determine the order in which that an implementation can determine the order in which
transport paths should be restored [RFC5654, requirement 71]. transport paths should be restored [RFC5654, requirement 71].
70. The MPLS-TP control plane must support preemption priority in 69. The MPLS-TP control plane must support preemption priority in
order to allow restoration to displace other transport paths in order to allow restoration to displace other transport paths in
the event of resource constraints [RFC5654, requirement 72 and the event of resource constraints [RFC5654, requirement 72 and
86]. 86].
71. The MPLS-TP control plane must support revertive and non- 70. The MPLS-TP control plane must support revertive and non-
revertive restoration behavior [RFC5654, requirement 73]. revertive restoration behavior [RFC5654, requirement 73].
72. The MPLS-TP control plane must support recovery being triggered 71. The MPLS-TP control plane must support recovery being triggered
by physical (lower) layer fault indications [RFC5654, by physical (lower) layer fault indications [RFC5654,
requirement 74]. requirement 74].
73. The MPLS-TP control plane must support recovery being triggered 72. The MPLS-TP control plane must support recovery being triggered
by OAM [RFC5654, requirement 75]. by OAM [RFC5654, requirement 75].
74. The MPLS-TP control plane must support management plane 73. The MPLS-TP control plane must support management plane
recovery triggers (e.g., forced switch, etc.) [RFC5654, recovery triggers (e.g., forced switch, etc.) [RFC5654,
requirement 76]. requirement 76].
75. The MPLS-TP control plane must support the differentiation of 74. The MPLS-TP control plane must support the differentiation of
administrative recovery actions from recovery actions initiated administrative recovery actions from recovery actions initiated
by other triggers [RFC5654, requirement 77]. by other triggers [RFC5654, requirement 77].
76. The MPLS-TP control plane should support control plane 75. The MPLS-TP control plane should support control plane
restoration triggers (e.g., forced switch, etc.) [RFC5654, restoration triggers (e.g., forced switch, etc.) [RFC5654,
requirement 78]. requirement 78].
77. The MPLS-TP control plane must support priority logic to 76. The MPLS-TP control plane must support priority logic to
negotiate and accommodate coexisting requests (i.e., multiple negotiate and accommodate coexisting requests (i.e., multiple
requests) for protection switching (e.g., administrative requests) for protection switching (e.g., administrative
requests and requests due to link/node failures) [RFC5654, requests and requests due to link/node failures) [RFC5654,
requirement 79]. requirement 79].
78. The MPLS-TP control plane must support the association of 77. The MPLS-TP control plane must support the association of
protection paths and working paths (sometimes known as protection paths and working paths (sometimes known as
protection groups) [RFC5654, requirement 80]. protection groups) [RFC5654, requirement 80].
79. The MPLS-TP control plane must support pre-calculation of 78. The MPLS-TP control plane must support pre-calculation of
recovery paths [RFC5654, requirement 81]. recovery paths [RFC5654, requirement 81].
80. The MPLS-TP control plane must support pre-provisioning of 79. The MPLS-TP control plane must support pre-provisioning of
recovery paths [RFC5654, requirement 82]. recovery paths [RFC5654, requirement 82].
81. The MPLS-TP control plane must support the external commands 80. The MPLS-TP control plane must support the external commands
defined in [RFC4427]. External controls overruled by higher defined in [RFC4427]. External controls overruled by higher
priority requests (e.g., administrative requests and requests priority requests (e.g., administrative requests and requests
due to link/node failures) or unable to be signaled to the due to link/node failures) or unable to be signaled to the
remote end (e.g. because of a protection state coordination remote end (e.g. because of a protection state coordination
fail) must be ignored/dropped [RFC5654, requirement 83]. fail) must be ignored/dropped [RFC5654, requirement 83].
82. The MPLS-TP control plane must permit the testing and 81. The MPLS-TP control plane must permit the testing and
validation of the integrity of the protection/recovery validation of the integrity of the protection/recovery
transport path [RFC5654, requirement 84 A]. transport path [RFC5654, requirement 84 A].
83. The MPLS-TP control plane must permit the testing and 82. The MPLS-TP control plane must permit the testing and
validation of protection/restoration mechanisms without validation of protection/restoration mechanisms without
triggering the actual protection/restoration [RFC5654, triggering the actual protection/restoration [RFC5654,
requirement 84 B]. requirement 84 B].
84. The MPLS-TP control plane must permit the testing and 83. The MPLS-TP control plane must permit the testing and
validation of protection/restoration mechanisms while the validation of protection/restoration mechanisms while the
working path is in service [RFC5654, requirement 84 C]. working path is in service [RFC5654, requirement 84 C].
85. The MPLS-TP control plane must permit the testing and 84. The MPLS-TP control plane must permit the testing and
validation of protection/restoration mechanisms while the validation of protection/restoration mechanisms while the
working path is out of service [RFC5654, requirement 84 D]. working path is out of service [RFC5654, requirement 84 D].
86. The MPLS-TP control plane must support the establishment and 85. The MPLS-TP control plane must support the establishment and
maintenance of all recovery entities and functions [RFC5654, maintenance of all recovery entities and functions [RFC5654,
requirement 89 A]. requirement 89 A].
87. The MPLS-TP control plane must support signaling of recovery 86. The MPLS-TP control plane must support signaling of recovery
administrative control [RFC5654, requirement 89 B]. administrative control [RFC5654, requirement 89 B].
88. The MPLS-TP control plane must support protection state 87. The MPLS-TP control plane must support protection state
coordination (PSC). Since control plane network topology is coordination (PSC). Since control plane network topology is
independent from the data plane network topology, the PSC independent from the data plane network topology, the PSC
supported by the MPLS-TP control plane may run on resources supported by the MPLS-TP control plane may run on resources
different than the data plane resources handled within the different than the data plane resources handled within the
recovery mechanism (e.g. backup) [RFC5654, requirement 89 C]. recovery mechanism (e.g. backup) [RFC5654, requirement 89 C].
89. When present, the MPLS-TP control plane must support recovery 88. When present, the MPLS-TP control plane must support recovery
mechanisms that are optimized for specific network topologies. mechanisms that are optimized for specific network topologies.
These mechanisms must be interoperable with the mechanisms These mechanisms must be interoperable with the mechanisms
defined for arbitrary topology (mesh) networks to enable defined for arbitrary topology (mesh) networks to enable
protection of end-to-end transport paths [RFC5654, requirement protection of end-to-end transport paths [RFC5654, requirement
91]. 91].
90. When present, the MPLS-TP control plane must support the 89. When present, the MPLS-TP control plane must support the
control of ring topology specific recovery mechanisms [RFC5654, control of ring topology specific recovery mechanisms [RFC5654,
Section 2.5.6.1]. Section 2.5.6.1].
91. The MPLS-TP control plane must include support for 90. The MPLS-TP control plane must include support for
differentiated services and different traffic types with differentiated services and different traffic types with
traffic class separation associated with different traffic traffic class separation associated with different traffic
[RFC5654, requirement 110]. [RFC5654, requirement 110].
92. The MPLS-TP control plane must support the provisioning of 91. The MPLS-TP control plane must support the provisioning of
services that provide guaranteed Service Level Specifications services that provide guaranteed Service Level Specifications
(SLS), with support for hard ([RFC3209] style) and relative (SLS), with support for hard ([RFC3209] style) and relative
([RFC3270] style) end-to-end bandwidth guarantees [RFC5654, ([RFC3270] style) end-to-end bandwidth guarantees [RFC5654,
requirement 111]. requirement 111].
93. The MPLS-TP control plane must support the provisioning of 92. The MPLS-TP control plane must support the provisioning of
services which are sensitive to jitter and delay [RFC5654, services which are sensitive to jitter and delay [RFC5654,
requirement 112]. requirement 112].
2.2. MPLS-TP Framework Derived Requirements 2.2. MPLS-TP Framework Derived Requirements
The following additional requirements are based on [RFC5921], [TP- The following additional requirements are based on [RFC5921], [TP-
P2MP-FWK] and [RFC5960]: P2MP-FWK] and [RFC5960]:
94. Per-packet equal cost multi-path (ECMP) load balancing is 93. Per-packet equal cost multi-path (ECMP) load balancing is
currently outside the scope of MPLS-TP [TP-DATA-PLANE , section currently outside the scope of MPLS-TP [RFC5960 , section
3.1.1., paragraph 6]. 3.1.1., paragraph 6].
95. Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by 94. Penultimate hop popping (PHP) must be disabled on MPLS-TP LSPs
default. [TP-DATA-PLANE , section 3.1.1., paragraph 7]. by default. [RFC5960 , section 3.1.1., paragraph 7].
96. The MPLS-TP control plane must support both E-LSP and L-LSP 95. The MPLS-TP control plane must support both E-LSP and L-LSP
MPLS DiffServ modes as specified in [RFC3270] [TP-DATA-PLANE , MPLS DiffServ modes as specified in [RFC3270] [RFC5960 ,
section 3.3.2., paragraph 12]. section 3.3.2., paragraph 12].
97. Both single-segment, see [RFC3985], and multi-segment PWs, see 96. Both single-segment, see [RFC3985], and multi-segment PWs, see
[RFC5659], shall be supported by the MPLS-TP control plane. [RFC5659], shall be supported by the MPLS-TP control plane.
MPLS-TP shall use the definition of multi-segment PWs as MPLS-TP shall use the definition of multi-segment PWs as
defined by the IETF [RFC5921, section 3.4.4]. defined by the IETF [RFC5921, section 3.4.4].
98. The MPLS-TP control plane must support the control of PWs and 97. The MPLS-TP control plane must support the control of PWs and
their associated labels [RFC5921, section 3.4.4]. their associated labels [RFC5921, section 3.4.4].
99. The MPLS-TP control plane must support network layer clients, 98. The MPLS-TP control plane must support network layer clients,
i.e., clients whose traffic is transported over an MPLS-TP i.e., clients whose traffic is transported over an MPLS-TP
network without the use of PWs [RFC5921, section 3.4.5]. network without the use of PWs [RFC5921, section 3.4.5].
a. The MPLS-TP control plane must support the use of network a. The MPLS-TP control plane must support the use of network
layer protocol-specific LSPs and labels. [RFC5921, layer protocol-specific LSPs and labels. [RFC5921,
section 3.4.5.] section 3.4.5.]
b. The MPLS-TP control plane must support the use of a b. The MPLS-TP control plane must support the use of a
client service-specific LSPs and labels. [RFC5921, client service-specific LSPs and labels. [RFC5921,
section 3.4.5.] section 3.4.5.]
100. The MPLS-TP control plane for LSPs is based on the GMPLS 99. The MPLS-TP control plane for LSPs must be based on the GMPLS
control plane. More specifically, GMPLS RSVP-TE [RFC3473] and control plane. More specifically, GMPLS RSVP-TE [RFC3473] and
related extensions are used for LSP signaling, and GMPLS OSPF- related extensions are used for LSP signaling, and GMPLS OSPF-
TE [RFC5392] and ISIS-TE [RFC5316] are used for routing TE [RFC5392] and ISIS-TE [RFC5316] are used for routing
[RFC5921, section 3.9]. [RFC5921, section 3.9].
101. The MPLS-TP control plane for PWs is based on the MPLS control 100. The MPLS-TP control plane for PWs must be based on the MPLS
plane for PWs, and more specifically, targeted LDP (T-LDP) control plane for PWs, and more specifically, targeted LDP (T-
[RFC4447] is used for PW signaling [RFC5921, section 3.9., LDP) [RFC4447] is used for PW signaling [RFC5921, section 3.9.,
paragraph 5]. paragraph 5].
102. The MPLS-TP control plane must ensure its own survivability and 101. The MPLS-TP control plane must ensure its own survivability and
to enable it to recover gracefully from failures and to enable it to recover gracefully from failures and
degradations. These include graceful restart and hot redundant degradations. These include graceful restart and hot redundant
configurations [RFC5921, section 3.9., paragraph 16]. configurations [RFC5921, section 3.9., paragraph 16].
103. The MPLS-TP control plane must support linear, ring and meshed 102. The MPLS-TP control plane must support linear, ring and meshed
protection schemes [RFC5921, section 3.12., paragraph 3]. protection schemes [RFC5921, section 3.12., paragraph 3].
104. The MPLS-TP control plane must support the control of SPMEs 103. The MPLS-TP control plane must support the control of SPMEs
(hierarchical LSPs) for new or existing end-to-end LSPs (hierarchical LSPs) for new or existing end-to-end LSPs
[RFC5921, section 3.12., paragraph 7]. [RFC5921, section 3.12., paragraph 7].
2.3. OAM Framework Derived Requirements 2.3. OAM Framework Derived Requirements
The following additional requirements are based on [RFC5860] and [TP- The following additional requirements are based on [RFC5860] and [TP-
OAM]: OAM]:
105. The MPLS-TP control plane must support the capability to 104. The MPLS-TP control plane must support the capability to
enable/disable OAM functions as part of service establishment enable/disable OAM functions as part of service establishment
[RFC5860, section 2.1.6., paragraph 1]. Note that OAM functions [RFC5860, section 2.1.6., paragraph 1]. Note that OAM functions
are applicable regardless of the label stack depth (i.e., level are applicable regardless of the label stack depth (i.e., level
of LSP hierarchy or PW) [RFC5860, section 2.1.1., paragraph 3]. of LSP hierarchy or PW) [RFC5860, section 2.1.1., paragraph 3].
106. The MPLS-TP control plane must support the capability to 105. The MPLS-TP control plane must support the capability to
enable/disable OAM functions after service establishment. In enable/disable OAM functions after service establishment. In
such cases, the customer must not perceive service degradation such cases, the customer must not perceive service degradation
as a result of OAM enabling/disabling [RFC5860, section 2.1.6., as a result of OAM enabling/disabling [RFC5860, section 2.1.6.,
paragraph 1 and 2]. paragraph 1 and 2].
107. The MPLS-TP control plane must support dynamic control of any 106. The MPLS-TP control plane must support dynamic control of any
of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping
[RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD
[RFC5885]) [RFC5860, section 2.1.4., paragraph 2]. [RFC5885]) [RFC5860, section 2.1.4., paragraph 2].
108. The MPLS-TP control plane must allow for the ability to support 107. The MPLS-TP control plane must allow for the ability to support
experimental OAM functions. These functions must be disabled experimental OAM functions. These functions must be disabled
by default [RFC5860, section 2.2., paragraph 2]. by default [RFC5860, section 2.2., paragraph 2].
109. The MPLS-TP control plane must support the choice of which (if 108. The MPLS-TP control plane must support the choice of which (if
any) OAM function(s) to use and to which PW, LSP or Section it any) OAM function(s) to use and to which PW, LSP or Section it
applies [RFC5860, section 2.2., paragraph 3]. applies [RFC5860, section 2.2., paragraph 3].
110. The MPLS-TP control plane must allow (e.g., enable/disable) 109. The MPLS-TP control plane must allow (e.g., enable/disable)
mechanisms that support the localization of faults and the mechanisms that support the localization of faults and the
notification of appropriate nodes. [RFC5860, section 2.2.1., notification of appropriate nodes. [RFC5860, section 2.2.1.,
paragraph 1]. paragraph 1].
111. The MPLS-TP control plane may support mechanisms that permit 110. The MPLS-TP control plane may support mechanisms that permit
the service provider to be informed of a fault or defect the service provider to be informed of a fault or defect
affecting the service(s) it provides, even if the fault or affecting the service(s) it provides, even if the fault or
defect is located outside of his domain [RFC5860, section defect is located outside of his domain [RFC5860, section
2.2.1., paragraph 2]. 2.2.1., paragraph 2].
112. Information exchange between various nodes involved in the 111. Information exchange between various nodes involved in the
MPLS-TP control plane should be reliable such that, for MPLS-TP control plane should be reliable such that, for
example, defects or faults are properly detected or that state example, defects or faults are properly detected or that state
changes are effectively known by the appropriate nodes changes are effectively known by the appropriate nodes
[RFC5860, section 2.2.1., paragraph 3]. [RFC5860, section 2.2.1., paragraph 3].
113. The MPLS-TP control plane must provide functionality to control 112. The MPLS-TP control plane must provide functionality to control
an End Point's ability to monitor the liveness of a PW, LSP, or an End Point's ability to monitor the liveness of a PW, LSP, or
Section [RFC5860, section 2.2.2., paragraph 1]. Section [RFC5860, section 2.2.2., paragraph 1].
114. The MPLS-TP control plane must provide functionality to control 113. The MPLS-TP control plane must provide functionality to control
an End Point's ability to determine whether or not it is an End Point's ability to determine whether or not it is
connected to specific End Point(s) by means of the expected PW, connected to specific End Point(s) by means of the expected PW,
LSP, or Section [RFC5860, section 2.2.3., paragraph 1]. LSP, or Section [RFC5860, section 2.2.3., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control an End Point's ability to perform this function control an End Point's ability to perform this function
proactively [RFC5860, section 2.2.3., paragraph 2]. proactively [RFC5860, section 2.2.3., paragraph 2].
b. The MPLS-TP control plane must provide mechanisms to b. The MPLS-TP control plane must provide mechanisms to
control an End Point's ability to perform this function control an End Point's ability to perform this function
on-demand [RFC5860, section 2.2.3., paragraph 3]. on-demand [RFC5860, section 2.2.3., paragraph 3].
115. The MPLS-TP control plane must provide functionality to control 114. The MPLS-TP control plane must provide functionality to control
diagnostic testing on a PW, LSP or Section [RFC5860, section diagnostic testing on a PW, LSP or Section [RFC5860, section
2.2.5., paragraph 1]. 2.2.5., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function on-demand control the performance of this function on-demand
[RFC5860, section 2.2.5., paragraph 2]. [RFC5860, section 2.2.5., paragraph 2].
116. The MPLS-TP control plane must provide functionality to enable 115. The MPLS-TP control plane must provide functionality to enable
an End Point to discover the Intermediate (if any) and End an End Point to discover the Intermediate (if any) and End
Point(s) along a PW, LSP or Section, and more generally to Point(s) along a PW, LSP or Section, and more generally to
trace (record) the route of a PW, LSP or Section [RFC5860, trace (record) the route of a PW, LSP or Section [RFC5860,
section 2.2.4., paragraph 1]. section 2.2.4., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function on-demand control the performance of this function on-demand
[RFC5860, section 2.2.4., paragraph 2]. [RFC5860, section 2.2.4., paragraph 2].
117. The MPLS-TP control plane must provide functionality to enable 116. The MPLS-TP control plane must provide functionality to enable
an End Point of a PW, LSP or Section to instruct its associated an End Point of a PW, LSP or Section to instruct its associated
End Point(s) to lock the PW, LSP or Section [RFC5860, section End Point(s) to lock the PW, LSP or Section [RFC5860, section
2.2.6., paragraph 1]. 2.2.6., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function on-demand control the performance of this function on-demand
[RFC5860, section 2.2.6., paragraph 2]. [RFC5860, section 2.2.6., paragraph 2].
118. The MPLS-TP control plane must provide functionality to enable 117. The MPLS-TP control plane must provide functionality to enable
an Intermediate Point of a PW or LSP to report, to an End Point an Intermediate Point of a PW or LSP to report, to an End Point
of that same PW or LSP, a lock condition indirectly affecting of that same PW or LSP, a lock condition indirectly affecting
that PW or LSP [RFC5860, section 2.2.7., paragraph 1]. that PW or LSP [RFC5860, section 2.2.7., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively control the performance of this function proactively
[RFC5860, section 2.2.7., paragraph 2]. [RFC5860, section 2.2.7., paragraph 2].
119. The MPLS-TP control plane must provide functionality to enable 118. The MPLS-TP control plane must provide functionality to enable
an Intermediate Point of a PW or LSP to report, to an End Point an Intermediate Point of a PW or LSP to report, to an End Point
of that same PW or LSP, a fault or defect condition affecting of that same PW or LSP, a fault or defect condition affecting
that PW or LSP [RFC5860, section 2.2.8., paragraph 1]. that PW or LSP [RFC5860, section 2.2.8., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively control the performance of this function proactively
[RFC5860, section 2.2.8., paragraph 2]. [RFC5860, section 2.2.8., paragraph 2].
120. The MPLS-TP control plane must provide functionality to enable 119. The MPLS-TP control plane must provide functionality to enable
an End Point to report, to its associated End Point, a fault or an End Point to report, to its associated End Point, a fault or
defect condition that it detects on a PW, LSP or Section for defect condition that it detects on a PW, LSP or Section for
which they are the End Points [RFC5860, section 2.2.9., which they are the End Points [RFC5860, section 2.2.9.,
paragraph 1]. paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively control the performance of this function proactively
[RFC5860, section 2.2.9., paragraph 2]. [RFC5860, section 2.2.9., paragraph 2].
121. The MPLS-TP control plane must provide functionality to enable 120. The MPLS-TP control plane must provide functionality to enable
the propagation, across an MPLS-TP network, of information the propagation, across an MPLS-TP network, of information
pertaining to a client defect or fault condition detected at an pertaining to a client defect or fault condition detected at an
End Point of a PW or LSP, if the client layer mechanisms do not End Point of a PW or LSP, if the client layer mechanisms do not
provide an alarm notification/propagation mechanism [RFC5860, provide an alarm notification/propagation mechanism [RFC5860,
section 2.2.10., paragraph 1]. section 2.2.10., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively control the performance of this function proactively
[RFC5860, section 2.2.10., paragraph 2]. [RFC5860, section 2.2.10., paragraph 2].
122. The MPLS-TP control plane must provide functionality to enable 121. The MPLS-TP control plane must provide functionality to enable
the control of quantification of packet loss ratio over a PW, the control of quantification of packet loss ratio over a PW,
LSP or Section [RFC5860, section 2.2.11., paragraph 1]. LSP or Section [RFC5860, section 2.2.11., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively and control the performance of this function proactively and
on-demand [RFC5860, section 2.2.11., paragraph 4]. on-demand [RFC5860, section 2.2.11., paragraph 4].
123. The MPLS-TP control plane must provide functionality to control 122. The MPLS-TP control plane must provide functionality to control
the quantification and reporting of the one-way, and if the quantification and reporting of the one-way, and if
appropriate, the two-way, delay of a PW, LSP or Section appropriate, the two-way, delay of a PW, LSP or Section
[RFC5860, section 2.2.12., paragraph 1]. [RFC5860, section 2.2.12., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively and control the performance of this function proactively and
on-demand [RFC5860, section 2.2.12., paragraph 6]. on-demand [RFC5860, section 2.2.12., paragraph 6].
124. The MPLS-TP control plane must support the configuration of OAM 123. The MPLS-TP control plane must support the configuration of OAM
functional components which include MEs and MEGs as functional components which include Maintenance Entities (MEs)
instantiated in MEPs, MIPs and SPMEs [TP-OAM, section 3.6]. and Maintenance Entity Groups (MEGs) as instantiated in MEPs,
MIPs and SPMEs [TP-OAM, section 3.6].
125. For dynamically established transport paths, the control plane 124. For dynamically established transport paths, the control plane
must support the configuration of OAM operations [TP-OAM, must support the configuration of OAM operations [TP-OAM,
section 5]. section 5].
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
configure proactive monitoring for a MEG at, or after, configure proactive monitoring for a MEG at, or after,
transport path creation time. transport path creation time.
b. The MPLS-TP control plane must provide mechanisms to b. The MPLS-TP control plane must provide mechanisms to
configure the operational characteristics of in-band configure the operational characteristics of in-band
measurement transactions (e.g., CV, LM etc.) are measurement transactions (e.g., CV, LM etc.) are
skipping to change at page 22, line 52 skipping to change at page 22, line 41
path). path).
c. The MPLS-TP control plane may provide mechanisms to c. The MPLS-TP control plane may provide mechanisms to
configure server layer event reporting by intermediate configure server layer event reporting by intermediate
nodes. nodes.
d. The MPLS-TP control plane may provide mechanisms to d. The MPLS-TP control plane may provide mechanisms to
configure the reporting of measurements resulting from configure the reporting of measurements resulting from
proactive monitoring. proactive monitoring.
126. The MPLS-TP control plane must support the control of the loss 125. The MPLS-TP control plane must support the control of the loss
of continuity (LOC) traffic block consequent action [TP-OAM, of continuity (LOC) traffic block consequent action [TP-OAM,
section 5.1.2., paragraph 4]. section 5.1.2., paragraph 4].
127. For dynamically established transport paths that have a 126. For dynamically established transport paths that have a
proactive CC-V function enabled, the control plane must support proactive Continuity Check and Connectivity Verification (CC-V)
the signaling of the following MEP configuration information function enabled, the control plane must support the signaling
[TP-OAM, section 5.1.3]: of the following MEP configuration information [TP-OAM, section
5.1.3]:
a. The MPLS-TP control plane must provide mechanisms to a. The MPLS-TP control plane must provide mechanisms to
configure the MEG identifier to which the MEP belongs. configure the MEG identifier to which the MEP belongs.
b. The MPLS-TP control plane must provide mechanisms to b. The MPLS-TP control plane must provide mechanisms to
configure a MEP's own identity inside a MEG. configure a MEP's own identity inside a MEG.
c. The MPLS-TP control plane must provide mechanisms to c. The MPLS-TP control plane must provide mechanisms to
configure the list of the other MEPs in the MEG. configure the list of the other MEPs in the MEG.
d. The MPLS-TP control plane must provide mechanisms to d. The MPLS-TP control plane must provide mechanisms to
configure the CC-V transmission rate / reception period configure the CC-V transmission rate / reception period
(covering all application types). (covering all application types).
128. The MPLS-TP control plane must provide mechanisms to configure 127. The MPLS-TP control plane must provide mechanisms to configure
the generation of Alarm Indication Signal (AIS) packets for the generation of Alarm Indication Signal (AIS) packets for
each MEG [TP-OAM, section 5.3., paragraph 9]. each MEG [TP-OAM, section 5.3., paragraph 9].
129. The MPLS-TP control plane must provide mechanisms to configure 128. The MPLS-TP control plane must provide mechanisms to configure
the generation of Locked Report (LKR) packets for each MEG [TP- the generation of Locked Report (LKR) packets for each MEG [TP-
OAM, section 5.4., paragraph 9]. OAM, section 5.4., paragraph 9].
130. The MPLS-TP control plane must provide mechanisms to configure 129. The MPLS-TP control plane must provide mechanisms to configure
the use of proactive Packet Loss Measurement (LM), and the the use of proactive Packet Loss Measurement (LM), and the
transmission rate and PHB class associated with the LM OAM transmission rate and Per-hop Behavior (PHB) class associated
packets originating from a MEP [TP-OAM, section 5.5.1., with the LM OAM packets originating from a MEP [TP-OAM, section
paragraph 1]. 5.5.1., paragraph 1].
131. The MPLS-TP control plane must provide mechanisms to configure 130. The MPLS-TP control plane must provide mechanisms to configure
the use of proactive Packet Delay Measurement (DM), and the the use of proactive Packet Delay Measurement (DM), and the
transmission rate and PHB class associated with the DM OAM transmission rate and PHB class associated with the DM OAM
packets originating from a MEP [TP-OAM, section 5.6.1., packets originating from a MEP [TP-OAM, section 5.6.1.,
paragraph 1]. paragraph 1].
132. The MPLS-TP control plane must provide mechanisms to configure 131. The MPLS-TP control plane must provide mechanisms to configure
the use of Client Failure Indication (CFI), and the the use of Client Failure Indication (CFI), and the
transmission rate and PHB class associated with the CFI OAM transmission rate and PHB class associated with the CFI OAM
packets originating from a MEP [TP-OAM, section 5.7.1., packets originating from a MEP [TP-OAM, section 5.7.1.,
paragraph 1]. paragraph 1].
133. The MPLS-TP control plane should provide mechanisms to control 132. The MPLS-TP control plane should provide mechanisms to control
the use of on-demand CV packets [TP-OAM, section 6.1]. the use of on-demand CV packets [TP-OAM, section 6.1].
a. The MPLS-TP control plane should provide mechanisms to a. The MPLS-TP control plane should provide mechanisms to
configure the number of packets to be configure the number of packets to be
transmitted/received in each burst of on-demand CV transmitted/received in each burst of on-demand CV
packets and their packet size [TP-OAM, section 6.1.1, packets and their packet size [TP-OAM, section 6.1.1,
paragraph 1]. paragraph 1].
b. When an on-demand CV packet is used to check connectivity b. When an on-demand CV packet is used to check connectivity
toward a target MIP, the MPLS-TP control plane should toward a target MIP, the MPLS-TP control plane should
provide mechanisms to configure the number of hops to provide mechanisms to configure the number of hops to
reach the target MIP [TP-OAM, section 6.1.1, paragraph reach the target MIP [TP-OAM, section 6.1.1, paragraph
2]. 2].
c. The MPLS-TP control plane should provide mechanisms to c. The MPLS-TP control plane should provide mechanisms to
configure the PHB of on-demand CV packets [TP-OAM, configure the PHB of on-demand CV packets [TP-OAM,
section 6.1.1, paragraph 3]. section 6.1.1, paragraph 3].
134. The MPLS-TP control plane should provide mechanisms to control 133. The MPLS-TP control plane should provide mechanisms to control
the use of on-demand LM, including configuration of the the use of on-demand LM, including configuration of the
beginning and duration of the LM procedures, the transmission beginning and duration of the LM procedures, the transmission
rate and PHB associated with the LM OAM packets originating rate and PHB associated with the LM OAM packets originating
from a MEP. [TP-OAM, section 6.2.1.] from a MEP. [TP-OAM, section 6.2.1.]
135. The MPLS-TP control plane should provide mechanisms to control 134. The MPLS-TP control plane should provide mechanisms to control
the use of Throughput estimation [TP-OAM, section 6.3.1]. the use of Throughput estimation [TP-OAM, section 6.3.1].
136. The MPLS-TP control plane should provide mechanisms to control 135. The MPLS-TP control plane should provide mechanisms to control
the use of on-demand DM, including configuration of the the use of on-demand DM, including configuration of the
beginning and duration of the DM procedures, the transmission beginning and duration of the DM procedures, the transmission
rate and PHB associated with the DM OAM packets originating rate and PHB associated with the DM OAM packets originating
from a MEP. [TP-OAM, section 6.5.1.] from a MEP. [TP-OAM, section 6.5.1.]
2.4. Security Requirements 2.4. Security Requirements
There are no specific MPLS-TP control plane security requirements. There are no specific MPLS-TP control plane security requirements.
The existing framework for MPLS and GMPLS security is documented in The existing framework for MPLS and GMPLS security is documented in
[RFC5920] and that document applies equally to MPLS-TP. [RFC5920] and that document applies equally to MPLS-TP.
2.5. Identifier Requirements 2.5. Identifier Requirements
The following are requirements based on [TP-IDENTIFIERS]: The following are requirements based on [TP-IDENTIFIERS]:
137. The MPLS-TP control plane must support MPLS-TP point to point 136. The MPLS-TP control plane must support MPLS-TP point to point
tunnel identifiers of the forms defined in [TP-IDENTIFIERS, tunnel identifiers of the forms defined in [TP-IDENTIFIERS,
Section 5.1]. Section 5.1].
138. The MPLS-TP control plane must support MPLS-TP LSP identifiers 137. The MPLS-TP control plane must support MPLS-TP LSP identifiers
of the forms defined in [TP-IDENTIFIERS, Section 5.2], and the of the forms defined in [TP-IDENTIFIERS, Section 5.2], and the
mappings to GMPLS as defined in [TP-IDENTIFIERS, Section 5.3]. mappings to GMPLS as defined in [TP-IDENTIFIERS, Section 5.3].
139. The MPLS-TP control plane must support Pseudowire path 138. The MPLS-TP control plane must support Pseudowire path
identifiers of the form defined in [TP-IDENTIFIERS, Section identifiers of the form defined in [TP-IDENTIFIERS, Section
6.]. 6.].
140. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs 139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs
as defined in [TP-IDENTIFIERS, Section 7.1.1]. as defined in [TP-IDENTIFIERS, Section 7.1.1].
141. The MPLS-TP control plane must support IP compatible MEG_IDs 140. The MPLS-TP control plane must support IP compatible MEG_IDs
for LSPs and PWs as defined [TP-IDENTIFIERS, Section 7.1.2]. for LSPs and PWs as defined [TP-IDENTIFIERS, Section 7.1.2].
142. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs 141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs
of the forms defined in [TP-IDENTIFIERS, Section 7.2.1]. of the forms defined in [TP-IDENTIFIERS, Section 7.2.1].
143. The MPLS-TP control plane must support IP based MEP_IDs for 142. The MPLS-TP control plane must support IP based MEP_IDs for
MPLS-TP LSP of the forms defined in [TP-IDENTIFIERS, Section MPLS-TP LSP of the forms defined in [TP-IDENTIFIERS, Section
7.2.2.1]. 7.2.2.1].
144. The MPLS-TP control plane must support IP based MEP_IDs for 143. The MPLS-TP control plane must support IP based MEP_IDs for
Pseudowires of the form defined in [TP-IDENTIFIERS, Section Pseudowires of the form defined in [TP-IDENTIFIERS, Section
7.2.2.2]. 7.2.2.2].
3. Relationship of PWs and TE LSPs 3. Relationship of PWs and TE LSPs
The data plane relationship between PWs and LSPs is inherited from The data plane relationship between PWs and LSPs is inherited from
standard MPLS and is reviewed in the MPLS-TP Framework [RFC5921]. standard MPLS and is reviewed in the MPLS-TP Framework [RFC5921].
Likewise, the control plane relationship between PWs and LSPs is Likewise, the control plane relationship between PWs and LSPs is
inherited from standard MPLS. This relationship is reviewed in this inherited from standard MPLS. This relationship is reviewed in this
document. The relationship between the PW and LSP control planes in document. The relationship between the PW and LSP control planes in
skipping to change at page 27, line 15 skipping to change at page 27, line 5
o In-band o In-band
This term is used to refer to cases where control plane traffic This term is used to refer to cases where control plane traffic
is sent in the same communication channel used to transport is sent in the same communication channel used to transport
associated user data or management traffic. IP, MPLS, and associated user data or management traffic. IP, MPLS, and
Ethernet networks are all examples where control traffic is Ethernet networks are all examples where control traffic is
typically sent in-band with the data traffic. An example of this typically sent in-band with the data traffic. An example of this
case in the context of MPLS-TP is where control plane traffic is case in the context of MPLS-TP is where control plane traffic is
sent via the MPLS Generic Associated Channel (G-ACh), see sent via the MPLS Generic Associated Channel (G-ACh), see
[RFC5586], using the same LSP as controlled user traffic. [RFC5586], using the same LSP as controlled user traffic.
o Out-of-band, in-fiber o Out-of-band, in-fiber (same physical connection)
This term is used to refer to cases where control plane traffic This term is used to refer to cases where control plane traffic
is sent using a different communication channel from the is sent using a different communication channel from the
associated data or management traffic, and the control associated data or management traffic, and the control
communication channel resides in the same fiber as either the communication channel resides in the same fiber as either the
management or data traffic. An example of this case in the management or data traffic. An example of this case in the
context of MPLS-TP is where control plane traffic is sent via the context of MPLS-TP is where control plane traffic is sent via the
G-ACh using a dedicated LSP on the same link (interface) which G-ACh using a dedicated LSP on the same link (interface) which
carries controlled user traffic. carries controlled user traffic.
o Out-of-band, aligned topology o Out-of-band, aligned topology
skipping to change at page 28, line 6 skipping to change at page 27, line 48
preclude the use of in-fiber or aligned topology links, but preclude the use of in-fiber or aligned topology links, but
alignment is not required. An example of this case in the alignment is not required. An example of this case in the
context of MPLS-TP is where control plane traffic is sent between context of MPLS-TP is where control plane traffic is sent between
controlling nodes using any available path and links, completely controlling nodes using any available path and links, completely
without regard for the path(s) taken by corresponding management without regard for the path(s) taken by corresponding management
or user traffic. or user traffic.
In the context of MPLS-TP requirements, requirement 14 (see Section 2 In the context of MPLS-TP requirements, requirement 14 (see Section 2
above) can be met using out-of-band in-fiber or aligned topology above) can be met using out-of-band in-fiber or aligned topology
types of control. Requirement 15 can only be met by using Out-of- types of control. Requirement 15 can only be met by using Out-of-
band, independent topology. Some expect the G-ACh to be used band, independent topology. G-ACh is likely to be used extensively
extensively in MPLS-TP networks to support the MPLS-TP control (and in MPLS-TP networks to support the MPLS-TP control (and management)
management) planes. planes.
4.1.2. Addressing 4.1.2. Addressing
MPLS-TP reuses and supports the addressing mechanisms supported by MPLS-TP reuses and supports the addressing mechanisms supported by
MPLS. The MPLS-TP Identifiers document, see [TP-IDENTIFIERS], MPLS. The MPLS-TP Identifiers document, see [TP-IDENTIFIERS],
provides additional context on how IP addresses are used within MPLS- provides additional context on how IP addresses are used within MPLS-
TP. MPLS, and consequently, MPLS-TP uses the IPv4 and IPv6 address TP. MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address
families to identify MPLS-TP nodes by default for network management families to identify MPLS-TP nodes by default for network management
and signaling purposes. The address spaces and neighbor adjacencies and signaling purposes. The address spaces and neighbor adjacencies
in the control, management and data planes used in an MPLS-TP network in the control, management and data planes used in an MPLS-TP network
may be completely separated or combined at the discretion of an MPLS- may be completely separated or combined at the discretion of an MPLS-
TP operator and based on the equipment capabilities of a vendor. The TP operator and based on the equipment capabilities of a vendor. The
separation of the control and management planes from the data plane separation of the control and management planes from the data plane
allows each plane to be independently addressable. Each plane may allows each plane to be independently addressable. Each plane may
use addresses that are not mutually reachable, e.g., it is likely use addresses that are not mutually reachable, e.g., it is likely
that the data plane will not be able to reach an address from the that the data plane will not be able to reach an address from the
management or control planes and vice versa. Each plane may also use management or control planes and vice versa. Each plane may also use
skipping to change at page 29, line 14 skipping to change at page 29, line 7
as support for the other functions discussed in this section. as support for the other functions discussed in this section.
Both MPLS and GMPLS path computation allow for the restriction of Both MPLS and GMPLS path computation allow for the restriction of
path selection based on the use of Explicit Route Objects (EROs) and path selection based on the use of Explicit Route Objects (EROs) and
other LSP attributes, see [RFC3209] and [RFC3473]. In all cases, no other LSP attributes, see [RFC3209] and [RFC3473]. In all cases, no
specific algorithm is standardized by the IETF. This is anticipated specific algorithm is standardized by the IETF. This is anticipated
to continue to be the case for MPLS-TP LSPs. to continue to be the case for MPLS-TP LSPs.
4.1.4.1. Relation to PCE 4.1.4.1. Relation to PCE
Path Computation Element (PCE) Based approaches, see [RFC4655], may Path Computation Element (PCE)-based approaches, see [RFC4655], may
be used for path computation of a GMPLS LSP, and consequently an be used for path computation of a GMPLS LSP, and consequently an
MPLS-TP LSP, across domains and in a single domain. In cases where MPLS-TP LSP, across domains and in a single domain. In cases where
PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440],
will be used to communicate PCE requests and responses. MPLS-TP will be used to communicate PCE related requests and responses. MPLS-
specific extensions to PCEP are currently out of scope of the MPLS-TP TP specific extensions to PCEP are currently out of scope of the
project and this document. MPLS-TP project and this document.
4.1.5. Signaling 4.1.5. Signaling
GMPLS signaling is defined in [RFC3471] and [RFC3473], and is based GMPLS signaling is defined in [RFC3471] and [RFC3473], and is based
on RSVP-TE [RFC3209]. CR-LDP based GMPLS, [RFC3472] is no longer on RSVP-TE [RFC3209]. CR-LDP based GMPLS, [RFC3472] is no longer
under active development within the IETF, i.e., it is deprecated, and under active development within the IETF, i.e., it is deprecated, see
must not be used for MPLS-TP. In general, all RSVP-TE extensions [RFC3468], and must not be used for MPLS and consequently also MPLS-
that apply to MPLS may also be used for GMPLS and consequently MPLS- TP. In general, all RSVP-TE extensions that apply to MPLS may also
TP. Most notably this includes support for P2MP signaling as defined be used for GMPLS and consequently MPLS-TP. Most notably this
in [RFC4875]. includes support for P2MP signaling as defined in [RFC4875].
GMPLS signaling includes a number of MPLS-TP required functions. GMPLS signaling includes a number of MPLS-TP required functions.
Notably support for out-of-band control, bidirectional LSPs, and Notably support for out-of-band control, bidirectional LSPs, and
independent control and data plane fault management. There are also independent control and data plane fault management. There are also
numerous other GMPLS and MPLS extensions that can be used to provide numerous other GMPLS and MPLS extensions that can be used to provide
specific functions in MPLS-TP networks. Specific references are specific functions in MPLS-TP networks. Specific references are
provided below. provided below.
4.1.6. Unnumbered Links 4.1.6. Unnumbered Links
skipping to change at page 30, line 15 skipping to change at page 30, line 7
4.1.7. Link Bundling 4.1.7. Link Bundling
Link bundling provides a local construct that can be used to improve Link bundling provides a local construct that can be used to improve
scaling of TE routing when multiple data links are shared between scaling of TE routing when multiple data links are shared between
node pairs. Link bundling for MPLS and GMPLS networks is defined in node pairs. Link bundling for MPLS and GMPLS networks is defined in
[RFC4201]. Link bundling may be used in MPLS-TP networks and its use [RFC4201]. Link bundling may be used in MPLS-TP networks and its use
is at the discretion of the network operator. is at the discretion of the network operator.
4.1.8. Hierarchical LSPs 4.1.8. Hierarchical LSPs
This section reuses text from [HIERARCHY-BIS]. This section reuses text from [RFC6107].
[RFC3031] describes how MPLS labels may be stacked so that LSPs may [RFC3031] describes how MPLS labels may be stacked so that LSPs may
be nested with one LSP running through another. This concept of be nested with one LSP running through another. This concept of
Hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of Hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of
protocol mechanisms for the establishment of a hierarchical LSP that protocol mechanisms for the establishment of a hierarchical LSP that
can carry one or more other LSPs. can carry one or more other LSPs.
[RFC4206] goes on to explain that a hierarchical LSP may carry other [RFC4206] goes on to explain that a hierarchical LSP may carry other
LSPs only according to their switching types. This is a function of LSPs only according to their switching types. This is a function of
the way labels are carried. In a packet switch capable (PSC) network, the way labels are carried. In a packet switch capable (PSC) network,
skipping to change at page 31, line 16 skipping to change at page 31, line 4
GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs
recovery in [RFC4872], and segment recovery in [RFC4873] . GMPLS recovery in [RFC4872], and segment recovery in [RFC4873] . GMPLS
segment recovery provides a superset of the function in end-to-end segment recovery provides a superset of the function in end-to-end
recovery. End-to-end recovery can be viewed as a special case of recovery. End-to-end recovery can be viewed as a special case of
segment recovery where there is a single recovery domain whose segment recovery where there is a single recovery domain whose
borders coincide with the ingress and egress of the LSP, although borders coincide with the ingress and egress of the LSP, although
specific procedures are defined. specific procedures are defined.
The five defined types of recovery defined in GMPLS are: The five defined types of recovery defined in GMPLS are:
- 1+1 bidirectional protection for P2P LSPs - 1+1 bidirectional protection for P2P LSPs
- 1+1 unidirectional protection for P2MP LSPs - 1+1 unidirectional protection for P2MP LSPs
- 1:n (including 1:1) protection with or without extra traffic - 1:n (including 1:1) protection with or without extra traffic
- Rerouting without extra traffic (sometimes known as soft - Rerouting without extra traffic (sometimes known as soft
rerouting), including shared mesh restoration rerouting), including shared mesh restoration
- Full LSP rerouting - Full LSP rerouting
Recovery for MPLS-TP LSPs as discussed in [TP-SURVIVE], is signaled Recovery for MPLS-TP LSPs, as discussed in [TP-SURVIVE], is signaled
using the mechanism defined in [RFC4872] and [RFC4873]. Note that using the mechanism defined in [RFC4872] and [RFC4873]. Note that
when MEPs are required for the OAM CC function and the MEPs exist at when MEPs are required for the OAM CC function and the MEPs exist at
LSP transit nodes, each MEP is instantiated at a hierarchical LSP end LSP transit nodes, each MEP is instantiated at a hierarchical LSP end
point, and protection is provided end-to-end for the hierarchical point, and protection is provided end-to-end for the hierarchical
LSP. (Protection can be signaled using either [RFC4872] or [RFC4873] LSP. (Protection can be signaled using either [RFC4872] or [RFC4873]
defined procedures.) The use of Notify messages to trigger protection defined procedures.) The use of Notify messages to trigger protection
switching and recovery is not required in MPLS-TP as this function is switching and recovery is not required in MPLS-TP as this function is
expected to be supported via OAM. However, its use is not precluded. expected to be supported via OAM. However, its use is not precluded.
4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI)
skipping to change at page 31, line 47 skipping to change at page 31, line 36
(I-NNI). In the MPLS-TP context, some operators may choose to deploy (I-NNI). In the MPLS-TP context, some operators may choose to deploy
signaled interfaces across user-to-network (UNI) interfaces and signaled interfaces across user-to-network (UNI) interfaces and
across inter-provider, external network-to-network (E-NNI), across inter-provider, external network-to-network (E-NNI),
interfaces. Such support is embodied in [RFC4208] for UNIs and interfaces. Such support is embodied in [RFC4208] for UNIs and
[RFC5787] for routing areas in support of E-NNIs. This work may [RFC5787] for routing areas in support of E-NNIs. This work may
require extensions in order to meet the specific needs of an MPLS-TP require extensions in order to meet the specific needs of an MPLS-TP
UNI and E-NNI. UNI and E-NNI.
4.2. OAM, MEP (Hierarchy), MIP Configuration and Control 4.2. OAM, MEP (Hierarchy), MIP Configuration and Control
MPLS-TP is being defined to support a comprehensive set of MPLS-TP MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM
OAM functions. The MPLS-TP control plane will not itself provide OAM functions. The MPLS-TP control plane will not itself provide OAM
functions, but it will be used to instantiate and otherwise control functions, but it will be used to instantiate and otherwise control
MPLS-TP OAM functions. MPLS-TP OAM functions.
Specific OAM requirements for MPLS-TP are documented in [RFC5860]. Specific OAM requirements for MPLS-TP are documented in [RFC5860].
This document also states that it is also required that the control This document also states that it is also required that the control
plane be able to configure and control OAM entities. This plane be able to configure and control OAM entities. This
requirement is not yet addressed by the existing RFCs, but such work requirement is not yet addressed by the existing RFCs, but such work
is now underway, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT]. is now underway, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT].
Many OAM functions occur on a per-LSP basis, are typically in-band, Many OAM functions occur on a per-LSP basis, are typically in-band,
skipping to change at page 32, line 23 skipping to change at page 32, line 12
extra overhead and potential errors associated with separate OAM extra overhead and potential errors associated with separate OAM
configuration mechanisms. configuration mechanisms.
4.2.1. Management Plane Support 4.2.1. Management Plane Support
There is no MPLS-TP requirement for a standardized management There is no MPLS-TP requirement for a standardized management
interface to the MPLS-TP control plane. That said, MPLS and GMPLS interface to the MPLS-TP control plane. That said, MPLS and GMPLS
support a number of standardized management functions. These include support a number of standardized management functions. These include
the MPLS-TE/GMPLS TE Database Management Information Base (MIB), [TE- the MPLS-TE/GMPLS TE Database Management Information Base (MIB), [TE-
MIB]; the MPLS-TE MIB, [RFC3812]; the MPLS LSR MIB, [RFC3813]; the MIB]; the MPLS-TE MIB, [RFC3812]; the MPLS LSR MIB, [RFC3813]; the
GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803]. These MIBs GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803]. These MIB
may be used in MPLS-TP networks. modules may be used in MPLS-TP networks. A general overview of MPLS-
TP related MIB modules can be found in [TP-MIB]. Network management
requirements for MPLS-based transport networks are provided in
[RFC5951]
4.2.1.1. Recovery Triggers 4.2.1.1. Recovery Triggers
The GMPLS control plane allows for management plane recovery triggers The GMPLS control plane allows for management plane recovery triggers
and directly supports control plane recovery triggers. Support for and directly supports control plane recovery triggers. Support for
control plane recovery triggers is defined in [RFC4872] which refers control plane recovery triggers is defined in [RFC4872] which refers
to the triggers as "Recovery Commands". These commands can be used to the triggers as "Recovery Commands". These commands can be used
with both end-to-end and segment recovery, but are always controlled with both end-to-end and segment recovery, but are always controlled
on an end-to-end basis. The recovery triggers/commands defined in on an end-to-end basis. The recovery triggers/commands defined in
[RFC4872] are: [RFC4872] are:
skipping to change at page 32, line 35 skipping to change at page 32, line 27
4.2.1.1. Recovery Triggers 4.2.1.1. Recovery Triggers
The GMPLS control plane allows for management plane recovery triggers The GMPLS control plane allows for management plane recovery triggers
and directly supports control plane recovery triggers. Support for and directly supports control plane recovery triggers. Support for
control plane recovery triggers is defined in [RFC4872] which refers control plane recovery triggers is defined in [RFC4872] which refers
to the triggers as "Recovery Commands". These commands can be used to the triggers as "Recovery Commands". These commands can be used
with both end-to-end and segment recovery, but are always controlled with both end-to-end and segment recovery, but are always controlled
on an end-to-end basis. The recovery triggers/commands defined in on an end-to-end basis. The recovery triggers/commands defined in
[RFC4872] are: [RFC4872] are:
a. Lockout of recovery LSP a. Lockout of recovery LSP
b. Lockout of normal traffic b. Lockout of normal traffic
c. Forced switch for normal traffic c. Forced switch for normal traffic
d. Requested switch for normal traffic d. Requested switch for normal traffic
e. Requested switch for recovery LSP e. Requested switch for recovery LSP
Note that control plane triggers are typically invoked in response to Note that control plane triggers are typically invoked in response to
a management plane request at the ingress. a management plane request at the ingress.
4.2.1.2. Management Plane / Control Plane Ownership Transfer 4.2.1.2. Management Plane / Control Plane Ownership Transfer
In networks where both control plane and management plane are In networks where both control plane and management plane are
provided, LSP provisioning can be bone either by control plane or provided, LSP provisioning can be done either by control plane or
management plane. As mentioned in the requirements section above, it management plane. As mentioned in the requirements section above, it
must be possible to transfer, or handover, a management plane created must be possible to transfer, or handover, a management plane created
LSP to the control plane domain and vice versa. [RFC5493] defines the LSP to the control plane domain and vice versa. [RFC5493] defines the
specific requirements for an LSP ownership handover procedure. It specific requirements for an LSP ownership handover procedure. It
must be possible for the control plane to provide the management must be possible for the control plane to provide the management
plane, in a reliable manner, with the status or result of an plane, in a reliable manner, with the status or result of an
operation performed by the management plane. This notification may operation performed by the management plane. This notification may
be either synchronous or asynchronous with respect to the operation. be either synchronous or asynchronous with respect to the operation.
Moreover, it must be possible for the management plane to monitor the Moreover, it must be possible for the management plane to monitor the
status of the control plane, for example the status of a TE Link, its status of the control plane, for example the status of a TE Link, its
available resources, etc. This monitoring may be based on queries available resources, etc. This monitoring may be based on queries
initiated by the management plane or on notifications generated by initiated by the management plane or on notifications generated by
the control plane. A mechanism must be made available by the control the control plane. A mechanism must be made available by the control
plane to the management plane to log control plane LSP related plane to the management plane to log control plane LSP related
operation, that is, it must be possible from the NMS to have a clear operation, that is, it must be possible from the NMS to have a clear
view of the life, (traffic hit, action performed, signaling etc.) of view of the life (traffic hit, action performed, signaling, etc.) of
a given LSP. The LSP handover procedure for MPLS-TP LSPs is supported a given LSP. The LSP handover procedure for MPLS-TP LSPs is supported
via [RFC5852]. via [RFC5852].
4.3. GMPLS and MPLS-TP Requirements Table 4.3. GMPLS and MPLS-TP Requirements Table
The following table shows how the MPLS-TP control plane requirements The following table shows how the MPLS-TP control plane requirements
can be met using the existing GMPLS control plane (which builds on can be met using the existing GMPLS control plane (which builds on
the MPLS control plane). Areas where additional specifications are the MPLS control plane). Areas where additional specifications are
required are also identified. The table lists references based on required are also identified. The table lists references based on
the control plane requirements as identified and numbered above in the control plane requirements as identified and numbered above in
skipping to change at page 34, line 9 skipping to change at page 34, line 4
| 18 | [RFC3945], [RFC4202] + proper vendor implementation | | 18 | [RFC3945], [RFC4202] + proper vendor implementation |
| 19 | [RFC3945], [RFC4202] | | 19 | [RFC3945], [RFC4202] |
| 20 | [RFC3473] | | 20 | [RFC3473] |
| 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | | 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] | | | [RFC5151] |
| 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | | 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] | | | [RFC5151] |
| 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | | 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [HIERARCHY-BIS] | | | [RFC6107] |
| 26 | [RFC3473], [RFC4875] | | 26 | [RFC3473], [RFC4875] |
| 27 | [RFC3473], [RFC4875] | | 27 | [RFC3473], [RFC4875] |
| 28 | [RFC3945], [RFC3471], [RFC4202] | | 28 | [RFC3945], [RFC3471], [RFC4202] |
| 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 30 | [RFC3945], [RFC3471], [RFC4202] | | 30 | [RFC3945], [RFC3471], [RFC4202] |
| 31 | [RFC3945], [RFC3471], [RFC4202] | | 31 | [RFC3945], [RFC3471], [RFC4202] |
| 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] | | 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] |
| 33 | [RFC3473], [RFC4875] | | 33 | [RFC3473], [RFC4875] |
| 34 | [RFC4875] | | 34 | [RFC4875] |
| 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 36 | [RFC3473], [RFC3209] (Make-before-break) | | 36 | [RFC3473], [RFC3209] (Make-before-break) |
| 37 | [RFC3473], [RFC3209] (Make-before-break) | | 37 | [RFC3473], [RFC3209] (Make-before-break) |
| 38 | | | 38 | |
| 39 | [RFC4139], [RFC4258], [RFC5787] | | 38 | [RFC4139], [RFC4258], [RFC5787] |
| 40 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 39 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 41 | [RFC3473], [RFC5063] | | 40 | [RFC3473], [RFC5063] |
| 42 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] | | 41 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] |
| 43 | [RFC3945], [RFC3471], [RFC4202] | | 42 | [RFC3945], [RFC3471], [RFC4202] |
| 44 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 43 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 45 | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 44 | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 46 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 45 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 47 | [RFC5493] | | 46 | [RFC5493] |
| 48 | [RFC4872], [RFC4873] | | 47 | [RFC4872], [RFC4873] |
| 49 | [RFC3945], [RFC3471], [RFC4202] | | 48 | [RFC3945], [RFC3471], [RFC4202] |
| 50 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | | 49 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 51 | [RFC4872], [RFC4873] | | 50 | [RFC4872], [RFC4873] |
| 52 | [RFC4872], [RFC4873] + proper vendor implementation | | 51 | [RFC4872], [RFC4873] + proper vendor implementation |
| 53 | [RFC4872], [RFC4873], [GMPLS-PS] | | 52 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 54 | [RFC4872], [RFC4873] | | 53 | [RFC4872], [RFC4873] |
| 55 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] | | 54 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] |
| | Timers are a local implementation matter | | | Timers are a local implementation matter |
| 56 | [RFC4872], [RFC4873], [GMPLS-PS] + | | 55 | [RFC4872], [RFC4873], [GMPLS-PS] + |
| | implementation of timers | | | implementation of timers |
| 57 | [RFC4872], [RFC4873], [GMPLS-PS] | | 56 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 57 | [RFC4872], [RFC4873] |
| 58 | [RFC4872], [RFC4873] | | 58 | [RFC4872], [RFC4873] |
| 59 | [RFC4872], [RFC4873] | | 59 | [RFC4872], [RFC4873] |
| 60 | [RFC4872], [RFC4873] | | 60 | [RFC4872], [RFC4873], [RFC6107] |
| 61 | [RFC4872], [RFC4873], [HIERARCHY-BIS] | | 61 | [RFC4872], [RFC4873] |
| 62 | [RFC4872], [RFC4873] | | 62 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 63 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | | 63 | [RFC4872], [RFC4873] |
| 64 | [RFC4872], [RFC4873] | | 64 | [RFC4872], [RFC4873] |
| 65 | [RFC4872], [RFC4873] | | 65 | [RFC4872], [RFC4873] |
| 66 | [RFC4872], [RFC4873] | | 66 | [RFC4872], [RFC4873], [RFC6107] |
| 67 | [RFC4872], [RFC4873], [HIERARCHY-BIS] | | 67 | [RFC4872], [RFC4873] |
| 68 | [RFC4872], [RFC4873] | | 68 | [RFC3473], [RFC4872], [RFC4873] |
| 69 | [RFC3473], [RFC4872], [RFC4873] | | 69 | [RFC3473] |
| 70 | [RFC3473] | | 70 | [RFC3473], [RFC4872], [GMPLS-PS] |
| 71 | [RFC3473], [RFC4872], [GMPLS-PS] | | 71 | [RFC3473], [RFC4872] |
| 72 | [RFC3473], [RFC4872] | | 72 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 73 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 73 | [RFC4426], [RFC4872], [RFC4873] |
| 74 | [RFC4426], [RFC4872], [RFC4873] | | 74 | [RFC4426], [RFC4872], [RFC4873] |
| 75 | [RFC4426], [RFC4872], [RFC4873] | | 75 | [RFC4426], [RFC4872], [RFC4873] |
| 76 | [RFC4426], [RFC4872], [RFC4873] | | 76 | [RFC4426], [RFC4872], [RFC4873] |
| 77 | [RFC4426], [RFC4872], [RFC4873] | | 77 | [RFC4426], [RFC4872], [RFC4873] |
| 78 | [RFC4426], [RFC4872], [RFC4873] | | 78 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation |
| 79 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation | | 79 | [RFC4426], [RFC4872], [RFC4873] |
| 80 | [RFC4426], [RFC4872], [RFC4873] | | 80 | [RFC4426], [RFC4872], [RFC4873] |
| 81 | [RFC4426], [RFC4872], [RFC4873] | | 81 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 85 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 85 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 86 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 86 | [RFC4872], [RFC4873] |
| 87 | [RFC4872], [RFC4873] | | 87 | [RFC4872], [RFC4873] |
| 88 | [RFC4872], [RFC4873] | | 88 | [RFC4872], [RFC4873], [TP-RING] |
| 89 | [RFC4872], [RFC4873], [TP-RING] | | 89 | [RFC4872], [RFC4873], [TP-RING] |
| 90 | [RFC4872], [RFC4873], [TP-RING] | | 90 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 91 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | | 91 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 92 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 92 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] |
| 93 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] | | 93 | Generic requirement on data plane (correct implementation)|
| 94 | Generic requirement on data plane (correct implementation)| | 94 | [RFC3473], [NO-PHP] |
| 95 | [RFC3473], [NO-PHP] | | 95 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 96 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | | 96 | PW only requirement, see PW Requirements Table (5.2) |
| 97 | PW only requirement, see PW Requirements Table (5.2) | | 97 | PW only requirement, see PW Requirements Table (5.2) |
| 98 | PW only requirement, see PW Requirements Table (5.2) | | 98 | [RFC3945], [RFC3473], [RFC6107] |
| 99 | [RFC3945], [RFC3473], [HIERARCHY-BIS] | | 99 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + |
| 100 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + |
| | [RFC5392] and [RFC5316] | | | [RFC5392] and [RFC5316] |
| 101 | PW only requirement, see PW Requirements Table (5.2) | | 100 | PW only requirement, see PW Requirements Table (5.2) |
| 102 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 101 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 103 | [RFC4872], [RFC4873], [TP-RING] | | 102 | [RFC4872], [RFC4873], [TP-RING] |
| 104 | [RFC3945], [RFC3473], [HIERARCHY-BIS] | | 103 | [RFC3945], [RFC3473], [RFC6107] |
| 105 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 106 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 105 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 106 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 109 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 109 | [RFC3473], [RFC4872], [RFC4873] |
| 110 | [RFC3473], [RFC4872], [RFC4873] | | 110 | [RFC3473], [RFC4872], [RFC4873] |
| 111 | [RFC3473], [RFC4872], [RFC4873] | | 111 | [RFC3473], [RFC4783] |
| 112 | [RFC3473], [RFC4783] | | 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 115 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 115 | [RFC3473] |
| 116 | [RFC3473] | | 116 | [RFC4426], [RFC4872], [RFC4873] |
| 117 | [RFC4426], [RFC4872], [RFC4873] | | 117 | [RFC3473], [RFC4872], [RFC4873] |
| 118 | [RFC3473], [RFC4872], [RFC4873] | | 118 | [RFC3473], [RFC4783] |
| 119 | [RFC3473], [RFC4783] | | 119 | [RFC3473] |
| 120 | [RFC3473] | | 120 | [RFC3473], [RFC4783] |
| 121 | [RFC3473], [RFC4783] | | 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] |
| 124 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [HIERARCHY-BIS] | | 124 - | |
| 125 - | | | 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 136 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 136a | [RFC3473] |
| 136b | [RFC3473] + (See Sec. 4.4.7) |
| 137a | [RFC3473] | | 137a | [RFC3473] |
| 137b | [RFC3473] + (See Sec. 4.4.7) | | 137b | [RFC3473] + (See Sec. 4.4.7) |
| 138a | [RFC3473] | | 138 | PW only requirement, see PW Requirements Table (5.2) |
| 138b | [RFC3473] + (See Sec. 4.4.7) | | 139 - | |
| 139 | PW only requirement, see PW Requirements Table (5.2) | | 143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) |
| 140 - | |
| 144 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) |
+=======+===========================================================+ +=======+===========================================================+
Table 1: GMPLS and MPLS-TP Requirements Table
4.4. Anticipated MPLS-TP Related Extensions and Definitions 4.4. Anticipated MPLS-TP Related Extensions and Definitions
This section identifies the extensions and other documents that have This section identifies the extensions and other documents that have
been identified as likely to be needed to support the full set of been identified as likely to be needed to support the full set of
MPLS-TP control plane requirements. MPLS-TP control plane requirements.
4.4.1. MPLS-TE to MPLS-TP LSP Control Plane Interworking 4.4.1. MPLS-TE to MPLS-TP LSP Control Plane Interworking
While no interworking function is expected in the data-plane to While no interworking function is expected in the data-plane to
support the interconnection of MPLS-TE and MPLS-TP networking, this support the interconnection of MPLS-TE and MPLS-TP networking, this
is not the case for the control plane. MPLS-TE networks typically is not the case for the control plane. MPLS-TE networks typically
use LSP signaling based on [RFC3209] while MPLS-TP LSPs will be use LSP signaling based on [RFC3209] while MPLS-TP LSPs will be
signaled using GMPLS RSVP-TE, i.e., [RFC3473]. The data plane of signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies
a set of solutions that are aimed to aid in the interworking of MPLS-
[RFC5145] identifies a set of solutions that are aimed to aid in the TE and GMPLS control planes. [RFC5145] work will serve as the
interworking of MPLS-TE and GMPLS control planes. This work will foundation for a formal definition of MPLS to MPLS-TP control plane
serve as the foundation for a formal definition of MPLS to MPLS-TP interworking.
control plane interworking.
4.4.2. Associated Bidirectional LSPs 4.4.2. Associated Bidirectional LSPs
GMPLS signaling, [RFC3473], supports unidirectional, and co-routed GMPLS signaling, [RFC3473], supports unidirectional, and co-routed
bidirectional point-to-point LSPs. MPLS-TP also requires support for bidirectional point-to-point LSPs. MPLS-TP also requires support for
associated bidirectional point-to-point LSPs. Such support will associated bidirectional point-to-point LSPs. Such support will
require an extension or a formal definition of how the LSP endpoints require an extension or a formal definition of how the LSP endpoints
supporting an associated bidirectional service will coordinate the supporting an associated bidirectional service will coordinate the
two LSPs used to provide such a service. Per requirement 11, transit two LSPs used to provide such a service. Per requirement 11, transit
nodes that support an associated bidirectional service should be nodes that support an associated bidirectional service should be
aware of the association of the LSPs used to support the service when aware of the association of the LSPs used to support the service when
both LSPs are supported on that transit node. There are several both LSPs are supported on that transit node. There are several
existing protocol mechanisms on which to base such support, existing protocol mechanisms on which to base such support,
including, but not limited to: including, but not limited to:
o GMPLS calls, [RFC4974]. o GMPLS calls, [RFC4974].
o The ASSOCIATION object, [RFC4872]. o The ASSOCIATION object, [RFC4872].
o The LSP_TUNNEL_INTERFACE_ID object, [HIERARCHY-BIS]. o The LSP_TUNNEL_INTERFACE_ID object, [RFC6107].
4.4.3. Asymmetric Bandwidth LSPs 4.4.3. Asymmetric Bandwidth LSPs
[RFC5467] defines support for bidirectional LSPs which have different [RFC5467] defines support for bidirectional LSPs which have different
(asymmetric) bandwidth requirements for each direction. This RFC can (asymmetric) bandwidth requirements for each direction. This RFC can
be used to meet the related MPLS-TP technical requirement, but this be used to meet the related MPLS-TP technical requirement, but this
RFC is currently an Experimental RFC. To fully satisfy the MPLS-TP RFC is currently an Experimental RFC. To fully satisfy the MPLS-TP
requirement this document will need to become a Standards Track RFC. requirement this document will need to become a Standards Track RFC.
4.4.4. Recovery for P2MP LSPs 4.4.4. Recovery for P2MP LSPs
The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and
[RFC4873], do not explicitly cover their interactions. MPLS-TP [RFC4873], do not explicitly cover their interactions. MPLS-TP
requires a formal definition of recovery techniques for P2MP LSPs. requires a formal definition of recovery techniques for P2MP LSPs.
Such a formal definition will be based on existing RFCs and may not Such a formal definition will be based on existing RFCs and may not
require any new protocol mechanisms, but nonetheless, must be require any new protocol mechanisms but, nonetheless, must be
documented. documented.
4.4.5. Test Traffic Control and other OAM functions 4.4.5. Test Traffic Control and other OAM functions
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are works in progress that extend [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related
the OAM related control capabilities of GMPLS. These extensions control extensions to GMPLS. These extensions cover a portion, but
cover a portion, but not all OAM related control functions that have not all OAM-related control functions that have been identified in
been identified in the context of MPLS-TP. As discussed above, the the context of MPLS-TP. As discussed above, the MPLS-TP control
MPLS-TP control plane must support the selection of which (if any) plane must support the selection of which (if any) OAM function(s) to
OAM function(s) to use (including support to select experimental OAM use (including support to select experimental OAM functions) and what
functions) and what OAM functionality to run, including, continuity OAM functionality to run, including, continuity check (CC),
check (CC), connectivity verification (CV), packet loss and delay connectivity verification (CV), packet loss and delay quantification,
quantification, and diagnostic testing of a service. As OAM and diagnostic testing of a service. Such support may be included in
configuration is directly linked to data plane OAM, it is expected the listed documents or in other documents.
that [CCAMP-OAM-EXT] will evolve in parallel with the specification
of data plane OAM functions. These documents do not yet cover the
implications of SPMEs, including both dynamic creation and dynamic
OAM function control.
4.4.6. DiffServ Object usage in GMPLS 4.4.6. DiffServ Object usage in GMPLS
[RFC3270] and [RFC4124] define support for DiffServ enabled MPLS [RFC3270] and [RFC4124] define support for DiffServ-enabled MPLS
LSPs. While [RFC4124] references GMPLS signaling, there is no LSPs. While [RFC4124] references GMPLS signaling, there is no
explicit discussion on the use of the DiffServ related objects in explicit discussion on the use of the DiffServ-related objects in
GMPLS signaling. A (possibly Informational) document on how GMPLS GMPLS signaling. A (possibly Informational) document on how GMPLS
supports DiffServ LSPs is likely to prove useful in the context of supports DiffServ LSPs is likely to prove useful in the context of
MPLS-TP. MPLS-TP.
4.4.7. Support for MPLS-TP LSP Identifiers 4.4.7. Support for MPLS-TP LSP Identifiers
MPLS-TP uses two forms of LSP identifiers, see [TP-IDENTIFIERS]. One MPLS-TP uses two forms of LSP identifiers, see [TP-IDENTIFIERS]. One
form is based on existing GMPLS fields. The other form is based on form is based on existing GMPLS fields. The other form is based on
either the globally unique Attachment Interface Identifier (AII) either the globally unique Attachment Interface Identifier (AII)
defined in [RFC5003], or the M.1400 defined the ITU Carrier Code defined in [RFC5003], or the M.1400 defined the ITU Carrier Code
(ICC). Neither form is currently supported in GMPLS and such (ICC). Neither form is currently supported in GMPLS and such
extensions will need to be documented. extensions will need to be documented.
4.4.8. Support for MPLS-TP Maintenance Identifiers 4.4.8. Support for MPLS-TP Maintenance Identifiers
MPLS-TP defines several forms of maintenance entity related MPLS-TP defines several forms of maintenance entity-related
identifiers. Both node unique and global forms are defined. identifiers. Both node unique and global forms are defined.
Extensions will be required to GMPLS to support these identifiers. Extensions will be required to GMPLS to support these identifiers.
These extensions may be added to existing works in progress, such as These extensions may be added to existing works in progress, such as
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent
documents. documents.
5. Pseudowires 5. Pseudowires
5.1. LDP Functions and Pseudowires 5.1. LDP Functions and Pseudowires
skipping to change at page 39, line 23 skipping to change at page 39, line 13
packet containers. An MPLS-TP network may also contain Switching PEs packet containers. An MPLS-TP network may also contain Switching PEs
(S-PEs) for a multi-segment PW whereby the T-PEs may be at the edge (S-PEs) for a multi-segment PW whereby the T-PEs may be at the edge
of an MPLS-TP network or in a client network. In this latter case, a of an MPLS-TP network or in a client network. In this latter case, a
T-PE in a client network is a T-PE performing the adaptation of the T-PE in a client network is a T-PE performing the adaptation of the
native service to MPLS and an MPLS-TP network performs pseudowire native service to MPLS and an MPLS-TP network performs pseudowire
switching. switching.
The SS-PW signaling control plane is based on targeted LDP (T-LDP) The SS-PW signaling control plane is based on targeted LDP (T-LDP)
with specific procedures defined in [RFC4447]. The MS-PW signaling with specific procedures defined in [RFC4447]. The MS-PW signaling
control plane is also based on T-LDP as allowed for in [RFC5659], control plane is also based on T-LDP as allowed for in [RFC5659],
[SEGMENTED-PW] and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the [RFC6073] and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the same
same PW signaling protocols and procedures for placing SS-PWs and MS- PW signaling protocols and procedures for placing SS-PWs and MS-PWs.
PWs. This will leverage existing technology as well as facilitate This will leverage existing technology as well as facilitate
interoperability with client networks with native attachment circuits interoperability with client networks with native attachment circuits
or PW segments that are switched across an MPLS-TP network. or PW segments that are switched across an MPLS-TP network.
5.1.1. Management Plane Support
There is no MPLS-TP requirement for a standardized management
interface to the MPLS-TP control plane. A general overview of MPLS-
TP related MIB modules can be found in [TP-MIB]. Network management
requirements for MPLS-based transport networks are provided in
[RFC5951].
5.2. PW Control (LDP) and MPLS-TP Requirements Table 5.2. PW Control (LDP) and MPLS-TP Requirements Table
The following table shows how the MPLS-TP control plane requirements The following table shows how the MPLS-TP control plane requirements
can be met using the existing LDP control plane for Pseudowires can be met using the existing LDP control plane for Pseudowires
(targeted LDP). Areas where additional specifications are required (targeted LDP). Areas where additional specifications are required
are also identified. The table lists references based on the control are also identified. The table lists references based on the control
plane requirements as identified and numbered above in section 2. plane requirements as identified and numbered above in section 2.
In the table below, several of the requirements shown are addressed - In the table below, several of the requirements shown are addressed -
in part or in full - by the use of MPLS-TP LSPs to carry pseudowires. in part or in full - by the use of MPLS-TP LSPs to carry pseudowires.
skipping to change at page 40, line 34 skipping to change at page 40, line 34
| 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation | | 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation |
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] | | 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] |
| | [RFC4842], [RFC5287] | | | [RFC4842], [RFC5287] |
| 28 | [RFC3985] | | 28 | [RFC3985] |
| 29-31 | [RFC3985], [RFC4447] | | 29-31 | [RFC3985], [RFC4447] |
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6. | | 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6. |
| 33 | [RFC4385], [RFC4447], [RFC5586] | | 33 | [RFC4385], [RFC4447], [RFC5586] |
| 34 | [PW-P2MPR], [PW-P2MPE] | | 34 | [PW-P2MPR], [PW-P2MPE] |
| 35 | [RFC4863] | | 35 | [RFC4863] |
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 | | 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 38 | | | 38 | Provided by TP-LSPs |
| 39 | Provided by TP-LSPs | | 39 | [RFC3985], [RFC4447], + TP-LSPs |
| 40 | [RFC3985], [RFC4447], + TP-LSPs | | 40 | [RFC3478] |
| 41 | [RFC3478] | | 41-42 | [RFC3985], [RFC4447] |
| 42-43 | [RFC3985], [RFC4447] | | 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 |
| 44-45 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 | | 45 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs |
| 46 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs | | 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 |
| 47 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 | | 47 | [PW-RED], [PW-REDB] |
| 48 | [PW-RED], [PW-REDB] | | 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 49-50 | [RFC3985], [RFC4447], + TP-LSPs, implementation | | 50-52 | Provided by TP-LSPs, and Section 5.3.5 |
| 51-53 | Provided by TP-LSPs, and Section 5.3.5 | | 53-55 | [RFC3985], [RFC4447], See Section 5.3.5 |
| 54-56 | [RFC3985], [RFC4447], See Section 5.3.5 | | 56 | [PW-RED], [PW-REDB] |
| 57 | [PW-RED], [PW-REDB] |
| | revertive/non-revertive behavior is a local matter for PW | | | revertive/non-revertive behavior is a local matter for PW |
| 58-59 | [PW-RED], [PW-REDB] | | 57-58 | [PW-RED], [PW-REDB] |
| 60-82 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 83-84 | [RFC5085], [RFC5586], [RFC5885] | | 82-83 | [RFC5085], [RFC5586], [RFC5885] |
| 85-90 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 91-96 | [RFC3985], [RFC4447], + TP-LSPs, implementation | | 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 97 | [RFC4447], [MS-PW-DYNAMIC] | | 96 | [RFC4447], [MS-PW-DYNAMIC] |
| 98 | [RFC4447] | | 97 | [RFC4447] |
| 99 - | | | 98 - | |
| 100 | Not Applicable to PW | | 99 | Not Applicable to PW |
| 101 | [RFC4447] | | 100 | [RFC4447] |
| 102 | [RFC3478] | | 101 | [RFC3478] |
| 103 | [RFC3985], + TP-LSPs | | 102 | [RFC3985], + TP-LSPs |
| 104 | Not Applicable to PW | | 103 | Not Applicable to PW |
| 104 | [PW-OAM] |
| 105 | [PW-OAM] | | 105 | [PW-OAM] |
| 106 | [PW-OAM] | | 106 - | |
| 107 - | | | 108 | [RFC5085], [RFC5586], [RFC5885] |
| 109 | [RFC5085], [RFC5586], [RFC5885] | | 109 | [RFC5085], [RFC5586], [RFC5885] |
| 110 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local | | | fault reporting and protection triggering is a local |
| | matter for PW | | | matter for PW |
| 111 | [RFC5085], [RFC5586], [RFC5885] | | 110 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local | | | fault reporting and protection triggering is a local |
| | matter for PW | | | matter for PW |
| 112 | [RFC4447] | | 111 | [RFC4447] |
| 113 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] | | 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] |
| 113 | [RFC5085], [RFC5586], [RFC5885] |
| 114 | [RFC5085], [RFC5586], [RFC5885] | | 114 | [RFC5085], [RFC5586], [RFC5885] |
| 115 | [RFC5085], [RFC5586], [RFC5885] | | 115 | path traversed by PW is determined by LSP path, see |
| 116 | path traversed by PW is determined by LSP path, see |
| | GMPLS and MPLS-TP Requirements Table, 4.3 | | | GMPLS and MPLS-TP Requirements Table, 4.3 |
| 117 | [PW-RED], [PW-REDB], administrative control of redundant | | 116 | [PW-RED], [PW-REDB], administrative control of redundant |
| | PW is a local matter at the PW head-end | | | PW is a local matter at the PW head-end |
| 118 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] | | 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] |
| 119 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 120 | [RFC4447] | | 119 | [RFC4447] |
| 121 - | | | 120 - | |
| 126 | [RFC5085], [RFC5586], [RFC5885] | | 125 | [RFC5085], [RFC5586], [RFC5885] |
| 127 - | | | 126 - | |
| 131 | [PW-OAM] | | 130 | [PW-OAM] |
| 132 | Section 5.3.5 | | 131 | Section 5.3.5 |
| 132 | [PW-OAM] |
| 133 | [PW-OAM] | | 133 | [PW-OAM] |
| 134 | [PW-OAM] | | 134 | Section 5.3.5 |
| 135 | Section 5.3.5 | | 135 | [PW-OAM] |
| 136 | [PW-OAM] | | 136 | Not Applicable to PW |
| 137 | Not Applicable to PW | | 137 | Not Applicable to PW |
| 138 | Not Applicable to PW | | 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] |
| 139 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] | | 139 - | |
| 140 - | | | 143 | [PW-OAM] |
| 144 | [PW-OAM] |
+=======+===========================================================+ +=======+===========================================================+
Table 2: PW Control (LDP) and MPLS-TP Requirements Table
5.3. Anticipated MPLS-TP Related Extensions 5.3. Anticipated MPLS-TP Related Extensions
The same control protocol and procedures will be reused as much as Existing control protocol and procedures will be reused as much as
possible. However, when using PWs in MPLS-TP, a set of new possible to support MPLS-TP. However, when using PWs in MPLS-TP, a
requirements are defined which may require extensions of the existing set of new requirements are defined which may require extensions of
control mechanisms. This section clarifies the areas where extensions the existing control mechanisms. This section clarifies the areas
are needed based on the PW Control Plane related requirements where extensions are needed based on the PW Control Plane related
documented in [RFC5654]. requirements documented in [RFC5654].
See the table in the section above for a list of how requirements Table 2 lists how requirements defined in [RFC5654] are expected to
defined in [RFC5654] are expected to be addressed. be addressed.
The baseline requirement for extensions to support transport The baseline requirement for extensions to support transport
applications is that any new mechanisms and capabilities must be able applications is that any new mechanisms and capabilities must be able
to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3
[RFC3985] control and data planes where appropriate. Hence, [RFC3985] control and data planes where appropriate. Hence,
extensions of the PW Control Plane must be in-line with the extensions of the PW Control Plane must be in-line with the
procedures defined in [RFC4447], [SEGMENTED-PW] and [MS-PW-DYNAMIC]. procedures defined in [RFC4447], [RFC6073] and [MS-PW-DYNAMIC].
5.3.1. Extensions to Support Out-of-Band PW Control 5.3.1. Extensions to Support Out-of-Band PW Control
For MPLS-TP, it is required that the data and control planes can be For MPLS-TP, it is required that the data and control planes can be
both logically and physically separated. That is, the PW Control both logically and physically separated. That is, the PW Control
Plane must be able to operate out-of-band (OOB). This separation Plane must be able to operate out-of-band (OOB). This separation
ensures, among other things, that in the case of control plane ensures, among other things, that in the case of control plane
failures the data plane is not affected and can continue to operate failures the data plane is not affected and can continue to operate
normally. This was not a design requirement for the current PW normally. This was not a design requirement for the current PW
Control Plane. However, due to the PW concept, i.e., PWs are Control Plane. However, due to the PW concept, i.e., PWs are
skipping to change at page 43, line 5 skipping to change at page 43, line 18
acting as T-PEs and S-PEs or a control plane entity that may be the acting as T-PEs and S-PEs or a control plane entity that may be the
same one signaling the PW. However, an extension of the PW signaling same one signaling the PW. However, an extension of the PW signaling
protocol is required to allow the LSR at signal initiation end to protocol is required to allow the LSR at signal initiation end to
inform the targeted LSR (at the signal termination end) which LSP the inform the targeted LSR (at the signal termination end) which LSP the
resulting PW is to be bound to, in the event that more than one such resulting PW is to be bound to, in the event that more than one such
LSP exists and the choice of LSPs is important to the service being LSP exists and the choice of LSPs is important to the service being
setup (for example, if the service requires co-routed bidirectional setup (for example, if the service requires co-routed bidirectional
paths). This is also particularly important to support transport path paths). This is also particularly important to support transport path
(symmetric and asymmetric) bandwidth requirements. (symmetric and asymmetric) bandwidth requirements.
If the control plane is physically separated from the forwarder, the For transport services, MPLS-TP requires support for bidirectional
control plane must be able to program the forwarders with necessary traffic which follows congruent paths. Currently, each direction of a
information. PW or a PW segment is bound to a unidirectional LSP that extends
between two T-PEs, S-PEs, or a T-PE and an S-PE. The unidirectional
For transport services, it may be required that bidirectional traffic LSPs in both directions are not required to follow congruent paths,
follows congruent paths. Currently, each direction of a PW or a PW and therefore both directions of a PW may not follow congruent paths,
segment is bound to a unidirectional LSP that extends between two T- i.e., they are associated bidirectional paths. The only requirement
PEs, S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in both in [RFC5659] is that a PW or a PW segment shares the same T-PEs in
directions are not required to follow congruent paths, and therefore both directions, and same S-PEs in both directions.
both directions of a PW may not follow congruent paths, i.e., they
are associated bidirectional paths. The only requirement in [RFC5659]
is that a PW or a PW segment shares the same T-PEs in both
directions, and same S-PEs in both directions.
MPLS-TP imposes new requirements on the PW Control Plane, in MPLS-TP imposes new requirements on the PW Control Plane, in
requiring that both end points map the PW or PW segment to the same requiring that both end points map the PW or PW segment to the same
transport path for the case where this is an objective of the transport path for the case where this is an objective of the
service. When a bidirectional LSP is selected on one end to service. When a bidirectional LSP is selected on one end to
transport the PW, a mechanism is needed that signals to the remote transport the PW, a mechanism is needed that signals to the remote
end which LSP has been selected locally to transport the PW. This end which LSP has been selected locally to transport the PW. This
would be accomplished by adding a new TLV to PW signaling. would be accomplished by adding a new TLV to PW signaling.
Note that this coincides with the gap identified for OOB support: a Note that this coincides with the gap identified for OOB support: a
skipping to change at page 44, line 38 skipping to change at page 44, line 48
REDB] that define - respectively - how to establish redundant REDB] that define - respectively - how to establish redundant
Pseudowires and how to indicate which is in use. Additional work may Pseudowires and how to indicate which is in use. Additional work may
be required. be required.
Protection switching may be triggered manually by the operator, or as Protection switching may be triggered manually by the operator, or as
a result of loss of connectivity (detected using the mechanisms of a result of loss of connectivity (detected using the mechanisms of
[RFC5085] and [RFC5586]), or service degradation (detected using [RFC5085] and [RFC5586]), or service degradation (detected using
mechanisms yet to be defined). mechanisms yet to be defined).
Automated protection switching is just one of the functions for which Automated protection switching is just one of the functions for which
a transport service require OAM. OAM is generally referred to as a transport service requires OAM. OAM is generally referred to as
either "proactive" or "on-demand", where the distinction is whether a either "proactive" or "on-demand", where the distinction is whether a
specific OAM tool is being used continuously over time (for the specific OAM tool is being used continuously over time (for the
purpose of detecting a need for protection switching, for example) or purpose of detecting a need for protection switching, for example) or
is only used - either a limited number of times, or over a short is only used - either a limited number of times, or over a short
period of time - when explicitly enabled (for diagnostics, for period of time - when explicitly enabled (for diagnostics, for
example). example).
PW OAM currently consists of connectivity verification defined by PW OAM currently consists of connectivity verification defined by
[RFC5085]. Work is currently in progress to extend PW OAM to include [RFC5085]. Work is currently in progress to extend PW OAM to include
bidirectional forwarding detection (BFD) in [RFC5885], and work has bidirectional forwarding detection (BFD) in [RFC5885], and work has
begun on extending BFD to include performance related monitor begun on extending BFD to include performance-related monitor
functions. functions.
5.3.6. Client Layer and Cross-Provider Interfaces to PW Control 5.3.6. Client Layer and Cross-Provider Interfaces to PW Control
Additional work is likely to be required to define consistent access Additional work is likely to be required to define consistent access
by a client layer network, as well as between provider networks, to by a client layer network, as well as between provider networks, to
control information available to each type of network, for example, control information available to each type of network, for example,
about the topology of an MS-PW. This information may be required by about the topology of an MS-PW. This information may be required by
the client layer network in order to provide hints that may help to the client layer network in order to provide hints that may help to
avoid establishment of fate-sharing alternate paths. Such work will avoid establishment of fate-sharing alternate paths. Such work will
skipping to change at page 45, line 40 skipping to change at page 45, line 46
- Client layer Interfaces for PW control (Section 5.3.6) - Client layer Interfaces for PW control (Section 5.3.6)
This work is expected to be consistent with ASON architecture and may This work is expected to be consistent with ASON architecture and may
require additional specification in order to achieve this goal. require additional specification in order to achieve this goal.
6. Security Considerations 6. Security Considerations
This document primarily describes how existing mechanisms can be used This document primarily describes how existing mechanisms can be used
to meet the MPLS-TP control plane requirements. The documents that to meet the MPLS-TP control plane requirements. The documents that
describe each mechanism contain their own security considerations describe each mechanism contain their own security considerations
sections. For a general discussion on MPLS and GMPLS related sections. For a general discussion on MPLS- and GMPLS-related
security issues, see the MPLS/GMPLS security framework [RFC5920]. security issues, see the MPLS/GMPLS security framework [RFC5920]. As
mentioned above in Section 2.4., there are no specific MPLS-TP
control plane security requirements.
This document also identifies a number of needed control plane This document also identifies a number of needed control plane
extensions. It is expected that the documents that define such extensions. It is expected that the documents that define such
extensions will also include any appropriate security considerations. extensions will also include any appropriate security considerations.
7. IANA Considerations 7. IANA Considerations
There are no new IANA considerations introduced by this document. There are no new IANA considerations introduced by this document.
8. Acknowledgments 8. Acknowledgments
skipping to change at page 49, line 11 skipping to change at page 49, line 11
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., Berger, [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., Berger,
L., "A Framework for MPLS in Transport Networks", RFC L., "A Framework for MPLS in Transport Networks", RFC
5921, July 2010. 5921, July 2010.
[RFC5960] Frost, D., Bryant, S., Bocci, M., "MPLS Transport [RFC5960] Frost, D., Bryant, S., Bocci, M., "MPLS Transport
Profile Data Plane Architecture", RFC 5960, August 2010. Profile Data Plane Architecture", RFC 5960, August 2010.
[TP-IDENTIFIERS] Bocci, M., Swallow, G., "MPLS-TP Identifiers", [TP-IDENTIFIERS] Bocci, M., Swallow, G., "MPLS-TP Identifiers",
work in progress, draft-ietf-mpls-tp-identifiers. work in progress, draft-ietf-mpls-tp-identifiers.
[TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM [TP-OAM] Busi, I., Ed., Allan, D., Ed., "Operations,
Framework and Overview", work in progress, Administration and Maintenance Framework for MPLS-based
Transport Networks", work in progress,
draft-ietf-mpls-tp-oam-framework. draft-ietf-mpls-tp-oam-framework.
[TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label Switching [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label Switching
Transport Profile Survivability Framework", work in Transport Profile Survivability Framework", work in
progress, draft-ietf-mpls-tp-survive-fwk. progress, draft-ietf-mpls-tp-survive-fwk.
9.2. Informative References 9.2. Informative References
[CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration
Framework and Requirements for GMPLS RSVP-TE", Framework and Requirements for GMPLS RSVP-TE",
skipping to change at page 49, line 35 skipping to change at page 49, line 36
[CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for [CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for
MPLS-TP OAM Configuration", work in progress, MPLS-TP OAM Configuration", work in progress,
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext. draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext.
[GMPLS-PS] Takacs, A., et al, "GMPLS RSVP-TE Recovery Extension [GMPLS-PS] Takacs, A., et al, "GMPLS RSVP-TE Recovery Extension
for data plane initiated reversion and protection timer for data plane initiated reversion and protection timer
signalling", work in progress, signalling", work in progress,
draft-takacs-ccamp-revertive-ps. draft-takacs-ccamp-revertive-ps.
[HIERARCHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched
Paths", work in progress,
draft-ietf-ccamp-lsp-hierarchy-bis.
[TE-MIB] T Otani, et.al., "Traffic Engineering Database Management [TE-MIB] T Otani, et.al., "Traffic Engineering Database Management
Information Base in support of MPLS-TE/GMPLS", work in Information Base in support of MPLS-TE/GMPLS", work in
progress, draft-ietf-ccamp-gmpls-ted-mib. progress, draft-ietf-ccamp-gmpls-ted-mib.
[MS-PW-DYNAMIC] L. Martini, M Bocci, and F Balus "Dynamic [MS-PW-DYNAMIC] L. Martini, M Bocci, and F Balus "Dynamic
Placement of Multi Segment Pseudo Wires", work in Placement of Multi Segment Pseudo Wires", work in
progress, draft-ietf-pwe3-dynamic-ms-pw. progress, draft-ietf-pwe3-dynamic-ms-pw.
[ITU.G8080.2006] International Telecommunications Union, [ITU.G8080.2006] International Telecommunications Union,
"Architecture for the automatically switched "Architecture for the automatically switched
skipping to change at page 50, line 14 skipping to change at page 50, line 9
[ITU.G8080.2008] International Telecommunications Union, [ITU.G8080.2008] International Telecommunications Union,
"Architecture for the automatically switched "Architecture for the automatically switched
optical network (ASON) Amendment 1", ITU-T optical network (ASON) Amendment 1", ITU-T
Recommendation G.8080 Amendment 1, March 2008. Recommendation G.8080 Amendment 1, March 2008.
[NO-PHP] Ali, z., et al, "Non PHP Behavior and out-of-band mapping [NO-PHP] Ali, z., et al, "Non PHP Behavior and out-of-band mapping
for RSVP-TE LSPs", work in progress, for RSVP-TE LSPs", work in progress,
draft-ietf-mpls-rsvp-te-no-php-oob-mapping draft-ietf-mpls-rsvp-te-no-php-oob-mapping
[PW-RED] Muley, P., et al, "Pseudowire (PW) Redundancy", work in [PW-RED] Muley, P., et al, "Pseudowire (PW) Redundancy", work in
progress, draft-ietf-pwe3-redundancy. progress, draft-ietf-pwe3-redundancy.
[PW-REDB] Muley, P., et al, "Preferential Forwarding Status bit [PW-REDB] Muley, P., et al, "Preferential Forwarding Status bit
definition", work in progress, definition", work in progress,
draft-ietf-pwe3-redundancy-bit. draft-ietf-pwe3-redundancy-bit.
[PW-OAM] Zhang, F., et al, "LDP Extensions for MPLS-TP PW OAM [PW-OAM] Zhang, F., et al, "LDP Extensions for MPLS-TP PW OAM
configuration", work in progress, configuration", work in progress,
draft-zhang-mpls-tp-pw-oam-config. draft-zhang-mpls-tp-pw-oam-config.
[PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint [PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint
skipping to change at page 50, line 37 skipping to change at page 50, line 32
draft-raggarwa-pwe3-p2mp-pw-encaps. draft-raggarwa-pwe3-p2mp-pw-encaps.
[PW-P2MPR] Jounay, F., et al, "Requirements for [PW-P2MPR] Jounay, F., et al, "Requirements for
Point-to-Multipoint Pseudowire", work in progress, Point-to-Multipoint Pseudowire", work in progress,
draft-ietf-pwe3-p2mp-pw-requirements. draft-ietf-pwe3-p2mp-pw-requirements.
[RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label Switching [RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label Switching
(MPLS) Support of Differentiated Services", RFC 3270, (MPLS) Support of Differentiated Services", RFC 3270,
May 2002. May 2002.
[RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS
signaling protocols", RFC 3468, February 2003.
[RFC3472] Ashwood-Smith, P., Ed, Berger, L. Ed., "Generalized [RFC3472] Ashwood-Smith, P., Ed, Berger, L. Ed., "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Multi-Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol Constraint-based Routed Label Distribution Protocol
(CR-LDP) Extensions", RFC 3472, January 2003. (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful [RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful
skipping to change at page 53, line 26 skipping to change at page 53, line 26
[RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions [RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions
for ASON Routing", RFC 5787, March 2010. for ASON Routing", RFC 5787, March 2010.
[RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., [RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D.,
Bardalai, S., "RSVP-TE Signaling Extension for LSP Bardalai, S., "RSVP-TE Signaling Extension for LSP
Handover from the Management Plane to the Control Plane Handover from the Management Plane to the Control Plane
in a GMPLS-Enabled Transport Network", RFC 5852, April in a GMPLS-Enabled Transport Network", RFC 5852, April
2010. 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) For MPLS "Bidirectional Forwarding Detection (BFD) For MPLS
Label Switched Paths (LSPs)", RFC 5884, June 2010. Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Forwarding Detection (BFD) for the Pseudowire
Virtual Circuit Connectivity Verification (VCCV)", Virtual Circuit Connectivity Verification (VCCV)",
RFC 5885, June 2010. RFC 5885, June 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC5951] Lam, K., Mansfield, S., Gray, E., "Network Management
Requirements for MPLS-based Transport Networks", RFC
5951, September 2010.
[RFC6001] Papadimitriou, D., et al, "Generalized Multi-Protocol [RFC6001] Papadimitriou, D., et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Label Switching (GMPLS) Protocol Extensions for
Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC
6001, October 2010. 6001, October 2010.
[SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M., "Segmented [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., Aissaoui, M.,
Pseaudowire", work in progress, "Segmented Pseudowire", RFC 6073, January 2011.
draft-ietf-pwe3-segmented-pw.
[RFC6107] Shiomoto, K., Farrel, A., "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", RFC 6107,
February 2011.
[TP-MIB] Farrel, A., King, D., Mahalingam, V., Ryoo, J., Koushik,
K., "Multiprotocol Label Switching Transport Profile
(MPLS-TP) MIB-based Management Overview", work in
progress, draft-ietf-mpls-tp-mib-management-overview.
[TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for [TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for
Point-to-Multipoint MPLS in Transport Networks", Point-to-Multipoint MPLS in Transport Networks",
draft-fbb-mpls-tp-p2mp-framework. draft-fbb-mpls-tp-p2mp-framework.
[TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in [TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in
progress, draft-weingarten-mpls-tp-ring-protection. progress, draft-weingarten-mpls-tp-ring-protection.
[TP-UNI] Bocci, M., Levrau, L., Frost, D., "MPLS Transport Profile
User-to-Network and Network-to-Network Interfaces", work
in progress, draft-ietf-mpls-tp-uni-nni.
10. Authors' Addresses 10. Authors' Addresses
Loa Andersson (editor) Loa Andersson (editor)
Ericsson Ericsson
Phone: +46 10 717 52 13 Phone: +46 10 717 52 13
Email: loa.andersson@ericsson.com Email: loa.andersson@ericsson.com
Lou Berger (editor) Lou Berger (editor)
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
skipping to change at line 2590 skipping to change at line 2643
Martin Vigoureux Martin Vigoureux
Alcatel-Lucent Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.fr Email: martin.vigoureux@alcatel-lucent.fr
Elisa Bellagamba Elisa Bellagamba
Ericsson Ericsson
Farogatan, 6 Farogatan, 6
164 40, Kista, Stockholm, SWEDEN 164 40, Kista, Stockholm, SWEDEN
Email: elisa.bellagamba@ericsson.com Email: elisa.bellagamba@ericsson.com
Generated on: Fri, Jan 07, 2011 2:44:55 PM Generated on: Thu, Feb 10, 2011 9:01:05 AM
 End of changes. 221 change blocks. 
416 lines changed or deleted 470 lines changed or added

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