draft-ietf-ccamp-mpls-tp-cp-framework-00.txt   draft-ietf-ccamp-mpls-tp-cp-framework-01.txt 
Internet Draft Loa Andersson, Ed. (Acreo AB) Internet Draft Loa Andersson, Ed. (Acreo AB)
Category: Informational Lou Berger, Ed. (LabN) Category: Informational Lou Berger, Ed. (LabN)
Expiration Date: September 22, 2010 Luyuan Fang, Ed. (Cisco) Expiration Date: September 22, 2010 Luyuan Fang, Ed. (Cisco)
Nabil Bitar, Ed. (Verizon) Nabil Bitar, Ed. (Verizon)
March 22, 2010 March 22, 2010
MPLS-TP Control Plane Framework MPLS-TP Control Plane Framework
draft-ietf-ccamp-mpls-tp-cp-framework-00.txt draft-ietf-ccamp-mpls-tp-cp-framework-01.txt
Abstract Abstract
The MPLS Transport Profile (MPLS-TP) supports static provisioning The MPLS Transport Profile (MPLS-TP) supports static provisioning
of transport paths via a Network Management System (NMS), and of transport paths via a Network Management System (NMS), and
dynamic provisioning of transport paths via a control plane. This dynamic provisioning of transport paths via a control plane. This
document provides the framework for MPLS-TP dynamic provisioning, document provides the framework for MPLS-TP dynamic provisioning,
and covers control plane addressing, routing, path computation, and covers control plane addressing, routing, path computation,
signaling, traffic engineering,, and path recovery. MPLS-TP uses signaling, traffic engineering,, and path recovery. MPLS-TP uses
GMPLS as the control plane for MPLS-TP LSPs and provides for GMPLS as the control plane for MPLS-TP LSPs and provides for
skipping to change at page 2, line 54 skipping to change at page 2, line 54
4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 26 4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 26
4.2 OAM, MEP (Hierarchy) Configuration and Control ......... 26 4.2 OAM, MEP (Hierarchy) Configuration and Control ......... 26
4.2.1 Management Plane Support ............................... 27 4.2.1 Management Plane Support ............................... 27
4.3 GMPLS and MPLS-TP Requirements Table ................... 28 4.3 GMPLS and MPLS-TP Requirements Table ................... 28
4.4 Anticipated MPLS-TP Related Extensions and Definitions . 31 4.4 Anticipated MPLS-TP Related Extensions and Definitions . 31
4.4.1 MPLS to MPLS-TP Interworking ........................... 31 4.4.1 MPLS to MPLS-TP Interworking ........................... 31
4.4.2 Associated Bidirectional LSPs .......................... 31 4.4.2 Associated Bidirectional LSPs .......................... 31
4.4.3 Asymmetric Bandwidth LSPs .............................. 31 4.4.3 Asymmetric Bandwidth LSPs .............................. 31
4.4.4 Recovery for P2MP LSPs ................................. 32 4.4.4 Recovery for P2MP LSPs ................................. 32
4.4.5 Test Traffic Control and other OAM functions ........... 32 4.4.5 Test Traffic Control and other OAM functions ........... 32
4.4.6 Diffserv Object usage in GMPLS ......................... 32 4.4.6 DiffServ Object usage in GMPLS ......................... 32
5 Pseudowires ............................................ 32 5 Pseudowires ............................................ 32
5.1 General reuse of existing PW control plane mechanisms .. 35 5.1 LDP Functions and Pseudowires .......................... 32
5.2 Signaling .............................................. 35 5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 33
5.3 Recovery (Redundancy) .................................. 35 5.3 Anticipated MPLS-TP Related Extensions ................. 35
6 Network Managment Considerations ....................... 35 5.4 Pseudowire OAM and Recovery (Redundancy) ............... 37
7 Security Considerations ................................ 35 6 Security Considerations ................................ 38
8 IANA Considerations .................................... 36 7 IANA Considerations .................................... 38
9 Acknowledgments ........................................ 36 8 Acknowledgments ........................................ 38
10 References ............................................. 36 9 References ............................................. 38
10.1 Normative References ................................... 36 9.1 Normative References ................................... 38
10.2 Informative References ................................. 38 9.2 Informative References ................................. 41
11 Authors' Addresses ..................................... 43 10 Authors' Addresses ..................................... 46
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 functionalities of a packet transport network as capabilities and functions of a packet transport network as defined
defined by the ITU-T. by the ITU-T.
1.1. Conventions Used In This Document 1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Scope 1.2. Scope
This document covers the control plane functions involved in This document covers the control plane functions involved in
skipping to change at page 6, line 40 skipping to change at page 6, line 40
TE-RTG: OSPF-TE or ISIS-TE TE-RTG: OSPF-TE or ISIS-TE
UNI: User to Network Interface UNI: User to Network Interface
Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs".
These segments are present to support scaling, OAM and MEPs within These segments are present to support scaling, OAM and MEPs within
each provider and across the inter-provider NNI. The MEPs are used each provider and across the inter-provider NNI. The MEPs are used
to collect performance information, support diagnostic functions, and to collect performance information, support diagnostic functions, and
support OAM triggered survivability schemes as discussed in [TP- support OAM triggered survivability schemes as discussed in [TP-
SURVIVE], and each H-LSP may be protected using any of the schemes SURVIVE], and each H-LSP may be protected using any of the schemes
discussed in [TP-SURVIVE]. End-to-end monitoring is supported via discussed in [TP-SURVIVE]. End-to-end monitoring is supported via
MEPs at the End-to-End LSP end-points. Note that segement MEPs end- MEPs at the End-to-End LSP end-points. Note that segment MEPs end-
points are collocated with MIPs of the next higher-layer (e.g., end- points are collocated with MIPs of the next higher-layer (e.g., end-
to-end) LSPs. to-end) LSPs.
|< ------- client signal (IP / MPLS / L2 / PW) ------ >| |< ------- client signal (IP / MPLS / L2 / PW) ------ >|
|< -------- SP1 ----------- >|< ------- SP2 ----- >| |< -------- SP1 ----------- >|< ------- SP2 ----- >|
|< ----------- MPLS-TP End-to-End PW -------- >| |< ----------- MPLS-TP End-to-End PW -------- >|
|< ------- MPLS-TP End-to-End LSP ------- >| |< ------- MPLS-TP End-to-End LSP ------- >|
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 9, line 5 skipping to change at page 9, line 5
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. All nodes (i.e., ingress, egress and intermediate) must be
aware about the pairing relationship of the forward and the aware about the pairing relationship of the forward and the
backward directions belonging to the same co-routed backward directions belonging to the same co-routed
bidirectional transport path [RFC5654, requirement 10]. bidirectional transport path [RFC5654, requirement 10].
10. Edge nodes (i.e., ingress and egress) must be aware about the 10. Edge nodes (i.e., ingress and egress) must be aware of the
pairing relationship of the forward and the backward directions pairing relationship of the forward and the backward directions
belonging to the same associated bidirectional transport path belonging to the same associated bidirectional transport path
[RFC5654, requirement 11]. [RFC5654, requirement 11].
11. Transit nodes should be aware about the pairing relationship of 11. Transit nodes should be aware of the pairing relationship of
the forward and the backward directions belonging to the same the forward and the backward directions belonging to the same
associated bidirectional transport path [RFC5654, requirement associated bidirectional transport path [RFC5654, requirement
12]. 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
skipping to change at page 10, line 23 skipping to change at page 10, line 23
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 support scale gracefully to 25. The MPLS-TP control plane must scale gracefully to support a
support a large number of transport paths, nodes and links. large number of transport paths, nodes and links. That is it
That is it must be able to scale at least as well as control must be able to scale at least as well as control planes in
planes in existing transport technologies with growing and existing transport technologies with growing and increasingly
increasingly complex network topologies as well as with complex network topologies as well as with increasing bandwidth
increasing bandwidth demands, number of customers, and number demands, number of customers, and number of services [RFC 5654,
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
which contain forwarding loops [RFC5654, requirement 29]. which contain forwarding loops [RFC5654, requirement 29].
27. The MPLS-TP control plane must support multiple client layers. 27. The MPLS-TP control plane must support multiple client layers.
(e.g. MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.) [RFC5654, (e.g. MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.) [RFC5654,
requirement 30]. requirement 30].
28. The MPLS-TP control plane must provide a generic and extensible 28. The MPLS-TP control plane must provide a generic and extensible
solution to support the transport of MPLS-TP transport paths solution to support the transport of MPLS-TP transport paths
skipping to change at page 14, line 48 skipping to change at page 14, line 48
69. The MPLS-TP control plane must support restoration priority so 69. The MPLS-TP control plane must support restoration priority so
that an implementation can determine the order in which that an implementation can determine the order in which
transport paths should be restored [RFC5654, requirement 71]. transport paths should be restored [RFC5654, requirement 71].
70. The MPLS-TP control plane must support preemption priority in 70. The MPLS-TP control plane must support preemption priority in
order to allow restoration to displace other transport paths in order to allow restoration to displace other transport paths in
the event of resource constraints [RFC5654, requirement 72 and the event of resource constraints [RFC5654, requirement 72 and
86]. 86].
71. The MPLS-TP control plane may support revertive and non- 71. The MPLS-TP control plane must support revertive and non-
revertive restoration behavior [RFC5654, requirement 73]. revertive restoration behavior [RFC5654, requirement 73].
72. The MPLS-TP control plane must support recovery being triggered 72. The MPLS-TP control plane must support recovery being triggered
by physical (lower) layer fault indications [RFC5654, by physical (lower) layer fault indications [RFC5654,
requirement 74]. requirement 74].
73. The MPLS-TP control plane must support recovery being triggered 73. The MPLS-TP control plane must support recovery being triggered
by OAM [RFC5654, requirement 75]. by OAM [RFC5654, requirement 75].
74. The MPLS-TP control plane must support management plane 74. The MPLS-TP control plane must support management plane
skipping to change at page 15, line 41 skipping to change at page 15, line 41
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
due to link/node failures) or unable to be signaled to the due to link/node failures) or unable to be signaled to the
remote end (e.g. because of a protection state coordination remote end (e.g. because of a protection state coordination
fail) must be dropped [RFC5654, requirement 83]. fail) must be ignored/dropped [RFC5654, requirement 83].
82. The MPLS-TP control plane must permit the testing and 82. The MPLS-TP control plane must permit the testing and
validation of the integrity of the protection/recovery validation of the integrity of the protection/recovery
transport path [RFC5654, requirement 84 A]. transport path [RFC5654, requirement 84 A].
83. The MPLS-TP control plane must permit the testing and 83. The MPLS-TP control plane must permit the testing and
validation of protection/ restoration mechanisms without validation of protection/ restoration mechanisms without
triggering the actual protection/restoration [RFC5654, triggering the actual protection/restoration [RFC5654,
requirement 84 B]. requirement 84 B].
skipping to change at page 18, line 5 skipping to change at page 18, line 5
100. The MPLS-TP control plane is based on the GMPLS control plane 100. The MPLS-TP control plane is based on the GMPLS control plane
for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE [RFC3473] for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE [RFC3473]
and related extensions are used for LSP signaling, and GMPLS and related extensions are used for LSP signaling, and GMPLS
OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing
[TP-FWK, section 3.8.]. [TP-FWK, section 3.8.].
101. The MPLS-TP control plane is based on the MPLS control plane 101. The MPLS-TP control plane is based on the MPLS control plane
for PWs, and more specifically, Targeted LDP (T-LDP) [RFC4447] for PWs, and more specifically, Targeted LDP (T-LDP) [RFC4447]
is used for PW signaling [TP-FWK, section 3.8, paragraph 6]. is used for PW signaling [TP-FWK, section 3.8, paragraph 6].
102. The MPLS-TP LSP control plane must allow for interoperation 102. (Requirement removed from [TP-FWK].)
with the MPLS-TE LSP control plane [TP-FWK, section 3.8.2.,
paragraph 5].
103. The MPLS-TP control plane must ensure its own survivability and 103. The MPLS-TP control plane must ensure its own survivability and
to enable it to recover gracefully from failures and to enable it to recover gracefully from failures and
degradations. These include graceful restart and hot redundant degradations. These include graceful restart and hot redundant
configurations [TP-FWK-06, section 3.8., paragraph 12]. configurations [TP-FWK-06, section 3.8., paragraph 12].
104. The MPLS-TP control plane must support linear, ring and meshed 104. The MPLS-TP control plane must support linear, ring and meshed
protection schemes [TP-FWK-06, section 3.10., paragraph 8]. protection schemes [TP-FWK-06, section 3.10., paragraph 8].
2.3. OAM Framework Derived Requirements 2.3. OAM Framework Derived Requirements
skipping to change at page 18, line 50 skipping to change at page 18, line 48
109. The MPLS-TP control plane must support the choice of which (if 109. The MPLS-TP control plane must support the choice of which (if
any) OAM function(s) to use and to which PW, LSP or Section it any) OAM function(s) to use and to which PW, LSP or Section it
applies [TP-OAM-REQ, section 2.2., paragraph 3]. applies [TP-OAM-REQ, section 2.2., paragraph 3].
110. The MPLS-TP control plane must provide a mechanism to support 110. The MPLS-TP control plane must provide a mechanism to support
the localization of faults and the notification of appropriate the localization of faults and the notification of appropriate
nodes. Such notification should trigger corrective (recovery) nodes. Such notification should trigger corrective (recovery)
actions [TP-OAM-REQ, section 2.2.1., paragraph 1]. actions [TP-OAM-REQ, section 2.2.1., paragraph 1].
111. The MPLS-TP control plane must allow service provider to be 111. The MPLS-TP control plane must allow the service provider to be
informed of a fault or defect affecting the service(s) it informed of a fault or defect affecting the service(s) it
provides, even if the fault or defect is located outside of his provides, even if the fault or defect is located outside of his
domain [TP-OAM-REQ, section 2.2.1., paragraph 2]. domain [TP-OAM-REQ, section 2.2.1., paragraph 2].
112. Information exchange between various nodes involved in the 112. Information exchange between various nodes involved in the
MPLS-TP control plane should be reliable such that, for MPLS-TP control plane should be reliable such that, for
example, defects or faults are properly detected or that state example, defects or faults are properly detected or that state
changes are effectively known by the appropriate nodes [TP-OAM- changes are effectively known by the appropriate nodes [TP-OAM-
REQ, section 2.2.1., paragraph 3]. REQ, section 2.2.1., paragraph 3].
skipping to change at page 20, line 50 skipping to change at page 21, line 5
4., paragraph 5]. 4., paragraph 5].
125. The MPLS-TP control plane must support the signaling of the MEP 125. The MPLS-TP control plane must support the signaling of the MEP
identifier used in CC and CV [TP-OAM, section 5.1., paragraph identifier used in CC and CV [TP-OAM, section 5.1., paragraph
4]. 4].
126. The MPLS-TP control plane must support the signaling of the 126. The MPLS-TP control plane must support the signaling of the
transmission period used in CC and CV [TP-OAM, section 5.1., transmission period used in CC and CV [TP-OAM, section 5.1.,
paragraph 6]. paragraph 6].
127. [NOTE: Need to review NM frawework for derived requirments]
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 on
[MPLS-SEC] and that document applies equally to MPLS-TP. [MPLS-SEC] and that document applies equally to MPLS-TP.
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 [TP-FWK].
skipping to change at page 26, line 39 skipping to change at page 26, line 39
messages to trigger protection switching and recovery is not required messages to trigger protection switching and recovery is not required
in MPLS-TP as this function is expected to be supported via OAM. in MPLS-TP as this function is expected to be supported via OAM.
However, it's use is not precluded. However, it's use is not precluded.
4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI)
The majority of GMPLS control plane related RFCs define the control The majority of GMPLS control plane related RFCs define the control
plane from the context of an internal network-to-network interface plane from the context of an internal network-to-network interface
(I-NNI). In the MPLS-TP context, some operators may choose to deploy (I-NNI). In the MPLS-TP context, some operators may choose to deploy
signaled interfaces across user-to-network (UNI) interfaces and signaled interfaces across user-to-network (UNI) interfaces and
across interprovider, external network-to-network (E-NNI), across inter-provider, external network-to-network (E-NNI),
interfaces. Such support is embodied in [RFC4208] for UNIs and interfaces. Such support is embodied in [RFC4208] for UNIs and
[GMPLS-ASON] for routing areas in support of E-NNIs. This work may [GMPLS-ASON] for routing areas in support of E-NNIs. This work may
require extensions in order to meet the specific needs of an MPLS-TP require extensions in order to meet the specific needs of an MPLS-TP
UNI and E-NNI. UNI and E-NNI.
4.2. OAM, MEP (Hierarchy) Configuration and Control 4.2. OAM, MEP (Hierarchy) Configuration and Control
MPLS-TP is being defined to support a comprehensive set of MPLS-TP MPLS-TP is being defined to support a comprehensive set of MPLS-TP
OAM functions. Specific OAM requirements for MPLS-TP are documented OAM functions. Specific OAM requirements for MPLS-TP are documented
in [TP-OAM-REQ]. In addition to the actual OAM requirements, it is in [TP-OAM-REQ]. In addition to the actual OAM requirements, it is
skipping to change at page 28, line 5 skipping to change at page 28, line 5
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, 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 notify, in a reliable
manner, the management plane about the status/result of either manner, the management plane about the status/result of either
synchronous or asynchronous, with respect to the management plane, synchronous or asynchronous, with respect to the management plane,
operation performed. Moreover it must be possible to monitor, via operation performed. Moreover it must be possible to monitor, via
query or spontaneous notify, the status of the control plane object query or spontaneous notify, the status of the control plane object
such as the TE Link status, the available resources, etc. A mechanism such as the TE Link status, the available resources, etc. A mechanism
must be made available by the control plane to the management plane must be made available by the control plane to the management plane
to log control plane LSP related operation, that is, it must be to log control plane LSP related operation, that is, it must be
possible from the NMS to have a clear view of the life, (traffic hit, possible from the NMS to have a clear view of the life, (traffic hit,
skipping to change at page 28, line 34 skipping to change at page 28, line 34
specifications are required are also identified. The table lists specifications are required are also identified. The table lists
references based on the control plane requirements as identified and references based on the control plane requirements as identified and
numbered above in section 2. numbered above in section 2.
+=======+===========================================================+ +=======+===========================================================+
| Req # | References | | Req # | References |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs | | 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 3 | [RFC5145] + Formal Definition (See Section 4.4.1) | | 3 | [RFC5145] + Formal Definition (See Section 4.4.1) |
| 4 | [Generic requirement met by using Standards Track RFCs | | 4 | [Generic requirement met by using Standards Track RFCs] |
| 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 6 | [RFC3471], [RFC3473], [RFC4875] | | 6 | [RFC3471], [RFC3473], [RFC4875] |
| 7 | [RFC3471], [RFC3473] + | | 7 | [RFC3471], [RFC3473] + |
| | Associated bidirectional LSPs (See Section 4.4.2) | | | Associated bidirectional LSPs (See Section 4.4.2) |
| 8 | [RFC4875] | | 8 | [RFC4875] |
| 9 | [RFC3473] | | 9 | [RFC3473] |
| 10 | Associated bidirectional LSPs (See Section 4.4.2) | | 10 | Associated bidirectional LSPs (See Section 4.4.2) |
| 11 | Associated bidirectional LSPs (See Section 4.4.2) | | 11 | Associated bidirectional LSPs (See Section 4.4.2) |
| 12 | [RFC3473] | | 12 | [RFC3473] |
| 13 | [RFC5467] (Currently Experimental, See Section 4.4.3) | | 13 | [RFC5467] (Currently Experimental, See Section 4.4.3) |
skipping to change at page 29, line 25 skipping to change at page 29, line 25
| 31 | [RFC3945], [RFC3471], [RFC4202] | | 31 | [RFC3945], [RFC3471], [RFC4202] |
| 32 | [RFC4208], [RFC4974], [GMPLS-ASON], [GMPLS-MLN] | | 32 | [RFC4208], [RFC4974], [GMPLS-ASON], [GMPLS-MLN] |
| 33 | [RFC3473], [RFC4875] | | 33 | [RFC3473], [RFC4875] |
| 34 | [RFC4875] | | 34 | [RFC4875] |
| 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 36 | [RFC3473], [RFC3209] (Make-before-break) | | 36 | [RFC3473], [RFC3209] (Make-before-break) |
| 37 | [RFC3473], [RFC3209] (Make-before-break) | | 37 | [RFC3473], [RFC3209] (Make-before-break) |
| 38 | [RFC3945], [RFC4202], [RFC5718] | | 38 | [RFC3945], [RFC4202], [RFC5718] |
| 39 | [RFC4139], [RFC4258], [GMPLS-ASON] | | 39 | [RFC4139], [RFC4258], [GMPLS-ASON] |
| 40 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 40 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 41 | [RFC3473] | | 41 | [RFC3473], [RFC5063] |
| 42 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] | | 42 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] |
| 43 | [RFC3945], [RFC3471], [RFC4202] | | 43 | [RFC3945], [RFC3471], [RFC4202] |
| 44 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 44 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 45 | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 45 | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 46 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 46 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 47 | [PC-SCP] | | 47 | [PC-SCP] |
| 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] |
skipping to change at page 30, line 28 skipping to change at page 30, line 28
| 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 85 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 85 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 86 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 86 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 87 | [RFC4872], [RFC4873] | | 87 | [RFC4872], [RFC4873] |
| 88 | [RFC4872], [RFC4873] | | 88 | [RFC4872], [RFC4873] |
| 89 | [RFC4872], [RFC4873], [TP-RING] | | 89 | [RFC4872], [RFC4873], [TP-RING] |
| 90 | [RFC4872], [RFC4873], [TP-RING] | | 90 | [RFC4872], [RFC4873], [TP-RING] |
| 91 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | | 91 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 92 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 92 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 93 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] | | 93 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] |
| 94 | Generic requirement on data plane (correct implmentation) | | 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 | [RFC3473] (See Section 3) | | 97 | PW only requirement, see PW Requirements Table (5.2) |
| 98 | [RFC3473] (See Section 3) | | 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 | | 101 | PW only requirement, see PW Requirements Table (5.2) |
| 102 | [RFC5145] + Formal Definition (See Section 4.4.1) | | 102 | (Requirement removed.) |
| 103 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 103 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 104 | [RFC4872], [RFC4873], [TP-RING] | | 104 | [RFC4872], [RFC4873], [TP-RING] |
| 105 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 105 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 106 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 106 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 109 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 109 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 110 | [RFC3473], [RFC4872], [RFC4873] | | 110 | [RFC3473], [RFC4872], [RFC4873] |
| 111 | [RFC3473], [RFC4872], [RFC4873] | | 111 | [RFC3473], [RFC4872], [RFC4873] |
| 112 | [RFC3473], [RFC4783] | | 112 | [RFC3473], [RFC4783] |
skipping to change at page 31, line 11 skipping to change at page 31, line 11
| 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 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 126 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 126 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 127 | TBD |
+=======+===========================================================+ +=======+===========================================================+
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 to MPLS-TP Interworking
skipping to change at page 32, line 29 skipping to change at page 32, line 29
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.
4.4.6. Diffserv Object usage in GMPLS 4.4.6. DiffServ Object usage in GMPLS
[RFC3270] and [RFC4124] defines support for DiffServ enabled MPLS [RFC3270] and [RFC4124] defines support for DiffServ enabled MPLS
LSPs. While the document references GMPLS signaling, there is no LSPs. While the document references GMPLS signaling, there is no
explicit discussion of discussion on the use of the DiffServ related explicit discussion of discussion on the use of the DiffServ related
objects in GMPLS signaling. A (possibly Information) document on how objects in GMPLS signaling. A (possibly Information) document on how
GMPLS supports DiffServ LSPs is likely to prove useful in the context GMPLS supports DiffServ LSPs is likely to prove useful in the context
of MPLS-TP. of MPLS-TP.
5. Pseudowires 5. Pseudowires
[Editor's note: This section is preliminary and will be 5.1. LDP Functions and Pseudowires
edited/replaced in future versions.]
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],
and (5) circuit Emulation PWs [RFC4553]. and (5) circuit Emulation PWs [RFC4553].
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 types of PWs: (1) Single-Segment pseudowires (SS-PW), There are two general classes of PWs: (1) Single-Segment Pseudowires
and (2) Multi-segment pseudowires (MS-PW) [SEGMENTED-PW]. An MPLS-TP (SS-PW), and (2) Multi-segment Pseudowires (MS-PW) [SEGMENTED-PW].
domain may transparently transport a PW whose endpoints are within a An MPLS-TP domain may transparently transport a PW whose endpoints
client network. Alternatively, an MPLS-TP edge node may be the are within a client network. Alternatively, an MPLS-TP edge node may
Terminating PE (T-PE) for a PW, performing adaptation from the native be the Terminating PE (T-PE) for a PW, performing adaptation from the
attachment circuit technology (e.g. Ethernet 802.1q) to an MPLS PW native attachment circuit technology (e.g. Ethernet 802.1q) to an
for transport over an MPLS-TP domain, with a GMPLS LSP or a hierarchy MPLS PW for transport over an MPLS-TP domain, with a GMPLS LSP or a
of LSPs transporting the PW between the T-PEs. In this way, the PW is hierarchy of LSPs transporting the PW between the T-PEs. In this way,
analogous to a transport channel in a TDM network and the LSP is the PW is analogous to a transport channel in a TDM network and the
equivalent to a container of multiple non-concatenated channels, LSP is equivalent to a container of multiple non-concatenated
albeit they are packet containers. The MPLS-TP domain may also channels, albeit they are packet containers. The MPLS-TP domain may
contain Switching PEs (S-PEs) for a multi-segment PW whereby the T- also contain Switching PEs (S-PEs) for a multi-segment PW whereby the
PEs may be at the edge of the MPLS-TP domain or in a client network. T-PEs may be at the edge of the MPLS-TP domain or in a client
In this latter case, a T-PE in a client network is a T-PE performing network. In this latter case, a T-PE in a client network is a T-PE
the adaptation of the native service to MPLS and the MPLS-TP domain performing the adaptation of the native service to MPLS and the MPLS-
performs Pseudo-wire switching. TP domain performs Pseudo-wire switching.
SS-PW signaling control plane is based on LDP with specific SS-PW signaling control plane is based on LDP with specific
procedures defined in [RFC4447]. [RFC5659], [SEGMENTED-PW] and [MS- procedures defined in [RFC4447]. [RFC5659], [SEGMENTED-PW] and [MS-
PW-DYNAMIC] allow for static switching of multi-segment pseudowires PW-DYNAMIC] allow for static switching of multi-segment Pseudowires
in data and control plane and for dynamic routing and placement of an in data and control plane and for dynamic routing and placement of an
MS-PW whereby signaling is still based on Targeted LDP (T-LDP). The MS-PW whereby signaling is still based on Targeted LDP (T-LDP). The
MPLS-TP domain shall use the same PW signaling protocols and MPLS-TP domain shall use the same PW signaling protocols and
procedures for placing SS-PWs and MS-PWs. This will leverage existing procedures for placing SS-PWs and MS-PWs. This will leverage existing
technology as well as facilitate interoperability with client technology as well as facilitate interoperability with client
networks with native attachment circuits or PW segment that is networks with native attachment circuits or PW segment that is
switched across the MPLS-TP domain. switched across the MPLS-TP domain.
The same control protocol and procedures are reused as much as 5.2. PW Control (LDP) and MPLS-TP Requirements Table
The following table shows how the MPLS-TP control plane requirements
can be met using existing the LDP control plane for Pseudowires
(targeted LDP). Areas where additional specifications are required
are also identified. The table lists references based on the control
plane requirements as identified and numbered above in section 2.
Requirements with no specific relevance to pseudowire control, are
already included in the GMPLS and MPLS-TP Requirements Table (section
4.3), and are omitted from this table.
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 3 | [RFC3985], [RFC4447], [RFC5317] |
| 4 | [Generic requirement met by using Standards Track RFCs] |
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] |
| | [RFC4842], [RFC5287] |
| 33 | [RFC4385], [RFC4447], [RFC5586] |
| 35 | [RFC4863] |
| 41 | [RFC3478] |
| 43 | [RFC3985], [RFC4447] |
| 48 | [PW-RED], [PW-REDB] |
| 57 | [PW-RED], [PW-REDB] |
| | revertive/non-revertive behavior is a local matter for PW |
| 58 | [PW-RED], [PW-REDB] |
| 59 | [PW-RED], [PW-REDB] |
| 72 | [PW-RED], [PW-REDB] |
| | recovery triggering is a local matter for PW |
| 83 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 84 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 97 | [RFC4447], [MS-PW-DYNAMIC] |
| 98 | [RFC4447] |
| 101 | [RFC4447] |
| 105 | TBD |
| 106 | TBD |
| 107 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 108 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 109 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 110 | [RFC5085], [RFC5586], [VCCV-BFD] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 111 | [RFC5085], [RFC5586], [VCCV-BFD] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 112 | [RFC4447] |
| 113 | [RFC4447], [RFC5085], [RFC5586], [VCCV-BFD] |
| 114 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 115 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 116 | path traversed by PW is determined by LSP path, see |
| | GMPLS and MPLS-TP Requirements Table, 4.3 |
| 117 | [PW-RED], [PW-REDB], administrative control of redundant |
| | PW is a local matter at the PW head-end |
| 118 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [VCCV-BFD] |
| 121 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 122 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 123 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 124 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 125 | [RFC5085], [RFC5586], [VCCV-BFD] |
| 126 | [RFC5085], [RFC5586], [VCCV-BFD] |
+=======+===========================================================+
5.3. Anticipated MPLS-TP Related Extensions
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 identifies areas where extensions control mechanisms. This section clarifies the areas where extensions
are needed based on the PW Control Plane related requirements are needed based on the PW Control Plane related requirements
documented in [RFC5654]. documented in [RFC5654].
See the table in the section above for a list of how requirements
defined in [RFC5654] are expected to be addressed.
The baseline requirement for extensions to support transport The baseline requirement for extensions to support transport
applications is that any new mechanisms and capabilities must be able applications is that any new mechanisms and capabilities must be able
to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3
[RFC3985] control and data planes where appropriate. Hence, [RFC3985] control and data planes where appropriate. Hence,
extensions of the PW Control Plane must be in-line with the extensions of the PW Control Plane must be in-line with the
procedures defined in [RFC4447]], [SEGMENTED-PW] and [MS-PW-DYNAMIC]. procedures defined in [RFC4447]], [SEGMENTED-PW] and [MS-PW-DYNAMIC].
For MPLS-TP, it is required that the data and control planes are both For MPLS-TP, it is required that the data and control planes are both
logically and physically separated. That is, the PW Control Plane logically and physically separated. That is, the PW Control Plane
must be able to operate out-of-band (OOB). This separation ensures must be able to operate out-of-band (OOB). This separation ensures
that in the case of control plane failures the data plane is not that in the case of control plane failures the data plane is not
affected and can continue to operate normally. This was not a design affected and can continue to operate normally. This was not a design
requirement for the current PW Control Plane. However, due to the PW requirement for the current PW Control Plane. However, due to the PW
concept, i.e., PWs are connecting logical entities ('forwarders'), concept, i.e., PWs are connecting logical entities ('forwarders'),
and the operation of the PW control protocol, i.e., only edge PE and the operation of the PW control protocol, i.e., only edge PE
nodes (T-PE, S-PE) take part in the signaling exchanges: moving T-LDP nodes (T-PE, S-PE) take part in the signaling exchanges: moving T-LDP
out-of-band seems to be, theoretically, a straightforward exercise. out-of-band seems to be, theoretically, a straightforward exercise.
In fact, as a strictly local matter, ensuring that Targeted LDP (T-
LDP) uses out-of-band signaling requires only that the local
implementation is configured in such a way that reachability for a
target LSR address is via the out-of-band channel.
More precisely, if IP addressing is used in the MPLS-TP control plane More precisely, if IP addressing is used in the MPLS-TP control plane
then T-LDP addressing can be maintained, although all addresses will then T-LDP addressing can be maintained, although all addresses will
refer to control plane entities. Both, the PWid FEC and Generalized refer to control plane entities. Both, the PWid FEC and Generalized
PWid FEC Elements can possibly be used in an OOB case as well PWid FEC Elements can possibly be used in an OOB case as well
(Detailed evaluation is FFS). The PW Label allocation and exchange (Detailed evaluation is FFS). The PW Label allocation and exchange
mechanisms can be possibly reused unchanged (Detailed evaluation is mechanisms should be reused without change.
FFS). Binding a PW to an LSP, or PW segments to LSPs can be left to
networks elements acting as T-PEs and S-PEs or a control plane entity
that may be the same one signaling the PW. If the control plane is
physically separated from the forwarder, the control plane must be
able to program the forwarders with necessary information.
For transport applications, it is mandatory that bidirectional Binding a PW to an LSP, or PW segments to LSPs is left to networks
traffic is following congruent paths. Today, each direction of a PW elements acting as T-PEs and S-PEs or a control plane entity that may
or a PW segment is bound to a unidirectional LSP that extends between be the same one signaling the PW. However, an extension of the PW
two T-PEs, S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in signaling protocol is required to allow the LSR at signal initiation
both directions are not required to follow congruent paths, and end to inform the targeted LSR (at the signal termination end) which
therefore both directions of a PW may not follow congruent paths. The LSP the resulting PW is to be bound to, in the event that more than
only requirement today is that a PW or a PW segment shares the same one such LSP exists and the choice of LSPs is important to the
T-PEs in both directions, and same S-PEs in both directions. This service being setup (for example, if the service requires co-routed
poses a new requirement on the PW Control Plane, namely to ensure bi-directional paths).
that both ends map the PW to the same transport path. When a
If the control plane is physically separated from the forwarder, the
control plane must be able to program the forwarders with necessary
information.
For transport servics, it may be mandatory that bidirectional traffic
follows congruent paths. Currently, each direction of a PW or a PW
segment is bound to a unidirectional LSP that extends between two T-
PEs, S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in both
directions are not required to follow congruent paths, and therefore
both directions of a PW may not follow congruent paths. The only
current requirement is that a PW or a PW segment shares the same T-
PEs in both directions, and same S-PEs in both directions.
MPLS-TP imposes new requirements on the PW Control Plane, in
requiring that both ends map the PW to the same transport path for
the case where this is an objective of the service. When a
bidirectional LSP is selected on one end to transport the PW, a bidirectional LSP is selected on one end to transport the PW, a
mechanism is needed that signals to the remote end which LSP has been mechanism is needed that signals to the remote end which LSP has been
selected locally to transport the PW. This likely can be accomplished selected locally to transport the PW. This would be accomplished by
by adding a new TLV to PW signaling. This coincides with the gap adding a new TLV to PW signaling.
identified for OOB support: a new mechanism may be needed to
explicitly bind PWs to the supporting transport LSP. 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
supporting transport LSP.
Alternatively, two unidirectional LSPs may be used to support the PW. Alternatively, two unidirectional LSPs may be used to support the PW.
However, to meet the congruency requirement, the LSPs must be placed However, to meet the congruency requirement, the LSPs must be placed
so that they are forced to follow the same path (switches and links). so that they are forced to follow the same path (switches and links).
This maybe accomplished by placing one unidirectional TE-LSP in one This may be accomplished by placing one unidirectional TE-LSP in one
direction at one endpoint, and forcing the other endpoint to setup a direction at one endpoint, and forcing the other endpoint to setup a
TE-LSP with an ERO that has the nodes/links in the reverse order from TE-LSP with an ERO that has the nodes/links in the reverse order from
the RRO seen in the path message of the LSP in the reverse direction. the RRO seen in the path message of the LSP in the reverse direction.
In this case, when one endpoint selects an LSP to bind the PW to, it In this case, when one endpoint selects an LSP to bind the PW to, it
must identify to the remote end which LSP to bind the other direction must identify to the remote end which LSP to bind the other direction
of the PW to. of the PW to.
Transport applications require resource guarantees. In the case of Transport applications may require resource guarantees. For such
transport LSPs, resource reservation mechanisms are provided via transport LSPs, resource reservation mechanisms are provided via
RSVP-TE and the use of DiffServ. If multiple PWs are multiplexed into RSVP-TE and the use of DiffServ. If multiple PWs are multiplexed into
the same transport LSP resources, contention may occur. However, the same transport LSP resources, contention may occur. However,
local policy at PEs may ensure proper resource sharing among PWs local policy at PEs should ensure proper resource sharing among PWs
mapped into a resource guaranteed LSP. In the case of MS-PWs, mapped into a resource guaranteed LSP. In the case of MS-PWs,
signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable
admission control of a PW segment over a resource-guaranteed LSP. admission control of a PW segment over a resource-guaranteed LSP.
The PW control plane must be able to establish and configure all of The PW control plane must be able to establish and configure all of
the available features manageable for the PW, including protection the available features manageable for the PW, including protection
and OAM entities and mechanisms. There is ongoing work on PW and OAM entities and mechanisms. There is ongoing work on PW
protection and MPLS-TP OAM. protection and MPLS-TP OAM.
To summarize, the main areas identified for potential PW Control To summarize, the main areas identified for potential PW Control
Plane extensions to support MPLS-TP are the following. Plane extensions to support MPLS-TP are the following.
o Move PW Control Plane out-of-band o Provide necessary extensions to support out-of-band PW Control.
o Explicit control of PW to LSP binding o Provide mechanisms to allow explicit control of PW to LSP binding
o PW QoS o Verify that existing mechanisms allow necessary interoperable
support for PW/LSP resource allocation.
o PW protection o Provide necessary extensions to support PW protection.
o PW OAM configuration and control o Define necessary mechanisms/extensions for PW OAM configuration
and control.
5.1. General reuse of existing PW control plane mechanisms 5.4. Pseudowire OAM and Recovery (Redundancy)
5.2. Signaling Many of the requirements listed in section 2 are intended to support
connectivity and performance monitoring (grouped together as OAM) and
protection conformant with the transport services model.
5.3. Recovery (Redundancy) In general, protection of MPLS-TP transported services is provided by
way of protection of transport LSPs. PW protection requires that
mechanisms be defined to support redundant pseudowires, including a
mechanism already described above for associating such pseudowires
with specific protected ("working" and "protection") LSPs. Also
required are definitions of local protection control functions, to
include test/verification operations, and protection status signals
needed to ensure that PW termination points are in agreement as to
which of a set of redundant pseudowires are in use for which
transport services at any given point in time.
6. Network Managment Considerations Much of this work is currently being done in drafts [PW-RED] and [PW-
REDB] that define - respectively - how to establish redundant
pseudowires and how to indicate which is in use. Additional work may
be required.
[Editor's note: TBD] Protection switching may be triggered manually by the operator, or as
a result of loss of connectivity (detected using the mechanisms of
[RFC5085] and [RFC5586]), or service degradation (detected using
mechanisms yet to be defined in [VCCV-BFD] and elsewhere).
7. Security Considerations Automated protection switching is but one of the functions that a
transport service requries OAM for. OAM is generally classed as
either "proactive" or "on-demand", where the distinction is whether a
specific OAM tool is being used continuously over time (for the
purpose of detecting a need for protection switching, for example) or
is only used - either a limited number of times, or over a short
period of time - when explicitly enabled (for diagnostics, for
example).
This primarily document describes how exiting mechanisms can be used PW OAM currently consists of connectivity verification defined by
[RFC5085]. Work is currently in progress to extend PW OAM to include
bi-directional forwarding detection (BFD) in [VCCV-BFD], and work has
begun on extending BFD to include performance related monitor
functions.
6. Security Considerations
This document primarily describes how exiting mechanisms can be used
to meet the MPLS-TP control plane requirements. The documents that to meet the MPLS-TP control plane requirements. The documents that
describe each mechanism contain their own security considerations describe each mechanism contain their own security considerations
sections. For a general discussion on MPLS and GMPLS related sections. For a general discussion on MPLS and GMPLS related
security issues, see the MPLS/GMPLS security framework [MPLS-SEC]. security issues, see the MPLS/GMPLS security framework [MPLS-SEC].
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.
8. 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.
9. 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, and Dave Mcdysan to this work.
10. References 9. References
10.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.
skipping to change at page 36, line 46 skipping to change at page 39, line 20
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label [RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003. RFC 3471, 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",
January 2003. RFC 3473, January 2003.
[RFC3478] Leelanivas, M, et al, "Graceful Restart Mechanism for
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 3630, Engineering (TE) Extensions to OSPF Version 2", RFC
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 of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label (LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC Switching (GMPLS) Traffic Engineering (TE)", RFC
4206, October 2005. 4206, October 2005.
[RFC4385] Bryant, S., et al, "Pseudowire Emulation Edge-to-Edge
(PWE3) Control Word for Use over an MPLS PSN", RFC
4385, 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, April 2006. 4447, April 2006.
[RFC4448] Martini, L., Ed., "Encapsulation Methods for [RFC4448] Martini, L., Ed., "Encapsulation Methods for
Transport Ethernet over MPLS Network", RFC 4448, Transport Ethernet over MPLS Network", RFC 4448,
April 2006. April 2006.
[RFC4842] Malis, A., et al, "Synchronous Optical Network/
Synchronous Digital Hierarchy (SONET/SDH) Circuit
Emulation over Packet (CEP)", RFC 4842, April 2007.
[RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire
Type", RFC 4863, May 2007.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D.,
"RSVP-TE Extensions in Support of End-to-End "RSVP-TE Extensions in Support of End-to-End
Generalized Multi- Protocol Label Switching (GMPLS) Generalized Multi- Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007. Recovery", RFC 4872, 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
skipping to change at page 37, line 51 skipping to change at page 40, line 37
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
for the Setup of Time-Division Multiplexing (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 Support of Inter-Autonomous System (AS) MPLS and in Support of Inter-Autonomous System (AS) MPLS and
GMPLS Traffic Engineering", RFC 5316, December 2008. GMPLS 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 Support of Inter-Autonomous System (AS) MPLS and in Support of Inter-Autonomous System (AS) MPLS and
GMPLS Traffic Engineering", RFC 5392, January 2009. GMPLS 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, March
2009. 2009.
[TP-FWK] Bocci, M., Ed., Et al, "A Framework for MPLS in [RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC
Transport Networks", work in Progress, 5586, June 2009.
draft-ietf-mpls-tp-framework-10, February 2010.
[TP-FWK] Bocci, M., Ed., et al, "A Framework for MPLS in
Transport Networks", work in progress,
draft-ietf-mpls-tp-framework.
[TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM [TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM
Framework and Overview", work in Progress, Framework and Overview", work in progress,
draft-ietf-mpls-tp-oam-framework-04 December 2009. draft-ietf-mpls-tp-oam-framework.
[TP-OAM-REQ] Vigoureux, M., Ward, D, and Betts, M., "Requirements for [TP-OAM-REQ] Vigoureux, M., Ward, D, and Betts, M., "Requirements for
OAM in MPLS Transport Networks", work in progress, OAM in MPLS Transport Networks", work in progress,
draft-ietf-mpls-tp-oam-requirements. draft-ietf-mpls-tp-oam-requirements.
[TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label
Switching Transport Profile Survivability Switching Transport Profile Survivability
Framework", work in Progress, Framework", work in progress,
draft-ietf-mpls-tp-survive-fwk. draft-ietf-mpls-tp-survive-fwk.
10.2. Informative References 9.2. Informative References
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in "BFD For MPLS LSPs", work in progress,
progress. draft-ietf-bfd-mpls.
[GMPLS-ASON] Papadimitriou, D., "OSPFv2 Routing Protocols [GMPLS-ASON] Papadimitriou, D., "OSPFv2 Routing Protocols
Extensions for ASON Routing", work in progress, Extensions for ASON Routing", work in progress,
draft-ietf-ccamp-gmpls-ason-routing-ospf. draft-ietf-ccamp-gmpls-ason-routing-ospf.
[GMPLS-MLN] Papadimitriou, D., et al, "Generalized Multi-Protocol [GMPLS-MLN] Papadimitriou, D., et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Label Switching (GMPLS) Protocol Extensions for
Multi-Layer and Multi-Region Networks (MLN/MRN)", work Multi-Layer and Multi-Region Networks (MLN/MRN)", work
in progress, draft-ietf-ccamp-gmpls-mln-extensions. in progress, draft-ietf-ccamp-gmpls-mln-extensions.
[GMPLS-PS] Takacs, A., et al, "GMPLS RSVP-TE Recovery Extension [GMPLS-PS] Takacs, A., et al, "GMPLS RSVP-TE Recovery Extension
for data plane initiated reversion and protection timer for data plane initiated reversion and protection timer
signalling", draft-takacs-ccamp-revertive-ps, work in signalling", work in progress,
progress. draft-takacs-ccamp-revertive-ps.
[TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for [TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for
Point-to-Multipoint MPLS in Transport Networks", Point-to-Multipoint MPLS in Transport Networks",
draft-fbb-mpls-tp-p2mp-framework. draft-fbb-mpls-tp-p2mp-framework.
[RFC4655] A. Farrel, J.-P. Vasseur, and J. Ash, "A Path [RFC4655] A. Farrel, J.-P. Vasseur, and J. Ash, "A Path
Computation Element (PCE) -Based Architecture", RFC4655, Computation Element (PCE) -Based Architecture", RFC4655,
August 2006. August 2006.
[RFC5440] JP. Vasseur and JL. Le Roux, "Path Computation Element [RFC5440] JP. Vasseur and JL. Le Roux, "Path Computation Element
skipping to change at page 39, line 43 skipping to change at page 42, line 38
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC3477, January 2003. (RSVP-TE)", RFC3477, January 2003.
[RFC4201] K. Kompella and Y. Rekhter "Link Bundling in MPLS [RFC4201] K. Kompella and Y. Rekhter "Link Bundling in MPLS
Traffic Engineering (TE)", RFC4201, October 2005. Traffic Engineering (TE)", RFC4201, October 2005.
[RFC5145] K. Shiomoto, "Framework for MPLS-TE to GMPLS Migration" [RFC5145] K. Shiomoto, "Framework for MPLS-TE to GMPLS Migration"
RFC5145, March 2008. RFC5145, March 2008.
[CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration
Framework and Requirements for GMPLS RSVP-TE" Framework and Requirements for GMPLS RSVP-TE", work
draft-ietf-ccamp-oam-configuration-fwk, work in in progress, draft-ietf-ccamp-oam-configuration-fwk.
progress.
[CCAMP-OAM-EXT] Bellaganba, 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.
[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", draft-ietf-ccamp-lsp-hierarchy-bis, work Paths", work in progress,
in progress, October 2009. 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", Information Base in support of MPLS-TE/GMPLS", work in
draft-ietf-ccamp-gmpls-ted-mib, work in progress. 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",
draft-ietf-pwe3-dynamic-ms-pw-10, work in work in progress, draft-ietf-pwe3-dynamic-ms-pw.
progress, October 2009.
[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.
skipping to change at page 40, line 40 skipping to change at page 43, line 30
GMPLS Networks", work in progress, GMPLS Networks", work in progress,
draft-ietf-mpls-mpls-and-gmpls-security-framework. draft-ietf-mpls-mpls-and-gmpls-security-framework.
[NO-PHP] Ali, z., et al, "Non PHP Behavior and out-of-band mapping [NO-PHP] Ali, z., et al, "Non PHP Behavior and out-of-band mapping
for RSVP-TE LSPs", work in progress, for RSVP-TE LSPs", work in progress,
draft-ietf-mpls-rsvp-te-no-php-oob-mapping draft-ietf-mpls-rsvp-te-no-php-oob-mapping
[PC-SCP] Caviglia, D, et al, "RSVP-TE Signaling Extension For [PC-SCP] Caviglia, D, et al, "RSVP-TE Signaling Extension For
The Conversion Between Permanent Connections And Soft The Conversion Between Permanent Connections And Soft
Permanent Connections In A GMPLS Enabled Transport Permanent Connections In A GMPLS Enabled Transport
Network.", draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt, Network", work in progress,
work in progress, February 2010. draft-ietf-ccamp-pc-spc-rsvpte-ext.
[SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M., [SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M.,
"Segmented Pseaudowire", work in Progress, "Segmented Pseaudowire", work in progress,
draft-ietf-pwe3-segmented-pw-13.txt, August 2009. draft-ietf-pwe3-segmented-pw.
[RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label [RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[RFC3472] Ashwood-Smith, P., Ed, Berger, L. Ed., "Generalized [RFC3472] Ashwood-Smith, P., Ed, Berger, L. Ed., "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Multi-Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol Constraint-based Routed Label Distribution Protocol
(CR-LDP) Extensions", RFC 3472, January 2003. (CR-LDP) Extensions", RFC 3472, January 2003.
skipping to change at page 42, line 20 skipping to change at page 45, line 10
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and Malis, A., Ed., [RFC4619] Martini, L., Ed., Kawa, C., Ed., and Malis, A., Ed.,
"Encapsulation Methods for Transport of Frame Relay "Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS) Networks", over Multiprotocol Label Switching (MPLS) Networks",
September 2006. September 2006.
[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", RFC4802, Feb., 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", RFC4803, Feb., 2007. Management Information Base", RFC 4803, February 2007.
[RFC4816] Malis, A., Martini, L., Brayley, J., and Walsh, T., [RFC4816] Malis, A., Martini, L., Brayley, J., and Walsh, T.,
"Pseudowire Emulation Edge-to-Edge (PWE3) "Pseudowire Emulation Edge-to-Edge (PWE3)
Asynchronous Transfer Mode (ATM) Transparent Cell Asynchronous Transfer Mode (ATM) Transparent Cell
Transport Service", RFC 4816, February 2007. Transport Service", RFC 4816, February 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual
Circuit Connectivity Verification (VCCV) : A Control Circuit Connectivity Verification (VCCV) : A Control
Channel for Pseudowires", RFC 5085, December 2007. Channel for Pseudowires", RFC 5085, December 2007.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
[RFC5493] Caviglia, D., et al, "Requirements for the [RFC5493] Caviglia, D., et al, "Requirements for the
Conversion between Permanent Connections and Conversion between Permanent Connections and
Switched Connections in a Generalized Multiprotocol Switched Connections in a Generalized Multiprotocol
Label Switching (GMPLS) Network", RFC 5493, April Label Switching (GMPLS) Network", RFC 5493, April
2009. 2009.
[RFC5659] Bocci, M., and Bryant, B., "An Architecture for [RFC5659] Bocci, M., and Bryant, B., "An Architecture for
Multi-Segment Pseudowire Emulation Edge-to-Edge", Multi-Segment Pseudowire Emulation Edge-to-Edge",
RFC 5659, October 2009. RFC 5659, October 2009.
[RFC5718] Bellar, D., Farrel, A., "An In-Band Data Communication [RFC5718] Bellar, D., Farrel, A., "An In-Band Data Communication
Network For the MPLS Transport Profile", RFC 5718, January Network For the MPLS Transport Profile", RFC 5718, January
2010. 2010.
[PW-RED] Muley, P., et al, "Pseudowire (PW) Redundancy", work in
progress, draft-ietf-pwe3-redundancy.
[PW-REDB] Muley, P., et al, "Preferential Forwarding Status bit
definition", work in progress, draft-ietf-pwe3-redundancy-
bit.
[TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in [TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in
progress, draft-weingarten-mpls-tp-ring-protection. progress, draft-weingarten-mpls-tp-ring-protection.
[VCCV-BFD] Nadeau, T. and C. Pignataro, "Bidirectional [VCCV-BFD] 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)",
draft-ietf-pwe3-vccv-bfd, work in progress. work in progress, draft-ietf-pwe3-vccv-bfd.
11. Authors' Addresses 10. Authors' Addresses
Loa Andersson (editor) Loa Andersson (editor)
Ericsson Ericsson
Phone: +46 10 717 52 13 Phone: +46 10 717 52 13
Email: loa.andersson@ericsson.com Email: loa.andersson@ericsson.com
Lou Berger (editor) Lou Berger (editor)
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
skipping to change at line 2093 skipping to change at page 47, line 4
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
Ericsson
900 Chelmsford Street
Lowell, MA, 01851
Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com
Generated on: Mon Mar 22 09:11:17 PDT 2010 Generated on: Mon Mar 22 09:17:03 PDT 2010
 End of changes. 79 change blocks. 
138 lines changed or deleted 288 lines changed or added

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