idnits 2.17.1 draft-irtf-sdnrg-layered-sdn-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-12 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDN Research Group LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Standards Track CJ. Bernardos 5 Expires: May 4, 2017 UC3M 6 D. Lopez 7 Telefonica 8 M. Boucadair 9 Orange 10 P. Iovanna 11 Ericsson 12 October 31, 2016 14 Cooperating Layered Architecture for SDN 15 draft-irtf-sdnrg-layered-sdn-01 17 Abstract 19 Software Defined Networking proposes the separation of the control 20 plane from the data plane in the network nodes and its logical 21 centralization on a control entity. Most of the network intelligence 22 is moved to this functional entity. Typically, such entity is seen 23 as a compendium of interacting control functions in a vertical, tight 24 integrated fashion. The relocation of the control functions from a 25 number of distributed network nodes to a logical central entity 26 conceptually places together a number of control capabilities with 27 different purposes. As a consequence, the existing solutions do not 28 provide a clear separation between transport control and services 29 that relies upon transport capabilities. 31 This document describes a proposal named Cooperating Layered 32 Architecture for SDN. The idea behind that is to differentiate the 33 control functions associated to transport from those related to 34 services, in such a way that they can be provided and maintained 35 independently, and can follow their own evolution path. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 4, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Architecture overview . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Functional strata . . . . . . . . . . . . . . . . . . . . 8 75 3.1.1. Connectivity stratum . . . . . . . . . . . . . . . . 8 76 3.1.2. Service stratum . . . . . . . . . . . . . . . . . . . 9 77 3.1.3. Recursiveness . . . . . . . . . . . . . . . . . . . . 9 78 3.2. Plane separation . . . . . . . . . . . . . . . . . . . . 9 79 3.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 9 80 3.2.2. Management Plane . . . . . . . . . . . . . . . . . . 10 81 3.2.3. Resource Plane . . . . . . . . . . . . . . . . . . . 10 82 4. Required features . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Communication between SDN Controllers . . . . . . . . . . . . 11 84 6. Deployment scenarios . . . . . . . . . . . . . . . . . . . . 11 85 6.1. Full SDN environments . . . . . . . . . . . . . . . . . . 11 86 6.1.1. Multiple Service strata associated to a single 87 Connectivity stratum . . . . . . . . . . . . . . . . 11 88 6.1.2. Single service stratum associated to multiple 89 Connectivity strata . . . . . . . . . . . . . . . . . 12 90 6.2. Hybrid environments . . . . . . . . . . . . . . . . . . . 12 91 6.2.1. SDN Service stratum associated to a legacy 92 Connectivity stratum . . . . . . . . . . . . . . . . 12 93 6.2.2. Legacy Service stratum associated to an SDN 94 Connectivity stratum . . . . . . . . . . . . . . . . 12 95 6.3. Multi-domain scenarios in Connectivity Stratum . . . . . 12 96 7. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 7.1. Network Function Virtualization . . . . . . . . . . . . . 13 98 7.2. Abstraction and Control of Transport Networks . . . . . . 13 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 103 10.2. Informative References . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 106 1. Introduction 108 Software Defined Networking (SDN) proposes the separation of the 109 control plane from the data plane in the network nodes and its 110 logical centralization on a control entity. A programmatic interface 111 is defined between such entity and the network nodes, which 112 functionality is supposed to perform traffic forwarding (only). 113 Through that interface, the control entity instructs the nodes 114 involved in the forwarding plane and modifies their traffic 115 forwarding behavior accordingly. 117 Most of the intelligence is moved to such functional entity. 118 Typically, such entity is seen as a compendium of interacting control 119 functions in a vertical, tight integrated fashion. 121 This approach presents a number of issues: 123 o Unclear responsibilities between actors involved in a service 124 provision and delivery. 126 o Complex reuse of functions for the provision of services. 128 o Closed, monolithic control architectures. 130 o Difficult interoperability and interchangeability of functional 131 components. 133 o Blurred business boundaries among providers. 135 o Complex service/network diagnosis and troubleshooting, 136 particularly to determine which segment is responsible for a 137 failure. 139 The relocation of the control functions from a number of distributed 140 network nodes to another entity conceptually places together a number 141 of control capabilities with different purposes. As a consequence, 142 the existing solutions do not provide a clear separation between 143 services and transport control. 145 This document describes a proposal named Cooperating Layered 146 Architecture for SDN (CLAS). The idea behind that is to 147 differentiate the control functions associated to transport from 148 those related to services, in such a way that they can be provided 149 and maintained independently, and can follow their own evolution 150 path. 152 Despite such differentiation it is required a close cooperation 153 between service and transport layers and associated components to 154 provide an efficient usage of the resources. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC2119 [RFC2119]. 162 This document makes use of the following terms: 164 o Transport: denotes the transfer capabilities offered by a 165 networking infrastructure. The transfer capabilities can rely 166 upon pure IP techniques, or other means such as MPLS or optics. 168 o Service: denote a logical construct that make use of transport 169 capabilities. This document does not make any assumption on the 170 functional perimeter of a service that can be built above a 171 transport infrastructure. As such, a service can be an offering 172 that is offered to customers or be invoked for the delivery of 173 another (added-value) service. 175 o SDN intelligence: refers to the decision-making process that is 176 hosted by a node or a set of nodes. The intelligence can be 177 centralized or distributed. Both schemes are within the scope of 178 this document. The SDN intelligence relies on inputs form various 179 functional blocks such as: network topology discovery, service 180 topology discovery, resource allocation, business guidelines, 181 customer profiles, service profiles, etc. The exact decomposition 182 of an SDN intelligence, apart from the layering discussed in this 183 document, is out of scope. 185 Additionally, the following acronyms are used in this document. 187 CLAS: Cooperating Layered Architecture for SDN 189 FCAPS: Fault, Configuration, Accounting, Performance and Security 191 SDN: Software Defined Networking 192 SLA: Service Level Agreement 194 3. Architecture overview 196 Current operator networks support multiple services (e.g., VoIP, 197 IPTV, mobile VoIP, critical mission applications, etc.) on a variety 198 of transport technologies. The provision and delivery of a service 199 independently of the underlying transport capabilities requires a 200 separation of the service related functionalities and an abstraction 201 of the transport network to hide the specificities of underlying 202 transfer techniques while offering a common set of capabilities. 204 Such separation can provide configuration flexibility and 205 adaptability from the point of view of either the services or the 206 transport network. Multiple services can be provided on top of a 207 common transport infrastructure, and similarly, different 208 technologies can accommodate the connectivity requirements of a 209 certain service. A close coordination among them is required for a 210 consistent service delivery (inter-layer cooperation). 212 This document focuses particularly on: 214 o Means to expose transport capabilities to external services. 216 o Means to capture service requirements of services. 218 o Means to notify service intelligence with underlying transport 219 events, for example to adjust service decision-making process with 220 underlying transport events. 222 o Means to instruct the underlying transport capabilities to 223 accommodate new requirements, etc. 225 An example is to guarantee some Quality of Service (QoS) levels. 226 Different QoS-based offerings could be present at both service and 227 transport layers. Vertical mechanisms for linking both service and 228 transport QoS mechanisms should be in place to provide the quality 229 guarantees to the end user. 231 CLAS architecture assumes that the logically centralized control 232 functions are separated in two functional blocks or layers. One of 233 the functional blocks comprises the service-related functions, 234 whereas the other one contains the transport-related functions. The 235 cooperation between the two layers is considered to be implemented 236 through standard interfaces. 238 Figure 1 shows the CLAS architecture. It is based on functional 239 separation in the NGN architecture defined by the ITU-T in [Y.2011]. 241 Two strata of functionality are defined, namely the Service Stratum, 242 comprising the service-related functions, and the Connectivity 243 Stratum, covering the transport ones. The functions on each of these 244 layers are further grouped on control, management and user (or data) 245 planes. 247 North Bound Interface 249 /\ 250 || 251 +-------------------------------------||-------------+ 252 | Service Stratum || | 253 | \/ | 254 | ........................... | 255 | . SDN Controller . | 256 | . . | 257 | +--------------+ . +--------------+ . | 258 | | Resource Pl. | . | Mngmt. Pl. | . | 259 | | |<===>. +--------------+ | . | 260 | | | . | Control Pl. | | . | 261 | +--------------+ . | |-----+ . | 262 | . | | . | 263 | . +--------------+ . | 264 | ........................... | 265 | /\ | 266 | || | 267 +-------------------------------------||-------------+ 268 || 269 || 270 || 271 +-------------------------------------||-------------+ 272 | Connectivity Stratum || | 273 | \/ | 274 | ........................... | 275 | . SDN Controller . | 276 | . . | 277 | +--------------+ . +--------------+ . | 278 | | Resource Pl. | . | Mngmt. Pl. | . | 279 | | |<===>. +--------------+ | . | 280 | | | . | Control Pl. | | . | 281 | +--------------+ . | |-----+ . | 282 | . | | . | 283 | . +--------------+ . | 284 | ........................... | 285 | | 286 | | 287 +----------------------------------------------------+ 289 Figure 1: Cooperating Layered Architecture for SDN 291 In the CLAS architecture both the control and management functions 292 are the ones logically centralized in one or a set of SDN 293 controllers, in such a way that separated SDN controllers are present 294 in the Service and Connectivity strata. Furthermore, the generic 295 user or data plane functions included in the NGN architecture are 296 referred here as resource plane functions. The resource plane in 297 each stratum is controlled by the corresponding SDN controller 298 through a standard interface. 300 The SDN controllers cooperate for the provision and delivery of 301 services. There is a hierarchy in which the Service SDN controller 302 requests transport capabilities to the Transport SDN controller. 303 Furthermore, the Transport SDN controller interacts with the Service 304 SDN controller to inform it about events in the transport network 305 that can motivate actions in the service layer. 307 The Service SDN controller acts as a client of the Transport SDN 308 controller. 310 Despite it is not shown in the figure, the Resource planes of each 311 stratum could be connected. This will depend on the kind of service 312 provided. Furthermore, the Service stratum could offer an interface 313 towards external applications to expose network service capabilities 314 to those applications or customers. 316 This document does assume that SDN techniques can be enabled jointly 317 with other distributed means (e.g., IGP). 319 3.1. Functional strata 321 As described before, the functional split separates transport-related 322 functions from service-related functions. Both strata cooperate for 323 a consistent service delivery. 325 Consistecy is determined and characterized by the service layer. 327 Communication between these two components could be implemented using 328 a variety of means (such as 329 [I-D.boucadair-connectivity-provisioning-protocol], Intermediate- 330 Controller Plane Interface (I-CPI) [ONFArch], etc). 332 3.1.1. Connectivity stratum 334 The Connectivity stratum comprises the functions focused on the 335 transfer of data between the communication end points (e.g., between 336 end-user devices, between two service gateways, etc.). The data 337 forwarding nodes are controlled and managed by the Transport SDN 338 component. The Control plane in the SDN controller is in charge of 339 instructing the forwarding devices to build the end to end data path 340 for each communication or to make sure forwarding service is 341 appropriately setup. Forwarding may not be rely on the sole pre- 342 configured entries; dynamic means can be enabled so that involved 343 nodes can build dynamically routing and forwarding paths. Finally, 344 the Management plane performs management functions (i.e., FCAPS) on 345 those devices, like fault or performance management, as part of the 346 Connectivity stratum capabilities. 348 3.1.2. Service stratum 350 The Service stratum contains the functions related to the provision 351 of services and the capabilities offered to external applications. 352 The Resource plane consists of the resources involved in the service 353 delivery, such as computing resources, registries, databases, etc. 354 The Control plane is in charge of controlling and configuring those 355 resources, as well as interacting with the Control plane of the 356 Transport stratum in client mode for requesting transport 357 capabilities for a given service. In the same way, the Management 358 plane implements management actions on the service-related resources 359 and interacts with the Management plane in the Connectivity stratum 360 for a cooperating management between layers. 362 3.1.3. Recursiveness 364 Recursive layering can happen in some usage scenarios in which the 365 Connectivity Stratum is itself structured in Service and Connectivity 366 Stratum. This could be the case of the provision of a transport 367 services complemented with advanced capabilities additional to the 368 pure data transport (e.g., maintenance of a given SLA [RFC7297]). 370 3.2. Plane separation 372 The CLAS architecture leverages on the SDN proposition of plane 373 separation. As mentioned before, three different planes are 374 considered for each stratum. The communication among these three 375 planes (and with the corresponding plane in other strata) is based on 376 open, standard interfaces. 378 3.2.1. Control Plane 380 The Control plane logically centralizes the control functions of each 381 stratum and directly controls the corresponding resources. [RFC7426] 382 introduces the role of the control plane in a SDN architecture. This 383 plane is part of an SDN controller, and can interact with other 384 control planes in the same or different strata for accomplishing 385 control functions. 387 3.2.2. Management Plane 389 The Management plane logically centralizes the management functions 390 for each stratum, including the management of the Control and 391 Resource planes. [RFC7426] describes the functions of the management 392 plane in a SDN environment. This plane is also part of the SDN 393 controller, and can interact with the corresponding management planes 394 residing in SDN controllers of the same or different strata. 396 3.2.3. Resource Plane 398 The Resource plane comprises the resources for either the transport 399 or the service functions. In some cases the service resources can be 400 connected to the transport ones (e.g., being the terminating points 401 of a transport function) whereas in other cases it can be decoupled 402 from the transport resources (e.g., one database keeping some 403 register for the end user). Both forwarding and operational planes 404 proposed in [RFC7426] would be part of the Resource plane in this 405 architecture. 407 4. Required features 409 A number of features are required to be supported by the CLAS 410 architecture. 412 o Abstraction: the mapping of physical resources into the 413 corresponding abstracted resources. 415 o Service parameter translation: translation of service parameters 416 (e.g., in the form of SLAs) to transport parameters (or 417 capabilities) according to different policies. 419 o Monitoring: mechanisms (e.g. event notifications) available in 420 order to dynamically update the (abstracted) resources' status 421 taking in to account e.g. the traffic load. 423 o Resource computation: functions able to decide which resources 424 will be used for a given service request. As an example, 425 functions like PCE could be used to compute/select/decide a 426 certain path. 428 o Orchestration: ability to combine diverse resources (e.g., IT and 429 network resources) in an optimal way. 431 o Accounting: record of resource usage. 433 o Security: secure communication among components, preventing e.g. 434 DoS attacks. 436 5. Communication between SDN Controllers 438 The SDN Controller residing respectively in the Service and the 439 Connectivity Stratum need to establish a tight coordination. 440 Mechanisms for transfer relevant information for each stratum should 441 be defined. 443 From the Service perspective, the Service SDN controller needs to 444 easily access transport resources through well defined APIs to access 445 the capabilities offered by the Connectivity Stratum. There could be 446 different ways of obtainign such transport-aware information, i.e., 447 by discovering or publishing mechanisms. In the former case the 448 Service SDN Controller could be able of handling complete information 449 about the transport capabilities (including resources) offered by the 450 Connectivity Stratum. In the latter case, the Connectivity Stratum 451 exposes available capabilities e.g. through a catalog, reducing the 452 amount of detail of the underlying network. 454 On the other hand, the Connectivity Stratum requires to properly 455 capture Service requirements. These can include SLA requirements 456 with specific metrics (such as delay), level of protection to be 457 provided, max/min capacity, applicable resource constraints, etc. 459 The communication between controllers should be also secure, 460 preventing denial of service. 462 6. Deployment scenarios 464 Different situations can be found depending on the characteristics of 465 the networks involved in a given deployment. 467 6.1. Full SDN environments 469 This case considers the fact that the networks involved in the 470 provision and delivery of a given service have SDN capabilities. 472 6.1.1. Multiple Service strata associated to a single Connectivity 473 stratum 475 A single Connectivity stratum can provide transfer functions to more 476 than one Service strata. The Connectivity stratum offers a standard 477 interface to each of the Service strata. The Service strata are the 478 clients of the Connectivity stratum. Some of the capabilities 479 offered by the Connectivity stratum can be isolation of the transport 480 resources (slicing), independent routing, etc. 482 6.1.2. Single service stratum associated to multiple Connectivity 483 strata 485 A single Service stratum can make use of different Connectivity 486 strata for the provision of a certain service. The Service stratum 487 interfaces each of the Connectivity strata with standard protocols, 488 and orchestrates the provided transfer capabilities for building the 489 end to end transport needs. 491 6.2. Hybrid environments 493 This case considers scenarios where one of the strata is legacy 494 totally or in part. 496 6.2.1. SDN Service stratum associated to a legacy Connectivity stratum 498 An SDN service stratum can interact with a legacy Connectivity 499 stratum through some interworking function able to adapt SDN-based 500 control and management service-related commands to legacy transport- 501 related protocols, as expected by the legacy Connectivity stratum. 502 The SDN controller in the Service stratum is not aware of the legacy 503 nature of the underlying Connectivity stratum. 505 6.2.2. Legacy Service stratum associated to an SDN Connectivity stratum 507 A legacy Service stratum can work with an SDN-enabled Connectivity 508 stratum through the mediation of and interworking function capable to 509 interpret commands from the legacy service functions and translate 510 them into SDN protocols for operating with the SDN-enabled 511 Connectivity stratum. 513 6.3. Multi-domain scenarios in Connectivity Stratum 515 The Connectivity Stratum can be composed by transport resources being 516 part of different administrative, topological or technological 517 domains. The Service Stratum can yet interact with a single entity 518 in the Connectivity Stratum in case some abstraction capabilities are 519 provided in the transport part to emulate a single stratum. 521 Those abstraction capabilities constitute a service itself offered by 522 the Connectivity Stratum to the services making use of it. This 523 service is focused on the provision of transport capabilities, then 524 different of the final communication service using such capabilities. 526 In this particular case this recursion allows multi-domain scenarios 527 at transport level. 529 Multi-domain situations can happen in both single-operator and multi- 530 operator scenarios. Multi-operator scenarios will be addressed in 531 future versions of the document. 533 In single operator scenarios a multi-domain or end-to-end abstraction 534 component can provide an homogeneous abstract view of the underlying 535 heterogeneous transport capabilities for all the domains. 537 7. Use cases 539 This section presents a number of use cases as examples of 540 applicability of this proposal 542 7.1. Network Function Virtualization 544 NFV environments offer two possible levels of SDN control 545 [ETSI_NFV_EVE005]. One level is the need for controlling the NFVI to 546 provide connectivity end-to- end among VNFs (Virtual Network 547 Functions) or among VNFs and PNFs (Physical Network Functions). A 548 second level is the control and configuration of the VNFs themselves 549 (in other words, the configuration of the network service implemented 550 by those VNFs), taking profit of the programmability brought by SDN. 551 Both control concerns are separated in nature. However, interaction 552 between both could be expected in order to optimize, scale or 553 influence each other. 555 7.2. Abstraction and Control of Transport Networks 557 To be completed. 559 8. IANA Considerations 561 TBD. 563 9. Security Considerations 565 TBD. Security in the communication between strata to be addressed. 567 10. References 569 10.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [Y.2011] "General principles and general reference model for Next 577 Generation Networks", ITU-T Recommendation Y.2011 , 578 October 2004. 580 10.2. Informative References 582 [ETSI_NFV_EVE005] 583 "Report on SDN Usage in NFV Architectural Framework", 584 Dicember 2015. 586 [I-D.boucadair-connectivity-provisioning-protocol] 587 Boucadair, M., Jacquenet, C., Zhang, D., and P. 588 Georgatsos, "Connectivity Provisioning Negotiation 589 Protocol (CPNP)", draft-boucadair-connectivity- 590 provisioning-protocol-12 (work in progress), June 2016. 592 [ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1", 593 June 2014, 594 . 598 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 599 Connectivity Provisioning Profile (CPP)", RFC 7297, 600 DOI 10.17487/RFC7297, July 2014, 601 . 603 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 604 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 605 Defined Networking (SDN): Layers and Architecture 606 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 607 2015, . 609 Authors' Addresses 611 Luis M. Contreras 612 Telefonica 613 Ronda de la Comunicacion, s/n 614 Sur-3 building, 3rd floor 615 Madrid 28050 616 Spain 618 Email: luismiguel.contrerasmurillo@telefonica.com 619 URI: http://lmcontreras.com 620 Carlos J. Bernardos 621 Universidad Carlos III de Madrid 622 Av. Universidad, 30 623 Leganes, Madrid 28911 624 Spain 626 Phone: +34 91624 6236 627 Email: cjbc@it.uc3m.es 628 URI: http://www.it.uc3m.es/cjbc/ 630 Diego R. Lopez 631 Telefonica 632 Ronda de la Comunicacion, s/n 633 Sur-3 building, 3rd floor 634 Madrid 28050 635 Spain 637 Email: diego.r.lopez@telefonica.com 639 Mohamed Boucadair 640 Orange 641 Rennes 35000 642 France 644 Email: mohamed.boucadair@orange.com 646 Paola Iovanna 647 Ericsson 648 Pisa 649 Italy 651 Email: paola.iovanna@ericsson.com