Internet Engineering Task Force H. Xie Internet-Draft Huawei & USTC Intended status: Informational T. Tsou Expires: December 30, 2012 Huawei (USA) D. Lopez Telefonica I+D H. Yin Huawei (USA) June 28, 2012 Use Cases for ALTO with Software Defined Networks draft-xie-alto-sdn-extension-use-cases-00 Abstract The introduction of SDN fundamentally changes the way that the ALTO works. This draft describes the Vertical Architecture and the Horizontal Architecture allowing coherent coexistence of application layer traffic optimization (ALTO) with software defined network (SDN). Unique requirements for design and operations are identified and summarized, suggesting that the Vertical Architecture allows better division, management, flexibility, privacy control and long- term evolution of the network. We also define the main interactions and information flows, and present a set of use cases to illustrate how we extend ALTO to support SDN, in the Vertical Architecture. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 30, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Xie, et al. Expires December 30, 2012 [Page 1] Internet-Draft ALTO Use Cases For SDN June 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Xie, et al. Expires December 30, 2012 [Page 2] Internet-Draft ALTO Use Cases For SDN June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. An Overview of Software Defined Network . . . . . . . . . . . 5 2.1. Software Defined Network . . . . . . . . . . . . . . . . . 5 2.2. Division of Network . . . . . . . . . . . . . . . . . . . 6 2.3. SDN Domain . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Architectural Considerations for SDN and ALTO . . . . . . . . 9 3.1. The Vertical Architecture . . . . . . . . . . . . . . . . 9 3.2. The Horizontal Architecture . . . . . . . . . . . . . . . 11 3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Interactions between SDN and ALTO . . . . . . . . . . . . . . 12 4.1. ALTO Scopes . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. ALTO clients . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Interactions between SDN and ALTO . . . . . . . . . . . . 14 4.3.1. Downward Interaction . . . . . . . . . . . . . . . . . 14 4.3.2. Upward Interaction . . . . . . . . . . . . . . . . . . 14 4.4. Interactions between Legacy ALTO Clients and ALTO Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Information Flows . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Information Flow of SDN Controller . . . . . . . . . . . . 16 5.2. Information Flow of Applications, SDN and ALTO . . . . . . 16 5.2.1. SDN-aware Applications . . . . . . . . . . . . . . . . 16 5.2.2. SDN-unaware Applications . . . . . . . . . . . . . . . 17 5.2.3. Legacy Applications . . . . . . . . . . . . . . . . . 17 5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Use Case for Upward Flow . . . . . . . . . . . . . . . . . . . 18 6.1. Unrestrictive Information Exporting . . . . . . . . . . . 18 6.2. Restrictive Information Exporting . . . . . . . . . . . . 19 6.3. Information Aggregation . . . . . . . . . . . . . . . . . 19 7. Use Case for Downward Flow . . . . . . . . . . . . . . . . . . 20 7.1. SDN-Aware QoS Metrics . . . . . . . . . . . . . . . . . . 20 7.1.1. On-Demand Bandwidth . . . . . . . . . . . . . . . . . 21 7.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Content Delivery Networks (CDN) . . . . . . . . . . . . . 22 7.3. Information-Centric Content Delivery Networks (IC-CDN) . . 24 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13. Informative References . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Xie, et al. Expires December 30, 2012 [Page 3] Internet-Draft ALTO Use Cases For SDN June 2012 1. Introduction The concept of Software Defined Network (SDN) has emerged and become one of the fundamental, promising networking primitives that allow flexibility of control, separation of functional planes and continuous evolution in networks. One of the key features of SDN is the full separation of two functional planes: the control plane and the data-forwarding plane. SDN requires that networking devices support such separation, implementing the data plane mechanisms, while the control plane is provided by an external entity called the "controller". The other key feature of SDN is the new interaction process between the separated control plane and data-forwarding plane. This interaction is mandated to be performed specific open protocols, allowing for a free combination of networking devices and controllers, as well as supporting the controller to take decisions on information additional to the networking device status. There could be numerous benefits as a result of the above features in SDN, e.g., just to name a few, network virtualization, better flexible control and utilization of the network, networks customized for scenarios with specific requirements. For instance, some SDN technologies have started to find their ways into Data Center Networks (DCNs). Furthermore, in order to allow efficient and flexible implementation of the above separation and interactions, a significant portion of the SDN system could typically be implemented in software, as opposed to the hardware-based implementation adopted by most of today's networking devices. Due to the great potentials of SDN and the unique requirements of DCNs, Data Centers are likely to become a first place where SDN could be deployed. We envision that SDN could be gradually adopted by enterprise networks and then by carrier networks due to its unique, attractive features. When deploying SDN in large-scale distributed networks, we expect to see a collection of deployments limited in relatively small segments of a bigger network. In other words, it is likely that the operator of a large-scale enterprise / carrier network prefers to divide the whole networks into multiple smaller segments and put each of there segments in an SDN domain. These smaller network segments (therefore their corresponding SDN domains) are connected and jointly form the larger whole network. Such a divide-and-conquer methodology not only allows gradual deployment and continuous evolution, but also enables flexible provisioning of the network. With the deployment of SDN, application layer traffic optimization (ALTO) faces new challenges including, but not limited to, privacy Xie, et al. Expires December 30, 2012 [Page 4] Internet-Draft ALTO Use Cases For SDN June 2012 preservation, granularity of information collection and exchange, join optimization, etc. We shall elaborate these challenges and their impacts on the design of ALTO extensions for SDN in this draft. 1.1. Terminology While the definition of software defined networks is still "nebulous" to some extent, we refer to as SDN the networks that implement the separation of the control and data-forwarding planes and software defined interactions between these two separated planes; such interactions are characterized by open interfaces which allow programming the network equipment's forwarding plane by external agents, e.g., SDN controllers. However, how the two separated planes interact is not a focus of this draft; instead, the ALTO extension for SDN recommended in this draft is independent of how such interactions would be. An SDN domain is a portion of a network infrastructure, consisting of numerous connected networking devices that are SDN capable (i.e., SDN capable devices implement the control/forwarding plane separation and the open interfaces allowing external agents to program the devices) and a domain controller which implements the SDN control plane functionalities for these devices. An SDN domain can be as small as a sub-network of a dozen devices or as large as a medium/large data center network. A software defined network is a network that has one or multiple SDN domains. Due to an SDN domain typically has limited coverage, an SDN may be comprised of networking devices under control of some SDN domains (i.e., SDN managed devices) and devices under no control of any SDN domain (i.e., normal devices). Note that such normal devices could still be SDN capable and their control/forwarding planes are managed as in normal networks today. This implies that a network with both normal devices and SDN capable devices (managed by SDN domains) needs both normal and SDN capable control/forwarding plane management. 2. An Overview of Software Defined Network This section provides a high level and conceptual overview of software defined network in order to help illustrate its unique requirements for ALTO. 2.1. Software Defined Network We refer to as an "SDN" a carrier's or an enterprise's network which deploys or implements software defined networking technologies. Xie, et al. Expires December 30, 2012 [Page 5] Internet-Draft ALTO Use Cases For SDN June 2012 Since SDN separates the control plane and data-forwarding plane, we refer to the entity that implements the control-plane functionalities as the "SDN controller". In order for a network to be classified as an SDN, it is unnecessary that all networking devices have to be SDN capable. Some of devices in a network may be managed by an SDN controller while the remaining ones may not; such a network is still qualified as an SDN. Applications in software defined networks are either SDN-aware or unaware of SDN. o If an application is SDN-aware, then the application may prefer direct communication with SDN controllers, which implies that there must exist mechanism(s) for SDN-aware applications to locate and communication with SDN controllers. If the application prefers indirect communication with SDN controllers, then it follows the case of SDN-unaware applications (see below). Applications that are SDN-aware may be able to better utilize the SDN capable network due to its knowledge about SDN and its capability of proactive, direct interaction with SDN. o If an application is SDN-unaware, then the application indirectly communicates with SDN controllers by sending application datagrams with specific formats, via which the application can specify its requirements for the network resources. Legacy applications (applications for the current IP networks) are largely SDN- unaware, and such applications may not be able to utilize the SDN capable networks as efficiently as SDN-aware applications. Whether and how applications should/can be SDN-aware or SDN-unaware is beyond the scope of this draft. However, the framework we described in this draft is applicable to both SDN-aware and SDN- unaware cases. 2.2. Division of Network A network operator may decide to divide the network into multiple sub-networks, some of which are SDN capable and thus are managed by corresponding SDN controllers. There could be numerous reasons for such division of network. Below we summarize a few of them: o Scalability. The number of devices an SDN controller can feasibly manage is likely to be limited. Therefore, in order to manage a many Xie, et al. Expires December 30, 2012 [Page 6] Internet-Draft ALTO Use Cases For SDN June 2012 devices that cannot be put under control of a single SDN controller, multiple controllers have to be deployed. Hence, the network is divided into multiple sub-networks; if a sub-network has SDN capable devices, it should be managed by an SDN controller. o Manageability. At the network level, in order to reduce the complexity of management, a carrier may decide to divide the network into multiple sub-networks and put some of them under control of some SDN controllers (provided that the devices in such sub-networks are SDN capable); each of the sub-networks can be managed independently to some extent, thus reducing the overall complexity of managing the whole network. Even at the sub-network level, a carrier may still decide to further divide the sub-network in order to further reduce complexity of management. For instance, a sub-network under control of an SDN controller may span across a large geographical area or cover a large number of devices; in this case it is reasonable for the carrier to further divide it into two or even more sub-networks, such that the complexity of managing each individual sub-network plus the overall complexity of managing all divided sub-networks are reduced. o Privacy. When a carrier divides its network into multiple sub-networks and put them under control of SDN, the carrier may choose to implement difference privacy policies in different sub-networks. For example, a carrier may dedicate a part of its infrastructure to some certain customers, dividing the whole network and dedicate some of the sub-networks is a convenient and scalable way to manage the network resources for these customers. Another example is that a sub-network in a carrier's network may be dedicated to some certain customers and such information as network topology may not be disclosed to any external entity. o Deployment The deployment of network infrastructures, especially new network infrastructure and technologies, has to be incremental. This means that at any time, a carrier's network may consist of a portion of legacy and a portion of non-legacy infrastructure. When deploying new infrastructure or technologies, it is highly preferable to limit the scope of new deployment and do it in an incremental way. In such cases, it is very favorable to divide the network into multiple individually manageable sub-networks and choose some of them to deploy the new infrastructure / Xie, et al. Expires December 30, 2012 [Page 7] Internet-Draft ALTO Use Cases For SDN June 2012 technologies. 2.3. SDN Domain With the introduction of SDN, we believe that it is inevitable for carriers to divide their networks for many reasons as illustrated in the preceding subsection. Therefore, we believe that to better suit this need, it should be recommended that SDN domains are defined and applied in division of the networks. An SDN domain is a sub-network, resulted from division of a network which is determined by the network operator. Each domain typically consists of numerous connected networking devices, each of which is SDN capable. Each domain also has a domain controller which implements SDN control plane functionalities for the devices in this domain. Another important task such a domain controller is responsible for includes fine-grain network information collection (for devices in this domain). The collected information is necessary for the controller to make data-forwarding plane decisions. Note that such a domain controller may be integrated as a part of a so- called "network operating system" (NOS). An example of such a network operating system is illustrated in [1]. Any networking device, if under the control of certain SDN domains, should belong to only one SDN domain and should be under the control of the SDN domain's controller. In other words, the intersection of two domains is always empty. Furthermore, SDN domains are connected (via the connectivity among underlying devices provided by the underlying network; such devices belong to different SDN domains) to form the whole network. For a large-scale distributed networks owned by a national/multi-national carrier or enterprise, it is natural to adopt the "divide-and- conquer" strategy and divide the whole network into multiple SDN domains. Even for small or medium networks, multiple SDN domains may be necessary in order to virtualize the network resources (e.g., set up multiple SDN domains for a large data center network to instantiate multiple virtual data centers for many content providers). Note that how multiple SDN domains inside a carrier's/ enterprise' network work together is beyond the scope of this draft and is handled by other working groups. Inside each SDN domain, its controller may define domain-specific policies on information importing from devices, aggregating, and exporting to external entities. Such policies may not be made public; therefore, other domain controllers or ALTO may not know the existence of such policies for any given SDN domain. Xie, et al. Expires December 30, 2012 [Page 8] Internet-Draft ALTO Use Cases For SDN June 2012 The natural network division implemented by SDN domains impose significantly new and challenging requirement for shaping the interactions between SDN and ALTO, and therefore designing the protocols to enable such interactions. 3. Architectural Considerations for SDN and ALTO We introduce two architectures that allow coherent co-existence of SDN and ALTO in this section: o The Vertical Architecture (or the V Architecture for short) allows better division, management, flexibility, privacy control and long-term evolution of the network, and o The Horizontal Architecture (or the H Architecture for short) simplifies the implementation of ALTO extensions for SDN. We next present each of these two architectures individually. 3.1. The Vertical Architecture The Vertical Architecture is illustrated in the following figure. The network has one or multiple SDN domains and an ALTO server. The interactions between the SDN controllers and the SDN capable devices fall in the scope of SDN and therefore is out of the scope of this draft; instead, the interactions between the SDN domains (more specifically, SDN controllers) and the ALTO server is what this draft focuses on. .----------------------------------------------. | ALTO Server | `----------------------------------------------' ^ | .-------------|------------|-------------------. | | V | | .-------------------------------. | | | SDN Controller | | | `-------------------------------' | | | | | | | | .-------------------------------. | | | SDN Capable Devices | | | `-------------------------------' | | | | An SDN Domain | `----------------------------------------------' Xie, et al. Expires December 30, 2012 [Page 9] Internet-Draft ALTO Use Cases For SDN June 2012 The Vertical Architecture is a hierarchical architecture consisting of three tiers. In the first tier, the only entity is the ALTO server. In the second tier, the only entities are the SDN domain controllers. In the third tier, the only entities are SDN domains (each domain consists of numerous networking devices). In this architecture, all entities are owned by the same carrier. However, some of the SDN domains (and the networking devices in them) may be dedicated to certain customers of the carrier (the carrier gives the customers privileges access). This is subject to a collaboration agreement between them. The interactions between the SDN controllers and the ALTO server can be divided into two categories: o Upward interactions (i.e., from SDN controllers to ALTO servers): each SDN controller collects network information from the devices managed by it and information from other SDN controllers), and report such information to the ALTO server, subject to the information aggregation and privacy policies defined for the corresponding individual SDN domain. Such network information is referred to the inter-domain network information. The network information could include key information such as domain-level network cost, bandwidth, domain-specific connectivity, etc. The upward interactions could be implemented in either the push model or the pull model. It is worth noting that network information collection has not been explored, and that network information collection could introduce significant overhead and complexity, in the current scope of ALTO. However, automated network information collection is a key to the success of ALTO. With the help of SDN and the Vertical Architecture, such automated network information collection becomes feasible and appealing. Note that this does not exclude the possibility of network operators manually or automatically update the ALTO server with the network information (e.g., the network cost map). It is also worth noting that an SDN controller may choose to report its domain-specific network information only (referred to as the intra-domain information), with or without privacy policies. In this case, SDN controllers become an automated information collector for the ALTO server. o Downward interactions (i.e., from ALTO servers to SDN controllers): each SDN controller is also an ALTO client and retrieves relevant network information from the ALTO server. This is similar to the current scope of ALTO without the existence of SDN; however, the differences are that with the existence of SDN, the network information is generally specific to SDN and SDN domains; SDN controllers as ALTO clients could query the ALTO server for either inter-domain or intra-domain network information (provided that intra-domain information is reported and made Xie, et al. Expires December 30, 2012 [Page 10] Internet-Draft ALTO Use Cases For SDN June 2012 available). We refer to as the "upward flow" the information flow from the second tier (SDN controllers as ALTO clients) to the first tier (ALTO server), and refer to as the "downward flow" the information flow in the reverse direction, i.e., from the first tier (ALTO server) to the second tier (SDN controllers as ALTO clients). 3.2. The Horizontal Architecture The Horizontal Architecture is illustrated in the following figure. Each SDN controller is integrated with an ALTO server. The interactions between the SDN controllers and the ALTO server is represented by the horizontal line in the figure. An example of this architecture can be found in [2]. .---------------------------------------------------------------------. | .--------------------------. .--------------------------. | | | SDN Controller |<----| ALTO Server | | | `--------------------------' `--------------------------' | `-----------------|---------------------------------------------------' | .-------------------------------. | SDN Capable Devices | `-------------------------------' In the Horizontal Architecture, the SDN controller can act as an ALTO client and query the network information of the networking devices from the ALTO server. However, such network information may not meet the SDN controllers' granularity requirement (i.e., the information provided by the ALTO server may not be as fine-grained as needed by the SDN controllers). In addition, there may exist redundant information collection, as SDN controllers are inevitably collecting various fine-grain information from the devices they manage; the information collection by the ALTO server, either manually or automatically, is likely to be redundant. Furthermore, when the carrier decides to divide its network into multiple SDN domains, it can be difficult, if not impossible at all, for the Horizontal Architecture to adapt to the network division. 3.3. Summary The ALTO server covers a carrier's network as a whole; however, if the carrier divide the network into multiple SDN domains, each SDN domain covers only a segment of the network. Additionally, the ALTO server has only relatively coarse-grained information, while SDN domain controllers could easily collect more fine-grained Xie, et al. Expires December 30, 2012 [Page 11] Internet-Draft ALTO Use Cases For SDN June 2012 information. More importantly, different SDN domains may implement different information aggregation and privacy policies (e.g., when such domains are dedicated to certain customers of the carrier). These observations suggest that the Vertical Architecture is advantageous over the Horizontal Architecture. With the Vertical Architecture, SDN and ALTO are explicitly separated and as a result the logic is cleaner and this allows them to evolve independently. Furthermore, the Vertical Architecture makes automated information collect possible for ALTO, which could make ALTO deployment and management easier and more attractive. Therefore, in the remainder of this draft, we mainly focus on the Vertical Architecture. We will describe the interactions and the information flows in further details for the Vertical Architecture. 4. Interactions between SDN and ALTO We now describe the interactions between SDN and ALTO in details. We first compare the ALTO scopes without and with the existence of SDN, and then describe the various interactions existing in the Vertical Architecture. 4.1. ALTO Scopes The existence of SDN differentiates two scopes of ALTO, namely, the current scope of ALTO without SDN (referred to as the SDN-unfriendly Scope) and the new scope of ALTO with coherent coexistence of SDN (referred to as the SDN-friendly Scope): o the SDN-unfriendly Scope: in the current scope of ALTO, there exist interactions between ALTO clients and ALTO servers. Such interactions are one-way interaction, meaning that ALTO information flows in one direction, i.e., from the server to the clients. More specifically, ALTO clients submit ALTO requests to (and subsequently receive ALTO responses from) an ALTO server. Additionally, ALTO clients in the current scope of ALTO are network applications who would like to consume the network resources. ALTO clients are typically managed by network applications rather than by network carriers. However, ALTO servers are owned and managed by network carriers. o With the introduction of SDN, the interactions between ALTO clients and ALTO servers become more complex. A more careful examination as well as important ALTO extensions are necessary to make ALTO work in the context of SDN. It is important to note that if the network does not implement network division (i.e., does not implement SDN domains), the interactions are "compressed" Xie, et al. Expires December 30, 2012 [Page 12] Internet-Draft ALTO Use Cases For SDN June 2012 into a compact set of interactions; specifically, both the SDN controller (recall that there exists only one single controller for the whole network) and the ALTO server could be integrated in many equally efficient fashions. For instance, ALTO server could be put underneath the controller, i.e., ALTO server provides information to the controller, as suggested by [2]. However, if the network implements division via SDN domains (i.e., there exists multiple SDN domains), we essentially "unfold" the compressed interaction space and need more complex structures that allow efficient design and implementation, due to the facts that we listed in the preceding sections. Furthermore, the design originally for the compressed space could be instantiated for the unfolded space but could not be as efficient. We next focus on the SDN-friendly Scope and highlight the complex structures and the important differences. 4.2. ALTO clients With the existence of SDN and SDN controllers, ALTO clients could be not only legacy network applications (or proxies for these network applications), but also SDN controllers. In SDN, SDN controllers have similar needs as the legacy ALTO clients which communicate with ALTO servers, because ALTO clients would like to better understand the network and thus improve the application performance. There are multiple reasons for this similarity. The most important reason is that each SDN controller is only responsible for managing a sub-network in a carrier's network; therefore, it may not understand well other sub-networks in the same carrier network. However, in order to allocate the network resources to satisfy application requirements (note that the end points of such applications may well span across multiple SDN domains), an SDN controller may have to involve other SDN controllers because the network paths needed may traverse multiple SDN domains. Thus, obtaining global information from the ALTO server is a significantly more efficient and more preferable than otherwise from SDN interconnection protocols; plus, such protocols do not exist yet today. Although SDN controllers have similar needs as legacy ALTO applications do, the fundamental properties of SDN controllers as ALTO clients are significantly different. One of the differences is the ownership and management, as most SDN controllers require additional (and more likely complex) access privileges. Specifically, SDN controllers are typically owned by the network carriers who also own their ALTO servers, while legacy ALTO clients Xie, et al. Expires December 30, 2012 [Page 13] Internet-Draft ALTO Use Cases For SDN June 2012 are network applications typically not owned by network carriers (there are cases where owned collaboratively amongst operators). In terms of management, the entity managing SDN controller is the same as that managing the ALTO server. We emphasize that when an SDN domain is dedicated to some customers of a network carrier, the use of the SDN domain is owned by these customers and so is the management. In this case, the SDN controllers as ALTO clients are slightly more like legacy ALTO clients. However, there still exist fundamental differences which we will illustrate later. 4.3. Interactions between SDN and ALTO Another difference is the interactions between SDN controllers as ALTO clients and ALTO servers. Legacy ALTO clients retrieve information from ALTO servers. However, SDN controllers may also need to push information to ALTO servers. In a carrier's network, SDN controllers and the ALTO server are owned by the same carrier. Interactions between them could be significantly more complex. 4.3.1. Downward Interaction The downward interaction is the information flow from ALTO servers to ALTO clients (i.e., SDN controllers). SDN controllers request information from ALTO servers, similar to legacy ALTO clients. However, the requested information is significantly different. The fundamental difference is a result of SDN and SDN domain division, which do not exist in legacy network application scenarios. For instance, an SDN controller for a specific SDN domain may be interested in obtaining internal information of other SDN domains (provided that other domains allow to do so), or obtaining domain- level information such as inter-SDN-domain connectivity. None of these is applicable to legacy ALTO client scenarios. As a result, ALTO server and its protocol should be extended to support such scenarios. 4.3.2. Upward Interaction The upward interaction is the information flow from ALTO clients (i.e., SDN controllers) to ALTO servers. SDN controllers open up the possibilities of conveniently collecting network information and exporting such information to ALTO servers. SDN controllers are at the best position to collect network information. More importantly, it is an inevitable requirement that SDN controllers collect the information of the networking devices in its domain. In some scenarios, it is a requirement that information flow from ALTO clients to ALTO servers. For instance, an SDN domain could be Xie, et al. Expires December 30, 2012 [Page 14] Internet-Draft ALTO Use Cases For SDN June 2012 dedicated to some of a carrier's certain customers; the usage of such a domain gives privileged client access. However, such a domain is an integral sub-network of the carrier's network. In such a case, the ALTO server for the carrier's network is not able to collect necessary information in a scalable, manageable way. Even if we assume that the ALTO server can automatically pull necessary information directly from networking devices, the dedicated domain may disallow the ALTO server to do so, because customers who own and manage this domain may enforce stringent privacy policies and disallow exporting information externally. The SDN controller is the best entity that can facility the automation of information collection while at the same time enforce the specific privacy policy. 4.4. Interactions between Legacy ALTO Clients and ALTO Servers With the existence of SDN, the way that legacy network applications (i.e., as legacy ALTO clients) interact with ALTO servers is also different. In legacy ALTO client/server scenarios, ALTO clients obtain cost maps from ALTO servers, with the implicit assumption that ALTO servers understand how the underlying network routes packets, which allows ALTO servers to define or compute a cost metric associated with a given route. However, with the introduction of SDN, such assumption may no longer hold, as SDN controllers may dynamically negotiate and determine a route between two end points (which may belong to two different SDN domains), especially when applications have specific requirements for network resources (e.g.bandwidth, delay, etc). Thus, in order for applications to best utilize the network resources, the way that legacy ALTO clients communicate with ALTO servers should be adapted to SDN. 4.5. Summary In the context of SDN, due to the specific and unique properties of SDN domains, SDN controllers as ALTO clients are significantly different from legacy ALTO clients, posing new requirements for the interactions between ALTO clients and ALTO servers. 5. Information Flows We now further describe the two different information flows through two sets of use cases, one for the information flow from ALTO servers to ALTO clients, the other for the information flow from SDN Xie, et al. Expires December 30, 2012 [Page 15] Internet-Draft ALTO Use Cases For SDN June 2012 controllers to ALTO servers. 5.1. Information Flow of SDN Controller A network may consist of multiple SDN domains. Note that due to operational or deployment concerns, there may exist networking devices that do not belong to any SDN domain. In each SDN domain, the SDN controller is responsible for the following tasks (only ALTO related tasks are included below): o Collect fine-grain information from the networking devices it manages. Such information could include, but not limited to, SDN domain topology, link capacity, available bandwidth on each link, links connected to external devices belonging to other SDN domains. o Implement pre-defined domain-specific policies. Such policies could include, but not limited to, how resources should be allocated, how the collected information should combined and presented. o Optionally aggregate the collected information for external view purposes per its policies. o Obtain cost maps at the granularity of SDN domains or obtain internal cost maps for specific domains (if available), consult for cross-domain data-forwarding plane recommendations from ALTO. o Make (ALTO recommended) data/forwarding plane decisions based on the cost maps obtained from ALTO. 5.2. Information Flow of Applications, SDN and ALTO We now describe three examples of complete information flows, which connect all key elements in an SDN. 5.2.1. SDN-aware Applications o An application's end point sends a request for network resources to the SDN controller it belongs to (i.e., the SDN controller for the SDN domain where this application's end point belongs to). The request should include the destination end point or the set of destination end points, and a set of requirements on network resources (e.g., bandwidth) o The SDN controller obtains an SDN-specific cost map from the ALTO server (this step may occur independent of remaining steps) Xie, et al. Expires December 30, 2012 [Page 16] Internet-Draft ALTO Use Cases For SDN June 2012 o The SDN controller uses the cost map and negotiate one or many path(s) with other SDN controllers (since the path may span across multiple SDN domains, thus all SDN controllers of the involved domains should participate in setting up the paths) o The SDN controller responds to the requesting application's end point. o If the requested path(s) are successfully set up, the application's end point starts to communicate with the destination end points. 5.2.2. SDN-unaware Applications SDN-unaware applications do not directly communicate with SDN controllers. Instead, they follow special packet formatting rules to encode the SDN-specific requests, and the SDN capable networking devices pick up these requests and forward them the SDN controllers. The remaining information flow is similar to that of SDN-aware applications, except that SDN controllers do not respond to the requesting applications. Thus, when the requests cannot be satisfied, SDN-unaware applications may suffer from packet losses, due to networking devices process these applications' packets in a best effort fashion. 5.2.3. Legacy Applications Legacy applications can be greatly simplified, as it is unnecessary and is not helpful for them to directly communicate with ALTO servers any more: o An end point of a legacy application sends a packet to a known destination. o A SDN capable networking device picks up the packet; however, if the path for the two end points has not been set up yet, the SDN controller will be consulted. o The SDN controller obtains a cost map from the ALTO server (this step may occur independent of remaining steps). o The SDN controller negotiate with other SDN controllers to set up a best-effort path for the requesting end point. o The forwarding rules for this path are pushed to all networking devices that are on the chosen path Xie, et al. Expires December 30, 2012 [Page 17] Internet-Draft ALTO Use Cases For SDN June 2012 o Communications between the two end points continue; the forwarding rules may expire if the communication is tore down. In this case, legacy applications are relieved from the complexity of dealing with the ALTO server using the ALTO protocol. ALTO-related intelligence, which fundamentally belongs to the network intelligence, is implemented in the network, rather than partly outside the network. 5.3. Summary It is worth noting that this architecture is fundamentally different from common ALTO use cases such as ALTO in CDN or data center (DC). The differences lie in that in the latter cases the components in question (e.g., CDN or DC) are largely consumers of ALTO services, while in the former case SDN domains are not only making decisions that may affect ALTO and generating/aggregating information that ALTO needs, but also the consumers of ALTO services. Furthermore, in the former case, SDN domains are an integral part of the underlying network infrastructure where their decisions could be treated as constraints for ALTO; however, in the latter cases, the components in question (e.g., CDN or DC) are apparently not necessarily integral parts of the underlying network and their decisions could be treated as recommended outcomes suggested by ALTO. 6. Use Case for Upward Flow The upward flow delivers SDN domains' network information by SDN controllers to the ALTO server. Each SDN controller is responsible for collecting, aggregating, and submitting its own domain's network information to the ALTO server. Due to the possibility of some SDN domain being dedicated to certain customers, we illustrate the upward flow in two use cases. 6.1. Unrestrictive Information Exporting SDN domain controllers have to collect various network information from the networking devices they manage no matter if ALTO exists or not. The reason is that an SDN controller may have to make decisions for allocating resources within its domain, and making such decisions need various network information. Since such information is readily collected and available, an SDN controller could submit such information as is (or after simple processing) to the ALTO server.Take the available link bandwidth as an example (available link bandwidth could be used as a measure of "distance"). An SDN controller could periodically collect the available bandwidth on all links in its domain and submit it to the ALTO server. However, such Xie, et al. Expires December 30, 2012 [Page 18] Internet-Draft ALTO Use Cases For SDN June 2012 information should be annotated with the domain information (e.g., domain ID). By submitting such information, later other SDN controllers may request for this domain's available link bandwidth information. 6.2. Restrictive Information Exporting An SDN domain belonging to a carrier may be dedicated to certain customers of that carrier. In this case, the dedicated users of an SDN domain manage not only how resources should be allocated but also what information should be exported. A carrier may dedicate a set of small data centers (on multiple sites) to its certain customer. These data centers are put under a single SDN domain. The customer can manage the dedicated multi-site, small data centers via the SDN controller. Periodically the SDN controller collects network information from all data centers. However, different than the former unrestrictive case, the customer may have stringent privacy policies and therefore decide to aggregate the collected information before submitting to the ALTO server. For instance, the customer may aggregate the information for a data center network in the same site such that the data center network is shrunk into a single node; by doing so, the multi-site data center network is aggregated into a multi-node network topology, each node in the topology actually corresponds to a small data center in reality. The aggregated network topology could be annotated with available link bandwidth information or other information that is collected and allowed to be exported. The customer's information aggregation policy defines how the information should be pre-processed before exporting to the ALTO server. The main purpose of aggregation is to protect privacy. As a result of information aggregation, the exported network information could be a logical topology (annotated with various network information, e.g., distance or cost) which is totally different from the physical topology. 6.3. Information Aggregation Without SDN, ALTO defines cost maps for an aggregated view of the network topology, where the granularity of aggregation is determined by the network carrier and could be either coarse-grain or fine- grain. However, with the introduction of SDN, such information aggregation could be greatly simplified and should be policed based on the Xie, et al. Expires December 30, 2012 [Page 19] Internet-Draft ALTO Use Cases For SDN June 2012 policies defined for each SDN domain. For instance, ALTO only needs to collect information from a pre-defined set of SDN domain controllers, where the controllers determines at what granularity they would like to aggregate the information and export them. In addition, such aggregation is governed by the domain-specific policies, which defines not only the granularity of aggregation but also to whom such aggregated information may be exposed. More specifically, an illustrative use case is as follows. SDN controllers collect fine-grain information and aggregate it periodically per their policies. ALTO is configured to obtain the aggregated information from a set of SDN domain controllers and obtain possibly raw information from networking devices (or the network operation center). ALTO then constructs a complete view of the overall network (an aggregated view of the network). SDN controllers obtain cost maps from ALTO and apply such maps when making data/forwarding plane decisions. Another illustrative use case is as follows. SDN controllers may choose to export fine-grain information to ALTO. After it obtains the cost maps from ALTO, it could leverage the cost maps with greater details about their own domains and make informed decisions. However, SDN controllers should not overload ALTO by exporting too much fine-grain information. 7. Use Case for Downward Flow We illustrate the use of downward flow through several use cases as follows: Note that when the originating SDN domain's controller make decisions for choosing path(s) and set up the path(s), each involved SDN domain controller should map the overall decision to scoped decisions specifically for their responsible domains. 7.1. SDN-Aware QoS Metrics We use two use cases to describe SDN-aware QoS. When aggregating QoS information, SDN controllers or the information aggregation policies should understand the semantics of each QoS metrics. For instance, some metrics (e.g., delay) are additive, while some others are multiplicative (e.g., packet loss rate). The information aggregation policy should be flexible enough to specify such details. Xie, et al. Expires December 30, 2012 [Page 20] Internet-Draft ALTO Use Cases For SDN June 2012 7.1.1. On-Demand Bandwidth An SDN capable application / source end-point may request for a certain amount of end-to-end bandwidth to a destination end-point on the fly. The two end points in question should be in the same administrative domain, but they are not in the same SDN domain. The path(s) set up for such a request span across multiple SDN domains. The SDN controller of the source domain (i.e., the SDN domain where the source end-point is located), referred to as the source SDN controller, should first obtain the cost maps from the ALTO server. Such cost maps are SDN-domain-specific, namely, the costs are defined for pairs of SDN domains, rather than for pairs of end points as in the legacy ALTO case. The source SDN domain controller should then determine path(s) for the two end points based on the cost maps and associated information obtained from ALTO. More specifically, the controller should: o Compute a lowest-cost path at the SDN domain level using the obtained SDN-domain-specific cost map. o Contact the controllers of those SDN domains on the selected path, probing for the available bandwidth that could be dedicated to the requested session. o Check if all of the selected path have sufficient combined bandwidth that matches the required bandwidth. o if the combined bandwidth of all selected paths cannot match the requirement, then go back to step 1 and select another lowest-cost path (different than the already selected ones). * if no path can be selected and the combined bandwidth does not match the requirement, the request cannot be satisfied. o if the combined bandwidth of all selected paths match the requirement, then set up all selected paths by signaling all involved SDN domain controllers. Note that the signaling protocol and how to set up paths are beyond the scope of this document. Data backup and migration among data centers, which typically require bulk data transfers, is an example of on-demand bandwidth use case. Data centers may be managed by one or multiple SDN domains; thus bulk data transfer could be thought of as bulk data transfer among multiple SDN domains. Xie, et al. Expires December 30, 2012 [Page 21] Internet-Draft ALTO Use Cases For SDN June 2012 7.1.2. Delay Similar to the preceding use case, applications may request for paths satisfying some certain QoS metrics, e.g., VoIP applications may ask for paths with delay being lower than certain thresholds. This requires that ALTO cost maps embed such information, and that SDN controller should export such information to ALTO. 7.2. Content Delivery Networks (CDN) Content Delivery Network (CDN) has been widely deployed to help dissemination of content at the Internet scale. Network carries are also deploying CDNs inside their own networks to improve the user experiences of their customers. With the introduction of SDN, not only legacy CDN but also a new SDN-based CDN can be seamlessly implemented and integrated with the current network infrastructure. Here is an example of the flow of SDN-enabled CDN. Suppose that there are a set of CDN servers deployed in a carrier's network and they are willing to be managed by SDN. An equivalent class for each of the CDN server is defined by either the CDN carrier or the network carrier (these two carriers can be the same). An equivalent class is a set of IP addresses, one for a CDN server, where if one can be used to fulfill requests for a specific content, then any server in this class can also be used to serve the same requests. In the extreme case, there is only one equivalent class for all CDN servers. Then the pre-defined equivalent classes are pushed to the SDN controllers, which leverage such information to select CDN servers and set up paths for any end point to any such servers. o A network client (e.g., an HTTP-based Web client) obtains the IP address, referred to as A, of one of the CDN servers in the carrier's network (e.g., by DNS queries). o The client sends a first packet destined for A (for HTTP requests, this packet is a TCP SYN packet). o An SDN capable networking device picks up the packet. o If there are forwarding rules already set up for the communication between the requesting client and the destination A, then follow the rules to forward the request packet. o Otherwise, forward the request packet to the SDN controller of this domain. Xie, et al. Expires December 30, 2012 [Page 22] Internet-Draft ALTO Use Cases For SDN June 2012 o Once receiving a forwarded packet from a networking device, the SDN controller takes the following actions: * Retrieves the equivalent class for the given destination A. * Obtains a cost map from the ALTO server (this step could take place asynchronously). * Ranks all CDN servers in the equivalent class according to the cost map obtained from the ALTO server. * Selects the best CDN server, referred to as B, based on the above ranking. * Negotiates and sets up a best-effort path to the selected CDN server with other controllers. * Sets up forwarding rules for the path, and rewriting rules for replacing the IP address of A with the IP address of B (so that the client is actually communicating with B, although it may think that it is communicating with A; however, which server it communicates is not important). o The request packet is forwarded to the chosen CDN server B, subject to the forwarding rules and rewriting rules. o The client communicates with the CDN server B. o The path and associated forwarding/rewriting rules are expired when the communication is torn down (this step is irrelevant to the ALTO extension for SDN, therefore, it is out of scope). However, the above use case has two limitations. First, it violates the TCP semantics; namely, the client intends to and believes that it is communicating with server A, but actually it is communicating with server B. Second, it has to rely on the capability of devices being able to rewrite forwarding rules (e.g., use one IP address to replace another one in a packet). If the above two limitations become concerns, e.g., either TCP semantics should not be violated or rewriting is not available or both, the above SDN-enabled CDN use case can be implemented in similar way, with the help of a redirection server. Below we describe the steps that are different: o A redirection server (or server farm), referred to as R, is set up for redirecting client requests. Xie, et al. Expires December 30, 2012 [Page 23] Internet-Draft ALTO Use Cases For SDN June 2012 o Each SDN controller sets up path(s) to the given redirection server R. o Note that the redirection server could be an integral component of an SDN controller (either collocated or integrated), in which path(s) are not necessary. o Once receiving a forwarded packet from a networking device, the SDN controller takes the following actions: * Retrieves the equivalent class for the given destination A. * Obtains a cost map from the ALTO server (this step could take place asynchronously). * Ranks all CDN servers in the equivalent class according to the cost map obtained from the ALTO server. * Selects the best CDN server, referred to as B, based on the above ranking. * Sends the information of the chosen CDN server, i.e., its IP address B, to the redirection server R. * Negotiates and sets up a best-effort path to the redirection server R (if R is not integrated with the SDN controller). * Sets up forwarding rules for the path to R * Negotiates and sets up a best-effort path to the CDN server B. * Sets up forwarding rules for the path to B. o The client communicates with the redirection server R. o R sends an HTTP redirection packet to the client, redirecting future requests to the CDN server B (which is notified by the SDN controller). o The client communicates with the chosen CDN server B (note that the path to B has been already set up). 7.3. Information-Centric Content Delivery Networks (IC-CDN) Information-Centric Networking (ICN) is a "host-to-information" communication model, different from the legacy "host-to-host" model implemented by the Internet. Content Delivery Network (CDN) is more of a "host-to-information" model (i.e., CDNs can be treated as a Xie, et al. Expires December 30, 2012 [Page 24] Internet-Draft ALTO Use Cases For SDN June 2012 special instance of ICN), but implemented in the "host-to-host" model, due to the fact that the current semantics provided by the Internet only support the "host-to-host" model. With the introduction of SDN, CDNs can be converted into an information-centric networking implementation: o A CDN client sends a request for a specific content. o The request packet is formatted per the CDN in SDN specification (beyond the scope of this draft), containing: * the requested content name in the packet. * destination (a specific anycast IP address) which is reserved for legacy applications to invoke SDN capabilities. * (optional) QoS requirements (e.g., prefer fast/local servers vs. slow/remote servers, demands are elastic or not). o An SDN capable networking device picks up the request packet. o If there are forwarding rules set up for this content request already, then follow the rules to forward the request packet, and terminate this. o Otherwise, forward the request packet to the SDN controller for this domain. o The SDN controller communicates with the CDN's name directory to look up possible CDN servers that can satisfy the request. o The SDN controller obtains a cost map from the ALTO server. o The SDN controller applies the cost map to select the best CDN server per the QoS requirements if specified in the request. o The SDN controller negotiate the path to the selected CDN server with other controllers. o The SDN controllers that along the chosen path set up the path, and push the forwarding rule(s) for this chosen path to all networking devices that are involved. o The request packet is forwarded to the chosen CDN server. o Data packets flow back to the CDN client. Xie, et al. Expires December 30, 2012 [Page 25] Internet-Draft ALTO Use Cases For SDN June 2012 In this use case, the CDN clients could be modified to send the "information-centric" request. However, in a realistic implementation, neither the CDN clients nor the CDN servers have to be significantly modified (e.g., CDN redirection could be leveraged to implement the above work flow). 8. Conclusions In this draft, we identify the fundamental differences between legacy ALTO client/server and ALTO client/server with the existence of SDN. The introduction of SDN fundamentally changes the way that the ALTO works. We present the Vertical Architecture and the Horizontal Architecture to allow coherent coexistence of SDN and ALTO. We believe that the Vertical Architecture allows better division, management, flexibility, privacy control and long-term evolution of the network. Therefore we mainly focus on the Vertical Architecture in this draft. We also define the main interactions and information flows, and present a set of use cases to illustrate how we extend ALTO to support SDN, in the Vertical Architecture. 9. Contributors The authors would like to thank Vijay K. Gurbani for his many detailed reviews and helpful assistance on this draft. Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533 Naperville, IL 60566 USA Email: vkg AT (acm.org,bell-labs.com) 10. Acknowledgements The authors would like to thank Christos Kolias for his reviews and feedbacks, and thank Aditi Vira for editing the draft. 11. Security Considerations TBD. Xie, et al. Expires December 30, 2012 [Page 26] Internet-Draft ALTO Use Cases For SDN June 2012 12. IANA Considerations This document makes no specific request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 13. Informative References [1] Koponen, T., Casado, M., Gude, N., Stribling, J., Poutievski, L., Zhu, M., Ramanathan, R., Iwata, Y., Inoue, H., Hama, T., and S. Shenker, "Onix: A Distributed Control Platform for Large- scale Production Networks", Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI 10), Vancouver, Canada, pp. 351-364", October 2010. [2] Gurbani, V., Scharf, M., Lakshman, T., and V. Hilt, "Abstracting network state in Software Defined Networks (SDN) for rendezvous services, IEEE International Conference on Communications (ICC) Workshop on Software Defined Networks (SDN)", June 2012. Authors' Addresses Haiyong Xie Huawei & USTC 2330 Central Expy Santa Clara, CA 95050 USA Email: Haiyong.xie@huawei.com Tina Tsou Huawei (USA) 2330 Central Expy Santa Clara, CA 95050 USA Email: Tina.Tsou.Zouting@huawei.com Xie, et al. Expires December 30, 2012 [Page 27] Internet-Draft ALTO Use Cases For SDN June 2012 Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 84 Madrid, 28006 Spain Email: diego@tid.es Hongtao Yin Huawei (USA) 2330 Central Expy Santa Clara, CA 95050 USA Email: Hongtao.yin@huawei.com Xie, et al. Expires December 30, 2012 [Page 28]