idnits 2.17.1 draft-bao-pwe3-pw-transfer-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5654], [RFC5852], [RFC5493]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1) PW attributes MUST not be changed == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The PW attributes, such as bandwith, PWid , PW type, Control Word, VCCV, Interface Parameter, MUST not be changed during and after the PW transfer. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The PW transfer SHOULD not depend on whether the LSP (bearing this PW) is controlled by MP or CP. Since PW transfer procedure will not impact the data plane path, so PW transfer MUST leave LSP alone. The relationship between PW and LSP MUST NOT be changed. -- The document date (Mar 12, 2012) is 4390 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6373' is mentioned on line 107, but not defined == Missing Reference: 'ITU.G805.2000' is mentioned on line 147, but not defined == Missing Reference: 'RFC 4447' is mentioned on line 323, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Unused Reference: 'RFC3985' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'MPLS-TP-CP-FWK' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'MPLS-TP-FWK' is defined on line 488, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 5493 == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-10 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-mpls-tp-cp-framework-02 == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-11 Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Qilei Wang 3 Internet-Draft Muliu Tao 4 Intended status: Standards Track Xihua Fu 5 Expires: September 13, 2012 Lizhong Jin 6 ZTE Corporation 7 Ruiquan Jing 8 China Telecom 9 Mar 12, 2012 11 LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network 12 draft-bao-pwe3-pw-transfer-03.txt 14 Abstract 16 As defined in [RFC5654] MPLS-TP transport path includes LSP and PW. 17 And the possibility of transferring the ownership and control of an 18 existing and in-use path between the management plane and the control 19 plane, without actually affecting data plane traffic being carried 20 over it, is a valuable option for carrier. [RFC5493] and [RFC5852] 21 describe the LSP transfer. This memo gives the requirement and LDP 22 extensions for PW transfer in an MPLS-TP network. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Comparison with Make-before-Break . . . . . . . . . . . . 3 60 1.2. Conventions used in this document . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview of the PW Transfer . . . . . . . . . . . . . . . . . 4 63 4. Requirements for PW Transfer . . . . . . . . . . . . . . . . . 5 64 5. LDP Extension for PW Transfer . . . . . . . . . . . . . . . . 6 65 5.1. LDP Extension . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1.1. Support PW Transfer Capability with LDP . . . . . . . 6 67 5.1.2. PW Ownership Transfer TLV . . . . . . . . . . . . . . 6 68 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2.1. PW Ownership Transfer from MP to CP . . . . . . . . . 7 70 5.2.1.1. MP2CP PW Transfer Failure . . . . . . . . . . . . 8 71 5.2.2. PW Ownership Transfer from CP to MP . . . . . . . . . 9 72 5.2.2.1. CP2MP PW Transfer Failure . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 As defined in [RFC5654], MPLS-TP transport path corresponds to an LSP 84 or a PW which is carried in an LSP. And LSP includes unidirectional 85 LSP, co-routed bidirectional LSP and associated bidirectional LSP, 86 while PW includes Single-Segment Pseudowire (SS-PW) and Multi-Segment 87 Pseudowire (MS-PW). 89 For MPLS-TP LSP, it can be created/deleted via GMPLS signaling, see 90 [RFC3945]. However, the creation/deletion of PW can be completed by 91 LDP, and [RFC4447] gives these procedures of SS-PW while [RFC6073] 92 and [DYNAMIC-MS-PW] decribes the ones of MS-PW. 94 Nowdays, some service providers have deployed MPLS-TP network for 95 mobile backhaul. However, most PWs are statically configured by 96 management plane in the first stage. So if control plane is deployed 97 massively, it is desirable for provider to transfer the control of 98 PWs from the management plane (MP) to control plane (CP) in the 99 future. In addition, the control transfer in the opposite direction, 100 i.e. from CP to MP, should be considered as well if operators want 101 to. 103 Both the requirement 55 in [RFC5654] and requirement 47 in [RFC6373] 104 state that an MPLS-TP control plane MUST provide a mechanism for 105 dynamic ownership transfer of the control of MPLS-TP transport paths 106 from the management plane to the control plane and vice versa. 107 Furthermore, section 5.3.3 of [RFC6373] describes the requirement for 108 PW transfer. Since [RFC5493] and [RFC5852] give the requirements and 109 RSVP-TE extensions and procedures for LSP transfer, this memo 110 considers the procedures and LDP extensions for PW transfer. 112 1.1. Comparison with Make-before-Break 114 The Make-Before-Break (MBB) technology is an alternative method for 115 PW transfer which has three steps. Firstly, a new PW (has the same 116 parameters with the one to be transferred) will be created; then the 117 PW will be switched from old PW to the new one; and after the PW 118 switching completed successfully the old PW will be deleted. From 119 this process, we can find there're many drawbacks with MBB. 121 The creation and swithing steps of MBB will lead to instant 122 interruption which is acceptable if it can be controlled within 50ms. 123 Furthermore, extra resource is need, in the circumstance that the 124 network is almost saturated, there maybe not enough resource for the 125 new PWs, so MBB will be unavailable. Otherwise, MBB will lead to 126 label modification which will make the bundling relationship between 127 PW and LSP modified at the same time. This will triggre many 128 problems, and a new detection mechanism needs to be defined which may 129 be very complex. In addition, since control plane is used to create 130 the new PW while management plane is responsible for the deletion of 131 the old PW. Thus batch operation can't be used for this process. If 132 there're a large number PWs needed to be transfered, the operator's 133 time will be engaged by this tedious operation which is inefficiency. 134 However, the PW transfer method described in this document will not 135 affect the data plane, the traffic and it's configuration. So it's 136 preference for PW transfer. 138 1.2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Terminology 146 o Transport Path: A network connection as defined in G.805 147 [ITU.G805.2000]. In an MPLS-TP environment, a transport path 148 corresponds to an LSP or a PW (see RFC5654). 150 o Single-Segment Pseudowire (SS-PW): A PW setup directly between two 151 T-PE devices. Each PW in one direction of a SS-PW traverses one 152 PSN tunnel that connects the two T-PEs. 154 o Multi-Segment Pseudowire (MS-PW): A static or dynamically 155 configured set of two or more contiguous PW segments that behave 156 and function as a single point-to-point PW. Each end of a MS-PW 157 by definition MUST terminate on a T-PE. 159 o PW Segment: A part of a single-segment or multi-segment PW, which 160 traverses one PSN tunnel in each direction between two PE devices, 161 T-PEs and/or S-PEs. 163 o Resource Ownership: A resource used by an MPLS-TP path is said to 164 be 'owned' by the plane that was used to set up the MPLS-TP path 165 through that part of the network. So, a resource owned by the 166 management/control plane means the resource was used to set up the 167 MPLS-TP path through the management/control plane. See RFC5493 168 for detailed description. 170 3. Overview of the PW Transfer 172 The PW transfer includes two reverse procedures. One is the MP to CP 173 (MP2CP) transfer procedure, another is the CP to MP (CP2MP) transfer 174 procedure. 176 For MP2CP transfer procedure, a PW set up and owned by MP needs to be 177 transferred to CP control. To conduct this transfer, the T-LDP 178 session will be created in CP for PW. After this transfer procedure, 179 the resource ownership is transferred from MP to CP. 181 The CP2MP transfer procedure is the reverse one compared to MP2CP 182 procedure. However, since a LDP session may be shared by multi PWs, 183 the T-LDP session may be retained after one PW transferring from CP 184 to MP, if there're still other PWs remain controlled by CP. So, the 185 CP2MP procedure needs to check whether this signaling session should 186 be retained or not. 188 As an requirement listed in [RFC5493], during both MP2CP and CP2MP 189 transfer procedures, if PW is carrying traffic, its control transfer 190 has to be done without any disruption to the data plane traffic. 192 Furthermore, both MP2CP and CP2MP transfer procedures can be 193 conducted in a batch manner, that is, multiple LSPs or PWs can be 194 transferred all at one time. For example, all PWs on a node can be 195 transferred at one time. However, this transfer manner is out of 196 this document. 198 4. Requirements for PW Transfer 200 [RFC5493] describes the requirements for the conversion between 201 permanent connection (PC) and switched connection (SC) in a GMPLS 202 network. The terminologies "PC" and "SPC" come from ITU-T standard 203 [G.8081], Because associated bidirectional LSP isn't defined in ITU-T 204 standard. So, both PC and SPC can only be considered as 205 unidirectional LSP and co-routed bidirectional LSP. Therefore, these 206 requirements fully apply to unidirectional LSP and co-routed 207 bidirectional LSP in a MPLS-TP network. Although, some requirements 208 defined in [RFC5493] apply to PW, but other new requirements also 209 need to be explored. 211 This section lists the special requirements for PW transfer. 213 1) PW attributes MUST not be changed 215 The PW attributes, such as bandwith, PWid , PW type, Control 216 Word, VCCV, Interface Parameter, MUST not be changed during and 217 after the PW transfer. 219 2) PW transfer MUST be independent of LSP 221 The PW transfer SHOULD not depend on whether the LSP (bearing 222 this PW) is controlled by MP or CP. Since PW transfer procedure 223 will not impact the data plane path, so PW transfer MUST leave 224 LSP alone. The relationship between PW and LSP MUST NOT be 225 changed. 227 3) Support partial MS-PW segments transfer 229 Since a MS-PW transit multi domains and these domains may belong 230 to different providers. In this scenario, if some providers have 231 deployed control plane while others not, the PW segments in these 232 domains that control plane are deployed SHOULD be allowed to 233 transfer between MP and CP while other PW segments keep their 234 original states. 236 5. LDP Extension for PW Transfer 238 5.1. LDP Extension 240 5.1.1. Support PW Transfer Capability with LDP 242 A new Capability Parameter TLV is defined, the PW Transfer 243 Capability. Following is the format of the PW Transfer Capability 244 Parameter. 246 0 1 2 3 247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |1|0|PW Transfer Capability(TBD)| Length (= 1) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |1| Reserved | 252 +-+-+-+-+-+-+-+-+ 254 Figure 1: PW Transfer Capability 256 The PW Transfer Capability TLV MUST be supported in the LDP 257 Initialization Message([RFC5561]). Advertisement of the PW Transfer 258 Capability indicates the support of the procedures for PW transfer 259 between MP and CP detailed in this document. If the peer has not 260 advertised the corresponding capability, then no PW transfer label 261 messages should be sent to the peer. 263 5.1.2. PW Ownership Transfer TLV 265 To ensure the PW ownership transfer between MP and CP automatically, 266 T-PE/S-PE SHOULD be notified by the PW transfer signaling message. 267 So, the PW path and PW transfer indication MUST be carried in the LDP 268 Label Mapping message. 270 Since [RFC6073] has defined PW switching point TLV (S-PE TLV) and 271 Sub-TLV to the switching points that the PW traverses, these TLV and 272 Sub-TLV can be used to carry the PW path which is needed to be 273 transferred. 275 ER-TLV which is defined in [draft-ietf-pwe3-mspw-er] can also be used 276 to carry the information of PW path which is needed to be transferred 277 in the scenario of setting up MS-PW using generalized FEC 129 from 278 source PE to destination PE. 280 Therefore, this section only defines a new LDP TLV - Transfer TLV - 281 which can be used to indicate a PW transfer signaling procedure. 283 The PW Ownership Transfer TLV (PW-OH TLV), is defined as follows (TLV 284 type needs to be assigned by IANA): 286 0 1 2 3 287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |0|0| PW Transfer (0x0105) | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |POT| Reserved | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 2: PW Ownership Transfer TLV 296 POT (2 bits): PW Ownership Transfer. PE MUST carry this TLV in 297 LDP Label Mapping and Notification message defined in [RFC5036] 298 when transferring from MP to CP, or CP to MP. The value of POT 299 is following: 301 1 - PW ownership transfer from management plane to control plane 303 2 - PW ownership transfer from control plane to management plane 305 Reserved(30 bits): This field MUST be set to zero on transmission 306 and MUST be ignored on receipt. 308 5.2. Procedures 310 5.2.1. PW Ownership Transfer from MP to CP 312 Before transferring from MP to CP, there MUST be a T-LDP session 313 between two T-PE for SS-PW, or T-PE and S-PE for MS-PW. During the 314 LDP initialization stage, the LDP speaker MUST announce it's PW 315 transfer capability according to [RFC5561] by sending the peer a 316 Capability message carrying the PW transfer capability TLV. 318 To conduct the MP2CP PW transfer, operator sends the MP2CP PW 319 transfer command to the source and destination T-PEs which will 320 inform MP and CP to initiate the MP2CP PW transfer process. When CP 321 gets all the information of the PW to be transferred , the CP of 322 source and destination nodes will build the LDP mapping message based 323 on the procedures described in [RFC 4447], and send the mapping 324 message to its peer T-PE or S-PE. 326 The differences between the normal and the MP2CP PW transfer Label 327 Mapping message are: 329 1. PW-OH TLV with POT value equals 1 will be encoded into the 330 "Optional Parameters" of the Mapping message for both SS-PW and 331 MS-PW MP2CP transfer. 333 2. For MS-PW, the PW path will be encoded into S-PE TLVs and Sub- 334 TLVs with local S-PE address according to [RFC6073] or ER-TLV 335 defined in [draft-ietf-pwe3-mspw-er]. 337 When the Label Mapping message is build up, it will be send to 338 source/destination T-PE for SS-PW and to S-PE for MS-PW. 340 For SS-PW, when the source/destination T-PE receives the MP2CP PW 341 transfer Label Mapping message, and also send MP2CP PW transfer Label 342 Mapping message to its peer, it will transfer the PW control from MP 343 to CP. 345 For MS-PW, when the S-PE receives the MP2CP PW transfer Label Mapping 346 message, it will decode the next hop S-PE from local IP address Sub- 347 TLVs in S-PE TLVs then forward this Label Mapping message to the next 348 hop S-PE. Only when S-PE receive the MP2CP PW transfer label mapping 349 message from the reverse direction of PW, it will transfer the PW 350 control from MP to CP. When the source/destination T-PE receives the 351 MP2CP PW transfer Label Mapping message, it will deal with it in the 352 same way as SS-PW described above. 354 When ER-TLV is used in MP2CP transfer label mapping message, the next 355 hop S-PE information can be get from ER-TLV. Transfer label mapping 356 message then is forwarded to the next hop S-PE. Only when 357 S-PEreceive the MP2CP PW transfer label mapping message from the 358 reverse direction, it will transfer the PW control from MP to CP. 359 When T-PE receives the MP2CP PW transfer label mapping message, it 360 will also deal with it in the same way as SS-PW. 362 5.2.1.1. MP2CP PW Transfer Failure 364 If T-PEs or S-PEs fail to negotiate PW transfer capability, the 365 procedures in [RFC5561] SHOULD be performed. 367 Since T-LDP runs over TCP, and there is only one hop between T-PEs in 368 SS-PW, if the T-LDP sesseion is created successfully, the PW transfer 369 Label Mapping can be sent and received reliably. 371 For MS-PW, if one of the PW segment fails to transfer from MP to CP, 372 a Notification message SHOULD be sent to source/destionation T-PE 373 along the PW path to report the failure. Reverse control from CP to 374 MP is needed. And the PW segments successfully transferred SHOULD be 375 remained.Indication of reverse control from CP to MP is needed in 376 status TLV. If nodes that have already finished the transfer receive 377 the notification message, reverse transfer would be executed, and 378 then forward the notification message along the PW path to the next 379 T-PE/S-PE. If nodes that don't finish the transfer receive the 380 notification message, record information about the transfer will be 381 cleared. 383 5.2.2. PW Ownership Transfer from CP to MP 385 Since multiple PWs can share a single T-LDP session, when a PW 386 transferred from CP to MP, the LDP session may be retained for other 387 PWs. So when a PW transfers from CP to MP, a Notification message 388 carring the corresponding PW FEC and PW-OH TLV or ER-TLV with the POT 389 value equals 2 SHOULD be send out. All the other S-PEs along the PW 390 received this Notification message, SHOULD send the notification 391 message to next hop S-PE. Only when S-PE receives notification 392 message from reverse direction of PW, it will transfer the PW control 393 from CP to MP and remain the corresponding LDP session. When there 394 is no PW, the session MAY be still remained for the future use. 395 Thus, whether to delete the LDP session depends on the provider's 396 policy. If the provider want to delete the LDP session in which 397 there is no PW, the procedures in [RFC5036] can be conducted. 399 5.2.2.1. CP2MP PW Transfer Failure 401 Since the PW transfer capability is negotiated before T-LDP session 402 set up, and the T-LDP runs over TCP, CP2MP PW transfer can be 403 performed reliably. 405 For MS-PW, if one PW segment fails to transfer from CP to MP, a 406 Notification message SHOULD be sent to source/destionation T-PE to 407 report the failure. Indication of reverse control from MP to CP is 408 needed in status TLV. If nodes that have already finished the 409 transfer receive the notification message, reverse transfer from MP 410 to CP would be executed, and then forward the notification message 411 along the PW path to the next T-PE/S-PE. If nodes that don't finish 412 the transfer receive the notification message, record information 413 about the transfer will be cleared. 415 6. Security Considerations 417 [RFC5036] and [RFC4447] describe the security considerations that 418 apply to the T-LDP specification. The same security framework and 419 considerations apply to the capability mechanism described in this 420 document. 422 7. IANA considerations 424 TBD. 426 8. Acknowledgements 428 The authors would like to thank Weilian Jiang, and Kan Hu for their 429 useful comments. 431 9. References 433 9.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 439 (GMPLS) Architecture", RFC 3945, October 2004. 441 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 442 Edge (PWE3) Architecture", RFC 3985, March 2005. 444 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 445 Heron, "Pseudowire Setup and Maintenance Using the Label 446 Distribution Protocol (LDP)", RFC 4447, April 2006. 448 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 449 Specification", RFC 5036, October 2007. 451 [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, 452 "Requirements for the Conversion between Permanent 453 Connections and Switched Connections in a Generalized 454 Multiprotocol Label Switching (GMPLS) Network", RFC 5493, 455 April 2009. 457 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 458 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 460 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 461 and S. Ueno, "Requirements of an MPLS Transport Profile", 462 RFC 5654, September 2009. 464 [RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. 465 Bardalai, "RSVP-TE Signaling Extension for LSP Handover 466 from the Management Plane to the Control Plane in a GMPLS- 467 Enabled Transport Network", RFC 5852, April 2010. 469 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 470 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 472 9.2. Informative References 474 [DYNAMIC-MS-PW] 475 Luca Martini, Matthew Bocci, and Florin Balus, "Dynamic 476 Placement of Multi Segment Pseudo Wires", 477 draft-ietf-pwe3-dynamic-ms-pw-10.txt . 479 [G.8081] International Telecommunications Union, "Terms and 480 definitions for Automatically Switched Optical Networks 481 (ASON)", Recommendation G.8081/Y.1353, June 2004 . 483 [MPLS-TP-CP-FWK] 484 Loa Andersson, Lou Berger, and Luyuan Fang, "MPLS-TP 485 Control Plane Framework", 486 draft-ietf-ccamp-mpls-tp-cp-framework-02.txt . 488 [MPLS-TP-FWK] 489 M. Bocci and S. Bryant etc., "A Framework for MPLS in 490 Transport Networks", draft-ietf-mpls-tp-framework-11.txt . 492 Authors' Addresses 494 Qilei Wang 495 ZTE Corporation 497 Email: wang.qilei@zte.com.cn 499 Muliu Tao 500 ZTE Corporation 502 Phone: +86 755 26773923 503 Email: tao.muliu@zte.com.cn 504 Xihua Fu 505 ZTE Corporation 506 ZTE Plaza, No.10, Tangyan South Road, Gaoxin District 507 Xi'an 210012 508 P.R.China 510 Email: fu.xihua@zte.com.cn 512 Lizhong Jin 513 ZTE Corporation 515 Ruiquan Jing 516 China Telecom 518 Email: jingrq@ctbri.com.cn