Software Defined Networks (SDN): Leveraging network state for rendezvous services

Transcription

1 Software Defined Networks (SDN): Leveraging network state for rendezvous services Vijay K. Gurbani, Michael Scharf, T.V. Lakshman and Volker Hilt Bell Laboratories, Alcatel-Lucent Enrico Marocco Telecom Italia, Abstract The Software Defined Network (SDN) paradigm closely links networks and applications. By having access to network topology information, applications can optimize decisions related to service rendezvous, service fulfillment, service placement and service removal. The network is in the best position to provide guidance to a broad class of applications, including peer-to-peer systems, Content Distribution Network (CDN), and datacenter applications. In all these use cases proximity matters as peers need to rendezvous with other peers and users need to rendezvous with the best cloud application or best CDN server. We maintain that a solution for such a rendezvous problem should be an intrinsic component of the emerging SDN paradigm. An existing solution for applications to obtain rich information from the network is the Application Layer Traffic Optimization (ALTO) protocol. ALTO provides applications an abstract view of the network and thus enables applications to leverage a network without exposing the network provider s internal details or policies. We argue that that ALTO provides a clean, mature, standards-based, available and powerful abstraction that can be used by SDNs today to impart network state to applications. I. INTRODUCTION Software Defined Networks (SDN) are defined by the separation of the control plane from the packet forwarding plane [6], [9]. The control plane is realized as a network operating system that observes and controls the entire network state from a central vantage point. To realize forwarding and network-state abstractions, it has been proposed that SDNs use logically centralized control (e.g., NOX [7], Onix [8], Ethane[3]). A network operating system incorporating control plane functions, interacts with various network devices and presents an abstract view of the network state. A forwarding plane abstraction is used by the network OS for configuring flow tables, forwarding rules, etc. Network-function oriented applications, such as VLAN provisioning and load-balancing, can use these abstractions to achieve the desired network behavior without knowledge of detailed physical configuration. An alternative view of Software Driven Networks is proposed by Nadeau and Pan [11]. Here, SDN is defined a solution that enables applications to converse and manipulate the control software of network devices. Nadeau and Pan posit that applications possess limited knowledge of the underlying network or resource utilization on hosts in the network. Furthermore, since applications do not control the network, they have no impact on crucial decisions that they would like to affect at the network level such as load balancing, instantiating new virtual machines as the traffic towards a particular application increases, or removing existing virtual machines when demand subsides. In essence, Nadeau and Pan argue for a well-defined protocol that allows applications to interface with the network to benefit from network virtualization, programmability and monitoring. This north-bound interface could be combined with a hardware abstraction such as OpenFlow, but it can also mapped to existing mechanisms to configure and manage network elements. Clearly, the network and the applications that run on it are extremely synergistic. The applications can inform the network of desired behaviour (service-specific packet treatment, load at the application server) to have the network take proactive measurements (install new flow entries, instantiate new replicas). In the converse direction, the network can inform the applications of certain characteristics that will allow the application to behave more intelligently (network topology, routing costs, policies). In a broad sense, SDNs allow for this synergy to occur. SDNs have been envisaged as providing abstractions that extract simplicity from the network and reduce the need to master complexity when building applications that interact closely with the network [14]. SDN abstractions provide relevant information that applications can use to improve their functionality and provide the means for applications to specify desired network behavior without the need to be aware of network configuration details. The challenge is in developing the right abstractions that are useful for a large class of applications. Contribution: We posit that there is a class of applications, which we term as the rendezvous class, that can benefit from network introspection. Such applications are characterized by the simple requirement that a requesting application has a choice to pick one (or more) resources, and that these resources are available in the form of many replicas on the network. The choice comes down to which replica should the requesting application pick? In this paper, we argue that an abstraction that aids the building of rendezvous services is a fundamental abstraction needed in SDNs. This is motivated by the fact that rendezvous is intrinsic to content distribution, routing traffic to cloud services, enhancing peerto-peer services and various other widely-used distributed applications. We further argue that the network abstractions made possible by the Application Layer Traffic Optimization

2 (ALTO) protocol are very much in the spirit of the network state abstractions envisaged for SDNs, i.e, ALTO hides unnecessary detail of the underlying networks without unnecessarily constraining applications. The ALTO protocol is a well-defined and mature solution that provides the required information for the rendezvous-class of services in a SDN. The rest of this paper is structured as follows: we provide further motivation of the rendezvous application class driven from real-life example services (Section II). We then look at the ALTO protocol in detail (Section III). Section IV shows wherealtofitsinthesdncontinuumandsectionvoutlines how the ALTO abstraction in SDNs can be used in the rendezvous problem for a wide variety of applications. We conclude in Section VI. II. THE Rendezvous CLASS OF APPLICATIONS We present three motivating examples driven from the need of a requesting application to choose a resource, given that the the requesting application has a multiplicity of resources to choose from. A. Peer-to-peer applications In peer-to-peer networks, content is disseminated by caching it at various points in the network. Some peer-to-peer networks, exemplified by BitTorrent, also allow peers to exchange pieces of the content in an incremental fashion until a peer has reformulated the entire content. In many cases, it is advantageous for a requesting peer to choose candidate peers that are topographically in close proximity to it. However, the requesting peer does not possess a global view of the network topology to authoritatively decide which candidate peer is close to it. Thus, in the absence of such information, the requesting peer randomly picks a candidate peer, which may result in lower quality of experience exhibited by a delay in downloading the entire content. B. Content distribution networks (CDN) CDNs deliver content from the servers that are closest to the end user in order to minimize latency and packet loss (thereby increasing the quality of experience). The rapid growth of streaming video on the Internet coupled with many devices capable of receiving this content directly (IP TV, tablets, laptops, mobile phones) have resulted in content being cached deeper into the network to be ever closer to the end user. There are many different ways a CDN can obtain topological information to allow it to rendezvous an end user with the closest cache: static configuration, public looking glass servers, passively listening to routing protocols and actively probing the underlying network are some heuristics in wide use. When CDN servers are deployed sparsely in a network, a simplified view of network topology suffices to allow the surrogate to serve end users optimally. However, as CDN servers are deployed increasingly deeper into the network, more detailed knowledge of the underlying network topology and costs associated with routing packets is required to best serve the end users [12]. C. Datacenters Rendezvous services are also common in cloud computing, which provides on-demand resource provisioning from multitenant virtual datacenters. In these datacenters, an overall control and management of network, processing, and storage resources is required. On can distinguish public clouds that are offered by a service provide over the Internet, private clouds that are operated by an enterprise, and virtual private clouds that are offered by a service provider with access over a L2 and/or L3 Virtual Private Network (VPN) as a combination of both [10]. Depending on that class there are different rendezvous challenges: A public cloud offer is similar to a CDN, as discussed in the previous paragraph. Users can get better service when they are served by the closest datacenter, which requires a load balancing scheme similar to a CDN. Furthermore, the users expect their services follow them as they move. Inside a given datacenter or private cloud, there is a combined rendezvous problem for processing, storage, and networking. A user wishing to use a particular application in a datacenter would like to not only be connected with the nearest server, but also require that the server be lightly loaded or else a new replica created to handle the user. Finally, a virtual private cloud has some similarity to the rendezvous challenge in peer-to-peer applications, since the VPN corresponds to an overlay topology. Having information about the underlay topology and proximity thus helps to optimize the traffic distribution and load balancing inside the overall cloud system. III. THE ALTO PROTOCOL The ALTO protocol is a distillation of contributions from several sources, prominent among them being P4P [15]. In July 2011, the IETF hosted the first ALTO interoperability event. There were seven implementations, a majority of which passed most of the interoperability test cases 1. Syntactically, the ALTO protocol is based on HTTP and uses a RESTful interface. The protocol encodes message bodies in JSON [4]. It is on track to become a Proposed Standard RFC, and is currently specified by Alimi et al. [2]. A. The core ALTO abstractions The ALTO protocol operates on two abstractions: a network map and an associated cost map. The network map results from a mapping between an endpoint identifier (typically an IP address, but MAC addresses and generic identifiers are also permitted) in a network to a coarse network location identifier called a partition ID or PID. The PID is an identifier that provides an indirect and network-agnostic means to specify a network aggregation(subnets, a set of subnets, or a metropolitan area network, etc.) There are various ways of grouping the endpoints and assigning PIDs to indicate proximity and improve scalability. These PIDs represent vertices in a graph, and the edges joining these vertices comprise the cost map. Thecost mapcan beviewedasanadjacencymatrixcontaining 1 Pleaseseehttp:// for detailed results from the interoperability event

3 IV. THE ALTO SDN ABSTRACTION We now show where ALTO fits in the SDN continuum. Fig. 1. Simplified ALTO architecture path costs among PIDs. Path costs are generic costs and can be internally computed by a network provider according to its specific needs. These two abstractions is all that is needed to allow richer rendezvous services that depend on network topology and associated costs to occur: an application simply computes the shortest path (or least costliest path) from itself to a resource replica, which consequently becomes the preferred replica for that application. The network provider can change the topology and resulting costs at will; all the application has to do is to recompute the shortest path to benefit from the network reorganization. Figure 1 shows a simplified ALTO architecture of a network containing three PIDs. The network map shows the aggregation of the hosts into PIDs and the cost map depicts a path-cost adjacency matrix. B. ALTO extensions In addition to the map and cost abstraction, the ALTO protocol supports retrieving properties of an endpoint(the PID it resides in, its connectivity type) and a filtering service that returns a subgraph of the complete network topology graph and a subset of the cost matrix. Finally, the ALTO protocol supports extensions to allow more complex rendezvous services to be realized as well. For example, some rendezvous services will depend on a path being lightly occupied or a host s service input queue being relatively empty. Historical statistics related to these metrics can therefore be maintained (and refreshed periodically) and disseminated to applications through the ALTO protocol. The multi-cost extension[13] outlines the primitives to disseminate historical statistics towards applications for richer rendezvous services. C. Operational ALTO The ALTO server is operated by the network service provider, who is the authoritative owner of the network as well as the administrative entity that is aware of the routing costs between points in the network and towards other network providers. The network provider can easily abstract this information in the form of the ALTO maps and distribute it to any content service provider who is interested in solving the rendezvous problem. A. SDN architecture Figure 2 depicts our view of an SDN architecture. Logically, SDN enables applications to query and customize the network via a north-bound API. The north-bound interface is provided by one or more SDN controllers that abstract the network state and orchestrate the network elements. The actual configuration and management of the state in the network elements is performed by south-bound interfaces. These interfaces can be provided by existing control and management mechanisms, or by new protocols such as OpenFlow. Given these different choices, interoperability can be realized by plug-ins that map the functions [11]. The SDN north-bound interface should provide both information and a certain level of control. As illustrated in Figure 2, this programmability requires a bi-directional interaction. Specifically, it is not sufficient for SDN applications to simply query network state and change it; the network must also be able to trigger actions of SDN application (as a reaction to failure events, for example). SDN applications, in turn, may also have to provide information such as constraints or security credentials (for example in case of inter-domain use). The key challenge for the north-bound interface is to achieve the right level of abstraction. If SDN applications have todealwithall specificdetailsofnetworkelements,thereisno benefit compared to existing network control and management mechanisms. B. SDN abstraction offered by ALTO Oneof thecore functionsofan SDN controlleris to abstract the network topology, networking constraints (such as routing costs), historical statistics related to bandwidth use, packet drops or queue length statistics, etc. SDN applications can then operate on this abstract view of the network state. As explained in Table I, ALTO is designed precisely to impart such abstraction of network information. Being RESTful, it is both simple to integrate in applications and flexible to extensions. ALTO can also be extended to support events and asynchronous notifications. Fig. 2. The ALTO SDN abstraction

4 TABLE I OVERVIEW OF SDN FUNCTIONS OFFERED BY ALTO SDN primitive Abstraction Get network topology Get network resources Get device capabilities Event notifications ALTO equivalent Aggregation into PIDs Generic cost types and ranking Map service, providing both network maps and cost maps Cost maps, optionally extended by multi-cost maps and historical statistics Endpoint property service Publish-subscribe service Legend: Currently not part of the core ALTO protocol This leads credence to our key argument in Section I that ALTO is very much in the spirit of the network state abstractions envisaged for SDNs. We argue that ALTO is naturally predisposed to providing network information for an SDN north-bound interface in a functionally clean manner. Furthermore, this ALTO SDN solution can be complemented by other protocols to provide additional network configuration and control functions for SDN as desired. V. ALTO SDN BENEFITS AND LIMITATIONS In order to underline the suitability of ALTO for SDN, we analyze in the following how different classes of rendevous application can use SDN mechanisms. Note that in all of the use cases discussed below, there are two natural entities: the content provider and the network provider. The former requires a simple abstraction of the network state in order to build services while the latter is charged with maintaining the complexity inherent in the network. The ALTO SDN abstraction allows both of these actors to fulfill their roles. A. Peer-to-peer applications The ALTO SDN abstraction allows a requesting peer to converge to a set consisting of the closest peers to contact while keeping the policies of the network service provider in mind (i.e., minimize transit links while maximizing peering ones).todoso,thebittorrentclientqueriesatrackertogather candidate IP addresses, or it will collect a set of candidate IP addresses through the distributed hash table. This is the normal mode of operation for a client. However, once the candidate set has been gathered, the BitTorrent client retrieves the topology and cost maps from the ALTO server. Armed with these maps, the client trivially performs least-cost routing to choose peers that are in close proximity. An alternate architecture that eliminates any source code changes in the client is to perform filtering at a tracker proxy. In such an architecture, the client uses the tracker proxy, which in turn, contacts the real tracker. The tracker proxy uses the ALTO SDN abstractions to prune the candidate list of peers deemed to be costly. From an SDN perspective, the difference between both modes is that in the former case a large number of peers would use the north-bound interface, whereas in the latter case the north-bound interface is only used by a smaller number of potentially well-defined tracker applications, resulting in less scaling and security issues. However, we note that the ALTO SDN abstractions are able to easily support both of these modes of operation of a peerto-peer system. Finally, it is not immediately obvious whether peer-to-peer applications can efficiently use additional more complex SDN functions. Peer-to-peer swarms are typically highly dynamic and can select from a large number of replicas. As a result, potential SDN functions such as customized routing do not offer a significant benefit when compared to what is already achieved at application level by peer selection strategies. In summary, for this class of applications it may be sufficient for SDNs to simply offer a view of the network state. B. Content distribution networks CDNs are an example of an important existing use case that closely links network and application functionalty as envisioned by SDN. The main use case for an ALTO SDN abstraction in CDN is to improve the selection of a CDN surrogate (cache server) or an origin server. As CDN servers get deployed deeper into the network, the CDN content provider requires better abstractions to effect a good rendezvous. Information about the network topology and routing policies helps to better serve different CDN deployment scenarios [12]. In the ALTO SDN abstraction, the CDN request router can use the SDN north-bound interface to obtain topology and proximity information to rendezvous the user with the best surrogate. CDNs may also want to impact the network behavior, for instance to prioritize the delivery of certain content types. This could be a control feature for a corresponding north-bound SDN interface. We note that there are other existing alternatives to accomplish this (e. g., DiffServ packet markings). C. Datacenters Networks inside datacenters and in general cloud computing are one of the most apparentuse cases for SDN. A cloud computing management software requires access to three different networking mechanisms (see e. g. [10]). First, connectivity has to be ensured inside the datacenter, towards customers, and potentially between datacenters if sites are distributed. A crucial problem here is to correctly configure the VPNs, e. g., VLANs, Ethernet Provider-Backbone Bridging(PBB), or other Layer 2 or Layer 3 VPN technologies. Second, additional networking functions such as load balancers or firewalls have to be set up appropriately. And third, network virtualization in multi-tenant environments may require Quality-of-Service (QoS) mechanisms such as traffic policing or bandwidth reservations. All three functions are an inherent candidate for SDN interfaces. Moreover, all three require some knowledge about the underlying network topology and its characteristics. The SDN ALTO abstraction is therefore a key component of a datacenter SDN solution and well suited to provide the information needed for the resource management and load balancing inside a datacenter and across data centers. As we note

5 in Section II, there are different datacenter usage scenarios; the ALTO SDN offers provides value to all of them. First, in a public cloud the global assignment of customers to data centers can benefit from an ALTO SDN interface. To a certain extent,this case is similar to rendezvousinga user with a CDN surrogate. Second, the network topology information inside a datacenter or private cloud can be provided and exchanged by the SDN ALTO abstraction. Having access to the full network topology and attendant costs can act as an enabler for an SDN application to optimize routing in a centralized way (thus complementing or replacing the existing distributed routing schemes). Finally, the SDN ALTO abstraction could be used in virtual private clouds for optimizing the use of datacenter interconnection links. Most notably, the network provider can enforce policies to the network map and cost information thereby encouraging the cloud operator to use network links that may not otherwise be preferred by the normal routing algorithms. This allows for better resource allocation and load balancing in the data center sites. We note that an SDN ALTO abstraction is not the only possible solution. For instance, inside one domain, Anycast [1] can be a viable alternative for determining which replica to serve a request from. Unlike Anycast, the abstraction principle of ALTO offers a highly flexible solution that is scalable beyond one domain. Furthermore, a datacenter SDN application may also have to configure and modify network state, for instance, to set up or tear down VPNs, to configure firewalls, encryption, load balancing, and address mapping, or to enforce QoS policies. A north-bound SDN interface encompassing all those functions isstill tobedefined,butit wouldwellcomplementtheservices already offered by the ALTO SDN abstraction. VI. CONCLUSIONS ThispapermakesacasethattheALTOprotocolisasuitable tool in the SDN framework. The fundamental motivation of SDN is to extract simplicity [14] from the network when building applications that interact closely with the network. We believe that ALTO provides a clean way to extract this simplicity in the form of two simple yet powerful maps the network map and the cost map and allow the applications to use them for varied purposes. In essence, ALTO provides a succinct getx() API, where X is an artifact related to network state(topology, resources, or device capabilities). This level of abstraction appears to be sufficient for a diverse set applications that are able to use this API to perform a wide range of services (Section V) without being hindered by the complexity of the underlying network. The ALTO abstraction does not aid in the reverse direction, where an application would like to influence the network for some action, but this is inherent in the design of ALTO. There are other gaps as well, for example the publish/subscribe paradigmin networkingapis [5] is not enabled by ALTO, nor does the core ALTO protocol provide information that may allow a SDN controller/orchestrator to create new resources or deactivate old ones. Finally, a SDN application may want to impart some state to the controller (queue lengths, CPU usage, etc.) but the core ALTO protocol does not support these, though there are extensions [13] that augment the core protocol and allow such information to flow to the controller. However, what ALTO does provide is a powerful abstraction at the network level that makes it trivial to enable a large class of rendezvous-type of services. The proposal described in this paper is a preliminary but informed look at approaching a part of the SDN abstraction using a novel and standards-based protocol. Our hope is that the use of such standardized protocols will aid in the evolution of the SDN. We hope to engage the broader community to solicit feedback on our approach as we continue our work. REFERENCES [1] J. Abley and K. Lindqvist. Operation of Anycast Services. RFC 4786 (Best Current Practice), Dec [2] R. Alimi, R. Penno, and Y. Yang. ALTO Protocol. IETF Internet-draft (work-in-progress), draft-ietf-alto-protocol-10, October [3] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker. Ethane: taking control of the enterprise. SIGCOMM Comput. Commun. Rev., 37:1 12, Aug [4] D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). RFC 4627 (Informational), July [5] M. Demmer, K. Fall, T. Koponen, and S. Shenker. Towards a modern communications API. In Proceedings of the Sixth ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets-VI. ACM, [6] K. Greene. 10 Emerging Technologies, TR10: Software Defined Networking, [7] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker. Nox: towards an operating system for networks. SIGCOMM Comput. Commun. Rev., 38: , July [8] 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. In Proceedings of the 9th USENIX conference on Operating systems design and implementation, OSDI 10, pages 1 6. USENIX Association, [9] B. Lantz, B. Heller, and N. McKeown. A network in a laptop: rapid prototyping for software-defined networks. In Proceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets 10, pages 19:1 19:6, New York, NY, USA, ACM. [10] D. McDysan. Cloudbursting use case. IETF Internet-Draft (work-inprogress), draft-mcdysan-sdnp-cloudbursting-usecase-00, October [11] T. D. Nadeau and P. Pan. Software Driven Networks Problem Statement. IETF Internet-Draft (work-in-progress), draft-nadeau-sdnproblem-statement-01, October [12] B. Niven-Jenkins, G. Watson, N. Bitar, J. Medved, and S. Previdi. Use cases for ALTO within CDNs. IETF Internet-Draft (work-in-progress), draft-jenkins-alto-cdn-use-cases-02, December [13] S. Randriamasy and N. Schwan. Multi-cost ALTO. IETF Internet-Draft (work-in-progress), draft-randriamasy-alto-multi-cost-05, October [14] S. Shenker, M. Casado, T. Koponen, and N. McKeown. The future of networking, and the past of protocols. Keynote at Open Networking Summit, October [15] H. Xie, R. Y. Yang, A. Krishnamurthy, Y. G. Liu, and A. Silberschatz. P4P: Provider Portal for Applications. ACM SIGCOMM Computer Communications Review (CCR), 38(4): , Oct