idnits 2.17.1 draft-ietf-sfc-hierarchical-11.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 (June 25, 2018) is 2130 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Virus' is mentioned on line 1040, but not defined == Missing Reference: 'Monitor' is mentioned on line 1052, but not defined == Missing Reference: 'CF' is mentioned on line 1073, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining D. Dolson 3 Internet-Draft Sandvine 4 Intended status: Experimental S. Homma 5 Expires: December 27, 2018 NTT 6 D. Lopez 7 Telefonica I+D 8 M. Boucadair 9 Orange 10 June 25, 2018 12 Hierarchical Service Function Chaining (hSFC) 13 draft-ietf-sfc-hierarchical-11 15 Abstract 17 Hierarchical Service Function Chaining (hSFC) is a network 18 architecture allowing an organization to decompose a large-scale 19 network into multiple domains of administration. 21 The goals of hSFC are to make a large-scale network easier to reason 22 about, simpler to control and to support independent functional 23 groups within large network operators. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 27, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Experiment Goals . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 5 63 3.1. Top Level . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 9 66 4.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 9 67 4.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 10 68 4.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 11 69 4.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 12 70 4.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 12 71 4.1.5. Stateful/Metadata Hybrid . . . . . . . . . . . . . . 13 72 4.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 15 73 4.3. Decrementing Service Index . . . . . . . . . . . . . . . 15 74 4.4. Managing TTL . . . . . . . . . . . . . . . . . . . . . . 15 75 5. Sub-domain Classifier . . . . . . . . . . . . . . . . . . . . 16 76 6. Control Plane Elements . . . . . . . . . . . . . . . . . . . 17 77 7. Extension for Adapting to NSH-Unaware Service Functions . . . 17 78 7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 7.2. Requirements for IBN . . . . . . . . . . . . . . . . . . 19 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20 83 9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 21 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 87 11.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Appendix A. Examples of Hierarchical Service Function Chaining . 23 89 A.1. Reducing the Number of Service Function Paths . . . . . . 23 90 A.2. Managing a Distributed Data-Center Network . . . . . . . 25 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 Service Function Chaining (SFC) is a technique for prescribing 96 differentiated traffic forwarding policies within an SFC-enabled 97 domain. The SFC architecture is described in detail in [RFC7665], 98 and is not repeated here. 100 This document focuses on the difficult problem of implementing SFC 101 across a large, geographically dispersed network, potentially 102 comprised of millions of hosts and thousands of network forwarding 103 elements, and which may involve multiple operational teams (with 104 varying functional responsibilities). We recognize that some 105 stateful Service Functions (SFs) require bidirectional traffic for 106 transport-layer sessions (e.g., NATs, firewalls). We assume that 107 some Service Function Paths (SFPs) need to be selected on the basis 108 of transport-layer coordinate (typically, the 5-tuple of source IP 109 address, source port number, destination IP address, destination port 110 number, and transport protocol) stickiness to specific stateful SF 111 instances. 113 Difficult problems are often made easier by decomposing them in a 114 hierarchical (nested) manner. So instead of considering a single SFC 115 Control Plane that can manage (create, withdraw, supervise, etc.) 116 complete SFPs from one end of the network to the other, we decompose 117 the network into smaller domains operated by as many SFC control 118 plane components (under the same administrative entity). 119 Coordination between such components is further discussed in the 120 document. 122 Each sub-domain may support a subset of the network applications or a 123 subset of the users. Decomposing a network should be done with care 124 to ease monitoring and troubleshooting of the network and services as 125 a whole. The criteria for decomposing a domain into multiple SFC- 126 enabled sub-domains are beyond the scope of this document. These 127 criteria are deployment-specific. 129 An example of simplifying a network by using multiple SFC-enabled 130 domains is further discussed in [I-D.ietf-sfc-dc-use-cases]. 132 We assume the SFC-aware nodes use Network Service Header (NSH) 133 [RFC8300] or a similar labeling mechanism. Sample examples are 134 described in Appendix A. 136 The SFC-enabled domains discussed in this document are assumed to be 137 under the control of a single organization (an operator, typically), 138 such that there is a strong trust relationship between the domains. 139 The intention of creating multiple domains is to improve the ability 140 to operate a network. It is outside of the scope of the document to 141 consider domains operated by different organizations or to dwell on 142 inter-operator considerations. 144 We introduce the concept of an Internal Boundary Node (IBN) that acts 145 as a gateway between the levels of the hierarchy. We also discuss 146 options for realizing this function. 148 1.1. Experiment Goals 150 This document defines an architecture which aims to solve 151 complications that may be encountered when deploying SFC in large 152 networks. A single network is therefore decomposed into multiple 153 sub-domains; each treated as an SFC-enabled domain. Levels of 154 hierarchy are defined together with SFC operations that are specific 155 to each level. In order to ensure consistent SFC operations when 156 multiple sub-domains are involved, the document identifies and 157 analyses various options for IBNs to glue the layers together 158 (Section 4.1). 160 Because the document does not make any assumption about (1) how sub- 161 domains are defined, (2) whether one or multiple IBNs are enabled per 162 sub-domain, (3) whether the same IBN is solicited at both the ingress 163 and egress of a sub-domain for the same flow, (4) the nature of the 164 internal paths to reach SFs within a sub-domain, and (5) the lack of 165 deployment feedback, this document does not call for a recommended 166 option to glue the SFC layers together. 168 Further experiments are required to test and evaluate the different 169 options. A recommendation for hSFC might be documented in a future 170 specification when the results of implementation and deployment of 171 the aforementioned options are available. 173 It is not expected that all the options discussed in this document 174 will be implemented and deployed. The lack of an implementation 175 might be seen as a signal to recommend against a given option. 177 2. Terminology 179 This document makes use of the terms defined in Section 1.4 of 180 [RFC7665] and Section 1.3 of [RFC8300]. 182 The following terms are defined: 184 o High-level: encompasses the entire network domain to be managed. 186 o Lower-level: encompasses a portion of the network (called, sub- 187 domain). 189 o Internal Boundary Node (IBN): is responsible for bridging packets 190 between higher and lower levels of SFC-enabled domains. 192 Top-level and high-level are used interchangeably. 194 3. Hierarchical Service Function Chaining (hSFC) 196 A hierarchy has multiple levels: the top-most level encompasses the 197 entire network domain to be managed, and lower levels encompass 198 portions of the network. These levels are discussed in the following 199 sub-sections. 201 3.1. Top Level 203 Considering the example depicted in Figure 1, a top-level network 204 domain includes SFC data plane components distributed over a wide 205 area, including: 207 o Classifiers (CFs), 209 o Service Function Forwarders (SFFs) and 211 o Sub-domains. 213 +------------+ 214 |Sub-domain#1| 215 | in DC1 | 216 +----+-------+ 217 | 218 .---- SFF1 ------. +----+ 219 +----+ / / | \--|CF#4| 220 --->|CF#1|--/---->' | \ +----+ 221 +----+ / SC#1 | \ 222 | | | 223 | V .------>|---> 224 | / / | 225 \ | / / 226 +----+ \ | / / +----+ 227 |CF#2|---\ | / /---|CF#3| 228 +----+ '---- SFF2 ------' +----+ 229 | 230 +----+-------+ 231 |Sub-domain#2| 232 | in DC2 | 233 +------------+ 235 Legend: 236 SC#1: Service Chain 1 237 DC: Data Center 239 Figure 1: Network-wide view of top-level of hierarchy 241 One path is shown from edge classifier (CF#1) to SFF1 to Sub-domain#1 242 (residing in data-center1) to SFF1 to SFF2 (residing in data-center 243 2) to Sub-domain#2 to SFF2 to network egress. 245 For the sake of clarity, components of the underlay network are not 246 shown; an underlay network is assumed to provide connectivity between 247 SFC data plane components. 249 Top-level SFPs carry packets from classifiers through a set of SFFs 250 and sub-domains, with the operations within sub-domains being opaque 251 to the higher levels. 253 We expect the system to include a top-level control plane having 254 responsibility for configuring forwarding policies and traffic 255 classification rules. 257 The top-level Service Chaining control plane manages end-to-end 258 service chains and associated service function paths from network 259 edge points to sub-domains and configures top-level classifiers at a 260 coarse level (e.g., based on source or destination host) to forward 261 traffic along paths that will transit across appropriate sub-domains. 263 Figure 1 shows one possible service chain passing from edge, through 264 two sub-domains, to network egress. The top-level control plane does 265 not configure traffic classification rules or forwarding policies 266 within the sub-domains. 268 At this network-wide level, the number of SFPs required is a linear 269 function of the number of ways in which a packet is required to 270 traverse different sub-domains and egress the network. Note that the 271 various paths which may be followed within a sub-domain are not 272 represented by distinct network-wide SFPs; specific policies at the 273 ingress nodes of each sub-domain bind flows to sub-domain paths. 275 Packets are classified at the edge of the network to select the paths 276 by which sub-domains are to be traversed. At the ingress of each 277 sub-domain, packets are reclassified to paths directing them to the 278 required SFs of the sub-domain. At the egress of each sub-domain, 279 packets are returned to the top-level paths. Contrast this with an 280 approach requiring the top-level classifier to select paths to 281 specify all of the SFs in each sub-domain. 283 It should be assumed that some SFs require bidirectional symmetry of 284 paths (see more in Section 5). Therefore the classifiers at the top 285 level must be configured with policies ensuring outgoing packets take 286 the reverse path of incoming packets through sub-domains. 288 3.2. Lower Levels 290 Each of the sub-domains in Figure 1 is an SFC-enabled domain. 292 Figure 2 shows a sub-domain interfaced with a higher-level domain by 293 means of an Internal Boundary Node (IBN). An IBN acts as an SFC- 294 aware SF in the higher-level domain and as a classifier in the lower- 295 level domain. As such, data packets entering the sub-domain are 296 already SFC-encapsulated. Also, it is the purpose of the IBN to 297 apply classification rules and direct the packets to the selected 298 local SFPs terminating at an egress IBN. The egress IBN finally 299 restores packets to the original SFC shim and hands them off to SFFs. 301 Each sub-domain intersects a subset of the total paths that are 302 possible in the higher-level domain. An IBN is concerned with 303 higher-level paths, but only those traversing its sub-domain. 305 Each sub-domain is likely to have a control plane that can operate 306 independently of the top-level control plane, managing 307 classification, forwarding paths, etc. within the level of the sub- 308 domain, with the details being opaque to the upper-level control 309 elements. Section 4 provides more details about the behavior of an 310 IBN. 312 The sub-domain control plane configures the classification rules in 313 the IBN, where SFC encapsulation of the top-level domain is converted 314 to/from SFC encapsulation of the lower-level domain. The sub-domain 315 control plane also configures the forwarding rules in the SFFs of the 316 sub-domain. 318 +----+ +-----+ +----------------------+ +-----+ 319 | | | SFF | | IBN 1 (in DC 1) | | SFF | 320 | |SC#1| | | +----------------+ | | | 321 ->| |===============>| SFF |================> 322 | | +-----+ | +----------------+ | +-----+ 323 | CF | | | ^ | 324 | | | v | | 325 | | |+--------------------+| Top domain 326 | | ||CF, fwd/rev mapping || 327 | | * * * * *|| and "glue" || * * * * * 328 | | * |+--------------------+| * 329 +----+ * | | | | | | Sub * 330 * +-o-o--------------o-o-+ domain* 331 * SC#2 | |SC#1 ^ ^ #1 * 332 * +-----+ | | | * 333 * | V | | * 334 * | +---+ +------+ | | * 335 * | |SFF|->|SF#1.1|--+ | * 336 * | +---+ +------+ | * 337 * V | * 338 * +---+ +------+ +---+ +------+ * 339 * |SFF|->|SF#2.1|->|SFF|->|SF#2.2| * 340 * +---+ +------+ +---+ +------+ * 341 * * * * * * * * * * * * * * * * * * * * * * 342 Legend: 343 *** Sub-domain boundary 344 === top-level chain 345 --- low-level chain 347 Figure 2: Example of a sub-domain within a higher-level domain 349 If desired, the pattern can be applied recursively. For example, 350 SF#1.1 in Figure 2 could be a sub-domain of the sub-domain. 352 4. Internal Boundary Node (IBN) 354 As mentioned in the previous section, a network element termed 355 "Internal Boundary Node" (IBN) is responsible for bridging packets 356 between higher and lower layers of SFC-enabled domains. It behaves 357 as an SF to the higher level (Section 3.1), and looks like a 358 classifier and end-of-chain to the lower level (Section 3.2). 360 To achieve the benefits of hierarchy, the IBN should be applying 361 fine-grained traffic classification rules at the lower level than the 362 traffic passed to it. This means that the number of SFPs within the 363 lower level is greater than the number of SFPs arriving to the IBN. 365 The IBN is also the termination of lower-level SFPs. This is because 366 the packets exiting lower-level SF paths must be returned to the 367 higher-level SF paths and forwarded to the next hop in the higher- 368 level domain. 370 When different metadata schemes are used at different levels, the IBN 371 has further responsibilities: when packets enter the sub-domain, the 372 IBN translates upper-level metadata into lower-level metadata; and 373 when packets leave the sub-domain at the termination of lower-level 374 SFPs, the IBN translates lower-level metadata into upper-level 375 metadata. 377 Appropriately configuring IBNs is key to ensure the consistency of 378 the overall SFC operation within a given domain that enables hSFC. 379 Classification rules (or lack thereof) in the IBN classifier can of 380 course impact higher levels. 382 4.1. IBN Path Configuration 384 The lower-level domain may be provisioned with valid high-level paths 385 or may allow any high-level paths. 387 When packets enter the sub-domain, the Service Path Identifier (SPI) 388 and Service Index (SI) are re-marked according to the path selected 389 by the (sub-domain) classifier. 391 At the termination of an SFP in the sub-domain, packets can be 392 restored to an original upper-level SFP by implementing one of these 393 methods: 395 1. Saving SPI and SI in transport-layer flow state (Section 4.1.1). 397 2. Pushing SPI and SI into a metadata header (Section 4.1.2). 399 3. Using unique lower-level paths per upper-level path coordinates 400 (Section 4.1.3). 402 4. Nesting NSH headers, encapsulating the higher-level NSH headers 403 within the lower-level NSH headers (Section 4.1.4). 405 5. Saving upper-level by a flow identifier (ID) and placing an hSFC 406 flow ID into a metadata header (Section 4.1.5). 408 4.1.1. Flow-Stateful IBN 410 An IBN can be flow-aware, returning packets to the correct higher- 411 level SFP on the basis, for example, of the transport-layer 412 coordinates (typically, a 5-tuple) of packets exiting the lower-level 413 SFPs. 415 When packets are received by the IBN on a higher-level path, the 416 classifier parses encapsulated packets for IP and transport-layer 417 (TCP, UDP, etc.) coordinates. State is created, indexed by some or 418 all transport-coordinates ({source-IP, destination-IP, source-port, 419 destination-port and transport protocol}, typically). The state 420 contains at minimum the critical fields of the encapsulating SFC 421 header (SPI, SI, MD Type, flags); additional information carried in 422 the packet (metadata, TTL) may also be extracted and saved as state. 423 Note, that the some fields of a packet may be altered by an SF of the 424 sub-domain (e.g., source IP address). 426 Note that this state is only accessed by the classifier and 427 terminator functions of the sub-domain. Neither the SFFs nor SFs 428 have knowledge of this state; in fact they may be agnostic about 429 being in a sub-domain. 431 One approach is to ensure that packets are terminated at the same IBN 432 at the end of the chain that classified the packet at the start of 433 the chain. If the packet is returned to a different egress IBN, 434 state must be synchronized between the IBNs. 436 When a packet returns to the IBN at the end of a chain (which is the 437 SFP terminating node of the lower-level chain), the SFC header is 438 removed, the packet is parsed for flow-identifying information, and 439 state is retrieved from them. The state contains the information 440 required to forward the packet within the higher-level service chain. 442 State cannot be created by packets arriving from the lower-level 443 chain; when state cannot be found for such packets, they must be 444 dropped. 446 This stateful approach is limited to use with SFs that retain the 447 transport coordinates of the packet. This approach cannot be used 448 with SFs that modify those coordinates (e.g., NATs) or otherwise 449 create packets for new coordinates other than those received (e.g., 450 as an HTTP cache might do to retrieve content on behalf of the 451 original flow). In both cases, the fundamental problem is the 452 inability to forward packets when state cannot be found for the 453 packet transport-layer coordinates. 455 In the stateful approach, there are issues caused by having state, 456 such as how long the state should be maintained, as well as whether 457 the state needs to be replicated to other devices to create a highly 458 available network. 460 It is valid to consider the state to be disposable after failure, 461 since it can be re-created by each new packet arriving from the 462 higher-level domain. For example, if an IBN loses all flow state, 463 the state is re-created by an end-point retransmitting a TCP packet. 465 If an SFC domain handles multiple network regions (e.g., multiple 466 private networks), the coordinates may be augmented with additional 467 parameters, perhaps using some metadata to identify the network 468 region. 470 In this stateful approach, it is not necessary for the sub-domain's 471 control plane to modify paths when higher-level paths are changed. 472 The complexity of the higher-level domain does not cause complexity 473 in the lower-level domain. 475 Since it doesn't depend on NSH in the lower domain, this flow- 476 stateful approach can be applied to translation methods of converting 477 NSH to other forwarding techniques (refer to Section 7). 479 4.1.2. Encoding Upper-Level Paths in Metadata 481 An IBN can push the upper-level SPI and SI (or encoding thereof) into 482 a metadata field of the lower-level encapsulation (e.g., placing 483 upper-level path information into a metadata field of NSH). When 484 packets exit the lower-level path, the upper-level SPI and SI can be 485 restored from the metadata retrieved from the packet. 487 This approach requires the SFs in the path to be capable of 488 forwarding the metadata and appropriately attaching metadata to any 489 packets injected for a flow. 491 Using new metadata header may inflate packet size when variable- 492 length metadata (NSH MD Type 0x2) is used. 494 It is conceivable that the MD Type 0x1 Fixed-Length Context Header 495 field of NSH are not all relevant to the lower-level domain. In this 496 case, 32 bits of the Fixed Length Context Header could be repurposed 497 within the lower-level domain, and restored when leaving. 499 If flags or TTL (see Section 4.4) from the original header also need 500 to be saved, more metadata space will be consumed. 502 In this metadata approach, it is not necessary for the sub-domain's 503 control element to modify paths when higher-level paths are changed. 504 The complexity of the higher-level domain does not increase 505 complexity in the lower-level domain. 507 4.1.3. Using Unique Paths per Upper-Level Path 509 This approach assumes that paths within the sub-domain are 510 constrained so that a SPI (of the sub-domain) unambiguously indicates 511 the egress SPI and SI (of the upper domain). This allows the 512 original path information to be restored at sub-domain egress from a 513 look-up table using the sub-domain SPI. 515 Whenever the upper-level domain provisions a path via the lower-level 516 domain, the lower-level domain control plane must provision 517 corresponding paths to traverse the lower-level domain. 519 A down-side of this approach is that the number of paths in the 520 lower-level domain is multiplied by the number of paths in the 521 higher-level domain that traverse the lower-level domain. I.e., a 522 sub-path must be created for each combination of upper SPI/SI and 523 lower chain. The number of paths required for lower-level domains 524 will increase exponentially as hierarchy becomes deep. 526 A further down-side of this approach is that it requires upper and 527 lower levels to utilize the same metadata configuration. 529 Furthermore, this approach does not allow any information to be 530 stashed away in state or embedded in metadata. E.g., the TTL 531 modifications by the lower level cannot be hidden from the upper 532 level. 534 4.1.4. Nesting Upper-Level NSH within Lower-Level NSH 536 When packets arrive at an IBN in the top-level domain, the classifier 537 in the IBN determines the path for the lower-level domain and pushes 538 the new NSH header in front of the original NSH header. 540 As shown in Figure 3 the Lower-NSH header used to forward packets in 541 the lower-level domain precedes the Upper-NSH header from the top- 542 level domain. 544 +---------------------------------+ 545 | Outer-transport Encapsulation | 546 +---------------------------------+ 547 | Lower-NSH Header | 548 +---------------------------------+ 549 | Upper-NSH Header | 550 +---------------------------------+ 551 | Original Packet | 552 +---------------------------------+ 554 Figure 3: Encapsulation of NSH within NSH 556 The traffic with the above stack of two NSH headers is to be 557 forwarded according to the Lower-NSH header in the lower-level SFC 558 domain. The Upper-NSH header is preserved in the packets but not 559 used for forwarding. At the last SFF of the chain of the lower-level 560 domain (which resides in the IBN), the Lower-NSH header is removed 561 from the packet, and then the packet is forwarded by the IBN to an 562 SFF of the upper-level domain. The packet will be forwarded in the 563 top-level domain according to the Upper-NSH header. 565 With such encapsulation, Upper-NSH information is carried along the 566 extent of the lower-level chain without modification. 568 A benefit of this approach is that it does not require state in the 569 IBN or configuration to encode fields in meta-data. All header 570 fields, including flags and TTL are easily restored when the chains 571 of the sub-domain terminate. 573 However, the down-side is it does require SFC-aware SFs in the lower- 574 level domain to be able to parse multiple NSH layers. If an SFC- 575 aware SF injects packets, it must also be able to deal with adding 576 appropriate multiple layers of headers to injected packets. 578 By increasing packet overhead, nesting may lead to fragmentation or 579 decreased MTU in some networks. 581 4.1.5. Stateful/Metadata Hybrid 583 The basic idea of this approach is for the IBN to save upper domain 584 encapsulation information such that it can be retrieved by a unique 585 identifier, termed an "hSFC Flow ID". 587 The hSFC Flow ID is placed, for example, in the NSH Fixed-Length 588 Context Header of the packet in the lower domain, as shown in 589 Figure 4. Likewise, hSFC Flow ID may be encoded as a Variable-Length 590 Context Header when MD Type 0x2 is used. 592 When packets exit the lower domain, the IBN uses the hSFC Flow ID to 593 retrieve the appropriate NSH encapsulation for returning the packet 594 to the upper domain. The hSFC Flow ID Context Header is then 595 stripped by the IBN. 597 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Service Path Identifier | Service Index | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | hSFC Flow ID | 604 | Zero Padding or other fields | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 4: Storing hSFC Flow ID in lower-level NSH Fixed-Length 608 Context Header ([RFC8300], Section 2.4) 610 Advantages of this approach include: 612 o Does not require state based on 5-tuple, so it works with SFs that 613 change the IP addresses or port numbers of a packet such as NATs. 615 o Does not require all domains to have the same metadata scheme. 617 o Can be used to restore any upper-domain information, including 618 metadata, flags and TTL, not just service path. 620 o The lower domain only requires a single item of metadata 621 regardless of the number of items of metadata used in the upper 622 domain. 624 o The SFC-related functionality required by this approach in an SFC- 625 aware SF is to be able to preserve and apply metadata, which is a 626 requirement that was already present in [RFC8300]. 628 Disadvantages include those of other stateful approaches, including 629 state timeout and synchronization mentioned in Section 4.1.1. 631 There may be a large number of unique NSH encapsulations to be 632 stored, given that the hSFC Flow ID must represent all of the bits in 633 the upper-level encapsulation. This might consume a lot of memory or 634 create out-of-memory situations in which hSFC Flow IDs cannot be 635 created or old hSFC Flow IDs are discarded while still in use. 637 4.2. Gluing Levels Together 639 The SPI or metadata included in a packet received by the IBN may be 640 used as input to reclassification and path selection within a lower- 641 level domain. 643 In some cases the meanings of the various path IDs and metadata must 644 be coordinated between domains for the sake of proper end-to-end SFC 645 operation. 647 One approach is to use well-known identifier values in metadata, 648 maintained in a global registry. 650 Another approach is to use well-known labels for chain identifiers or 651 metadata, as an indirection to the actual identifiers. The actual 652 identifiers can be assigned by control-plane systems. For example, a 653 sub-domain classifier could have a policy, "if pathID = classA then 654 chain packet to path 1234"; the higher-level controller would be 655 expected to configure the concrete higher-level 'pathID' for 656 'classA'. 658 4.3. Decrementing Service Index 660 Because the IBN acts as an SFC-aware SF to the higher-level domain, 661 it must decrement the Service Index in the NSH headers of the higher- 662 level path. This operation should be undertaken when the packet is 663 first received by the IBN, before applying any of the strategies of 664 Section 4.1, immediately prior to classification. 666 4.4. Managing TTL 668 The NSH base header contains a TTL field [RFC8300]. There is a 669 choice: 671 a sub-domain may appear as a pure service function, which should 672 not decrement the TTL from the perspective of the higher-level 673 domain, or 675 all of the TTL changes within the sub-domain may be visible to the 676 higher-level domain. 678 Some readers may recognize this as a choice between "pipe" and 679 "uniform" models, respectively [RFC3443]. 681 The network operator should be given control of this behavior, 682 choosing whether to expose the lower-level topology to the higher 683 layer. An implementation may support per-packet policy, allowing 684 some users to perform a layer-transcending trace-route, for example. 686 The choice affects whether the methods of restoring the paths in 687 Section 4.1 restore a saved version of TTL or propagate it with the 688 packet. The method of Section 4.1.3 does not permit topology-hiding. 689 The other methods of Section 4.1.1, Section 4.1.2, Section 4.1.4, and 690 Section 4.1.5 have unique methods for restoring saved versions of 691 TTL. 693 5. Sub-domain Classifier 695 Within the sub-domain (referring to Figure 2), as the classifier 696 receives incoming packets, the high-level encapsulation is treated 697 according to one of the methods described in Section 4.1 to either 698 statefully store, encode, or nest header information. The classifier 699 then selects the path and metadata for the packet within the sub- 700 domain. 702 One of the goals of the hierarchical approach is to make it easy to 703 have transport-flow-aware service chaining with bidirectional paths. 704 For example, it is desired that for each TCP flow, the client-to- 705 server packets traverse the same SF instances as the server-to-client 706 packets, but in the opposite sequence. We call this bidirectional 707 symmetry. If bidirectional symmetry is required, it is the 708 responsibility of the control plane to be aware of symmetric paths 709 and configure the classifier to chain the traffic in a symmetric 710 manner. 712 Another goal of the hierarchical approach is to simplify the 713 mechanisms of scaling in and scaling out SFs. All of the 714 complexities of load-balancing among multiple SFs can be handled 715 within a sub-domain, under control of the classifier, allowing the 716 higher-level domain to be oblivious to the existence of multiple SF 717 instances. 719 Considering the requirements of bidirectional symmetry and load- 720 balancing, it is useful to have all packets entering a sub-domain to 721 be received by the same classifier or a coordinated cluster of 722 classifiers. There are both stateful and stateless approaches to 723 ensuring bidirectional symmetry. 725 6. Control Plane Elements 727 Although SFC control protocols have not yet been standardized (2018), 728 from the point of view of hierarchical service function chaining we 729 have these expectations: 731 o Each control-plane instance manages a single level of hierarchy of 732 a single domain. 734 o Each control plane is agnostic about other levels of hierarchy. 735 This aspect allows humans to reason about the system within a 736 single domain and allows control-plane algorithms to use only 737 domain-local inputs. Top-level control does not need visibility 738 to sub-domain policies, nor does sub-domain control need 739 visibility to higher-level policies. (Top-level control considers 740 a sub-domain as though it were an SF.) 742 o Sub-domain control planes are agnostic about control planes of 743 other sub-domains. This allows both humans and machines to 744 manipulate sub-domain policy without considering policies of other 745 domains. 747 Recall that the IBN acts as an SFC-aware SF in the higher-level 748 domain (receiving SF instructions from the higher-level control 749 plane) and as a classifier in the lower-level domain (receiving 750 classification rules from the sub-domain control plane). In this 751 view, it is the IBN that glues the layers together. 753 The above expectations are not intended to prohibit network-wide 754 control. A control hierarchy can be envisaged to distribute 755 information and instructions to multiple domains and sub-domains. 756 Control hierarchy is outside the scope of this document. 758 7. Extension for Adapting to NSH-Unaware Service Functions 760 The hierarchical approach can be used for dividing networks into NSH- 761 aware and NSH-unaware domains by converting NSH encapsulation to 762 other forwarding techniques (e.g., 5-tuple-based forwarding with 763 OpenFlow), as shown in Figure 5. 765 * * * * * * * * * * * * * * * * * * 766 * NSH-aware domain * 767 * +-------+ +-------+ * 768 * | SF#1 | | SF#5 | * 769 * +-o---o-+ +-o---o-+ * 770 * ^ | ^ | * 771 * +-|---|-+ +-|---|-+ * 772 * | |SFF| | | |SFF| | * 773 * +-|---|-+ +-|---|-+ * 774 * . | | . * 775 * +--+ / | | \ * 776 -->|CF|--' | | '-------> 777 * +--+ v | * 778 * +---o-----------o---+ * 779 .*.*.*.*.| / | IBN | \ |*.*.*. 780 . +-o--o---------o--o-+ . 781 . | | ^ ^ . 782 . | +-+ +-+ | . 783 . +---+ v | +---+ . 784 . | +-o-----o-+ | . 785 . | | SF#2 | | . 786 . | +---------+ | . 787 . +--+ +--+ . 788 . | +---------+ | . 789 . v | v | . 790 . +-o---o-+ +-o---o-+ . 791 . | SF#3 | | SF#4 | . 792 . +-------+ +-------+ . 793 . NSH-unaware domain . 794 . . . . . . . . . . . . . . . . . . 796 SF#1 and SF#5 are NSH-aware and SF#2, SF#3 and SF#4 are NSH-unaware. 797 In the NSH-unaware domain, packets are conveyed in a format supported 798 by SFs which are deployed there. 800 Figure 5: Dividing NSH-aware and NSH-unaware domains 802 7.1. Purpose 804 This approach is expected to facilitate service chaining in networks 805 in which NSH-aware and NSH-unaware SFs coexist. Some examples of 806 such situations are: 808 o In a period of transition from legacy SFs to NSH-aware SFs, and 810 o Supporting multi-tenancy. 812 7.2. Requirements for IBN 814 In this usage, an IBN classifier is required to have an NSH 815 conversion table for applying packets to appropriate lower-level 816 paths and returning packets to the correct higher-level paths. For 817 example, the following methods would be used for saving/restoring 818 upper-level path information: 820 o Saving SPI and SI in transport-layer flow state (refer to 821 Section 4.1.1) and 823 o Using unique lower-level paths per upper-level NSH coordinates 824 (refer to Section 4.1.3). 826 Especially, the use of unique paths approach would be good for 827 translating NSH to a different forwarding technique in the lower 828 level. A single path in the upper level may be branched to multiple 829 paths in the lower level such that any lower-level path is only used 830 by one upper-level path. This allows unambiguous restoration to the 831 upper-level path. 833 In addition, an IBN might be required to convert metadata contained 834 in NSH to the format appropriate to the packet in the lower-level 835 path. For example, some legacy SFs identify subscriber based on 836 information of network topology, such as VID (VLAN ID), and IBN would 837 be required to create VLAN to packets from metadata if subscriber 838 identifier is conveyed as metadata in higher-level domains. 840 Other fundamental functions required as IBN (e.g., maintaining 841 metadata of upper level or decrementing Service Index) are the same 842 as in normal usage. 844 It is useful to permit metadata to be transferred between levels of a 845 hierarchy. Metadata from a higher level may be useful within a sub- 846 domain and a sub-domain may augment metadata for consumption in an 847 upper domain. However, allowing uncontrolled metadata between 848 domains may lead to forwarding failures. 850 In order to prevent SFs of low-level SFC-enabled domains from 851 supplying (illegitimate) metadata, IBNs may be instructed to only 852 permit specific metadata types to exit the sub-domain. Such 853 control over the metadata in the upper level is the responsibility 854 of the upper-level control plane. 856 To limit unintentional metadata reaching SFs of low-level SFC- 857 enabled sub-domains, IBNs may be instructed to only permit 858 specific metadata types into the sub-domain. Such control of 859 metadata in the low-level domain is the responsibility of the 860 lower-level control plane. 862 8. IANA Considerations 864 This memo includes no request to IANA. 866 9. Security Considerations 868 Hierarchical service function chaining makes use of service chaining 869 architecture, and hence inherits the security considerations 870 described in the architecture document [RFC7665]. 872 Furthermore, hierarchical service function chaining inherits security 873 considerations of the data-plane protocols (e.g., NSH) and control- 874 plane protocols used to realize the solution. 876 This document describes systems that may be managed by distinct 877 teams, which all belong to the same administrative entity. Sub- 878 domains must have consistent configurations in order to properly 879 forward traffic. Any protocol designed to distribute the 880 configurations must be secure from tampering. Means to prevent 881 attacks from within a network must be enforced. For example, 882 continuously monitoring the network may allow detecting such 883 misbehaviors. hSFC adheres to the same security considerations of 884 [RFC8300]. Those considerations must be taken into account. 886 The options in Section 4.1.2 and Section 4.1.5 assume the use of a 887 dedicated context header to store information to bind a flow to its 888 high-level SFP. Such context header is stripped by the IBN of a sub- 889 domain before exiting a sub-domain. Additional guards to prevent 890 leaking unwanted context information when entering/exiting a sub- 891 domain are discussed in Section 7.2. 893 All of the systems and protocols must be secure from modification by 894 untrusted agents. 896 9.1. Control Plane 898 Security considerations related to the control plane are discussed in 899 the corresponding control specification documents (e.g., 900 [I-D.ietf-bess-nsh-bgp-control-plane], 901 [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]). 903 9.2. Infinite Forwarding Loops 905 Distributing policies among multiple domains may lead to forwarding 906 loops. NSH supports the ability to detect loops (Section 4.3 and 907 Section 4.4), but means to ensure the consistency of the policies 908 should be enabled at all levels of a domain. Within the context of 909 hSFC, it is the responsibility of the Control Elements at all levels 910 to prevent such (unwanted) loops. 912 10. Acknowledgements 914 The concept of Hierarchical Service Path Domains was introduced in 915 [I-D.homma-sfc-forwarding-methods-analysis] as a means to improve 916 scalability of service chaining in large networks. 918 The concept of nesting NSH headers within lower-level NSH was 919 contributed by Ting Ao. The concept originally appeared in 920 [I-D.ao-sfc-for-dc-interconnect] as a means of creating hierarchical 921 SFC in a data center. 923 We thank Dapeng Liu for contributing the data-center examples in the 924 appendix. 926 The Stateful/Metadata Hybrid section was contributed by Victor Wu. 928 The authors would also like to thank the following individuals for 929 providing valuable feedback: 931 Ron Parker 933 Christian Jacquenet 935 Jie Cao 937 Kyle Larose 939 Thanks to Ines Robles, Sean Turner, Vijay Gurbani, Ben Campbell, and 940 Benjamin Kaduk for their review. 942 11. References 944 11.1. Normative References 946 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 947 Chaining (SFC) Architecture", RFC 7665, 948 DOI 10.17487/RFC7665, October 2015, 949 . 951 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 952 "Network Service Header (NSH)", RFC 8300, 953 DOI 10.17487/RFC8300, January 2018, 954 . 956 11.2. Informative References 958 [I-D.ao-sfc-for-dc-interconnect] 959 Ao, T. and W. Bo, "Hierarchical SFC for DC 960 Interconnection", draft-ao-sfc-for-dc-interconnect-01 961 (work in progress), October 2015. 963 [I-D.homma-sfc-forwarding-methods-analysis] 964 Homma, S., Naito, K., Lopez, D., Stiemerling, M., Dolson, 965 D., Gorbunov, A., Leymann, N., Bottorff, P., and d. 966 don.fedyk@hpe.com, "Analysis on Forwarding Methods for 967 Service Chaining", draft-homma-sfc-forwarding-methods- 968 analysis-05 (work in progress), January 2016. 970 [I-D.ietf-bess-nsh-bgp-control-plane] 971 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 972 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 973 nsh-bgp-control-plane-03 (work in progress), March 2018. 975 [I-D.ietf-sfc-dc-use-cases] 976 Kumar, S., Tufail, M., Majee, S., Captari, C., and S. 977 Homma, "Service Function Chaining Use Cases In Data 978 Centers", draft-ietf-sfc-dc-use-cases-06 (work in 979 progress), February 2017. 981 [I-D.maglione-sfc-nsh-radius] 982 Maglione, R., Trueba, G., and C. Pignataro, "RADIUS 983 Attributes for NSH", draft-maglione-sfc-nsh-radius-01 984 (work in progress), October 2016. 986 [I-D.wu-pce-traffic-steering-sfc] 987 Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. 988 Tantsura, "PCEP Extensions for Service Function Chaining 989 (SFC)", draft-wu-pce-traffic-steering-sfc-12 (work in 990 progress), June 2017. 992 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 993 in Multi-Protocol Label Switching (MPLS) Networks", 994 RFC 3443, DOI 10.17487/RFC3443, January 2003, 995 . 997 Appendix A. Examples of Hierarchical Service Function Chaining 999 The advantage of hierarchical service function chaining compared with 1000 normal or flat service function chaining is that it can reduce the 1001 management complexity significantly. This section discusses examples 1002 that show those advantages. 1004 A.1. Reducing the Number of Service Function Paths 1006 In this case, hierarchical service function chaining is used to 1007 simplify service function chaining management by reducing the number 1008 of SFPs. 1010 As shown in Figure 6, there are two domains, each with different 1011 concerns: a Security Domain that selects SFs based on network 1012 conditions and an Optimization Domain that selects SFs based on 1013 traffic protocol. 1015 In this example there are five security functions deployed in the 1016 Security Domain. The Security Domain operator wants to enforce the 1017 five different security policies, and the Optimization Domain 1018 operator wants to apply different optimizations (either cache or 1019 video optimization) to each of these two types of traffic. If we use 1020 flat SFC (normal branching), 10 SFPs are needed in each domain. In 1021 contrast, if we use hierarchical SFC, only 5 SFPs in Security Domain 1022 and 2 SFPs in Optimization Domain will be required, as shown in 1023 Figure 7. 1025 In the flat model, the number of SFPs is the product of the number of 1026 SFs in all of the domains. In the hSFC model, the number of SFPs is 1027 the sum of the number of SFs. For example, adding a "bypass" path in 1028 the Optimization Domain would cause the flat model to require 15 1029 paths (5 more), but cause the hSFC model to require one more path in 1030 the Optimization Domain. 1032 . . . . . . . . . . . . . . . . . . . . . . . . . 1033 . Security Domain . . Optimization Domain . 1034 . . . . 1035 . +-1---[ ]----------------->[Cache ]-------> 1036 . | [ WAF ] . . . 1037 . +-2-->[ ]----------------->[Video Opt.]----> 1038 . | . . . 1039 . +-3---[Anti ]----------------->[Cache ]-------> 1040 . | [Virus] . . . 1041 . +-4-->[ ]----------------->[Video Opt.]----> 1042 . | . . . 1043 . +-5-->[ ]----------------->[Cache ]-------> 1044 [DPI]--->[CF]---| [ IPS ] . . . 1045 . +-6-->[ ]----------------->[Video Opt.]----> 1046 . | . . . 1047 . +-7-->[ ]----------------->[Cache ]-------> 1048 . | [ IDS ] . . . 1049 . +-8-->[ ]----------------->[Video Opt.]----> 1050 . | . . . 1051 . +-9-->[Traffic]--------------->[Cache ]-------> 1052 . | [Monitor] . . . 1053 . +-10->[ ]--------------->[Video Opt.]----> 1054 . . . . . . . . . . . . . . . . . . . . . . . . . 1056 Legend: 1057 IDS: Intrusion Detection System 1058 IPS: Intrusion Prevention System 1059 WAF: Web Application Firewall 1060 DPI: Deep Packet Inspection 1062 The classifier must select paths that determine the combination of 1063 Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt, 1064 3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 1065 6:IPS+VideoOpt, 7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache, 1066 10:TrafficMonitor+VideoOpt 1068 Figure 6: Flat SFC (normal branching) 1070 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071 . Security Domain . . Optimization Domain . 1072 . . . . 1073 [CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]----> 1074 . | ^ . . | ^ . 1075 . +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ . 1076 . | | . . | | . 1077 . +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ . 1078 . | | . . . 1079 . +----->[ IPS ]-----+ . . . . . . . . . . . . . . . . 1080 . | | . 1081 . +----->[ IDS ]-----+ . 1082 . | | . 1083 . +-->[ Traffic ]----+ . 1084 . [ Monitor ] . 1085 . . . . . . . . . . . . . . . 1087 Figure 7: Simplified path management with Hierarchical SFC 1089 A.2. Managing a Distributed Data-Center Network 1091 Hierarchical service function chaining can be used to simplify inter- 1092 data-center SFC management. In the example of Figure 8, shown below, 1093 there is a central data center (Central DC) and multiple local data 1094 centers (Local DC#1, #2, #3) that are deployed in a geographically 1095 distributed manner. All of the data centers are under a single 1096 administrative domain. 1098 The central DC may have some service functions that the local DC 1099 needs, such that the local DC needs to chain traffic via the central 1100 DC. This could be because: 1102 o Some SFs are deployed as dedicated hardware appliances, and there 1103 is a desire to lower the cost (both CAPEX and OPEX) of deploying 1104 such SFs in all data centers. 1106 o Some SFs are being trialed, introduced or otherwise handle a 1107 relatively small amount of traffic. It may be cheaper to manage 1108 these SFs in a single central data center and steer packets to the 1109 central data center than to manage these SFs in all data centers. 1111 +-----------+ 1112 |Central DC | 1113 +-----------+ 1114 ^ ^ ^ 1115 | | | 1116 .---|--|---|----. 1117 / / | | \ 1118 / / | \ \ 1119 +-----+ / / | \ \ +-----+ 1120 |Local| | / | \ | |Local| 1121 |DC#1 |--|--. | .----|----|DC#3 | 1122 +-----+ | | | +-----+ 1123 \ | / 1124 \ | / 1125 \ | / 1126 '----------------' 1127 | 1128 +-----+ 1129 |Local| 1130 |DC#2 | 1131 +-----+ 1133 Figure 8: Simplify inter-DC SFC management 1135 For large data center operators, one local DC may have tens of 1136 thousands of servers and hundreds of thousands of virtual machines. 1137 SFC can be used to manage user traffic. For example, SFC can be used 1138 to classify user traffic based on service type, DDoS state, etc. 1140 In such large scale data center, using flat SFC is very complex, 1141 requiring a super-controller to configure all data centers. For 1142 example, any changes to SFs or SFPs in the central DC (e.g., 1143 deploying a new SF) would require updates to all of the SFPs in the 1144 local DCs accordingly. Furthermore, requirements for symmetric paths 1145 add additional complexity when flat SFC is used in this scenario. 1147 Conversely, if using hierarchical SFC, each data center can be 1148 managed independently to significantly reduce management complexity. 1149 SFPs between data centers can represent abstract notions without 1150 regard to details within data centers. Independent controllers can 1151 be used for the top level (getting packets to pass the correct data 1152 centers) and local levels (getting packets to specific SF instances). 1154 Authors' Addresses 1156 David Dolson 1157 Sandvine 1158 Waterloo, ON 1159 Canada 1161 Email: ddolson@acm.org 1163 Shunsuke Homma 1164 NTT, Corp. 1165 3-9-11, Midori-cho 1166 Musashino-shi, Tokyo 180-8585 1167 Japan 1169 Email: homma.shunsuke@lab.ntt.co.jp 1171 Diego R. Lopez 1172 Telefonica I+D 1173 Don Ramon de la Cruz, 82 1174 Madrid 28006 1175 Spain 1177 Phone: +34 913 129 041 1178 Email: diego.r.lopez@telefonica.com 1180 Mohamed Boucadair 1181 Orange 1182 Rennes 35000 1183 France 1185 Email: mohamed.boucadair@orange.com