draft-ietf-ccamp-mpls-tp-cp-framework-02.txt   draft-ietf-ccamp-mpls-tp-cp-framework-03.txt 
Internet Draft Loa Andersson, Ed. (Ericsson) Internet Draft Loa Andersson, Ed. (Ericsson)
Category: Informational Lou Berger, Ed. (LabN) Category: Informational Lou Berger, Ed. (LabN)
Expiration Date: December 18, 2010 Luyuan Fang, Ed. (Cisco) Expiration Date: April 15, 2011 Luyuan Fang, Ed. (Cisco)
Nabil Bitar, Ed. (Verizon) Nabil Bitar, Ed. (Verizon)
Eric Gray, Ed. (Ericsson)
June 18, 2010 October 15, 2010
MPLS-TP Control Plane Framework MPLS-TP Control Plane Framework
draft-ietf-ccamp-mpls-tp-cp-framework-02.txt draft-ietf-ccamp-mpls-tp-cp-framework-03.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. MPLS-TP also uses
compatibility with MPLS. MPLS-TP also uses the control plane for the control plane for Pseudowires (PWs). Management plane
Pseudowires (PWs). Management plane functions such as manual functions such as manual configuration and the initiation of LSP
configuration and the initiation of LSP setup are out of scope of setup are out of scope of this document.
this document.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T.
This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF
Last Call.
[RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published
RFC has IETF consensus.]
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This 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 2, line 16
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 18, 2010 This Internet-Draft will expire on April 15, 2011
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 Scope .................................................. 4
1.2 Scope .................................................. 4 1.2 Basic Approach ......................................... 5
1.3 Basic Approach ......................................... 4 1.3 Reference Model ........................................ 6
1.4 Reference Model ........................................ 5 2 Control Plane Requirements ............................. 9
2 Control Plane Requirements ............................. 8 2.1 Primary Requirements ................................... 9
2.1 Primary Requirements ................................... 8 2.2 MPLS-TP Framework Derived Requirements ................. 18
2.2 MPLS-TP Framework Derived Requirements ................. 17 2.3 OAM Framework Derived Requirements ..................... 19
2.3 OAM Framework Derived Requirements ..................... 18 2.4 Security Requirements .................................. 24
2.4 Security Requirements .................................. 21 2.5 Identifier Requirements ................................ 24
3 Relationship of PWs and TE LSPs ........................ 21 3 Relationship of PWs and TE LSPs ........................ 25
4 TE LSPs ................................................ 22 4 TE LSPs ................................................ 26
4.1 GMPLS Functions and MPLS-TP LSPs ....................... 22 4.1 GMPLS Functions and MPLS-TP LSPs ....................... 26
4.1.1 In-Band and Out-Of-Band Control and Management ......... 22 4.1.1 In-Band and Out-Of-Band Control ........................ 26
4.1.2 Addressing ............................................. 23 4.1.2 Addressing ............................................. 27
4.1.3 Routing ................................................ 23 4.1.3 Routing ................................................ 28
4.1.4 TE LSPs and Constraint-Based Path Computation .......... 24 4.1.4 TE LSPs and Constraint-Based Path Computation .......... 28
4.1.5 Signaling .............................................. 24 4.1.5 Signaling .............................................. 29
4.1.6 Unnumbered Links ....................................... 25 4.1.6 Unnumbered Links ....................................... 29
4.1.7 Link Bundling .......................................... 25 4.1.7 Link Bundling .......................................... 29
4.1.8 Hierarchical LSPs ...................................... 25 4.1.8 Hierarchical LSPs ...................................... 29
4.1.9 LSP Recovery ........................................... 26 4.1.9 LSP Recovery ........................................... 30
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) ..... 31
4.2 OAM, MEP (Hierarchy) Configuration and Control ......... 26 4.2 OAM, MEP (Hierarchy), MIP Configuration and Control .... 31
4.2.1 Management Plane Support ............................... 27 4.2.1 Management Plane Support ............................... 31
4.3 GMPLS and MPLS-TP Requirements Table ................... 28 4.3 GMPLS and MPLS-TP Requirements Table ................... 32
4.4 Anticipated MPLS-TP Related Extensions and Definitions . 31 4.4 Anticipated MPLS-TP Related Extensions and Definitions . 36
4.4.1 MPLS to MPLS-TP Interworking ........................... 31 4.4.1 MPLS-TE to MPLS-TP LSP Control Plane Interworking ...... 36
4.4.2 Associated Bidirectional LSPs .......................... 31 4.4.2 Associated Bidirectional LSPs .......................... 36
4.4.3 Asymmetric Bandwidth LSPs .............................. 32 4.4.3 Asymmetric Bandwidth LSPs .............................. 36
4.4.4 Recovery for P2MP LSPs ................................. 32 4.4.4 Recovery for P2MP LSPs ................................. 37
4.4.5 Test Traffic Control and other OAM functions ........... 32 4.4.5 Test Traffic Control and other OAM functions ........... 37
4.4.6 DiffServ Object usage in GMPLS ......................... 32 4.4.6 DiffServ Object usage in GMPLS ......................... 37
5 Pseudowires ............................................ 33 4.4.7 Support for MPLS-TP LSP Identifiers .................... 37
5.1 LDP Functions and Pseudowires .......................... 33 4.4.8 Support for MPLS-TP Maintenance Identifiers ............ 38
5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 34 5 Pseudowires ............................................ 38
5.3 Anticipated MPLS-TP Related Extensions ................. 36 5.1 LDP Functions and Pseudowires .......................... 38
5.3.1 Extensions to Support Out-of-Band PW Control ........... 37 5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 39
5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 37 5.3 Anticipated MPLS-TP Related Extensions ................. 41
5.3.3 Support for Dynamic Transfer of PW Control/Ownership ... 38 5.3.1 Extensions to Support Out-of-Band PW Control ........... 42
5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 38 5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 42
5.3.5 Support for PW Protection and PW OAM Configuration ..... 39 5.3.3 Support for Dynamic Transfer of PW Control/Ownership ... 43
5.3.6 Client Layer Interfaces to Pseudowire Control .......... 39 5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 43
5.4 Pseudowire OAM and Recovery (Redundancy) ............... 39 5.3.5 Support for PW Protection and PW OAM Configuration ..... 44
6 Security Considerations ................................ 40 5.3.6 Client Layer and Cross-Provider Interfaces to PW Control. 45
7 IANA Considerations .................................... 40 5.4 ASON Architecture Considerations ....................... 45
8 Acknowledgments ........................................ 40 6 Security Considerations ................................ 45
9 References ............................................. 40 7 IANA Considerations .................................... 46
9.1 Normative References ................................... 40 8 Acknowledgments ........................................ 46
9.2 Informative References ................................. 43 9 References ............................................. 46
10 Authors' Addresses ..................................... 48 9.1 Normative References ................................... 46
9.2 Informative References ................................. 49
10 Authors' Addresses ..................................... 54
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.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functions of a packet transport network as defined capabilities and functions of a packet transport network as defined
by the ITU-T. by the ITU-T.
1.1. Conventions Used In This Document 1.1. Scope
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Scope
This document covers the control plane functions involved in This document covers the control plane functions involved in
establishing MPLS-TP Label Switched Paths (LSPs) and Pseudowires establishing MPLS-TP Label Switched Paths (LSPs) and Pseudowires
(PWs). The control plane requirements for MPLS-TP are defined in the (PWs). The control plane requirements for MPLS-TP are defined in the
MPLS-TP requirements document [RFC5654]. These requirements define MPLS-TP requirements document [RFC5654]. These requirements define
the role of the control plane in MPLS-TP. In particular, Sections the role of the control plane in MPLS-TP. In particular, Section 2.4
2.4 and portions of the remainder of Section 2 of [RFC5654] provide of [RFC5654] and portions of the remainder of Section 2 of [RFC5654]
specific control plane requirements. provide 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 an MPLS Packet Switched Network (PSN). The PW encapsulation over
LSPs used in MPLS-TP networks is also the same as for PWs over MPLS MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs
in an MPLS network. MPLS-TP also defines protection and restoration over MPLS in an MPLS network. MPLS-TP also defines protection and
(or, collectively, recovery) functions. The MPLS-TP control plane restoration (or, collectively, recovery) functions, see [RFC5654] and
provides methods to establish, remove and control MPLS-TP LSPs and [RFC4427]. The MPLS-TP control plane provides methods to establish,
PWs. This includes control of data plane, OAM and recovery remove and control MPLS-TP LSPs and PWs. This includes control of
functions. 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 [RFC5921], and a
survivability framework for MPLS-TP has been defined in [TP-SURVIVE]. survivability framework for MPLS-TP has been defined in [TP-SURVIVE].
These document scope the approaches and protocols that will be used These document scope the approaches and protocols that are the
as the foundation for MPLS-TP. Notably, Section 3.5 of [TP-FWK] foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the
scopes the IETF protocols that serve as the foundation of the MPLS-TP IETF protocols that serve as the foundation of the MPLS-TP control
control plane. The PW control plane is based on the existing PW plane. The PW control plane is based on the existing PW control
control plane, see [RFC4447], and the PW end-to-end (PWE3) plane, see [RFC4447], and the PW end-to-end (PWE3) architecture, see
architecture, see [RFC3985]. The LSP control plane is based on [RFC3985]. The LSP control plane is based on Generalized MPLS
Generalized MPLS (GMPLS), see [RFC3945], which is built on MPLS (GMPLS), see [RFC3945], which is built on MPLS Traffic Engineering
Traffic Engineering (TE) and its numerous extensions. [TP-SURVIVE] (TE) and its numerous extensions. [TP-SURVIVE] focuses on the
focuses on LSPs, and the protection functions that must be supported recovery functions that must be supported within MPLS-TP. It does not
within MPLS-TP. It does not specify which control plane mechanisms 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 the MPLS-TP
requirements on the control of PWs as specified in [RFC4447], requirements on the GMPLS signaling and routing protocols that are
[SEGMENTED-PW] and [MS-PW-DYNAMIC]. This document also discusses the used to control MPLS-TP LSPs, and on the control of PWs as specified
impact of the MPLS-TP requirements on the GMPLS signaling and routing in [RFC4447], [SEGMENTED-PW], and [MS-PW-DYNAMIC].
protocols that are used to control MPLS-TP LSPs.
1.3. Basic Approach 1.2. Basic Approach
The basic approach taken in defining the MPLS-TP Control Plane The basic approach taken in defining the MPLS-TP Control Plane
framework is: framework 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-TP is a standard MPLS data plane
extensions defined for MPLS-TP is also applicable to MPLS. [RFC3031] as profiled in [RFC5960].
Additionally, the same encapsulation used for MPLS over any 3) MPLS PWs are used by MPLS-TP including the use of targeted LDP
layer 2 network is also used for MPLS-TP. as the foundation for PW signaling [RFC4447]; and OSPF-TE,
3) MPLS PWs are used as-is by MPLS-TP including the use of ISIS-TE or MP-BGP as they apply for Multi-Segment(MS)-PW
targeted-LDP as the foundation for PW signaling [RFC4447], routing. However, the PW can be encapsulated over an MPLS-TP
OSPF-TE, ISIS-TE or MP-BGP as they apply for Multi- LSP (established using methods and procedures for MPLS-TP LSP
Segment(MS)-PW routing. However, the PW can be encapsulated establishment) in addition to the presently defined methods of
over an MPLS-TP LSP (established using methods and procedures carrying PWs over LSP based packet switched networks (PSNs).
for MPLS-TP LSP establishment) in addition to the presently That is, the MPLS-TP domain is a packet switched network from a
defined methods of carrying PWs over LSP based packet switched PWE3 architecture perspective [RFC3985].
networks (PSNs). That is, the MPLS-TP domain is a packet
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 as defined by the IETF for transport LSPs. The protocols
within scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392], within scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392],
and ISIS-TE [RFC5307][RFC5316]. ASON/ASTN signaling and and ISIS-TE [RFC5307][RFC5316]. ASON signaling and routing
routing requirements in the context of GMPLS can be found in requirements in the context of GMPLS can be found in [RFC4139]
[RFC4139] and [RFC4258]. 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 LSP related functions.
8) Control-plane software upgrades to existing (G)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 and PW
plane to not be used in MPLS-TP networks, e.g. the possibility control planes to not be used in MPLS-TP networks.
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 generally control OAM functionality. This will require
existing control plane specifications which will be usable in extensions to existing control plane specifications which will
MPLS-TP as well as MPLS networks. be usable in MPLS-TP as well as MPLS networks.
11) MPLS-TP requirements are primarily defined in Section 2.4 and 11) The foundation for MPLS-TP control plane requirements is
relevant portions of the remainder Section 2 of [RFC5654]. primarily found in Section 2.4 of [RFC5654] and relevant
portions of the remainder Section 2 of [RFC5654].
1.4. Reference Model 1.3. Reference Model
The control plane reference model is based on the general MPLS-TP The control plane reference model is based on the general MPLS-TP
reference model as defined in the MPLS-TP framework [TP-FWK]. Per the reference model as defined in the MPLS-TP framework [RFC5921]. Per
MPLS-TP framework [TP-FWK], the MPLS-TP control plane is based on the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based
GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW
signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions
is used for dynamic routing within an MPLS-TP domain. is used for dynamic routing within an MPLS-TP domain.
From a service perspective, client interfaces are provided for both Note that in this context, "targeted LDP" (or T-LDP) means LDP as
the PWs and LSPs. PW client interfaces are defined on an interface defined in RFC 5036, using Targeted Hello messages. See Section
technology basis, e.g., Ethernet over PW [RFC4448]. In the context of 2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the
MPLS-TP LSP, the client interface is expected to be provided via a extended discovery mechanism is specified in [RFC4447] Section 5
GMPLS based UNI, see [RFC4208], or statically provisioned. As ("LDP").
discussed in [TP-FWK], MPLS-TP also presumes an LSP NNI reference
point. From a service perspective, MPLS-TP client services may be supported
via both PWs and LSPs. PW client interfaces, or adaptations, are
defined on an interface technology basis, e.g., Ethernet over PW
[RFC4448]. In the context of MPLS-TP LSP, the client interface is
provided at the network layer and may be controlled via a GMPLS based
UNI, see [RFC4208], or statically provisioned. As discussed in
[RFC5921], MPLS-TP also presumes an LSP NNI reference point.
The MPLS-TP end-to-end control plane reference model is shown in The MPLS-TP end-to-end control plane reference model is shown in
Figure 1. The Figure shows the control plane protocols used by MPLS- Figure 1. The Figure shows the control plane protocols used by MPLS-
TP, as well as the UNI and NNI reference points. TP, as well as the UNI and NNI reference points, in the case of a
single segment PW. (The MS-PW case is not shown.)
|< ---- client signal (IP / MPLS / L2 / PW) ------------ >| |< ---- client signal (e.g., IP / MPLS / L2) -------- >|
|< --------- SP1 ----------- >|< ------- SP2 ------- >| |< --------- SP1 ---------- >|< ------- SP2 ----- >|
|< ---------- MPLS-TP End-to-End PW ------------ >| |< ---------- MPLS-TP End-to-End PW --------- >|
|< -------- MPLS-TP End-to-End LSP --------- >| |< -------- MPLS-TP End-to-End LSP ------ >|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI UNI NNI UNI
TE-RTG |< ---------------- >|< --- >|< ---------- >| TE-RTG, |< ---------------- >|< --- >|< ---------- >|
RSVP-TE & RSVP-TE
LDP |< --------------------------------------- >| LDP |< --------------------------------------- >|
Figure 1. End-to-End MPLS-TP Control Plane Reference Model Figure 1. End-to-End MPLS-TP Control Plane Reference Model
Legend: Legend:
CE: Customer Edge CE: Customer Edge
Client signal: defined in MPLS-TP Requirements Client signal: defined in MPLS-TP Requirements
L2: Any layer 2 signal that may be carried L2: Any layer 2 signal that may be carried
over a PW, e.g. Ethernet. over a PW, e.g. Ethernet.
NNI: Network to Network Interface NNI: Network to Network Interface
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 Maintenance
each provider domain and across the inter-provider NNI. The MEPs are End Points (MEPs), see [TP-OAM], within each provider domain and
used to collect performance information, support diagnostic across the inter-provider NNI. The MEPs are used to collect
performance information, support diagnostic and fault management
functions, and support OAM triggered survivability schemes as functions, and support OAM triggered survivability schemes as
discussed in [TP-SURVIVE]. Each H-LSP may be protected using any of discussed in [TP-SURVIVE]. Each H-LSP may be protected or restored
the schemes discussed in [TP-SURVIVE]. End-to-end monitoring is using any of the schemes discussed in [TP-SURVIVE]. End-to-end
supported via MEPs at the End-to-End LSP and PW end points. Note monitoring is supported via MEPs at the End-to-End LSP and PW end
that segment MEPs are collocated with MIPs of the next higher-layer points. Note that segment MEPs may be collocated with MIPs of the
(e.g., end-to-end) LSPs. next higher-layer (e.g., end-to-end) LSPs. H-LSPs may also be used
to implement Sub-Path Maintenance Elements (SPMEs) as defined in
|< ------- client signal (IP / MPLS / L2 / PW) ------ >| [RFC5921]. (The MS-PW case is not shown.)
|< ------- client signal (e.g., IP / MPLS / L2) ----- >|
|< -------- SP1 ----------- >|< ------- SP2 ----- >| |< -------- SP1 ----------- >|< ------- SP2 ----- >|
|< ----------- MPLS-TP End-to-End PW -------- >| |< ----------- MPLS-TP End-to-End PW -------- >|
|< ------- MPLS-TP End-to-End LSP ------- >| |< ------- MPLS-TP End-to-End LSP ------- >|
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI UNI NNI UNI
..... ..... ..... ..... ..... ..... ..... .....
End2end |MEP|----------------|MIP|---|MIP|---------|MEP| End2end |MEP|----------------|MIP|---|MIP|---------|MEP|
OAM ''''' ''''' ''''' ''''' PW OAM ''''' ''''' ''''' '''''
..... ..... ..... ......... ......... ..... ..... ..... ..... ..... ......... ......... ..... .....
Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP| Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' ''''' OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''
Seg.TE-RTG|< -- >|< -- >|< -- >||< -- >||< -- >|< -- >| Seg.TE-RTG|< -- >|< -- >|< -- >||< -- >||< -- >|< -- >|
RSVP-TE (within the MPLS-TP domain) &RSVP-TE (within an MPLS-TP network)
E2E TE-RTG|< ---------------- >|< ---- >|< --------- >| E2E TE-RTG|< ---------------- >|< ---- >|< --------- >|
RSVP-TE &RSVP-TE
LDP |< --------------------------------------- >| LDP |< --------------------------------------- >|
Figure 2. MPLS-TP Control Plane Reference Model with OAM Figure 2. MPLS-TP Control Plane Reference Model with OAM
Legend: Legend:
CE: Customer Edge CE: Customer Edge
Client signal: defined in MPLS-TP Requirements Client signal: defined in MPLS-TP Requirements
E2E: End-to-end E2E: End-to-end
L2: Any layer 2 signal that may be carried L2: Any layer 2 signal that may be carried
over a PW, e.g. Ethernet. over a PW, e.g. Ethernet.
H-LSP: Hierarchical LSP H-LSP: Hierarchical LSP
MEP: Maintenance end point MEP: Maintenance end point
MIP: Maintenance intermediate point MIP: Maintenance intermediate point
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
While not shown in the Figures above, it is worth noting that the While not shown in the Figures above, the MPLS-TP control plane must
MPLS-TP control plane must support the addressing separation and support the addressing separation and independence between the data,
independence between the data, control and management planes as shown control and management planes. Address separation between the planes
in Figure 3 of [TP-FWK]. Address separation between the planes is is already included in GMPLS. Such separation is also already
already included in GMPLS. included in LDP as LDP session end point addresses are never
automatically associated with forwarding.
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], [RFC5860], [TP-OAM], and [TP-SURVIVE]. The requirements [RFC5921], [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 of [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
skipping to change at page 8, line 51 skipping to change at page 9, line 51
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-
point transport paths [RFC5654, requirement 7]. point transport paths [RFC5654, requirement 7].
8. The MPLS-TP control plane must support unidirectional point-to- 8. The MPLS-TP control plane must support unidirectional point-to-
multipoint transport paths [RFC5654, requirement 8]. multipoint transport paths [RFC5654, requirement 8].
9. All nodes (i.e., ingress, egress and intermediate) must be 9. The MPLS-TP control plane must enable all nodes (i.e., ingress,
aware about the pairing relationship of the forward and the egress and intermediate) to be aware about the pairing
backward directions belonging to the same co-routed relationship of the forward and the backward directions
bidirectional transport path [RFC5654, requirement 10]. belonging to the same co-routed bidirectional transport path
10. Edge nodes (i.e., ingress and egress) must be aware of the [RFC5654, requirement 10].
pairing relationship of the forward and the backward directions
belonging to the same associated bidirectional transport path
[RFC5654, requirement 11].
11. Transit nodes should be aware of the pairing relationship of 10. The MPLS-TP control plane must enable edge nodes (i.e., ingress
the forward and the backward directions belonging to the same and egress) to be aware of the pairing relationship of the
forward and the backward directions belonging to the same
associated bidirectional transport path [RFC5654, requirement associated bidirectional transport path [RFC5654, requirement
12]. 11].
11. The MPLS-TP control plane should enable common transit nodes to
be aware of the pairing relationship of the forward and the
backward directions belonging to the same associated
bidirectional transport path [RFC5654, requirement 12].
12. The MPLS-TP control plane must support bidirectional transport 12. The MPLS-TP control plane must support bidirectional transport
paths with symmetric bandwidth requirements, i.e. the amount of paths with symmetric bandwidth requirements, i.e. the amount of
reserved bandwidth is the same in the forward and backward reserved bandwidth is the same in the forward and backward
directions [RFC5654, requirement 13]. directions [RFC5654, requirement 13].
13. The MPLS-TP control plane must support bidirectional transport 13. The MPLS-TP control plane must support bidirectional transport
paths with asymmetric bandwidth requirements, i.e. the amount paths with asymmetric bandwidth requirements, i.e. the amount
of reserved bandwidth differs in the forward and backward of reserved bandwidth differs in the forward and backward
directions [RFC5654, requirement 14]. directions [RFC5654, requirement 14].
14. The MPLS-TP control plane must support the logical separation 14. The MPLS-TP control plane must support the logical separation
of the control and management planes from the data plane of the control plane from the management and data plane
[RFC5654, requirement 15]. Note that this implies that the [RFC5654, requirement 15]. Note that this implies that the
addresses used in the management, control and data planes are addresses used in the control plane are independent from the
independent. addresses used in the management and data planes.
15. The MPLS-TP control plane must support the physical separation 15. The MPLS-TP control plane must support the physical separation
of the control and management planes from the data plane, and of the control plane from the management and data plane, and no
no assumptions should be made about the state of the data-plane assumptions should be made about the state of the data plane
channels from information about the control or management-plane channels from information about the control or management plane
channels when they are running out-of-band [RFC5654, channels when they are running out-of-band [RFC5654,
requirement 16]. requirement 16].
16. A control plane must be defined to support dynamic provisioning 16. A control plane must be defined to support dynamic provisioning
and restoration of MPLS-TP transport paths, but its use is a and restoration of MPLS-TP transport paths, but its use is a
network operator's choice [RFC5654, requirement 18]. network operator's choice [RFC5654, requirement 18].
17. A control plane must not be required to support the static 17. A control plane must not be required to support the static
provisioning of MPLS-TP transport paths. [RFC5654, requirement provisioning of MPLS-TP transport paths. [RFC5654, requirement
19]. 19].
skipping to change at page 10, line 21 skipping to change at page 11, line 25
22. The MPLS-TP control plane should work across multiple non- 22. The MPLS-TP control plane should work across multiple non-
homogeneous domains [RFC5654, requirement 26]. homogeneous domains [RFC5654, requirement 26].
23. The MPLS-TP control plane must not dictate any particular 23. The MPLS-TP control plane must not dictate any particular
physical or logical topology [RFC5654, requirement 27]. physical or logical topology [RFC5654, requirement 27].
24. The MPLS-TP control plane must include support of ring 24. The MPLS-TP control plane must include support of ring
topologies which may be deployed with arbitrarily topologies which may be deployed with arbitrarily
interconnection, support rings of at least 16 nodes [RFC5654, interconnection, support rings of at least 16 nodes [RFC5654,
requirement 27.A. and 27.B.]. requirement 27.A. and 27.B].
25. The MPLS-TP control plane must scale gracefully to support a 25. The MPLS-TP control plane must scale gracefully to support a
large number of transport paths, nodes and links. That is it large number of transport paths, nodes and links. That is it
must be able to scale at least as well as control planes in must be able to scale at least as well as control planes in
existing transport technologies with growing and increasingly existing transport technologies with growing and increasingly
complex network topologies as well as with increasing bandwidth complex network topologies as well as with increasing bandwidth
demands, number of customers, and number of services [RFC 5654, demands, number of customers, and number of services [RFC 5654,
requirements 53 and 28]. requirements 53 and 28].
26. The MPLS-TP control plane should not provision transport paths 26. The MPLS-TP control plane should not provision transport paths
skipping to change at page 11, line 5 skipping to change at page 12, line 9
a client layer network, and the MPLS-TP layer network is a client layer network, and the MPLS-TP layer network is
supported by a server layer network then the control plane supported by a server layer network then the control plane
operation of the MPLS-TP layer network must be possible without operation of the MPLS-TP layer network must be possible without
any dependencies on the server or client layer network any dependencies on the server or client layer network
[RFC5654, requirement 32]. [RFC5654, requirement 32].
30. The MPLS-TP control plane must allow for the transport of a 30. The MPLS-TP control plane must allow for the transport of a
client MPLS or MPLS-TP layer network over a server MPLS or client MPLS or MPLS-TP layer network over a server MPLS or
MPLS-TP layer network [RFC5654, requirement 33]. MPLS-TP layer network [RFC5654, requirement 33].
31. The MPLS-TP control plane must allow the operation the layers 31. The MPLS-TP control plane must allow the autonomous operation
of a multi-layer network that includes an MPLS-TP layer of the layers of a multi-layer network that includes an MPLS-TP
autonomously [RFC5654, requirement 34]. layer [RFC5654, requirement 34].
32. The MPLS-TP control plane must allow the hiding of MPLS-TP 32. The MPLS-TP control plane must allow the hiding of MPLS-TP
layer network addressing and other information (e.g. topology) layer network addressing and other information (e.g. topology)
from client layer networks. However, it should be possible, at from client layer networks. However, it should be possible, at
the option of the operator, to leak a limited amount of the option of the operator, to leak a limited amount of
summarized information (such as SRLGs or reachability) between summarized information (such as 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 the use of P2MP server
(sub-)layers [RFC5654, requirement 40]. (sub)layer capabilities as well as P2P server (sub)layer
capabilities when supporting P2MP MPLS-TP transport paths
[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].
37. The MPLS-TP control plane should support the reserved bandwidth 37. The MPLS-TP control plane should support the reserved bandwidth
of a transport path to be decreased without impacting the of a transport path to be decreased without impacting the
existing traffic on that transport path, provided that the existing traffic on that transport path, provided that the
level of existing traffic is smaller than the reserved level of existing traffic is smaller than the reserved
bandwidth following the decrease [RFC5654, requirement 43]. bandwidth following the decrease [RFC5654, requirement 43].
38. The MPLS-TP control plane must support an unambiguous and 38. Requirement removed.
reliable means of distinguishing users' (client) packets from
MPLS-TP control packets (e.g. control plane, management plane,
OAM and protection switching packets) [RFC5654, requirement
46].
39. The control plane for MPLS-TP must fit within the ASON 39. The control plane for MPLS-TP must fit within the ASON
architecture. The ITU-T has defined an architecture for architecture. The ITU-T has defined an architecture for
Automatically Switched Optical Networks (ASON) in G.8080 Automatically Switched Optical Networks (ASON) in G.8080
[ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An
interpretation of the ASON signaling and routing requirements interpretation of the ASON signaling and routing requirements
in the context of GMPLS can be found in [RFC4139] and [RFC4258] in the context of GMPLS can be found in [RFC4139] and [RFC4258]
[RFC5654, Section 2.4., Paragraph 2 and 3]. [RFC5654, Section 2.4., Paragraph 2 and 3].
40. The MPLS-TP control plane must support control plane topology 40. The MPLS-TP control plane must support control plane topology
skipping to change at page 15, line 26 skipping to change at page 16, line 26
76. The MPLS-TP control plane should support control plane 76. The MPLS-TP control plane should support control plane
restoration triggers (e.g., forced switch, etc.) [RFC5654, restoration triggers (e.g., forced switch, etc.) [RFC5654,
requirement 78]. requirement 78].
77. The MPLS-TP control plane must support priority logic to 77. The MPLS-TP control plane must support priority logic to
negotiate and accommodate coexisting requests (i.e., multiple negotiate and accommodate coexisting requests (i.e., multiple
requests) for protection switching (e.g., administrative requests) for protection switching (e.g., administrative
requests and requests due to link/node failures) [RFC5654, requests and requests due to link/node failures) [RFC5654,
requirement 79]. requirement 79].
78. The MPLS-TP control plane must support the relationships of 78. The MPLS-TP control plane must support the association of
protection paths and protection-to-working paths (sometimes protection paths and working paths (sometimes known as
known as protection groups) [RFC5654, requirement 80]. protection groups) [RFC5654, requirement 80].
79. The MPLS-TP control plane must support pre-calculation of 79. The MPLS-TP control plane must support pre-calculation of
recovery paths [RFC5654, requirement 81]. recovery paths [RFC5654, requirement 81].
80. The MPLS-TP control plane must support pre-provisioning of 80. The MPLS-TP control plane must support pre-provisioning of
recovery paths [RFC5654, requirement 82]. recovery paths [RFC5654, requirement 82].
81. The MPLS-TP control plane must support the external commands 81. The MPLS-TP control plane must support the external commands
defined in [RFC4427]. External controls overruled by higher defined in [RFC4427]. External controls overruled by higher
priority requests (e.g., administrative requests and requests priority requests (e.g., administrative requests and requests
skipping to change at page 17, line 7 skipping to change at page 18, line 7
(SLS), with support for hard ([RFC3209] style) and relative (SLS), with support for hard ([RFC3209] style) and relative
([RFC3270] style) end-to-end bandwidth guarantees [RFC5654, ([RFC3270] style) end-to-end bandwidth guarantees [RFC5654,
requirement 111]. requirement 111].
93. The MPLS-TP control plane must support the provisioning of 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], [TP- The following additional requirements are based on [RFC5921], [TP-
P2MP-FWK] and [TP-DATA]: P2MP-FWK] and [RFC5960]:
94. Per-packet equal cost multi-path (ECMP) load balancing is not 94. Per-packet equal cost multi-path (ECMP) load balancing is
applicable to MPLS-TP [TP-DATA-PLANE , section 3.1.1., currently outside the scope of MPLS-TP [TP-DATA-PLANE , section
paragraph 6]. 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. [TP-DATA-PLANE , section 3.1.1., paragraph 7].
networks generally providing packet transport services will be
clarified in a future version [TP-DATA-PLANE , section 3.1.1.,
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-DATA-PLANE , MPLS DiffServ modes as specified in [RFC3270] [TP-DATA-PLANE ,
section 3.3.2., paragraph 12]. section 3.3.2., paragraph 12].
97. Both single-segment and multi-segment PWs shall be supported by 97. Both single-segment, see [RFC3985], and multi-segment PWs, see
the MPLS-TP control plane. MPLS-TP shall use the definition of [RFC5659], shall be supported by the MPLS-TP control plane.
multi-segment PWs as defined by the IETF [TP-FWK, section MPLS-TP shall use the definition of multi-segment PWs as
3.4.4.]. defined by the IETF [RFC5921, section 3.4.4].
98. The MPLS-TP control plane must support the control of PWs and 98. The MPLS-TP control plane must support the control of PWs and
their associated labels [TP-FWK, section 3.4.4.]. their associated labels [RFC5921, 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.5.]. network without the use of PWs [RFC5921, section 3.4.5].
a. The MPLS-TP control plane must support the use of network a. The MPLS-TP control plane must support the use of network
layer protocol-specific LSPs and labels. [TP-FWK, section layer protocol-specific LSPs and labels. [RFC5921,
3.4.5.] section 3.4.5.]
b. The MPLS-TP control plane must support the use of a b. The MPLS-TP control plane must support the use of a
client service-specific LSPs and labels. [TP-FWK, section client service-specific LSPs and labels. [RFC5921,
3.4.5.] section 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.9.]. [RFC5921, 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.9., paragraph 5]. is used for PW signaling [RFC5921, section 3.9., paragraph 5].
102. Requirement intentionally blank.
103. The MPLS-TP control plane must ensure its own survivability and 102. 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, section 3.9., paragraph 16]. configurations [RFC5921, section 3.9., paragraph 16].
104. The MPLS-TP control plane must support linear, ring and meshed 103. The MPLS-TP control plane must support linear, ring and meshed
protection schemes [TP-FWK, section 3.12., paragraph 3]. protection schemes [RFC5921, section 3.12., paragraph 3].
104. The MPLS-TP control plane must support the control of SPMEs
(hierarchical LSPs) for new or existing end-to-end LSPs
[RFC5921, section 3.12., paragraph 7].
2.3. OAM Framework Derived Requirements 2.3. OAM Framework Derived Requirements
The following additional requirements are based on [RFC5860] and [TP- The following additional requirements are based on [RFC5860] and [TP-
OAM]: OAM]:
105. The MPLS-TP control plane must support the capability to 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
[RFC5860, section 2.1.6., paragraph 1]. [RFC5860, section 2.1.6., paragraph 1]. Note that OAM functions
are applicable regardless of the label stack depth (i.e., level
of LSP hierarchy or PW) [RFC5860, section 2.1.1., paragraph 3].
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 [RFC5860, section 2.1.6., as a result of OAM enabling/disabling [RFC5860, section 2.1.6.,
paragraph 1 and 2]. paragraph 1 and 2].
107. The MPLS-TP control plane must allow for the IP/MPLS and PW OAM 107. The MPLS-TP control plane must support dynamic control of any
protocols (e.g., LSP-Ping [RFC4379], MPLS-BFD [RFC5884], VCCV of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping
[RFC5085] and VCCV-BFD [RFC5885]) [RFC5860, section 2.1.4., [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD
paragraph 2]. [RFC5885]) [RFC5860, section 2.1.4., 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 [RFC5860, section 2.2., paragraph 2]. by default [RFC5860, section 2.2., paragraph 2].
109. The MPLS-TP control plane must support the choice of which (if 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 [RFC5860, 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 allow (e.g., enable/disable)
the localization of faults and the notification of appropriate mechanisms that support the localization of faults and the
nodes. Such notification should trigger corrective (recovery) notification of appropriate nodes. [RFC5860, section 2.2.1.,
actions [RFC5860, section 2.2.1., paragraph 1]. paragraph 1].
111. The MPLS-TP control plane must allow the service provider to be 111. The MPLS-TP control plane may support mechanisms that permit
informed of a fault or defect affecting the service(s) it the service provider to be informed of a fault or defect
provides, even if the fault or defect is located outside of his affecting the service(s) it provides, even if the fault or
domain [RFC5860, section 2.2.1., paragraph 2]. defect is located outside of his 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 changes are effectively known by the appropriate nodes
[RFC5860, section 2.2.1., paragraph 3]. [RFC5860, section 2.2.1., paragraph 3].
113. The MPLS-TP control plane must provide functionality to control 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's ability to monitor the liveness of a PW, LSP, or
(CC), of a PW, LSP or Section [RFC5860, section 2.2.2., 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) by means of the expected PW,
verification (CV), by means of the expected PW, LSP or Section LSP, or Section [RFC5860, section 2.2.3., paragraph 1].
[RFC5860, section 2.2.3., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control an End Point's ability to perform this function
proactively [RFC5860, section 2.2.3., paragraph 2].
b. The MPLS-TP control plane must provide mechanisms to
control an End Point's ability to perform this function
on-demand [RFC5860, section 2.2.3., paragraph 3].
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 [RFC5860, section diagnostic testing on a PW, LSP or Section [RFC5860, section
2.2.5., paragraph 1]. 2.2.5., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function on-demand
[RFC5860, section 2.2.5., paragraph 2].
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 [RFC5860, trace (record) the route of a PW, LSP or Section [RFC5860,
section 2.2.4., paragraph 1]. section 2.2.4., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function on-demand
[RFC5860, section 2.2.4., paragraph 2].
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 [RFC5860, section
corresponds to an administrative status in which it is expected 2.2.6., paragraph 1].
that only test traffic, if any, and OAM (dedicated to the PW,
LSP or Section) can be mapped on that PW, LSP or Section a. The MPLS-TP control plane must provide mechanisms to
[RFC5860, section 2.2.6., paragraph 1]. control the performance of this function on-demand
[RFC5860, section 2.2.6., paragraph 2].
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 [RFC5860, section 2.2.7., paragraph 1]. that PW or LSP [RFC5860, section 2.2.7., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively
[RFC5860, section 2.2.7., paragraph 2].
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 [RFC5860, section 2.2.8., paragraph 1]. that PW or LSP [RFC5860, section 2.2.8., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively
[RFC5860, section 2.2.8., paragraph 2].
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 [RFC5860, section 2.2.9., which they are the End Points [RFC5860, section 2.2.9.,
paragraph 1]. paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively
[RFC5860, section 2.2.9., paragraph 2].
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 [RFC5860, provide an alarm notification/propagation mechanism [RFC5860,
section 2.2.10., paragraph 1]. section 2.2.10., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively
[RFC5860, section 2.2.10., paragraph 2].
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 [RFC5860, section 2.2.11., paragraph 1]. LSP or Section [RFC5860, section 2.2.11., paragraph 1].
a. The MPLS-TP control plane must provide mechanisms to
control the performance of this function proactively and
on-demand [RFC5860, section 2.2.11., paragraph 4].
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 appropriate, the two-way, delay of a PW, LSP or Section
[RFC5860, section 2.2.12., paragraph 1]. [RFC5860, section 2.2.12., paragraph 1].
124. The MPLS-TP control plane must support the configuration of a. The MPLS-TP control plane must provide mechanisms to
MEPs. control the performance of this function proactively and
on-demand [RFC5860, section 2.2.12., paragraph 6].
a. The CC and CV functions operate between MEPs [TP-OAM, 124. The MPLS-TP control plane must support the configuration of OAM
section 5.1., paragraph 3]. functional components which include MEs and MEGs as
instantiated in MEPs, MIPs and SPMEs [TP-OAM, section 3.6].
b. All OAM packets coming to a MEP source are tunneled via 125. For dynamically established transport paths, the control plane
label stacking, and therefore a MEP can only exist at the must support the configuration of OAM operations [TP-OAM,
beginning and end of an LSP (i.e. at an LSP's ingress and section 5].
egress nodes and never at an LSP's transit node) [TP-OAM,
section 3.2., paragraph 10].
c. The CC and CV functions may serve as a trigger for a. The MPLS-TP control plane must provide mechanisms to
protection switching, see requirement 45 above. configure proactive monitoring for a MEG at, or after,
transport path creation time.
d. This implies that LSP hierarchy must be used in cases b. The MPLS-TP control plane must provide mechanisms to
where OAM is used to trigger recovery when the recover configure the operational characteristics of in-band
occurs at points other than an LSPs endpoints. [TP-OAM, measurement transactions (e.g., CV, LM etc.) are
section 4., paragraph 5]. configured at the MEPs (associated with a transport
path).
125. The MPLS-TP control plane must support the signaling of the MEP c. The MPLS-TP control plane may provide mechanisms to
identifier used in CC and CV [TP-OAM, section 5.1., paragraph configure server layer event reporting by intermediate
4]. nodes.
126. The MPLS-TP control plane must support the signaling of the d. The MPLS-TP control plane may provide mechanisms to
transmission period used in CC and CV [TP-OAM, section 5.1., configure the reporting of measurements resulting from
paragraph 6]. proactive monitoring.
126. The MPLS-TP control plane must support the control of the loss
of continuity (LOC) traffic block consequent action [TP-OAM,
section 5.1.2., paragraph 4].
127. For dynamically established transport paths that have a
proactive CC-V function enabled, the control plane must support
the signaling of the following MEP configuration information
[TP-OAM, section 5.1.3]:
a. The MPLS-TP control plane must provide mechanisms to
configure the MEG identifier to which the MEP belongs.
b. The MPLS-TP control plane must provide mechanisms to
configure a MEP's own identity inside a MEG.
c. The MPLS-TP control plane must provide mechanisms to
configure the list of the other MEPs in the MEG.
d. The MPLS-TP control plane must provide mechanisms to
configure the CC-V transmission rate / reception period
(covering all application types).
128. The MPLS-TP control plane must provide mechanisms to configure
the generation of Alarm Indication Signal (AIS) packets for
each MEG [TP-OAM, section 5.3., paragraph 9].
129. The MPLS-TP control plane must provide mechanisms to configure
the generation of Locked Report (LKR) packets for each MEG [TP-
OAM, section 5.4., paragraph 9].
130. The MPLS-TP control plane must provide mechanisms to configure
the use of proactive Packet Loss Measurement (LM), and the
transmission rate and PHB class associated with the LM OAM
packets originating from a MEP [TP-OAM, section 5.5.1.,
paragraph 1].
131. The MPLS-TP control plane must provide mechanisms to configure
the use of proactive Packet Delay Measurement (DM), and the
transmission rate and PHB class associated with the DM OAM
packets originating from a MEP [TP-OAM, section 5.6.1.,
paragraph 1].
132. The MPLS-TP control plane must provide mechanisms to configure
the use of Client Failure Indication (CFI), and the
transmission rate and PHB class associated with the CFI OAM
packets originating from a MEP [TP-OAM, section 5.7.1.,
paragraph 1].
133. The MPLS-TP control plane should provide mechanisms to control
the use of on-demand CV packets [TP-OAM, section 6.1].
a. The MPLS-TP control plane should provide mechanisms to
configure the number of packets to be
transmitted/received in each burst of on-demand CV
packets and their packet size [TP-OAM, section 6.1.1,
paragraph 1].
b. When an on-demand CV packet is used to check connectivity
toward a target MIP, the MPLS-TP control plane should
provide mechanisms to configure the number of hops to
reach the target MIP [TP-OAM, section 6.1.1, paragraph
2].
c. The MPLS-TP control plane should provide mechanisms to
configure the PHB of on-demand CV packets [TP-OAM,
section 6.1.1, paragraph 3].
134. The MPLS-TP control plane should provide mechanisms to control
the use of on-demand LM, including configuration of the
beginning and duration of the LM procedures, the transmission
rate and PHB associated with the LM OAM packets originating
from a MEP. [TP-OAM, section 6.2.1.]
135. The MPLS-TP control plane should provide mechanisms to control
the use of Throughput estimation [TP-OAM, section 6.3.1].
136. The MPLS-TP control plane should provide mechanisms to control
the use of on-demand DM, including configuration of the
beginning and duration of the DM procedures, the transmission
rate and PHB associated with the DM OAM packets originating
from a MEP. [TP-OAM, section 6.5.1.]
2.4. Security Requirements 2.4. Security Requirements
There are no specific MPLS-TP control plane security requirements. There are no specific MPLS-TP control plane security requirements.
The existing framework for MPLS and GMPLS security is documented on The existing framework for MPLS and GMPLS security is documented in
[MPLS-SEC] and that document applies equally to MPLS-TP. [RFC5920] and that document applies equally to MPLS-TP.
2.5. Identifier Requirements
The following are requirements based on [TP-IDENTIFIERS]:
137. The MPLS-TP control plane must support MPLS-TP point to point
tunnel identifiers of the forms defined in [TP-IDENTIFIERS,
Section 5.1].
138. The MPLS-TP control plane must support MPLS-TP LSP identifiers
of the forms defined in [TP-IDENTIFIERS, Section 5.2], and the
mappings to GMPLS as defined in [TP-IDENTIFIERS, Section 5.3].
139. The MPLS-TP control plane must support Pseudowire path
identifiers of the form defined in [TP-IDENTIFIERS, Section 6].
140. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs
as defined in [TP-IDENTIFIERS, Section 7.1.1].
141. The MPLS-TP control plane must support IP compatible MEG_IDs
for LSPs and PWs as defined [TP-IDENTIFIERS, Section 7.1.2].
142. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs
of the forms defined in [TP-IDENTIFIERS, Section 7.2.1].
143. The MPLS-TP control plane must support IP based MEP_IDs for
MPLS-TP LSP of the forms defined in [TP-IDENTIFIERS, Section
7.2.2.1].
144. The MPLS-TP control plane must support IP based MEP_IDs for
Pseudowires of the form defined in [TP-IDENTIFIERS, Section
7.2.2.2].
3. Relationship of PWs and TE LSPs 3. Relationship of PWs and TE LSPs
The data plane relationship between PWs and LSPs is inherited from The data plane relationship between PWs and LSPs is inherited from
standard MPLS and is reviewed in the MPLS-TP Framework [TP-FWK]. standard MPLS and is reviewed in the MPLS-TP Framework [RFC5921].
Likewise, the control plane relationship between PWs and LSPs is Likewise, the control plane relationship between PWs and LSPs is
inherited from standard MPLS. This relationship is reviewed in this inherited from standard MPLS. This relationship is reviewed in this
document. The relationship between the PW and LSP control planes in document. The relationship between the PW and LSP control planes in
MPLS-TP is the same as the relationship found in the PWE3 Maintenance MPLS-TP is the same as the relationship found in the PWE3 Maintenance
Reference Model as presented in the PWE3 Architecture, see Figure 6 Reference Model as presented in the PWE3 Architecture, see Figure 6
of [RFC3985]. The PWE3 Architecture [RFC3985] states: "the PWE3 of [RFC3985]. The PWE3 Architecture [RFC3985] states: "the PWE3
protocol-layering model is intended to minimize the differences protocol-layering model is intended to minimize the differences
between PWs operating over different PSN types." Additionally, PW between PWs operating over different PSN types." Additionally, PW
control (maintenance) takes place separately from LSP tunnel control (maintenance) takes place separately from LSP signaling.
signaling. [RFC3985] does allow for the extension of the (LSP) [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of
tunnel control plane to exchange information necessary to support LDP as the control plane for PWs. This control can provide PW
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
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, or PW PW control will occur within the nodes that terminate PWs, or PW
segments. See Section 5.3.2 for an additional discussion on such segments. See Section 5.3.2 for an additional discussion on such
coordination. coordination.
skipping to change at page 21, line 50 skipping to change at page 25, line 46
used independently, and that one may be employed without the other. used independently, and that one may be employed without the other.
This translates into the four possible scenarios: (1) no control This translates into the four possible scenarios: (1) no control
plane is employed; (2) a control plane is used for both LSPs and PWs; plane is employed; (2) a control plane is used for both LSPs and PWs;
(3) a control plane is used for LSPs, but not PWs; (4) a control (3) a control plane is used for LSPs, but not PWs; (4) a control
plane is used for PWs, but not LSPs. 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 can 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
LSP layer. PW based recovery is under development at this time and LSP layer. PW based recovery is under development at this time and
may be used once defined. may be used once defined.
4. TE LSPs 4. TE LSPs
MPLS-TP LSPs are controlled via Generalized MPLS (GMPLS) signaling MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see
and routing, see [RFC3945]. The GMPLS control plane is based on the [RFC3945], as the control plane for LSPs. The GMPLS control plane is
MPLS control plane. GMPLS includes support for MPLS labeled data and based on the MPLS control plane. GMPLS includes support for MPLS
transport data planes. GMPLS includes most of the transport centric labeled data and transport data planes. GMPLS includes most of the
features required to support MPLS-TP LSPs. This section will first transport centric features required to support MPLS-TP LSPs. This
review the MPLS-TP LSP relevant features of GMPLS, then identify how section will first review the features of GMPLS relevant to MPLS-TP
specific requirements can be met using existing GMPLS functions and LSPs, then identify how specific requirements can be met using
will conclude with extensions that are anticipated to support MPLS- existing GMPLS functions, and will conclude with extensions that are
TP. anticipated to support the remaining MPLS-TP control plane
requirements.
4.1. GMPLS Functions and MPLS-TP LSPs 4.1. GMPLS Functions and MPLS-TP LSPs
This section reviews how existing GMPLS functions can be applied to This section reviews how existing GMPLS functions can be applied to
MPLS-TP. MPLS-TP.
4.1.1. In-Band and Out-Of-Band Control and Management 4.1.1. In-Band and Out-Of-Band Control
GMPLS supports both in-band and out-of-band control. The terms in- GMPLS supports both in-band and out-of-band control. The terms in-
band and out-of-band typically refer to the relationship of the band and out-of-band, in the context of this document, refer to the
management and control planes relative to the data plane. The terms relationship of the control plane relative to the management and data
may be used to refer to the management plane independent of the planes. The terms may be used to refer to the control plane
control plane, or to both of them in concert. There are multiple independent of the management plane, or to both of them in concert.
uses of both terms in-band and out-of-band. The terms may relate to The remainder of this section describes the relationship of the
a channel, a path or a network. Each of these can be used control plane to the management and data planes.
independently or in combination. Briefly, some typical usage of the
terms are as follows: There are multiple uses of both terms in-band and out-of-band. The
terms may relate to a channel, a path or a network. Each of these
can be used independently or in combination. Briefly, some typical
usage of the terms are as follows:
o In-band o In-band
This term is used to refer to cases where management and/or This term is used to refer to cases where control plane traffic
control plane traffic is sent using or embedded in the same is sent in the same communication channel used to transport
communication channel used to transport the associated data. IP, associated user data or management traffic. IP, MPLS, and
MPLS, and Ethernet networks are all examples where control Ethernet networks are all examples where control traffic is
traffic is typically sent in-band with the data traffic. typically sent in-band with the data traffic. An example of this
case in the context of MPLS-TP is where control plane traffic is
sent via the MPLS Generic Associated Channel (G-ACh), see
[RFC5586], using the same LSP as controlled user traffic.
o Out-of-band, in-fiber o Out-of-band, in-fiber
This term is used to refer to cases where management and/or This term is used to refer to cases where control plane traffic
control plane traffic is sent using a different communication is sent using a different communication channel from the
channel from the associated data traffic, and the associated data or management traffic, and the control
control/management communication channel resides in the same communication channel resides in the same fiber as either the
fiber as the data traffic. Optical transport networks typically management or data traffic. An example of this case in the
operate in an out-of-band in-fiber configuration. context of MPLS-TP is where control plane traffic is sent via the
G-ACh using a dedicated LSP on the same link (interface) which
carries controlled user traffic.
o Out-of-band, aligned topology o Out-of-band, aligned topology
This term is used to refer to the cases where management and/or This term is used to refer to the cases where control plane
control plane traffic is sent using a different communication traffic is sent using a different communication channel from the
channel from the associated data traffic, and the associated data or management traffic, and the control traffic
control/management communication must follow the same node-to- follows the same node-to-node path as either the data or
node path as the data traffic. Such topologies are usually management traffic.
supported using a parallel fiber or other configurations where
multiple data channels are available and one is (dynamically) Such topologies are usually supported using a parallel fiber or
selected as the control channel. other configurations where multiple data channels are available
and one is (dynamically) selected as the control channel. An
example of this case in the context of MPLS-TP is where control
plane traffic is sent along the same node pairs, but not
necessarily the same links (interfaces), as the corresponding
controlled user traffic.
o Out-of-band, independent topology o Out-of-band, independent topology
This term is used to refer to the cases where management and/or This term is used to refer to the cases where control plane
control plane traffic is sent using a different communication traffic is sent using a different communication channel from the
channel from the associated data traffic, and the associated data or management traffic, and the control traffic
control/management communication may follow a path that is may follow a path that is completely independent of the data
completely independent of the data traffic. Such configurations traffic.
do not preclude the use of in-fiber or aligned topology links,
but alignment is not required.
In the context of MPLS-TP, requirement 14 (see Section 2 above) can Such configurations are a superset of the other cases and do not
be met using out-of-band in-fiber or aligned topology types of preclude the use of in-fiber or aligned topology links, but
control. Requirement 15 can only be met by using Out-of-band, alignment is not required. An example of this case in the
independent topology. GMPLS routing and signaling can be used to context of MPLS-TP is where control plane traffic is sent between
support in-band and all of the out-of-band forms of control, see controlling nodes using any available path and links, completely
[RFC3945]. without regard for the path(s) taken by corresponding management
or user traffic.
In the context of MPLS-TP requirements, requirement 14 (see Section 2
above) can be met using out-of-band in-fiber or aligned topology
types of control. Requirement 15 can only be met by using Out-of-
band, independent topology. Some expect the G-ACh to be used
extensively in MPLS-TP networks to support the MPLS-TP control (and
management) planes.
4.1.2. Addressing 4.1.2. Addressing
MPLS-TP reuses and supports the addressing mechanisms supported by MPLS-TP reuses and supports the addressing mechanisms supported by
MPLS. MPLS, and consequently, MPLS-TP uses the IPv4 and IPv6 address MPLS. The MPLS-TP Identifiers document, see [TP-IDENTIFIERS],
provides additional context on how IP addresses are used within MPLS-
TP. MPLS, and consequently, MPLS-TP uses the IPv4 and IPv6 address
families to identify MPLS-TP nodes by default for network management families to identify MPLS-TP nodes by default for network management
and signaling purposes. The control, management and data planes used and signaling purposes. The address spaces and neighbor adjacencies
in an MPLS-TP network may be completely separated or combined at the in the control, management and data planes used in an MPLS-TP network
discretion of an MPLS-TP operator and based on the equipment may be completely separated or combined at the discretion of an MPLS-
capabilities of a vendor. The separation of the control and TP operator and based on the equipment capabilities of a vendor. The
management planes from the data plane allows each plane to be separation of the control and management planes from the data plane
independently addressable. Each plane may use addresses that are not allows each plane to be independently addressable. Each plane may
mutually reachable, e.g., it is likely that the data plane will not use addresses that are not mutually reachable, e.g., it is likely
be able to reach an address from the management or control planes and that the data plane will not be able to reach an address from the
vice versa. Each plane may also use a different address family. It management or control planes and vice versa. Each plane may also use
is even possible to reuse addresses in each plane, but this is not a different address family. It is even possible to reuse addresses
recommended as it may lead to operational confusion. in each plane, but this is not recommended as it may lead to
operational confusion. As previously mentioned, the G-ACh mechanism
defined in [RFC5586] is expected to be used extensively in MPLS-TP
networks to support the MPLS-TP control (and management) planes.
4.1.3. Routing 4.1.3. Routing
Routing support for MPLS-TP LSPs is based on GMPLS routing. GMPLS Routing support for MPLS-TP LSPs is based on GMPLS routing. GMPLS
routing builds on TE routing and has been extended to support routing builds on TE routing and has been extended to support
multiple switching technologies per [RFC3945] and [RFC4202] as well multiple switching technologies per [RFC3945] and [RFC4202] as well
as multiple levels of packet switching (PSC) within a single network. as multiple levels of packet switching (PSC) within a single network.
IS-IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], IS-IS extensions for GMPLS are defined in [RFC5307] and [RFC5316],
which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF
extensions for GMPLS are defined in [RFC4203] and [RFC5392], which extensions for GMPLS are defined in [RFC4203] and [RFC5392], which
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
skipping to change at page 24, line 16 skipping to change at page 28, line 34
which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF
extensions for GMPLS are defined in [RFC4203] and [RFC5392], which extensions for GMPLS are defined in [RFC4203] and [RFC5392], which
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, explicit recovery path computation as well adds bidirectional LSPs, explicit recovery path computation as well
as support for the other functions discussed in this section. as support for the other functions discussed in this section.
Both MPLS and GMPLS path computation allow for the restriction of Both MPLS and GMPLS path computation allow for the restriction of
path selection based on the use of Explicit Route Objects (EROs) and path selection based on the use of Explicit Route Objects (EROs) and
other LSP attributes, see [RFC3209] and [RFC3473]. In all cases, no other LSP attributes, see [RFC3209] and [RFC3473]. In all cases, no
specific algorithm is standardized by the IETF. This is anticipated specific algorithm is standardized by the IETF. This is anticipated
to continue to be the case for MPLS-TP LSPs. to continue to be the case for MPLS-TP LSPs.
4.1.4.1. Relation to PCE 4.1.4.1. Relation to PCE
Path Computation Element (PCE) Based approaches, see [RFC4655], may Path Computation Element (PCE) Based approaches, see [RFC4655], may
be used for path computation of a GMPLS LSP, and consequently an be used for path computation of a GMPLS LSP, and consequently an
MPLS-TP LSP, across domains and in a single domain. In cases where MPLS-TP LSP, across domains and in a single domain. In cases where
the architecture is used, the PCE Communication Protocol (PCECP), see PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440],
[RFC5440], will be used to communicate PCE requests and responses. will be used to communicate PCE requests and responses. MPLS-TP
MPLS-TP specific extensions to PCECP are currently out of scope of specific extensions to PCEP are currently out of scope of the MPLS-TP
the MPLS-TP project and this document. 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., it 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
specific functions in MPLS-TP networks. Specific references are specific functions in MPLS-TP networks. Specific references are
skipping to change at page 25, line 27 skipping to change at page 29, line 46
node pairs. Link bundling for MPLS and GMPLS networks is defined in node pairs. Link bundling for MPLS and GMPLS networks is defined in
[RFC4201]. Link bundling may be used in MPLS-TP networks and its use [RFC4201]. Link bundling may be used in MPLS-TP networks and its use
is at the discretion of the network operator. is at the discretion of the network operator.
4.1.8. Hierarchical LSPs 4.1.8. Hierarchical LSPs
This section reuses text from [HIERARCHY-BIS]. This section reuses text from [HIERARCHY-BIS].
[RFC3031] describes how MPLS labels may be stacked so that LSPs may [RFC3031] describes how MPLS labels may be stacked so that LSPs may
be nested with one LSP running through another. This concept of be nested with one LSP running through another. This concept of
Hierarchical LSPs is formalized in [RFC4206] with a set of protocol Hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of
mechanisms for the establishment of a hierarchical LSP that can carry protocol mechanisms for the establishment of a hierarchical LSP that
one or more other LSPs. can carry one or more other LSPs.
[RFC4206] goes on to explain that a hierarchical LSP may carry other [RFC4206] goes on to explain that a hierarchical LSP may carry other
LSPs only according to their switching types. This is a function of LSPs only according to their switching types. This is a function of
the way labels are carried. In a packet switch capable (PSC) network, the way labels are carried. In a packet switch capable (PSC) network,
the hierarchical LSP can carry other PSC LSPs using the MPLS label the hierarchical LSP can carry other PSC LSPs using the MPLS label
stack. stack.
Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to
be treated as a single hop in the path of another LSP. This mechanism be treated as a single hop in the path of another LSP. This
is known as "non-adjacent signaling." mechanism is also sometimes known as "non-adjacent signaling", see
[RFC4208].
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link
created from an LSP and advertised in the same instance of the created from an LSP and advertised in the same instance of the
control plane that advertises the TE links from which the LSP is control plane that advertises the TE links from which the LSP is
constructed. The LSP itself is called an FA-LSP. constructed. The LSP itself is called an FA-LSP. FA LSPs are
analogous to MPLS-TP Sections as discussed in [RFC5960].
Thus, a hierarchical LSP may form an FA such that it is advertised as Thus, a hierarchical LSP may form an FA such that it is advertised as
a TE link in the same instance of the routing protocol as was used to a TE link in the same instance of the routing protocol as was used to
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.
LSP hierarchy is expected to play an important role in MPLS-TP
networks, particularly in the context of scaling and recovery as well
as supporting SPMEs.
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. End-to-end recovery can be viewed as a special case of recovery. End-to-end recovery can be viewed as a special case of
segment recovery where there is a single recovery domain whose segment recovery where there is a single recovery domain whose
borders coincide with the ingress and egress of the LSP, although borders coincide with the ingress and egress of the LSP, although
specific procedures are defined. specific procedures are defined.
The five defined types of recovery defined in MPLS-TP are: The five defined types of recovery defined in GMPLS are:
- 1+1 bidirectional protection for P2P LSPs - 1+1 bidirectional protection for P2P LSPs
- 1+1 unidirectional protection for P2MP LSPs - 1+1 unidirectional protection for P2MP LSPs
- 1:n (including 1:1) protection with or without extra traffic - 1:n (including 1:1) protection with or without extra traffic
- Rerouting without extra traffic (sometimes known as soft - Rerouting without extra traffic (sometimes known as soft
rerouting), including shared mesh restoration rerouting), including shared mesh restoration
- Full LSP rerouting - Full LSP rerouting
Recovery for MPLS-TP LSPs is signaled using the mechanism defined in Recovery for MPLS-TP LSPs as discussed in [TP-SURVIVE], is signaled
[RFC4872] and [RFC4873]. Note that when MEPs are required for the using the mechanism defined in [RFC4872] and [RFC4873]. Note that
OAM CC function and the MEPs exists at LSP transit nodes, each MEP is when MEPs are required for the OAM CC function and the MEPs exist at
instantiated at a hierarchical LSP end point, and protection is LSP transit nodes, each MEP is instantiated at a hierarchical LSP end
provided end-to-end for the hierarchical LSP. (Protection can be point, and protection is provided end-to-end for the hierarchical
signaled using either [RFC4872] and [RFC4873] defined procedures.) LSP. (Protection can be signaled using either [RFC4872] or [RFC4873]
The use of Notify messages to trigger protection switching and defined procedures.) The use of Notify messages to trigger protection
recovery is not required in MPLS-TP as this function is expected to switching and recovery is not required in MPLS-TP as this function is
be supported via OAM. However, it's use is not precluded. expected to be supported via OAM. However, its use is not precluded.
4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI)
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
[RFC5787] for routing areas in support of E-NNIs. This work may [RFC5787] for routing areas in support of E-NNIs. This work may
require extensions in order to meet the specific needs of an MPLS-TP require extensions in order to meet the specific needs of an MPLS-TP
UNI and E-NNI. UNI and E-NNI.
4.2. OAM, MEP (Hierarchy) Configuration and Control 4.2. OAM, MEP (Hierarchy), MIP Configuration and Control
MPLS-TP is being defined to support a comprehensive set of MPLS-TP MPLS-TP is being defined to support a comprehensive set of MPLS-TP
OAM functions. Specific OAM requirements for MPLS-TP are documented OAM functions. The MPLS-TP control plane will not itself provide OAM
in [RFC5860]. In addition to the actual OAM requirements, it is also functions, but it will be used to instantiate and otherwise control
required that the control plane be able to configure and control OAM MPLS-TP OAM functions.
entities. This requirement is not yet addressed by the existing RFCs,
but such work is now underway, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM- Specific OAM requirements for MPLS-TP are documented in [RFC5860].
EXT]. This document also states that it is also required that the control
plane be able to configure and control OAM entities. This
requirement is not yet addressed by the existing RFCs, but such work
is now underway, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT].
Many OAM functions occur on a per-LSP basis, are typically in-band, Many OAM functions occur on a per-LSP basis, are typically in-band,
and 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 such functions be established and activated via the
data path (i.e., with the same signaling). This way OAM setup is same control plane signaling used to set up the LSP, as this
bound to connection establishment signaling, avoiding two separate effectively synchronizes OAM with the LSP lifetime and avoids the
management/configuration steps (connection setup followed by OAM extra overhead and potential errors associated with separate OAM
configuration) which would increases delay, processing and more configuration mechanisms.
importantly may be prune to misconfiguration errors.
It must be noted that although the control plane is used to establish
OAM maintenance entities, OAM messaging and functions occur
independently from the control plane. That is, in MPLS-TP OAM
mechanisms are responsible for monitoring and initiating recovery
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
interface to the MPLS-TP control plane. That said, MPLS and GMPLS interface to the MPLS-TP control plane. That said, MPLS and GMPLS
support a number of standardized management functions. These include support a number of standardized management functions. These include
the MPLS-TE/GMPLS TE Database Management Information Base (MIB), [TE- the MPLS-TE/GMPLS TE Database Management Information Base (MIB), [TE-
MIB]; the MPLS TE MIB, [RFC3812]; the MPLS LSR MIB, [RFC3813]; the MIB]; the MPLS-TE MIB, [RFC3812]; the MPLS LSR MIB, [RFC3813]; the
GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803]. These MIBs GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803]. These MIBs
may be used in MPLS-TP networks. may be used in MPLS-TP networks.
4.2.1.1. Recovery Triggers 4.2.1.1. Recovery Triggers
The GMPLS control plane allows for management plane recovery triggers The GMPLS control plane allows for management plane recovery triggers
and directly supports control plane recovery triggers. Support for and directly supports control plane recovery triggers. Support for
control plane recovery triggers is defined in [RFC4872] which refers control plane recovery triggers is defined in [RFC4872] which refers
to the triggers as "Recovery Commands". These commands can be used to the triggers as "Recovery Commands". These commands can be used
with both end-to-end and segment recovery, but are always controlled with both end-to-end and segment recovery, but are always controlled
skipping to change at page 28, line 4 skipping to change at page 32, line 28
e. Requested switch for recovery LSP e. Requested switch for recovery LSP
Note that control plane triggers are typically invoked in response to Note that control plane triggers are typically invoked in response to
a management plane request at the ingress. a management plane request at the ingress.
4.2.1.2. Management Plane / Control Plane Ownership Transfer 4.2.1.2. Management Plane / Control Plane Ownership Transfer
In networks where both control plane and management plane are In networks where both control plane and management plane are
provided, LSP provisioning can be bone either by control plane or provided, LSP provisioning can be bone either by control plane or
management plane. As mentioned in the requirements section above, it management plane. As mentioned in the requirements section above, it
must be possible to transfer, or handover, management plane created must be possible to transfer, or handover, a management plane created
LSP to the control plane domain and vice versa. [RFC5493] defines the LSP to the control plane domain and vice versa. [RFC5493] defines the
specific requirements for an LSP ownership handover procedure. It specific requirements for an LSP ownership handover procedure. It
must be possible for the control plane to notify, in a reliable must be possible for the control plane to provide the management
manner, the management plane about the status/result of either plane, in a reliable manner, with the status or result of an
synchronous or asynchronous, with respect to the management plane, operation performed by the management plane. This notification may
operation performed. Moreover it must be possible to monitor, via be either synchronous or asynchronous with respect to the operation.
query or spontaneous notify, the status of the control plane object Moreover, it must be possible for the management plane to monitor the
such as the TE Link status, the available resources, etc. A mechanism status of the control plane, for example the status of a TE Link, its
must be made available by the control plane to the management plane available resources, etc. This monitoring may be based on queries
to log control plane LSP related operation, that is, it must be initiated by the management plane or on notifications generated by
possible from the NMS to have a clear view of the life, (traffic hit, the control plane. A mechanism must be made available by the control
action performed, signaling etc.) of a given LSP. The LSP handover plane to the management plane to log control plane LSP related
procedure for MPLS-TP LSPs is supported via [RFC5852]. operation, that is, it must be possible from the NMS to have a clear
view of the life, (traffic hit, action performed, signaling etc.) of
a given LSP. The LSP handover 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 the existing GMPLS control plane (which builds on
top of the MPLS control plane). Areas where additional the MPLS control plane). Areas where additional specifications are
specifications are required are also identified. The table lists required are also identified. The table lists references based on
references based on the control plane requirements as identified and the control plane requirements as identified and numbered above in
numbered above in section 2. 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] |
skipping to change at page 29, line 16 skipping to change at page 33, line 43
| 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], [RFC5787], [GMPLS-MLN] | | 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] |
| 33 | [RFC3473], [RFC4875] | | 33 | [RFC3473], [RFC4875] |
| 34 | [RFC4875] | | 34 | [RFC4875] |
| 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 36 | [RFC3473], [RFC3209] (Make-before-break) | | 36 | [RFC3473], [RFC3209] (Make-before-break) |
| 37 | [RFC3473], [RFC3209] (Make-before-break) | | 37 | [RFC3473], [RFC3209] (Make-before-break) |
| 38 | [RFC3945], [RFC4202], [RFC5718] | | 38 | |
| 39 | [RFC4139], [RFC4258], [RFC5787] | | 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 | [RFC5493] | | 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] + |
| | implementation of timers | | | implementation of timers |
| 57 | [RFC4872], [RFC4873], [GMPLS-PS] | | 57 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 58 | [RFC4872], [RFC4873] | | 58 | [RFC4872], [RFC4873] |
| 59 | [RFC4872], [RFC4873] | | 59 | [RFC4872], [RFC4873] |
| 60 | [RFC4872], [RFC4873] | | 60 | [RFC4872], [RFC4873] |
| 61 | [RFC4872], [RFC4873], [HIERARCHY-BIS] | | 61 | [RFC4872], [RFC4873], [HIERARCHY-BIS] |
| 62 | [RFC4872], [RFC4873] | | 62 | [RFC4872], [RFC4873] |
| 63 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | | 63 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 64 | [RFC4872], [RFC4873] | | 64 | [RFC4872], [RFC4873] |
| 65 | [RFC4872], [RFC4873] | | 65 | [RFC4872], [RFC4873] |
skipping to change at page 30, line 38 skipping to change at page 35, line 13
| 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 intentionally blank.) | | 102 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 103 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 103 | [RFC4872], [RFC4873], [TP-RING] |
| 104 | [RFC4872], [RFC4873], [TP-RING] | | 104 | [RFC3945], [RFC3473], [HIERARCHY-BIS] |
| 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] |
| 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 115 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 115 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 116 | [RFC3473] | | 116 | [RFC3473] |
| 117 | [RFC4426], [RFC4872], [RFC4873] | | 117 | [RFC4426], [RFC4872], [RFC4873] |
| 118 | [RFC3473], [RFC4872], [RFC4873] | | 118 | [RFC3473], [RFC4872], [RFC4873] |
| 119 | [RFC3473], [RFC4783] | | 119 | [RFC3473], [RFC4783] |
| 120 | [RFC3473] | | 120 | [RFC3473] |
| 121 | [RFC3473], [RFC4783] | | 121 | [RFC3473], [RFC4783] |
| 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 124 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [HIERARCHY-BIS] | | 124 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [HIERARCHY-BIS] |
| 125 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 125 - | |
| 126 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 136 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 137a | [RFC3473] |
| 137b | [RFC3473] + (See Sec. 4.4.7) |
| 138a | [RFC3473] |
| 138b | [RFC3473] + (See Sec. 4.4.7) |
| 139 | PW only requirement, see PW Requirements Table (5.2) |
| 140 - | |
| 144 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) |
+=======+===========================================================+ +=======+===========================================================+
4.4. Anticipated MPLS-TP Related Extensions and Definitions 4.4. Anticipated MPLS-TP Related Extensions and Definitions
This section identifies the extensions and other documents that have This section identifies the extensions and other documents that have
been identified as likely to be needed to support the full set of been identified as likely to be needed to support the full set of
MPLS-TP control plane requirements. MPLS-TP control plane requirements.
4.4.1. MPLS to MPLS-TP Interworking 4.4.1. MPLS-TE to MPLS-TP LSP Control Plane Interworking
While no interworking function is expected in the data-lane to
support the interconnection of MPLS-TE and MPLS-TP networking, this
is not the case for the control plane. MPLS-TE networks typically
use LSP signaling based on [RFC3209] while MPLS-TP LSPs will be
signaled using GMPLS RSVP-TE, i.e., [RFC3473]. The data plane of
[RFC5145] identifies a set of solutions that are aimed to aid in the [RFC5145] identifies a set of solutions that are aimed to aid in the
interworking of MPLS-TE and GMPLS control planes. This work will interworking of MPLS-TE and GMPLS control planes. This work will
serve as the foundation for a formal definition of MPLS to MPLS-TP serve as the foundation for a formal definition of MPLS to MPLS-TP
control plane interworking. control plane interworking.
4.4.2. Associated Bidirectional LSPs 4.4.2. Associated Bidirectional LSPs
GMPLS signaling, [RFC3473], supports unidirectional, and co-routed GMPLS signaling, [RFC3473], supports unidirectional, and co-routed
bidirectional point-to-point LSPs. MPLS-TP also requires support for bidirectional point-to-point LSPs. MPLS-TP also requires support for
associated bidirectional point-to-point LSPs. Such support will associated bidirectional point-to-point LSPs. Such support will
require an extension or a formal definition of how the LSP endpoints require an extension or a formal definition of how the LSP endpoints
supporting an associated bidirectional service will coordinate the supporting an associated bidirectional service will coordinate the
two LSPs used to provide such a service. Per requirement 11, transit two LSPs used to provide such a service. Per requirement 11, transit
nodes that support an associated bidirectional service should be nodes that support an associated bidirectional service should be
aware of the association of the LSPs used to support the service. aware of the association of the LSPs used to support the service when
There are several existing protocol mechanisms on which to base such both LSPs are supported on that transit node. There are several
support, including, but not limited to: existing protocol mechanisms on which to base such support,
including, but not limited to:
o GMPLS calls, [RFC4974]. o GMPLS calls, [RFC4974].
o The ASSOCIATION object, [RFC4872]. o The ASSOCIATION object, [RFC4872].
o The LSP_TUNNEL_INTERFACE_ID object, [HIERARCHY-BIS]. o The LSP_TUNNEL_INTERFACE_ID object, [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 the MPLS-TP
requirement this document will need to become a Standards Track RFC. requirement this document will need to become a Standards Track RFC.
4.4.4. Recovery for P2MP LSPs 4.4.4. Recovery for P2MP LSPs
The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and
[RFC4873], do not explicitly cover their interactions. MPLS-TP [RFC4873], do not explicitly cover their interactions. MPLS-TP
requires a formal definition of recovery techniques for P2MP LSPs. requires a formal definition of recovery techniques for P2MP LSPs.
Such a formal definition will be based on existing RFCs and may not Such a formal definition will be based on existing RFCs and may not
require any new protocol mechanisms, but nonetheless, must be require any new protocol mechanisms, but nonetheless, must be
documented. documented.
skipping to change at page 32, line 35 skipping to change at page 37, line 27
the OAM related control capabilities of GMPLS. These extensions the OAM related control capabilities of GMPLS. These extensions
cover a portion, but not all OAM related control functions that have cover a portion, but not all OAM related control functions that have
been identified in the context of MPLS-TP. As discussed above, the been identified in the context of MPLS-TP. As discussed above, the
MPLS-TP control plane must support the selection of which (if any) MPLS-TP control plane must support the selection of which (if any)
OAM function(s) to use (including support to select experimental OAM OAM function(s) to use (including support to select experimental OAM
functions) and what OAM functionality to run, including, continuity functions) and what OAM functionality to run, including, continuity
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. These documents do not yet cover the
implications of SPMEs, including both dynamic creation and dynamic
OAM function control.
4.4.6. DiffServ Object usage in GMPLS 4.4.6. DiffServ Object usage in GMPLS
[RFC3270] and [RFC4124] defines support for DiffServ enabled MPLS [RFC3270] and [RFC4124] define support for DiffServ enabled MPLS
LSPs. While the document references GMPLS signaling, there is no LSPs. While [RFC4124] references GMPLS signaling, there is no
explicit discussion on the use of the DiffServ related objects in explicit discussion on the use of the DiffServ related objects in
GMPLS signaling. A (possibly Information) document on how GMPLS GMPLS signaling. A (possibly Informational) document on how GMPLS
supports DiffServ LSPs is likely to prove useful in the context of supports DiffServ LSPs is likely to prove useful in the context of
MPLS-TP. MPLS-TP.
4.4.7. Support for MPLS-TP LSP Identifiers
MPLS-TP uses two forms of LSP identifiers, see [TP-IDENTIFIERS]. One
form is based on existing GMPLS fields. The other form is based on
either the globally unique Attachment Interface Identifier (AII)
defined in [RFC5003], or the M.1400 defined the ITU Carrier Code
(ICC). Neither form is currently supported in GMPLS and such
extensions will need to be documented.
4.4.8. Support for MPLS-TP Maintenance Identifiers
MPLS-TP defines several forms of maintenance entity related
identifiers. Both node unique and global forms are defined.
Extensions will be required to GMPLS to support these identifiers.
These extensions may be added to existing works in progress, such as
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent
documents.
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
MPLS[RFC4618], (3) ATM PWs [RFC4816], (4) Frame Relay PWs [RFC4619], MPLS[RFC4618], (3) ATM PWs [RFC4816], (4) Frame Relay PWs [RFC4619],
skipping to change at page 33, line 27 skipping to change at page 38, line 36
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) [RFC3985], and (2) Multi-segment Pseudowires (MS-PW) (SS-PW) [RFC3985], and (2) Multi-segment Pseudowires (MS-PW)
[RFC5659]. An MPLS-TP domain may transparently transport a PW whose [RFC5659]. An MPLS-TP network domain may transparently transport a
endpoints are within a client network. Alternatively, an MPLS-TP PW whose endpoints are within a client network. Alternatively, an
edge node may be the Terminating PE (T-PE) for a PW, performing MPLS-TP edge node may be the Terminating PE (T-PE) for a PW,
adaptation from the native attachment circuit technology (e.g. performing adaptation from the native attachment circuit technology
Ethernet 802.1Q) to an MPLS PW which is then transported in an LSP (e.g. Ethernet 802.1Q) to an MPLS PW which is then transported in an
over an MPLS-TP domain. In this way, the PW is analogous to a LSP over an MPLS-TP network. In this way, the PW is analogous to a
transport channel in a TDM network and the LSP is equivalent to a transport channel in a TDM network and the LSP is equivalent to a
container of multiple non-concatenated channels, albeit they are container of multiple non-concatenated channels, albeit they are
packet containers. The MPLS-TP domain may also contain Switching PEs packet containers. An MPLS-TP network may also contain Switching PEs
(S-PEs) for a multi-segment PW whereby the T-PEs may be at the edge (S-PEs) for a multi-segment PW whereby the T-PEs may be at the edge
of the MPLS-TP domain or in a client network. In this latter case, a of an MPLS-TP network or in a client network. In this latter case, a
T-PE in a client network is a T-PE performing the adaptation of the T-PE in a client network is a T-PE performing the adaptation of the
native service to MPLS and the MPLS-TP domain performs Pseudo-wire native service to MPLS and an MPLS-TP network performs pseudowire
switching. switching.
SS-PW signaling control plane is based on LDP with specific The SS-PW signaling control plane is based on targeted LDP (T-LDP)
procedures defined in [RFC4447]. [RFC5659], [SEGMENTED-PW] and [MS- with specific procedures defined in [RFC4447]. The MS-PW signaling
PW-DYNAMIC] allow for static switching of multi-segment Pseudowires control plane is also based on T-LDP as allowed for in [RFC5659],
in data and control plane and for dynamic routing and placement of an [SEGMENTED-PW] and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the
MS-PW whereby signaling is still based on Targeted LDP (T-LDP). The same PW signaling protocols and procedures for placing SS-PWs and MS-
MPLS-TP domain shall use the same PW signaling protocols and PWs. This will leverage existing technology as well as facilitate
procedures for placing SS-PWs and MS-PWs. This will leverage existing interoperability with client networks with native attachment circuits
technology as well as facilitate interoperability with client or PW segments that are switched across an MPLS-TP network.
networks with native attachment circuits or PW segment that is
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 the existing LDP control plane for Pseudowires can be met using the existing LDP control plane for Pseudowires
(targeted LDP). Areas where additional specifications are required (targeted LDP). Areas where additional specifications are required
are also identified. The table lists references based on the control are also identified. The table lists references based on the control
plane requirements as identified and numbered above in section 2. plane requirements as identified and numbered above in section 2.
In the table below, several of the requirements shown are addressed - In the table below, several of the requirements shown are addressed -
in part or in full - by the use of MPLS-TP LSPs to carry pseudo- in part or in full - by the use of MPLS-TP LSPs to carry pseudowires.
wires. This is reflected by including "TP-LSPs" as a reference for This is reflected by including "TP-LSPs" as a reference for those
those requirements. Section 5.3.2 provides additional context for requirements. Section 5.3.2 provides additional context for the
the binding of PWs to TP-LSPs. binding of PWs to TP-LSPs.
+=======+===========================================================+ +=======+===========================================================+
| Req # | References | | Req # | References |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs | | 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) | | 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) |
| 3 | [RFC3985], [RFC4447] | | 3 | [RFC3985], [RFC4447] |
| 4 | Generic requirement met by using Standards Track RFCs | | 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3985], [RFC4447], Together with TP-LSPs | | 5 | [RFC3985], [RFC4447], Together with TP-LSPs |
| 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs | | 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs |
skipping to change at page 35, line 34 skipping to change at page 40, line 34
| 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation | | 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation |
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] | | 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] |
| | [RFC4842], [RFC5287] | | | [RFC4842], [RFC5287] |
| 28 | [RFC3985] | | 28 | [RFC3985] |
| 29-31 | [RFC3985], [RFC4447] | | 29-31 | [RFC3985], [RFC4447] |
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6. | | 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6. |
| 33 | [RFC4385], [RFC4447], [RFC5586] | | 33 | [RFC4385], [RFC4447], [RFC5586] |
| 34 | [PW-P2MPR], [PW-P2MPE] | | 34 | [PW-P2MPR], [PW-P2MPE] |
| 35 | [RFC4863] | | 35 | [RFC4863] |
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 | | 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 38 | [RFC5586] | | 38 | |
| 39 | Provided by TP-LSPs | | 39 | Provided by TP-LSPs |
| 40 | [RFC3985], [RFC4447], + TP-LSPs | | 40 | [RFC3985], [RFC4447], + TP-LSPs |
| 41 | [RFC3478] | | 41 | [RFC3478] |
| 42-43 | [RFC3985], [RFC4447] | | 42-43 | [RFC3985], [RFC4447] |
| 44-45 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 | | 44-45 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 |
| 46 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs | | 46 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs |
| 47 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 | | 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 | | 49-50 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 51-53 | Provided by TP-LSPs, and Section 5.3.5 | | 51-53 | Provided by TP-LSPs, and Section 5.3.5 |
skipping to change at page 36, line 6 skipping to change at page 41, line 6
| 58-59 | [PW-RED], [PW-REDB] | | 58-59 | [PW-RED], [PW-REDB] |
| 60-82 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 60-82 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 83-84 | [RFC5085], [RFC5586], [RFC5885] | | 83-84 | [RFC5085], [RFC5586], [RFC5885] |
| 85-90 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 85-90 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 91-96 | [RFC3985], [RFC4447], + TP-LSPs, implementation | | 91-96 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 97 | [RFC4447], [MS-PW-DYNAMIC] | | 97 | [RFC4447], [MS-PW-DYNAMIC] |
| 98 | [RFC4447] | | 98 | [RFC4447] |
| 99 - | | | 99 - | |
| 100 | Not Applicable to PW | | 100 | Not Applicable to PW |
| 101 | [RFC4447] | | 101 | [RFC4447] |
| 102 | (Requirement intentionally blank.) | | 102 | [RFC3478] |
| 103 | [RFC3478] | | 103 | [RFC3985], + TP-LSPs |
| 104 | [RFC3985], + TP-LSPs | | 104 | Not Applicable to PW |
| 105 | [PW-OAM] | | 105 | [PW-OAM] |
| 106 | [PW-OAM] | | 106 | [PW-OAM] |
| 107 - | | | 107 - | |
| 109 | [RFC5085], [RFC5586], [RFC5885] | | 109 | [RFC5085], [RFC5586], [RFC5885] |
| 110 | [RFC5085], [RFC5586], [RFC5885] | | 110 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local | | | fault reporting and protection triggering is a local |
| | matter for PW | | | matter for PW |
| 111 | [RFC5085], [RFC5586], [RFC5885] | | 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 |
skipping to change at page 36, line 32 skipping to change at page 41, line 32
| 115 | [RFC5085], [RFC5586], [RFC5885] | | 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], [RFC5885] | | 118 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] |
| 119 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 119 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 120 | [RFC4447] | | 120 | [RFC4447] |
| 121 - | | | 121 - | |
| 126 | [RFC5085], [RFC5586], [RFC5885] | | 126 | [RFC5085], [RFC5586], [RFC5885] |
| 127 - | |
| 131 | [PW-OAM] |
| 132 | Section 5.3.5 |
| 133 | [PW-OAM] |
| 134 | [PW-OAM] |
| 135 | Section 5.3.5 |
| 136 | [PW-OAM] |
| 137 | Not Applicable to PW |
| 138 | Not Applicable to PW |
| 139 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] |
| 140 - | |
| 144 | [PW-OAM] |
+=======+===========================================================+ +=======+===========================================================+
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].
skipping to change at page 37, line 19 skipping to change at page 42, line 29
Plane must be able to operate out-of-band (OOB). This separation Plane must be able to operate out-of-band (OOB). This separation
ensures, among other things, that in the case of control plane ensures, among other things, that in the case of control plane
failures the data plane is not affected and can continue to operate failures the data plane is not affected and can continue to operate
normally. This was not a design requirement for the current PW normally. This was not a design requirement for the current PW
Control Plane. However, due to the PW concept, i.e., PWs are Control Plane. However, due to the PW concept, i.e., PWs are
connecting logical entities ('forwarders'), and the operation of the connecting logical entities ('forwarders'), and the operation of the
PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part 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, in the signaling exchanges: moving T-LDP out-of-band seems to be,
theoretically, a straightforward exercise. 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 outside the scope of this document). The PW (Detailed evaluation is outside the scope of this document). The PW
Label allocation and exchange mechanisms should be reused without Label allocation and exchange mechanisms should be reused without
change. change.
5.3.2. Support for Explicit Control of PW-to-LSP Binding 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 nodes
elements acting as T-PEs and S-PEs or a control plane entity that may acting as T-PEs and S-PEs or a control plane entity that may be the
be the same one signaling the PW. However, an extension of the PW same one signaling the PW. However, an extension of the PW signaling
signaling protocol is required to allow the LSR at signal initiation protocol is required to allow the LSR at signal initiation end to
end to inform the targeted LSR (at the signal termination end) which inform the targeted LSR (at the signal termination end) which LSP the
LSP the resulting PW is to be bound to, in the event that more than resulting PW is to be bound to, in the event that more than one such
one such LSP exists and the choice of LSPs is important to the LSP exists and the choice of LSPs is important to the service being
service being setup (for example, if the service requires co-routed setup (for example, if the service requires co-routed bidirectional
bidirectional paths). This is also particularly important to support paths). This is also particularly important to support transport path
transport path (symmetric and asymmetric) bandwidth requirements. (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 services, it may be required 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, i.e., they both directions of a PW may not follow congruent paths, i.e., they
are associated bidirectional paths. The only requirement in [RFC5659] are associated bidirectional paths. The only requirement in [RFC5659]
is that a PW or a PW segment shares the same T-PEs in both is that a PW or a PW segment shares the same T-PEs in both
directions, and same S-PEs in both directions. 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 PW or PW segment both end points map the PW or PW requiring that both end points map the PW or PW segment to the same
segment to the same transport path for the case where this is an transport path for the case where this is an objective of the
objective of the service. When a bidirectional LSP is selected on service. When a bidirectional LSP is selected on one end to
one end to transport the PW, a mechanism is needed that signals to transport the PW, a mechanism is needed that signals to the remote
the remote end which LSP has been selected locally to transport the end which LSP has been selected locally to transport the PW. This
PW. This would be accomplished by adding a new TLV to PW signaling. would be accomplished by adding a new TLV to PW signaling.
Note that this coincides with the gap identified for OOB support: a Note that this coincides with the gap identified for OOB support: a
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.
The case of unidirectional transport paths may also require The case of unidirectional transport paths may also require
additional protocol mechanisms as today's PWs are always additional protocol mechanisms as today's PWs are always
bidirectional. One potential approach for providing a unidirectional bidirectional. One potential approach for providing a unidirectional
PW based transport path is for the PW to associate different PW based transport path is for the PW to associate different
(asymmetric) bandwidths in each direction, with a zero or minimal (asymmetric) bandwidths in each direction, with a zero or minimal
bandwidth for the return path. bandwidth for the return path. This approach is consistent with
Section 3.8.2 of [RFC5921] but does not address P2MP paths.
5.3.3. Support for Dynamic Transfer of PW Control/Ownership 5.3.3. Support for Dynamic Transfer of PW Control/Ownership
In order to satisfy requirement 47 (as defined in section 2) it will 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 be necessary to specify methods for transfer of PW ownership from the
management to the control plane (and vice versa). management to the control plane (and vice versa).
5.3.4. Interoperable Support for PW/LSP Resource Allocation 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
skipping to change at page 39, line 7 skipping to change at page 44, line 12
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 In conjunction with explicit PW-to-LSP binding, existing mechanisms
may be sufficient, however this needs to be verified in detailed may be sufficient, however this needs to be verified in detailed
evaluation. evaluation.
5.3.5. Support for PW Protection and PW OAM Configuration 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 available features manageable for the PW, including protection
and OAM entities and mechanisms. There is ongoing work on PW
protection and MPLS-TP OAM.
5.3.6. Client Layer Interfaces to Pseudowire Control
Additional work is likely to be required to define consistent access
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)
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
skipping to change at page 39, line 48 skipping to change at page 44, line 37
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). mechanisms yet to be defined).
Automated protection switching is but one of the functions that a Automated protection switching is just one of the functions for which
transport service requires OAM for. OAM is generally referred to as a transport service require OAM. OAM is generally referred to as
either "proactive" or "on-demand", where the distinction is whether a either "proactive" or "on-demand", where the distinction is whether a
specific OAM tool is being used continuously over time (for the specific OAM tool is being used continuously over time (for the
purpose of detecting a need for protection switching, for example) or purpose of detecting a need for protection switching, for example) or
is only used - either a limited number of times, or over a short is only used - either a limited number of times, or over a short
period of time - when explicitly enabled (for diagnostics, for period of time - when explicitly enabled (for diagnostics, for
example). example).
PW OAM currently consists of connectivity verification defined by PW OAM currently consists of connectivity verification defined by
[RFC5085]. Work is currently in progress to extend PW OAM to include [RFC5085]. Work is currently in progress to extend PW OAM to include
bidirectional forwarding detection (BFD) in [RFC5885], and work has bidirectional forwarding detection (BFD) in [RFC5885], and work has
begun on extending BFD to include performance related monitor begun on extending BFD to include performance related monitor
functions. functions.
5.3.6. Client Layer and Cross-Provider Interfaces to PW Control
Additional work is likely to be required to define consistent access
by a client layer network, as well as between provider networks, to
control information available to each type of 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. Such work will
need to fit within the ASON architecture, see requirement 39 above.
5.4. ASON Architecture Considerations
MPLS-TP PWs are always transported using LSPs, and these LSP will
either have been statically provisioned or signaled using GMPLS.
For LSPs signaled using the MPLS-TP LSP control plane (GMPLS),
conformance with the ASON architecture is as described in Section 1.2
("Basic Approach"), bullet 4, of this framework document.
As discussed above in Section 5.3, there are anticipated extensions
in the following areas that may be related to ASON architecture:
- PW-to-LSP binding (Section 5.3.2)
- PW/LSP resource allocation (Section 5.3.4)
- PW protection and OAM configuration (Section 5.3.5)
- Client layer Interfaces for PW control (Section 5.3.6)
This work is expected to be consistent with ASON architecture and may
require additional specification in order to achieve this goal.
6. Security Considerations 6. Security Considerations
This document primarily describes how exiting mechanisms can be used This document primarily describes how existing mechanisms can be used
to meet the MPLS-TP control plane requirements. The documents that to meet the MPLS-TP control plane requirements. The documents that
describe each mechanism contain their own security considerations describe each mechanism contain their own security considerations
sections. For a general discussion on MPLS and GMPLS related sections. For a general discussion on MPLS and GMPLS related
security issues, see the MPLS/GMPLS security framework [MPLS-SEC]. security issues, see the MPLS/GMPLS security framework [RFC5920].
This document also identifies a number of needed control plane This document also identifies a number of needed control plane
extensions. It is expected that the documents that define such extensions. It is expected that the documents that define such
extensions will also include any appropriate security considerations. extensions will also include any appropriate security considerations.
7. IANA Considerations 7. IANA Considerations
There are no new IANA considerations introduced by this document. There are no new IANA considerations introduced by this document.
8. Acknowledgments 8. Acknowledgments
The authors would like to acknowledge the contributions of Yannick The authors would like to acknowledge the contributions of Yannick
Brehon, Diego Caviglia, Nic Neate, and Dave Mcdysan to this work. Brehon, Diego Caviglia, Nic Neate, Dave Mcdysan, Dan Frost, and Eric
Osborne to this work. We also thank Dan Frost in his help responding
to last call comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2210] Wroclawski, J., "The Use of RSVP with Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled Load [RFC2211] Wroclawski, J., "Specification of the Controlled Load
Quality of Service", RFC 2211, September 1997. Quality of Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R Guerin, "Specification [RFC2212] Shenker, S., Partridge, C., and R Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, September of Guaranteed Quality of Service", RFC 2212, September
1997. 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3031] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol
Requirement Levels," RFC 2119. Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen, E., Viswanathan, A., Callon, R.,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
LSP Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
Switching (GMPLS) Signaling Functional Description", (GMPLS) Signaling Functional Description", RFC 3471,
RFC 3471, January 2003. January 2003.
[RFC3473] Berger, L. Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L. Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
RFC 3473, January 2003. 3473, January 2003.
[RFC3478] Leelanivas, M, et al, "Graceful Restart Mechanism for [RFC3478] Leelanivas, M, et al, "Graceful Restart Mechanism for
Label Distribution Protocol", RFC 3478, February 2003. Label Distribution Protocol", RFC 3478, February 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003. 3630, September 2003.
[RFC4124] Le Faucheur, F., Ed. "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., Ed. "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, June Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
2005. 2005.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Support of Generalized Multi-Protocol Label
Switching(GMPLS)", RFC 4202, October 2005. Switching(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
Support of Generalized Multi-Protocol Label Switching of Generalized Multi-Protocol Label Switching (GMPLS)",
(GMPLS)", RFC 4203, October 2005. RFC 4203, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
(LSP) Hierarchy with Generalized Multi-Protocol Label Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
4206, October 2005. October 2005.
[RFC4385] Bryant, S., et al, "Pseudowire Emulation Edge-to-Edge [RFC4385] Bryant, S., et al, "Pseudowire Emulation Edge-to-Edge
(PWE3) Control Word for Use over an MPLS PSN", RFC (PWE3) Control Word for Use over an MPLS PSN", RFC 4385,
4385, February 2006. February 2006.
[RFC4447] Martini, L., Ed., "Pseudowire Setup and Maintenance [RFC4447] Martini, L., Ed., "Pseudowire Setup and Maintenance
Using the Label Distribution Protocol (LDP)", RFC Using the Label Distribution Protocol (LDP)", RFC 4447,
4447, April 2006.
[RFC4448] Martini, L., Ed., "Encapsulation Methods for
Transport Ethernet over MPLS Network", RFC 4448,
April 2006. April 2006.
[RFC4448] Martini, L., Ed., "Encapsulation Methods for Transport
Ethernet over MPLS Network", RFC 4448, April 2006.
[RFC4842] Malis, A., et al, "Synchronous Optical Network/ [RFC4842] Malis, A., et al, "Synchronous Optical Network/
Synchronous Digital Hierarchy (SONET/SDH) Circuit Synchronous Digital Hierarchy (SONET/SDH) Circuit
Emulation over Packet (CEP)", RFC 4842, April 2007. Emulation over Packet (CEP)", RFC 4842, April 2007.
[RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire [RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type",
Type", RFC 4863, May 2007. RFC 4863, May 2007.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
"RSVP-TE Extensions in Support of End-to-End Extensions in Support of End-to-End Generalized Multi-
Generalized Multi- Protocol Label Switching (GMPLS) Protocol Label Switching (GMPLS) Recovery", RFC 4872,
Recovery", RFC 4872, May 2007. May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4929] Andersson, L. and A. Farrel, "Change Process for [RFC4929] Andersson, L. and A. Farrel, "Change Process for
Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC
4929, June 2007. 4929, June 2007.
[RFC4974] Papadimitriou, D., Farrel, A., "Generalized MPLS (GMPLS) [RFC4974] Papadimitriou, D., Farrel, A., "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls", RFC RSVP-TE Signaling Extensions in Support of Calls", RFC
4974, August 2007. 4974, August 2007.
[RFC5063] Satyanarayana, A., Ed., "Extensions to GMPLS Resource [RFC5063] Satyanarayana, A., Ed., "Extensions to GMPLS Resource
Reservation Protocol (RSVP) Graceful Restart", RFC 5063, Reservation Protocol (RSVP) Graceful Restart", RFC 5063,
September 2007. September 2007.
[RFC5287] Vainshtein, A. and Y. Stein, "Control Protocol Extensions [RFC5287] Vainshtein, A. and Y. Stein, "Control Protocol
for the Setup of Time-Division Multiplexing (TDM) Extensions for the Setup of Time-Division Multiplexing
Pseudowires in MPLS Networks", RFC 5287, August 2008. (TDM) Pseudowires in MPLS Networks", RFC 5287, August
2008.
[RFC5305] Smit, H. and T. Li, "IS-IS Extensions for Traffic [RFC5305] Smit, H. and T. Li, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in [RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008. (GMPLS)", RFC 5307, October 2008.
[RFC5316] Chen, M., Zhang, R., and Duan, X., "ISIS Extensions [RFC5316] Chen, M., Zhang, R., and Duan, X., "ISIS Extensions in
in Support of Inter-Autonomous System (AS) MPLS and Support of Inter-Autonomous System (AS) MPLS and GMPLS
GMPLS Traffic Engineering", RFC 5316, December 2008. Traffic Engineering", RFC 5316, December 2008.
[RFC5392] Chen, M., Zhang, R., and Duan, X., "OSPF Extensions [RFC5392] Chen, M., Zhang, R., and Duan, X., "OSPF Extensions in
in Support of Inter-Autonomous System (AS) MPLS and Support of Inter-Autonomous System (AS) MPLS and GMPLS
GMPLS Traffic Engineering", RFC 5392, January 2009. Traffic Engineering", RFC 5392, January 2009.
[RFC5151] Farrel, A., Ed., "Inter-Domain MPLS and GMPLS Traffic [RFC5151] Farrel, A., Ed., "Inter-Domain MPLS and GMPLS Traffic
Engineering -- Resource Reservation Protocol-Traffic Engineering -- Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 5151, February 2008. Engineering (RSVP-TE) Extensions", RFC 5151, February
2008.
[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,
2009. March 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., [RFC5860] Vigoureux, M., Ward, D., Betts, M., "Requirements for
"Requirements for Operations, Administration, and Operations, Administration, and Maintenance (OAM) in
Maintenance MPLS Transport Networks", RFC 5860, May 2010.
(OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[TP-DATA] Frost, D., Bryant, S., Bocci, M., [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., Berger,
"MPLS Transport Profile Data Plane Architecture", work in L., "A Framework for MPLS in Transport Networks", RFC
progress, draft-ietf-mpls-tp-data-plane. 5921, July 2010.
[TP-FWK] Bocci, M., Ed., et al, "A Framework for MPLS in [RFC5960] Frost, D., Bryant, S., Bocci, M., "MPLS Transport
Transport Networks", work in progress, Profile Data Plane Architecture", RFC 5960, August 2010.
draft-ietf-mpls-tp-framework.
[TP-IDENTIFIERS] Bocci, M., Swallow, G., "MPLS-TP Identifiers",
work in progress, draft-ietf-mpls-tp-identifiers.
[TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM [TP-OAM] Busi, I., Ed., 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-SURVIVE] Sprecher, N., et al., "Multiprotocol Label [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label Switching
Switching Transport Profile Survivability Transport Profile Survivability Framework", work in
Framework", work in progress, progress, draft-ietf-mpls-tp-survive-fwk.
draft-ietf-mpls-tp-survive-fwk.
9.2. Informative References 9.2. Informative References
[CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration
Framework and Requirements for GMPLS RSVP-TE", work Framework and Requirements for GMPLS RSVP-TE",
in progress, draft-ietf-ccamp-oam-configuration-fwk. work in progress,
draft-ietf-ccamp-oam-configuration-fwk.
[CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for [CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for
MPLS-TP OAM Configuration", work in progress, MPLS-TP OAM Configuration", work in progress,
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext. draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext.
[GMPLS-MLN] Papadimitriou, D., et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for
Multi-Layer and Multi-Region Networks (MLN/MRN)", work
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.
[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
Placement of Multi Segment Pseudo Wires", Placement of Multi Segment Pseudo Wires", work in
work in progress, draft-ietf-pwe3-dynamic-ms-pw. progress, draft-ietf-pwe3-dynamic-ms-pw.
[ITU.G8080.2006] International Telecommunications Union, [ITU.G8080.2006] International Telecommunications Union,
"Architecture for the automatically switched "Architecture for the automatically switched
optical network (ASON)", ITU- T Recommendation optical network (ASON)", ITU- T Recommendation
G.8080, June 2006. G.8080, June 2006.
[ITU.G8080.2008] International Telecommunications Union, [ITU.G8080.2008] International Telecommunications Union,
"Architecture for the automatically switched "Architecture for the automatically switched
optical network (ASON) Amendment 1", ITU-T optical network (ASON) Amendment 1", ITU-T
Recommendation G.8080 Amendment 1, March 2008. Recommendation G.8080 Amendment 1, March 2008.
[MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and
GMPLS Networks", work in progress,
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
[SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M., [PW-RED] Muley, P., et al, "Pseudowire (PW) Redundancy", work in
"Segmented Pseaudowire", work in progress, progress, draft-ietf-pwe3-redundancy.
draft-ietf-pwe3-segmented-pw.
[TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for [PW-REDB] Muley, P., et al, "Preferential Forwarding Status bit
Point-to-Multipoint MPLS in Transport Networks", definition", work in progress,
draft-fbb-mpls-tp-p2mp-framework. draft-ietf-pwe3-redundancy-bit.
[RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label [PW-OAM] Zhang, F., et al, "LDP Extensions for MPLS-TP PW OAM
Switching (MPLS) Support of Differentiated configuration", work in progress,
Services", RFC 3270, May 2002. 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.
[RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label Switching
(MPLS) Support of Differentiated 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 [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
skipping to change at page 45, line 32 skipping to change at page 51, line 10
[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.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
Switching (GMPLS) Architecture", RFC 3945, October (GMPLS) Architecture", RFC 3945, October 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
Generalized MPLS (GMPLS) Signaling Usage and MPLS (GMPLS) Signaling Usage and Extensions for
Extensions for Automatically Switched Optical Automatically Switched Optical Network (ASON)", RFC4139,
Network (ASON)", RFC4139, July 2005. July 2005.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
"Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
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
the Automatically Switched Optical Network (ASON)", Automatically Switched Optical Network (ASON)", RFC4258,
RFC4258, November 2005. November 2005.
[RFC4379] Kompella, K. and G. Swallow, "Detecting [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Multi-Protocol Label Switched (MPLS) Data Plane Label Switched (MPLS) Data Plane Failures", RFC 4379,
Failures", RFC 4379, February 2006. February 2006.
[RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors, [RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March 2006. Recovery Functional Specification", RFC 4426, March
2006.
[RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and
and Restoration) Terminology for Generalized Restoration) Terminology for Generalized Multi-Protocol
Multi-Protocol Label Switching (GMPLS)", RFC4427, Label Switching (GMPLS)", RFC4427, March 2006.
March 2006.
[RFC4553] Vainshtein, A., Ed., and Stein, YJ., Ed.,"Structure- [RFC4553] Vainshtein, A., Ed., and Stein, YJ., Ed.,"Structure-
Agnostic Time Division Multiplexing (TDM) over Packet Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, June 2006. (SAToP)", RFC 4553, June 2006.
[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
Level Data Link Control (HDLC) over MPLS Networks", Data Link Control (HDLC) over MPLS Networks", RFC 4618,
RFC 4618, September 2006. 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
over Multiprotocol Label Switching (MPLS) Networks", Multiprotocol Label Switching (MPLS) Networks",
September 2006. September 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., Ash, J., [RFC4655] Farrel, A., Vasseur, J.-P., Ash, J., "A Path Computation
"A Path Computation Element (PCE)-Based Architecture", RFC Element (PCE)-Based Architecture", RFC 4655, August
4655, August 2006. 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
Asynchronous Transfer Mode (ATM) Transparent Cell Transfer Mode (ATM) Transparent Cell Transport Service",
Transport Service", RFC 4816, February 2007. RFC 4816, February 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S., [RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S.,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual [RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J.,
Circuit Connectivity Verification (VCCV) : A Control "Attachment Individual Identifier (AII) Types for
Channel for Pseudowires", RFC 5085, December 2007. Aggregation", RFC 5003, September 2007.
[RFC5145] Shiomoto, K., [RFC5036] Andersson, L., I. Minei and B. Thomas, Editors, "LDP
"Framework for MPLS-TE to GMPLS Migration", RFC 5145, March Specification", RFC 5036, October 2007.
2008.
[RFC5440] Vasseur, JP., Le, JL., [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
"Path Computation Element (PCE) Communication Protocol Connectivity Verification (VCCV) : A Control Channel for
(PCEP)", RFC 5440, March 2009. Pseudowires", RFC 5085, December 2007.
[RFC5493] Caviglia, D., et al, "Requirements for the [RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS
Conversion between Permanent Connections and Migration", RFC 5145, March 2008.
Switched Connections in a Generalized Multiprotocol
Label Switching (GMPLS) Network", RFC 5493, April
2009.
[RFC5659] Bocci, M., and Bryant, B., "An Architecture for [RFC5440] Vasseur, JP., Le, JL., "Path Computation Element (PCE)
Multi-Segment Pseudowire Emulation Edge-to-Edge", Communication Protocol (PCEP)", RFC 5440, March 2009.
RFC 5659, October 2009.
[RFC5718] Bellar, D., Farrel, A., "An In-Band Data Communication [RFC5493] Caviglia, D., et al, "Requirements for the Conversion
Network For the MPLS Transport Profile", RFC 5718, January between Permanent Connections and Switched Connections
2010. in a Generalized Multiprotocol Label Switching (GMPLS)
Network", RFC 5493, April 2009.
[RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols [RFC5659] Bocci, M., and Bryant, B., "An Architecture for
Extensions for ASON Routing", RFC 5787, March 2010. Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC
5659, October 2009.
[RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions
for ASON Routing", RFC 5787, March 2010.
[RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., [RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D.,
Bardalai, S., "RSVP-TE Signaling Extension for LSP Bardalai, S., "RSVP-TE Signaling Extension for LSP
Handover from the Management Plane to the Control Plane Handover from the Management Plane to the Control Plane
in a GMPLS-Enabled Transport Network", RFC 5852, April in a GMPLS-Enabled Transport Network", RFC 5852, April
2010. 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) For MPLS "Bidirectional Forwarding Detection (BFD) For MPLS
Label Switched Paths (LSPs)", RFC 5884, June 2010. Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Forwarding Detection (BFD) for the Pseudowire
Virtual Circuit Connectivity Verification (VCCV)", Virtual Circuit Connectivity Verification (VCCV)",
RFC 5885, June 2010. RFC 5885, June 2010.
[PW-RED] Muley, P., et al, "Pseudowire (PW) Redundancy", work in [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
progress, draft-ietf-pwe3-redundancy. Networks", RFC 5920, July 2010.
[PW-REDB] Muley, P., et al, "Preferential Forwarding Status bit
definition", work in progress,
draft-ietf-pwe3-redundancy-bit.
[PW-OAM] Zhang, F., et al, "LDP Extensions for MPLS-TP PW OAM [RFC6001] Papadimitriou, D., et al, "Generalized Multi-Protocol
configuration", work in progress, Label Switching (GMPLS) Protocol Extensions for
draft-zhang-mpls-tp-pw-oam-config. Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC
6001, October 2010.
[PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint [SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M., "Segmented
Pseudo-Wire Encapsulation", work in progress, Pseaudowire", work in progress,
draft-raggarwa-pwe3-p2mp-pw-encaps. draft-ietf-pwe3-segmented-pw.
[PW-P2MPR] Jounay, F., et al, "Requirements for [TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for
Point-to-Multipoint Pseudowire", work in progress, Point-to-Multipoint MPLS in Transport Networks",
draft-ietf-pwe3-p2mp-pw-requirements. draft-fbb-mpls-tp-p2mp-framework.
[TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in [TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in
progress, draft-weingarten-mpls-tp-ring-protection. progress, draft-weingarten-mpls-tp-ring-protection.
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
skipping to change at page 49, line 4 skipping to change at page 54, line 23
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., 117 West Street
Waltham, MA 02451 Waltham, MA 02451
Email: nabil.n.bitar@verizon.com Email: nabil.n.bitar@verizon.com
Eric Gray (editor)
Ericsson
900 Chelmsford Street
Lowell, MA, 01851
Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.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 Generated on: Fri, Oct 15, 2010 2:54:52 PM
Ericsson
900 Chelmsford Street
Lowell, MA, 01851
Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com
Generated on: Thu Jun 17 19:11:25 EDT 2010
 End of changes. 194 change blocks. 
634 lines changed or deleted 895 lines changed or added

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