| Internet Engineering Task Force | H. Xie |
| Internet-Draft | Huawei & USTC |
| Intended status: Informational | T. Tsou |
| Expires: July 13, 2013 | Huawei (USA) |
| D.R. Lopez | |
| Telefonica I+D | |
| H. Yin | |
| Huawei (USA) | |
| January 09, 2013 |
Use Cases for ALTO with Software Defined Networks
draft-xie-alto-sdn-extension-use-cases-01
The introduction of SDN fundamentally changes the way that the application layer traffic optimization (ALTO) works. This draft describes two architectures, the Vertical Architecture and the Horizontal Architecture, allowing coherent coexistence of ALTO and 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.
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 July 13, 2013.
Copyright (c) 2013 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 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.
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 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.
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.
This section provides a high level and conceptual overview of software defined network in order to help illustrate its unique requirements for ALTO.
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 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.
There are two types of applications in software defined networks:
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.
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:
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 [onix].
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.
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.
In this section, we first compare the ALTO scopes without and with the existence of SDN, and then describe two architectures for co-existing SDN and ALTO.
SDN incurs significant changes to ALTO scopes and clients. We describe the major differences below.
The existence of SDN differentiates two scopes of ALTO, namely,
We next focus on the SDN-friendly Scope and highlight the complex structures and the important differences.
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 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.
.----------------------------------------------. | ALTO Server | `----------------------------------------------' ^ | .-------------|------------|-------------------. | | V | | .-------------------------------. | | | SDN Controller | | | `-------------------------------' | | | | | | | | .-------------------------------. | | | SDN Capable Devices | | | `-------------------------------' | | | | An SDN Domain | `----------------------------------------------'
.---------------------------------------------------------------------. | .--------------------------. .--------------------------. | | | SDN Controller |〈----| ALTO Server | | | `--------------------------' `--------------------------' | `-----------------|---------------------------------------------------' | .-------------------------------. | SDN Capable Devices | `-------------------------------'
We now introduce two architectures that allow coherent co-existence of SDN and ALTO in this section:
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 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.
The interactions between SDN controllers (as ALTO clients) and ALTO servers are significantly different. 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 between the SDN controllers and the ALTO server can be divided into two categories. 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).
The downward interaction is the information flow from ALTO servers to ALTO clients (i.e., 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 available).
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.
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. Each SDN controller may collect 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.
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.
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.
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.
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 controllers to ALTO servers.
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):
We now give three examples to describe a complete work flow, which connects all key elements in an SDN.
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 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 effort fashion.
Legacy applications can be greatly simplified, as it is unnecessary and is not helpful for them to directly communicate with ALTO servers any more:
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.
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.
The information exchanged between the SDN domain controllers and the ALTO server is encoded and implemented by specific messaging mechanisms. Below we describe a preferred messaging mechanism where we focus mainly on the semantics of the messages.
Based on the ALTO services, there are two-way message exchanges between the SDN controller and the ALTO server. NBI is used and should be adapted to accommodate such message exchanges. The concept of SDN domain is enforced by the controller if its policy defines so; therefore, the controller can opt to export the relevant information at policy-specific granularities.
SDN Domain controllers can communicate with the ALTO server to negotiate any or all of the service information described in the next two subsections. After negotiation, such information can be pulled from or pushed to ALTO server depending further on the communication mechanism provided by NBI. Further, the detail mechanism of consuming the above information will depend on the types of ALTO services being offered and not be covered by this use case.
It is important to note that the vanilla ALTO service (i.e., cost map or path cost information) is no longer directly applicable to the context of co-existing SDN and ALTO.
In vanilla ALTO service scenarios, paths (i.e., routing between any pair of routers) are deterministic a prior, regardless of ALTO recommendations. However, in the context of co-existing SDN and ALTO, routing is to be determined based on many factors including ALTO. For instance, the routing between any pair of two SDN capable routers may not be fully determined when the SDN domain controller(s) query ALTO service for recommendations.
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.
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 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.
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.
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.
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.
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.
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:
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.
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.
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.
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:
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:
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).
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.
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)
The authors would like to thank Tom Taylor and Aditi Vira for editing the draft.
This memo is based upon work supported in part by the National Science Foundation of China (NSFC) under Grant No. 61073192 and the China 973 Program under Grant No. 2011CB302905. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of NSF.
TBD.
This document makes no specific request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.