idnits 2.17.1 draft-xie-alto-sdn-extension-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 9, 2013) is 4119 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Xie 3 Internet-Draft Huawei & USTC 4 Intended status: Informational T. Tsou 5 Expires: July 13, 2013 Huawei (USA) 6 D. Lopez 7 Telefonica I+D 8 H. Yin 9 Huawei (USA) 10 January 9, 2013 12 Use Cases for ALTO with Software Defined Networks 13 draft-xie-alto-sdn-extension-use-cases-01 15 Abstract 17 The introduction of SDN fundamentally changes the way that the 18 application layer traffic optimization (ALTO) works. This draft 19 describes two architectures, the Vertical Architecture and the 20 Horizontal Architecture, allowing coherent coexistence of ALTO and 21 software defined network (SDN). Unique requirements for design and 22 operations are identified and summarized, suggesting that the 23 Vertical Architecture allows better division, management, 24 flexibility, privacy control and long-term evolution of the network. 25 We also define the main interactions and information flows, and 26 present a set of use cases to illustrate how we extend ALTO to 27 support SDN, in the Vertical Architecture. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 13, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. An Overview of Software Defined Network . . . . . . . . . . . 5 66 2.1. Software Defined Network and Applications . . . . . . . . 5 67 2.2. Division of Network . . . . . . . . . . . . . . . . . . . 6 68 2.3. SDN Domain . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. Architectures for Co-existing SDN and ALTO . . . . . . . . . . 9 70 3.1. ALTO Changes Due to SDN . . . . . . . . . . . . . . . . . 9 71 3.1.1. ALTO Scopes . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.2. ALTO clients . . . . . . . . . . . . . . . . . . . . . 10 73 3.2. The Vertical and Horizontal Architectures . . . . . . . . 11 74 3.3. Interactions between SDN and ALTO . . . . . . . . . . . . 13 75 3.3.1. Downward Interaction . . . . . . . . . . . . . . . . . 13 76 3.3.2. Upward Interaction . . . . . . . . . . . . . . . . . . 14 77 3.4. Interactions between Legacy ALTO Clients and ALTO 78 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4. Information Flows . . . . . . . . . . . . . . . . . . . . . . 15 80 4.1. Information Flow of SDN Controller . . . . . . . . . . . . 15 81 4.2. Information Flow of Applications, SDN and ALTO . . . . . . 16 82 4.2.1. SDN-aware Applications . . . . . . . . . . . . . . . . 16 83 4.2.2. SDN-unaware Applications . . . . . . . . . . . . . . . 17 84 4.2.3. Legacy Applications . . . . . . . . . . . . . . . . . 17 85 4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 5. Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 5.1. Service Negotiation . . . . . . . . . . . . . . . . . . . 18 88 5.2. Status Report (Upward Information Flow) . . . . . . . . . 18 89 5.3. ALTO Message Dissemination (Downward Information Flow . . 19 90 6. Use Case for Co-existing SDN and ALTO . . . . . . . . . . . . 19 91 6.1. Use Case for Upward Flow . . . . . . . . . . . . . . . . . 19 92 6.1.1. Unrestrictive Information Exporting . . . . . . . . . 20 93 6.1.2. Restrictive Information Exporting . . . . . . . . . . 20 94 6.1.3. Information Aggregation . . . . . . . . . . . . . . . 21 95 6.2. Use Case for Downward Flow . . . . . . . . . . . . . . . . 21 96 6.2.1. SDN-Aware QoS Metrics . . . . . . . . . . . . . . . . 22 97 6.2.2. Content Delivery Networks (CDN) . . . . . . . . . . . 23 98 6.2.3. Information-Centric Content Delivery Networks 99 (IC-CDN) . . . . . . . . . . . . . . . . . . . . . . . 26 100 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 27 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 105 12. Informative References . . . . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 108 1. Introduction 110 The concept of Software Defined Network (SDN) has emerged and become 111 one of the fundamental, promising networking primitives that allow 112 flexibility of control, separation of functional planes and 113 continuous evolution in networks. 115 One of the key features of SDN is the full separation of two 116 functional planes: the control plane and the data-forwarding plane. 117 SDN requires that networking devices support such separation, 118 implementing the data plane mechanisms, while the control plane is 119 provided by an external entity called the "controller". The other 120 key feature of SDN is the new interaction process between the 121 separated control plane and data-forwarding plane. This interaction 122 is mandated to be performed specific open protocols, allowing for a 123 free combination of networking devices and controllers, as well as 124 supporting the controller to take decisions on information additional 125 to the networking device status. 127 There could be numerous benefits as a result of the above features in 128 SDN, e.g., just to name a few, network virtualization, better 129 flexible control and utilization of the network, networks customized 130 for scenarios with specific requirements. For instance, some SDN 131 technologies have started to find their ways into Data Center 132 Networks (DCNs). Furthermore, in order to allow efficient and 133 flexible implementation of the above separation and interactions, a 134 significant portion of the SDN system could typically be implemented 135 in software, as opposed to the hardware-based implementation adopted 136 by most of today's networking devices. 138 Due to the great potentials of SDN and the unique requirements of 139 DCNs, Data Centers are likely to become a first place where SDN could 140 be deployed. We envision that SDN could be gradually adopted by 141 enterprise networks and then by carrier networks due to its unique, 142 attractive features. When deploying SDN in large-scale distributed 143 networks, we expect to see a collection of deployments limited in 144 relatively small segments of a bigger network. In other words, it is 145 likely that the operator of a large-scale enterprise / carrier 146 network prefers to divide the whole networks into multiple smaller 147 segments and put each of there segments in an SDN domain. These 148 smaller network segments (therefore their corresponding SDN domains) 149 are connected and jointly form the larger whole network. Such a 150 divide-and-conquer methodology not only allows gradual deployment and 151 continuous evolution, but also enables flexible provisioning of the 152 network. 154 With the deployment of SDN, application layer traffic optimization 155 (ALTO) faces new challenges including, but not limited to, privacy 156 preservation, granularity of information collection and exchange, 157 join optimization, etc. We shall elaborate these challenges and 158 their impacts on the design of ALTO extensions for SDN in this draft. 160 1.1. Terminology 162 While the definition of software defined networks is still "nebulous" 163 to some extent, we refer to as SDN the networks that implement the 164 separation of the control and data-forwarding planes and software 165 defined interactions between these two separated planes; such 166 interactions are characterized by open interfaces which allow 167 programming the network equipment's forwarding plane by external 168 agents, e.g., SDN controllers. However, how the two separated planes 169 interact is not a focus of this draft; instead, the ALTO extension 170 for SDN recommended in this draft is independent of how such 171 interactions would be. 173 An SDN domain is a portion of a network infrastructure, consisting of 174 numerous connected networking devices that are SDN capable (i.e., SDN 175 capable devices implement the control/forwarding plane separation and 176 the open interfaces allowing external agents to program the devices) 177 and a domain controller which implements the SDN control plane 178 functionalities for these devices. An SDN domain can be as small as 179 a sub-network of a dozen devices or as large as a medium/large data 180 center network. 182 A software defined network is a network that has one or multiple SDN 183 domains. Due to an SDN domain typically has limited coverage, an SDN 184 may be comprised of networking devices under control of some SDN 185 domains (i.e., SDN managed devices) and devices under no control of 186 any SDN domain (i.e., normal devices). Note that such normal devices 187 could still be SDN capable and their control/forwarding planes are 188 managed as in normal networks today. This implies that a network 189 with both normal devices and SDN capable devices (managed by SDN 190 domains) needs both normal and SDN capable control/forwarding plane 191 management. 193 2. An Overview of Software Defined Network 195 This section provides a high level and conceptual overview of 196 software defined network in order to help illustrate its unique 197 requirements for ALTO. 199 2.1. Software Defined Network and Applications 201 We refer to as an "SDN" a carrier's or an enterprise's network which 202 deploys or implements software defined networking technologies. 204 Since SDN separates the control plane and data-forwarding plane, we 205 refer to the entity that implements the control-plane functionalities 206 as the "SDN controller". 208 In order for a network to be classified as an SDN, it is unnecessary 209 that all networking devices have to be SDN capable. Some of devices 210 in a network may be managed by an SDN controller while the remaining 211 ones may not; such a network is still qualified as an SDN. 213 There are two types of applications in software defined networks: 215 o SDN-aware applications: applications prefer direct communication 216 with SDN controllers, which implies that there must exist 217 mechanism(s) for SDN-aware applications to locate and 218 communication with SDN controllers. If the application prefers 219 indirect communication with SDN controllers, then it follows the 220 case of SDN-unaware applications (see below). Applications that 221 are SDN-aware may be able to better utilize the SDN capable 222 network due to its knowledge about SDN and its capability of 223 proactive, direct interaction with SDN. 225 o SDN-unaware applications: applications indirectly communicate with 226 SDN controllers by sending application protocol datagrams with 227 specific formats, via which the application can specify its 228 requirements for the network resources. Legacy applications 229 (applications for the current IP networks) are largely SDN- 230 unaware, and such applications may not be able to utilize the SDN 231 capable networks as efficiently as SDN-aware applications. 233 Whether and how applications should/can be SDN-aware or SDN-unaware 234 is beyond the scope of this draft. However, the framework we 235 described in this draft is applicable to both SDN-aware and SDN- 236 unaware cases. 238 2.2. Division of Network 240 A network operator may decide to divide the network into multiple 241 sub-networks, some of which are SDN capable and thus are managed by 242 corresponding SDN controllers. 244 There could be numerous reasons for such division of network. Below 245 we summarize a few of them: 247 o Scalability. 249 The number of devices an SDN controller can feasibly manage is 250 likely to be limited. Therefore, in order to manage a many 251 devices that cannot be put under control of a single SDN 252 controller, multiple controllers have to be deployed. Hence, the 253 network is divided into multiple sub-networks; if a sub-network 254 has SDN capable devices, it should be managed by an SDN 255 controller. 257 o Manageability. 259 At the network level, in order to reduce the complexity of 260 management, a carrier may decide to divide the network into 261 multiple sub-networks and put some of them under control of some 262 SDN controllers (provided that the devices in such sub-networks 263 are SDN capable); each of the sub-networks can be managed 264 independently to some extent, thus reducing the overall complexity 265 of managing the whole network. Even at the sub-network level, a 266 carrier may still decide to further divide the sub-network in 267 order to further reduce complexity of management. For instance, a 268 sub-network under control of an SDN controller may span across a 269 large geographical area or cover a large number of devices; in 270 this case it is reasonable for the carrier to further divide it 271 into two or even more sub-networks, such that the complexity of 272 managing each individual sub-network plus the overall complexity 273 of managing all divided sub-networks are reduced. 275 o Privacy. 277 When a carrier divides its network into multiple sub-networks and 278 put them under control of SDN, the carrier may choose to implement 279 difference privacy policies in different sub-networks. For 280 example, a carrier may dedicate a part of its infrastructure to 281 some certain customers, dividing the whole network and dedicate 282 some of the sub-networks is a convenient and scalable way to 283 manage the network resources for these customers. Another example 284 is that a sub-network in a carrier's network may be dedicated to 285 some certain customers and such information as network topology 286 may not be disclosed to any external entity. 288 o Deployment 290 The deployment of network infrastructures, especially new network 291 infrastructure and technologies, has to be incremental. This 292 means that at any time, a carrier's network may consist of a 293 portion of legacy and a portion of non-legacy infrastructure. 294 When deploying new infrastructure or technologies, it is highly 295 preferable to limit the scope of new deployment and do it in an 296 incremental way. In such cases, it is very favorable to divide 297 the network into multiple individually manageable sub-networks and 298 choose some of them to deploy the new infrastructure / 299 technologies. 301 2.3. SDN Domain 303 With the introduction of SDN, we believe that it is inevitable for 304 carriers to divide their networks for many reasons as illustrated in 305 the preceding subsection. Therefore, we believe that to better suit 306 this need, it should be recommended that SDN domains are defined and 307 applied in division of the networks. 309 An SDN domain is a sub-network, resulted from division of a network 310 which is determined by the network operator. Each domain typically 311 consists of numerous connected networking devices, each of which is 312 SDN capable. Each domain also has a domain controller which 313 implements SDN control plane functionalities for the devices in this 314 domain. Another important task such a domain controller is 315 responsible for includes fine-grain network information collection 316 (for devices in this domain). The collected information is necessary 317 for the controller to make data-forwarding plane decisions. Note 318 that such a domain controller may be integrated as a part of a so- 319 called "network operating system" (NOS). An example of such a 320 network operating system is illustrated in [1]. 322 Any networking device, if under the control of certain SDN domains, 323 should belong to only one SDN domain and should be under the control 324 of the SDN domain's controller. In other words, the intersection of 325 two domains is always empty. 327 Furthermore, SDN domains are connected (via the connectivity among 328 underlying devices provided by the underlying network; such devices 329 belong to different SDN domains) to form the whole network. For a 330 large-scale distributed networks owned by a national/multi-national 331 carrier or enterprise, it is natural to adopt the "divide-and- 332 conquer" strategy and divide the whole network into multiple SDN 333 domains. Even for small or medium networks, multiple SDN domains may 334 be necessary in order to virtualize the network resources (e.g., set 335 up multiple SDN domains for a large data center network to 336 instantiate multiple virtual data centers for many content 337 providers). Note that how multiple SDN domains inside a carrier's/ 338 enterprise' network work together is beyond the scope of this draft 339 and is handled by other working groups. 341 Inside each SDN domain, its controller may define domain-specific 342 policies on information importing from devices, aggregating, and 343 exporting to external entities. Such policies may not be made 344 public; therefore, other domain controllers or ALTO may not know the 345 existence of such policies for any given SDN domain. 347 The natural network division implemented by SDN domains impose 348 significantly new and challenging requirement for shaping the 349 interactions between SDN and ALTO, and therefore designing the 350 protocols to enable such interactions. 352 3. Architectures for Co-existing SDN and ALTO 354 In this section, we first compare the ALTO scopes without and with 355 the existence of SDN, and then describe two architectures for co- 356 existing SDN and ALTO. 358 3.1. ALTO Changes Due to SDN 360 SDN incurs significant changes to ALTO scopes and clients. We 361 describe the major differences below. 363 3.1.1. ALTO Scopes 365 The existence of SDN differentiates two scopes of ALTO, namely, 367 o The current scope of ALTO without SDN (referred to as the SDN- 368 unfriendly Scope). 370 In the current scope of ALTO, there exist interactions between 371 ALTO clients and ALTO servers. Such interactions are one-way 372 interaction, meaning that ALTO information flows in one direction, 373 i.e., from the server to the clients. More specifically, ALTO 374 clients submit ALTO requests to (and subsequently receive ALTO 375 responses from) an ALTO server. Additionally, ALTO clients in the 376 current scope of ALTO are network applications who would like to 377 consume the network resources. ALTO clients are typically managed 378 by network applications rather than by network carriers. However, 379 ALTO servers are owned and managed by network carriers. 381 o The new scope of ALTO with coherent coexistence of SDN (referred 382 to as the SDN-friendly Scope). 384 With the introduction of SDN, the interactions between ALTO 385 clients and ALTO servers become more complex. A more careful 386 examination as well as important ALTO extensions are necessary to 387 make ALTO work in the context of SDN. It is important to note 388 that if the network does not implement network division (i.e., 389 does not implement SDN domains), the interactions are "compressed" 390 into a compact set of interactions; specifically, both the SDN 391 controller (recall that there exists only one single controller 392 for the whole network) and the ALTO server could be integrated in 393 many equally efficient fashions. For instance, ALTO server could 394 be put underneath the controller, i.e., ALTO server provides 395 information to the controller, as suggested by [2]. However, if 396 the network implements division via SDN domains (i.e., there 397 exists multiple SDN domains), we essentially "unfold" the 398 compressed interaction space and need more complex structures that 399 allow efficient design and implementation, due to the facts that 400 we listed in the preceding sections. Furthermore, the design 401 originally for the compressed space could be instantiated for the 402 unfolded space but could not be as efficient. 404 3.1.2. ALTO clients 406 We next focus on the SDN-friendly Scope and highlight the complex 407 structures and the important differences. 409 With the existence of SDN and SDN controllers, ALTO clients could be 410 not only legacy network applications (or proxies for these network 411 applications), but also SDN controllers. 413 In SDN, SDN controllers have similar needs as the legacy ALTO clients 414 which communicate with ALTO servers, because ALTO clients would like 415 to better understand the network and thus improve the application 416 performance. 418 There are multiple reasons for this similarity. The most important 419 reason is that each SDN controller is only responsible for managing a 420 sub-network in a carrier's network; therefore, it may not understand 421 well other sub-networks in the same carrier network. However, in 422 order to allocate the network resources to satisfy application 423 requirements (note that the end points of such applications may well 424 span across multiple SDN domains), an SDN controller may have to 425 involve other SDN controllers because the network paths needed may 426 traverse multiple SDN domains. Thus, obtaining global information 427 from the ALTO server is a significantly more efficient and more 428 preferable than otherwise from SDN interconnection protocols; plus, 429 such protocols do not exist yet today. 431 Although SDN controllers have similar needs as legacy ALTO 432 applications do, the fundamental properties of SDN controllers as 433 ALTO clients are significantly different. One of the differences is 434 the ownership and management, as most SDN controllers require 435 additional (and more likely complex) access privileges. 436 Specifically, SDN controllers are typically owned by the network 437 carriers who also own their ALTO servers, while legacy ALTO clients 438 are network applications typically not owned by network carriers 439 (there are cases where owned collaboratively amongst operators). 441 In terms of management, the entity managing SDN controller is the 442 same as that managing the ALTO server. We emphasize that when an SDN 443 domain is dedicated to some customers of a network carrier, the use 444 of the SDN domain is owned by these customers and so is the 445 management. In this case, the SDN controllers as ALTO clients are 446 slightly more like legacy ALTO clients. However, there still exist 447 fundamental differences which we will illustrate later. 449 3.2. The Vertical and Horizontal Architectures 451 We now introduce two architectures that allow coherent co-existence 452 of SDN and ALTO in this section: 454 o the Vertical Architecture (or the V Architecture for short) allows 455 better division, management, flexibility, privacy control and 456 long-term evolution of the network. 458 The Vertical Architecture is illustrated in the following figure. 459 The network has one or multiple SDN domains and an ALTO server. 460 The interactions between the SDN controllers and the SDN capable 461 devices fall in the scope of SDN and therefore is out of the scope 462 of this draft; instead, the interactions between the SDN domains 463 (more specifically, SDN controllers) and the ALTO server is what 464 this draft focuses on. 466 .----------------------------------------------. 467 | ALTO Server | 468 `----------------------------------------------' 469 ^ | 470 .-------------|------------|-------------------. 471 | | V | 472 | .-------------------------------. | 473 | | SDN Controller | | 474 | `-------------------------------' | 475 | | | 476 | | | 477 | .-------------------------------. | 478 | | SDN Capable Devices | | 479 | `-------------------------------' | 480 | | 481 | An SDN Domain | 482 `----------------------------------------------' 484 The Vertical Architecture is a hierarchical architecture 485 consisting of three tiers. In the first tier, the only entity is 486 the ALTO server. In the second tier, the only entities are the 487 SDN domain controllers. In the third tier, the only entities are 488 SDN domains (each domain consists of numerous networking devices). 490 In this architecture, all entities are owned by the same carrier. 491 However, some of the SDN domains (and the networking devices in 492 them) may be dedicated to certain customers of the carrier (the 493 carrier gives the customers privileges access). This is subject 494 to a collaboration agreement between them. 496 o the Horizontal Architecture (or the H Architecture for short) 497 simplifies the implementation of ALTO extensions for SDN. The 498 Horizontal Architecture is illustrated in the following figure. 499 Each SDN controller is integrated with an ALTO server. The 500 interactions between the SDN controllers and the ALTO server is 501 represented by the horizontal line in the figure. An example of 502 this architecture can be found in [2]. 504 .---------------------------------------------------------------------. 505 | .--------------------------. .--------------------------. | 506 | | SDN Controller |<----| ALTO Server | | 507 | `--------------------------' `--------------------------' | 508 `-----------------|---------------------------------------------------' 509 | 510 .-------------------------------. 511 | SDN Capable Devices | 512 `-------------------------------' 514 In the Horizontal Architecture, the SDN controller can act as an 515 ALTO client and query the network information of the networking 516 devices from the ALTO server. However, such network information 517 may not meet the SDN controllers' granularity requirement (i.e., 518 the information provided by the ALTO server may not be as fine- 519 grained as needed by the SDN controllers). In addition, there may 520 exist redundant information collection, as SDN controllers are 521 inevitably collecting various fine-grain information from the 522 devices they manage; the information collection by the ALTO 523 server, either mannully or automatically, is likely to be 524 redundant. Furthermore, when the carrier decides to divide its 525 network into multiple SDN domains, it can be difficult, if not 526 impossible at all, for the Horizontal Architecture to adapt to the 527 network division. 529 The ALTO server covers a carrier's network as a whole; however, if 530 the carrier divide the network into multiple SDN domains, each SDN 531 domain covers only a segment of the network. Additionally, the ALTO 532 server has only relatively coarse-grained information, while SDN 533 domain controllers could easily collect more fine-grained 534 information. More importantly, different SDN domains may implement 535 different information aggregation and privacy policies (e.g., when 536 such domains are dedicated to certain customers of the carrier). 538 These observations suggest that the Vertical Architecture is 539 advantageous over the Horizontal Architecture. With the Vertical 540 Architecture, SDN and ALTO are explicitly separated and as a result 541 the logic is cleaner and this allows them to evolve independently. 542 Furthermore, the Vertical Architecture makes automated information 543 collect possible for ALTO, which could make ALTO deployment and 544 management easier and more attractive. Therefore, in the remainder 545 of this draft, we mainly focus on the Vertical Architecture. We will 546 describe the interactions and the information flows in further 547 details for the Vertical Architecture. 549 3.3. Interactions between SDN and ALTO 551 The interactions between SDN controllers (as ALTO clients) and ALTO 552 servers are significantly different. Legacy ALTO clients retrieve 553 information from ALTO servers. However, SDN controllers may also 554 need to push information to ALTO servers. In a carrier's network, 555 SDN controllers and the ALTO server are owned by the same carrier. 556 Interactions between them could be significantly more complex. 558 The interactions between the SDN controllers and the ALTO server can 559 be divided into two categories. We refer to as the "upward flow" the 560 information flow from the second tier (SDN controllers as ALTO 561 clients) to the first tier (ALTO server), and refer to as the 562 "downward flow" the information flow in the reverse direction, i.e., 563 from the first tier (ALTO server) to the second tier (SDN controllers 564 as ALTO clients). 566 3.3.1. Downward Interaction 568 The downward interaction is the information flow from ALTO servers to 569 ALTO clients (i.e., SDN controllers). Each SDN controller is also an 570 ALTO client and retrieves relevant network information from the ALTO 571 server. This is similar to the current scope of ALTO without the 572 existence of SDN; however, the differences are that with the 573 existence of SDN, the network information is generally specific to 574 SDN and SDN domains; SDN controllers as ALTO clients could query the 575 ALTO server for either inter-domain or intra-domain network 576 information (provided that intra-domain information is reported and 577 made available). 579 The fundamental difference is a result of SDN and SDN domain 580 division, which do not exist in legacy network application scenarios. 581 For instance, an SDN controller for a specific SDN domain may be 582 interested in obtaining internal information of other SDN domains 583 (provided that other domains allow to do so), or obtaining domain- 584 level information such as inter-SDN-domain connectivity. None of 585 these is applicable to legacy ALTO client scenarios. As a result, 586 ALTO server and its protocol should be extended to support such 587 scenarios. 589 3.3.2. Upward Interaction 591 The upward interaction is the information flow from ALTO clients 592 (i.e., SDN controllers) to ALTO servers. SDN controllers open up the 593 possibilities of conveniently collecting network information and 594 exporting such information to ALTO servers. SDN controllers are at 595 the best position to collect network information. 597 More importantly, it is an inevitable requirement that SDN 598 controllers collect the information of the networking devices in its 599 domain. Each SDN controller may collect network information from the 600 devices managed by it and information from other SDN controllers), 601 and report such information to the ALTO server, subject to the 602 information aggregation and privacy policies defined for the 603 corresponding individual SDN domain. Such network information is 604 referred to the inter-domain network information. The network 605 information could include key information such as domain-level 606 network cost, bandwidth, domain-specific connectivity, etc. The 607 upward interactions could be implemented in either the push model or 608 the pull model. 610 For instance, an SDN domain could be dedicated to some of a carrier's 611 certain customers; the usage of such a domain gives privileged client 612 access. However, such a domain is an integral sub-network of the 613 carrier's network. In such a case, the ALTO server for the carrier's 614 network is not able to collect necessary information in a scalable, 615 manageable way. Even if we assume that the ALTO server can 616 automatically pull necessary information directly from networking 617 devices, the dedicated domain may disallow the ALTO server to do so, 618 because customers who own and manage this domain may enforce 619 stringent privacy policies and disallow exporting information 620 externally. The SDN controller is the best entity that can facility 621 the automation of information collection while at the same time 622 enforce the specific privacy policy. 624 It is worth noting that network information collection has not been 625 explored, and that network information collection could introduce 626 significant overhead and complexity, in the current scope of ALTO. 627 However, automated network information collection is a key to the 628 success of ALTO. With the help of SDN and the Vertical Architecture, 629 such automated network information collection becomes feasible and 630 appealing. Note that this does not exclude the possibility of 631 network operators manually or automatically update the ALTO server 632 with the network information (e.g., the network cost map). It is 633 also worth noting that an SDN controller may choose to report its 634 domain-specific network information only (referred to as the intra- 635 domain information), with or without privacy policies. In this case, 636 SDN controllers become an automated information collector for the 637 ALTO server. 639 3.4. Interactions between Legacy ALTO Clients and ALTO Servers 641 With the existence of SDN, the way that legacy network applications 642 (i.e., as legacy ALTO clients) interact with ALTO servers is also 643 different. 645 In legacy ALTO client/server scenarios, ALTO clients obtain cost maps 646 from ALTO servers, with the implicit assumption that ALTO servers 647 understand how the underlying network routes packets, which allows 648 ALTO servers to define or compute a cost metric associated with a 649 given route. 651 However, with the introduction of SDN, such assumption may no longer 652 hold, as SDN controllers may dynamically negotiate and determine a 653 route between two end points (which may belong to two different SDN 654 domains), especially when applications have specific requirements for 655 network resources (e.g.bandwidth, delay, etc). Thus, in order for 656 applications to best utilize the network resources, the way that 657 legacy ALTO clients communicate with ALTO servers should be adapted 658 to SDN. 660 4. Information Flows 662 We now further describe the two different information flows through 663 two sets of use cases, one for the information flow from ALTO servers 664 to ALTO clients, the other for the information flow from SDN 665 controllers to ALTO servers. 667 4.1. Information Flow of SDN Controller 669 A network may consist of multiple SDN domains. Note that due to 670 operational or deployment concerns, there may exist networking 671 devices that do not belong to any SDN domain. In each SDN domain, 672 the SDN controller is responsible for the following tasks (only ALTO 673 related tasks are included below): 675 o Collect fine-grain information from the networking devices it 676 manages. Such information could include, but not limited to, SDN 677 domain topology, link capacity, available bandwidth on each link, 678 links connected to external devices belonging to other SDN 679 domains. 681 o Implement pre-defined domain-specific policies. Such policies 682 could include, but not limited to, how resources should be 683 allocated, how the collected information should combined and 684 presented. 686 o Optionally aggregate the collected information for external view 687 purposes per its policies. 689 o Obtain cost maps at the granularity of SDN domains or obtain 690 internal cost maps for specific domains (if available), consult 691 for cross-domain data-forwarding plane recommendations from ALTO. 693 o Make (ALTO recommended) data/forwarding plane decisions based on 694 the cost maps obtained from ALTO. 696 4.2. Information Flow of Applications, SDN and ALTO 698 We now give three examples to describe a complete work flow, which 699 connects all key elements in an SDN. 701 4.2.1. SDN-aware Applications 703 o An application's end point sends a request for network resources 704 to the SDN controller it belongs to (i.e., the SDN controller for 705 the SDN domain where this application's end point belongs to). 706 The request should include the destination end point or the set of 707 destination end points, and a set of requirements on network 708 resources (e.g., bandwidth) 710 o The SDN controller obtains an SDN-specific cost map from the ALTO 711 server (this step may occur independent of remaining steps) 713 o The SDN controller uses the cost map and negotiate one or many 714 path(s) with other SDN controllers (since the path may span across 715 multiple SDN domains, thus all SDN controllers of the involved 716 domains should participate in setting up the paths) 718 o The SDN controller responds to the requesting application's end 719 point. 721 o If the requested path(s) are successfully set up, the 722 application's end point starts to communicate with the destination 723 end points. 725 4.2.2. SDN-unaware Applications 727 SDN-unaware applications do not directly communicate with SDN 728 controllers. Instead, they follow special packet formatting rules to 729 encode the SDN-specific requests, and the SDN capable networking 730 devices pick up these requests and forward them the SDN controllers. 732 The remaining work flow is similar to the work flow of SDN-aware 733 applications, except that SDN controllers do not respond to the 734 requesting applications. Thus, when the requests cannot be 735 satisfied, SDN-unaware applications may suffer from packet losses, 736 due to networking devices process these applications' packets in a 737 best effort fashion. 739 4.2.3. Legacy Applications 741 Legacy applications can be greatly simplified, as it is unnecessary 742 and is not helpful for them to directly communicate with ALTO servers 743 any more: 745 o An end point of a legacy application sends a packet to a known 746 destination 748 o A SDN capable networking device picks up the packet; however, if 749 the path for the two end points has not been set up yet, the SDN 750 controller will be consulted 752 o The SDN controller obtains a cost map from the ALTO server (this 753 step may occur independent of remaining steps). 755 o The SDN controller negotiate with other SDN controllers to set up 756 a best-effort path for the requesting end point. 758 o The forwarding rules for this path are pushed to all networking 759 devices that are on the chosen path 761 o Communications between the two end points continue; the forwarding 762 rules may expire if the communication is tore down 764 In this case, legacy applications are relieved from the complexity of 765 dealing with the ALTO server using the ALTO protocol. ALTO-related 766 intelligence, which fundamentally belongs to the network 767 intelligence, is implemented in the network, rather than partly 768 outside the network. 770 4.3. Summary 772 It is worth noting that this architecture is fundamentally different 773 from common ALTO use cases such as ALTO in CDN or data center (DC). 774 The differences lie in that in the latter cases the components in 775 question (e.g., CDN or DC) are largely consumers of ALTO services, 776 while in the former case SDN domains are not only making decisions 777 that may affect ALTO and generating/aggregating information that ALTO 778 needs, but also the consumers of ALTO services. Furthermore, in the 779 former case, SDN domains are an integral part of the underlying 780 network infrastructure where their decisions could be treated as 781 constraints for ALTO; however, in the latter cases, the components in 782 question (e.g., CDN or DC) are apparently not necessarily integral 783 parts of the underlying network and their decisions could be treated 784 as recommended outcomes suggested by ALTO. 786 5. Messaging 788 The information exchanged between the SDN domain controllers and the 789 ALTO server is encoded and implemented by specific messaging 790 mechanisms. Below we describe a preferred messaging mechanism where 791 we focus mainly on the semantics of the messages. 793 Based on the ALTO services, there are two-way message exchanges 794 between the SDN controller and the ALTO server. NBI is used and 795 should be adapted to accommodate such message exchanges. The concept 796 of SDN domain is enforced by the controller if its policy defines so; 797 therefore, the controller can opt to export the relevant information 798 at policy-specific granularities. 800 5.1. Service Negotiation 802 SDN Domain controllers can communicate with the ALTO server to 803 negotiate any or all of the service information described in the next 804 two subsections. After negotiation, such information can be pulled 805 from or pushed to ALTO server depending further on the communication 806 mechanism provided by NBI. Further, the detail mechanism of 807 consuming the above information will depend on the types of ALTO 808 services being offered and not be covered by this use case. 810 5.2. Status Report (Upward Information Flow) 812 o network "node" information (its granularity is specified by 813 controller's policy), mainly including network and/or geographical 814 location, services, etc 816 o network "topology" information (at a granularity specified by 817 controller's policy), mainly including SDN-domain-level 818 (interdomain) topology and an abstract SDN intradomain topology if 819 any; if the policy allows, controller can also export detailed 820 intradomain topology (the granularity should be specified by the 821 policy). 823 o network "link" information, similar to "node" and "topology", such 824 information (e.g., link usage and state like congestion, delay, 825 cost etc) is policed by the controller's policy and could be 826 exported at different levels of granularity 828 o network "routing" information, for flows defined in flow tables, 829 at the policy-specified granularity 831 o path information, about the path initiation and status policed by 832 controller's policy. 834 5.3. ALTO Message Dissemination (Downward Information Flow 836 It is important to note that the vanilla ALTO service (i.e., cost map 837 or path cost information) is no longer directly applicable to the 838 context of co-existing SDN and ALTO. 840 In vanilla ALTO service scenarios, paths (i.e., routing between any 841 pair of routers) are deterministic a prior, regardless of ALTO 842 recommendations. However, in the context of co-existing SDN and 843 ALTO, routing is to be determined based on many factors including 844 ALTO. For instance, the routing between any pair of two SDN capable 845 routers may not be fully determined when the SDN domain controller(s) 846 query ALTO service for recommendations. 848 o network path-cost map at the granularity of SDN domains (keep in 849 mind that the routing path may not be finalized when ALTO is 850 consulted, as the flow table may not be propagated for the given 851 flows). 853 o selection or preferences of one or multiple paths among a set of 854 paths at the granularity of SDN domains; selected/preferred paths 855 can have defined priority and/or failover definitions; 857 6. Use Case for Co-existing SDN and ALTO 859 6.1. Use Case for Upward Flow 861 The upward flow delivers SDN domains' network information by SDN 862 controllers to the ALTO server. Each SDN controller is responsible 863 for collecting, aggregating, and submitting its own domain's network 864 information to the ALTO server. Due to the possibility of some SDN 865 domain being dedicated to certain customers, we illustrate the upward 866 flow in two use cases. 868 6.1.1. Unrestrictive Information Exporting 870 SDN domain controllers have to collect various network information 871 from the networking devices they manage no matter if ALTO exists or 872 not. The reason is that an SDN controller may have to make decisions 873 for allocating resources within its domain, and making such decisions 874 need various network information. Since such information is readily 875 collected and available, an SDN controller could submit such 876 information as is (or after simple processing) to the ALTO 877 server.Take the available link bandwidth as an example (available 878 link bandwidth could be used as a measure of "distance"). An SDN 879 controller could periodically collect the available bandwidth on all 880 links in its domain and submit it to the ALTO server. However, such 881 information should be annotated with the domain information (e.g., 882 domain ID). By submitting such information, later other SDN 883 controllers may request for this domain's available link bandwidth 884 information. 886 6.1.2. Restrictive Information Exporting 888 An SDN domain belonging to a carrier may be dedicated to certain 889 customers of that carrier. In this case, the dedicated users of an 890 SDN domain manage not only how resources should be allocated but also 891 what information should be exported. 893 A carrier may dedicate a set of small data centers (on multiple 894 sites) to its certain customer. These data centers are put under a 895 single SDN domain. The customer can manage the dedicated multi-site, 896 small data centers via the SDN controller. Periodically the SDN 897 controller collects network information from all data centers. 899 However, different than the former unrestrictive case, the customer 900 may have stringent privacy policies and therefore decide to aggregate 901 the collected information before submitting to the ALTO server. 903 For instance, the customer may aggregate the information for a data 904 center network in the same site such that the data center network is 905 shrunk into a single node; by doing so, the multi-site data center 906 network is aggregated into a multi-node network topology, each node 907 in the topology actually corresponds to a small data center in 908 reality. The aggregated network topology could be annotated with 909 available link bandwidth information or other information that is 910 collected and allowed to be exported. 912 The customer's information aggregation policy defines how the 913 information should be pre-processed before exporting to the ALTO 914 server. The main purpose of aggregation is to protect privacy. As a 915 result of information aggregation, the exported network information 916 could be a logical topology (annotated with various network 917 information, e.g., distance or cost) which is totally different from 918 the physical topology. 920 6.1.3. Information Aggregation 922 Without SDN, ALTO defines cost maps for an aggregated view of the 923 network topology, where the granularity of aggregation is determined 924 by the network carrier and could be either coarse-grain or fine- 925 grain. 927 However, with the introduction of SDN, such information aggregation 928 could be greatly simplified and should be policed based on the 929 policies defined for each SDN domain. For instance, ALTO only needs 930 to collect information from a pre-defined set of SDN domain 931 controllers, where the controllers determines at what granularity 932 they would like to aggregate the information and export them. In 933 addition, such aggregation is governed by the domain-specific 934 policies, which defines not only the granularity of aggregation but 935 also to whom such aggregated information may be exposed. 937 More specifically, an illustrative use case is as follows. SDN 938 controllers collect fine-grain information and aggregate it 939 periodically per their policies. ALTO is configured to obtain the 940 aggregated information from a set of SDN domain controllers and 941 obtain possibly raw information from networking devices (or the 942 network operation center). ALTO then constructs a complete view of 943 the overall network (an aggregated view of the network). SDN 944 controllers obtain cost maps from ALTO and apply such maps when 945 making data/forwarding plane decisions. 947 Another illustrative use case is as follows. SDN controllers may 948 choose to export fine-grain information to ALTO. After it obtains 949 the cost maps from ALTO, it could leverage the cost maps with greater 950 details about their own domains and make informed decisions. 951 However, SDN controllers should not overload ALTO by exporting too 952 much fine-grain information. 954 6.2. Use Case for Downward Flow 956 We illustrate the use of downward flow through several use cases as 957 follows. 959 Note that when the originating SDN domain's controller make decisions 960 for choosing path(s) and set up the path(s), each involved SDN domain 961 controller should map the overall decision to scoped decisions 962 specifically for their responsible domains. 964 6.2.1. SDN-Aware QoS Metrics 966 We use two use cases to describe SDN-aware QoS. When aggregating QoS 967 information, SDN controllers or the information aggregation policies 968 should understand the semantics of each QoS metrics. For instance, 969 some metrics (e.g., delay) are additive, while some others are 970 multiplicative (e.g., packet loss rate). The information aggregation 971 policy should be flexible enough to specify such details. 973 An SDN capable application / source end-point may request for a 974 certain amount of end-to-end bandwidth to a destination end-point on 975 the fly. The two end points in question should be in the same 976 administrative domain, but they are not in the same SDN domain. The 977 path(s) set up for such a request span across multiple SDN domains. 979 The SDN controller of the source domain (i.e., the SDN domain where 980 the source end-point is located), referred to as the source SDN 981 controller, should first obtain the cost maps from the ALTO server. 982 Such cost maps are SDN-domain-specific, namely, the costs are defined 983 for pairs of SDN domains, rather than for pairs of end points as in 984 the legacy ALTO case. 986 The source SDN domain controller should then determine path(s) for 987 the two end points based on the cost maps and associated information 988 obtained from ALTO. More specifically, the controller should: 990 o Compute a lowest-cost path at the SDN domain level using the 991 obtained SDN-domain-specific cost map. 993 o Contact the controllers of those SDN domains on the selected path, 994 probing for the available bandwidth that could be dedicated to the 995 requested session. 997 o Check if all of the selected path have sufficient combined 998 bandwidth that matches the required bandwidth 1000 o if the combined bandwidth of all selected paths cannot match the 1001 requirement, then go back to step 1 and select another lowest-cost 1002 path (different than the already selected ones) 1004 * if no path can be selected and the combined bandwidth does not 1005 match the requirement, the request cannot be satisfied. 1007 o if the combined bandwidth of all selected paths match the 1008 requirement, then set up all selected paths by signaling all 1009 involved SDN domain controllers. Note that the signaling protocol 1010 and how to set up paths are beyond the scope of this document. 1012 Data backup and migration among data centers, which typically require 1013 bulk data transfers, is an example of on-demand bandwidth use case. 1014 Data centers may be managed by one or multiple SDN domains; thus bulk 1015 data transfer could be thought of as bulk data transfer among 1016 multiple SDN domains. 1018 Similar to the preceding use case, applications may request for paths 1019 satisfying some certain QoS metrics, e.g., VoIP applications may ask 1020 for paths with delay being lower than certain thresholds. This 1021 requires that ALTO cost maps embed such information, and that SDN 1022 controller should export such information to ALTO. 1024 6.2.2. Content Delivery Networks (CDN) 1026 Content Delivery Network (CDN) has been widely deployed to help 1027 dissemination of content at the Internet scale. Network carries are 1028 also deploying CDNs inside their own networks to improve the user 1029 experiences of their customers. With the introduction of SDN, not 1030 only legacy CDN but also a new SDN-based CDN can be seamlessly 1031 implemented and integrated with the current network infrastructure. 1033 Here is an example of the flow of SDN-enabled CDN. Suppose that 1034 there are a set of CDN servers deployed in a carrier's network and 1035 they are willing to be managed by SDN. An equivalent class for each 1036 of the CDN server is defined by either the CDN carrier or the network 1037 carrier (these two carriers can be the same). An equivalent class is 1038 a set of IP addresses, one for a CDN server, where if one can be used 1039 to fulfill requests for a specific content, then any server in this 1040 class can also be used to serve the same requests. In the extreme 1041 case, there is only one equivalent class for all CDN servers. 1043 Then the pre-defined equivalent classes are pushed to the SDN 1044 controllers, which leverage such information to select CDN servers 1045 and set up paths for any end point to any such servers. 1047 o A network client (e.g., an HTTP-based Web client) obtains the IP 1048 address, referred to as A, of one of the CDN servers in the 1049 carrier's network (e.g., by DNS queries) 1051 o The client sends a first packet destined for A (for HTTP requests, 1052 this packet is a TCP SYN packet) 1054 o An SDN capable networking device picks up the packet 1056 o If there are forwarding rules already set up for the communication 1057 between the requesting client and the destination A, then follow 1058 the rules to forward the request packet 1060 o Otherwise, forward the request packet to the SDN controller of 1061 this domain 1063 o Once receiving a forwarded packet from a networking device, the 1064 SDN controller takes the following actions: 1066 * Retrieves the equivalent class for the given destination A 1068 * Obtains a cost map from the ALTO server (this step could take 1069 place asynchronously) 1071 * Ranks all CDN servers in the equivalent class according to the 1072 cost map obtained from the ALTO server 1074 * Selects the best CDN server, referred to as B, based on the 1075 above ranking 1077 * Negotiates and sets up a best-effort path to the selected CDN 1078 server with other controllers 1080 * Sets up forwarding rules for the path, and rewriting rules for 1081 replacing the IP address of A with the IP address of B (so that 1082 the client is actually communicating with B, although it may 1083 think that it is communicating with A; however, which server it 1084 communicates is not important) 1086 o The request packet is forwarded to the chosen CDN server B, 1087 subject to the forwarding rules and rewriting rules 1089 o The client communicates with the CDN server B 1091 o The path and associated forwarding/rewriting rules are expired whe 1092 n the communication is torn down (this step is irrelevant to the 1093 ALTO extension for SDN, therefore, it is out of scope) 1095 However, the above use case has two limitations. First, it violates 1096 the TCP semantics; namely, the client intends to and believes that it 1097 is communicating with server A, but actually it is communicating with 1098 server B. Second, it has to rely on the capability of devices being 1099 able to rewrite forwarding rules (e.g., use one IP address to replace 1100 another one in a packet). 1102 If the above two limitations become concerns, e.g., either TCP 1103 semantics should not be violated or rewriting is not available or 1104 both, the above SDN-enabled CDN use case can be implemented in 1105 similar way, with the help of a redirection server. 1107 Below we describe the steps that are different: 1109 o A redirection server (or server farm), referred to as R, is set up 1110 for redirecting client requests 1112 o Each SDN controller sets up path(s) to the given redirection 1113 server R 1115 o Note that the redirection server could be an integral component of 1116 an SDN controller (either collocated or integrated), in which 1117 path(s) are not necessary 1119 o Once receiving a forwarded packet from a networking device, the 1120 SDN controller takes the following actions: 1122 * Retrieves the equivalent class for the given destination A 1124 * Obtains a cost map from the ALTO server (this step could take 1125 place asynchronously) 1127 * Ranks all CDN servers in the equivalent class according to the 1128 cost map obtained from the ALTO server 1130 * Selects the best CDN server, referred to as B, based on the 1131 above ranking 1133 * Sends the information of the chosen CDN server, i.e., its IP 1134 address B, to the redirection server R 1136 * Negotiates and sets up a best-effort path to the redirection 1137 server R (if R is not integrated with the SDN controller) 1139 * Sets up forwarding rules for the path to R 1141 * Negotiates and sets up a best-effort path to the CDN server B 1143 * Sets up forwarding rules for the path to B 1145 o The client communicates with the redirection server R 1147 o R sends an HTTP redirection packet to the client, redirecting 1148 future requests to the CDN server B (which is notified by the SDN 1149 controller) 1151 o The client communicates with the chosen CDN server B (note that 1152 the path to B has been already set up) 1154 6.2.3. Information-Centric Content Delivery Networks (IC-CDN) 1156 Information-Centric Networking (ICN) is a "host-to-information" 1157 communication model, different from the legacy "host-to-host" model 1158 implemented by the Internet. Content Delivery Network (CDN) is more 1159 of a "host-to-information" model (i.e., CDNs can be treated as a 1160 special instance of ICN), but implemented in the "host-to-host" 1161 model, due to the fact that the current semantics provided by the 1162 Internet only support the "host-to-host" model. 1164 With the introduction of SDN, CDNs can be converted into an 1165 information-centric networking implementation: 1167 o A CDN client sends a request for a specific content 1169 o The request packet is formatted per the CDN in SDN specification 1170 (beyond the scope of this draft), containing 1172 * the requested content name in the packet 1174 * destination (a specific anycast IP address) which is reserved 1175 for legacy applications to invoke SDN capabilities 1177 * (optional) QoS requirements (e.g., prefer fast/local servers 1178 vs. slow/remote servers, demands are elastic or not) 1180 o An SDN capable networking device picks up the request packet 1182 o If there are forwarding rules set up for this content request 1183 already, then follow the rules to forward the request packet, and 1184 terminate this. 1186 o Otherwise, forward the request packet to the SDN controller for 1187 this domain. 1189 o The SDN controller communicates with the CDN's name directory to 1190 look up possible CDN servers that can satisfy the request 1192 o The SDN controller obtains a cost map from the ALTO server 1194 o The SDN controller applies the cost map to select the best CDN 1195 server per the QoS requirements if specified in the request 1197 o The SDN controller negotiate the path to the selected CDN server 1198 with other controllers 1200 o The SDN controllers that along the chosen path set up the path, 1201 and push the forwarding rule(s) for this chosen path to all 1202 networking devices that are involved 1204 o The request packet is forwarded to the chosen CDN server 1206 o Data packets flow back to the CDN client 1208 In this use case, the CDN clients could be modified to send the 1209 "information-centric" request. However, in a realistic 1210 implementation, neither the CDN clients nor the CDN servers have to 1211 be significantly modified (e.g., CDN redirection could be leveraged 1212 to implement the above work flow). 1214 7. Conclusions 1216 In this draft, we identify the fundamental differences between legacy 1217 ALTO client/server and ALTO client/server with the existence of SDN. 1218 The introduction of SDN fundamentally changes the way that the ALTO 1219 works. We present the Vertical Architecture and the Horizontal 1220 Architecture to allow coherent coexistence of SDN and ALTO. We 1221 believe that the Vertical Architecture allows better division, 1222 management, flexibility, privacy control and long-term evolution of 1223 the network. Therefore we mainly focus on the Vertical Architecture 1224 in this draft. We also define the main interactions and information 1225 flows, and present a set of use cases to illustrate how we extend 1226 ALTO to support SDN, in the Vertical Architecture. 1228 8. Contributors 1230 The authors would like to thank Vijay K. Gurbani for his many 1231 detailed reviews and helpful assistance on this draft. 1233 Vijay K. Gurbani 1234 Bell Laboratories, Alcatel-Lucent 1235 1960 Lucent Lane, Rm. 9C-533 1236 Naperville, IL 60566 1237 USA 1239 Email: vkg AT (acm.org,bell-labs.com) 1241 9. Acknowlegements 1243 The authors would like to thank Tom Taylor and Aditi Vira for editing 1244 the draft. 1246 This memo is based upon work supported in part by the National 1247 Science Foundation of China (NSFC) under Grant No. 61073192 and the 1248 China 973 Program under Grant No. 2011CB302905. Any opinions, 1249 findings and conclusions or recommendations expressed in this 1250 material are those of the authors and do not necessarily reflect the 1251 views of NSF. 1253 10. Security Considerations 1255 TBD. 1257 11. IANA Considerations 1259 This document makes no specific request of IANA. 1261 Note to RFC Editor: this section may be removed on publication as an 1262 RFC. 1264 12. Informative References 1266 [1] Koponen, T., Casado, M., Gude, N., Stribling, J., Poutievski, 1267 L., Zhu, M., Ramanathan, R., Iwata, Y., Inoue, H., Hama, T., and 1268 S. Shenker, "Onix: A Distributed Control Platform for Large- 1269 scale Production Networks", Proceedings of the 9th USENIX 1270 Symposium on Operating Systems Design and Implementation (OSDI 1271 10), Vancouver, Canada, pp. 351-364", October 2010. 1273 [2] Gurbani, V., Scharf, M., Lakshman, T., and V. Hilt, "Abstracting 1274 network state in Software Defined Networks (SDN) for rendezvous 1275 services, IEEE International Conference on Communications (ICC) 1276 Workshop on Software Defined Networks (SDN)", June 2012. 1278 Authors' Addresses 1280 Haiyong Xie 1281 Huawei & USTC 1282 2330 Central Expy 1283 Santa Clara, CA 95050 1284 USA 1286 Phone: 1287 Email: Haiyong.xie@huawei.com 1288 Tina Tsou 1289 Huawei (USA) 1290 2330 Central Expy 1291 Santa Clara, CA 95050 1292 USA 1294 Phone: 1295 Email: Tina.Tsou.Zouting@huawei.com 1297 Diego R. Lopez 1298 Telefonica I+D 1299 Don Ramon de la Cruz, 84 1300 Madrid, 28006 1301 Spain 1303 Phone: 1304 Email: diego@tid.es 1306 Hongtao Yin 1307 Huawei (USA) 1308 2330 Central Expy 1309 Santa Clara, CA 95050 1310 USA 1312 Phone: 1313 Email: Hongtao.yin@huawei.com