draft-ietf-ccamp-mpls-tp-cp-framework-01.txt   draft-ietf-ccamp-mpls-tp-cp-framework-02.txt 
Internet Draft Loa Andersson, Ed. (Acreo AB) Internet Draft Loa Andersson, Ed. (Ericsson)
Category: Informational Lou Berger, Ed. (LabN) Category: Informational Lou Berger, Ed. (LabN)
Expiration Date: September 22, 2010 Luyuan Fang, Ed. (Cisco) Expiration Date: December 18, 2010 Luyuan Fang, Ed. (Cisco)
Nabil Bitar, Ed. (Verizon) Nabil Bitar, Ed. (Verizon)
March 22, 2010 June 18, 2010
MPLS-TP Control Plane Framework MPLS-TP Control Plane Framework
draft-ietf-ccamp-mpls-tp-cp-framework-01.txt draft-ietf-ccamp-mpls-tp-cp-framework-02.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 and provides for GMPLS as the control plane for MPLS-TP LSPs and provides for
compatibility with MPLS. The control plane for Pseudowires (PWs) compatibility with MPLS. MPLS-TP also uses the control plane for
is also covered by this document. Management plane functions such Pseudowires (PWs). Management plane functions such as manual
as manual configuration and the initiation of LSP setup are out of configuration and the initiation of LSP setup are out of scope of
scope of this document. this document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 September 22, 2010 This Internet-Draft will expire on December 18, 2010
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
1.1 Conventions Used In This Document ...................... 3 1.1 Conventions Used In This Document ...................... 3
1.2 Scope .................................................. 3 1.2 Scope .................................................. 4
1.3 Basic Approach ......................................... 4 1.3 Basic Approach ......................................... 4
1.4 Reference Model ........................................ 5 1.4 Reference Model ........................................ 5
2 Control Plane Requirements ............................. 8 2 Control Plane Requirements ............................. 8
2.1 Primary Requirements ................................... 8 2.1 Primary Requirements ................................... 8
2.2 MPLS-TP Framework Derived Requirements ................. 17 2.2 MPLS-TP Framework Derived Requirements ................. 17
2.3 OAM Framework Derived Requirements ..................... 18 2.3 OAM Framework Derived Requirements ..................... 18
2.4 Security Requirements .................................. 21 2.4 Security Requirements .................................. 21
3 Relationship of PWs and TE LSPs ........................ 21 3 Relationship of PWs and TE LSPs ........................ 21
4 TE LSPs ................................................ 22 4 TE LSPs ................................................ 22
4.1 GMPLS Functions and MPLS-TP LSPs ....................... 22 4.1 GMPLS Functions and MPLS-TP LSPs ....................... 22
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4.1.7 Link Bundling .......................................... 25 4.1.7 Link Bundling .......................................... 25
4.1.8 Hierarchical LSPs ...................................... 25 4.1.8 Hierarchical LSPs ...................................... 25
4.1.9 LSP Recovery ........................................... 26 4.1.9 LSP Recovery ........................................... 26
4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 26 4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 26
4.2 OAM, MEP (Hierarchy) Configuration and Control ......... 26 4.2 OAM, MEP (Hierarchy) Configuration and Control ......... 26
4.2.1 Management Plane Support ............................... 27 4.2.1 Management Plane Support ............................... 27
4.3 GMPLS and MPLS-TP Requirements Table ................... 28 4.3 GMPLS and MPLS-TP Requirements Table ................... 28
4.4 Anticipated MPLS-TP Related Extensions and Definitions . 31 4.4 Anticipated MPLS-TP Related Extensions and Definitions . 31
4.4.1 MPLS to MPLS-TP Interworking ........................... 31 4.4.1 MPLS to MPLS-TP Interworking ........................... 31
4.4.2 Associated Bidirectional LSPs .......................... 31 4.4.2 Associated Bidirectional LSPs .......................... 31
4.4.3 Asymmetric Bandwidth LSPs .............................. 31 4.4.3 Asymmetric Bandwidth LSPs .............................. 32
4.4.4 Recovery for P2MP LSPs ................................. 32 4.4.4 Recovery for P2MP LSPs ................................. 32
4.4.5 Test Traffic Control and other OAM functions ........... 32 4.4.5 Test Traffic Control and other OAM functions ........... 32
4.4.6 DiffServ Object usage in GMPLS ......................... 32 4.4.6 DiffServ Object usage in GMPLS ......................... 32
5 Pseudowires ............................................ 32 5 Pseudowires ............................................ 33
5.1 LDP Functions and Pseudowires .......................... 32 5.1 LDP Functions and Pseudowires .......................... 33
5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 33 5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 34
5.3 Anticipated MPLS-TP Related Extensions ................. 35 5.3 Anticipated MPLS-TP Related Extensions ................. 36
5.4 Pseudowire OAM and Recovery (Redundancy) ............... 37 5.3.1 Extensions to Support Out-of-Band PW Control ........... 37
6 Security Considerations ................................ 38 5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 37
7 IANA Considerations .................................... 38 5.3.3 Support for Dynamic Transfer of PW Control/Ownership ... 38
8 Acknowledgments ........................................ 38 5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 38
9 References ............................................. 38 5.3.5 Support for PW Protection and PW OAM Configuration ..... 39
9.1 Normative References ................................... 38 5.3.6 Client Layer Interfaces to Pseudowire Control .......... 39
9.2 Informative References ................................. 41 5.4 Pseudowire OAM and Recovery (Redundancy) ............... 39
10 Authors' Addresses ..................................... 46 6 Security Considerations ................................ 40
7 IANA Considerations .................................... 40
8 Acknowledgments ........................................ 40
9 References ............................................. 40
9.1 Normative References ................................... 40
9.2 Informative References ................................. 43
10 Authors' Addresses ..................................... 48
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) is being defined in a joint The MPLS Transport Profile (MPLS-TP) is being defined in a joint
effort between the International Telecommunications Union (ITU) and effort between the International Telecommunications Union (ITU) and
the IETF. The requirements for MPLS-TP are defined in the the IETF. The requirements for MPLS-TP are defined in the
requirements document, see [RFC5654]. These requirements state that requirements document, see [RFC5654]. These requirements state that
"A solution MUST be provided to support dynamic provisioning of MPLS- "A solution MUST be provided to support dynamic provisioning of MPLS-
TP transport paths via a control plane." This document provides the TP transport paths via a control plane." This document provides the
framework for such dynamic provisioning. framework for such dynamic provisioning.
skipping to change at page 4, line 11 skipping to change at page 4, line 20
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, Sections the role of the control plane in MPLS-TP. In particular, Sections
2.4 and portions of the remainder of Section 2 of [RFC5654] provide 2.4 and portions of the remainder of Section 2 of [RFC5654] provide
specific control plane requirements. specific control plane requirements.
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 a Packet switched network (PSN). The PW encapsulation over MPLS-TP in a Packet switched network (PSN). The PW encapsulation over MPLS-TP
LSPs used in MPLS-TP networks is the same as for PWs over MPLS in an LSPs used in MPLS-TP networks is also the same as for PWs over MPLS
MPLS network. MPLS-TP also defines protection and restoration (or, in an MPLS network. MPLS-TP also defines protection and restoration
collectively, recovery) functions. The MPLS-TP control plane provides (or, collectively, recovery) functions. The MPLS-TP control plane
methods to establish, remove and control MPLS-TP LSPs and PWs. This provides methods to establish, remove and control MPLS-TP LSPs and
includes control of data plane, OAM and recovery functions. PWs. This includes control of data plane, OAM and recovery
functions.
A general framework for MPLS-TP has been defined in [TP-FWK], and a A general framework for MPLS-TP has been defined in [TP-FWK], 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 document scope the approaches and protocols that will be used These document scope the approaches and protocols that will be used
as the foundation for MPLS-TP. Notably, Section 3.5 of [TP-FWK] as the foundation for MPLS-TP. Notably, Section 3.5 of [TP-FWK]
scopes the IETF protocols that serve as the foundation of the MPLS-TP scopes the 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) control plane, see [RFC4447], and the PW end-to-end (PWE3)
architecture, see [RFC3985]. The LSP control plane is based on architecture, see [RFC3985]. The LSP control plane is based on
Generalized MPLS (GMPLS), see [RFC3945], which is built on MPLS Generalized MPLS (GMPLS), see [RFC3945], which is built on MPLS
Traffic Engineering (TE) and its numerous extensions. [TP-SURVIVE] Traffic Engineering (TE) and its numerous extensions. [TP-SURVIVE]
focuses on LSPs, and the protection functions that must be supported focuses on LSPs, and the protection functions that must be supported
within MPLS-TP. It does not specify which control plane mechanisms within MPLS-TP. It does not specify which control plane mechanisms
are to be used. are to be used.
The remainder of this document discusses the impact of MPLS-TP The remainder of this document discusses the impact of MPLS-TP
requirements on the signaling that is used to provision PWs as requirements on the control of PWs as specified in [RFC4447],
specified in [RFC4447]. This document also discusses the impact of [SEGMENTED-PW] and [MS-PW-DYNAMIC]. This document also discusses the
the MPLS-TP requirements on the GMPLS signaling and routing protocols impact of the MPLS-TP requirements on the GMPLS signaling and routing
that is used to provision MPLS-TP LSPs. protocols that are used to control MPLS-TP LSPs.
1.3. Basic Approach 1.3. 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 is:
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 and MPLS-TP is identical, i.e. any 2) The data plane for MPLS and MPLS-TP is identical, i.e. any
extensions defined for MPLS-TP is also applicable to MPLS. extensions defined for MPLS-TP is also applicable to MPLS.
skipping to change at page 5, line 8 skipping to change at page 5, line 21
3) MPLS PWs are used as-is by MPLS-TP including the use of 3) MPLS PWs are used as-is by MPLS-TP including the use of
targeted-LDP as the foundation for PW signaling [RFC4447], targeted-LDP as the foundation for PW signaling [RFC4447],
OSPF-TE, ISIS-TE or MP-BGP as they apply for Multi- OSPF-TE, ISIS-TE or MP-BGP as they apply for Multi-
Segment(MS)-PW routing. However, the PW can be encapsulated Segment(MS)-PW routing. However, the PW can be encapsulated
over an MPLS-TP LSP (established using methods and procedures over an MPLS-TP LSP (established using methods and procedures
for MPLS-TP LSP establishment) in addition to the presently for MPLS-TP LSP establishment) in addition to the presently
defined methods of carrying PWs over LSP based packet switched defined methods of carrying PWs over LSP based packet switched
networks (PSNs). That is, the MPLS-TP domain is a packet networks (PSNs). That is, the MPLS-TP domain is a packet
switched network from a PWE3 architecture aspect [RFC3985]. switched network from a PWE3 architecture aspect [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 within as defined by the IETF for transport LSPs. The protocols
scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392], and within scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392],
ISIS-TE [RFC5307][RFC5316]. ASON/ASTN signaling and routing and ISIS-TE [RFC5307][RFC5316]. ASON/ASTN signaling and
requirements in the context of GMPLS can be found in [RFC4139] routing requirements in the context of GMPLS can be found in
and [RFC4258]. [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 GMPLS control plane may be required in order 7) Extensions to the GMPLS control plane may be required in order
to fully automate MPLS-TP functions. to fully automate MPLS-TP functions.
8) Control-plane software upgrades to existing MPLS enabled 8) Control-plane software upgrades to existing (G)MPLS enabled
equipment is acceptable and expected. equipment is acceptable and expected.
9) It is permissible for functions present in the GMPLS control 9) It is permissible for functions present in the GMPLS control
plane to not be used in MPLS-TP networks, e.g. the possibility plane to not be used in MPLS-TP networks, e.g. the possibility
to merge LSPs. to merge LSPs.
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 empower OAM functionality. This will require extensions to and empower OAM functionality. This will require extensions to
existing control plane specifications which will be usable in existing control plane specifications which will be usable in
MPLS-TP as well as MPLS networks. MPLS-TP as well as MPLS networks.
11) MPLS-TP requirements are primarily defined in Section 2.4 and 11) MPLS-TP requirements are primarily defined in Section 2.4 and
relevant portions of the remainder Section 2 of [RFC5654]. relevant portions of the remainder Section 2 of [RFC5654].
1.4. Reference Model 1.4. 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 [TP-FWK]. Per the reference model as defined in the MPLS-TP framework [TP-FWK]. Per the
MPLS-TP framework [TP-FWK], the MPLS-TP control plane is based on MPLS-TP framework [TP-FWK], the MPLS-TP control plane is based on
GMPLS with RSVP-TE for LSP signaling and LDP for PW signaling. In GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW
both cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions
dynamic routing. is used for dynamic routing within an MPLS-TP domain.
From a service perspective, client interfaces are provided for both From a service perspective, client interfaces are provided for both
the PWs and LSPs. PW client interfaces are defined on an interface the PWs and LSPs. PW client interfaces are defined on an interface
technology basis, e.g., Ethernet over PW [RFC4448]. In the context of technology basis, e.g., Ethernet over PW [RFC4448]. In the context of
MPLS-TP LSP, the client interface is expected to be provided via a MPLS-TP LSP, the client interface is expected to be provided via a
GMPLS based UNI, see [RFC4208], or statically provisioned. As GMPLS based UNI, see [RFC4208], or statically provisioned. As
discussed in [TP-FWK], MPLS-TP also presumes an LSP NNI reference discussed in [TP-FWK], MPLS-TP also presumes an LSP NNI reference
point. 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. It shows the control plane protocols used by MPLS-TP, as Figure 1. The Figure shows the control plane protocols used by MPLS-
well as the UNI and NNI reference points. TP, as well as the UNI and NNI reference points.
|< ---- client signal (IP / MPLS / L2 / PW) ------------ >| |< ---- client signal (IP / MPLS / L2 / PW) ------------ >|
|< --------- 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 --------- >|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|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 6, line 35 skipping to change at page 6, line 47
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
PE: Provider Edge PE: Provider Edge
SP: Service Provider SP: Service Provider
TE-RTG: OSPF-TE or ISIS-TE TE-RTG: OSPF-TE or ISIS-TE
UNI: User to Network Interface UNI: User to Network Interface
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 MEPs within These segments are present to support scaling, OAM and MEPs within
each provider and across the inter-provider NNI. The MEPs are used each provider domain and across the inter-provider NNI. The MEPs are
to collect performance information, support diagnostic functions, and used to collect performance information, support diagnostic
support OAM triggered survivability schemes as discussed in [TP- functions, and support OAM triggered survivability schemes as
SURVIVE], and each H-LSP may be protected using any of the schemes discussed in [TP-SURVIVE]. Each H-LSP may be protected using any of
discussed in [TP-SURVIVE]. End-to-end monitoring is supported via the schemes discussed in [TP-SURVIVE]. End-to-end monitoring is
MEPs at the End-to-End LSP end-points. Note that segment MEPs end- supported via MEPs at the End-to-End LSP and PW end points. Note
points are collocated with MIPs of the next higher-layer (e.g., end- that segment MEPs are collocated with MIPs of the next higher-layer
to-end) LSPs. (e.g., end-to-end) LSPs.
|< ------- client signal (IP / MPLS / L2 / PW) ------ >| |< ------- client signal (IP / MPLS / L2 / PW) ------ >|
|< -------- 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|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 8, line 9 skipping to change at page 8, line 9
While not shown in the Figures above, it is worth noting that the While not shown in the Figures above, it is worth noting that the
MPLS-TP control plane must support the addressing separation and MPLS-TP control plane must support the addressing separation and
independence between the data, control and management planes as shown independence between the data, control and management planes as shown
in Figure 3 of [TP-FWK]. Address separation between the planes is in Figure 3 of [TP-FWK]. Address separation between the planes is
already included in GMPLS. already included in GMPLS.
2. Control Plane Requirements 2. Control Plane Requirements
The requirements for the MPLS-TP control plane are derived from the The requirements for the MPLS-TP control plane are derived from the
MPLS-TP requirements and framework documents, specifically [RFC5654], MPLS-TP requirements and framework documents, specifically [RFC5654],
[TP-FWK], [TP-OAM-REQ], [TP-OAM], and [TP-SURVIVE]. The requirements [TP-FWK], [RFC5860], [TP-OAM], and [TP-SURVIVE]. The requirements
are summarized in this section, but do not replace those documents. are summarized in this section, but do not replace those documents.
If there are differences between this section and those documents, If there are differences between this section and those documents,
those documents shall be considered authoritative. those documents shall be considered authoritative.
2.1. Primary Requirements 2.1. Primary Requirements
These requirements are based on Section 2 [RFC5654]: These requirements are based on Section 2 [RFC5654]:
1. Any new functionality that is defined to fulfill the 1. Any new functionality that is defined to fulfill the
requirements for MPLS-TP must be agreed within the IETF through requirements for MPLS-TP must be agreed within the IETF through
the IETF consensus process as per [RFC4929] [RFC5654, Section the IETF consensus process as per [RFC4929] [RFC5654, Section
1, Paragraph 15]. 1, Paragraph 15].
2. The MPLS-TP control plane design should as far as reasonably 2. The MPLS-TP control plane design should as far as reasonably
possible reuse existing MPLS standards [RFC5654, requirement possible reuse existing MPLS standards [RFC5654, requirement
2]. 2].
3. The MPLS-TP control plane must be able to interoperate with 3. The MPLS-TP control plane must be able to interoperate with
existing IETF MPLS and PWE3 control planes where appropriate existing IETF MPLS and PWE3 control planes where appropriate
[RFC5654, requirement 3]. [RFC5654, requirement 3].
4. The MPLS-TP control plane must be sufficiently well-defined 4. The MPLS-TP control plane must be sufficiently well-defined to
that interworking equipment supplied by multiple vendors will ensure the interworking between equipment supplied by multiple
be possible both within a single domain and between domains vendors will be possible both within a single domain and
[RFC5654, requirement 4]. between domains [RFC5654, requirement 4].
5. The MPLS-TP control plane must support a connection- oriented 5. The MPLS-TP control plane must support a connection-oriented
packet switching model with traffic engineering capabilities packet switching model with traffic engineering capabilities
that allow deterministic control of the use of network that allow deterministic control of the use of network
resources [RFC5654, requirement 5]. resources [RFC5654, requirement 5].
6. The MPLS-TP control plane must support traffic-engineered 6. The MPLS-TP control plane must support traffic-engineered
point-to-point (P2P) and point-to-multipoint (P2MP) transport point-to-point (P2P) and point-to-multipoint (P2MP) transport
paths [RFC5654, requirement 6]. paths [RFC5654, requirement 6].
7. The MPLS-TP control plane must support unidirectional, 7. The MPLS-TP control plane must support unidirectional,
associated bidirectional and co-routed bidirectional point-to- associated bidirectional and co-routed bidirectional point-to-
skipping to change at page 11, line 22 skipping to change at page 11, line 22
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 SRLGs or reachability) between
layers [RFC5654, requirement 35]. 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 P2MP capable server 34. The MPLS-TP control plane must allow for P2MP capable server
(sub-)layers. (sub-)layers [RFC5654, requirement 40].
35. The MPLS-TP control plane must be extensible in order to 35. The MPLS-TP control plane must be extensible in order to
accommodate new types of client layer networks and services accommodate new types of client layer networks and services
[RFC5654, requirement 41]. [RFC5654, requirement 41].
36. The MPLS-TP control plane should support the reserved bandwidth 36. The MPLS-TP control plane should support the reserved bandwidth
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].
skipping to change at page 16, line 21 skipping to change at page 16, line 21
requirement 89 A]. requirement 89 A].
87. The MPLS-TP control plane must support signaling of recovery 87. 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 88. 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). recovery mechanism (e.g. backup) [RFC5654, requirement 89 C].
89. When present, the MPLS-TP control plane must support recovery 89. 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 90. 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 91. 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 92. 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 and relative end-to-end bandwidth (SLS), with support for hard ([RFC3209] style) and relative
guarantees [RFC5654, requirement 111]. [Editor's note: add ([RFC3270] style) end-to-end bandwidth guarantees [RFC5654,
reference to definition of hard and relative guarantees] requirement 111].
93. The MPLS-TP control plane must support the provisioning of 93. 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 [TP-FWK]: The following additional requirements are based on [TP-FWK], [TP-
[Editor's note: Need to update section (on document) to match split P2MP-FWK] and [TP-DATA]:
of P2P and P2MP now in [TP-FWK] and [TP-P2MP-FWK].)
94. Per-packet equal cost multi-path (ECMP) load balancing is not 94. Per-packet equal cost multi-path (ECMP) load balancing is not
applicable to MPLS-TP [TP-FWK, section 3.3.2, paragraph 9]. applicable to MPLS-TP [TP-DATA-PLANE , section 3.1.1.,
paragraph 6].
95. Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by 95. Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by
default. The applicability of PHP to both MPLS-TP LSPs and MPLS default. The applicability of PHP to both MPLS-TP LSPs and MPLS
networks general providing packet transport services will be networks generally providing packet transport services will be
clarified in a future version. [TP-FWK, section 3.3.2, clarified in a future version [TP-DATA-PLANE , section 3.1.1.,
paragraph 10] paragraph 7].
96. The MPLS-TP control plane must support both E-LSP and L-LSP 96. The MPLS-TP control plane must support both E-LSP and L-LSP
MPLS DiffServ modes as specified in [RFC3270] [TP-FWK, section MPLS DiffServ modes as specified in [RFC3270] [TP-DATA-PLANE ,
3.3.2, paragraph 11]. section 3.3.2., paragraph 12].
97. Both single-segment and multi-segment PWs shall be supported by 97. Both single-segment and multi-segment PWs shall be supported by
the MPLS-TP control plane. MPLS-TP shall use the definition of the MPLS-TP control plane. MPLS-TP shall use the definition of
multi-segment PWs as defined by the IETF [TP-FWK, section multi-segment PWs as defined by the IETF [TP-FWK, section
3.4.2.]. 3.4.4.].
98. The MPLS-TP control plane must support the control of PWs and 98. The MPLS-TP control plane must support the control of PWs and
their associated labels [TP-FWK, section 3.4.2.]. their associated labels [TP-FWK, section 3.4.4.].
99. The MPLS-TP control plane must support network layer clients, 99. 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 [TP-FWK, section 3.4.3.]. network without the use of PWs [TP-FWK, 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. [TP-FWK, section layer protocol-specific LSPs and labels. [TP-FWK, section
3.4.3.] 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. [TP-FWK, section client service-specific LSPs and labels. [TP-FWK, section
3.4.3.] 3.4.5.]
100. The MPLS-TP control plane is based on the GMPLS control plane 100. The MPLS-TP control plane is based on the GMPLS control plane
for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE [RFC3473] for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE [RFC3473]
and related extensions are used for LSP signaling, and GMPLS and related extensions are used for LSP signaling, and GMPLS
OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing
[TP-FWK, section 3.8.]. [TP-FWK, section 3.9.].
101. The MPLS-TP control plane is based on the MPLS control plane 101. The MPLS-TP control plane is based on the MPLS control plane
for PWs, and more specifically, Targeted LDP (T-LDP) [RFC4447] for PWs, and more specifically, Targeted LDP (T-LDP) [RFC4447]
is used for PW signaling [TP-FWK, section 3.8, paragraph 6]. is used for PW signaling [TP-FWK, section 3.9., paragraph 5].
102. (Requirement removed from [TP-FWK].) 102. Requirement intentionally blank.
103. The MPLS-TP control plane must ensure its own survivability and 103. 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 [TP-FWK-06, section 3.8., paragraph 12]. configurations [TP-FWK, section 3.9., paragraph 16].
104. The MPLS-TP control plane must support linear, ring and meshed 104. The MPLS-TP control plane must support linear, ring and meshed
protection schemes [TP-FWK-06, section 3.10., paragraph 8]. protection schemes [TP-FWK, section 3.12., paragraph 3].
2.3. OAM Framework Derived Requirements 2.3. OAM Framework Derived Requirements
The following additional requirements are based on [TP-OAM-REQ] and The following additional requirements are based on [RFC5860] and [TP-
[TP-OAM]: OAM]:
105. 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 as part of service establishment enable/disable OAM functions as part of service establishment
[TP-OAM-REQ, section 2.1.6., paragraph 1]. [RFC5860, section 2.1.6., paragraph 1].
106. The MPLS-TP control plane must support the capability to 106. 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 [TP-OAM-REQ, section as a result of OAM enabling/disabling [RFC5860, section 2.1.6.,
2.1.6., paragraph 1 and 2]. paragraph 1 and 2].
107. The MPLS-TP control plane must allow for the IP/MPLS and PW OAM 107. The MPLS-TP control plane must allow for the IP/MPLS and PW OAM
protocols (e.g., LSP-Ping [RFC4379], MPLS-BFD [BFD-MPLS], VCCV protocols (e.g., LSP-Ping [RFC4379], MPLS-BFD [RFC5884], VCCV
[RFC5085] and VCCV-BFD [VCCV-BFD]) [TP-OAM-REQ, section 2.1.4., [RFC5085] and VCCV-BFD [RFC5885]) [RFC5860, section 2.1.4.,
paragraph 2]. paragraph 2].
108. The MPLS-TP control plane must allow for the ability to support 108. 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 [TP-OAM-REQ, 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 109. 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 [TP-OAM-REQ, section 2.2., paragraph 3]. applies [RFC5860, section 2.2., paragraph 3].
110. The MPLS-TP control plane must provide a mechanism to support 110. The MPLS-TP control plane must provide a mechanism to support
the localization of faults and the notification of appropriate the localization of faults and the notification of appropriate
nodes. Such notification should trigger corrective (recovery) nodes. Such notification should trigger corrective (recovery)
actions [TP-OAM-REQ, section 2.2.1., paragraph 1]. actions [RFC5860, section 2.2.1., paragraph 1].
111. The MPLS-TP control plane must allow the service provider to be 111. The MPLS-TP control plane must allow the service provider to be
informed of a fault or defect affecting the service(s) it informed of a fault or defect affecting the service(s) it
provides, even if the fault or defect is located outside of his provides, even if the fault or defect is located outside of his
domain [TP-OAM-REQ, section 2.2.1., paragraph 2]. domain [RFC5860, section 2.2.1., paragraph 2].
112. Information exchange between various nodes involved in the 112. 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 [TP-OAM- changes are effectively known by the appropriate nodes
REQ, section 2.2.1., paragraph 3]. [RFC5860, section 2.2.1., paragraph 3].
113. The MPLS-TP control plane must provide functionality to control 113. The MPLS-TP control plane must provide functionality to control
an End Point to monitor the liveness, i.e., continuity check an End Point to monitor the liveness, i.e., continuity check
(CC), of a PW, LSP or Section [TP-OAM-REQ, section 2.2.2., (CC), of a PW, LSP or Section [RFC5860, section 2.2.2.,
paragraph 1]. paragraph 1].
114. The MPLS-TP control plane must provide functionality to control 114. 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), i.e., connectivity connected to specific End Point(s), i.e., connectivity
verification (CV), by means of the expected PW, LSP or Section verification (CV), by means of the expected PW, LSP or Section
[TP-OAM-REQ, section 2.2.3., paragraph 1]. [RFC5860, section 2.2.3., paragraph 1].
115. The MPLS-TP control plane must provide functionality to control 115. The MPLS-TP control plane must provide functionality to control
diagnostic testing on a PW, LSP or Section [TP-OAM-REQ, section diagnostic testing on a PW, LSP or Section [RFC5860, section
2.2.5., paragraph 1]. 2.2.5., paragraph 1].
116. The MPLS-TP control plane must provide functionality to enable 116. 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 [TP-OAM-REQ, trace (record) the route of a PW, LSP or Section [RFC5860,
section 2.2.4., paragraph 1]. section 2.2.4., paragraph 1].
117. The MPLS-TP control plane must provide functionality to enable 117. 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. Note that lock End Point(s) to lock the PW, LSP or Section. Note that lock
corresponds to an administrative status in which it is expected corresponds to an administrative status in which it is expected
that only test traffic, if any, and OAM (dedicated to the PW, that only test traffic, if any, and OAM (dedicated to the PW,
LSP or Section) can be mapped on that PW, LSP or Section [TP- LSP or Section) can be mapped on that PW, LSP or Section
OAM-REQ, section 2.2.6., paragraph 1]. (This requirement [RFC5860, section 2.2.6., paragraph 1].
duplicates a requirement stated above but is listed again to
maintain alignment with [TP-OAM].)
118. 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 lock condition indirectly affecting of that same PW or LSP, a lock condition indirectly affecting
that PW or LSP [TP-OAM-REQ, section 2.2.7., paragraph 1]. that PW or LSP [RFC5860, section 2.2.7., paragraph 1].
119. The MPLS-TP control plane must provide functionality to enable 119. 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 [TP-OAM-REQ, section 2.2.8., paragraph 1]. that PW or LSP [RFC5860, section 2.2.8., paragraph 1].
120. The MPLS-TP control plane must provide functionality to enable 120. 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 [TP-OAM-REQ, section 2.2.9., which they are the End Points [RFC5860, section 2.2.9.,
paragraph 1]. paragraph 1].
121. The MPLS-TP control plane must provide functionality to enable 121. 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 [TP-OAM- provide an alarm notification/propagation mechanism [RFC5860,
REQ, section 2.2.10., paragraph 1]. section 2.2.10., paragraph 1].
122. The MPLS-TP control plane must provide functionality to enable 122. 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 [TP-OAM-REQ, section 2.2.11., paragraph 1]. LSP or Section [RFC5860, section 2.2.11., paragraph 1].
123. The MPLS-TP control plane must provide functionality to control 123. 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 [TP- appropriate, the two-way, delay of a PW, LSP or Section
OAM-REQ, section 2.2.12., paragraph 1]. [RFC5860, section 2.2.12., paragraph 1].
124. The MPLS-TP control plane must support the configuration of 124. The MPLS-TP control plane must support the configuration of
MEPs. [Editor's note: this set of requirements needs to be MEPs.
aligned with the current terminology in [TP-OAM].]
a. The CC and CV functions operate between MEPs [TP-OAM, a. The CC and CV functions operate between MEPs [TP-OAM,
section 5.1., paragraph 3]. section 5.1., paragraph 3].
b. All OAM packets coming to a MEP source are tunneled via b. All OAM packets coming to a MEP source are tunneled via
label stacking, and therefore a MEP can only exist at the label stacking, and therefore a MEP can only exist at the
beginning and end of a sub-layer (i.e. at an LSP's beginning and end of an LSP (i.e. at an LSP's ingress and
ingress and egress nodes and never at an LSP's transit egress nodes and never at an LSP's transit node) [TP-OAM,
node) [TP-OAM, section 3.2., paragraph 10]. section 3.2., paragraph 10].
c. The CC and CV functions may serve as a trigger for c. The CC and CV functions may serve as a trigger for
protection switching, see requirement 45 above. protection switching, see requirement 45 above.
d. This implies that LSP hierarchy must be used in cases d. This implies that LSP hierarchy must be used in cases
where OAM is used to trigger recovery [TP-OAM, section where OAM is used to trigger recovery when the recover
4., paragraph 5]. occurs at points other than an LSPs endpoints. [TP-OAM,
section 4., paragraph 5].
125. The MPLS-TP control plane must support the signaling of the MEP 125. The MPLS-TP control plane must support the signaling of the MEP
identifier used in CC and CV [TP-OAM, section 5.1., paragraph identifier used in CC and CV [TP-OAM, section 5.1., paragraph
4]. 4].
126. The MPLS-TP control plane must support the signaling of the 126. The MPLS-TP control plane must support the signaling of the
transmission period used in CC and CV [TP-OAM, section 5.1., transmission period used in CC and CV [TP-OAM, section 5.1.,
paragraph 6]. paragraph 6].
2.4. Security Requirements 2.4. Security Requirements
skipping to change at page 21, line 35 skipping to change at page 21, line 35
tunnel control plane to exchange information necessary to support tunnel control plane to exchange information necessary to support
PWs. [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the PWs. [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the
use of LDP as the control plane for PWs. This control can provide PW use of LDP as the control plane for PWs. This control can provide PW
control without providing LSP control. control without providing LSP control.
In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS
RSVP-TE. While RSVP-TE could be extended to support PW control much RSVP-TE. While RSVP-TE could be extended to support PW control much
as LDP was extended in [RFC4447], such extensions are out of scope of as LDP was extended in [RFC4447], such extensions are out of scope of
this document. This means that the control of PWs and LSPs will this document. This means that the control of PWs and LSPs will
operate largely independently. The main coordination between LSP and operate largely independently. The main coordination between LSP and
PW control will occur within the nodes that terminate PWs. As this PW control will occur within the nodes that terminate PWs, or PW
coordination occurs within a single node, this coordination is a segments. See Section 5.3.2 for an additional discussion on such
local matter and is out of scope of this document. It is worth noting coordination.
that the control planes for PWs and LSPs may be used independently,
and that one may be employed without the other. This translates into It is worth noting that the control planes for PWs and LSPs may be
the four possible scenarios: (1) no control plane is employed; (2) a used independently, and that one may be employed without the other.
control plane is used for both LSPs and PWs; (3) a control plane is This translates into the four possible scenarios: (1) no control
used for LSPs, but not PWs; (4) a control plane is used for PWs, but plane is employed; (2) a control plane is used for both LSPs and PWs;
not LSPs. (3) a control plane is used for LSPs, but not PWs; (4) a control
plane is used for PWs, but not LSPs.
The PW and LSP control planes, collectively, must satisfy the MPLS-TP The PW and LSP control planes, collectively, must satisfy the MPLS-TP
control plane requirements reviewed in this document. When client control plane requirements reviewed in this document. When client
services are provided directly via LSPs, all requirements must be services are provided directly via LSPs, all requirements must be
satisfied by the LSP control plane. When client services are satisfied by the LSP control plane. When client services are
provided via PWs, the PW and LSP control planes operate in provided via PWs, the PW and LSP control planes operate in
combination and some functions may be satisfied via the PW control combination and some functions may be satisfied via the PW control
plane while others are provided to PWs by the LSP control plane. For plane while others are provided to PWs by the LSP control plane. For
example, to support the recovery functions described in [TP-SURVIVE] example, to support the recovery functions described in [TP-SURVIVE]
this document focuses on the control of the recovery functions at the this document focuses on the control of the recovery functions at the
skipping to change at page 24, line 18 skipping to change at page 24, line 18
build on the TE extensions to OSPF defined in [RFC3630]. The listed build on the TE extensions to OSPF defined in [RFC3630]. The listed
RFCs should be viewed as a starting point rather than an RFCs should be viewed as a starting point rather than an
comprehensive list as there are other IS-IS and OSPF extensions, as comprehensive list as there are other IS-IS and OSPF extensions, as
defined in IETF RFCs, that can be used within an MPLS-TP network. defined in IETF RFCs, that can be used within an MPLS-TP network.
4.1.4. TE LSPs and Constraint-Based Path Computation 4.1.4. TE LSPs and Constraint-Based Path Computation
Both MPLS and GMPLS allow for traffic engineering and constraint- Both MPLS and GMPLS allow for traffic engineering and constraint-
based path computation. MPLS path computation provides paths for based path computation. MPLS path computation provides paths for
MPLS TE unidirectional P2P and P2MP LSPs. GMPLS path computation MPLS TE unidirectional P2P and P2MP LSPs. GMPLS path computation
adds bidirectional LSPs, recovery path computation as well as support adds bidirectional LSPs, explicit recovery path computation as well
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), see path selection based on the use of Explicit Route Objects (EROs) and
[RFC3209] and [RFC3473]. In all cases, no specific algorithm is other LSP attributes, see [RFC3209] and [RFC3473]. In all cases, no
standardized by the IETF. This is anticipated to continue to be the specific algorithm is standardized by the IETF. This is anticipated
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
the architecture is used the PCE Communication Protocol (PCECP), see the architecture is used, the PCE Communication Protocol (PCECP), see
[RFC5440], will be used to communicate PCE requests and responses. [RFC5440], will be used to communicate PCE requests and responses.
MPLS-TP specific extensions to PCECP are currently out of scope of MPLS-TP specific extensions to PCECP are currently out of scope of
the MPLS-TP project and this document. the 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., is deprecated, and under active development within the IETF, i.e., is deprecated, and
must not be used for MPLS-TP. In general, all RSVP-TE extensions must not be used for MPLS-TP. In general, all RSVP-TE extensions
that apply to MPLS may also be used for GMPLS and consequently MPLS- that apply to MPLS may also be used for GMPLS and consequently MPLS-
TP. Most notably this includes support for P2MP signaling as defined TP. Most notably this includes support for P2MP signaling as defined
in [RFC4875]. 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
skipping to change at page 26, line 10 skipping to change at page 26, line 10
advertise the TE links that the LSP traverses. advertise the TE links that the LSP traverses.
As observed in [RFC4206] the nodes at the ends of an FA would not As observed in [RFC4206] the nodes at the ends of an FA would not
usually have a routing adjacency. usually have a routing adjacency.
4.1.9. LSP Recovery 4.1.9. LSP Recovery
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. The former can be viewed as a special case of segment recovery. End-to-end recovery can be viewed as a special case of
recovery where there is a single recovery domain whose borders segment recovery where there is a single recovery domain whose
coincide with the ingress and egress of the LSP, although specific borders coincide with the ingress and egress of the LSP, although
procedures are defined. specific procedures are defined.
The five defined types of recovery defined in MPLS-TP are: The five defined types of recovery defined in MPLS-TP 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 is signaled using the mechanism defined in Recovery for MPLS-TP LSPs is signaled using the mechanism defined in
[RFC4872] and [RFC4873]. Note that when MEPs are required for the [RFC4872] and [RFC4873]. Note that when MEPs are required for the
OAM CC function each MEP (other than the ones co-resident with the OAM CC function and the MEPs exists at LSP transit nodes, each MEP is
ingress and egress) are instantiated via a hierarchical LSP and instantiated at a hierarchical LSP end point, and protection is
protection is always end-to-end. (Which can be signaled using either provided end-to-end for the hierarchical LSP. (Protection can be
[RFC4872] and [RFC4873] defined procedures.) The use of Notify signaled using either [RFC4872] and [RFC4873] defined procedures.)
messages to trigger protection switching and recovery is not required The use of Notify messages to trigger protection switching and
in MPLS-TP as this function is expected to be supported via OAM. recovery is not required in MPLS-TP as this function is expected to
However, it's use is not precluded. be supported via OAM. However, it's 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)
The majority of GMPLS control plane related RFCs define the control The majority of GMPLS control plane related RFCs define the control
plane from the context of an internal network-to-network interface plane from the context of an internal network-to-network interface
(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
[GMPLS-ASON] 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) Configuration and Control 4.2. OAM, MEP (Hierarchy) Configuration and Control
MPLS-TP is being defined to support a comprehensive set of MPLS-TP MPLS-TP is being defined to support a comprehensive set of MPLS-TP
OAM functions. Specific OAM requirements for MPLS-TP are documented OAM functions. Specific OAM requirements for MPLS-TP are documented
in [TP-OAM-REQ]. In addition to the actual OAM requirements, it is in [RFC5860]. In addition to the actual OAM requirements, it is also
also required that the control plane be able to configure and control required that the control plane be able to configure and control OAM
OAM entities. This requirement is not yet addressed by the existing entities. This requirement is not yet addressed by the existing RFCs,
RFCs, but such work is now underway, e.g., [CCAMP-OAM-FWK] and but such work is now underway, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-
[CCAMP-OAM-EXT]. EXT].
Many OAM functions occur on a per-LSP, and even in-band, basis and Many OAM functions occur on a per-LSP basis, are typically in-band,
are initiated immediately after LSP establishment. Hence, it is and are initiated immediately after LSP establishment. Hence, it is
desirable that OAM is setup together with the establishment of the desirable that OAM is setup together with the establishment of the
data path (i.e., with the same signaling). This way OAM setup is data path (i.e., with the same signaling). This way OAM setup is
bound to connection establishment signaling, avoiding two separate bound to connection establishment signaling, avoiding two separate
management/configuration steps (connection setup followed by OAM management/configuration steps (connection setup followed by OAM
configuration) which would increases delay, processing and more configuration) which would increases delay, processing and more
importantly may be prune to mis-configuration errors. importantly may be prune to misconfiguration errors.
It must be noted that although the control plane is used to establish It must be noted that although the control plane is used to establish
OAM maintenance entities, OAM messaging and functions occur OAM maintenance entities, OAM messaging and functions occur
independently from the control plane. That is, in MPLS-TP OAM independently from the control plane. That is, in MPLS-TP OAM
mechanisms are responsible for monitoring and initiating recovery mechanisms are responsible for monitoring and initiating recovery
actions (driving switches between primary and backup paths). actions (driving switches between primary and backup paths).
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
skipping to change at page 28, line 17 skipping to change at page 28, line 17
must be possible for the control plane to notify, in a reliable must be possible for the control plane to notify, in a reliable
manner, the management plane about the status/result of either manner, the management plane about the status/result of either
synchronous or asynchronous, with respect to the management plane, synchronous or asynchronous, with respect to the management plane,
operation performed. Moreover it must be possible to monitor, via operation performed. Moreover it must be possible to monitor, via
query or spontaneous notify, the status of the control plane object query or spontaneous notify, the status of the control plane object
such as the TE Link status, the available resources, etc. A mechanism such as the TE Link status, the available resources, etc. A mechanism
must be made available by the control plane to the management plane must be made available by the control plane to the management plane
to log control plane LSP related operation, that is, it must be to log control plane LSP related operation, that is, it must be
possible from the NMS to have a clear view of the life, (traffic hit, possible from the NMS to have a clear view of the life, (traffic hit,
action performed, signaling etc.) of a given LSP. The LSP handover action performed, signaling etc.) of a given LSP. The LSP handover
procedure for MPLS-TP LSPs is supported via [PC-SCP]. procedure for MPLS-TP LSPs is supported 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 existing the GMPLS control plane (which builds on can be met using existing the GMPLS control plane (which builds on
top of the MPLS control plane). Areas where additional top of the MPLS control plane). Areas where additional
specifications are required are also identified. The table lists specifications are required are also identified. The table lists
references based on the control plane requirements as identified and references based on the control plane requirements as identified and
numbered above in section 2. numbered above in section 2.
+=======+===========================================================+ +=======+===========================================================+
| Req # | References | | Req # | References |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs | | 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 3 | [RFC5145] + Formal Definition (See Section 4.4.1) | | 3 | [RFC5145] + Formal Definition (See Section 4.4.1) |
| 4 | [Generic requirement met by using Standards Track RFCs] | | 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 6 | [RFC3471], [RFC3473], [RFC4875] | | 6 | [RFC3471], [RFC3473], [RFC4875] |
| 7 | [RFC3471], [RFC3473] + | | 7 | [RFC3471], [RFC3473] + |
| | Associated bidirectional LSPs (See Section 4.4.2) | | | Associated bidirectional LSPs (See Section 4.4.2) |
| 8 | [RFC4875] | | 8 | [RFC4875] |
| 9 | [RFC3473] | | 9 | [RFC3473] |
| 10 | Associated bidirectional LSPs (See Section 4.4.2) | | 10 | Associated bidirectional LSPs (See Section 4.4.2) |
| 11 | Associated bidirectional LSPs (See Section 4.4.2) | | 11 | Associated bidirectional LSPs (See Section 4.4.2) |
| 12 | [RFC3473] | | 12 | [RFC3473] |
| 13 | [RFC5467] (Currently Experimental, See Section 4.4.3) | | 13 | [RFC5467] (Currently Experimental, See Section 4.4.3) |
skipping to change at page 29, line 16 skipping to change at page 29, line 16
| 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] | | | [HIERARCHY-BIS] |
| 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], [GMPLS-ASON], [GMPLS-MLN] | | 32 | [RFC4208], [RFC4974], [RFC5787], [GMPLS-MLN] |
| 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 | [RFC3945], [RFC4202], [RFC5718] | | 38 | [RFC3945], [RFC4202], [RFC5718] |
| 39 | [RFC4139], [RFC4258], [GMPLS-ASON] | | 39 | [RFC4139], [RFC4258], [RFC5787] |
| 40 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 40 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 41 | [RFC3473], [RFC5063] | | 41 | [RFC3473], [RFC5063] |
| 42 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] | | 42 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] |
| 43 | [RFC3945], [RFC3471], [RFC4202] | | 43 | [RFC3945], [RFC3471], [RFC4202] |
| 44 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 44 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 45 | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 45 | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 46 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 46 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 47 | [PC-SCP] | | 47 | [RFC5493] |
| 48 | [RFC4872], [RFC4873] | | 48 | [RFC4872], [RFC4873] |
| 49 | [RFC3945], [RFC3471], [RFC4202] | | 49 | [RFC3945], [RFC3471], [RFC4202] |
| 50 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | | 50 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 51 | [RFC4872], [RFC4873] | | 51 | [RFC4872], [RFC4873] |
| 52 | [RFC4872], [RFC4873] + proper vendor implementation | | 52 | [RFC4872], [RFC4873] + proper vendor implementation |
| 53 | [RFC4872], [RFC4873], [GMPLS-PS] | | 53 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 54 | [RFC4872], [RFC4873] | | 54 | [RFC4872], [RFC4873] |
| 55 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] | | 55 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] |
| | Timers are a local implementation matter | | | Timers are a local implementation matter |
| 56 | [RFC4872], [RFC4873, [GMPLS-PS] + | | 56 | [RFC4872], [RFC4873, [GMPLS-PS] + |
skipping to change at page 30, line 17 skipping to change at page 30, line 17
| 72 | [RFC3473], [RFC4872] | | 72 | [RFC3473], [RFC4872] |
| 73 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 73 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 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] |
| 79 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation | | 79 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation |
| 80 | [RFC4426], [RFC4872], [RFC4873] | | 80 | [RFC4426], [RFC4872], [RFC4873] |
| 81 | [RFC4426], [RFC4872], [RFC4873] | | 81 | [RFC4426], [RFC4872], [RFC4873] |
| 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] + Testing control (See Sec. 4.4.5) |
| 86 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 86 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 87 | [RFC4872], [RFC4873] | | 87 | [RFC4872], [RFC4873] |
| 88 | [RFC4872], [RFC4873] | | 88 | [RFC4872], [RFC4873] |
| 89 | [RFC4872], [RFC4873], [TP-RING] | | 89 | [RFC4872], [RFC4873], [TP-RING] |
| 90 | [RFC4872], [RFC4873], [TP-RING] | | 90 | [RFC4872], [RFC4873], [TP-RING] |
| 91 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | | 91 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 92 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 92 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 93 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] | | 93 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] |
| 94 | Generic requirement on data plane (correct implementation)| | 94 | Generic requirement on data plane (correct implementation)|
| 95 | [RFC3473], [NO-PHP] | | 95 | [RFC3473], [NO-PHP] |
| 96 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | | 96 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 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 | PW only requirement, see PW Requirements Table (5.2) |
| 99 | [RFC3945], [RFC3473], [HIERARCHY-BIS] | | 99 | [RFC3945], [RFC3473], [HIERARCHY-BIS] |
| 100 | [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) | | 101 | PW only requirement, see PW Requirements Table (5.2) |
| 102 | (Requirement removed.) | | 102 | (Requirement intentionally blank.) |
| 103 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 103 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 104 | [RFC4872], [RFC4873], [TP-RING] | | 104 | [RFC4872], [RFC4873], [TP-RING] |
| 105 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 105 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 106 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 106 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 109 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 109 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 110 | [RFC3473], [RFC4872], [RFC4873] | | 110 | [RFC3473], [RFC4872], [RFC4873] |
| 111 | [RFC3473], [RFC4872], [RFC4873] | | 111 | [RFC3473], [RFC4872], [RFC4873] |
| 112 | [RFC3473], [RFC4783] | | 112 | [RFC3473], [RFC4783] |
skipping to change at page 31, line 36 skipping to change at page 31, line 37
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. aware of the association of the LSPs used to support the service.
GMPLS calls, [RFC4974], may serve as the foundation for this support. There are several existing protocol mechanisms on which to base such
support, including, but not limited to:
o GMPLS calls, [RFC4974].
o The ASSOCIATION object, [RFC4872].
o The LSP_TUNNEL_INTERFACE_ID object, [HIERARCHY-BIS].
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 MPLS-TP RFC is currently an Experimental RFC. To fully satisfy 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
skipping to change at page 32, line 33 skipping to change at page 32, line 41
check (CC), connectivity verification (CV), packet loss and delay check (CC), connectivity verification (CV), packet loss and delay
quantification, and diagnostic testing of a service. As OAM quantification, and diagnostic testing of a service. As OAM
configuration is directly linked to data plane OAM, it is expected configuration is directly linked to data plane OAM, it is expected
that [CCAMP-OAM-EXT] will evolve in parallel with the specification that [CCAMP-OAM-EXT] will evolve in parallel with the specification
of data plane OAM functions. of data plane OAM functions.
4.4.6. DiffServ Object usage in GMPLS 4.4.6. DiffServ Object usage in GMPLS
[RFC3270] and [RFC4124] defines support for DiffServ enabled MPLS [RFC3270] and [RFC4124] defines support for DiffServ enabled MPLS
LSPs. While the document references GMPLS signaling, there is no LSPs. While the document references GMPLS signaling, there is no
explicit discussion of discussion on the use of the DiffServ related explicit discussion on the use of the DiffServ related objects in
objects in GMPLS signaling. A (possibly Information) document on how GMPLS signaling. A (possibly Information) document on how GMPLS
GMPLS supports DiffServ LSPs is likely to prove useful in the context supports DiffServ LSPs is likely to prove useful in the context of
of MPLS-TP. MPLS-TP.
5. Pseudowires 5. Pseudowires
5.1. LDP Functions and Pseudowires 5.1. LDP Functions and Pseudowires
MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for
emulated services over an MPLS Packet Switched Network (PSN). emulated services over an MPLS Packet Switched Network (PSN).
Several types of PWs have been defined: (1) Ethernet PWs providing Several types of PWs have been defined: (1) Ethernet PWs providing
for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2) for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2)
HDLC/PPP PW providing for HDLC/PPP leased line transport over HDLC/PPP PW providing for HDLC/PPP leased line transport over
skipping to change at page 33, line 10 skipping to change at page 33, line 26
Today's transport networks based on PDH, WDM, or SONET/SDH provide Today's transport networks based on PDH, WDM, or SONET/SDH provide
transport for PDH or SONET (e.g., ATM over SONET or Packet PPP over transport for PDH or SONET (e.g., ATM over SONET or Packet PPP over
SONET) client signals with no payload awareness. Implementing PW SONET) client signals with no payload awareness. Implementing PW
capability allows for the use of an existing technology to substitute capability allows for the use of an existing technology to substitute
the TDM transport with packet based transport, using well-defined PW the TDM transport with packet based transport, using well-defined PW
encapsulation methods for carrying various packet services over MPLS, encapsulation methods for carrying various packet services over MPLS,
and providing for potentially better bandwidth utilization. and providing for potentially better bandwidth utilization.
There are two general classes of PWs: (1) Single-Segment Pseudowires There are two general classes of PWs: (1) Single-Segment Pseudowires
(SS-PW), and (2) Multi-segment Pseudowires (MS-PW) [SEGMENTED-PW]. (SS-PW) [RFC3985], and (2) Multi-segment Pseudowires (MS-PW)
An MPLS-TP domain may transparently transport a PW whose endpoints [RFC5659]. An MPLS-TP domain may transparently transport a PW whose
are within a client network. Alternatively, an MPLS-TP edge node may endpoints are within a client network. Alternatively, an MPLS-TP
be the Terminating PE (T-PE) for a PW, performing adaptation from the edge node may be the Terminating PE (T-PE) for a PW, performing
native attachment circuit technology (e.g. Ethernet 802.1q) to an adaptation from the native attachment circuit technology (e.g.
MPLS PW for transport over an MPLS-TP domain, with a GMPLS LSP or a Ethernet 802.1Q) to an MPLS PW which is then transported in an LSP
hierarchy of LSPs transporting the PW between the T-PEs. In this way, over an MPLS-TP domain. In this way, the PW is analogous to a
the PW is analogous to a transport channel in a TDM network and the transport channel in a TDM network and the LSP is equivalent to a
LSP is equivalent to a container of multiple non-concatenated container of multiple non-concatenated channels, albeit they are
channels, albeit they are packet containers. The MPLS-TP domain may packet containers. The MPLS-TP domain may also contain Switching PEs
also contain Switching PEs (S-PEs) for a multi-segment PW whereby the (S-PEs) for a multi-segment PW whereby the T-PEs may be at the edge
T-PEs may be at the edge of the MPLS-TP domain or in a client of the MPLS-TP domain or in a client network. In this latter case, a
network. In this latter case, a T-PE in a client network is a T-PE T-PE in a client network is a T-PE performing the adaptation of the
performing the adaptation of the native service to MPLS and the MPLS- native service to MPLS and the MPLS-TP domain performs Pseudo-wire
TP domain performs Pseudo-wire switching. switching.
SS-PW signaling control plane is based on LDP with specific SS-PW signaling control plane is based on LDP with specific
procedures defined in [RFC4447]. [RFC5659], [SEGMENTED-PW] and [MS- procedures defined in [RFC4447]. [RFC5659], [SEGMENTED-PW] and [MS-
PW-DYNAMIC] allow for static switching of multi-segment Pseudowires PW-DYNAMIC] allow for static switching of multi-segment Pseudowires
in data and control plane and for dynamic routing and placement of an in data and control plane and for dynamic routing and placement of an
MS-PW whereby signaling is still based on Targeted LDP (T-LDP). The MS-PW whereby signaling is still based on Targeted LDP (T-LDP). The
MPLS-TP domain shall use the same PW signaling protocols and MPLS-TP domain shall use the same PW signaling protocols and
procedures for placing SS-PWs and MS-PWs. This will leverage existing procedures for placing SS-PWs and MS-PWs. This will leverage existing
technology as well as facilitate interoperability with client technology as well as facilitate interoperability with client
networks with native attachment circuits or PW segment that is networks with native attachment circuits or PW segment that is
switched across the MPLS-TP domain. switched across the MPLS-TP domain.
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 existing the 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.
Requirements with no specific relevance to pseudowire control, are In the table below, several of the requirements shown are addressed -
already included in the GMPLS and MPLS-TP Requirements Table (section in part or in full - by the use of MPLS-TP LSPs to carry pseudo-
4.3), and are omitted from this table. wires. This is reflected by including "TP-LSPs" as a reference for
those requirements. Section 5.3.2 provides additional context for
the binding of PWs to TP-LSPs.
+=======+===========================================================+ +=======+===========================================================+
| Req # | References | | Req # | References |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 3 | [RFC3985], [RFC4447], [RFC5317] | | 1 | Generic requirement met by using Standards Track RFCs |
| 4 | [Generic requirement met by using Standards Track RFCs] | | 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) |
| 3 | [RFC3985], [RFC4447] |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3985], [RFC4447], Together with TP-LSPs |
| 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs |
| 7 | [RFC3985], [RFC4447], + TP-LSPs |
| 8 | [PW-P2MPR], [PW-P2MPE] |
| 9 | [RFC3985], end-node only involvement for PW |
| 10 | [RFC3985], proper vendor implementation |
| 11 | [RFC3985], end-node only involvement for PW |
| 12-13 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 14 | [RFC3985], [RFC4447] |
| 15 | [RFC4447], [RFC3478], proper vendor implementation |
| 16 | [RFC3985], [RFC4447] |
| 17-18 | [RFC3985], proper vendor 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] |
| 29-31 | [RFC3985], [RFC4447] |
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6. |
| 33 | [RFC4385], [RFC4447], [RFC5586] | | 33 | [RFC4385], [RFC4447], [RFC5586] |
| 34 | [PW-P2MPR], [PW-P2MPE] |
| 35 | [RFC4863] | | 35 | [RFC4863] |
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 38 | [RFC5586] |
| 39 | Provided by TP-LSPs |
| 40 | [RFC3985], [RFC4447], + TP-LSPs |
| 41 | [RFC3478] | | 41 | [RFC3478] |
| 43 | [RFC3985], [RFC4447] | | 42-43 | [RFC3985], [RFC4447] |
| 44-45 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 |
| 46 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs |
| 47 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 |
| 48 | [PW-RED], [PW-REDB] | | 48 | [PW-RED], [PW-REDB] |
| 49-50 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 51-53 | Provided by TP-LSPs, and Section 5.3.5 |
| 54-56 | [RFC3985], [RFC4447], See Section 5.3.5 |
| 57 | [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 | [PW-RED], [PW-REDB] | | 58-59 | [PW-RED], [PW-REDB] |
| 59 | [PW-RED], [PW-REDB] | | 60-82 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 72 | [PW-RED], [PW-REDB] | | 83-84 | [RFC5085], [RFC5586], [RFC5885] |
| | recovery triggering is a local matter for PW | | 85-90 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 83 | [RFC5085], [RFC5586], [VCCV-BFD] | | 91-96 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 84 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 97 | [RFC4447], [MS-PW-DYNAMIC] | | 97 | [RFC4447], [MS-PW-DYNAMIC] |
| 98 | [RFC4447] | | 98 | [RFC4447] |
| 99 - | |
| 100 | Not Applicable to PW |
| 101 | [RFC4447] | | 101 | [RFC4447] |
| 105 | TBD | | 102 | (Requirement intentionally blank.) |
| 106 | TBD | | 103 | [RFC3478] |
| 107 | [RFC5085], [RFC5586], [VCCV-BFD] | | 104 | [RFC3985], + TP-LSPs |
| 108 | [RFC5085], [RFC5586], [VCCV-BFD] | | 105 | [PW-OAM] |
| 109 | [RFC5085], [RFC5586], [VCCV-BFD] | | 106 | [PW-OAM] |
| 110 | [RFC5085], [RFC5586], [VCCV-BFD] | | 107 - | |
| 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], [VCCV-BFD] | | 111 | [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] | | 112 | [RFC4447] |
| 113 | [RFC4447], [RFC5085], [RFC5586], [VCCV-BFD] | | 113 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] |
| 114 | [RFC5085], [RFC5586], [VCCV-BFD] | | 114 | [RFC5085], [RFC5586], [RFC5885] |
| 115 | [RFC5085], [RFC5586], [VCCV-BFD] | | 115 | [RFC5085], [RFC5586], [RFC5885] |
| 116 | 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 | | 117 | [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], [VCCV-BFD] | | 118 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] |
| 121 | [RFC5085], [RFC5586], [VCCV-BFD] | | 119 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 122 | [RFC5085], [RFC5586], [VCCV-BFD] | | 120 | [RFC4447] |
| 123 | [RFC5085], [RFC5586], [VCCV-BFD] | | 121 - | |
| 124 | [RFC5085], [RFC5586], [VCCV-BFD] | | 126 | [RFC5085], [RFC5586], [RFC5885] |
| 125 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 126 | [RFC5085], [RFC5586], [VCCV-BFD] |
+=======+===========================================================+ +=======+===========================================================+
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 The same control protocol and procedures will be reused as much as
possible. However, when using PWs in MPLS-TP, a set of new possible. However, when using PWs in MPLS-TP, a set of new
requirements are defined which may require extensions of the existing requirements are defined which may require extensions of the existing
control mechanisms. This section clarifies the areas where extensions control mechanisms. This section clarifies the areas where extensions
are needed based on the PW Control Plane related requirements are needed based on the PW Control Plane related requirements
documented in [RFC5654]. documented in [RFC5654].
See the table in the section above for a list of how requirements See the table in the section above for a list of how requirements
defined in [RFC5654] are expected to be addressed. defined in [RFC5654] are expected to 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], [SEGMENTED-PW] and [MS-PW-DYNAMIC].
For MPLS-TP, it is required that the data and control planes are both 5.3.1. Extensions to Support Out-of-Band PW Control
logically and physically separated. That is, the PW Control Plane
must be able to operate out-of-band (OOB). This separation ensures For MPLS-TP, it is required that the data and control planes can be
that in the case of control plane failures the data plane is not both logically and physically separated. That is, the PW Control
affected and can continue to operate normally. This was not a design Plane must be able to operate out-of-band (OOB). This separation
requirement for the current PW Control Plane. However, due to the PW ensures, among other things, that in the case of control plane
concept, i.e., PWs are connecting logical entities ('forwarders'), failures the data plane is not affected and can continue to operate
and the operation of the PW control protocol, i.e., only edge PE normally. This was not a design requirement for the current PW
nodes (T-PE, S-PE) take part in the signaling exchanges: moving T-LDP Control Plane. However, due to the PW concept, i.e., PWs are
out-of-band seems to be, theoretically, a straightforward exercise. connecting logical entities ('forwarders'), and the operation of the
PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part
in the signaling exchanges: moving T-LDP out-of-band seems to be,
theoretically, a straightforward exercise.
In fact, as a strictly local matter, ensuring that Targeted LDP (T- In fact, as a strictly local matter, ensuring that Targeted LDP (T-
LDP) uses out-of-band signaling requires only that the local LDP) uses out-of-band signaling requires only that the local
implementation is configured in such a way that reachability for a implementation is configured in such a way that reachability for a
target LSR address is via the out-of-band channel. target LSR address is via the out-of-band channel.
More precisely, if IP addressing is used in the MPLS-TP control plane More precisely, if IP addressing is used in the MPLS-TP control plane
then T-LDP addressing can be maintained, although all addresses will then T-LDP addressing can be maintained, although all addresses will
refer to control plane entities. Both, the PWid FEC and Generalized refer to control plane entities. Both, the PWid FEC and Generalized
PWid FEC Elements can possibly be used in an OOB case as well PWid FEC Elements can possibly be used in an OOB case as well.
(Detailed evaluation is FFS). The PW Label allocation and exchange (Detailed evaluation is outside the scope of this document). The PW
mechanisms should be reused without change. Label allocation and exchange mechanisms should be reused without
change.
5.3.2. Support for Explicit Control of PW-to-LSP Binding
Binding a PW to an LSP, or PW segments to LSPs is left to networks Binding a PW to an LSP, or PW segments to LSPs is left to networks
elements acting as T-PEs and S-PEs or a control plane entity that may elements 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 be the same one signaling the PW. However, an extension of the PW
signaling protocol is required to allow the LSR at signal initiation signaling protocol is required to allow the LSR at signal initiation
end to inform the targeted LSR (at the signal termination end) which end to 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 LSP the 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 one such LSP exists and the choice of LSPs is important to the
service being setup (for example, if the service requires co-routed service being setup (for example, if the service requires co-routed
bi-directional paths). bidirectional paths). This is also particularly important to support
transport path (symmetric and asymmetric) bandwidth requirements.
If the control plane is physically separated from the forwarder, the If the control plane is physically separated from the forwarder, the
control plane must be able to program the forwarders with necessary control plane must be able to program the forwarders with necessary
information. information.
For transport servics, it may be mandatory that bidirectional traffic For transport services, it may be required that bidirectional traffic
follows congruent paths. Currently, each direction of a PW or a PW follows congruent paths. Currently, each direction of a PW or a PW
segment is bound to a unidirectional LSP that extends between two T- 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 LSPs in both PEs, S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in both
directions are not required to follow congruent paths, and therefore directions are not required to follow congruent paths, and therefore
both directions of a PW may not follow congruent paths. The only both directions of a PW may not follow congruent paths, i.e., they
current requirement is that a PW or a PW segment shares the same T- are associated bidirectional paths. The only requirement in [RFC5659]
PEs in both directions, and same S-PEs in both directions. 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 ends map the PW to the same transport path for requiring that PW or PW segment both end points map the PW or PW
the case where this is an objective of the service. When a segment to the same transport path for the case where this is an
bidirectional LSP is selected on one end to transport the PW, a objective of the service. When a bidirectional LSP is selected on
mechanism is needed that signals to the remote end which LSP has been one end to transport the PW, a mechanism is needed that signals to
selected locally to transport the PW. This would be accomplished by the remote end which LSP has been selected locally to transport the
adding a new TLV to PW signaling. PW. This 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
new mechanism is needed to allow explicit binding of a PW to the new mechanism is needed to allow explicit binding of a PW to the
supporting transport LSP. supporting transport LSP.
Alternatively, two unidirectional LSPs may be used to support the PW. The case of unidirectional transport paths may also require
However, to meet the congruency requirement, the LSPs must be placed additional protocol mechanisms as today's PWs are always
so that they are forced to follow the same path (switches and links). bidirectional. One potential approach for providing a unidirectional
This may be accomplished by placing one unidirectional TE-LSP in one PW based transport path is for the PW to associate different
direction at one endpoint, and forcing the other endpoint to setup a (asymmetric) bandwidths in each direction, with a zero or minimal
TE-LSP with an ERO that has the nodes/links in the reverse order from bandwidth for the return path.
the RRO seen in the path message of the LSP in the reverse direction.
In this case, when one endpoint selects an LSP to bind the PW to, it 5.3.3. Support for Dynamic Transfer of PW Control/Ownership
must identify to the remote end which LSP to bind the other direction
of the PW to. In order to satisfy requirement 47 (as defined in section 2) it will
be necessary to specify methods for transfer of PW ownership from the
management to the control plane (and vice versa).
5.3.4. Interoperable Support for PW/LSP Resource Allocation
Transport applications may require resource guarantees. For such Transport applications may require resource guarantees. For such
transport LSPs, resource reservation mechanisms are provided via transport LSPs, resource reservation mechanisms are provided via
RSVP-TE and the use of DiffServ. If multiple PWs are multiplexed into RSVP-TE and the use of DiffServ. If multiple PWs are multiplexed into
the same transport LSP resources, contention may occur. However, the same transport LSP resources, contention may occur. However,
local policy at PEs should ensure proper resource sharing among PWs local policy at PEs should ensure proper resource sharing among PWs
mapped into a resource guaranteed LSP. In the case of MS-PWs, mapped into a resource guaranteed LSP. In the case of MS-PWs,
signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable
admission control of a PW segment over a resource-guaranteed LSP. admission control of a PW segment over a resource-guaranteed LSP.
In conjunction with explicit PW-to-LSP binding, existing mechanisms
may be sufficient, however this needs to be verified in detailed
evaluation.
5.3.5. Support for PW Protection and PW OAM Configuration
The PW control plane must be able to establish and configure all of The PW control plane must be able to establish and configure all of
the available features manageable for the PW, including protection the available features manageable for the PW, including protection
and OAM entities and mechanisms. There is ongoing work on PW and OAM entities and mechanisms. There is ongoing work on PW
protection and MPLS-TP OAM. protection and MPLS-TP OAM.
To summarize, the main areas identified for potential PW Control 5.3.6. Client Layer Interfaces to Pseudowire Control
Plane extensions to support MPLS-TP are the following.
o Provide necessary extensions to support out-of-band PW Control.
o Provide mechanisms to allow explicit control of PW to LSP binding
o Verify that existing mechanisms allow necessary interoperable
support for PW/LSP resource allocation.
o Provide necessary extensions to support PW protection.
o Define necessary mechanisms/extensions for PW OAM configuration Additional work is likely to be required to define consistent access
and control. by a client layer network to control information available to the
client layer network, for example, 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 avoid establishment of fate-sharing
alternate paths.
5.4. Pseudowire OAM and Recovery (Redundancy) 5.4. Pseudowire OAM and Recovery (Redundancy)
Many of the requirements listed in section 2 are intended to support Many of the requirements listed in section 2 are intended to support
connectivity and performance monitoring (grouped together as OAM) and connectivity and performance monitoring (grouped together as OAM) and
protection conformant with the transport services model. protection conformant with the transport services model.
In general, protection of MPLS-TP transported services is provided by In general, protection of MPLS-TP transported services is provided by
way of protection of transport LSPs. PW protection requires that way of protection of transport LSPs. PW protection requires that
mechanisms be defined to support redundant pseudowires, including a mechanisms be defined to support redundant Pseudowires, including a
mechanism already described above for associating such pseudowires mechanism already described above for associating such Pseudowires
with specific protected ("working" and "protection") LSPs. Also with specific protected ("working" and "protection") LSPs. Also
required are definitions of local protection control functions, to required are definitions of local protection control functions, to
include test/verification operations, and protection status signals include test/verification operations, and protection status signals
needed to ensure that PW termination points are in agreement as to needed to ensure that PW termination points are in agreement as to
which of a set of redundant pseudowires are in use for which which of a set of redundant Pseudowires are in use for which
transport services at any given point in time. transport services at any given point in time.
Much of this work is currently being done in drafts [PW-RED] and [PW- Much of this work is currently being done in drafts [PW-RED] and [PW-
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 in [VCCV-BFD] and elsewhere). mechanisms yet to be defined).
Automated protection switching is but one of the functions that a Automated protection switching is but one of the functions that a
transport service requries OAM for. OAM is generally classed as transport service requires OAM for. 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
bi-directional forwarding detection (BFD) in [VCCV-BFD], 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.
6. Security Considerations 6. Security Considerations
This document primarily describes how exiting mechanisms can be used This document primarily describes how exiting 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 [MPLS-SEC]. security issues, see the MPLS/GMPLS security framework [MPLS-SEC].
skipping to change at page 41, line 19 skipping to change at page 43, line 19
[RFC5654] Niven-Jenkins, B., et al, "Requirements of an MPLS [RFC5654] Niven-Jenkins, B., et al, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009. Transport Profile", RFC 5654, September 2009.
[RFC5467] Berger, L., et al, "GMPLS Asymmetric Bandwidth [RFC5467] Berger, L., et al, "GMPLS Asymmetric Bandwidth
Bidirectional Label Switched Paths (LSPs)", RFC 5467, March Bidirectional Label Switched Paths (LSPs)", RFC 5467, March
2009. 2009.
[RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC [RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC
5586, June 2009. 5586, June 2009.
[RFC5860] Vigoureux, M., Ward, D., Betts, M.,
"Requirements for Operations, Administration, and
Maintenance
(OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[TP-DATA] Frost, D., Bryant, S., Bocci, M.,
"MPLS Transport Profile Data Plane Architecture", work in
progress, draft-ietf-mpls-tp-data-plane.
[TP-FWK] Bocci, M., Ed., et al, "A Framework for MPLS in [TP-FWK] Bocci, M., Ed., et al, "A Framework for MPLS in
Transport Networks", work in progress, Transport Networks", work in progress,
draft-ietf-mpls-tp-framework. draft-ietf-mpls-tp-framework.
[TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM [TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM
Framework and Overview", work in progress, Framework and Overview", work in progress,
draft-ietf-mpls-tp-oam-framework. draft-ietf-mpls-tp-oam-framework.
[TP-OAM-REQ] Vigoureux, M., Ward, D, and Betts, M., "Requirements for
OAM in MPLS Transport Networks", work in progress,
draft-ietf-mpls-tp-oam-requirements.
[TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label
Switching Transport Profile Survivability Switching Transport Profile Survivability
Framework", work in progress, Framework", work in progress,
draft-ietf-mpls-tp-survive-fwk. draft-ietf-mpls-tp-survive-fwk.
9.2. Informative References 9.2. Informative References
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration
"BFD For MPLS LSPs", work in progress, Framework and Requirements for GMPLS RSVP-TE", work
draft-ietf-bfd-mpls. in progress, draft-ietf-ccamp-oam-configuration-fwk.
[GMPLS-ASON] Papadimitriou, D., "OSPFv2 Routing Protocols [CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for
Extensions for ASON Routing", work in progress, MPLS-TP OAM Configuration", work in progress,
draft-ietf-ccamp-gmpls-ason-routing-ospf. draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext.
[GMPLS-MLN] Papadimitriou, D., et al, "Generalized Multi-Protocol [GMPLS-MLN] 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)", work Multi-Layer and Multi-Region Networks (MLN/MRN)", work
in progress, draft-ietf-ccamp-gmpls-mln-extensions. in progress, draft-ietf-ccamp-gmpls-mln-extensions.
[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.
[TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for
Point-to-Multipoint MPLS in Transport Networks",
draft-fbb-mpls-tp-p2mp-framework.
[RFC4655] A. Farrel, J.-P. Vasseur, and J. Ash, "A Path
Computation Element (PCE) -Based Architecture", RFC4655,
August 2006.
[RFC5440] JP. Vasseur and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC5440, March
2009.
[RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC4875, May 2007.
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC3477, January 2003.
[RFC4201] K. Kompella and Y. Rekhter "Link Bundling in MPLS
Traffic Engineering (TE)", RFC4201, October 2005.
[RFC5145] K. Shiomoto, "Framework for MPLS-TE to GMPLS Migration"
RFC5145, March 2008.
[CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration
Framework and Requirements for GMPLS RSVP-TE", work
in progress, draft-ietf-ccamp-oam-configuration-fwk.
[CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for
MPLS-TP OAM Configuration", work in progress,
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext.
[HIERARCHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for [HIERARCHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched Dynamically Signaled Hierarchical Label Switched
Paths", work in progress, Paths", work in progress,
draft-ietf-ccamp-lsp-hierarchy-bis. 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
skipping to change at page 43, line 27 skipping to change at page 44, line 46
Recommendation G.8080 Amendment 1, March 2008. Recommendation G.8080 Amendment 1, March 2008.
[MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and [MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and
GMPLS Networks", work in progress, GMPLS Networks", work in progress,
draft-ietf-mpls-mpls-and-gmpls-security-framework. draft-ietf-mpls-mpls-and-gmpls-security-framework.
[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
[PC-SCP] Caviglia, D, et al, "RSVP-TE Signaling Extension For
The Conversion Between Permanent Connections And Soft
Permanent Connections In A GMPLS Enabled Transport
Network", work in progress,
draft-ietf-ccamp-pc-spc-rsvpte-ext.
[SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M., [SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M.,
"Segmented Pseaudowire", work in progress, "Segmented Pseaudowire", work in progress,
draft-ietf-pwe3-segmented-pw. draft-ietf-pwe3-segmented-pw.
[TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for
Point-to-Multipoint MPLS in Transport Networks",
draft-fbb-mpls-tp-p2mp-framework.
[RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label [RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[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
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful
Restart Mechanism for Label Distribution Protocol", RFC
3478, February 2003.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic "Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)", RFC Engineering (TE) Management Information Base (MIB)", RFC
3812, June 2004. 3812, June 2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching "Multiprotocol Label Switching (MPLS) Label Switching
(LSR) Router Management Information Base (MIB)", RFC (LSR) Router Management Information Base (MIB)", RFC
3813, June 2004. 3813, June 2004.
skipping to change at page 44, line 17 skipping to change at page 45, line 44
2004. 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge- [RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005. to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4139] Papadimitriou, D., et al, "Requirements for [RFC4139] Papadimitriou, D., et al, "Requirements for
Generalized MPLS (GMPLS) Signaling Usage and Generalized MPLS (GMPLS) Signaling Usage and
Extensions for Automatically Switched Optical Extensions for Automatically Switched Optical
Network (ASON)", RFC4139, July 2005. Network (ASON)", RFC4139, July 2005.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L.,
"Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201,
October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter,
Y., "Generalized Multi-Protocol Label Switching Y., "Generalized Multi-Protocol Label Switching
(GMPLS) User-Network Interface (UNI) : Resource (GMPLS) User-Network Interface (UNI) : Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) ReserVation Protocol-Traffic Engineering (RSVP-TE)
Support for the Overlay Model", RFC 4208, October Support for the Overlay Model", RFC 4208, October
2005. 2005.
[RFC4258] Brungard, D., et al, "Requirements for Generalized [RFC4258] Brungard, D., et al, "Requirements for Generalized
Multi-Protocol Label Switching (GMPLS) Routing for Multi-Protocol Label Switching (GMPLS) Routing for
the Automatically Switched Optical Network (ASON)", the Automatically Switched Optical Network (ASON)",
skipping to change at page 45, line 5 skipping to change at page 46, line 37
[RFC4618] Martini, L., Rosen, E., Heron, G., and Malis, A., [RFC4618] Martini, L., Rosen, E., Heron, G., and Malis, A.,
"Encapsulation Methods for Transport of PPP/High- "Encapsulation Methods for Transport of PPP/High-
Level Data Link Control (HDLC) over MPLS Networks", Level Data Link Control (HDLC) over MPLS Networks",
RFC 4618, September 2006. RFC 4618, September 2006.
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and Malis, A., Ed., [RFC4619] Martini, L., Ed., Kawa, C., Ed., and Malis, A., Ed.,
"Encapsulation Methods for Transport of Frame Relay "Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS) Networks", over Multiprotocol Label Switching (MPLS) Networks",
September 2006. September 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., Ash, J.,
"A Path Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[RFC4783] Berger, L.,Ed., "GMPLS - Communication of Alarm [RFC4783] Berger, L.,Ed., "GMPLS - Communication of Alarm
Information", RFC 4763, December 2006. Information", RFC 4763, December 2006.
[RFC4802] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol [RFC4802] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol
Label Switching (GMPLS) Traffic Engineering Management Label Switching (GMPLS) Traffic Engineering Management
Information Base", RFC 4802, February 2007. Information Base", RFC 4802, February 2007.
[RFC4803] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol [RFC4803] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol
Label Switching (GMPLS) Label Switching Router (LSR) Label Switching (GMPLS) Label Switching Router (LSR)
Management Information Base", RFC 4803, February 2007. Management Information Base", RFC 4803, February 2007.
[RFC4816] Malis, A., Martini, L., Brayley, J., and Walsh, T., [RFC4816] Malis, A., Martini, L., Brayley, J., and Walsh, T.,
"Pseudowire Emulation Edge-to-Edge (PWE3) "Pseudowire Emulation Edge-to-Edge (PWE3)
Asynchronous Transfer Mode (ATM) Transparent Cell Asynchronous Transfer Mode (ATM) Transparent Cell
Transport Service", RFC 4816, February 2007. Transport Service", RFC 4816, February 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S.,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual
Circuit Connectivity Verification (VCCV) : A Control Circuit Connectivity Verification (VCCV) : A Control
Channel for Pseudowires", RFC 5085, December 2007. Channel for Pseudowires", RFC 5085, December 2007.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) [RFC5145] Shiomoto, K.,
Report on MPLS Architectural Considerations for a "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March
Transport Profile", RFC 5317, February 2009. 2008.
[RFC5440] Vasseur, JP., Le, JL.,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
[RFC5493] Caviglia, D., et al, "Requirements for the [RFC5493] Caviglia, D., et al, "Requirements for the
Conversion between Permanent Connections and Conversion between Permanent Connections and
Switched Connections in a Generalized Multiprotocol Switched Connections in a Generalized Multiprotocol
Label Switching (GMPLS) Network", RFC 5493, April Label Switching (GMPLS) Network", RFC 5493, April
2009. 2009.
[RFC5659] Bocci, M., and Bryant, B., "An Architecture for [RFC5659] Bocci, M., and Bryant, B., "An Architecture for
Multi-Segment Pseudowire Emulation Edge-to-Edge", Multi-Segment Pseudowire Emulation Edge-to-Edge",
RFC 5659, October 2009. RFC 5659, October 2009.
[RFC5718] Bellar, D., Farrel, A., "An In-Band Data Communication [RFC5718] Bellar, D., Farrel, A., "An In-Band Data Communication
Network For the MPLS Transport Profile", RFC 5718, January Network For the MPLS Transport Profile", RFC 5718, January
2010. 2010.
[RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols
Extensions for ASON Routing", RFC 5787, March 2010.
[RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D.,
Bardalai, S., "RSVP-TE Signaling Extension for LSP
Handover from the Management Plane to the Control Plane
in a GMPLS-Enabled Transport Network", RFC 5852, April
2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) For MPLS
Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional
Forwarding Detection (BFD) for the Pseudowire
Virtual Circuit Connectivity Verification (VCCV)",
RFC 5885, June 2010.
[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, draft-ietf-pwe3-redundancy- definition", work in progress,
bit. draft-ietf-pwe3-redundancy-bit.
[PW-OAM] Zhang, F., et al, "LDP Extensions for MPLS-TP PW OAM
configuration", work in progress,
draft-zhang-mpls-tp-pw-oam-config.
[PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint
Pseudo-Wire Encapsulation", work in progress,
draft-raggarwa-pwe3-p2mp-pw-encaps.
[PW-P2MPR] Jounay, F., et al, "Requirements for
Point-to-Multipoint Pseudowire", work in progress,
draft-ietf-pwe3-p2mp-pw-requirements.
[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.
[VCCV-BFD] Nadeau, T. and C. Pignataro, "Bidirectional
Forwarding Detection (BFD) for the Pseudowire
Virtual Circuit Connectivity Verification (VCCV)",
work in progress, draft-ietf-pwe3-vccv-bfd.
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 page 46, line 28 skipping to change at page 49, line 4
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Luyuan Fang (editor) Luyuan Fang (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: lufang@cisco.com Email: lufang@cisco.com
Nabil Bitar (editor) Nabil Bitar (editor)
Verizon, Verizon,
40 Sylvan Rd., 40 Sylvan Rd.,
Waltham, MA 02451 Waltham, MA 02451
Email: nabil.n.bitar@verizon.com Email: nabil.n.bitar@verizon.com
Attila Takacs Attila Takacs
Ericsson Ericsson
1. Laborc u. 1. Laborc u.
Budapest, HUNGARY 1037 Budapest, HUNGARY 1037
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
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
Eric Gray Eric Gray
Ericsson Ericsson
900 Chelmsford Street 900 Chelmsford Street
Lowell, MA, 01851 Lowell, MA, 01851
Phone: +1 978 275 7470 Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com Email: Eric.Gray@Ericsson.com
Generated on: Mon Mar 22 09:17:03 PDT 2010 Generated on: Thu Jun 17 19:11:25 EDT 2010
 End of changes. 133 change blocks. 
332 lines changed or deleted 408 lines changed or added

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