--- 1/draft-ietf-ccamp-mpls-tp-cp-framework-00.txt 2010-03-22 20:11:10.000000000 +0100 +++ 2/draft-ietf-ccamp-mpls-tp-cp-framework-01.txt 2010-03-22 20:11:10.000000000 +0100 @@ -1,20 +1,20 @@ Internet Draft Loa Andersson, Ed. (Acreo AB) Category: Informational Lou Berger, Ed. (LabN) Expiration Date: September 22, 2010 Luyuan Fang, Ed. (Cisco) Nabil Bitar, Ed. (Verizon) March 22, 2010 MPLS-TP Control Plane Framework - draft-ietf-ccamp-mpls-tp-cp-framework-00.txt + draft-ietf-ccamp-mpls-tp-cp-framework-01.txt Abstract The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering,, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs and provides for @@ -88,50 +88,50 @@ 4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 26 4.2 OAM, MEP (Hierarchy) Configuration and Control ......... 26 4.2.1 Management Plane Support ............................... 27 4.3 GMPLS and MPLS-TP Requirements Table ................... 28 4.4 Anticipated MPLS-TP Related Extensions and Definitions . 31 4.4.1 MPLS to MPLS-TP Interworking ........................... 31 4.4.2 Associated Bidirectional LSPs .......................... 31 4.4.3 Asymmetric Bandwidth LSPs .............................. 31 4.4.4 Recovery for P2MP LSPs ................................. 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.1 General reuse of existing PW control plane mechanisms .. 35 - 5.2 Signaling .............................................. 35 - 5.3 Recovery (Redundancy) .................................. 35 - 6 Network Managment Considerations ....................... 35 - 7 Security Considerations ................................ 35 - 8 IANA Considerations .................................... 36 - 9 Acknowledgments ........................................ 36 - 10 References ............................................. 36 - 10.1 Normative References ................................... 36 - 10.2 Informative References ................................. 38 - 11 Authors' Addresses ..................................... 43 + 5.1 LDP Functions and Pseudowires .......................... 32 + 5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 33 + 5.3 Anticipated MPLS-TP Related Extensions ................. 35 + 5.4 Pseudowire OAM and Recovery (Redundancy) ............... 37 + 6 Security Considerations ................................ 38 + 7 IANA Considerations .................................... 38 + 8 Acknowledgments ........................................ 38 + 9 References ............................................. 38 + 9.1 Normative References ................................... 38 + 9.2 Informative References ................................. 41 + 10 Authors' Addresses ..................................... 46 1. Introduction The MPLS Transport Profile (MPLS-TP) is being defined in a joint effort between the International Telecommunications Union (ITU) and the IETF. The requirements for MPLS-TP are defined in the requirements document, see [RFC5654]. These requirements state that "A solution MUST be provided to support dynamic provisioning of MPLS- TP transport paths via a control plane." This document provides the framework for such dynamic provisioning. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the - capabilities and functionalities of a packet transport network as - defined by the ITU-T. + capabilities and functions of a packet transport network as defined + by the ITU-T. 1.1. Conventions Used In This Document 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 @@ -269,21 +269,21 @@ TE-RTG: OSPF-TE or ISIS-TE UNI: User to Network Interface Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". These segments are present to support scaling, OAM and MEPs within each provider and across the inter-provider NNI. The MEPs are used to collect performance information, support diagnostic functions, and support OAM triggered survivability schemes as discussed in [TP- SURVIVE], and each H-LSP may be protected using any of the schemes 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- to-end) LSPs. |< ------- client signal (IP / MPLS / L2 / PW) ------ >| |< -------- SP1 ----------- >|< ------- SP2 ----- >| |< ----------- MPLS-TP End-to-End PW -------- >| |< ------- MPLS-TP End-to-End LSP ------- >| |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ @@ -372,26 +372,26 @@ point transport paths [RFC5654, requirement 7]. 8. The MPLS-TP control plane must support unidirectional point-to- multipoint transport paths [RFC5654, requirement 8]. 9. All nodes (i.e., ingress, egress and intermediate) must be aware about the pairing relationship of the forward and the backward directions belonging to the same co-routed 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 belonging to the same associated bidirectional transport path [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 associated bidirectional transport path [RFC5654, requirement 12]. 12. The MPLS-TP control plane must support bidirectional transport paths with symmetric bandwidth requirements, i.e. the amount of reserved bandwidth is the same in the forward and backward directions [RFC5654, requirement 13]. 13. The MPLS-TP control plane must support bidirectional transport @@ -440,27 +440,27 @@ homogeneous domains [RFC5654, requirement 26]. 23. The MPLS-TP control plane must not dictate any particular physical or logical topology [RFC5654, requirement 27]. 24. The MPLS-TP control plane must include support of ring topologies which may be deployed with arbitrarily interconnection, support rings of at least 16 nodes [RFC5654, requirement 27.A. and 27.B.]. - 25. The MPLS-TP control plane must support scale gracefully to - support a large number of transport paths, nodes and links. - That is it must be able to scale at least as well as control - planes in existing transport technologies with growing and - increasingly complex network topologies as well as with - increasing bandwidth demands, number of customers, and number - of services [RFC 5654, requirements 53 and 28]. + 25. The MPLS-TP control plane must scale gracefully to support a + large number of transport paths, nodes and links. That is it + must be able to scale at least as well as control planes in + existing transport technologies with growing and increasingly + complex network topologies as well as with increasing bandwidth + demands, number of customers, and number of services [RFC 5654, + requirements 53 and 28]. 26. The MPLS-TP control plane should not provision transport paths which contain forwarding loops [RFC5654, requirement 29]. 27. The MPLS-TP control plane must support multiple client layers. (e.g. MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.) [RFC5654, requirement 30]. 28. The MPLS-TP control plane must provide a generic and extensible solution to support the transport of MPLS-TP transport paths @@ -665,21 +665,21 @@ 69. The MPLS-TP control plane must support restoration priority so that an implementation can determine the order in which transport paths should be restored [RFC5654, requirement 71]. 70. The MPLS-TP control plane must support preemption priority in order to allow restoration to displace other transport paths in the event of resource constraints [RFC5654, requirement 72 and 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]. 72. The MPLS-TP control plane must support recovery being triggered by physical (lower) layer fault indications [RFC5654, requirement 74]. 73. The MPLS-TP control plane must support recovery being triggered by OAM [RFC5654, requirement 75]. 74. The MPLS-TP control plane must support management plane @@ -708,21 +708,21 @@ recovery paths [RFC5654, requirement 81]. 80. The MPLS-TP control plane must support pre-provisioning of recovery paths [RFC5654, requirement 82]. 81. The MPLS-TP control plane must support the external commands defined in [RFC4427]. External controls overruled by higher priority requests (e.g., administrative requests and requests due to link/node failures) or unable to be signaled to the 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 validation of the integrity of the protection/recovery transport path [RFC5654, requirement 84 A]. 83. The MPLS-TP control plane must permit the testing and validation of protection/ restoration mechanisms without triggering the actual protection/restoration [RFC5654, requirement 84 B]. @@ -816,23 +816,21 @@ 100. The MPLS-TP control plane is based on the GMPLS control plane for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE [RFC3473] and related extensions are used for LSP signaling, and GMPLS OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing [TP-FWK, section 3.8.]. 101. The MPLS-TP control plane is based on the MPLS control plane for PWs, and more specifically, Targeted LDP (T-LDP) [RFC4447] is used for PW signaling [TP-FWK, section 3.8, paragraph 6]. - 102. The MPLS-TP LSP control plane must allow for interoperation - with the MPLS-TE LSP control plane [TP-FWK, section 3.8.2., - paragraph 5]. + 102. (Requirement removed from [TP-FWK].) 103. The MPLS-TP control plane must ensure its own survivability and to enable it to recover gracefully from failures and degradations. These include graceful restart and hot redundant configurations [TP-FWK-06, section 3.8., paragraph 12]. 104. The MPLS-TP control plane must support linear, ring and meshed protection schemes [TP-FWK-06, section 3.10., paragraph 8]. 2.3. OAM Framework Derived Requirements @@ -861,21 +859,21 @@ 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 applies [TP-OAM-REQ, section 2.2., paragraph 3]. 110. The MPLS-TP control plane must provide a mechanism to support the localization of faults and the notification of appropriate nodes. Such notification should trigger corrective (recovery) 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 provides, even if the fault or defect is located outside of his domain [TP-OAM-REQ, section 2.2.1., paragraph 2]. 112. Information exchange between various nodes involved in the MPLS-TP control plane should be reliable such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes [TP-OAM- REQ, section 2.2.1., paragraph 3]. @@ -963,22 +961,20 @@ 4., paragraph 5]. 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 4]. 126. The MPLS-TP control plane must support the signaling of the transmission period used in CC and CV [TP-OAM, section 5.1., paragraph 6]. - 127. [NOTE: Need to review NM frawework for derived requirments] - 2.4. Security Requirements There are no specific MPLS-TP control plane security requirements. The existing framework for MPLS and GMPLS security is documented on [MPLS-SEC] and that document applies equally to MPLS-TP. 3. Relationship of PWs and TE LSPs The data plane relationship between PWs and LSPs is inherited from standard MPLS and is reviewed in the MPLS-TP Framework [TP-FWK]. @@ -1242,21 +1238,21 @@ messages to trigger protection switching and recovery is not required in MPLS-TP as this function is expected to be supported via OAM. However, it's use is not precluded. 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) The majority of GMPLS control plane related RFCs define the control plane from the context of an internal network-to-network interface (I-NNI). In the MPLS-TP context, some operators may choose to deploy 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 [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 UNI and E-NNI. 4.2. OAM, MEP (Hierarchy) Configuration and Control MPLS-TP is being defined to support a comprehensive set of MPLS-TP OAM functions. Specific OAM requirements for MPLS-TP are documented in [TP-OAM-REQ]. In addition to the actual OAM requirements, it is @@ -1307,21 +1303,21 @@ Note that control plane triggers are typically invoked in response to a management plane request at the ingress. 4.2.1.2. Management Plane / Control Plane Ownership Transfer In networks where both control plane and management plane are provided, LSP provisioning can be bone either by control plane or management plane. As mentioned in the requirements section above, it 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 must be possible for the control plane to notify, in a reliable manner, the management plane about the status/result of either synchronous or asynchronous, with respect to the management plane, operation performed. Moreover it must be possible to monitor, via query or spontaneous notify, the status of the control plane object such as the TE Link status, the available resources, etc. A mechanism must be made available by the control plane to the management plane to log control plane LSP related operation, that is, it must be possible from the NMS to have a clear view of the life, (traffic hit, @@ -1336,21 +1332,21 @@ specifications are required are also identified. The table lists references based on the control plane requirements as identified and numbered above in section 2. +=======+===========================================================+ | Req # | References | +-------+-----------------------------------------------------------+ | 1 | Generic requirement met by using Standards Track RFCs | | 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 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] | | 6 | [RFC3471], [RFC3473], [RFC4875] | | 7 | [RFC3471], [RFC3473] + | | | Associated bidirectional LSPs (See Section 4.4.2) | | 8 | [RFC4875] | | 9 | [RFC3473] | | 10 | Associated bidirectional LSPs (See Section 4.4.2) | | 11 | Associated bidirectional LSPs (See Section 4.4.2) | | 12 | [RFC3473] | | 13 | [RFC5467] (Currently Experimental, See Section 4.4.3) | @@ -1377,21 +1373,21 @@ | 31 | [RFC3945], [RFC3471], [RFC4202] | | 32 | [RFC4208], [RFC4974], [GMPLS-ASON], [GMPLS-MLN] | | 33 | [RFC3473], [RFC4875] | | 34 | [RFC4875] | | 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 36 | [RFC3473], [RFC3209] (Make-before-break) | | 37 | [RFC3473], [RFC3209] (Make-before-break) | | 38 | [RFC3945], [RFC4202], [RFC5718] | | 39 | [RFC4139], [RFC4258], [GMPLS-ASON] | | 40 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | - | 41 | [RFC3473] | + | 41 | [RFC3473], [RFC5063] | | 42 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] | | 43 | [RFC3945], [RFC3471], [RFC4202] | | 44 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 45 | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 46 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 47 | [PC-SCP] | | 48 | [RFC4872], [RFC4873] | | 49 | [RFC3945], [RFC3471], [RFC4202] | | 50 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | | 51 | [RFC4872], [RFC4873] | @@ -1431,30 +1427,30 @@ | 84 | [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] | | 87 | [RFC4872], [RFC4873] | | 88 | [RFC4872], [RFC4873] | | 89 | [RFC4872], [RFC4873], [TP-RING] | | 90 | [RFC4872], [RFC4873], [TP-RING] | | 91 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | | 92 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 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] | | 96 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | - | 97 | [RFC3473] (See Section 3) | - | 98 | [RFC3473] (See Section 3) | + | 97 | PW only requirement, see PW Requirements Table (5.2) | + | 98 | PW only requirement, see PW Requirements Table (5.2) | | 99 | [RFC3945], [RFC3473], [HIERARCHY-BIS] | | 100 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + | | | [RFC5392] and [RFC5316] | - | 101 | PW only requirement | - | 102 | [RFC5145] + Formal Definition (See Section 4.4.1) | + | 101 | PW only requirement, see PW Requirements Table (5.2) | + | 102 | (Requirement removed.) | | 103 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | | 104 | [RFC4872], [RFC4873], [TP-RING] | | 105 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 106 | [RFC3473], [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) | | 109 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 110 | [RFC3473], [RFC4872], [RFC4873] | | 111 | [RFC3473], [RFC4872], [RFC4873] | | 112 | [RFC3473], [RFC4783] | @@ -1465,21 +1461,20 @@ | 117 | [RFC4426], [RFC4872], [RFC4873] | | 118 | [RFC3473], [RFC4872], [RFC4873] | | 119 | [RFC3473], [RFC4783] | | 120 | [RFC3473] | | 121 | [RFC3473], [RFC4783] | | 122 | [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] | | 125 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 126 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | - | 127 | TBD | +=======+===========================================================+ 4.4. Anticipated MPLS-TP Related Extensions and Definitions This section identifies the extensions and other documents that have been identified as likely to be needed to support the full set of MPLS-TP control plane requirements. 4.4.1. MPLS to MPLS-TP Interworking @@ -1525,204 +1520,323 @@ been identified in the context of MPLS-TP. As discussed above, the MPLS-TP control plane must support the selection of which (if any) OAM function(s) to use (including support to select experimental OAM functions) and what OAM functionality to run, including, continuity check (CC), connectivity verification (CV), packet loss and delay quantification, and diagnostic testing of a service. As OAM configuration is directly linked to data plane OAM, it is expected that [CCAMP-OAM-EXT] will evolve in parallel with the specification 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 LSPs. While the document references GMPLS signaling, there is no explicit discussion of discussion on the use of the DiffServ related objects in GMPLS signaling. A (possibly Information) document on how GMPLS supports DiffServ LSPs is likely to prove useful in the context of MPLS-TP. 5. Pseudowires - [Editor's note: This section is preliminary and will be - edited/replaced in future versions.] +5.1. LDP Functions and Pseudowires MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for emulated services over an MPLS Packet Switched Network (PSN). Several types of PWs have been defined: (1) Ethernet PWs providing for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2) HDLC/PPP PW providing for HDLC/PPP leased line transport over MPLS[RFC4618], (3) ATM PWs [RFC4816], (4) Frame Relay PWs [RFC4619], and (5) circuit Emulation PWs [RFC4553]. 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 SONET) client signals with no payload awareness. Implementing PW capability allows for the use of an existing technology to substitute the TDM transport with packet based transport, using well-defined PW encapsulation methods for carrying various packet services over MPLS, and providing for potentially better bandwidth utilization. - There are two types of PWs: (1) Single-Segment pseudowires (SS-PW), - and (2) Multi-segment pseudowires (MS-PW) [SEGMENTED-PW]. An MPLS-TP - domain may transparently transport a PW whose endpoints are within a - client network. Alternatively, an MPLS-TP edge node may be the - Terminating PE (T-PE) for a PW, performing adaptation from the native - attachment circuit technology (e.g. Ethernet 802.1q) to an MPLS PW - for transport over an MPLS-TP domain, with a GMPLS LSP or a hierarchy - of LSPs transporting the PW between the T-PEs. In this way, the PW is - analogous to a transport channel in a TDM network and the LSP is - equivalent to a container of multiple non-concatenated channels, - albeit they are packet containers. The MPLS-TP domain may also - contain Switching PEs (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 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 switching. + There are two general classes of PWs: (1) Single-Segment Pseudowires + (SS-PW), and (2) Multi-segment Pseudowires (MS-PW) [SEGMENTED-PW]. + An MPLS-TP domain may transparently transport a PW whose endpoints + are within a client network. Alternatively, an MPLS-TP edge node may + be the Terminating PE (T-PE) for a PW, performing adaptation from the + native attachment circuit technology (e.g. Ethernet 802.1q) to an + MPLS PW for transport over an MPLS-TP domain, with a GMPLS LSP or a + hierarchy of LSPs transporting the PW between the T-PEs. In this way, + the PW is analogous to a transport channel in a TDM network and the + LSP is equivalent to a container of multiple non-concatenated + channels, albeit they are packet containers. The MPLS-TP domain may + also contain Switching PEs (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 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 switching. SS-PW signaling control plane is based on LDP with specific 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 MS-PW whereby signaling is still based on Targeted LDP (T-LDP). The MPLS-TP domain shall use the same PW signaling protocols and procedures for placing SS-PWs and MS-PWs. This will leverage existing technology as well as facilitate interoperability with client networks with native attachment circuits or PW segment that is 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 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 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 applications is that any new mechanisms and capabilities must be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate. Hence, extensions of the PW Control Plane must be in-line with the procedures defined in [RFC4447]], [SEGMENTED-PW] and [MS-PW-DYNAMIC]. For MPLS-TP, it is required that the data and control planes are both logically and physically separated. That is, the PW Control Plane 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 affected and can continue to operate normally. This was not a design requirement for the current PW Control Plane. However, due to the PW concept, i.e., PWs are connecting logical entities ('forwarders'), and the operation of the PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part in the signaling exchanges: moving T-LDP out-of-band seems to be, theoretically, a straightforward exercise. + In fact, as a strictly local matter, ensuring that Targeted LDP (T- + 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 then T-LDP addressing can be maintained, although all addresses will refer to control plane entities. Both, the PWid FEC and Generalized PWid FEC Elements can possibly be used in an OOB case as well (Detailed evaluation is FFS). The PW Label allocation and exchange - mechanisms can be possibly reused unchanged (Detailed evaluation is - 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. + mechanisms should be reused without change. - For transport applications, it is mandatory that bidirectional - traffic is following congruent paths. Today, 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 requirement today is that a PW or a PW segment shares the same - T-PEs in both directions, and same S-PEs in both directions. This - poses a new requirement on the PW Control Plane, namely to ensure - that both ends map the PW to the same transport path. When a + Binding a PW to an LSP, or PW segments to LSPs is left to networks + elements acting as T-PEs and S-PEs or a control plane entity that may + be the same one signaling the PW. However, an extension of the PW + signaling protocol is required to allow the LSR at signal initiation + end to inform the targeted LSR (at the signal termination end) which + LSP the resulting PW is to be bound to, in the event that more than + one such LSP exists and the choice of LSPs is important to the + service being setup (for example, if the service requires co-routed + bi-directional paths). + + 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 mechanism is needed that signals to the remote end which LSP has been - selected locally to transport the PW. This likely can be accomplished - by adding a new TLV to PW signaling. This coincides with the gap - identified for OOB support: a new mechanism may be needed to - explicitly bind PWs to the supporting transport LSP. + selected locally to transport the PW. This would be accomplished by + adding a new TLV to PW signaling. + + Note that this coincides with the gap identified for OOB support: a + 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. However, to meet the congruency requirement, the LSPs must be placed so that they are forced to follow the same path (switches and links). This maybe accomplished by placing one unidirectional TE-LSP in one 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 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 must identify to the remote end which LSP to bind the other direction 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 RSVP-TE and the use of DiffServ. If multiple PWs are multiplexed into 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, signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable 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 available features manageable for the PW, including protection and OAM entities and mechanisms. There is ongoing work on PW protection and MPLS-TP OAM. To summarize, the main areas identified for potential PW Control 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 describe each mechanism contain their own security considerations sections. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [MPLS-SEC]. This document also identifies a number of needed control plane extensions. It is expected that the documents that define such extensions will also include any appropriate security considerations. -8. IANA Considerations +7. IANA Considerations There are no new IANA considerations introduced by this document. -9. Acknowledgments +8. Acknowledgments The authors would like to acknowledge the contributions of Yannick 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 Services", RFC 2210, September 1997. [RFC2211] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1997. [RFC2212] Shenker, S., Partridge, C., and R Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. @@ -1738,51 +1852,65 @@ V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L. Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation 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 - Engineering (TE) Extensions to OSPF Version 2", RFC 3630, - September 2003. + Engineering (TE) Extensions to OSPF Version 2", RFC + 3630, September 2003. [RFC4124] Le Faucheur, F., Ed. "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching(GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 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 Using the Label Distribution Protocol (LDP)", RFC 4447, 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/ + 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., "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC4929] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized @@ -1790,82 +1918,89 @@ 4929, June 2007. [RFC4974] Papadimitriou, D., Farrel, A., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007. [RFC5063] Satyanarayana, A., Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, 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 Engineering", RFC 5305, October 2008. [RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC5316] Chen, M., Zhang, R., and Duan, X., "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC5392] Chen, M., Zhang, R., and Duan, X., "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009. [RFC5151] Farrel, A., Ed., "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic 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. - [RFC5467] Berger, L., Et al, "GMPLS Asymmetric Bandwidth + [RFC5467] Berger, L., et al, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009. - [TP-FWK] Bocci, M., Ed., Et al, "A Framework for MPLS in - Transport Networks", work in Progress, - draft-ietf-mpls-tp-framework-10, February 2010. + [RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC + 5586, June 2009. + + [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 - Framework and Overview", work in Progress, - draft-ietf-mpls-tp-oam-framework-04 December 2009. + Framework and Overview", work in progress, + draft-ietf-mpls-tp-oam-framework. [TP-OAM-REQ] Vigoureux, M., Ward, D, and Betts, M., "Requirements for OAM in MPLS Transport Networks", work in progress, draft-ietf-mpls-tp-oam-requirements. [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label Switching Transport Profile Survivability - Framework", work in Progress, + Framework", work in progress, 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 For MPLS LSPs", draft-ietf-bfd-mpls, work in - progress. + "BFD For MPLS LSPs", work in progress, + draft-ietf-bfd-mpls. [GMPLS-ASON] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions for ASON Routing", work in progress, draft-ietf-ccamp-gmpls-ason-routing-ospf. [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 for data plane initiated reversion and protection timer - signalling", draft-takacs-ccamp-revertive-ps, work in - progress. + signalling", work in progress, + draft-takacs-ccamp-revertive-ps. [TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for Point-to-Multipoint MPLS in Transport Networks", draft-fbb-mpls-tp-p2mp-framework. [RFC4655] A. Farrel, J.-P. Vasseur, and J. Ash, "A Path Computation Element (PCE) -Based Architecture", RFC4655, August 2006. [RFC5440] JP. Vasseur and JL. Le Roux, "Path Computation Element @@ -1881,41 +2016,39 @@ in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC3477, January 2003. [RFC4201] K. Kompella and Y. Rekhter "Link Bundling in MPLS Traffic Engineering (TE)", RFC4201, October 2005. [RFC5145] K. Shiomoto, "Framework for MPLS-TE to GMPLS Migration" RFC5145, March 2008. [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration - Framework and Requirements for GMPLS RSVP-TE" - draft-ietf-ccamp-oam-configuration-fwk, work in - progress. + Framework and Requirements for GMPLS RSVP-TE", work + in progress, draft-ietf-ccamp-oam-configuration-fwk. - [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, draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext. [HIERARCHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched - Paths", draft-ietf-ccamp-lsp-hierarchy-bis, work - in progress, October 2009. + Paths", work in progress, + draft-ietf-ccamp-lsp-hierarchy-bis. [TE-MIB] T Otani, et.al., "Traffic Engineering Database Management - Information Base in support of MPLS-TE/GMPLS", - draft-ietf-ccamp-gmpls-ted-mib, work in progress. + Information Base in support of MPLS-TE/GMPLS", work in + progress, draft-ietf-ccamp-gmpls-ted-mib. [MS-PW-DYNAMIC] L. Martini, M Bocci, and F Balus "Dynamic Placement of Multi Segment Pseudo Wires", - draft-ietf-pwe3-dynamic-ms-pw-10, work in - progress, October 2009. + work in progress, draft-ietf-pwe3-dynamic-ms-pw. [ITU.G8080.2006] International Telecommunications Union, "Architecture for the automatically switched optical network (ASON)", ITU- T Recommendation G.8080, June 2006. [ITU.G8080.2008] International Telecommunications Union, "Architecture for the automatically switched optical network (ASON) Amendment 1", ITU-T Recommendation G.8080 Amendment 1, March 2008. @@ -1924,26 +2057,26 @@ 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 for RSVP-TE LSPs", work in progress, draft-ietf-mpls-rsvp-te-no-php-oob-mapping [PC-SCP] Caviglia, D, et al, "RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS Enabled Transport - Network.", draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt, - work in progress, February 2010. + Network", work in progress, + draft-ietf-ccamp-pc-spc-rsvpte-ext. [SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M., - "Segmented Pseaudowire", work in Progress, - draft-ietf-pwe3-segmented-pw-13.txt, August 2009. + "Segmented Pseaudowire", work in progress, + draft-ietf-pwe3-segmented-pw. [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 Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. @@ -2006,58 +2139,69 @@ [RFC4619] Martini, L., Ed., Kawa, C., Ed., and Malis, A., Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", September 2006. [RFC4783] Berger, L.,Ed., "GMPLS - Communication of Alarm Information", RFC 4763, December 2006. [RFC4802] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol 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 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., "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service", RFC 4816, February 2007. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV) : A Control 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 Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009. [RFC5659] Bocci, M., and Bryant, B., "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. [RFC5718] Bellar, D., Farrel, A., "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 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 progress, draft-weingarten-mpls-tp-ring-protection. [VCCV-BFD] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", - 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) Ericsson Phone: +46 10 717 52 13 Email: loa.andersson@ericsson.com Lou Berger (editor) LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net @@ -2083,12 +2227,18 @@ Martin Vigoureux Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.fr Elisa Bellagamba Ericsson Farogatan, 6 164 40, Kista, Stockholm, SWEDEN 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