idnits 2.17.1 draft-gdmb-netslices-intro-and-ps-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 9) being 103 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 87 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 89 has weird spacing: '...virtual netwo...' == Line 96 has weird spacing: '...routers are ...' == Line 151 has weird spacing: '...erfaces and /...' == Line 192 has weird spacing: '...address speci...' -- The document date (February 14, 2017) is 2628 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7665' is mentioned on line 377, but not defined == Missing Reference: 'RFC1958' is mentioned on line 432, but not defined == Missing Reference: 'RFC3439' is mentioned on line 436, but not defined == Missing Reference: 'RFC3234' is mentioned on line 440, but not defined == Missing Reference: 'SFC WG' is mentioned on line 90, but not defined == Missing Reference: 'RFC7149' is mentioned on line 444, but not defined == Missing Reference: 'I-D.leeking-actn-problem-statement 03' is mentioned on line 382, but not defined == Missing Reference: 'I-D.teas-actn-requirements-04' is mentioned on line 388, but not defined == Missing Reference: 'I-D.dong-network-slicing-problem-statement' is mentioned on line 367, but not defined == Missing Reference: 'I-D.galis-anima-autonomic-slice-networking' is mentioned on line 372, but not defined == Missing Reference: 'IETF-Slicing1' is mentioned on line 394, but not defined == Missing Reference: 'IETF-Slicing2' is mentioned on line 400, but not defined == Missing Reference: 'IETF-Slicing3' is mentioned on line 406, but not defined == Missing Reference: 'IETF-Slicing4' is mentioned on line 411, but not defined == Missing Reference: 'IETF-Slicing5' is mentioned on line 418, but not defined == Missing Reference: 'IETF-Virtualization' is mentioned on line 462, but not defined == Missing Reference: 'IETF-Coding' is mentioned on line 466, but not defined == Missing Reference: 'IETF-Anchoring' is mentioned on line 470, but not defined == Missing Reference: 'RFC2119' is mentioned on line 423, but not defined == Missing Reference: 'RFC4364' is mentioned on line 428, but not defined == Missing Reference: 'CPP' is mentioned on line 452, but not defined == Missing Reference: 'SFG WG' is mentioned on line 449, but not defined Summary: 1 error (**), 0 flaws (~~), 29 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Working Group A. Galis 3 Internet-Draft University College London 4 Intended status: Informational J. Dong 5 Expires: July 23, 2017 K. Makhijani 6 S. Bryant 7 Huawei Technologies 8 M. Boucadair 9 Orange 10 P. Martinez-Julia 11 NICT 12 February 14, 2017 14 Network Slicing - Introductory Document and Revised Problem Statement 15 draft-gdmb-netslices-intro-and-ps-02 17 Abstract 19 This document introduces Network Slicing problems and the motivation 20 for new work areas. It represents an initial revision of the Network 21 Slicing problem statement derived from the analysis of the technical 22 gaps in IETF protocols ecosystem. It complements and brings together 23 the silo efforts being carried out in several other IETF working groups 24 to achieve certain aspects of Network Slicing functions and operations. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 23, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Suggested Problems and Work Areas . . . . . . . . . . . . . . 4 63 2.1. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Network Slicing (NS) refers to the managed partitions of physical 76 and/or virtual network resources, network physical/virtual and 77 service functions [RFC7665] that can act as an independent instance 78 of a connectivity network and/or as a network cloud. Network resources 79 include connectivity, compute, and storage resources. 81 Network Slices considerably transform the networking perspective by 82 abstracting, isolating, orchestrating, softwarizing, and separating 83 logical network components from the underlying physical network 84 resources and as such they enhance Internet architecture principles 85 ([RFC1958], [RFC3439], [RFC3234]). 87 The management plane creates the grouping of network resources (whereby 88 network resources can be physical, virtual or a combination thereof), 89 it connects with the physical and virtual network and service functions 90 ([SFC WG]) as appropriate, and it instantiates all of the network and 91 service functions assigned to the slice. On the other hand, for slice 92 operations, the slice control plane takes over the control and governing 93 of all the network resources, network functions, and service functions 94 assigned to the slice. It (re-) configures them as appropriate and as per 95 elasticity needs, in order to provide an end-to-end service. In particular, 96 ingress routers are configured so that appropriate traffic is bound to 97 the relevant slice. Identification means for the traffic may be simple 98 (relying on a subset of the transport coordinate, DSCP/traffic class, or 99 flow label), or identification may be a more sophisticated one (to be 100 further defined). Also, the traffic capacity that is specified for a slice 101 can be changed dynamically, based on some events (e.g. triggered by a 102 service request). The slice control plane is responsible for instructing 103 the involved elements to honor such needs. 105 Network operators can use NS to enable different services to receive 106 different treatment and to allow the allocation and release of network 107 resources according to the context and contention policy of the operators. 108 Such an approach using NS would allow significant reduction of the operations 109 expenditure. In addition NS makes possible softwarization, programmability 110 ([RFC7149]), and the innovation necessary to enrich the offered services. 111 Network softwarization techniques [IMT2020-2015], [IMT2020-2016] may be used 112 to realise and manage [MANO-2014] network slicing. NS provides the 113 means for the network operators to provide network programmable 114 capabilities to both OTT providers and other market players without 115 changing their physical infrastructure. NS enables the concurrent 116 deployment of multiple logical, self-contained and independent, 117 shared or partitioned networks on a common infrastructure. Slices 118 may support dynamic multiple services, multi-tenancy, and the 119 integration means for vertical market players (e.g. automotive 120 industry, energy industry, healthcare industry, media and 121 entertainment industry, etc.) 123 The purpose of the NS work in IETF is to develop a set of protocols and/ 124 or protocol extensions that enable efficient slice creation, 125 activation / deactivation, composition, elasticity, coordination / 126 orchestration, management, isolation, guaranteed SLA, and safe and secure 127 operations within a connectivity network or network cloud / data centre 128 environment that assumes an IP and/or MPLS-based underlay. 130 While there are isolated efforts being carried out in several IETF 131 working groups Network WG [I-D.leeking-actn-problem-statement 03], TEAS WG 132 [I-D.teas-actn-requirements-04], [I-D.dong-network-slicing-problem-statement], 133 ANIMA WG [I-D.galis-anima-autonomic-slice-networking], [IETF-Slicing1], 134 [IETF-Slicing2], [IETF-Slicing3], [IETF-Slicing4], [IETF-Slicing5],[IETF- 135 Mobility], [IETF-Virtualization], [IETF-Coding], [IETF-Anchoring] to 136 achieve certain aspects of network slice functions and operations, 137 there is a clear need to look at the complete life-cycle management 138 characteristics of Network Slicing solutions though the discussions 139 based on the following architectural tenets: 141 o Underlay tenet: support for an IP/MPLS-based underlay data plane the 142 transport network used to carry that underlay. 144 o Governance tenet: a logically centralized authority for network 145 slices in a domain. 147 o Separation tenet: slices may be independent of each other and have 148 an appropriate degree of isolation (note 1) from each other. 150 o Capability exposure tenet: each slice allows third parties to 151 access via dedicated interfaces and /or APIs information regarding 152 services provided by the slice (e.g., connectivity information, mobility, 153 autonomicity, etc.) within the limits set by the operator. 155 NS approaches that do not adhere to these tenets are explicitly 156 outside of the scope of the proposed work at IETF. 158 In pursuit of the solutions described above, there is a need to 159 document an architecture for network slicing within both wide area 160 network and data center environments. 162 Elicitation of requirements ([RFC2119], [RFC4364]) for both Network 163 Slice control and management planes will be needed, facilitating 164 the selection, extension, and/or development of the protocols for each 165 of the functional interfaces identified to support the architecture. 167 Additionally, documentation on the common use-cases for slice 168 validation for 5G is needed, such as mission-critical ultra-low latency 169 communication services; massive-connectivity machine communication 170 services (e.g. smart metering, smart grid and sensor networks); extreme 171 QoS; independent operations and management; independent cost and/or 172 energy optimisation; independent multi-topology routing; multi-tenant 173 operations; etc. 175 The proposed NS work would be coordinated with other IETF WGs (e.g. 176 TEAS WG, DETNET WG, ANIMA WG, SFC WG, NETCONF WG, SUPA WG, NVO3 WG, 177 DMM WG, Routing Area WG (RTGWG), Network Management Research Group 178 (NMRG)and NFV Research Group (NFVRG)) to ensure that the commonalities 179 and differences in solutions are properly considered. Where suitable 180 protocols, models or methods exist, they will be preferred over 181 creating new ones. 183 1.1. Notes 185 (1) This issue requires efficient interaction between an upper layer 186 in the hierarchy and a lower layer for QoS guarantees and for most 187 of the operations on slicing. 189 2. Suggested Problems and Work Areas 191 The goal of this proposed work is to develop one or more protocol 192 specifications (or extensions to existing protocols) to address specific 193 slicing problems that are not met by the existing tools. The following 194 problems were selected according to the analysis of the technical gaps in 195 IETF protocols ecosystem. 197 o Uniform Reference Model for Network Slicing (Architecture document): 198 Describes all of the functional elements and instances of a network slice. 199 Describes shared non-sliced network parts. Establishes the boundaries to the 200 basic network slice operations (creation, management, exposure, consumption). 201 Describes the minimum functional and non-functional roles derived from basic 202 network slice operations including infrastructure owner (creation, exposure, 203 management), slice operator (exposure, management, consumption), slice user 204 (management, consumption). Describe the interactions between infrastructure 205 owner -- slice operator, slice operator -- slice operator, slice operator -- 206 slice user. Additionally, this working area will normalize nomenclature and 207 definitions for Network Slicing. 209 o Review common scenarios from the requirements for operations and 210 interactions point of view. Describes the roles (owner, operator, user) which 211 are played by entities with single /multiple entities playing different roles. 213 o Slice Templates: Design the slices to different scenarios 214 ([ChinaCom-2009], [GENI-2009], [IMT2020-2016bis], [NGMN-2016], 215 [NGS-3GPP-2016], [ONF-2016]); Outlines an appropriate slice template 216 definition that may include capability exposure of managed partitions 217 of network resources (i.e. connectivity ([CPP]), compute and storage 218 resources), physical and/or virtual network and service functions that can 219 act as an independent connectivity network and/or as a network cloud. 221 o Network Slice capabilities (where some prioritization may be 222 needed) are expected to be: 224 * Four-dimensional efficient slice creation with guarantees for 225 isolation in each of the Data /Control /Management /Service 226 planes. Enablers for safe, secure and efficient multi-tenancy 227 in slices. 229 * Methods to enable diverse requirements for NS including 230 guarantee for the end-to-end QoS of service in a slice. 232 * Efficiency in slicing: specifying policies and methods to realize 233 diverse requirements without re-engineering the infrastructure. 235 * Recursion: namely methods for NS segmentation allowing a slicing 236 hierarchy with parent - child relationships. 238 * Customized security mechanisms per slice. 240 * Methods and policies to manage the trade-offs between flexibility 241 and efficiency in slicing. 243 * Optimisation: namely methods for network resources automatic 244 selection for NS; global resource view formed; global energy view 245 formed; Network Slice deployed based on global resource 246 and energy efficiency; Mapping algorithms. 248 * Monitoring status and behaviour of NS in a single and/or 249 muti-domain environment; NS interconnection. 251 * Capability exposure (e.g. openness) for NS; plus APIs for slices. 253 * Programmability and control of Network Slices. 255 o Network slice operations (again some prioritization may be needed) are 256 expected to be: 258 * Slice life cycle management including creation, 259 activation / deactivation, protection (note 2), elasticity (note 3), 260 extensibility (note 4), safety (note 5), sizing and scalability of the 261 slicing model per network and per network cloud: slices in access, core 262 and transport networks; slices in data centres, slices in edge clouds. 264 * Autonomic slice management and operation: namely self-configuration, 265 self-composition, self-monitoring, self-optimisation, 266 self-elasticity are carried as part of the slice protocols. 268 * Slice stitching / composition: having enablers and methods for 269 efficient stitching /composition/ decomposition of slices: 270 - vertically (service + management + control planes) and/or 271 - horizontally (between different domains part of access, 272 core, edge segments) and /or 273 - vertically + horizontally. 275 * End-to-end network segments and network clouds orchestration 276 of slices ([GUERZONI-2016], [KARL-2016]). 278 * Service Mapping: having dynamic and Automatic Mapping of Services to 279 slices; YANG models for slices. 281 o Describe the enablers and methods for the above mentioned capabilities 282 and operations from different viewpoints on slices (note 6). 284 o Efficient enablers and methods for integration of above capabilities and 285 operations. 287 2.1. Notes 289 (2) Protection refers to the related mechanisms so that events within 290 one slice, such as congestion, do not have a negative impact on 291 another slice. 293 (3) Elasticity refers to the mechanisms and triggers for the growth 294 /shrinkage of network resources, and/or network and service functions. 296 (4) Extensibility refers to the ability to expand a NS with 297 additional functionality and/or characteristics, or through the 298 modification of existing functionality/characteristics, while 299 minimizing impact to existing functions. 301 (5) Safety refers to the conditions of being protected against 302 different types and the consequences of failure, error harm or any 303 other event, which could be considered non-desirable. 305 (6) Multiple viewpoints on slices: I) viewpoint of the slice's owner 306 towards user: from this viewpoint a slice is defined as a means to 307 "split" physical or virtual infrastructure elements to "service" smaller 308 portions. This action would be recursively done from the owner of the initial and 309 physical infrastructure element to the users. II) viewpoint of from the user towards 310 the physical infrastructure owner. From this viewpoint a slice is viewed just as a 311 set of resources that must be managed (requests to a provider, listed, changed, 312 returned to the provider, etc.). This viewpoint emphasizes those issues that would 313 be used in the SLA definition of a slice. 315 3. Documents 317 The following are the proposed / expected / resulting documents with 318 priority (I) or (II) (we note that revised prioritization may be needed): 320 o (I) Agreed work plan 322 o (I) NS Architecture document 323 - Slice template and reference model to IESG (Informational) 325 o (I) NS Exposure Interface specification and Data model 326 - Slice life-cycle management model and NS Exposure Interface 327 specification to IESG (Informational) 328 - YANG data model for slicing. 330 o (I) Service Requirement to Network Capability Mapping Data Model 331 - Requirements for both NS control and management planes. 332 - Common use-cases for slice validation for 5G. 334 o (I) Four dimensional efficient slice isolation with guarantees for 335 isolation in each of the Data/ Control/ Management/ Service planes. 337 o (II) Methods to enable diverse requirements for NS including 338 guarantee for the end-to-end QoS of a slice. 340 o (I) End-to-end coordination and orchestration of slices. 342 o (II) Customized security mechanisms per slice. 344 o (I) Slice stitching / composition: enablers for efficient stitch / 345 composition / decomposition of slices vertically, horizontally and 346 vertically + horizontally. This item covers considerations related to 347 interconnecting slices that are bond the same administrative domain or 348 interconnecting multi-administrative domain. 350 4. Security Considerations 352 Security will be a major part of the design of network slicing. 354 5. IANA Considerations 356 This document requests no IANA actions. 358 6. Acknowledgements 360 Thanks to Sheng Jiang (Huawei Technologies), Hannu Flinck (Nokia), 361 Kevin Smith (Vodafone) for reviewing this draft. 363 7. References 365 7.1. IETF References 367 [I-D.dong-network-slicing-problem-statement] 368 Dong, J. and S. Bryant, "Problem Statement of Network 369 Slicing in IP/MPLS Networks", draft-dong-network-slicing- 370 problem-statement-00 (work in progress), October 2016. 372 [I-D.galis-anima-autonomic-slice-networking] 373 Galis, A., Makhijani, K., and D. Yu, "Autonomic Slice 374 Networking-Requirements and Reference Model", draft-galis- 375 anima-autonomic-slice-networking-01 (work in progress), 376 October 2016. 377 [RFC7665] 378 Halpern, J., Pignataro, C., 379 "Service Function Chaining (SFC) Architecture", 380 https://tools.ietf.org/html/rfc7665, October 2015. 382 [I-D.leeking-actn-problem-statement 03] 383 Ceccarelli, D., Lee, Y., 384 "Framework for Abstraction and Control of Traffic Engineered 385 Networks", draft-leeking-actn-problem-statement-03 386 (work in progress), September 2014. 388 [I-D.teas-actn-requirements-04] 389 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., Ceccarelli, D., 390 "Requirements for Abstraction and Control of TE Networks", 391 draft-ietf-teas-actn-requirements-04.txt 392 January 2017. 394 [IETF-Slicing1] 395 "Presentations - Network Slicing meeting at IETF 97 of 396 15th November 2016", n.d., . 400 [IETF-Slicing2] 401 "Presentations - Network Slicing meeting at IETF 97 of 402 15th November 2016", n.d., . 406 [IETF-Slicing3] 407 "Presentations - Network Slicing meeting at IETF 97 of 408 15th November 2016", n.d., . 411 [IETF-Slicing4] 412 "Presentations - Network Slicing meeting at IETF 97 of 413 15th November 2016", n.d., . 418 [IETF-Slicing5] 419 "Presentations - Network Slicing meeting at IETF 97 of 420 15th November 2016", n.d., . 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 429 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 430 2006, . 432 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 433 RFC 1958, 434 . 436 [RFC3439] Bush, R., Meyer, D., "Some Internet Architectural Guidelines and 437 Philosophy", RFC 3439, 438 . 440 [RFC3234] Carpenter, B., Brim S., "Middleboxes: Taxonomy and Issues", 441 RFC3439, 442 . 444 [RFC7149] Boucadair, M., Jacquenet, C. , " Software-Defined Networking: A 445 Perspective from within a Service Provider Environment", RFC 7149, 446 March 2014 447 . 449 [SFG WG] 450 "Service Function Chaining WG" 451 . 452 [CPP] 453 Boucadair M., Jacquenet, C., Wang, N., "IP Connectivity 454 Provisioning Profile (CPP)" 455 457 [IETF-Mobility]Truong-Xuan Do, Young-Han Kim, "Architecture 458 for delivering multicast mobility services using network 459 slicing" 2016-10-31 460 462 [IETF-Virtualization] Carlos Bernardos, Akbar Rahman, Juan Zuniga, Luis Contreras, 463 Pedro Aranda, " Network Virtualization Research Challenges" 2016-10-31 464 466 [IETF-Coding] M.A. Vazquez-Castro, Tan Do-Duy, Paresh Saxena, Magnus Vikstrom, 467 "Network Coding Function Virtualization" 2016-11-14 468 470 [IETF-Anchoring] Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, 471 Alexandre Petrescu, Fred Templin "Distributed Mobility Anchoring" 472 2016-12-15 473 475 7.2. Informative References 477 [ChinaCom-2009] 478 "A. Galis et al - Management and Service-aware Networking 479 Architectures (MANA) for Future Internet - Invited paper 480 IEEE 2009 Fourth International Conference on 481 Communications and Networking in China (ChinaCom09) 26-28 482 August 2009, Xi'an, China", n.d., 483 . 485 [GENI-2009] 486 "GENI Key Concepts - Global Environment for Network 487 Innovations (GENI)", n.d., 488 . 490 [GUERZONI-2016] 491 "Guerzoni, R., Vaishnavi, I., Perez-Caparros, D., Galis, A., 492 et al Analysis of End-to-End Multi Domain Management and 493 Orchestration Frameworks for Software Defined 494 Infrastructures - an Architectural Survey", June 2016, 495 . 497 [IMT2020-2015] 498 "Report on Gap Analysis", ITU-T FG IMT2020, December 499 2015, . 502 [IMT2020-2016] 503 "Draft Technical Report Application of network 504 softwarization to IMT-2020 (O-041)", ITU-T FG IMT2020, 505 December 2016, . 508 [IMT2020-2016bis] 509 "Draft Terms and definitions for IMT-2020 in ITU-T 510 (O-040)", ITU-T FG IMT2020, December 2016, 511 . 514 [KARL-2016] 515 "Karl, H., Peuster, M, Galis, A., et al DevOps for Network 516 Function Virtualization - An Architectural Approach", July 517 2016, 518 . 520 [MANO-2014] 521 "Network Functions Virtualisation (NFV); Management and 522 Orchestration v1.1.1.", ETSI European Telecommunications 523 Standards Institute., December 2014, 524 . 527 [NGMN-2016] 528 "Hedmar,P., Mschner, K., et al - Description of Network 529 Slicing Concept", NGMN Alliance NGS-3GPP-2016, January 530 2016, . 533 [NGS-3GPP-2016] 534 "Study on Architecture for Next Generation System - latest 535 version v1.0.2", September 2016, 536 . 539 [ONF-2016] 540 "Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 541 M., Lopes, D., Kaippallimalit, J., - Open Network 542 Fundation document "Applying SDN Architecture to 5G 543 Slicing", Open Network Fundation, April 2016, 544 . 548 Authors' Addresses 550 Alex Galis 551 University College London 553 Email: a.galis@ucl.ac.uk 554 Jie Dong 555 Huawei Technologies 557 Email: jie.dong@huawei.com 559 Kiran Makhijani 560 Huawei Technologies 562 Email: kiran.makhijani@huawei.com 564 Stewart Bryant 565 Huawei Technologies 567 Email: stewart.bryant@gmail.com 569 Mohamed Boucadair 570 Orange 572 Email: mohamed.boucadair@orange.com 574 Pedro Martinez-Julia 575 National Institute of Information and Communications Technology (NICT) 577 Email: pedro@nict.go.jp