Semantic and Architectural Framework for Autonomic Transport Services

Transcription

1 Semantic and Architectural Framework for Autonomic Transport Services Ernesto EXPOSITO 1,2, Jorge GOMEZ 1,2,4 Myriam LAMOLLE 3 1 CNRS ; LAAS ; 7 av. du Colonel Roche, F Toulouse, FRANCE 2 Université de Toulouse; UPS, INSA, INP, ISAE; LAAS; F Toulouse, France 3 LIASD/LINC, IUT de Montreuil, Université Paris VIII 4 Facultad de Matemáticas, Universidad Autónoma de Yucatán, México {jorge.gomez, ernesto.exposito}@laas.fr m.lamolle@iut.univ-paris8.fr Abstract Fast development of Internet technologies has diversified by one hand the categories of distributed multimedia applications (i.e. IPTV, VoIP, VoD, visioconferencing, etc.) and by the other hand the available network technologies (i.e. high speed, wireless, mobile, etc.). This important evolution of application and network layers has deeply impacted the traditional transport layer. Indeed, traditional transport protocols (i.e. TCP and UDP) were well dimensioned for the original best-effort network model. However, specializations of the transport mechanisms were required to cope with new network technologies (e.g. TCP extensions for satellite or Wi-Fi networks). Likewise, new protocols such as DCCP and SCTP were proposed to enhance the basic transport services in order to include new mechanisms (e.g. more adapted network congestion avoidance strategies or multi-homing support for mobility). However, these partial enhancements and new developments in the area of transport protocols have not followed a reusable and service oriented approach intended to easily incorporate future protocol extensions and specializations. This paper presents a framework for communication services composition aimed at providing the basis for designing and developing autonomic transport services. This framework is intended to dynamically compose reusable transport mechanisms. A semantic space incorporating descriptions for user requirements, transport components and underlying network services is included in this framework in order to guide transport service composition process. Keywords: service component architecture, ontology driven architecture, transport protocols, Autonomic computing I. INTRODUCTION With the accelerated development of Internet, a large diversity of distributed applications (i.e. IPTV, VoIP, VoD, visio-conferencing, etc.) taking advantages of ubiquitous networked systems are constantly being deployed. These applications present diverse requirements in terms of Quality of Service (QoS) mainly related with time constraints, bandwidth and reliability. Requirements and preferences of these applications are more complex when compared with traditional applications such as FTP, HTTP or applications where a basic partially ordered and partially reliable transport service (i.e. TCP transport service) implemented over a Best-Effort network service was sufficient. In the past years, this basic Best-Effort service has been enhanced in order to offer QoS guarantees. Moreover, new technologies providing high speed, wireless or mobile services have deeply modified the QoS offered by the network layer, mainly providing new service models in terms of bandwidth, losses, delay or jitter. This dramatic evolution of application and network layers has deeply impacted the transport layer. Indeed, traditional TCP [2] and UDP [1] protocols are not able to provide an optimal service at the transport level over this large diversity of application categories and network services. In order to answer to these new requirements of adaptation, two different approaches have been followed. First approach proposes specializations of the existing transport services mainly implemented by extensions of TCP and UDP services (e.g. reliable UDP [5], fast TCP [6], etc). Second approach is based on the design and implementation of completely new transport protocols such as SCTP [3] or DCCP [4]. However, even if transport layer evolution represents a common example of classical software changing nature, no much effort has been invested in applying standard software engineering practices aimed at preparing the basis for the new extensions and specializations that will be certainly required in the future. Indeed, missing or insufficient component-oriented approaches makes difficult the implementation and specialization of new transport components, increasing the risks of code redundancy or functional incoherency. In this paper, a framework for communication services composition aimed at providing the basis for designing and developing autonomic transport services is presented. This framework is intended to dynamically compose reusable transport mechanisms. An adaptive communication pattern is included in this framework in order to allow autonomic functions development. This adaptive communication pattern facilitates the design of transport autonomic managers aimed at providing self-configuring and self-adapting functionalities. A semantic space incorporating descriptions for user requirements, transport components and underlying network services is included in this framework in order to guide self-configuring and self-adapting functions of autonomic transport services. This paper is structured as following. Section 2 presents a state of the art of existing protocol design architectures. Section 3 presents the service component architectural framework for autonomic transport protocols. Section 4 presents various case studies intended to illustrate the use of

2 the framework. Finally, the conclusions and perspectives of this work are presented. II. STATE OF THE ART Wherever Times is specified, Times Roman or Times New Roman may be used. If neither is available on your word processor, please use the font closest in appearance to Times. Avoid using bit-mapped fonts if possible. True-Type 1 or Open Type fonts are preferred. Please embed symbol fonts, as well, for math, etc. In the past years, different architectures and frameworks have been proposed in order to design and deploy communication protocols. Most of these architectures follow a hierarchical composition model. In these models the communication system is designed as a stack of directed graph of components called processing modules operating at the data plane and exchanging control or management messages. Examples of these hierarchical architectures are represented by the X-kernel [7] and V_STREAMS [8] models. Other architectural frameworks are based on eventbased approaches, where there is no mandatory sequential order between processing modules composing the system. The ADAPTIVE [9] and Cactus [10] systems are examples of event-based architectures. More recently, a new model for designing and implementing composite systems has been proposed by the OSOA and OASIS forum under the name of Service Component Architectures (SCA). The SCA specification proposes an architectural framework to build composite applications and systems based on plug and play components [11]. Next paragraphs introduce a state of the arts of these architectures. A. Hierarchical architectures V-STREAMS: The V_STREAMS was one of the first systems supporting a hierarchical and compositional model. In this system, a stream is a full duplex connection between several linearly connected processing modules with data flowing in both directions [8] (see Figure 1). The modules in a stream communicate almost exclusively by passing messages to their neighbours, except for some conventional variables used for some control functions. The API services consist in write and read messages. Each processing module consists of a pair of queues, one for each direction. In the V_STREAMS system a stream may be dynamically extended by the addition of new modules. Figure 1. V_STREAM hierarchical architecture X-kernel: This hierarchical model supports a more general directed protocol graph implemented in an object-based framework [7]. In the X-kernel framework, a protocol is considered as an abstract object that exports both a service interface and a peer-to-peer interface. The former defines the operations by which other protocols on the same machine invoke the services of this protocol, while the latter defines the form and meaning of messages exchanged between peers to implement the service. X-kernel supports an interesting mechanism to configure a protocol stack. This mechanism is based on a protocol graph, which makes it easy to plug protocols together in different ways (see Figure 2). This protocol graph is statically configured at initialization time. Figure 2. Example of an x-kernel protocol graph configuration B. Event-based architectures ADAPTIVE: This architecture implements a set of fundamental design patterns that simplify the development of concurrent event-driven communication software following an event-based approach. ADAPTIVE automates communication software configuration and reconfiguration by dynamically linking services into applications at runtime and executing these services on one or more processes or threads [9]. These services are implemented by a collection of object-oriented components. ADAPTIVE provides a higher level configuration interface, where a protocol composition is created automatically based on a functional specification. Cactus: Cactus is a framework for constructing configurable network services [10]. In Cactus each service attribute is implemented as an independent software module called a micro-protocol. With this approach, micro-protocols are chosen based on the needs of the higher levels that use the service or on the specific characteristics of the underlying network or computing platform. The configurable transport protocol (CTP) has been designed using the Cactus framework. In CTP various attributes such as reliable transmission and congestion control are implemented as separate micro protocols, which are then combined in different ways to provide customized semantics.

3 C. Service Component Architecture (SCA) The SCA framework provides a programming model for building systems based on Service Oriented Architectures (SOA) and based on composites and service components [11] (see Figure 3). In this model, an application or system results of the assembly of service components including their connections and bindings. Service components are the basic elements of the composite system in charge of implementing services and in the most of the cases are based on services implemented by other components. Components publish or implement a service interface and can require or use a reference interface. Interfaces are wired when the referenced interface is connected to an implemented interface. Interfaces are promoted when the service is only published and the binding has not been established. Components and the composite system itself can publish and share properties. The Service Component Definition Language (SCDL) is an XML-based language aimed at defining all the elements of a SCA composite. Figure 3. Service component architecture (SCA) model Hierarchical, event-based and service-component oriented architectures offer diverse solutions to design and deploy configurable protocols. However, a unique framework integrating these diverse approaches and solutions has not been proposed yet. An ideal architectural framework should be able to easily integrate existing and future transport mechanisms taking advantage of the service oriented architectures and sharing a common semantic space to guide self-configuring and self-adapting functions of the autonomic transport service compositions. III. PROTOCOL ARCHITECTURE DESIGN In previous sections, the needs for an autonomic transport service framework aimed at satisfying requirements diverse applications over heterogeneous network technologies have been raised. Likewise, existing architectures and frameworks aimed to be used when designing composite applications and communication protocols has also been introduced. This section is intended to define the basis of the design of this architectural framework for autonomic transport services. This design has to answer to the following fundamental questions: How the requirements of applications and available network services are going to be taken into account when selecting the adequate transport service? How transport protocol mechanisms can operate in an autonomous way in order to satisfy application requirements using available network services? Which internal architecture must be used to deploy transport services in order to allow future enhancements and specializations? The following sections are intended to propose solutions to these design requirements. A. Semantic space for transport service selection The first question is directly related to the way applications requirements are going to be taken into account to select the adequate composition and specialization of transport mechanisms. Likewise, the selection of mechanisms has to be based on underlying network services. As previously introduced, the constant evolution of application and network layers makes the selection of the adequate transport services a difficult task and traditional hard-coded strategies is not well suited anymore (e.g. static selection of UDP or TCP service). Indeed, a new approach is required to easily integrate new generations of transport protocols. The dynamic selection of services could be easily performed if a common semantic space is shared between user, application, transport and network layers. Within this semantic space, an intermediate component able to understand user and application requirements and to correctly match these requirements to an adequate transport service specification based on the existing network services could be implemented. In [11] an ontology-based framework aimed at integrating user and application requirements aimed at guiding the selection of the transport and network services has been proposed. This semantic framework can be used in order to develop a decision manager able to guide the selection of the adequate transport service specification. B. Autonomic transport components The second question is related to the correct provision (self-configuration) and adaptation (self-optimisation) of the transport mechanisms suited to satisfy the application requirements using the available underlying services. Transport components should be composed to provide a minimum set of basic transport services such as flow control, segmentation and reassembly or multiplexing [13]. These components should also provide specialized datacontrol and management functions taking into account the underlying communication services (i.e. IP Best-Effort or guaranteed network services) [14]. These transport mechanisms could include congestion control mechanisms in order to limit the congestion network consequences (i.e. losses and delay in Best-Effort networks) and error control mechanisms to satisfy the order and reliability constrains of

4 applications. These mechanisms have been included in some of the traditional and recent transport protocols (i.e. TCP, SCTP and DCCP). However these components have not been designed to implement an autonomic behaviour based on the application requirements and the network conditions. Examples of autonomic transport components are: Self-optimization: standard error control mechanisms providing a fully ordered and fully reliable service may be not compatible with multimedia streams time constraints. In contrast, an error control mechanism offering a partially ordered and partially reliable service could reduce the delay required to the data delivery while being compatible with the degree of error tolerance and out-of-order accepted by the applications. Self-configuration: the previously introduced error control mechanism could also be implicitly configured by the time requirements of the multimedia applications in order to automatically deduce the partial order and partial reliability parameter (e.g. by taking into account the interactive nature of the session and the intrinsic characteristics of audio and video codecs). Likewise, congestion control mechanisms could be specialized in order to take into account these time constraints. For instance, a source and rate based congestion control mechanism could be specialized in order to replace its delaying policy by a selective discarding policy when the network conditions could compromise the end-to-end delay. C. Hierarchical and Event-based Transport Service Component Architecture (SCA) The last question concerns the internal architecture provided by the framework in order to deploy the different transport components. A transport protocol that aims at satisfying the multiple QoS requirements of multimedia applications and that needs to be deployed over different network services should be implemented into a flexible and compositional architecture. This architecture should allow data-control and management mechanisms to be easily deployed and configured in order to efficiently work together: Data-control plane: The V_STREAMS system introduces the concept of processing modules aimed at controlling input and output flows. This is a key concept that can be applied to the data-control functions which have to be performed by a transport protocol synchronously to the application data units (ADU) exchanged between the distributed applications (e.g. source, receiver and hybrid-based mechanisms for rate control, error detection, etc.). Management plane: The management plane includes transport functions performed asynchronously to the data-plane, for instance when a specific event is triggered (e.g. error recovery mechanism triggered by a timeout). Management functions can be implemented in an event-based architecture such as the proposed by ADAPTIVE or Cactus. Communication channels should be established between the data-control and management functions allowing the exchange of signals between both functional planes. IV. DESIGN OF THE FRAMEWORK Based on the requirements presented in the previous section, the design of the semantic and architectural framework has been carried out. In this section a composite communication pattern intended to deploy transport mechanism will be presented. The specialization of this pattern in order to offer and adaptive API aimed at deploying autonomic transport protocols will also be introduced. Likewise, the orchestration of autonomic managers in order to offer self-adapting capabilities at the transport channel level as well as at the application, machine and group of machine levels will be presented. Finally, few issues regarding the deployment of the transport services will be detailed. A. Composite communication pattern Figure 4 presents the composite communication pattern of the transport framework. Figure 4. Composite communication pattern The composite communication pattern is based on two kinds of containers: Manager container (GMg): this container is aimed at deploying 1 or several components operating at the management plane. These components communicate with the data control plane by sending and receiving management signals. An example of a manager component is a retransmission controller able to decide the retransmission of lost data. Data-control containers (GSend and GRecv): these containers are intended to be used to deploy control

5 components operating on messages being sent or received by the applications. These components communicate with the underlying service to send and receive data. Examples of these components are a rate control limiting the data being sent or a loss detector component able to recognize losses in the data being received. These components are dynamically configured by the manager plane components (e.g. by changing the sending rate or by changing the loss acceptance policy in order to provide a partial reliable service). interfaces to adapt the error control strategies for lossy networks when the observed delay is too high. C. Autonomic components As previously introduced, transport services such as error control and congestion control mechanisms could be implemented using the composite communication pattern. Examples of these mechanisms are a Fully Reliable Error Control or a TCP-friendly congestion control (see Fig. 6). B. Adaptive composite communication pattern The communication pattern presented in the previous section allows deploying data-control and management plane components able to provide standard transport protocol mechanisms such as error control, rate control, congestion control, etc. These basic mechanisms are designed to operate based on their own view of the context. It means that the environment conditions are measured (e.g. delay, losses, congestion, etc.) and the management components are supposed to take the adequate decisions in order to satisfy the requirements of the application. However, in some cases, the policies implemented by these mechanisms could enter in conflict with the application requirements. For instance, when the delay in the communication is too high and the network is not reliable, retransmission performed by an error control mechanism could produce a final delay that is not acceptable for the application. In this scenario, the retransmission policy could be configuring to accept some losses when the delay is too important. This requirement leads to an enhancement to the basic composite communication pattern. Figure 5 illustrates this enhancement: the adaptive communication pattern. Figure 6. Autonomic components The adaptive composite communication pattern has been proposed to design externally adaptable transport mechanisms. Examples of these adaptable mechanisms are a Partially Reliable Error control and an Adaptive TCPfriendly Congestion Control. These mechanisms could be easily adapted by any external entity following specific adaptation policies. For instance, a component measuring the accumulated delay could change error and congestion control policies in order to relax the constraints when the delay is high and to go back to the preferred constraints when the network conditions are optimal. As illustrated in Fig. 6, this Time Manager is a specialization of an autonomic manager component. Figure 5. Adaptive composite communication pattern This adaptive pattern provides a new port allowing requesting and providing adaptation policies for an external component. For instance any application could use these D. Autonomic manager orchestration Sharing network resources by several communication entities is a very common scenario in distributed multimedia applications. For instance, for a VoD system, the transmission of two different streams is required (i.e. audio

6 and video streams). For each stream, specific transport mechanisms could be deployed within adaptive composite architectures. As illustrated in Fig. 7, a Synchronization Manager is required to guarantee the respect of inter-stream synchronization constraints (e.g. audio/video lips synchronization). This manager uses different adaptation ports to communicate with every transport entity in order to send synchronization adaptation policies (e.g. relaxing reliability constraints when the delay accumulated over the video leads to the interruption of the audio presentation). Figure 7. Autonomic manager for multimedia application More sophisticated autonomic manager orchestrators could be designed. For instance a Bandwidth Optimizer Manager could be designed in order to enforce adaptation policies when the network resources are not enough to transmit the audio and video streams. This manager could send adaptation requests to rate control mechanisms in order to give a higher priority to the most time sensible stream (e.g. audio stream). Likewise, other orchestrators could be designed to work on higher or lower level basis (see Fig. 8): Bandwidth Optimizer Manager previously presented). This autonomic manager follows the application requirements or preferences. Intra-systems: managers orchestrating the application-level manager within and end-system. This manager is based on the user requirements and preferences. Intra-group: managers aimed at enforce adaptation policies in the various end-systems composing a collaborating group (e.g. a visio-conferencing system with more than 2 participants). The group requirements and preferences are used to drive the autonomic manager. E. Deployment. The various components described in the previous sections need to be dynamically deployed within the adequate architectures: data-control and management planes of basic and adaptive communication architectures autonomic manager and autonomic manager orchestrators The deployment of this diversity of components needs to be done following a standard specification such as the one proposed by the SCA model. The adequate selection and configuration of these components needs to be done using the common semantic space introduced in the previous section. For further information about ontology driven architecture methodologies can be found in [11]. V. STUDY CASES This section presents different instances of autonomic transport services based on the architecture framework presented in the previous section. Fig. 9, present this set of transport services. Video/audio multimedia Based on inter-flow priorities Based on inter-apps priorities Based on inter-user priorities Group of user QoS Semantic Figure 8. Category of Autonomic manager orchestrators Intra-flow: manager operating within a multimedia stream and able to adapt the service by recognizing the sub-streams composing the media (e.g. multilayered video streams presenting different quality/compression layers) Intra-application: manager operating between the various streams of a same application (e.g. the Figure 9. Transport mechanisms A. Partially Reliable services Partially reliable services are implemented based on the explicit reliability requirements indicated by the application or implicitly, deducing the reliability requirements from the intrinsic time constraints. FEC (forward error correction)

7 and ARQ (automatic repeat request) mechanisms could be enhanced in order to provide this specialized error control mechanism. FEC mechanisms are considered as being very dependent on the traffic loss characteristics but the delay is lower than ARQ mechanisms. ARQ mechanisms seem to be more suitable to irregular traffic loss conditions. 1) Partially Reliable service (PR) PR is aimed at providing a basic partially reliable service following an ARQ-based or FEC-based scheme. PR is intended to guarantee a minimum reliability explicitly specified by a percentage of data packets that must reach the receiver. This service could be easily adapted using an external autonomic manager able to adjust the adequate reliability parameter regarding the application requirements (e.g. using an time manager). 2) Differentiated and Partially Reliable service (D-PR) D-PR specializes PR and is intended to provide a partially reliable service that takes into account the differentiation data packets within the multimedia stream. For example, for the H.263 video stream, D-PR service can guarantee a minimum percentage of reliability for each class of picture (i.e., I and P), taking into account both intra (i.e. segmentation of I or P pictures) and inter dependencies (i.e. dependency of P over I picture). This service could also be externally adapted following the same approach as for the PR service. 3) Time-constrained, Differentiated and Partially Reliable service (TD-PR) PR and D-PR services have been implemented as a mean to reduce the delay induced by a full reliable service. However, without looking at packet timing requirements, these services cannot always guarantee the respect of the time constraints. Indeed, even a partially reliable service can induce a delay that might be not tolerable for certain applications (i.e. interactive applications). In contrast, for other applications such as video on demand, the user could prefer additional delay than quality degradation. TD-PR service has been designed in order to implicitly adapt the differentiated and partially reliable service taking into account specific time constraints. TD-PR includes the adaptive D-PR service managed by a Time Control autonomic manager. This service is an example of an autonomic transport service. B. Rate and congestion control mechanisms (RC, TFRC, TD-RC, TD-TFRC) These mechanisms include a congestion control mechanism intended to preserve the network resources when a Best-Effort service is provided offering a TCPfriendly behavior (TFRC). Likewise, a rate control mechanism intended to efficiently use the resources of guaranteed networks services has been included (RC). Rate and congestion control mechanisms have been enhanced in order to include a Time Control autonomic manager able to take into account intrinsic application time constraints to adapt the transport service (TD-PR, TD-TFRC and TD-RC). C. Composition of services As illustrated in Fig. 9, error control and rate/congestion control mechanisms could be composed in order to satisfy the application requirements according to the underlying network services. The adequate composition could be dynamically computed using the description of every component, the application requirements and the underlying services. These specifications are part of transport service ontology able to describe components, mechanisms and services. Likewise, adaptation strategies for autonomic managers and autonomic manager orchestrators are also included within this ontology. The definition of this transport service ontology is currently in an experimental phase. Information about the principles being followed to develop this approach can be found in [11]. VI. CONCLUSIONS AND PERSPECTIVES In this paper the design of service component architectural framework aimed at designing autonomic transport services has been presented. This framework facilitates the integration of existing transport mechanisms and protocols and the incorporation of new components intended to satisfy new application requirements and to deal with new network services and technologies. Moreover, this framework includes abstract autonomic managers and autonomic manager orchestrators able to offer self-configuring and self-optimizing functionalities allowing the implementation of autonomic transport services. This framework has been designed based on well-known architectures and models and is a combination of hierarchical, event-based and service components oriented architectures. Hierarchical architecture design allows deploying transport components operating at data plane cadence (e.g. flow control, segmentation and reassembly, multiplexing, etc). Event-based design is aimed at deploying components operating at the management plane (e.g. retransmission of lost packets or recalculation of the congestion control windows based on packet loss rates). Finally, service component architecture model facilitates the integration and dynamic deployment of transport components. Moreover, a semantic space has been included in order to provide an ideal context to perform selfconfiguring functions based on the application goals and requirements. An autonomic transport protocol prototype has been implemented using this framework. Initial experiments aimed at demonstrate the advantages of this approach are in progress and at the moment of writing this paper the experiments have not been completed yet. However, preliminary results present optimistic perspectives.

8 REFERENCES [1] Postel J., "User Datagram Protocol (UDP)", RFC 768, August 1980 [2] Postel J., "Transmission Control Protocol; DARPA Internet Program Protocol Specification," RFC 793, September 1981 [3] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Scwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, Stream Control Transmission Protocol, RFC 2960, October 2000 [4] E. Kohler, M. Handley, and S. Floyd, Datagram congestion control protocol (dccp), IETF, RFC 4340, [5] T. Bova and T. Krivoruchka, Reliable udp protocol (rudp), Internet Draft, Tech. Rep., February [6] C. Jin, D. Wei, and S. Low, Fast tcp: Motivation, architecture, algorithms, performance, in Proceedings of IEEE INFOCOM, March [7] Hutchinson N., Peterson L., The x-kernel: An architecture for implementing network protocols, IEEE Transactions Software Engineering, vol. 17, no. 1, [8] Ritchie D.M., A stream input-output system, AT&T Bell Laboratories Technical Journal, vol. 63, no. 8, 1984 [9] Schmidt D. et al, ADAPTIVE: A dynamically assembled protocol transformation, integration and evaluation environment, Concurrency: Practice/Experience, vol. 5, no. 4, 1993 [10] Gary T. et al, A configurable and extensible transport protocol, INFOCOM, [11] Service Component Architecture specifications from the OSOA ( and OASIS ( websites. [12] J. Gomez, M. Lamolle, E. Exposito, " A Multimedia Ontology Driven Architecture framework (MODA) for Networked Multimedia Systems", International Conference on 'Networked Digital Technologies' (NDT 2009) Ostrava, The Czech Republic, July 29-31, 2009 [13] E. Exposito, "Specification and implementation of a QoS oriented transport protocol for multimedia applications", PhD dissertation, Institut National Polytechnique de Toulouse. December 2003, Toulouse, France. [14] Exposito E. et al, Deploying new QoS aware transport services. IDMS/PROMS'2002, pp , Portugal, November 2002.