idnits 2.17.1 draft-ietf-teas-gmpls-resource-sharing-proc-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 16, 2016) is 2809 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group X. Zhang 3 Internet-Draft H. Zheng, Ed. 4 Intended Status: Informational Huawei Technologies 5 Expires: February 17, 2017 R. Gandhi, Ed. 6 Z. Ali 7 Cisco Systems, Inc. 8 P. Brzozowski 9 ADVA Optical 10 August 16, 2016 12 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and 13 Resource Sharing 14 draft-ietf-teas-gmpls-resource-sharing-proc-05 16 Abstract 18 In non-packet transport networks, there are requirements where 19 Generalized Multi-Protocol Label Switching (GMPLS) end-to-end 20 recovery scheme needs to employ restoration Label Switched Path (LSP) 21 while keeping resources for the working and/or protecting LSPs 22 reserved in the network after the failure occurs. 24 This document reviews how the LSP association is to be provided using 25 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 26 signaling in the context of GMPLS end-to-end recovery scheme when 27 using restoration LSP where failed LSP is not torn down. In 28 addition, this document discusses resource sharing-based setup and 29 teardown of LSPs as well as LSP reversion procedures. No new 30 signaling extensions are defined by this document, and it is strictly 31 informative in nature. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4 73 2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6 75 3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 7 76 3.1. Restoration LSP Association . . . . . . . . . . . . . . . 7 77 3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7 78 3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9 79 3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 9 80 3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 10 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines 93 a set of protocols, including Open Shortest Path First - Traffic 94 Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - 95 Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used 96 to setup Label Switched Paths (LSPs) in non-packet transport 97 networks. The GMPLS protocol extends MPLS to support interfaces 98 capable of Time Division Multiplexing (TDM), Lambda Switching and 99 Fiber Switching. These switching technologies provide several 100 protection schemes [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). 102 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 103 signaling has been extended to support various GMPLS recovery 104 schemes, such as end-to-end recovery [RFC4872] and segment recovery 105 [RFC4873]. As described in [RFC6689], ASSOCIATION object can be used 106 to identify the LSPs for restoration using Association Type set to 107 "Recovery" [RFC4872] and also identify the LSPs for resource sharing 108 using Association Type set to "Resource Sharing" [RFC4873]. 109 [RFC6689] Section 2.2 reviews the procedure for providing LSP 110 associations for GMPLS end-to-end recovery and Section 2.4 reviews 111 the procedure for providing LSP associations for sharing resources. 113 In GMPLS end-to-end recovery schemes generally considered, 114 restoration LSP is signaled after the failure has been detected and 115 notified on the working LSP. For revertive recovery mode, a 116 restoration LSP is signaled while working LSP and/or protecting LSP 117 are not torn down in control plane due to a failure. In non-packet 118 transport networks, as working LSPs are typically signaled over a 119 nominal path, service providers would like to keep resources 120 associated with the working LSPs reserved. This is to make sure that 121 the service (working LSP) can be reverted to the nominal path when 122 the failure is repaired to provide deterministic behavior and 123 guaranteed Service Level Agreement (SLA). 125 In this document, procedures are reviewed for GMPLS LSP associations, 126 resource sharing based LSP setup, teardown and LSP reversion for 127 non-packet transport networks, including following: 129 o Review the procedure for providing LSP associations for the GMPLS 130 end-to-end recovery using restoration LSP where working and 131 protecting LSPs are not torn down and resources are kept reserved in 132 the network after the failure. 134 o In [RFC3209], the make-before-break (MBB) method assumes the old 135 and new LSPs share the SESSION object and signal Shared Explicit (SE) 136 flag in SESSION_ATTRIBUTE object for sharing resources. According to 138 [RFC6689], ASSOCIATION object with Association Type "Resource 139 Sharing" enables the sharing of resources across LSPs with different 140 SESSION objects. Procedure for resource sharing using the SE flag in 141 conjunction with ASSOCIATION object is discussed in this document. 143 o When using end-to-end recovery with revertive mode, methods for 144 LSP reversion and resource sharing are summarized in this document. 146 This document is strictly informative in nature and does not define 147 any RSVP-TE signaling extensions. 149 2. Overview 151 The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and 152 being considered in this document, "fully dynamic rerouting switches 153 normal traffic to an alternate LSP that is not even partially 154 established only after the working LSP failure occurs. The new 155 alternate route is selected at the LSP head-end node, it may reuse 156 resources of the failed LSP at intermediate nodes and may include 157 additional intermediate nodes and/or links". Two examples, 1+R and 158 1+1+R are described in the following sections. 160 2.1. 1+R Restoration 162 One example of the recovery scheme considered in this document is 1+R 163 recovery. The 1+R recovery is exemplified in Figure 1. In this 164 example, working LSP on path A-B-C-Z is pre-established. Typically 165 after a failure detection and notification on the working LSP, a 166 second LSP on path A-H-I-J-Z is established as a restoration LSP. 167 Unlike protection LSP, restoration LSP is signaled per need basis. 169 +-----+ +-----+ +-----+ +-----+ 170 | A +----+ B +-----+ C +-----+ Z | 171 +--+--+ +-----+ +-----+ +--+--+ 172 \ / 173 \ / 174 +--+--+ +-----+ +--+--+ 175 | H +-------+ I +--------+ J | 176 +-----+ +-----+ +-----+ 178 Figure 1: An Example of 1+R Recovery Scheme 180 During failure switchover with 1+R recovery scheme, in general, 181 working LSP resources are not released so that working and 182 restoration LSPs coexist in the network. Nonetheless, working and 183 restoration LSPs can share network resources. Typically when failure 184 is recovered on the working LSP, restoration LSP is no longer 185 required and torn down, while the traffic is reverted to the original 186 working LSP. 188 2.2. 1+1+R Restoration 190 Another example of the recovery scheme considered in this document is 191 1+1+R. In 1+1+R, a restoration LSP is signaled for the working LSP 192 and/or the protecting LSP after the failure has been detected, and 193 this recovery is exemplified in Figure 2. 195 +-----+ +-----+ +-----+ 196 | D +-------+ E +--------+ F | 197 +--+--+ +-----+ +--+--+ 198 / \ 199 / \ 200 +--+--+ +-----+ +-----+ +--+--+ 201 | A +----+ B +-----+ C +-----+ Z | 202 +--+--+ +-----+ +-----+ +--+--+ 203 \ / 204 \ / 205 +--+--+ +-----+ +--+--+ 206 | H +-------+ I +--------+ J | 207 +-----+ +-----+ +-----+ 209 Figure 2: An Example of 1+1+R Recovery Scheme 211 In this example, working LSP on path A-B-C-Z and protecting LSP on 212 path A-D-E-F-Z are pre-established. After a failure detection and 213 notification on a working LSP or protecting LSP, a third LSP on path 214 A-H-I-J-Z is established as a restoration LSP. The restoration LSP 215 in this case provides protection against a second order failure. 216 During failure switchover with 1+1+R recovery scheme, in general, 217 failed LSP resources are not released so that working, protecting and 218 restoration LSPs coexist in the network. Nonetheless, restoration 219 LSP with working LSP it is restoring as well as restoration LSP with 220 protecting LSP it is restoring can share network resources. 221 Typically, restoration LSP is torn down when the failure on the 222 original (working or protecting) LSP is repaired and the traffic is 223 reverted to the original LSP. 225 There are four possible models when using restoration LSP with 1+1+R 226 recovery scheme: 228 o A restoration LSP is signaled after either working or protecting 229 LSP fails. Only one restoration LSP is present at a time. 231 o A restoration LSP is signaled after either working or protecting 232 LSP fails. Two different restoration LSPs may be present, one for 233 the working LSP and one for the protecting LSP. 235 o A restoration LSP is signaled after both working and protecting 236 LSPs fail. Only one restoration LSP is present. 238 o Two different restoration LSPs are signaled after both working and 239 protecting LSPs fail, one for the working LSP and one for the 240 protecting LSP. 242 In all models discussed, if the restoration LSP also fails, it is 243 torn down and a new restoration LSP is signaled. 245 2.3. Resource Sharing By Restoration LSP 247 +-----+ +-----+ 248 | F +------+ G +--------+ 249 +--+--+ +-----+ | 250 | | 251 | | 252 +-----+ +-----+ +--+--+ +-----+ +--+--+ 253 | A +----+ B +-----+ C +--X---+ D +-----+ E | 254 +-----+ +-----+ +-----+ +-----+ +-----+ 256 Figure 3: Resource Sharing in 1+R Recovery Scheme 258 Using the network shown in Figure 3 as an example, LSP1 (A-B-C-D-E) 259 is the working LSP and it allows for resource sharing when the LSP 260 traffic is dynamically restored after the link failure. Upon 261 detecting the failure of a link along the LSP1, e.g. Link C-D, node A 262 needs to decide which alternative path it will use to signal 263 restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is 264 chosen as the restoration LSP path and the resources on the path 265 segment A-B-C are re-used by this LSP when the working LSP is not 266 torn down (e.g. in 1+R recovery scheme). 268 3. RSVP-TE Signaling Procedure 270 3.1. Restoration LSP Association 272 Where GMPLS end-to-end recovery scheme needs to employ a restoration 273 LSP while keeping resources for the working and/or protecting LSPs 274 reserved in the network after the failure, the restoration LSP is 275 signaled with an ASSOCIATION object that has Association Type set to 276 "Recovery" [RFC4872], the Association ID and the Association Source 277 set to the corresponding Association ID and the Association Source 278 signaled in the LSP it is restoring. For example, when a restoration 279 LSP is signaled for a failed working LSP, the ASSOCIATION object in 280 the restoration LSP contains the Association ID and Association 281 Source set to the Association ID and Association Source signaled in 282 the working LSP for the "Recovery" Association Type. Similarly, when 283 a restoration LSP is signaled for a failed protecting LSP, the 284 ASSOCIATION object in the restoration LSP contains the Association ID 285 and Association Source set to the Association ID and Association 286 Source signaled in the protecting LSP for the "Recovery" Association 287 Type. 289 The procedure for signaling the PROTECTION object is specified in 290 [RFC4872]. Specifically, the restoration LSP used for a working LSP 291 is signaled with P bit cleared in the PROTECTION object and the 292 restoration LSP used for a protecting LSP is signaled with P bit set 293 in the PROTECTION object. 295 3.2. Resource Sharing-based Restoration LSP Setup 297 GMPLS LSPs can share resources during LSP setup if they have Shared 298 Explicit (SE) flag set in their SESSION_ATTRIBUTE objects and: 300 o As defined in [RFC3209], LSPs have identical SESSION objects 301 and/or 303 o As defined in [RFC6689], LSPs have matching ASSOCIATION object 304 with Association Type set to "Resource Sharing". LSPs in this case 305 can have different SESSION objects i.e. different Tunnel ID, Source 306 and/or Destination. 308 As described in [RFC3209], Section 2.5, the purpose of make-before- 309 break is "not to disrupt traffic, or adversely impact network 310 operations while TE tunnel rerouting is in progress". In non-packet 311 transport networks, the label has a mapping into the data plane 312 resource used and the nodes along the LSP need to send triggering 313 commands to data plane for setting up cross-connections accordingly 314 during the RSVP-TE signaling procedure. Due to the nature of the 315 non-packet transport networks, node may not be able to fulfill this 316 purpose when sharing resources in some scenarios. 318 For LSP restoration upon failure, as explained in Section 11 of 319 [RFC4872], reroute procedure may re-use existing resources. The 320 behavior of the intermediate nodes during rerouting process to 321 reconfigure cross-connections does not further impact the traffic 322 since it has been interrupted due to the already failed LSP. 324 The node behavior for setting up the restoration LSP can be 325 categorized into the following three categories: 327 Table 1: Node Behavior during Restoration LSP Setup 329 ---------+--------------------------------------------------------- 330 Category | Node Behavior during Restoration LSP Setup 331 ---------+--------------------------------------------------------- 332 C1 + Reusing existing resource on both input and output 333 + interfaces (nodes A & B in Figure 3). 334 + 335 + This type of nodes only needs to book the existing 336 + resources and no cross-connection setup 337 + command is needed. 338 ---------+--------------------------------------------------------- 339 C2 + Reusing existing resource only on one of the interfaces, 340 + either input or output interfaces and need to use new 341 + resource on the other interface. 342 + (nodes C & E in Figure 3). 343 + 344 + This type of nodes needs to book the resources and send 345 + the re-configuration cross-connection command to its 346 + corresponding data plane node on the interfaces where new 347 + resources are needed and re-use the 348 + existing resources on the other interfaces. 349 ---------+--------------------------------------------------------- 350 C3 + Using new resources on both interfaces. 351 + (nodes F & G in Figure 3). 352 + 353 + This type of nodes needs to book the new resources 354 + and send the cross-connection setup 355 + command on both interfaces. 356 ---------+--------------------------------------------------------- 358 Depending on whether the resource is re-used or not, the node 359 behaviors differ. This deviates from normal LSP setup since some 360 nodes do not need to re-configure the cross-connection, and it should 361 not be viewed as an error. Also, the judgment whether the control 362 plane node needs to send a cross-connection setup/modification 363 command to its corresponding data plane node(s) relies on the check 364 whether the LSPs are sharing resources. 366 3.3. LSP Reversion 368 If the end-to-end LSP recovery is revertive, as described in Section 369 2, traffic can be reverted from the restoration LSP to the working or 370 protecting LSP after its failure is recovered. The LSP reversion can 371 be achieved using two methods: 373 1. Make-while-break Reversion, where resources associated with 374 working or protecting LSP are reconfigured while removing 375 reservations for the restoration LSP. 377 2. Make-before-break Reversion, where resources associated with 378 working or protecting LSP are reconfigured before removing 379 reservations for the restoration LSP. 381 In non-packet transport networks, both of the above reversion methods 382 will result in some traffic disruption when the restoration LSP and 383 the LSP being restored are sharing resources and the 384 cross-connections need to be reconfigured on intermediate nodes. 386 3.3.1. Make-while-break Reversion 388 In this reversion method, restoration LSP is simply requested to be 389 deleted by the head-end. Removing reservations for restoration LSP 390 triggers reconfiguration of resources associated with working or 391 protecting LSP on every node where resources are shared. Whenever 392 reservation for restoration LSP is removed from a node, data plane 393 configuration changes to reflect reservations of working or 394 protection LSP as signaling progresses. Eventually, after the whole 395 restoration LSP is deleted, data plane configuration will fully match 396 working or protecting LSP reservations on the whole path. Thus 397 reversion is complete. 399 Make-while-break, while being relatively simple in its logic, has few 400 limitations as follows which may not be acceptable in some networks: 402 o No rollback 404 Deletion of restoration LSPs is not a revertive process. If for some 405 reason reconfiguration of data plane on one of the nodes to match 406 working or protection LSP reservations fails, falling back to 407 restoration LSP is no longer an option, as its state might have 408 already been removed from other nodes. 410 o No completion guarantee 412 Deletion of an LSP provides no guarantees of completion. In 413 particular, if RSVP packets are lost due to nodal or DCN failures it 414 is possible for an LSP to be only partially deleted. To mitigate 415 this, RSVP could maintain soft state reservations and hence 416 eventually remove remaining reservations due to refresh timeouts. 417 This approach is not feasible in non-packet transport networks 418 however, where control and data channels are often separated and 419 hence soft state reservations are not useful. 421 Finally, one could argue that graceful LSP deletion [RFC3473] would 422 provide guarantee of completion. While this is true for most cases, 423 many implementations will time out graceful deletion if LSP is not 424 removed within certain amount of time, e.g. due to a transit node 425 fault. After that, deletion procedures which provide no completion 426 guarantees will be attempted. Hence, in corner cases completion 427 guarantee cannot be provided. 429 o No explicit notification of completion to head-end node 431 In some cases, it may be useful for a head-end node to know when the 432 data plane has been reconfigured to match working or protection LSP 433 reservations. This knowledge could be used for initiating operations 434 like enabling alarm monitoring, power equalization and others. 435 Unfortunately, for the reasons mentioned above, make-while-break 436 reversion lacks such explicit notification. 438 3.3.2. Make-before-break Reversion 440 This reversion method can be used to overcome limitations of 441 make-while-break reversion. It is similar in spirit to MBB concept 442 used for re-optimization. Instead of relying on deletion of 443 restoration LSP, head-end chooses to establish a new LSP to 444 reconfigure resources on the working or protection LSP path, and uses 445 identical ASSOCIATION and PROTECTION objects from the LSP it is 446 replacing. Only if setup of this LSP is successful will other 447 (restoration and working/protecting) LSPs be deleted by the head-end. 448 MBB reversion consists of two parts: 450 A) Make part: 452 Creating a new reversion LSP following working or protection LSP's 453 path. Reversion LSP is sharing resources both with working and 454 restoration LSPs. As reversion LSP is created, resources are 455 reconfigured to match its reservations. Hence, after reversion LSP 456 is created, data plane configuration essentially reflects working or 457 protecting LSP reservations. 459 B) Break part: 461 After "make" part is finished, working and restoration LSPs are torn 462 down. Removing reservations for working and restoration LSPs does 463 not cause any resource reconfiguration on reversion LSP's path - 464 nodes follow same procedures as for "break" part of any MBB 465 operation. Hence, after working and restoration LSPs are removed, 466 data plane configuration is exactly the same as before starting 467 restoration. Thus, reversion is complete. 469 MBB reversion uses make-before-break characteristics to overcome 470 challenges related to make-while-break reversion as follow: 472 o Rollback 474 If "make" part fails, (existing) restoration LSP will still be used 475 to carry existing traffic. Same logic applies here as for any MBB 476 operation failure. 478 o Completion guarantee 480 LSP setup is resilient against RSVP message loss, as Path and Resv 481 messages are refreshed periodically. Hence, given that network 482 recovers its DCN eventually, reversion LSP setup is guaranteed to 483 finish with either success or failure. 485 o Explicit notification of completion to head-end node 487 Head-end knows that data plane has been reconfigured to match working 488 or protection LSP reservations on intermediate nodes when it receives 489 Resv for the reversion LSP. 491 4. Security Considerations 493 This document reviews procedures defined in [RFC3209] [RFC4872] 494 [RFC4873] and [RFC6689] and does not define any new procedure. This 495 document does not introduce any new security issues other than those 496 already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. 498 5. IANA Considerations 500 This informational document does not make any request for IANA 501 action. 503 6. References 505 6.1. Normative References 507 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 508 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 509 Tunnels", RFC 3209, December 2001. 511 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 512 Switching (GMPLS) Signaling Resource ReserVation 513 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 514 3473, January 2003. 516 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 517 Ed., "RSVP-TE Extensions in Support of End-to-End 518 Generalized Multi-Protocol Label Switching (GMPLS) 519 Recovery", RFC 4872, May 2007. 521 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 522 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 524 [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC 525 6689, July 2012. 527 6.2. Informative References 529 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 530 (GMPLS) Architecture", RFC 3945, October 2004. 532 [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in 533 Support of Generalized Multi-Protocol Label Switching 534 (GMPLS)", RFC 4203, October 2005. 536 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., 537 "Generalized Multiprotocol Label Switching (GMPLS) 538 Recovery Functional Specification", RFC 4426, March 2006. 540 [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection 541 and Restoration) Terminology for Generalized 542 Multi-Protocol Label Switching", RFC 4427, March 2006. 544 Acknowledgements 546 The authors would like to thank George Swallow for the discussions on 547 the GMPLS restoration. The authors would like to thank Lou Berger 548 for the guidance on this work. The authors would also like to thank 549 Lou Berger and Vishnu Pavan Beeram for reviewing this document and 550 providing valuable comments. 552 Contributors 554 Gabriele Maria Galimberti 555 Cisco Systems, Inc. 557 EMail: ggalimbe@cisco.com 559 Authors' Addresses 561 Xian Zhang 562 Huawei Technologies 563 F3-1-B R&D Center, Huawei Base 564 Bantian, Longgang District 565 Shenzhen 518129 P.R.China 567 EMail: zhang.xian@huawei.com 569 Haomian Zheng (editor) 570 Huawei Technologies 571 F3-1-B R&D Center, Huawei Base 572 Bantian, Longgang District 573 Shenzhen 518129 P.R.China 575 EMail: zhenghaomian@huawei.com 577 Rakesh Gandhi (editor) 578 Cisco Systems, Inc. 580 EMail: rgandhi@cisco.com 582 Zafar Ali 583 Cisco Systems, Inc. 585 EMail: zali@cisco.com 587 Pawel Brzozowski 588 ADVA Optical 590 EMail: PBrzozowski@advaoptical.com