Service Oriented Internet ¡ ¡ ¡ ¢ Jaideep Chandrashekar , Zhi-Li Zhang , Zhenhai Duan , and Y. Thomas Hou £ University of Minnesota, Minneapolis, MN 55455, USA, ¤ jaideepc,zhzhang,duan ¥ @cs.umn.edu ¦ Virginia Tech, Blacksburg, VA 24061, USA, [email protected] Abstract. Effective service delivery capabilities are critical to the transformation of the Internet into a viable commercial infrastructure. At the present time, the ar- chitecture of the Internet is inadequately equipped to provide these capabilities. Traditionally, overlay networks have been proposed as a means of providing rich functionality at the upper layers. However, they suffer from their own drawbacks and do not constitute a perfect solution. In this paper, we propose a novel, overlay based Service Oriented Internet architecture that is meant to serve as a flexible, unifying and scalable platform for delivering services over the Internet. As part of this architecture, we introduce a new two-level addressing scheme and an as- sociated service layer. We also describe the functionality of the new network ele- ments that are introduced, namely service gateway and service point-of-presence, and subsequently discuss algorithms that are responsible for distributing service reachability across the overlay framework. We also present a few examples of application services that benefit significantly when deployed on our architecture. 1 Introduction Over the last decade, the unanticipated popularity of applications such as the World Wide Web and E-mail has transformed the Internet into the de facto global information infrastructure that underlies much of today’s commercial, social and cultural activities. People rely on the Internet for a variety of services essential to their daily lives, ranging from communications and information access to e-commerce and entertain- ment. Because of this, many new requirements of Internet services are more critical and urgent than ever before. These requirements include service availability and reliability (i.e., “always-on” services), quality and security. In spite of this, the Internet is still essentially a “best-effort” entity with end-to-end connectivity being its only service of- fering. In its present form, this architecture cannot adequately support the requirements of emerging services. Various ad-hoc mechanisms have been proposed and deployed to address these different issues. Examples include the deployment of CDNs (content distribution networks) and the widespread use of Network Address Translation. How- ever, it is important to realize that ad-hoc solutions are by nature temporary short term § This work was supported in part by the National Science Foundation under the grants ANI- 0073819, ITR-0085824, and CAREER Award NCR-9734428. Any opinions, findings, and conclusions or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the National Science Foundation measures – they do not address the underlying problem, and in some instances simply shift the bottlenecks elsewhere. In this paper, we describe a new architecture — the “Service Oriented Internet” or SOI, which can be described as an efficient, generic and unifying framework for enabling the deployment of new services. In the design of the SOI architecture, we introduce three key abstractions: (1) the notion of a service cloud, which is a collec- tion of service entities that are deployed by a service provider. The simplest example would be a cooperating hierarchy of web proxy servers; (2) a new two-level, location- independent addressing scheme; and (3) a new abstract service layer that is used for forwarding packets to the appropriate service endpoints. The main contributions of this paper are two-fold. We first present a critique of the current Internet architecture, highlighting obstacles in supporting future requirements of applications and services. Secondly, we outline an architectural framework that ad- dresses these obstacles. We would like to think of our architecture as an evolutionary guideline that would enable the Internet to become a viable platform for the delivery of services. Specifically, the proposed architecture provides support for newer applications with service requirements beyond what can be currently realized. The architecture also introduces an economic framework which could be used to provide QoS support for applications that require it. 2 Service Oriented Internet In recent times, overlay networks have emerged as an effective way to implement func- tionality which otherwise would require significant change at the IP layer. Such net- works are appealing because they can be realized with very little infrastructure over- head. A set of end-nodes can decide to form an overlay, and cooperatively construct it, without any additional support from the network or the ISP’s. However, this transparency comes at some cost. First, by being completely oblivious of the underlying network layer, there are certain inefficiencies that cannot be avoided — very often, an overlay neighbor could actually be very far away in terms of the IP level network. Secondly, it might be that a particular overlay provides some service that is mandated on a well behaved underlying network. In the present case, ISP’s do not differentiate between packets that will be routed to an overlay (or packets being for- warded on an overlay network) and other packets. This could be to the detriment of the application. For example, in the instance of a multicast overlay used for conferencing, it is reasonable to expect that the overall experience would be benefited by some prior- itization of packets that are being exchanged on this overlay. If the packets meant for the overlay are similar to all the other transiting packets, there is no way to provide this service differentiation. Now, if we can imagine a situation where the ISP was in some sense “overlay-aware” and also that packets heading to the overlay could be identified, then it might be possible to ensure that a certain degree of service differentiation is pro- vided, leading to a better experience on the overlay. For this to happen, in a realistic setting, the ISP would need some economic incentive to actually do this. Third, if we were to imagine a number of overlay networks in operation (over the same underly- ing network), each of the overlays would be replicating some common functions. For example, consider a situation where overlay A provides a streaming video service and overlay B is used for multicast video conferencing. Since both overlays are dealing with real-time traffic, they probably involve some active measurement component, running independent of each other. A far more efficient architecture would decouple the active measurement component from the overlay operation and allow the different overlays to share the the measurement infrastructure. A similar idea has been discussed in [1], where the authors advocate a routing underlay that takes over the common tasks. The primary argument that we make through our architecture is that services can be deployed as overlays, but to address the performance limitations of the overlays and to ensure support for the requirements of newer applications, we also need an underlying infrastructure which addresses the shortcomings listed above. In the rest of the paper, we focus on the details of the infrastructure and how it can be realized. To make the description complete, we also use examples to show how specific services can be realized and supported over the infrastructure. 2.1 Overview In our architecture, we distinguish between the data transport networks, which roughly correspond to the existing autonomous systems (and the IP networks), and the service overlay networks (SON), each of which can be thought of as providing a well defined service. The role of the data transport networks is to provide bit-pipes as a service to the service overlay networks. The service networks, on the other hand, are designed to provide specific value- added services to subscribers. These networks are operated by service providers and can be visualized as clouds which interface at multiple points with the data networks. Client requests are routed over the data network to the nearest (or most appropriate) point of entry into a particular service cloud. The client’s request is then served from some host inside the cloud. This high level description is depicted in Figure 1, with the data networks shown towards the bottom of the figure and the service clouds near the top. The logical decoupling between the data network domains and the service networks allows the independent evolution of each, allowing for flexible deployment of future In- ternet services while still supporting existing services. This logical independence is an artifact of completely separating the addressing, routing and forwarding mechanisms in the two realms. A service cloud could implement each of the mechanisms indepen- dently, as best suits its needs. There are three elements that are key to this separation, namely: a new naming and addressing scheme that is a significant departure from the existing IP addressing scheme, service gateways (SG), and service points-of-presence (S-PoP). Each of these will be described in this section. 2.2 Key Abstractions The SOI architecture is built on top of the existing IP infrastructure, and provides a common platform for flexibly deploying new Internet services and effectively support- ing their diverse requirements. The architecture is based on three key abstractions, as follows. Fig. 1. Illustration of the SOI architecture. Service Cloud abstraction: A service cloud is a collection of service entities (e.g., servers, proxies, caches and content switches) that are deployed over the Internet (typ- ically at the network edges) to collectively and collaboratively provide a set of appli- cation/information services to users. It is a “virtual service overlay network” that is commonly owned and managed by a single provider or a consortium of application service providers, and it relies on the underlying IP data network domains for data de- livery across the Internet3.