idnits 2.17.1 draft-king-opsawg-lime-multi-layer-oam-use-case-00.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 (September 25, 2014) is 3494 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-boucadair-sfc-requirements-05 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-10 == Outdated reference: A later version (-02) exists of draft-edprop-opsawg-multi-layer-oam-ps-01 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Operations and Management Area Working Group D. King 2 Internet-Draft Lancaster University 3 Intended status: Informational M. Boucadair 4 Expires: March 25, 2014 France Telecom 5 S. Aldrin 6 Huawei USA 7 G. Mirsky 8 Ericsson 9 Mishael Wexler 10 Huawei 11 September 25, 2014 13 Use Cases and Requirements for Layer Independent OAM Management 14 in multi-layer environments 15 draft-king-opsawg-lime-multi-layer-oam-use-case-00 17 Abstract 19 As operators deploy and operate multi-layer networks and diverse 20 transport technologies, layer independent Operations, Maintenance & 21 Administration Management (OAM) would be beneficial for monitoring 22 and troubleshooting operations of network and service infrastructure. 24 This document identifies and discusses the key use-cases and high- 25 level requirements for layer independent Operations, Administration, 26 and Maintenance management to facilitate operations and maintenance 27 in multi-layer and multi-domain networks utilizing a wide variety of 28 heterogeneous networking technologies. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 25, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 66 2.1. Conventions used in this document . . . . . . . . . . . .3 67 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . .3 68 3. Layer Independent OAM Management Use Cases . . . . . . . . .5 69 3.1. Multi-layer multi-region OAM Consolidation in the 70 Management Plane . . . . . . . . . . . . . . . . . . . .5 71 3.2. Multiple layer OAMs stitching in different part of the 72 network . . . . . . . . . . . . . . . . . . . . . . . . .6 73 3.3. Stitching OAM at layer requiring L4 to L7 service . . . .8 74 3.4. Multi-Region Overlay OAM Stitching . . . . . . . . . . .10 75 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . .11 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .12 77 6. Security Considerations . . . . . . . . . . . . . . . . . . .12 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . .12 79 7.1. Normative References . . . . . . . . . . . . . . . . . .12 80 7.2. Informative References . . . . . . . . . . . . . . . . .12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .13 82 Contributor's Addresses . . . . . . . . . . . . . . . . . . . . .14 84 1. Introduction 86 This document discusses use-cases for layer independent OAM 87 management that would interface to multi-layer or multi-domain 88 networks to cover various heterogeneous networking technologies. 90 As operators and providers (e.g., network operators, data center 91 operators, service providers, etc.) continue to deploy and operate 92 multi-layer networks using a wide range of transport technologies, 93 layer independent OAM Management for stitching different layer OAMs 94 is desirable to minimise operational complexity and simplifying O&M 95 (OAM and O&M are used as specified in [RFC6291]). 97 This document discusses Layer Independent OAM in Multi-Layer 98 Environment (LIME), and is intended to: 100 o outline use cases for layer independent OAM management 101 and highlight the issues encountered with existing OAM 102 protocols; 104 o discuss OAM requirements for when designing and deploying new 105 technologies; 107 o outline eixsting technologies to facilitate layer independent OAM 108 management, including MEF work, ITU-T work, IETF related work; 110 o discuss how OAM might be configured via a unified management 111 interface: 113 * Establishment of OAM Entities(e.g., MEG, ME,MIP,MEP) and 114 Functions(e.g.,CC,CV) 116 * Adjustment of OAM Parameters 118 * Deleting OAM Entities 120 o highlight a generic OAM Management model that may be applied to 121 various OAM technologies: 123 * Defining common objects and relationships model for various 124 technologies 126 * Defining a common set of methods/calls to use for the various 127 functions 129 * Defining a common set of attributes per object 131 * Defining a common set of alarms and notifications 133 Specific OAM technology models will augment the basic OAM 134 management model defined by the LIME Group. 136 o detail OAM fault management(e.g., fault location, path 137 discovery) data model using layer independent OAM Management: 139 * Propose means to help during service diagnosis; these means may 140 rely on filtering information so that time recovery can be 141 optimized. A typical example would be efficient root cause 142 analysis that is fed with input from various layers. 144 * Propose means that would help to optimize a network as a whole 145 instead of the monolithic approach that is specific to a given 146 layer. For example, investigate means that would help in 147 computing diverse and completely disjoint paths, not only at 148 the overlay but also at the underlay. 150 o discuss the security model for layer independent OAM management: 152 * Propose means to avoid leaking OAM information to no authorized 153 entities, and to avoid altering OAM information exposed by each 154 layer. 156 * Propose means to ensure reliability of OAM information exposed 157 by each layer. 159 These requirements are not frozen; further discussion is required to 160 target key issues and scope the work to be conducted within IETF 161 accordingly. 163 The problem statement and architecture is discussed in [LIME-PS]. 165 2. Terminology 167 2.1. Conventions used in this document 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC2119 [RFC2119]. 173 2.2. Acronyms and Abbreviations 175 LIME - Layer Independent OAM in Multi-Layer Environment 177 OAM - Operations, Administration, and Maintenance 179 O&M - OAM and Management 181 ABNO -Application Based Network Operation 183 MEG - Maintenance Entity Group [RFC6371] 185 MEP - Maintenance Entity Group End Point [RFC6371] 187 MIP - Maintenance Entity Group Intermediate Point [RFC6371] 189 CC -Continuity Check [RFC7276] 191 CV - Connectivity Verification [RFC7276] 193 CFM -Connectivity Fault Management 195 EFM - Ethernet In the First Mile 197 BFD -Bidirectional Forwarding Detect 199 LBM -Loopback Message 201 LBR -Loopback Reply 203 LTM -Linktrace Message 204 LTR -Linktrace Reply 206 OSS -Operation Support System 208 NMS -Network Management System 210 SFC -Service Function Chain [I-D.ietf-sfc-problem-statement] 212 SF - Service Function [I-D.ietf-sfc-problem-statement] 214 TES -Tenant End System [I-D.ietf-nvo3-framework ] 216 NVO3 -Network Virtualization Overlay [I-D.ietf-nvo3-overlay- 217 problem-statement] 219 WAN -Wide Area Network 221 VXLAN -Virtual eXtensible Local Area Network [RFC7348] 223 NVGRE -Network Virtualization using Generic Routing Encapsulation 224 [I-D.sridharan-virtualization-nvgre] 226 PW -Pseudowire 228 LSP -Label Switching Path 230 MPLS -Multi-Protocol Label Switching 232 3. Layer Independent OAM Management Use Cases 234 3.1. Multi-layer multi-region OAM Consolidation in the Management Plane 236 A multi-layer multi-region network will often require data traffic 237 between two customer edges to be transported across two regions, as 238 illustrated in figure 2. In this scenario the same domain and 239 multiple layer OAMs(i.e.,PW OAM,end to end LSP OAM, segment LSP OAM) 240 are used. 242 For PW OAM is used at the customer level for monitoring the end-to 243 -end connection between the two Provider edges(PEs), while end to end 244 LSP OAM and segment LSP OAM is used at the provider level for 245 monitoring the segment LSP and end to end LSP respectively. A 246 segment is between MEPs and The OAM in each segment is independent of 247 any other segment. 249 +--------------------------------------------------+ 250 | Carrier 1 | 251 |+---------------------+ +---------------------+| 252 || Region1 | | Region2 || 253 +----+ || +----+ +-+ +----+ | | +----+ +-+ +----+|| +----+ 254 | PE ------| PE --|P|--| PE ----------| PE ----|P|--| PE ------| PE | 255 +----+ || +----+ +-+ +----+ | | +----+ +-+ +----+|| +----+ 256 || | | || 257 |+---------------------+ +---------------------+| 258 +--------------------------------------------------+ 260 End to end LSP OAM 261 o----------D----------------------------------------D----------D 262 Segment LSP 263 Carrier 1 LSP OAM segment OAM 264 o------------D-------------D-------------o-o--------o 265 Carrier1 Region 1 Carrier1 Region 2 266 LSP OAM segment LSP OAM segment 268 o----D-------o o-------D------o 269 o Maintenance Endpoint(MEP) 270 D Maintenance Intermediary point (MIP) 272 Figure 1: Multi-Region Multi-Layer OAM 274 With single OSS/NMS in the management plane, customized service 275 diagnose can be provided, e.g., 277 o initiating tests on any layer in the multi-layer network 279 o initiating test on any segment of the end to end path 281 o initiate test on end to end path 283 o check end-to-end connectivity test results across a multi-layer 284 network even when each layer runs a different technology. 286 3.2. Multiple layer OAMs stitching in different part of the network 288 Figure 2 illustrates a multi-layer network in which data traffic 289 between two access nodes is transported through access section 290 between access node(AN) and aggregation node(AGG Node) and 291 aggregation section between aggregation node and edge node and even 292 core section from edge node to Internet or WAN. EFM OAM is used at 293 the access section for monitoring the access connection between the 294 access node and aggregation node, CFM OAM and IP OAM is used at the 295 aggregation section for monitoring end to end connection between 296 aggregation node and edge node. BFD is used at the core section for 297 monitoring end to end connection from edge node to Internet or WAN. 299 | | | | 300 ----EFM---------CFM/IP-----------BFD---------| 301 | | | | 302 +---|----------|---+ | | 303 | +----+ +-----+| | | 304 | | AN | |AGG +---+ | | 305 | +----+ |Node || | | | 306 | +-----+| | +------+ +-----+ /-----\ 307 +------------------+ | | Edge +---+Core |++|Internet| 308 ---| Node | |Node | | | 309 +------------------+ | +------+ +-----+ \-----/ 310 | ------ |AGG || | 311 | | AN | |Node +---+ 312 | +----+ +-----+| | 313 | +----+ +-----+| | 314 | | AN | |AGG || | 315 | +----+ |Node +---- +-------+ +-----+ /----\ 316 | +-----+| | | Edge +--+Core |+-+| WAN || 317 +------------------+ --- Node | |Node | | | 318 +------------------+ | +-------+ +-----+ \----/ 319 | +-----+| | | | 320 | +----+ |AGG +---+ | | 321 | | AN | |Node || | | 322 | +----+ +-----+| | | 323 +---|----------|---+ | | 324 | | | | 325 ----Access---Aggregation-| -----Core---------- 326 | | | | 328 Figure 2 330 With single OSS/NMS in the management plane, different layer OAM at 331 the different part of the network can be stitching together to 332 provide unified view for network problem reporting by consuming all 333 status reports from the network, aggregating them, correlating them. 335 In addition, a user who wishes to issue a IP Ping Command or use 336 connectivity verification command in the Ethernet layer can do so in 337 the same manner regardless of the underlying protocol or transport 338 technology. This can be achieved by invoking IP Ping Command or 339 connectivity verification command through uniform interface between 340 management plane and data plane. Consider a scenario where an IP 341 ping to Edge node B from Aggregation node A failed. Between AGG node 342 A and Edge Node B there are IEEE 802.1 [IEEE-802.1Q] bridges a,b and 343 c. Let's assume a,b and c are using [IEEE-802.1ag] CFM. IP layer 344 Ping can be invoked using uniform interface between single OSS/NMS 345 and AGG node A. Upon detecting IP layer ping failure, the user may 346 wish to "go down" to the Ethernet layer and issue the corresponding 347 fault verification (LBM/LBR) and fault isolation (LTM/LTR) tools, 348 using the same uniform interface used by IP Layer Ping. 350 3.3. Stitching OAM at layer requiring L4 to L7 service 352 In Service Function Chain ([I-D.ietf-sfc-problem-statement]), the 353 service packets are steered through a set of Service Function 354 distributed in the network. Overlay technologies and other tunneling 355 techniques can be used to stitch these Service Function Nodes in 356 order to form end to end path (see Figure 3). 358 +---------+ 359 | Single | 360 |----------------------| OSS/NMS ------------------------- 361 | +---------+ | 362 | | 363 | ---------------------- | 364 | /////-- --\\\\\ | 365 | ///// \\\\\ | 366 | //// |->SF1 SF2-+ SF3----+ +->Proxy-SF4 \\\\ | 367 |/ | | ^ | ^ | | \| 368 | V | | | | | 369 +-------+ | +---+-+ | +-+---+ | | +-----+ +-----+ 370 | SFC | |--| +<+ | |<- |->| | | | 371 |Ingress|------ NE-a -------+NE-b +------- NE-c --------+NE-d | 372 | Node | | | | | | | | | 373 +-------+ +-----+ +-----+ +-----+ +-----+ 375 \\\\ //// 376 \\\\\ ///// 377 \\\\\-- --///// 378 ---------------------- 379 SF OAM 380 o o o o D 381 SFC OAM 382 o-------------D---D-----------D-------------D 384 NVO3 OAM 385 o---------------o----------------D----------D----------------o 387 Link OAM 388 o--o---o--o- o---o o--o--o--o 390 o Maintenance Endpoint(MEP) 391 D Maintenance Intermediary point (MIP) 392 Layer7- SF1 --------------------------------------------------- 393 Layer6------------------------F4 -------------------------------- 394 Layer5------------ SF3------------------------------------------- 395 Layer4---SF2 ---------------------------------- ----------------- 397 Figure 3: Stitching OAM at layer requiring L4 to L7 service 399 In figure 3, Link OAM is used between any two adjacent SFs hosted in 400 the same service node in the SFC layer or between a SF and the 401 service node hosting that SF. NVO3 OAM is used between SFC ingress 402 node and NVO3-enabled Network element or any two NVO3-enabled network 403 element in the SFC domain. SFC OAM is used between a set of Service 404 Functions belong to the same service function chain in the SFC 405 domain. SF OAM is used between SF and SF Controller. 407 When the service packet enters into the network, OAM information 408 needs to be imposed by ingress node of the network into the OAM 409 packet (e.g., packet header extension or TLV extension in the overlay 410 header) and pass through the network in the same path as the service 411 traffic and processed by a set of Service Functions that are hosted 412 in Service Nodes and located in different layers requiring L4-L7 413 service. 415 When any Service Nodes or any service segment between two Service 416 Nodes fails to deliver user traffic, there is a need to provide a 417 tool that would enable users to detect such failures (e.g., fault 418 element in the path), and a mechanism to isolate faults. 420 In case of several SFs co-located in the same Service Node, the 421 packet is processed by all SFs in the Service Node, Once the packet 422 is successfully handled by one SF, the packet is forwarded to the 423 next SF that is in the same Service Node. 425 When the packet leaves the network, the OAM information needs to be 426 stripped out from the packet. 428 To provide unified view of OAM information from different layers and 429 different segment of the Service Function Path, these OAM information 430 needs to gathered from various layer using different encapsulation 431 and tunneling techniques and abstracted and provided to the 432 management application via the uniform management interface. 434 As indicated in [I-D.boucadair-sfc-requirements], the following OAM 435 functions are to be supported: 437 o Support means to verify the completion of the forwarding actions 438 until the SFC Border Node is reached (see Section 3.4.1 of 439 [RFC5706]). 441 o Support means to ensure coherent classification rules are 442 installed in and enforced by all the Classifiers of the SFC- 443 enabled domain. 445 o Support means to correlate classification policies with observed 446 forwarding actions. 448 o Support in-band liveliness and functionality checking mechanisms 449 for the instantiated Service Function Chains and the Service 450 Functions that belong to these chains. 452 Other service diagnosis and troubleshooting requirements are 453 discussed in [I-D.boucadair-sfc-requirements]. 455 3.4. Multi-Operator OAM Stitching 457 Multi-operator networks can be abstracted, virtualized and shared by 458 several tenants. A tenant has an end-to-end view of its virtual 459 network. Figure 5 illustrates an example of multi-layer 460 multi-operator network in which data traffic between two tenant 461 systems is transported across three operators. 463 +--------+ 464 -----------------------------+ Tenant +----------------------------- 465 | | | | 466 | +--------+ | 467 | | | 468 | + - - - - - - + | 469 | | Abstraction | | 470 | - - - --- - - - - | Layer (opt.)| - - - - - - - - | 471 | | + - - - - - - + | | 472 | | | | | 473 | +--------+ +--------+ +--------+ | 474 | + Single + + Single + + Single + | 475 | |OSS/NMS | |OSS/NMS | |OSS/NMS | | 476 | +--------+ +--------+ +--------+ | 477 | --------- --------- --------- | 478 | /// \\\ /// \\\ /// \\\ | 479 | / \ / \ / \ | 480 | | | | | | | | 481 +-----+ +-----+ +-----+ +----+ +-----+ +-----+ 482 | A1 | | A2 | | B1 | | B2 | | C1 | | C2 | 483 +-----+ +-----+ +-----+ +----+ +-----+ +-----+ 484 | | | | | | 485 \ / \ / \ / 486 \\\ /// \\\ /// \\\ /// 487 --------- --------- --------- 489 Oper A Oper B Oper C 490 o-------------D----------D---------------D----D-----------------o 492 Figure 4: Multi-Operator OAM Stitching 494 Each operator is using a different management system and is handling 495 only a segment of the whole end-to-end service. Each operator can 496 also use a different technology to transport the clients over its 497 segment. Within one operator region, multi-layers acn be used, e.g. 498 IP over WDM to transport L3VPN service. 500 The tenants has to view an end-to-end OAM model via abstraction of 501 each region and/or using abstraction layer between tenants and the 502 OSS/NMSs. 504 4. Requirements 506 This section identifies high-level requirements to fulfill layer 507 independent OAM management in Multi-layer Environment to support 508 various use cases discussed in the previous sections. 510 o The interfaces between the management entity and each Managed 511 device in one administrative domain SHOULD support standards- 512 based abstraction with a common information/data model. 514 o The management entity should be able to create a single unified 515 view of OAM information that is common to various layers, various 516 segment of the same domain. 518 o The management entity should provide an unified management 519 interface for multiple OAM technologies that will expose a common 520 set of management interface capabilities for different OAM 521 technologies (e.g. Continuity Check(CC),Connectivity 522 Verification(CV)). The management interface implementation will 523 convert the defined common management capabilities to the OAM 524 technology specific operations. 526 o The management entity should Model OAM operations management and 527 represent OAM information and mechanisms in the same way using 528 YANG at the management plane to provide consistent configuration, 529 reporting, and presentation for the OAM mechanisms. Specific OAM 530 technology models will augment the basic OAM management model 531 defined by the LIME Group. 533 o The following capability for layer independent OAM management 534 entity should be supported: 536 * Support customized service diagnostic. 538 * Support diagnose the availability of a end-to-end path. 540 * Support diagnose the availability of a segment Path that is 541 sub-path of end to end path. 543 * Support verification on the correct value of Path ID between 544 any two pair of overlay nodes or any two pair of service nodes. 546 * Support out-band liveliness and functionality checking 547 mechanisms for the overlay node or service node. 549 5. IANA Considerations 551 This memo includes no request to IANA. 553 6. Security Considerations 555 TBD. 557 7. References 559 7.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", March 1997. 564 7.2. Informative References 566 [I-D.boucadair-sfc-requirements] 567 Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., 568 Pignataro, C., and K. Kengo, "Requirements for Service 569 Function Chaining (SFC)", draft-boucadair-sfc- 570 requirements-05 (work in progress), July 2014. 572 [I-D.ietf-sfc-problem-statement] 573 Quinn, P. and T. Nadeau, "Service Function Chaining 574 Problem Statement", draft-ietf-sfc-problem-statement-10 575 (work in progress), August 2014. 577 [IEEE-802.1Q] 578 IEEE 802.1Q-2011, "IEEE standard for local and 579 metropolitan area networks: Media access control (MAC) 580 bridges and virtual bridged local area networks", August 581 2011. 583 [IEEE-802.1ag] 584 IEEE 802.1ag-2007, "IEEE Standard for Local and 585 Metropolitan Area Networks Virtual Bridged Local Area 586 Networks Amendment 5: Connectivity Fault Management", 587 December 2007. 589 [LIME-PS] Taylor, T. and Q. Wu, "Problem Statement and Architecture 590 for Layer-Independent OAM in Multi-Layer Environment", ID 591 draft-edprop-opsawg-multi-layer-oam-ps-01, (work in 592 progress). 594 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 595 Management of New Protocols and Protocol Extensions", RFC 596 5706, November 2009. 598 [RFC6291] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., 599 and S. Mansfield, "Guidelines for the Use of the "OAM" 600 Acronym in the IETF", RFC 6291, June 2011. 602 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 603 Maintenance Framework for MPLS-Based Transport Networks", 604 RFC 6371, September 2011. 606 [RFC7276] Mizrahi, T. et al., "An Overview of Operations, 607 Administration, and Maintenance (OAM) Tools," June 2014 609 [RFC7348] 611 [I-D.sridharan-virtualization-nvgre] 612 Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, 613 Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., 614 and C. Tumuluri, "NVGRE: Network Virtualization using 615 Generic Routing Encapsulation", draft-sridharan- 616 virtualization-nvgre-05 (work in progress). 618 Authors' Addresses 620 Daniel King 621 Lancaster University 622 UK 624 Email: d.king@lancaster.ac.uk 626 Mohamed Boucadair 627 France Telecom 628 Rennes 35000 629 France 631 Email: mohamed.boucadair@orange.com 633 Sam Aldrin 634 Huawei Technologies USA 635 2330 Central Expressway 636 NSanta Clara, CA 95051 637 USA 639 Email: aldrin.ietf@gmail.com 641 Greg Mirsky 642 Ericsson 644 Email: gregory.mirsky@ericsson.com 645 Mishael Wexler 646 Huawei 647 Riesstr. 25 648 Munich 80992 649 Germany 650 Email: mishael.wexler@huawei.com 652 Contributors' Addresses 654 Qin Wu 655 Huawei 656 101 Software Avenue, Yuhua District 657 Nanjing, Jiangsu 210012 658 China 659 Email: bill.wu@huawei.com