idnits 2.17.1 draft-bryskin-teas-use-cases-sf-aware-topo-model-01.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 (October 24, 2017) is 2375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sfc-hierarchical' is defined on line 494, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-12 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-08 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-hierarchical-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational X. Liu 5 Expires: April 27, 2018 Jabil 6 J. Guichard 7 Y. Lee 8 Huawei Technologies 9 L. Contreras 10 Telefonica 11 D. Ceccarelli 12 Ericsson 13 October 24, 2017 15 Use Cases for SF Aware Topology Models 16 draft-bryskin-teas-use-cases-sf-aware-topo-model-01 18 Abstract 20 This document describes some use cases that benefit from the network 21 topology models that are service and network function aware. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 27, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Exporting SF/NF Information to Network Clients and Other 60 Network SDN Controllers . . . . . . . . . . . . . . . . . . . 4 61 4. Flat End-to-end SFCs Managed on Multi-domain Networks . . . 5 62 5. Managing SFCs with TE Constrains . . . . . . . . . . . . . . 6 63 6. SFC Protection and Load Balancing . . . . . . . . . . . . . . 7 64 7. Network Clock Synchronization . . . . . . . . . . . . . . . . 10 65 8. Client - Provider Network Slicing Interface . . . . . . . . . 10 66 9. Dynamic Assignment of Regenerators for L0 Services . . . . . 10 67 10. Dynamic Assignment of OAM Functions for L1 Services . . . . . 12 68 11. SFC Abstraction and Scaling . . . . . . . . . . . . . . . . . 13 69 12. Dynamic Compute/VM/Storage Resource Assignment . . . . . . . 13 70 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 73 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 16.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 16.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 Normally network connectivity services are discussed as a means to 81 inter-connect various abstract or physical network topological 82 elements, such as ports, link termination points and nodes 83 [I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the 84 connectivity services, strictly speaking, interconnect not the 85 network topology elements per-se, rather, located on/associated with 86 the various network and service functions [RFC7498] [RFC7665]. In 87 many scenarios it is beneficial to decouple the service/network 88 functions from the network topology elements hosting them, describe 89 them in some unambiguous and identifiable way (so that it would be 90 possible, for example, to auto-discover on the network topology 91 service/network functions with identical or similar functionality and 92 characteristics) and engineer the connectivity between the service/ 93 network functions, rather than between their current topological 94 locations. The purpose of this document is to describe some use 95 cases that could benefit from such an approach. 97 2. Terminology 99 o Network Function (NF): A functional block within a network 100 infrastructure that has well-defined external interfaces and well- 101 defined functional behaviour [ETSI-NFV-TERM]. Such functions 102 include message router, CDN, session border controller, WAN 103 cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and 104 radio/fixed access network nodes. 106 o Network Service: Composition of Network Functions and defined by 107 its functional and behavioural specification. The Network Service 108 contributes to the behaviour of the higher layer service, which is 109 characterized by at least performance, dependability, and security 110 specifications. The end-to-end network service behaviour is the 111 result of the combination of the individual network function 112 behaviours as well as the behaviours of the network infrastructure 113 composition mechanism [ETSI-NFV-TERM]. 115 o Service Function (SF): A function that is responsible for specific 116 treatment of received packets. A service function can act at 117 various layers of a protocol stack (e.g., at the network layer or 118 other OSI layers). As a logical component, a service function can 119 be realized as a virtual element or be embedded in a physical 120 network element. One or more service functions can be embedded in 121 the same network element. Multiple occurrences of the service 122 function can exist in the same administrative domain. A non- 123 exhaustive list of service functions includes: firewalls, WAN and 124 application acceleration, Deep Packet Inspection (DPI), server 125 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 126 enrichment functions, and TCP optimizers. The generic term "L4-L7 127 services" is often used to describe many service functions 128 [RFC7498]. 130 o Service Function Chain (SFC): A service function chain defines an 131 ordered or partially ordered set of abstract service functions and 132 ordering constraints that must be applied to packets, frames, and/ 133 or flows selected as a result of classification. An example of an 134 abstract service function is a firewall. The implied order may 135 not be a linear progression as the architecture allows for SFCs 136 that copy to more than one branch, and also allows for cases where 137 there is flexibility in the order in which service functions need 138 to be applied. The term "service chain" is often used as 139 shorthand for "service function chain" [RFC7498]. 141 o Connectivity Service: Any service between layer 0 and layer 3 142 aiming at delivering traffic among two or more end customer edge 143 nodes connected to provider edge nodes. Examples include L3VPN, 144 L2VPN etc. 146 o Link Termination Point (LTP): A conceptual point of connection of 147 a TE node to one of the TE links, terminated by the TE node. 148 Cardinality between an LTP and the associated TE link is 1:0..1 149 [I-D.ietf-teas-yang-te-topo]. 151 o Tunnel Termination Point (TTP): An element of TE topology 152 representing one or several of potential transport service 153 termination points (i.e. service client adaptation points such as 154 WDM/OCh transponder). TTP is associated with (hosted by) exactly 155 one TE node. TTP is assigned with the TE node scope unique ID. 156 Depending on the TE node's internal constraints, a given TTP 157 hosted by the TE node could be accessed via one, several or all TE 158 links terminated by the TE node [I-D.ietf-teas-yang-te-topo]. 160 3. Exporting SF/NF Information to Network Clients and Other Network SDN 161 Controllers 163 In the context of Service Function Chain (SFC) orchestration one 164 existing problem is that there is no way to formally describe a 165 Service or Network Function in a standard way (recognizable/ 166 understood by a third party) as a resource of a network topology 167 node. 169 One implication of this is that there is no way for the orchestrator 170 to give a network client even a ball-park idea as to which network's 171 SFs/NFs are available for the client's use/control and where they are 172 located in the network even in terms of abstract topologies/virtual 173 networks configured and managed specifically for the client. 174 Consequently, the client has no say on how the SFCs provided for the 175 client by the network should be set up and managed (which SFs are to 176 be used and how they should be chained together, optimized, 177 manipulated, protected, etc.). 179 Likewise, there is no way for the orchestrator to export SF/NF 180 information to other network controllers. The SFC orchestrator may 181 serve, for example, a higher level controller (such as Network 182 Slicing Orchestrator), with the latter wanting at least some level of 183 control as to which SFs/NFs it wants on its SFCs and how the Service 184 Function Paths (SFPs) are to be routed and provisioned, especially, 185 if it uses services of more than one SFC orchestrator. 187 The issue of exporting of SF/NF information could be addressed by 188 defining a model, in which formally described/recognizable SF/NF 189 instances are presented as topological elements, for example, hosted 190 by TE, L3 or L2 topology nodes (see Figure 1). The model could 191 describe whether, how and at what costs the SFs/NFs hosted by a given 192 node could be chained together, how these intra-node SFCs could be 193 connected to the node's Service Function Forwarders (SFFs, entities 194 dealing with SFC NSHs and metadata), and how the SFFs could be 195 connected to the node's Tunnel and Link Termination Points (TTPs and 196 LTPs) to chain the intra-node SFCs across the network topology. 198 Figure 1: SF/NF aware TE topology 200 4. Flat End-to-end SFCs Managed on Multi-domain Networks 202 SFCs may span multiple administrative domains, each of which 203 controlled by a separate SFC controller. The usual solution for such 204 a scenario is the Hierarchical SFCs (H-SFCs), in which the higher 205 level orchestrator controls only SFs located on domain border nodes. 206 Said higher level SFs are chained together into higher level SFCs via 207 lower level (intra-domain) SFCs provisioned and controlled 208 independently by respective domain controllers. The decision as to 209 which higher level SFCs are connected to which lower level SFCs is 210 driven by packet re-classification every time the packet enters a 211 given domain. Said packet re-classification is a very time-consuming 212 operation. Furthermore, the independent nature of higher and lower 213 level SFC control is prone to configuration errors, which may lead to 214 long lasting loops and congestions. It is highly desirable to be 215 able to set up and manage SFCs spanning multiple domains in a flat 216 way as far as the data plane is concerned (i.e. with a single packet 217 classification at the ingress into the multi-domain network but 218 without re-classifications on domain ingress nodes). 220 One way to achieve this is to have the domain controllers expose SF/ 221 NF- aware topologies, and have the higher level orchestrator operate 222 on the network-wide topology, the product of merging of the 223 topologies catered by the domain controllers. This is similar in 224 spirit to setting up, coordinating and managing the transport 225 connectivity (TE tunnels) on a multi-domain multi-vendor transport 226 network. 228 5. Managing SFCs with TE Constrains 230 Some SFCs require per SFC link/element and end-to-end TE constrains 231 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 232 constraints could be ensured via carrying SFPs inside overlays that 233 are traffic engineered with the constrains in mind. A good analogy 234 would be orchestrating delay constrained L3 VPNs. One way to support 235 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 236 inside delay constrained TE tunnels interconnecting the PEs hosting 237 the VRFs. 239 Figure 2: L3 VPN with delay constraints 241 Planning, computing and provisioning of TE overlays to constrain 242 arbitrary SFCs, especially those that span multiple administrative 243 domains with each domain controlled by a separate controller, is a 244 very difficult challenge. Currently it is addressed by pre- 245 provisioning on the network of multiple TE tunnels with various TE 246 characteristics, and "nailing down" SFs/NFs to "strategic" locations 247 (e.g. nodes terminating many of such tunnels) in a hope that an 248 adequate set of tunnels could be found to carry the SFP of a given 249 TE-constrained SFC. Such an approach is especially awkward in the 250 case when some or all of the SFs/NFs are VNFs (i.e. could be 251 instantiated at multiple network locations). 253 SF/NF-aware TE topology model in combination with TE tunnel model 254 will allow for the network orchestrator (or a client controller) to 255 compute, set up and manipulate the TE overlays in the form of TE 256 tunnel chains (see Figure 3). 258 Said chains could be duel-optimized compromising on optimal SF/NF 259 locations with optimal TE tunnels interconnecting them. The TE 260 tunnel chains (carrying multiple similarly constrained SFPs) could be 261 adequately constrained both at individual TE tunnel level and at the 262 chain end-to-end level. 264 Figure 3: SFC with TE constraints 266 6. SFC Protection and Load Balancing 268 Currently the combination of TE topology & tunnel models offers to a 269 network controller various capabilities to recover an individual TE 270 tunnel from network failures occurred on one or more network links or 271 transit nodes on the TE paths taken by the TE tunnel's connection(s). 272 However, there is no simple way to recover a TE tunnel from a failure 273 affecting its source or destination node. SF/NF-aware TE topology 274 model can decouple the association of a given SF/NF with its location 275 on the network topology by presenting multiple, identifiable as 276 mutually substitutable SFs/NFs hosted by different TE topology nodes. 277 So, for example, if it is detected that a given TE tunnel destination 278 node is malfunctioning or has gone out of service, the TE tunnel 279 could be re-routed to terminate on a different node hosting 280 functionally the same SFs/NFs as ones hosted by the failed node (see 281 Figures 6). 283 This is in line with the ACTN edge migration and function mobility 284 concepts. It is important to note that the described strategy works 285 much better for the stateless SFs/NFs. This is because getting the 286 alternative stateful SFs/MFs into the same respective states as the 287 current (i.e. active, affected by failure) are is a very difficult 288 challenge. 290 Figure 4: SFC recovery: SF2 on node NE1 fails 292 At the SFC level the SF/NF-aware TE topology model can offer SFC 293 dynamic restoration capabilities against failed/malfunctioning SFs/ 294 NFs by identifying and provisioning detours to a TE tunnel chain, so 295 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 296 are functionally the same as the failed ones. Furthermore, multiple 297 parallel TE tunnel chains could be pre-provisioned for the purpose of 298 SFC load balancing and end-to-end protection. In the latter case 299 said parallel TE tunnel chains could be placed to be sufficiently 300 disjoint from each other. 302 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 303 node N1 has failed 305 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 306 has failed 308 7. Network Clock Synchronization 310 Many current and future network applications (including 5g and IoT 311 applications) require very accurate time services (PTP level, ns 312 resolution). One way to implement the adequate network clock 313 synchronization for such services is via describing network clocks as 314 NFs on an NF-aware TE topology optimized to have best possible delay 315 variation characteristics. Because such a topology will contain 316 delay/delay variation metrics of topology links and node cross- 317 connects, as well as costs in terms of delay/delay variation of 318 connecting clocks to hosting them node link and tunnel termination 319 points, it will be possible to dynamically select and provision bi- 320 directional time-constrained deterministic paths or trees connecting 321 clocks (e.g. grand master and boundary clocks) for the purpose of 322 exchange of clock synchronization information. Note that network 323 clock aware TE topologies separately provided by domain controllers 324 will enable multi-domain network orchestrator to set up and 325 manipulate the clock synchronization paths/trees spanning multiple 326 network domains. 328 8. Client - Provider Network Slicing Interface 330 3GPP defines network slice as "a set of network functions and the 331 resources for these network functions which are arranged and 332 configured, forming a complete logical network to meet certain 333 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 334 [_3GPP.28.801]. Network slice could be also defined as a logical 335 partition of a provider's network that is owned and managed by a 336 tenant. SF/NF-aware TE topology model has a potential to support a 337 very important interface between network slicing clients and 338 providers because, on the one hand, the model can describe 339 holistically and hierarchically the client's requirements and 340 preferences with respect to a network slice functional, topological 341 and traffic engineering aspects, as well as of the degree of resource 342 separation/ sharing between the slices, thus allowing for the client 343 (up to agreed upon extent) to dynamically (re-)configure the slice or 344 (re-)schedule said (re-)configurations in time, while, on the other 345 hand, allowing for the provider to convey to the client the slice's 346 operational state information and telemetry the client has expressed 347 interest in. 349 9. Dynamic Assignment of Regenerators for L0 Services 351 On large optical networks, some of provided to their clients L0 352 services could not be provisioned as single OCh trails, rather, as 353 chains of such trails interconnected via regenerators, such as 3R 354 regenerators. Current practice of the provisioning of such services 355 requires configuration of explicit paths (EROs) describing identity 356 and location of regenerators to be used. A solution is highly 357 desirable that could: 359 o Identify such services based, for example, on optical impairment 360 computations; 362 o Assign adequate for the services regenerators dynamically out of 363 the regenerators that are grouped together in pools and 364 strategically scattered over the network topology nodes; 366 o Compute and provision supporting the services chains of optical 367 trails interconnected via so selected regenerators, optimizing the 368 chains to use minimal number of regenerators, their optimal 369 locations, as well as optimality of optical paths interconnecting 370 them; 372 o Ensure recovery of such chains from any failures that could happen 373 on links, nodes or regenerators along the chain path. 375 NF-aware TE topology model (in this case L1 NF-aware L0 topology 376 model) is just the model that could provide a network controller (or 377 even a client controller operating on abstract NF-aware topologies 378 provided by the network) to realize described above computations and 379 orchestrate the service provisioning and network failure recovery 380 operations (see Figure 7). 382 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 383 Red trail (not regenerated) is not optically reachable, but blue 384 trail (twice regenerated) is 386 10. Dynamic Assignment of OAM Functions for L1 Services 388 OAM functionality is normally managed by configuring and manipulating 389 TCM/MEP functions on network ports terminating connections or their 390 segments over which OAM operations, such as performance monitoring, 391 are required to be performed. In some layer networks (e.g. 392 Ethernet) said TCMs/MEPs could be configured on any network ports. 393 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 394 (but not all network ports) due to the fact that the OAM 395 functionality (i.e. recognizing and processing of OAM messages, 396 supporting OAM protocols and FSMs) requires in these layer networks 397 certain support in the data plane, which is not available on all 398 network nodes. This makes TCMs/MEPs good candidates to be modeled as 399 NFs. This also makes TCM/MEP aware topology model a good basis for 400 placing dynamically an ODUk connection to pass through optimal OAM 401 locations without mandating the client to specify said locations 402 explicitly. 404 Figure 8: Compute/storage resource aware topology 406 11. SFC Abstraction and Scaling 408 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 409 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 410 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 411 of native and/or lower level abstract SFs/NFs). As in the case of 412 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 413 nature - the higher level of SF/NF-aware topology, the "larger" 414 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 415 This allows for managing large scale networks with great number of 416 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 417 scalable manner resulting in control of very large number of flat in 418 the data plane SFCs that span multiple domains. 420 12. Dynamic Compute/VM/Storage Resource Assignment 422 In a distributed data center network, virtual machines for compute 423 resources may need to be dynamically re-allocated due to various 424 reasons such as DCI network failure, compute resource load balancing, 425 etc. In many cases, the DCI connectivity for the source and the 426 destination is not predetermined. There may be a pool of sources and 427 a pool of destination data centers associated with re-allocation of 428 compute/VM/storage resources. There is no good mechanism to date to 429 capture this dynamicity nature of compute/VM/storage resource 430 reallocation. Generic Compute/VM/Storage resources can be described 431 and announced as a SF, where a DC hosting these resources can be 432 modeled as an abstract node. Topology interconnecting these abstract 433 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 434 topology model can facilitate a joint optimization of TE network 435 resources and Compute/VM/Storage resources and solve Compute/VM/ 436 Storage mobility problem within and between DCs (see Figure 8). 438 13. IANA Considerations 440 This document has no actions for IANA. 442 14. Security Considerations 444 This document does not define networking protocols and data, hence 445 are not directly responsible for security risks. 447 15. Acknowledgements 449 The authors would like to thank Maarten Vissers, Joel Halpern, and 450 Greg Mirsky for their helpful comments and valuable contributions. 452 16. References 454 16.1. Normative References 456 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 457 Service Function Chaining", RFC 7498, 458 DOI 10.17487/RFC7498, April 2015, . 461 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 462 Chaining (SFC) Architecture", RFC 7665, 463 DOI 10.17487/RFC7665, October 2015, . 466 [ETSI-NFV-TERM] 467 ETSI, "Network Functions Virtualisation (NFV); Terminology 468 for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1, 469 December 2014. 471 [I-D.ietf-teas-yang-te-topo] 472 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 473 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 474 teas-yang-te-topo-12 (work in progress), July 2017. 476 [I-D.ietf-teas-yang-te] 477 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 478 I. Bryskin, "A YANG Data Model for Traffic Engineering 479 Tunnels and Interfaces", draft-ietf-teas-yang-te-08 (work 480 in progress), July 2017. 482 16.2. Informative References 484 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 485 Address Translator (Traditional NAT)", RFC 3022, 486 DOI 10.17487/RFC3022, January 2001, . 489 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 490 NAT64: Network Address and Protocol Translation from IPv6 491 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 492 April 2011, . 494 [I-D.ietf-sfc-hierarchical] 495 Dolson, D., Homma, S., Lopez, D., Boucadair, M., Liu, D., 496 Ao, T., and V. Vu, "Hierarchical Service Function Chaining 497 (hSFC)", draft-ietf-sfc-hierarchical-04 (work in 498 progress), July 2017. 500 [I-D.defoy-netslices-3gpp-network-slicing] 501 Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", 502 draft-defoy-netslices-3gpp-network-slicing-02 (work in 503 progress), October 2017. 505 [_3GPP.28.801] 506 3GPP, "Study on management and orchestration of network 507 slicing for next generation network", 3GPP TR 28.801 508 V2.0.0, September 2017, 509 . 511 Authors' Addresses 513 Igor Bryskin 514 Huawei Technologies 516 EMail: Igor.Bryskin@huawei.com 518 Xufeng Liu 519 Jabil 521 EMail: Xufeng_Liu@jabil.com 523 Jim Guichard 524 Huawei Technologies 526 EMail: james.n.guichard@huawei.com 527 Young Lee 528 Huawei Technologies 530 EMail: leeyoung@huawei.com 532 Luis Miguel Contreras Murillo 533 Telefonica 535 EMail: luismiguel.contrerasmurillo@telefonica.com 537 Daniele Ceccarelli 538 Ericsson 540 EMail: daniele.ceccarelli@ericsson.com