idnits 2.17.1 draft-mwdt-ccamp-problem-statement-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 (July 8, 2016) is 2848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7277' is mentioned on line 155, but not defined ** Obsolete undefined reference: RFC 7277 (Obsoleted by RFC 8344) == Missing Reference: 'RFC 2863' is mentioned on line 159, but not defined == Unused Reference: 'RFC2234' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'I-D.ahlberg-ccamp-microwave-radio-link' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC7227' is defined on line 554, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-22 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP WG J. Ahlberg 3 Internet-Draft Ericsson AB 4 Intended status: Informational LM. Contreras 5 Expires: January 9, 2017 TID 6 A. Ye Min 7 Huawei 8 M. Vaupotic 9 Aviat Networks 10 J. Tantsura 11 Individual 12 K. Kawada 13 NEC Corporation 14 X. Li 15 NEC Laboratories Europe 16 I. Akiyoshi 17 NEC 18 July 8, 2016 20 A framework for Management and Control of microwave and millimeter wave 21 interface parameters - problem statement 22 draft-mwdt-ccamp-problem-statement-00 24 Abstract 26 To ensure an efficient data transport, meeting the requirements 27 requested by today's transport services, the unification of control 28 and management of microwave and millimeter wave radio link interfaces 29 is a precondition for seamless multilayer networking and automated 30 network wide provisioning and operation. 32 This document describes the required characteristics and use cases 33 for control and management of radio link interface parameters using a 34 YANG Data Model. It focuses on the benefits of a standardized 35 management model that is aligned with how other packet technology 36 interfaces in a microwave/millimeter wave node are modeled, the need 37 to support core parameters and at the same time allow for optional 38 product/feature specific parameters supporting new, unique innovative 39 features until they have become mature enough to be included in the 40 standardized model. 42 The purpose is to create a framework for identification of the 43 necessary information elements and definition of a YANG Data Model 44 for control and management of the radio link interfaces in a 45 microwave/millimeter wave node. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on January 9, 2017. 64 Copyright Notice 66 Copyright (c) 2016 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Conventions used in this document . . . . . . . . . . . . . . 5 83 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 84 4. Application . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 4.1. Network Management Solutions . . . . . . . . . . . . . . 7 86 4.2. Software Defined Networking . . . . . . . . . . . . . . . 7 87 4.2.1. SDN example of radio link configuration . . . . . . . 7 88 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 5.1. Configuration Management . . . . . . . . . . . . . . . . 9 90 5.1.1. Understand the capabilities and limitations . . . . . 10 91 5.1.2. Initial Configuration . . . . . . . . . . . . . . . . 10 92 5.1.3. Radio link re-configuration and optimization . . . . 10 93 5.2. Inventory . . . . . . . . . . . . . . . . . . . . . . . . 10 94 5.2.1. Retrieve logical inventory and configuration from 95 device . . . . . . . . . . . . . . . . . . . . . . . 10 96 5.2.2. Retrieve logical inventory and configuration from 97 device . . . . . . . . . . . . . . . . . . . . . . . 10 98 5.3. Status and statistics . . . . . . . . . . . . . . . . . . 10 99 5.3.1. Actual status and performance of a radio link 100 interface . . . . . . . . . . . . . . . . . . . . . . 11 101 5.4. Performance management . . . . . . . . . . . . . . . . . 11 102 5.4.1. Configuration of historical measurements to be 103 performed . . . . . . . . . . . . . . . . . . . . . . 11 104 5.4.2. Collection of historical performance data . . . . . . 11 105 5.5. Fault Management . . . . . . . . . . . . . . . . . . . . 11 106 5.5.1. Configuration of alarm reporting . . . . . . . . . . 11 107 5.5.2. Alarm management . . . . . . . . . . . . . . . . . . 11 108 5.5.3. Troubleshooting and Root Cause Analysis . . . . . . . 11 109 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 111 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 113 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 114 9.2. Informative References . . . . . . . . . . . . . . . . . 12 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 117 1. Introduction 119 Network requirements vary between operators globally as well as 120 within individual countries. The overall goal is however the same - 121 to deliver the best possible network performance and quality of 122 experience in a cost-efficient way. 124 Microwave/millimeter wave (hereafter referred to as microwave, but 125 including the frequency bands represented by millimeter wave) are 126 important technologies to fulfill this goal today, but also in the 127 future when demands on capacity and packet features increases. 128 Microwave is already today able to fully support the capacity needs 129 of a backhaul in a radio access network and will evolve to support 130 multiple gigabits in traditional frequency bands and beyond 10 131 gigabit in the millimeter wave. L2 packet features are normally an 132 integrated part of microwave nodes and more advanced L2 and L3 133 features will over time be introduced to support the evolution of the 134 transport services to be provided by a backhaul/transport network. 136 The main application for microwave is backhaul for mobile broadband. 137 Those networks will continue to be modernized using a combination of 138 microwave and fiber technologies. The choice of technology is a 139 question about fiber presence and cost of ownership, not about 140 capacity limitations in microwave. In 2020, more than 65% of all 141 cell sites are expected to be connected with microwave solutions. 143 Open and standardized interfaces are a pre-requisite for efficient 144 management of equipment from multiple vendors. This framework 145 addresses management and control of the radio link interface(s) and 146 the relationship to other packet interfaces, typically to Ethernet 147 interfaces, in a microwave node. A radio link provides the transport 148 over the air, using one or several carriers in aggregated or 149 protected configurations. Managing and controlling a transport 150 service over a microwave node involves both radio link and packet 151 functionality. 153 Already today there are numerous IETF data models, RFCs and drafts, 154 with technology specific extensions that cover a large part of the 155 packet domain. Examples are IP Management [RFC7277], Routing 156 Management [I-D.ietf-netmod-routing-cfg] and Provider Bridge [PB- 157 YANG]. They are based on RFC 7223 [RFC7223], which is the IETF YANG 158 model for Interface Management, and is an evolution of the SNMP IF- 159 MIB [RFC 2863]. 161 Since microwave nodes will contain more and more packet functionality 162 and the interfaces for those technologies are expected to be managed 163 using those models, there are advantages if radio link interfaces can 164 be modeled and be managed using the same structure and the same 165 approach, specifically for use cases in which a microwave node are 166 managed as one common entity including both the radio link and the 167 packet functionality, e.g. at installation, initial setup, trouble 168 shooting, upgrade and maintenance. All interfaces in a node, 169 irrespective of technology, would then be accessed from the same core 170 model, i.e. RFC 7223, and could be extended with technology specific 171 parameters in models augmenting that core model. The relationship/ 172 connectivity between interfaces would be given by the equipment 173 configuration and slot positions or be configured via management 174 systems or controllers. 176 +------------------------------------------------------------------+ 177 | Interface [RFC7223] | 178 | +------------------+ | 179 | |Ethernet Port | | 180 | +------------------+ | 181 | \ | 182 | +-----------------------+ | 183 | |Radio link terminal | | 184 | +-----------------------+ | 185 | \ | 186 | +------------------------+ | 187 | |Carrier termination | | 188 | +------------------------+ | 189 +------------------------------------------------------------------+ 191 Figure 1: Relationship between interfaces in a node 193 There will always be certain implementations that differ among 194 products and it is therefore practically impossible to achieve 195 industry consensus on every design detail. It is therefore important 196 to focus on the parameters that are required to support the use cases 197 applicable for centralized, unified, multi-vendor management and to 198 allow other parameters to be optional or to be covered by extensions 199 to the standardized model. Furthermore, a standard that allows for a 200 certain degree of freedom encourages innovation and competition which 201 is something that benefits the entire industry. It is therefore 202 important that a radio link management model covers all relevant 203 functions but also leaves room for product/feature-specific 204 parameters. 206 For microwave radio link functionality work has been initiated (ONF: 207 Microwave Modeling [ONF-model], IETF: Radio Link Model [I-D.ahlberg- 208 ccamp-microwave-radio-link]). This effort is expected to take these 209 initiatives into consideration and complement them on the gaps 210 identified with the ambition to reach consensus within the industry 211 around one common approach. 213 2. Conventions used in this document 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in RFC2119 [RFC2119]. 219 3. Terminology and Definitions 221 Software Defined Networking (SDN) is an emerging architecture that 222 decouples the network control and forwarding functions enabling the 223 network control to become directly programmable and the underlying 224 infrastructure to be abstracted for applications and network 225 services. This results in an extremely dynamic, manageable, cost- 226 effective, and adaptable architecture that gives administrators 227 unprecedented programmability, automation, and control. The SDN 228 concept is widely applied for network management, the adoption of SDN 229 framework to manage and control the microwave and millimeter wave 230 interface is one of the key applications of this work. 232 Microwave is a band of spectrum with wavelengths ranging from 1 meter 233 to 1 millimeter and with frequencies ranging between 300 MHz and 300 234 GHz. Microwave radio technology is widely used for point-to-point 235 telecommunications because of their small wavelength that allows 236 conveniently-sized antennas to direct them in narrow beams, and their 237 comparatively higher frequencies that allows broad bandwidth and high 238 data transmission rates. 240 Millimeter wave is also known as extremely high frequency (EHF) or 241 very high frequency (VHF) by the International Telecommunications 242 Union (ITU), which can be used for high-speed wireless broadband 243 communications. Millimeter wave is an undeveloped band of spectrum 244 that can be used for a broad range of services on mobile and wireless 245 networks including high-speed, point-to-point wireless local area 246 networks (WLANs) and broadband access. This band has short 247 wavelengths that range from 10 millimeters to 1 millimeter, namely 248 millimeter band or millimeter wave. The 71 - 76 GHz, 81 - 86 GHz and 249 92-95 GHz bands are used for point-to-point high-bandwidth 250 communication links, which allows for higher data rates up to 10 251 Gbit/s but requires a license. Unlicensed short-range data links can 252 be used on 60 GHz millimeter wave. For instance, the upcoming IEEE 253 Wi-Fi standard 802.11ad will run on the 60 GHz spectrum with data 254 transfer rates of up to 7 Gbit/s. 256 Carrier Termination is an interface for the capacity provided over 257 the air by a single carrier. It is typically defined by its 258 transmitting and receiving frequencies. 260 Radio Link Terminal is an interface providing packet capacity and/or 261 TDM capacity to the associated Ethernet and/or TDM interfaces in a 262 node and used for the capacity required for setting up a transport 263 service over a microwave/millimeter wave link. 265 4. Application 267 This framework addresses the definition of an open and standardized 268 interface for the radio link functionality in a microwave/millimeter 269 wave node. The application of such an interface used for management 270 and control of nodes and networks typically vary from one operator to 271 another, in terms of the systems used, what they are called and how 272 they interact. 274 4.1. Network Management Solutions 276 The classic network management solutions, with vendor specific domain 277 management combined with cross domain functionality for service 278 management and analytics, still dominates the market. 280 These solutions are expected to evolve and benefit from an increased 281 focus on standardization by simplifying multi-vendor management, 282 remove the need for vendor/domain specific management, and enabling 283 use of open source systems. 285 4.2. Software Defined Networking 287 SDN is another application emerging on the market. The main drivers 288 for SDN introduction from an operator perspective is simplification 289 and automation of network provisioning as well as E2E network 290 services. The vision is to have a global view of the network 291 conditions spanning across different vendors' equipment and multiple 292 technologies. A variety of different SDN architectures and functions 293 are being discussed and proposed within the industry, but they all 294 have in common a very clear relationship to network management. In 295 some proposals the SDN controller completely replaces the role of a 296 network management system while in some cases the SDN controller is 297 seen as an entity managed by the NMS. In any case the SDN functions 298 shall be seen as part of an overall NMS strategy, no matter how the 299 functionality is partitioned across units and no matter what 300 terminology is used. 302 If nodes from different vendors shall be managed by the same SDN 303 functions, without the extra effort of introducing mediation layers, 304 all nodes must align their interfaces. Hence, open and standardized 305 node interfaces are closely associated with the introduction of SDN. 307 4.2.1. SDN example of radio link configuration 309 Radio link terminals comprising a group of carriers are widely used 310 in microwave technology. There are several kinds of groups: 311 aggregation/bonding, 1+1 protection/redundancy, etc. To avoid 312 configuration on each carrier termination, a logical control provides 313 flexible management without configuring parameters on each carrier 314 termination directly. An operator using SDN manages radio links by 315 selecting an allowed operation mode. Alternatively, an operator can 316 prefer the complete configuration of all the parameters of interest. 317 Such case is not described in the document for simplicity). The 318 operation mode is a set of logical metrics or parameters describing a 319 complete radio link configuration, such as capacity, availability, 320 priority and power consumption. 322 +------+ +-----+ +-----+ +-------+ 323 | |-------| CT1 | ~~~~~~~~~~~ | CT1 |-------| | 324 | | +-----+ +-----+ | | 325 | RLT1 | | RLT2 | 326 | | +-----+ +-----+ | | 327 | |-------| CT2 | ~~~~~~~~~~~ | CT2 |-------| | 328 +------+ +-----+ +-----+ +-------+ 330 Figure 2: Radio link example 332 Example of an operation mode table is shown Table 1. One mode (ID = 333 1) provides high capacity but requires high power consumption; 334 another mode (ID = 2) provides low power consumption but low 335 capacity. SDN controller selects one of the operation modes 336 dynamically, according to the actual capacity need. 338 +------+--------------+-----------+--------------+----------+-------+ 339 | ID | Description | Capacity | Availability | Priority | Power | 340 +------+--------------+-----------+--------------+----------+-------+ 341 | 1 | High capacity| 400 | 99.9% | Low | High | 342 +------+--------------+-----------+--------------+----------+-------+ 343 | 2 | High avail- | 100 | 99.999% | High | Low | 344 | | ability | | | | | 345 +------+--------------+-----------+--------------+----------+-------+ 347 Figure 3: Example of an operation mode table 349 The procedure of logical control is as following: 351 1/ SDN controller gets the supported operation modes by reporting 352 from the node NE or by other means, e.g., NMS. 354 2/ According to its operation policy, SDN controller selects one 355 operation mode from the table and translates that into the required 356 configuration of the individual parameters for the radio link 357 terminals and the associated carrier terminations. 359 The operation mode could be selected based on power consumption. 361 Nowadays, more and more operators have strong requirement to decrease 362 the node power consumption. The SDN controller can monitor the real 363 time traffic distribution, and generated corresponding policy: to set 364 the operation mode to high capacity on the radio links with heavy 365 traffic load; to set the operation mode to low power consumption on 366 the radio links with light traffic load 368 Radio link aggregation/bonding is widely used in microwave: multiple 369 carriers are used to carry the traffic in cases where the needed 370 capacity is beyond the capability of single carriers. During night 371 time, the actual traffic load may be 1/3 of the peak day time. The 372 operation mode of low power consumption could be set to turn off some 373 of the radios within the group to save power consumption. 375 The operation mode could also be configured based on traffic 376 priority. 378 For high priority traffic, it is necessary to assure high 379 availability. On the other hand, low priority traffic is often high 380 volume and requires high capacity. The SDN controller can generate 381 corresponding policy based on the priority of traffic: to set the 382 operation mode to high availability on the radio links with high 383 priority traffic; to set the operation mode to high capacity on the 384 radio links with low priority traffic. 386 Radio protection/redundancy like a 1+1 Hot Standby is used to 387 increase overall availability of links between nodes while radio link 388 aggregation is used to achieve higher capacity. If traffic is 389 predominately TDM traffic, high availability is required on radio 390 links. In this case, SDN controller set operation mode as high 391 availability. On the other hand, if traffic is packet traffic, e.g., 392 LTE traffic, capacity is more of a concern. In this case, SDN 393 controller set the operation mode as high capacity. 395 5. Use cases 397 The use cases described should be the basis for identification and 398 definition of the parameters to be supported by a YANG Data model for 399 management of radio links, applicable for centralized, unified, 400 multi-vendor management. 402 Use cases addressing installation, on-site trouble shooting, fault 403 resolution and other activities not performed from a centralized 404 system and which in most cases are product specific are outside the 405 scope of this framework. 407 5.1. Configuration Management 409 Configuration of a radio link terminal, the constituent carrier 410 terminations and when applicable the relationship to packet/Ethernet 411 interfaces. 413 5.1.1. Understand the capabilities and limitations 415 Exchange of information between a manager and a device about the 416 capabilities supported and specific limitations in the parameter 417 values and enumerations that can be used. 419 Support for the XPIC feature or not and the maximum modulation 420 supported are two examples on information that could be exchanged. 422 5.1.2. Initial Configuration 424 Initial configuration of a radio link terminal, enough to establish 425 L1 connectivity over the hop to an associated radio link terminal on 426 a device at far end. It MAY also include configuration of the 427 relationship to a packet/Ethernet interface, unless that is given by 428 the equipment configuration. 430 Frequency, modulation, coding and output power are examples of 431 parameters typically configured for a carrier termination and type of 432 aggregation/bonding or protection configurations expected for a radio 433 link terminal. 435 5.1.3. Radio link re-configuration and optimization 437 Re-configuration, update or optimization of an existing radio link 438 terminal. Output power and modulation for a carrier termination and 439 protection schemas and activation/de-activation of carriers in a 440 radio link terminal are examples on parameters that can be re- 441 configured and used for optimization of the performance of a network. 443 5.2. Inventory 445 5.2.1. Retrieve logical inventory and configuration from device 447 Request from manager and response by device with information about 448 radio interfaces, their constitution and configuration. 450 5.2.2. Retrieve logical inventory and configuration from device 452 Request from manager about physical and/or equipment inventory 453 associated with the radio link terminals and carrier terminations 455 5.3. Status and statistics 456 5.3.1. Actual status and performance of a radio link interface 458 Manager requests and device responds with information about actual 459 status and statistics of configured radio link interfaces and their 460 constituent parts. 462 5.4. Performance management 464 5.4.1. Configuration of historical measurements to be performed 466 Configuration of historical measurements to be performed on a radio 467 link interface and/or its constituent parts is a subset of the 468 configuration use case to be supported. See 5.1 above. 470 5.4.2. Collection of historical performance data 472 Collection of historical performance data in bulk by the manager is a 473 general use case for a device and not specific to a radio link 474 interface. 476 Collection of an individual counter for a specific interval is in 477 same cases required as a complement to the retrieval in bulk as 478 described above. 480 5.5. Fault Management 482 5.5.1. Configuration of alarm reporting 484 Configuration of alarm reporting associated specifically with radio 485 interfaces, e.g. configuration of alarm severity, is a subset of the 486 configuration use case to be supported. See 5.1 above. 488 5.5.2. Alarm management 490 Alarm synchronization, visualization and handling, and notifications 491 and events are generic use cases for a device and not specific to a 492 radio link interface an should be supported accordingly. 494 5.5.3. Troubleshooting and Root Cause Analysis 496 Information and actions required by a manager/operator to investigate 497 and understand the underlying issue to a problem in the performance 498 and/or functionality of a radio link terminal and the associated 499 carrier terminations. 501 6. Requirements 503 This is a placeholder for a separate chapter about requirements. 505 7. Security Considerations 507 TBD. 509 8. IANA Considerations 511 N/A. 513 9. References 515 9.1. Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 523 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 524 November 1997, . 526 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 527 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 528 . 530 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 531 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 532 . 534 9.2. Informative References 536 [I-D.ahlberg-ccamp-microwave-radio-link] 537 Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., 538 and M. Vaupotic, "Microwave Radio Link YANG Data Models", 539 draft-ahlberg-ccamp-microwave-radio-link-01 (work in 540 progress), May 2016. 542 [I-D.ietf-netmod-routing-cfg] 543 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 544 Management", draft-ietf-netmod-routing-cfg-22 (work in 545 progress), July 2016. 547 [ONF-model] 548 "Microwave Modeling - ONF Wireless Transport Group", May 549 2016. 551 [PB-YANG] "IEEE 802.1X and 802.1Q YANG models, Marc,H.", October 552 2015. 554 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 555 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 556 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 557 . 559 Authors' Addresses 561 Jonas Ahlberg 562 Ericsson AB 563 Lindholmspiren 11 564 Goeteborg 417 56 565 Sweden 567 Email: jonas.ahlberg@ericsson.com 569 Luis M. Contreras 570 Telefonica I+D 571 Ronda de la Comunicacion, S/N 572 Madrid 28050 573 Spain 575 Email: luismiguel.contrerasmurillo@telefonica.com 577 Ye Min (Amy) 578 Huawei Technologies CO., Ltd 579 No.1899, Xiyuan Avenue 580 Chengdu 611731 581 P.R.China 583 Email: amy.yemin@huawei.com 585 Marko Vaupotic 586 Aviat Networks 587 Motnica 9 588 Trzin-Ljubljana 1236 589 Slovenia 591 Email: Marko.Vaupotic@aviatnet.com 592 Jeff Tantsura 593 Individual 595 Email: jefftant.ietf@gmail.com 597 Koji Kawada 598 NEC Corporation 599 1753, Shimonumabe Nakahara-ku 600 Kawasaki, Kanagawa 211-8666 601 Japan 603 Email: k-kawada@ah.jp.nec.com 605 Xi Li 606 NEC Laboratories Europe 607 Kurfuersten-Anlage 36 608 Heidelberg 69115 609 Germany 611 Email: Xi.Li@neclab.eu 613 Ippei Akiyoshi 614 NEC 615 1753, Shimonumabe Nakahara-ku 616 Kawasaki, Kanagawa 211-8666 617 Japan 619 Email: i-akiyoshi@ah.jp.nec.com