Service Orientation Paradigm in Future Network Architectures

2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing Service Orientation Paradigm in Future Network Architectures Rahamatullah Khondoker, Abbas Siddiqui, Bernd Reuther, Paul Mueller Integrated Communication Systems University of Kaiserslautern 67663 Kaiserslautern, Germany {khondoker, siddiqui, reuther, pmueller}@informatik.uni-kl.de [4]. Thus the Internet has become a complex system where it is hard to predict how does modification of one protocol or functionality affect the overall system. For example the many issues considered by the IETF IPv6 working group reflects this complexity [5]. Since, major changes of the Internet seem to be impossible, especially within a short time-line, disruptive new features are deployed in overlay networks. But without support of the network the efficiency of overlays is limited. In addition, overlays are usually designed only for a specific purpose such as file sharing, telephony, video-broadcasting, and are typically not open for arbitrary extensions or reuse. Hence overlays are no suitable alternative for a generic network infrastructure like the Internet. Thus, there is a need of rethinking network architecture in general [6]. This article presents basic concepts of network architectures based on the service orientation paradigm. The main goal is to develop a flexible network architecture which can be adapted to changing requirements and network capabilities as well as to integrate new functionality easily. Section II describes how software architecture principles can be used in future network architecture(s). In section III, general requirements of service oriented network architecture have been explained, section IV explores few research approaches on future network architecture and their compatibility with SOA concepts. In section V, some challenges are being discussed which could be faced while implementing SOA concepts in a future network architecture. Abstract—The Internet can not keep up with changing application requirements and new network technologies as its network architecture makes it hard to introduce new functionality because existing functionalities in the Architecture are inherently tightly coupled. This article describes how the principles of Service Oriented Architecture (SOA) can help to develop more flexible network architecture. We argue that the SOA paradigm can be applied to networks by utilizing the concepts of self-contained building blocks, dynamic protocol graphs and selection and composition methods. In order to make use of flexible networks, applications must be decoupled from the protocols they use. We give a brief overview, of how some of these concepts are already implemented, by presenting few approaches. Finally we describe some challenges of service oriented network architecture. I. I NTRODUCTION The Internet today faces many problems like security threats, rare support for mobility and multihoming, limited QoS capabilities, low efficiency for bulk data or the address space depletion [1]. The issue is not that researchers and developers are unable to solve such problems in general, but it is hard to change core mechanisms of the Internet. This so called ossification can not be solved by changing one or few existing protocols. The problem originates from the the fundamental organization of network functionality, their relationship and the lack of design and evolution principles, which are architectural [2] issues. The Internet architecture is organized as a layered system, where each layer enhances and abstracts functionality of lower layers. Accordingly, interface between layers should define the relationship of functionality. There are no universally accepted evolution principles of the Internet. But the OSI reference model, which is also a layered system, defines that it should be possible to modify or even exchange the implementation of a layer without the need to adapt to adjacent layers [3]. In today’s practice, there are a plenty of layer violations in the Internet, because of dependencies among protocols of different layers. For example UDP is aware of IP header and routers are aware of transport protocols. The relationship among functionality is mostly implementation dependent, because there are only few defined interfaces between layers, namely layer 2 functionality is offered via network adapters and transport functionality is offered via BSD socket or similar APIs. Also the evolution of the Internet “depends on rough consensus about technical proposals, and on running code” 978-0-7695-4684-1/12 $26.00 © 2012 IEEE DOI 10.1109/IMIS.2012.30 II. U SING S OFTWARE E NGINEERING TO B UILD N ETWORKS Current Internet is facing similar problems to Software Engineering (SE). It has evolved to manage complexities (e.g. maintenance, integration of new functionality, time and task management) of development process, which has direct affect in terms of cost, quality, development time. Similar kind of problems is part of the Internet which have not been addressed in the current design principle(s) of the Internet. As Internet has not been evolved with the change of trends, which made it victim of increased complexities. To deal with inflexibility and complexity issues of the Internet, we can learn and implement principle(s) and technique(s) from software engineering. The focus of the article is limited to the scope of SE architecture. 346 Software engineering architecture has advanced from structured programming till service oriented paradigm (SOP). The design of a future network architecture can benefit from software engineering architecture paradigms to make network architecture more flexible and easy to maintain rather than having an ossified architecture (e.g. Internet). In this section it will be argued how service oriented paradigm can be one of the suitable methodology for a future network architecture. Before arguing about why SOA could be a promising paradigm for a future internet, it will be helpful to describe fundamental principles [7] of SOA, which are following.                 1) Loose coupling: Coupling refers to the degree of dependencies and bounding between two components. Loose coupling defines independence of a service; where in order to execute own functionality, a service does not require to have a knowledge about other services. 2) Service contract: A communication agreement which is covered by service description(s) or related documents. 3) Autonomy: Control of a service over the logic it encapsulates characterize the autonomy. 4) Abstraction: Services are independent in logic they use and it is hidden from the outside world. 5) Reusability: A service should be independent and fine-grained enough thus reusability can be promoted. 6) Composability: An ability of a service to be coordinated to other services in a manner that they can form a composite service. Composability fosters reusability of a service. 7) Statelessness: A property in which services do not keep the state after request has been processed. 8) Discoverability: A Service should be descriptive enough to easily be discovered.               Fig. 1. Network functionality is inherently distributed in contrast to services on application level. of composability fosters ease integration of functionality. Nevertheless, statelessness principle of SOP might not be appropriate for all functionality of a network architecture as some functionality of network do require to keep the state (e.g. reliable transmission). III. S ERVICE O RIENTED N ETWORK A RCHITECTURES Now the question is: how to apply the SOA paradigm on networks? Implementation of SOA paradigm like WebServices is designed for the interplay of distributed autonomous functionality on application level (Figure 1 a). Network functionality like routing, data encoding or flow control itself is inherently distributed (Figure 1 b). Thus network architectures can not use same implementation like web-services and because of efficiency issues it wouldn’t be appropriate either to process exhausting meta tagging.This section provides an overview of such concepts, while section IV provides brief description of approaches implementing these concepts. Most of the issues in the Internet arise because of inflexibility and rigidness of the network architecture, which is built upon a protocol stack. Service oriented paradigm can provide new prospect to build a future network architecture as it addresses loose coupling, reusability and autonomy of a service, which are fundamental requirements of a flexible architecture. Protocol stack can be decomposed into a set of functionalities which are described with formal contract (i.e service description) which makes functionality autonomous and self-descriptive. Self-descriptive functionality has the ability to be discovered as it carries attached description which can be searched and processed by the searching entity. Abstraction should be taken into account while decomposing stack into various functionalities so that it should be at the abstract level where it does not rely on a particular implementation, thus, logic can be hidden from a consumer point of view. Characteristics of a functionality ,such as autonomy, description and reusability, makes it composable. Concept A. Concepts of SOA in Network Architecture Services are the essential elements of a SOA. A service reflects the effects of an activity rather than algorithms and data structures, i.e. a service represents a higher abstraction level since different algorithms may implement the same service. It is necessary that there are explicit service descriptions. Such a description includes the semantic of services and a definition of their interfaces. For example, Web-Service uses WSDL for interface specifications but does not define how to describe service semantics. A building block is the implementation of a service. A Micro-protocol(MP) can be an example of a building block such as retransmission MP, data encryption MP, Monitoring MP. Usually, each building block has several effects, for instance, reliable data transmission or confidential data transmission. But, there are also effects like increasing the end-to-end delay or reducing the maximum payload size. All the effects of a building block represents their covered 347 Without a predefined protocol graph, it must be determined which building blocks should be used and how these building blocks have to interact in order to provide a communication services. This process is called selection and composition 2 of building blocks (figure 3). The basis for selection and composition are the service descriptions of the available building blocks. The goal is to define an optimal protocol graph with regard to application requirements, network constraints and administrative policies. Several approaches for selection and composition are possible, ranging from manual defined protocol graphs to automatic composition at runtime. services. The interfaces of a building block should reflect the provided service and hide the implementation details to provide the abstraction property. Building blocks should also use generic interfaces (i.e. as used in Web-Services) so that interaction between building blocks does not require extra adapters. A new network architecture should be flexible by two ways. Firstly, networks should be able to adapt to specific customer or application needs and changing environmental conditions. Secondly, networks should be able to evolve, i.e. to add, change and even remove functionality. This flexibility is achieved by composing several fine-grained services to a more complex and specialized service. In today’s networks, complex protocols are organized in layers, building a static protocol graph ([8]). Service oriented network architectures aim at supporting dynamic composition of services, i.e. dynamic protocol graphs1 . Without being dependent on a static protocol graph it is easier to make use of new protocols (i.e. building blocks) and to reuse functionality on different levels. Having dynamic protocol graphs implies that there is no static placement of functionality as defined by the layers of the OSI reference model (see Figure 2). Thus, such networks will be layerless such that compression or encryption can be used for application payload only or also for some protocol headers. Furthermore it is not necessary that protocols are processed in a sequence, for example there might be different branches in the protocol graph to handle different but related data types within one flow, e.g. signaling and streaming media. In order to enable dynamic protocol graphs, the interaction between building blocks is not defined by the executable code, but by description which can be easily changed.                 Fig. 3.     Parameters for the definition / generation of workflows It is likely that flexible networks will offer several similar communication services to applications which might be implemented with different protocols. In such a scenario applications must not be aware of the implementation of protocols. To achieve this, applications must only be aware of the provided service while the selected implementation remains transparent for applications. This can be achieved by introducing a service broker which selects an appropriate service implementation at runtime (see Figure 4). A service is suitable to use if it fulfills all mandatory application requirements. In addition, services may differ regarding optional requirements which are used to determine the optimal service. A service broker might consider services provided by different sources. There may standard protocol stacks, precomposed services as well as dynamically composed services. This way a service broker also enables the simultaneous use of concurrent selection and composition approaches. B. SOA Principles in Networks The basic concepts of a service oriented network architecture described supports a service oriented design. Using a service as the basic element for the design of a system instead of algorithms or protocols foster loose coupling and abstraction. Service descriptions represent the service contracts and are also used to discover services. Building blocks should be largely independent of its environment to achieve autonomy. Generic interfaces of building blocks assist in the composition process. The layerless architecture implies higher probability for reuse of functionality which can be achieved by defining and using fine-grained services. Absolute statelessness can not be achieved in general because some functionality can be implemented only using statefull services. In addition there may be generic states, e.g. for the connection setup or release phase or states for failure or debug modes. IV. E XAMPLES OF S ERVICE O RIENTED N ETWORK A RCHITECTURES In this section, we briefly present some approaches for alternative network architectures and show how they implement some of the basic SOA concepts introduced earlier. Some of these approaches did not aim at developing a service oriented network architecture but implement the basic concepts nevertheless. C. Service composition and service selection In order to make use of flexible networks as mentioned above, it is necessary to define protocol graphs (i.e. execution and data flow of connected building blocks) and to select a communication service to be used. 1A      2 Often also the term “functional composition” is used, which implies that all building blocks can be represented as functions. protocol graph corresponds to workflows in SOA terminology. 348       Fig. 2.                    Layer vs. Service Oriented Paradigms            !               provides a Netlet execution environment intended for communication endpoints. In NENA, selection and composition of functionalities are done during design time. SONATE is also a node architecture aiming at high degree of flexibility by defining and providing fine-grained services and their composition possibility during design time, partial runtime or runtime for making a protocol graph. During the protocol graph composition, suitable and the best functionalities are selected and used in SONATE.   B. Implementing SOA Concepts Fig. 4. Selecting an appropriate communication service at runtime All of the approaches mentioned above basically make use of the building block concept. The common approach is to reuse “smaller elements” to create complex service(s). The granularity of the building blocks is not defined. For example in RBA a role may be a fine-grained functionality (e.g. a sequence counter) as well as a complete protocol like TCP. But in order to foster reusability fine-grained functionality is preferred. An exception is RNA, which encapsulates functionality in a so called meta protocol which builds up a layer. In this case considering fine-grained functionality will lead to too much overhead because of the recursive use of the metaprotocol. However, not all approaches rely on a static protocol graph. In RNA and SILO approach, functionalities are layered or sequentially ordered. But, the usage of the functionality and its ordering can be defined as needed, i.e. also RNA and SILO can be considered as a layerless approach in the sense of a given placement of functionality. All other mentioned approaches, in principle, allow arbitrary protocol graphs and thus are also layerless. This is not suprising because, to achieve greater flexibility and to overcome the limitations of today’s layered architecture is a common goal of the research in scope of future network architecture. Methods for selection and composition, i.e. defining a protocol graph, are not considered by all approaches. In the SILO, selection and composition is defined by a sequence of services based on an ontology. NENA requires that selection and composition is done at the design time, so that the process can be controlled or even can be performed by a human. The composition result is deployed a priory to all relevant nodes. SONATE accepts a description of a protocol graph (i.e. called workflow) as an input. This way arbitrary selection and composition methods can be used within SONATE. A. Brief Summary of Network Architecture Approaches Several approaches for a new network architecture have been introduced in the last years which aim on providing greater flexibility in the networks. Some of those are Role-Based Architecture (RBA) [9], Service Integration, controL and Optimization (SILO)[10], Recursive Network Architectures (RNA) [11], ”Netlet-based Network Architecture” (NENA) [12] and “Service Oriented Node Architecture” (SONATE). The RBA approach introduces a non-layered network architecture concept and organizes communication functionalities in functional units referred as “roles”. Roles are not hierarchically organized and thus may interact in many different ways. The main motivation for RBA is to address the frequent layer violations that occur in the current Internet architecture and to accommodate middle boxes. The SILO approach also introduces a non-layered design based on silos of atomic services . The overall goal of the SILO architecture is to facilitate cross-layer interactions in a manner that meets the user requirements accurately and to optimize the performance. The RNA approach examines the implications of using a single, tunable protocol for different layers. RNA reuses basic protocol operations across different protocol layers, avoiding redundancy of implementation as well as encouraging cleaner cross-layer interaction. NENA is a netlet based node architecture allowing to compose specialized communication services (Netlets). The goal is to handle many logical networks that fit to certain application requirements and network constraints [12]. NENA 349 V. C HALLENGES OF S ERVICE O RIENTED A PPROACHES IN F UTURE N ETWORK A RCHITECTURES communication service. These service descriptions are then used by the service broker and by the selection and composition process. At least the service broker, being used at runtime of an application, requires that service descriptions are machine processable. All kinds of service descriptions should use a common language to avoid language translations in the service broker or in the selection and composition process. Such a common description language must be comprehensive enough to describe all current communication services and the language must be extensible to describe future, yet unknown, services. It is likely to achieve this comprehensiveness and flexibility by using an RDF (Resource Description Framework) like syntax or defining sets of properties with (simple) attributes only. It is important that the language can be extended without the need of modifying the service broker or the selection and composition process because adaption and deployment of code will hinder extensions. The service description language must enable distinction between mandatory and optional requirements from the point of view of an application and also to distinguish guaranteed and not guaranteed properties of an offered service. The reason is that it must be decidable if a service is suitable to use, i.e. fulfills all mandatory requirements. Further non mandatory aspects of a service can be used to find the best service in terms of quality parameters. Several open issues remain for applying the SOA paradigm in a network architectures. A. Service Granularity SOA does not describe the granularity of a service, so design guidelines are required for the amount of logic every service must contain. A building block offers an atomic service which can be fine-grained (e.g. maintaining a sequence number) or coarse-grained (e.g. providing reliable transmission with flow control like TCP). While using many fine-grained services offer a greater flexibility but this increases the complexity for the selection and composition process. Coarse-grained services hide many relationsships of internal mechanisms, but reduce the ability of the network to adapt to current requirements and constraints. If some building blocks are often reused in the same composition then their granularity might be too fine, while superfluous functionality in composed services may indicate too coarse-grained functionality. B. Service Composition Approaches for selection and composition face a tradeoff between ’Composition time’ and ’Information availability’. Composition can be done at design time, deployment time and runtime. At design time, there are nearly no time limitations for the composition process and requirements of application(s) (or application classes) are already known. At deployment time (i.e. when an application is deployed on a platform), long running calculations are not suitable. But at this time also constraints of the platform, such as the available access networks and general resource limitations are known. At runtime there are hard time constraints for selection and composition, but only at this time specific user requirements (e.g. limits for costs) and dynamic network constraints (e.g. current network load) might be available. Examples for selection and composition approaches are: a) design time composition accomplished by humans possibly supported by tools; b) usage of templates, where the basic composition and especially the placement of functionality is defined at design time and some building blocks are selected later to fill out placeholders. c) selection and composition of coarse-grained building blocks, which have been pre-composed at an earlier time. As the examples b) and c) illustrate different steps of a selection and composition approach may be performed at different points in time. Selection and composition is still a research issue and it may turn out that no single composition approach is optimal in all cases. D. Feature Interaction Even though services should be designed and implemented so that they are autonomous, feature interaction among services is still possible. As an example, compression (i.e. compacting the payload) service and encryption (i.e. confidentiality) service where the processing sequence is not arbitrary as compression after encryption is senseless. If such interactions of feature between services of classes of services are known these may be described in policy rules. The problem is to ensure that all feature interactions are known, especially if new features are introduced. Beside feature interaction, some service implementations may define their own requirements. For example even though an application might accept low loss rates, a utilized protocol might require reliable transmission for signaling. Such requirements will be part of the service description of building blocks. Furthermore, there may be hints for the selection and composition process like which services should or should not be used together. For example reliable transmission should be accompanied by flow-control or there is no need to encrypt payload more than once. E. Heterogeneity C. Description Language A further challenging issue is how to handle different types of network nodes, to simultaneously make use of their provided services, and to ensure a conflict-free service composition at the same time. The network path for an end-toend communication consists of different network devices e.g. routers, switches, ISPs, proxy servers and so on. All of these nodes provide some defined services which can be used during Service descriptions are used to describe several kind of services. Firstly the service offered by building blocks must be described. Secondly also descriptions of composed service are required. In case services are composed dynamically also the corresponding service description must be generated. Finally applications use requirements description for requesting a 350 a data transmission. In such a case, it is necessary to identify which services are provided by which nodes and their compatibility for composing a specific workflow. These might be done before and during data transmission. The challenge here is to develop mechanisms or protocols to handle heterogeneous services offered by different devices on a communication path. VI. C ONCLUSION This article described how the principles of Service Oriented Architecture (SOA) can be helpful in designing network architectures. Focusing on a few implementation concepts, the paper has presented that some aspects show promises while other aspects are open challenges. Loose coupling of fine-grained functionality, such as micro-protocols, can enable more flexible networks, allowing adaptation of the network to an application’s needs and the network’s constraints. More importantly, this also allows the introduction, alteration and removal of network functionality. While this approach introduces more overhead, at least when compared to the current network stack, it trades performance for maintainability and flexibility. Security mechanisms face a similar trade off as security is necessary even though adding it reduces performance. A major goal for designing future network architectures is to achieve maintainability and flexibility with an acceptable overhead. It is hard to generalize the model or a definition for a flexible architecture as every domain has its own specifications of flexibility. Nevertheless, minimum interdependencies (i.e. loose-coupling) among components of an architecture is seen as a vital characteristic of a flexible architecture. SOA paradigm has evolved from other software engineering architecture paradigms to reinforce loose coupling. This paper can be a good ground to identify flexibility in the network architecture approaches with respect to SOA paradigm. R EFERENCES [1] M. Handley, “Why the internet only just works,” BT Technology Journal, vol. 24, no. 3, 2006. [2] I. Std., “Ieee std., 1471-2000 ieee recommended practice for architectural description of software-intensive systems -description,” 2000. [3] Recommendation, “Recommendation x.200 (07/94), x.200 information technology, open systems interconnection, basic reference model the basic model,” 1994. [4] B. Carpenter, “Architectural Principles of the Internet,” RFC 1958 (Informational), Internet Engineering Task Force, Jun. 1996, updated by RFC 3439. [Online]. Available: http://www.ietf.org/rfc/rfc1958.txt [5] J. A. Ralph Droms, “Ipv6 status pages,” Internet Engineering Task Force, March 2008. [Online]. Available: http://tools.ietf.org/wg/ipv6/ [6] R. Braden, D. Clark, S. Shenker, and J. Wroclawski, “Developing a next-generation internet architecture,” 2000. [7] T. Erl, “Service-oriented architecture,” 2006. [8] S. W, O’Malley, and L. L. Peterson, “A dynamic network architecture,” ACM Transactions on Computer Systems, vol. 10, pp. 110–143, 1992. [9] R. Braden, T. Faber, and M. Handley, “From protocol stack to protocol heap: role-based architecture,” SIGCOMM Comput. Commun. Rev., vol. 33, no. 1, pp. 17–22, 2003. [10] R. Dutta, G. Rouskas, I. Baldine, A. Bragg, and D. Stevenson, “The silo architecture for services integration, control, and optimization for the future internet,” in Communications, 2007. ICC ’07. IEEE International Conference on, June 2007, pp. 1899–1904. [11] V. P. Joseph D. Touch, Yu-Shun Wang, “A recursive network architecture,” 2006. [12] L. Voelker, D. Martin, I. E. Khayat, C. Werle, and M. Zitterbart, “A node architecture for 1000 future networks,” in International Workshop on the Network of the Future 2009, Dresden, Germany, 2009. 351