Network Working Group Haiyong Xie Internet Draft Huawei & USTC Intended status: Informational Tina Tsou Expires: June 18, 2012 Hongtao Yin Huawei D. Lopez Telefonica I+D Christos Kolias Orange June 19, 2012 Use Cases for ALTO with Software Defined Networks draft-xie-alto-sdn-use-cases-00.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 19, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Xie, et al. Expires June 19, 2012 [Page 1] Internet-Draft Use Cases for ALTO with SDN June 2012 carefully, as they describe your rights and restrictions with respect to this document. Abstract This draft describes a general, umbrella use case that illustrates application layer traffic optimization with software defined networks. Unique requirements for design and operations are identified and summarized. Under this umbrella, this draft also elaborates three detailed use cases. In addition, extensions to the existing ALTO protocol are recommended. Table of Contents 1. Introduction ................................................... 3 1.1. Terminology ............................................... 4 2. An Overview of Software Defined Network ........................ 4 2.1. Software Defined Network .................................. 5 2.2. Division of Network ....................................... 5 2.3. SDN Domain ................................................ 7 3. Interactions between SDN and ALTO .............................. 8 3.1. The Current Scope (The "SDN-unfriendly" Scope) ............ 8 3.2. The New Scope with Existence of SDN (The "SDN-friendly" Scope) ......................................................... 8 3.2.1. ALTO clients ......................................... 9 3.2.2. Interactions between SDN and ALTO ................... 10 3.2.3. Interactions between Legacy ALTO Clients and ALTO Servers .................................................... 11 3.3. Summary .................................................. 11 4. Architecture .................................................. 12 4.1. Overview ................................................. 12 4.2. Work Flow of SDN Controller .............................. 12 4.3. Work Flow of Applications, SDN and ALTO .................. 13 4.3.1. SDN-aware Applications .............................. 13 4.3.2. SDN-unaware Applications ............................ 14 4.3.3. Legacy Applications ................................. 14 4.4. Summary .................................................. 15 5. Use Case for Upward Flow ...................................... 15 5.1. Unrestrictive Information Exporting ...................... 15 5.2. Restrictive Information Exporting ........................ 16 5.3. Information Aggregation .................................. 17 6. Use Case for Downward Flow .................................... 17 6.1. SDN-Aware QoS Metrics .................................... 18 6.1.1. Use Case: On-Demand Bandwidth ....................... 18 6.1.2. Delay ............................................... 19 6.2. Content Delivery Networks (CDN) .......................... 19 Xie, et al. Expires June 18, 2012 [Page 2] Internet-Draft Use Cases for ALTO with SDN June 2012 6.3. Information-Centric Content Delivery Networks (IC-CDN) ... 22 7. Security Considerations ....................................... 23 8. IANA Considerations ........................................... 23 9. Conclusions ................................................... 24 10. References ................................................... 24 10.1. Informative References .................................. 24 Authors' Addresses ............................................... 24 Contributors ..................................................... 25 Intellectual Property Statement .................................. 25 Disclaimer of Validity ........................................... 26 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. In particular, OpenFlow, as a representative SDN technology, has started to find its way into Data Center Networks (DCNs) and campus networks. Furthermore, In order to allow efficient and flexible implement 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 Xie, et al. Expires June 18, 2012 [Page 3] Internet-Draft Use Cases for ALTO with SDN June 2012 limited in portions of a bigger network (referred to as SDN domains). In other words, the operator of a large-scale enterprise / carrier network should divide the whole networks into multiple connected SDN domains, where each of such domains corresponds to a relatively small portion of the 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 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. The software defined interactions could be similar to OpenFlow or the like. 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 compatible 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., SDN free devices). Note that SDN free devices could be still SDN compatible. 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. Xie, et al. Expires June 18, 2012 [Page 4] Internet-Draft Use Cases for ALTO with SDN June 2012 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. 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 compatible. 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). 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. 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 compatible 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. Xie, et al. Expires June 18, 2012 [Page 5] Internet-Draft Use Cases for ALTO with SDN June 2012 The number of devices an SDN controller can feasibly manage is likely to be limited. Therefore, in order to manage a many 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-compatible 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-compatible); 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. Xie, et al. Expires June 18, 2012 [Page 6] Internet-Draft Use Cases for ALTO with SDN June 2012 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 / 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 compatible. 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 [2]. 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 connections among underlying devices belonging to different 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 Xie, et al. Expires June 18, 2012 [Page 7] Internet-Draft Use Cases for ALTO with SDN June 2012 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. 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. Interactions between SDN and ALTO 3.1. The Current Scope (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. 3.2. The New Scope with Existence of SDN (The "SDN-friendly" Scope) 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" 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 Xie, et al. Expires June 18, 2012 [Page 8] Internet-Draft Use Cases for ALTO with SDN June 2012 server provides information to the controller, as suggested by [1]. 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 section. Furthermore, the design originally for the compressed space could be instantiated for the unfolded space but could not be as efficient. We now highlight the complex structures and the important differences below. 3.2.1. 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 are network applications typically not owned by network carriers (there are cases where owned collaboratively amongst Xie, et al. Expires June 18, 2012 [Page 9] Internet-Draft Use Cases for ALTO with SDN June 2012 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. 3.2.2. 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. The interactions can be divided into two categories: o Information flow from ALTO clients to ALTO servers SDN controllers also 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 evitable 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 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. o Information flow from ALTO servers to ALTO clients Xie, et al. Expires June 18, 2012 [Page 10] Internet-Draft Use Cases for ALTO with SDN June 2012 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. 3.2.3. 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. 3.3. 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. We will subsequently illustrate the fundamental differences through two sets of use cases, one for the information flow from ALTO servers to ALTO clients, the other for the information flow from ALTO servers to ALTO clients. Xie, et al. Expires June 18, 2012 [Page 11] Internet-Draft Use Cases for ALTO with SDN June 2012 4. Architecture The preceding discussions on SDN and ALTO suggest we need to put both SDN and ALTO in a coherent architecture. 4.1. Overview According to the preceding discussions, SDN domains cover sub- networks of a carrier's network, while the ALTO server covers the carrier's network as a whole. Additionally, SDN domain controllers could collect more fine-grained information, while the ALTO server has only relatively coarse-grained information. Therefore, SDN domains should be put under the ALTO server. In addition, the two types of information flows between SDN controllers and the ALTO server suggest that the ALTO server needs inputs from SDN controllers as ALTO clients in order to disseminate ALTO information. Therefore, SDN domain controllers should be put under the ALTO server in the architecture. The architecture is a hierarchical architecture consists 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 a carrier. However, some of the SDN domains (and the networking devices in them) may be dedicated to certain customers of the carrier giving them privileges access. This is subject to a collaboration agreement among carriers. 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). 4.2. Work 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): Xie, et al. Expires June 18, 2012 [Page 12] Internet-Draft Use Cases for ALTO with SDN June 2012 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. 4.3. Work Flow of Applications, SDN and ALTO We now give three examples to describe a complete work flow, which connects all key elements in an SDN. 4.3.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) 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 Xie, et al. Expires June 18, 2012 [Page 13] Internet-Draft Use Cases for ALTO with SDN June 2012 o If the requested path(s) are successfully set up, the application's end point starts to communicate with the destination end points 4.3.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-compatible networking devices pick up these requests and forward them the SDN controllers. The remaining work flow is similar to the work flow 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 offer fashion. 4.3.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-compatible 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 o Communications between the two end points continue; the forwarding rules may expire if the communication is tore down Xie, et al. Expires June 18, 2012 [Page 14] Internet-Draft Use Cases for ALTO with SDN June 2012 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. 4.4. 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. 5. 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. 5.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 Xie, et al. Expires June 18, 2012 [Page 15] Internet-Draft Use Cases for ALTO with SDN June 2012 controller could periodically collect the available bandwidth on all links in its domain and submit it to the ALTO server. However, such 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. 5.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. Xie, et al. Expires June 18, 2012 [Page 16] Internet-Draft Use Cases for ALTO with SDN June 2012 5.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 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. 6. 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. Xie, et al. Expires June 18, 2012 [Page 17] Internet-Draft Use Cases for ALTO with SDN June 2012 6.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. 6.1.1. Use Case: On-Demand Bandwidth An SDN-compatible 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) Xie, et al. Expires June 18, 2012 [Page 18] Internet-Draft Use Cases for ALTO with SDN June 2012 o 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. 6.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. 6.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. Xie, et al. Expires June 18, 2012 [Page 19] Internet-Draft Use Cases for ALTO with SDN June 2012 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-compatible 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 o Once receiving a forwarded packet from a networking device, the SDN controller takes the following actions: o Retrieves the equivalent class for the given destination A o Obtains a cost map from the ALTO server (this step could take place asynchronously) o Ranks all CDN servers in the equivalent class according to the cost map obtained from the ALTO server o Selects the best CDN server, referred to as B, based on the above ranking o Negotiates and sets up a best-effort path to the selected CDN server with other controllers o 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 Xie, et al. Expires June 18, 2012 [Page 20] Internet-Draft Use Cases for ALTO with SDN June 2012 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 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: o Retrieves the equivalent class for the given destination A o Obtains a cost map from the ALTO server (this step could take place asynchronously) o Ranks all CDN servers in the equivalent class according to the cost map obtained from the ALTO server o Selects the best CDN server, referred to as B, based on the above ranking o Sends the information of the chosen CDN server, i.e., its IP address B, to the redirection server R Xie, et al. Expires June 18, 2012 [Page 21] Internet-Draft Use Cases for ALTO with SDN June 2012 o Negotiates and sets up a best-effort path to the redirection server R (if R is not integrated with the SDN controller) o Sets up forwarding rules for the path to R o Negotiates and sets up a best-effort path to the CDN server B o 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) 6.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 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-compatible networking device picks up the request packet Xie, et al. Expires June 18, 2012 [Page 22] Internet-Draft Use Cases for ALTO with SDN June 2012 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 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). 7. Security Considerations TBD. 8. IANA Considerations This document makes no specific request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Xie, et al. Expires June 18, 2012 [Page 23] Internet-Draft Use Cases for ALTO with SDN June 2012 9. 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 system works. We present an architecture that consists of ALTO client/server, SDN controller, SDN domain and SDN applications. We also define the main interactions existing in this architecture. We further describe ALTO-related work flows in this architecture. We then present a set of use cases to illustrate how we extend ALTO to support SDN. 10. References 10.1. Informative References [1] Gurbani, V.K., Scharf, M., Lakshman, T.V. and Hilt, V., "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. [2] T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, 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 Authors' Addresses Haiyong Xie Huawei & USTC 2330 Central Expy, Santa Clara, CA 95050 Email: Haiyong.xie@huawei.com Tina Tsou (Ting Zou) Huawei 2330 Central Expy, Santa Clara, CA 95050 Email: Tina.Tsou.Zouting@huawei.com Xie, et al. Expires June 18, 2012 [Page 24] Internet-Draft Use Cases for ALTO with 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 2330 Central Expy, Santa Clara, CA 95050 Email: Hongtao.yin@huawei.com 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} Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr Xie, et al. Expires June 18, 2012 [Page 25] Internet-Draft Use Cases for ALTO with SDN June 2012 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Xie, et al. Expires June 18, 2012 [Page 26]