idnits 2.17.1 draft-barguil-teas-network-slices-instantation-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (22 February 2021) is 1130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.827' is mentioned on line 340, but not defined == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-03 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-01 == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-05 == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-05 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Barguil 3 Internet-Draft L.M. Contreras 4 Intended status: Informational V. Lopez 5 Expires: 26 August 2021 O. Gonzalez de Dios 6 Telefonica 7 22 February 2021 9 Instantiation of IETF Network Slices in service providers networks 10 draft-barguil-teas-network-slices-instantation-00 12 Abstract 14 The IETF has produced several YANG data models to support the 15 Software-Defined Networking and Network Slice Architecture. This 16 document describes the relationship between the abstract (generic, or 17 base) Service Models utilized for the Network Slices requests and the 18 Network Models (e.g. L3NM, L2NM). This document describes the 19 communication between the Network Slice Controller and a network 20 controller for IETF network slice creation. 22 The YANG service models available for network slicing provide a 23 customer-oriented view of the network. Thus, once the Network Slice 24 controller (NSC)receives a request, it needs to expand it to 25 accomplish the specific parameters expected by the network 26 controller. The network models are analyzed in terms of how they can 27 satisfy the IETF Network Slice requirements. Identified gaps on 28 existing models are reported. 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 https://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 26 August 2021. 47 Copyright Notice 49 Copyright (c) 2021 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 (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Reference architecture . . . . . . . . . . . . . . . . . . . 3 66 3. IETF Network Slice: requirements and data models . . . . . . 6 67 4. Yang Models for Network Controllers . . . . . . . . . . . . . 7 68 4.1. LxVPN Network Models . . . . . . . . . . . . . . . . . . 7 69 4.2. Traffic Engineering Models . . . . . . . . . . . . . . . 8 70 4.3. Traffic Engineering Service Mapping . . . . . . . . . . . 8 71 5. Compliance of Network Controller models with IETF Network slice 72 requirements. . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Availability . . . . . . . . . . . . . . . . . . . . . . 8 74 5.2. Downlink throughput / Uplink throughput. . . . . . . . . 9 75 6. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.1. Slice requested to Hierarchical Network Controller . . . 9 77 6.2. Slice requested to Network Slice Controller . . . . . . . 10 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 The IETF has produced several YANG data models to support the 87 Software-Defined Networking and Network Slice Architecture. This 88 document describes the relationship between the abstract (generic, or 89 base) Service Models utilized for the Network Slices requests and the 90 Network Models (e.g. L3NM, L2NM, TE, etc). This document describes 91 the communication between the Network Slice Controller and a network 92 controller for IETF network slice creation. 94 The YANG service models available for network slicing provide a 95 customer-oriented view of the network. Thus, once the Network Slice 96 controller (NSC)receives a request, it needs to expand it to 97 accomplish the specific parameters expected by the network 98 controller. The network models are analyzed in terms of how they can 99 satisfy the IETF Network Slice requirements. Identified gaps on 100 existing models are reported. 102 Editor's Note: the terminology in this draft will be aligned with the 103 final terminology selected for describing the notion of IETF Network 104 Slice when applied to IETF technologies, which is currently under 105 discussion. By now same terminology as used in 106 [I-D.ietf-teas-ietf-network-slice-definition] and 107 [I-D.nsdt-teas-ns-framework] is primarily used here. Consensus to 108 use "IETF Network Slice" term has been reached. 110 1.1. Terminology 112 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 113 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 114 document, are to be interpreted as described in [RFC2119]. 116 2. Reference architecture 118 Several architectural definitions have arisen on the IETF to support 119 SDN and network slicing deployments. The architectural proposal 120 defined in [I-D.ietf-teas-ietf-network-slice-definition] includes a 121 three-level hierarchy and expresses how each level relates with the 122 ACTN architecture framework. 124 Figure 1 defines a sample architecture using those concepts. It 125 starts from a top consumer or high-level operating system. Next, the 126 network Slice Controller function is part of the Hierarchical network 127 controller (e.g., as the MDSC in the ACTN context [RFC8453]) as a 128 modular function. At the bottom, two network controllers, each one 129 can handle multiple or single underlay technologies. 131 +------------------------------+ 132 | High-level operation system. | 133 +--------------+---------------+ 134 |Slice Request 135 | 136 +-------------------v------------------+ 137 | | 138 | Hierarchical Network | 139 | Controller/Orchestrator | 140 | | 141 | +------------------------------+ | 142 | | Network Slice Controller | | 143 | +------------------------------+ | 144 | | 145 +-------------------+------------------+ 146 | 147 | 148 +--------------+---------------+ 149 | | 150 v v 151 +-------------+----------+ +-------------+----------+ 152 | Network Controller | | Network Controller | 153 +-------------+----------+ +-------------+----------+ 154 | | 155 | | 156 v v 157 Network Elements Network Elements 159 Figure 1 Network Slice Controller as a module of the Hierarchical SDN 160 controller. 162 In other implementations, the NSC can be a stand-alone element and 163 directly interact with the network controller, as depicted in 164 Figure 2. In this scenario, the services request follows a data- 165 enrichment path, where each entity adds more information to the 166 service request. This document describes how the available service 167 models and network models interact to deliver the network slices in a 168 service provider environment. 170 +------------------------------+ 171 | High-level operation system | 172 +--------------+---------------+ 173 |Slice Request 174 | 175 +-------------v----------------+ 176 | Network Slice Controller | 177 +-------------+----------------+ 178 | 179 | 180 | 181 +-------------v----------------+ 182 | Network Controller | 183 +-------------+----------------+ 184 | 185 | 186 v 187 Network Elements 189 Figure 2 Network Slice Controller as a stand-alone entity. 191 As another implementation possibility, the Network Slice Controller 192 can be integrated with the Network controller and directly realize 193 the network slice using device data models to configure the network 194 devices. The sample architecture is depicted in Figure 4. 196 + 197 |Slice/VPN Request 198 | 199 +-------------v----------------+ 200 | Network Controller | 201 | | 202 |+----------------------------+| 203 || Network Slice Controller || 204 |+----------------------------+| 205 | | 206 +-------------+----------------+ 207 | 208 | 209 v 210 Network Elements 212 Figure 3 Network Slice Controller as a module of the Network 213 controller. 215 3. IETF Network Slice: requirements and data models 217 The main set of requirements for the IETF Slice, based on the high- 218 level slice requirements from multiple organizations and use cases, 219 are compiled in [I-D.contreras-teas-slice-nbi] and reproduced bellow 220 for one of the slice use cases reported as example: 222 +-----------------------------------------------+ 223 | Network Slice Requeriments for 5G service | 224 +-----------------------------------------------+ 225 | Availability | 226 | Deterministic communication | 227 | Downlink throughput per network slice | 228 | Energy efficiency | 229 | Group communication support | 230 | Isolation level | 231 | Maximum supported packet size | 232 | Mission critical support | 233 | Performance monitoring | 234 | Slice quality of service parameters | 235 | Support for non-IP traffic | 236 | Uplink throughput per network slice | 237 | User data access (i.e., tunneling mechanisms) | 238 +-----------------------------------------------+ 240 TODO#1: Summarize the requirements based on the different slice use 241 cases described in [I-D.contreras-teas-slice-nbi]. 243 To accomplish those requirements, a set of YANG data models have been 244 proposed. Those Yang models , summarized in table xx, could be used 245 by an IETF Network Slice Controller to manage CRUD operations on the 246 IETF Network Slice. That is, these models aim capturing the 247 requirements from the consumer of the slice point of view and avoid 248 entering into the detail of how the slice is actually created. 250 * [draft-wd-teas-ietf-network-slice-nbi-yang-01]: A Yang Data Model 251 for IETF Network Slice NBI. 253 * [draft-liu-teas-transport-network-slice-yang-00]: Transport 254 Network Slice YANG Data Model. 256 4. Yang Models for Network Controllers 258 A network controller, understood as the entity responsible for 259 managing a particular network domain, can expose a northbound 260 interface based on YANG models. That is, those YANG models will 261 define datastores that apply for a whole network domain and will 262 manage network-level concepts. The types of network models that are 263 of interest for the instantiation of IETF Network slices are: 265 * LxVPN Network models: 267 - These models describe a VPN service from the network point of 268 view. 270 * Traffic Engineering models: 272 - These models allow to manipulate Traffic Engineering tunnels 273 within the network segment. Technology-specific extensions 274 allow to work with a desired technology (e.g. MPLS RSVP-TE 275 tunnels, Segment Routing paths, OTN tunnels, etc.) 277 * TE Service Mapping extensions: 279 - These extensions allow to specify for LxVPN the details of an 280 underlay based on TE. 282 * ACLs and routing policies models: 284 - Even though ACLs and routing policies are device models, it's 285 exposure in the NBI of a domain controller allows to provide an 286 additional granularity that the network domain controller is 287 not able to infer on its own. 289 4.1. LxVPN Network Models 291 The framework defined in [RFC8969] compiles a set of YANG data models 292 for automating network services. The data models can be used during 293 the service and network management life cycle (e.g., service 294 instantiation, service provisioning, service optimization, service 295 monitoring, service diagnosing, and service assurance). The so 296 called Network models could be reused for the realization of Network 297 slice requests. 299 The following models are examples of Network models that describe 300 services. 302 * [I-D.ietf-opsawg-l3sm-l3nm]: A Layer 3 VPN Network YANG Model 303 * [I-D.ietf-opsawg-l2nm]: A Layer 2 VPN Network YANG Model 305 4.2. Traffic Engineering Models 307 TEAS has defined a collection of models to allow the management of 308 Traffic Engineering tunnels. 310 * [I-D.ietf-teas-yang-te]: A YANG Data Model for Traffic Engineering 311 Tunnels, Label Switched Paths and Interfaces. The model allows to 312 instantiate paths in a TE enabled network. Note that technology 313 augmented models are require to particular per-technology 314 instantiations. 316 4.3. Traffic Engineering Service Mapping 318 The IETF has defined a YANG model to set up the procedure to map VPN 319 service/network models to the TE models. This model, known as 320 service mapping, allows the network controller to assign/retrieve 321 transport resources allocated to specific services. At the moment 322 there is just one service mapping model 323 [I-D.ietf-teas-te-service-mapping-yang]. The "Traffic Engineering 324 (TE) and Service Mapping Yang Model" augments the VPN service and 325 network models. 327 5. Compliance of Network Controller models with IETF Network slice 328 requirements. 330 Section 3 presented the requirements of the IETF Network slice. In 331 this subsection it is analyzed how available YANG models that can be 332 used by a Network Controller can satisfy those requirements and 333 identify gaps. 335 5.1. Availability 337 As per [draft-ietf-teas-te-service-mapping-yang-05], Availability is 338 a probabilistic measure of the length of time that a VPN/VN instance 339 functions without a network failure. As per RFC 8330, The parameter 340 "availability", as described in [G.827], [F.1703], and [P.530], is 341 often used to describe the link capacity. The availability is a time 342 scale, representing a proportion of the operating time that the 343 requested bandwidth is ensured". 345 The calculation of the availability is not trivial and would need to 346 be clearly scoped to avoid misunderstandings. 348 The set of Yang models proposed today allow to request tunnels/paths 349 with different resiliency requirements in terms of protection and 350 restoration. However, none of them include the possibility of 351 requesting a specific availability (e.g. 99.9999%). 353 5.2. Downlink throughput / Uplink throughput. 355 The LxVPN Models allow to specify the bandwdidth at the interface 356 level between the slice and the customer. In addition, the TE models 357 allow to force a give bandwidth in the connection between Provider 358 Edges. 360 6. Interactions 362 6.1. Slice requested to Hierarchical Network Controller 364 When the Network Slice Controller is a Hierarchical SDN controller 365 module, the NSC's and the Hierarchical Network Controller should 366 share the same internal data and the same NBI. Thus, to process the 367 customer, view the H-SDN module must be able to: 369 * _Map_: The customer request received using the [draft-wd-teas- 370 ietf-network-slice-nbi-yang-01] must be processed by the NCS. The 371 mapping process takes the network-slice SLAs selected by the 372 customer to available Routing Policies and Forwarding policies. 374 * _Realize_: Create necessary network requests. The slice's 375 realization can be translated into one or several LXNM Network 376 requests, depending on the number of underlay controllers. Thus, 377 the NCS must have a complete view of the network to map the orders 378 and distribute them across domains. The realization should 379 include the expansion/selection of Forwarding Policies, Routing 380 Policies, VPN policies, and Underlay transport preference. 382 To maintain the data coherence between the control layers, the 383 "network-slice-id" used of the [draft-wd-teas-ietf-network-slice-nbi- 384 yang-01] must be directly mapped to the `transport-instance-id at the 385 VPN-Node level. 387 + 388 | 389 | Slice Request: 390 draft-wd-teas-ietf-network-slice-nbi-yang-01 391 | * network-slice-id 392 | 393 +-------------------v------------------+ 394 | | 395 | Hierarchical Network | 396 | Controller/Orchestrator | 397 | | 398 | +------------------------------+ | 399 | | Network Slice Controller | | 400 | +------------------------------+ | 401 | | 402 +-------------------+------------------+ 403 Slice Realizer: LXNM | 404 VPN-id | 405 * transport-instance-id 406 | 407 +--------------+---------------+ 408 | | 409 v v 410 +-------------+----------+ +-------------+----------+ 411 | Network Controller | | Network Controller | 412 +-------------+----------+ +-------------+----------+ 413 | | 414 | | 415 v v 416 Network Elements Network Elements 418 Figure 4 Workflow for the slice request in an integrated 419 architecture. 421 6.2. Slice requested to Network Slice Controller 423 When the Network Slice Controller is a stand-alone controller module, 424 the NSC's should perform the same two tasks described before: 426 * _Map_: Process the customer request. The customer request can be 427 sent using the [draft-liu-teas-transport-network-slice-yang-01]. 428 This draft allows the topology mapping of the Slice request. 430 * _Realize_: Create necessary network requests. The slice's 431 realization will be translated into one LXNM Network request. As 432 the NCS has a topological view of the network, the realization can 433 include the customer's traffic engineering transport preferences 434 and policies. 436 + 437 |Slice Request 438 draft-liu-teas-transport-network-slice-yang-01 439 network-id 440 | 441 +-------------v----------------+ 442 | Network Slice Controller | 443 +-------------+----------------+ 444 | 445 Slice Realizer: LXNM 446 VPN-id | 447 * Underlay-transport 448 * transport-instance-id 449 | 450 +-------------v----------------+ 451 | Network Controller | 452 +-------------+----------------+ 453 | 454 | 455 v 456 Network Elements 458 Figure 5 Workflow for the slice request in an stand-alone 459 architecture. 461 TODO#2: Include description for the scenario in Figure 3. 463 7. Security Considerations 465 There are two main aspects to consider. On the one hand, the IETF 466 Network Slice has a set of security related requirements, such as 467 hard isolation of the slice, or encryption of the communications 468 through the slice. All those requirements need to be analyzed in 469 detailed and cleary mapped to the Network Controller and device 470 interfaces. On the other hand, the communication between the IETF 471 network slicer and the network controller (or controllers or 472 hierarchy of controllers) need to follow the same security 473 considerations as with the network models. The network YANG modules 474 defines schemas for data that is designed to be accessed via network 475 management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 476 The lowest NETCONF layer is the secure transport layer, and the 477 mandatory-to-implement secure transport is Secure Shell (SSH) 478 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 479 implement secure transport is TLS [RFC8466]. The Network 480 Configuration Access Control Model (NACM) [RFC8341] provides the 481 means to restrict access for particular NETCONF or RESTCONF users to 482 a preconfigured subset of all available NETCONF or RESTCONF protocol 483 operations and content. 485 The following summarizes the foreseen risks of using the Network 486 Models to instantiate IETF network Slices: - Malicious clients 487 attempting to delete or modify VPN services that implements an IETF 488 network slice. The malicious client could manipulate security 489 related aspects of the network configuration that impact the 490 requirements of the slice, failing to satisfy the customer 491 requirement. - Unauthorized clients attempting to create/modify/ 492 delete a VPN hat implements an IETF network slice service. 493 - Unauthorized clients attempting to read VPN services related 494 information hat implements an IETF network slice - Malicious clients 495 attempting to leak traffic of the slice. 497 8. IANA Considerations 499 This document is informational and does not require IANA allocations. 501 9. Conclusions 503 A wide variety of yang models are currently under definition in IETF 504 that can be used by Network Controllers to instantiate IETF network 505 slices. Some of the IETF slice requirements can be satisfied by 506 multiple means, as there are multiple choices avaialable. However, 507 other requirements are still not covered by the existing models. A 508 more detailed definition of those uncovered requirements would be 509 needed. Finally a consensus on the set of models to be exposed by 510 Network Controllers would facilitate the deployment of IETF network 511 slices. 513 10. Normative References 515 [I-D.contreras-teas-slice-nbi] 516 Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF 517 Network Slice use cases and attributes for Northbound 518 Interface of controller", Work in Progress, Internet- 519 Draft, draft-contreras-teas-slice-nbi-03, 30 October 2020, 520 . 523 [I-D.ietf-opsawg-l2nm] 524 barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, 525 L., and J. Ma, "A Layer 2 VPN Network YANG Model", Work in 526 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-01, 2 527 November 2020, 528 . 530 [I-D.ietf-opsawg-l3sm-l3nm] 531 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 532 Aguado, "A Layer 3 VPN Network YANG Model", Work in 533 Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05, 534 16 October 2020, . 537 [I-D.ietf-teas-ietf-network-slice-definition] 538 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 539 Tantsura, "Definition of IETF Network Slices", Work in 540 Progress, Internet-Draft, draft-ietf-teas-ietf-network- 541 slice-definition-00, 25 January 2021, 542 . 545 [I-D.ietf-teas-te-service-mapping-yang] 546 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 547 and J. Tantsura, "Traffic Engineering (TE) and Service 548 Mapping Yang Model", Work in Progress, Internet-Draft, 549 draft-ietf-teas-te-service-mapping-yang-05, 2 November 550 2020, . 553 [I-D.ietf-teas-yang-te] 554 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 555 "A YANG Data Model for Traffic Engineering Tunnels, Label 556 Switched Paths and Interfaces", Work in Progress, 557 Internet-Draft, draft-ietf-teas-yang-te-25, 27 July 2020, 558 . 560 [I-D.nsdt-teas-ns-framework] 561 Gray, E. and J. Drake, "Framework for Transport Network 562 Slices", Work in Progress, Internet-Draft, draft-nsdt- 563 teas-ns-framework-04, 13 July 2020, 564 . 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 573 and A. Bierman, Ed., "Network Configuration Protocol 574 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 575 . 577 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 578 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 579 . 581 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 582 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 583 . 585 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 586 Access Control Model", STD 91, RFC 8341, 587 DOI 10.17487/RFC8341, March 2018, 588 . 590 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 591 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 592 DOI 10.17487/RFC8453, August 2018, 593 . 595 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 596 Data Model for Layer 2 Virtual Private Network (L2VPN) 597 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 598 2018, . 600 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 601 L. Geng, "A Framework for Automating Service and Network 602 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 603 January 2021, . 605 Authors' Addresses 607 Samier Barguil 608 Telefonica 609 Distrito T 610 Madrid 612 Email: samier.barguilgiraldo.ext@telefonica.com 614 Luis Miguel Contreras 615 Telefonica 616 Distrito T 617 Madrid 619 Email: luismiguel.contrerasmurillo@telefonica.com 621 Victor Lopez 622 Telefonica 623 Distrito T 624 Madrid 626 Email: victor.lopezalvarez@telefonica.com 627 Oscar Gonzalez de Dios 628 Telefonica 629 Distrito T 630 Madrid 632 Email: oscar.gonzalezdedios@telefonica.com