Transport Stratum Services in NGN: a SOA-oriented design

Transcription

1 Transport Stratum Services in NGN: a SOA-oriented design Giovanni Branca, Paolo Anedda, Luigi Atzori, Senior Member, IEEE Department of Electrical and Electronic Engineering - University of Cagliari, Cagliari, Italy {giovanni.branca, paolo.anedda, l.atzori}@diee.unica.it Abstract The transport stratum in the ITU-T Next Generation Networks (NGN) is expected to provide end-to-end connectivity according to the service requirements, the terminal capability and status of the network resource availability. Whereas mature technologies and protocols, such as DiffServ and MPLS, are available to satisfy these requirements, some issues are still open concerning the capability to provide these services in a dynamic and flexible way. In particular, interoperable and open interfaces are missing at the transport stratum, so that the dynamic activation of distributed application layer services is synchronized with dynamic activation, configuration and monitoring of transport services. This is the challenge addressed in this paper, whose objective is the definition of the NGN Transport Stratum functionalities according to the SOA paradigm and the implementation of the relevant services interfaces to analyze the potentialities of this approach. With the intention to follow the evolutionary approach towards the transition into the NGN networks from the current Internet, this study has been conducted by taking into account the efforts that have been already devoted in the last decade with regard to the definition of the technologies and protocols to build multiservice, QoS-aware and TE-oriented networks solutions. Preliminary experimental results provide some insight on the potentialities of the proposed strategy. Index Terms Service Oriented Architecture (SOA), Next Generation Networks (NGN), DiffServ-Traffic Engineering (DS- TE) I. INTRODUCTION Next Generation Networks are expected to fulfill the custom-need-driven model, which is mainly intended to: satisfy customers in differentiated ways, quickly deploy new services at user request, manage network and service resources in an integrate way. Accordingly, the ITU-T NGN architecture is characterized by the separation of the service stratum from the transport stratum so as to enable: the flexibility to add, maintain and remove services without any impact on the transport layer; the flexibility to add, maintain and remove transport technologies without any impact on the access to service, application, content and information; and finally the optimized usage of multiple access and core transport technologies to form end-to-end connectivity across multiple terminals, different access technologies and different core transport technologies [1]. We see a big challenge in this context, which is related to the flexibility and dynamicity in the provisioning of new transport services when requested by the service stratum so as to follow the rapid evolution of the user needs and market trends, which is one of the main feature of the NGNs. Herein, dynamicity is intended as the capability of the network to bind on-demand services and relevant resources, often provided by different operators through separate domains, at user request and according to his profile. Indeed, the creation of new market-driven applications by reusing an extensible set of existing service components has been a key aspect of telecom platforms for years, but this has almost exclusively characterized the application/service stratum. In truth, application provisioning is currently carried out without the cooperation of the lower layers (transport stratum), which are responsible for the delivery of the data between distributed services entrypoints. The present work goes in this direction, with the aim to make available in a flexible and dynamic way all the capabilities of the transport stratum to the upper layers, such as the service stratum, the end-users functions and to other networks. The addressed challenge is the analysis of the transport functional layer as required in the NGN transport stratum, the decomposition of this layer into a set of microfunctionalities according to the Service Oriented Architecture (SOA) style and the implementation of the relevant services using the Web Service (WS) technologies to analyze the advantages of the proposed approach. With the intention to follow the evolutionary approach towards the transition into the NGN networks from the current Internet, this study has been conducted by taking into account the efforts that have been already devoted in the last decade towards the definition of the technologies and protocols to build multiservice, QoSaware and TE-oriented networks solutions. The main advantages of the proposed solution are: the use of a common formalism for the definition of low level telecommunication services; the use of common interfaces that don t require the operators to know the inner details of each single service; the possibility for telcos to deploy services at the higher levels (Service and Application Stratum) by composing services in the lower layers (Transport Stratum) using a composition and coordination logic. This paper is structured as follows. Section II briefly provides the description of the technology background and past works. Section III introduces the layered architecture proposed, whereas Section IV describes our SOA-oriented design. Section V presents experimental results and Section VI draws the conclusions.

2 A. Technologies II. BACKGROUND 1) SOA principles and Web Services: The SOA principles [2] permit to transform a monolithic system into a dynamic and flexible one: in this way, a SOA-based system is made up of many independent, weakly coupled, stateless, selfcontained and reusable services. The SOA ideas are not new to the telecommunication industry [3] and the WS technologies represent the simplest SOA implementation [4]. Many efforts have been done towards their standardization so that today a WS can be an effective realization of a service according to SOA style. 2) Differentiated Services - Traffic Engineering (DS-TE): DS-TE technology [5] implements traffic engineering in a perclass basis making both end-to-end QoS guarantees and network scalability objectives in a DS environment. It optimizes the utilization of network resources computing one or more paths from each source to each destination according to a certain set of constraints. Default TE implementation relies on the flow-based MultiProtocol Label Switching (MPLS) technology: the incoming traffic flows are marked by the LERs (Label Edge Router) with a label corresponding to the forwarding along a specific Label Switching Path (LSP). 3) ITU-T NGN: A NGN is a packet-based network able to provide telecommunication services making use of multiple broadband and QoS-enabled transport technologies. The functional architecture proposed by ITU-T is composed by three different layers: the Transport Stratum, the Service Stratum and the Application Layer. The Transport Stratum takes care of maintaining end-to-end connectivity according to the service requirements, terminal and resource capability; the Service Stratum is responsible for enabling the creation and the delivery of services; the Application Layer is composed of servers that can use the Application Programming Interfaces (API) to discover and to use the available enablers and finally to create and execute their own service, application or content. B. Past works Most of the past works dealing with the SOA technologies applied to telecommunication issues have mainly focused on the business process management and network management. To our best knowledge, none have deeply focused on the design of the transport service as we do in this paper. As to the business process, [4] is a good survey on the the evolution of SOA concepts in telecommunication from a business point of view. Authors describe the key enablers in telecommunications: WS, event-driven architectures, Parlay X specifications, and the Enterprise Service Bus (ESB). Service composition is a technique that helps in the development of management systems by aggregating smaller services to produce more sophisticated ones. [6] provides a review of service composition in the context of network management. In [7], an overview of features and possible advantages of WS for network management, the architecture and design of an interface for operations supported by single Fig. 1. Proposed reference architecture for a SOA-based implementation of the transport stratum functionalities network management stations are presented. In [8] a universal architecture and its application to a MPLS network is evaluated, where management services are able to communicate with network devices using SNMP protocol, between them, and with infrastructure services thanks to SOAP/XML messages. Even if not explicitly referring to the SOA technologies, the TINA consortium [9] has dealt with service-based network architectures: in its guidelines, it introduces the concept that a network architecture should be designed according to a service-oriented abstraction of network resources. In a TINA architecture, any use of the network is the result of using a service, and for this reason it is important that the network provides a service-oriented view of connectivity procedures. Comparing the TINA architecture to ours, some differences emerge. The former is built following an overlapping layer structure similar to the Open System Interconnection (OSI) one: it is a hierarchical structure where each layer performs a different abstraction level. The latter architecture implements a service-oriented view too, but a service creation process does not follow a rigid and static structure: new services can be built at runtime as composition of elementary services by adhoc workflow definition without a rigid layered architecture. The work proposed in this paper goes in this direction, allowing more flexibility in NGN and so giving the ability to provide transport services in a dynamic and flexible way. A comparative analysis of SOA-based and OSI architectures can be found in [10]. III. TRANSPORT STRATUM ARCHITECTURAL MODEL This section describes the principles that have been followed to design the proposed architecture and the resulting reference model. The modeling activity proceeds defining different layers, each one with an higher level of abstraction. This approach starts from the basic services to the most complex: the services at the higher levels can be obtained as a composition of other services in the lower layers. These principles and considerations are the basis of the proposed SOAbased architecture for the provision of the transport stratum services,whichisshowninfigure1.inthisarchitecture,the classical hard-set layered structure of TINA is substituted with a more flexible one, where the creation of complex services is

3 dynamical and flexible, so that new services can be added or modified at runtime, taking advantage of all SOA principles. The bottom layer is composed by the physical infrastructure: the devices can belong to the same or to different network domains and regardless of this condition they participate to specific processes defined in the upper layers. Moving to the top, we have introduced the Elementary Services (ES) Layer where each component has the typical properties of SOA services. Their features of being independent, self-contained, weakly coupled and reusable permit to have more elementary services corresponding to a specific process, such as the path calculation, the admission control or the link traffic monitoring services. Accordingly, in the second layer, the basic and specific operations are associated to well-defined services. Some of these services could require the access to network physical devices. The third layer is where complex services are created as composition of more than one elementary service. Their behavior and the the logic that drive them can be expressed using workflows of coordinated services. On the top, the interfaces towards the service stratum are located. Each complex service exposes its own interface that in turn shows methods to access transport stratum resources. In this way is possible to deploy verticalized solutions with very detailed functionalities. Constructing this architecture, we watch out for the interfaces: each one has to be standardized, so that the complex service as well as the elementary service realization are not constrained to a specific implementation. Using common interfaces and protocols, operators without any knowledge of the inner details of each single service can compose new services tailored to their needs. Starting from these principles, in our work we have developed a framework for the construction of such an architecture, choosing to use WS and standard Internet technologies. Every service is equipped with a standard WS interface and also the access to the network devices is carried out through some WS Proxies (WP). IV. SOA ORIENTED DESIGN Following the architectural model defined in the previous section, we have analyzed the transport stratum functionalities as required in the foreseen NGN functional architecture and we have devised the decomposition of this layer into a set of macro-functionalities and micro-functionalities according to the SOA style. This decomposition has been carried out taking into account the DS-TE network solution. However, the resulting micro-functionalities can be easily generalized for other multi-service QoS-aware network solutions as far as these fit into the transport stratum functions defined by ITU-T [1]. To decompose the monolithic DS-TE architecture towards a new SOA-oriented architecture we have followed the procedure shown in the left side of Figure 2. In step 1, the DS-TE architecture is decomposed into macro-functionalities (MF), defined as a macroscopic component of the system that takes care of well-defined aspects. In our analysis we have isolated the following MFs, that define the management of NGNs [1]: Path computing: it calculates the physical path over the links and devices of the network Class Type definition: it defines a set of traffic trunks with similar QoS and bandwidth constraint requirements Load Balancing / Performance Management: it allows to achieve the best use of network resources Creation and management of bandwidth constraints: Resilience / Fault management: it recovers network faults TE-Routing, with the Load Balancing SLA Management: it defines the customer needs Accounting / Admission Control: it authorizes the user connectivity and stores its data for billing Policy Management: it manages any policies as defined by the network owner or administrator Security management: it gives the rights to use the network and the single user traffic isolation Inter-operability with other domains: it manage the connections and traffic delivery between different domains While the main macro-functionalities are included in this list, it is not intended to be exhaustive and amendments may be introduced. The refinement step1isdrivenbytheanalysis of all DS-TE MPLS requirements, as defined in literature [5] [11]. The result of this analysis is a set of MFs that apply to a generic multiservice transport stratum. In the second step every MF, in turn, is decomposed into micro Functionalities (mfs): each of these represents an elementary task, which can be considered as the smallest part of a generic service. For example, the Path Computing MF is built by the following mfs: 1) Edge routers specification: it defines the traffic ingress and the egress devices 2) Label definitions: it specifies the labels that have to be used in each link 3) Label distribution: it delivers the labels to each device 4) Path calculation: it computes the logical path to be created Arefinement step is performed at this point too, with the aim of having a better knowledge of all tasks participating to the related MF. The third step concerns the analysis of the interactions between mfs, aimed at avoiding the presence of fully or partially duplicated mfs. The global view of all mfs and relationships allows us to see which of these are strongly coupled: this is a key-indicator about a possible aggregation. In the fourth step, two or more mfs are combined together if the relationships between them are very strong. At this point, the mfs are wrapped into an elementary service, which exposes its interfaces to the upper complex services layer. Also in this step, the refinement step is fundamental to verify the completeness and the compliance of the proposed solution to the SOA principles. We have also defined several use-cases and corresponding workflows, which have allowed us to improve mfs definition and interaction, such as: 1) Activation of a traffic delivery service in a single domain with QoS guaranteed, 2) Activation

4 Macro Functionalities (MF) decomposition Refinement step 1 Micro Functionalities (mf) decomposition Investigation on relationships between mf mf aggregation and elementary services definition Refinement step 3 Final scheme Refinement step Load balancing/performance Management - Resilience/Fault Management - Path computing - TE Routing Network state monitoring - Policies used: preventive/proactive/reactive - Evaluation of traffic demand - Definition of roting constraints - Path calculation - Prevision and verify of the network state - Measurement of bandwidth used in every link - Calculation of alternative paths (in case of fault) - Network prevision with new paths created - New path activation - Traffic re-routing - Alarms creation to be sent to network administrator Use cases - Network inventory of all paths actived - Bandwidth measuration in every path - Calculation of alternative paths - Moving paths - Verify of SLA respected - Edge routers specification - Label definition - Label distribution - Path calculation Relationships investigation a) b) 4. Setup Management Label distribution What-If Analysis Definition of traffic marking criterion Research of the best traffic mapping over the network QoS requirements mapping Measurement and verify of Key Policy definition about traffic Performance Indicators (KPI) treatment with other domains Definition of target function and Definition and updating of all constraints for the routing algorithm possible SLAs to be stipulated SLA modifies in relationship Routing algorithm selection (e.g. of new network conditions Constrained Routing Algorithm (CBR)) Definition of the bandwidth model and Analysis and admission of setting of Bandwidth Constraints (BC) incoming traffic requests Network previsioning with Traffic aggregation in traffic trunks new paths enabled Edge routers specification Analysis SLAs and KPI thresholds to be respected Path calculation Policy management Traffic sending over the path Activation Network of new paths monitoring Moving traffic towards other paths Resilience Fig. 2. a) The SOA-based decomposition procedure, b) the scheme of Elementary Services extracted following the procedure in a) of a traffic delivery service in a multi-domain environment, 3) Optimization of network resource usage, 4) Setup of a bandwidth model over the network, 5) Change of policy mapping for incoming requests. These use-cases represent some of the main functionalities that are expected to be provided by the transport stratum and that should be developed in the third layer of our architectural model. Subsequently, we have grouped the elementary services in the following macroareas: setup, resilience and management. Figure 2 shows an example of the decomposition procedure and the complete list of elementary services, which is our final result. In this figure, starting from the top where some MF are listed (step1), it can be seen the decomposition in mf (step 2), some use cases definition and the relationship investigation (step 3) up to the extraction of the Path calculation elementary service (step 4). A complex application is built by a well-defined sequence of operations that involve more elementary services, also named workflow. Consider, for example, the first use-case (Activation of a traffic delivery service in a single domain with QoS guaranteed): it involves 5 different WSs plus the WP, as shown in Figure 3. V. SYSTEM EVALUATION A. System setup Every Elementary Service (ES) is composed at least by two main components: the Interface Layer and the Business Logic Layer. The former exposes the methods available through a standard WS interface and is responsible for the management of all messaging operations involved in the services communication. The latter implements the logic of the Elementary Service. Additionally, if the WS needs to communicate with the network devices, a third component is used, which is the Device Communication Layer. It is designated to translate the interfaces methods used by the Business Logic Layer into device specific commands and is also responsible for the communications session management. Details of this architecture can be found in [12]. Finally, every workflow exports a WS interface, that belongs to the Transport Interfaces Layer. We have implemented the architecture shown in Figure 1 making use of the open source framework Axis2 and Tomcat from the Apache Software Foundation. Furthermore, every Elementary Service listen in Figure 2b has been implemented making use of the WS technologies as defined above. B. Experiments In the construction of the DS-TE network solution according to the SOA style, our attention has been focused on the development of the ES methods wrapped into WSs and especially on the usability, scalability and flexibility of the proposed SOA architecture. To evaluate the limits and potentialities of the proposed approach, we have developed a simple architecture connecting a workstation running a Remote Procedure Call (RPC) client and a server running all the WSs, by means of a simple LAN. The connection rate has been set using a software traffic shaper running in another server. The aim of this test architecture is to study the execution time requested by the workflow at different WS Aggregation Levels (AL), where the AL indicates how many elementary services, and so their correspondent WS, are delivered by a single WS. In this first test, the workflow realizes an implementation of the case study 1) shown in Figure 3. In this first test, this workflow has been executed skipping the WSs related to the communication with the physical devices not to mix the ES communication delays with the device communication delays. With regard to the figure, with an AL 1, the client calls four different elementary WSs by sending four different SOAP messages requests to the server. With the AL 2, the client calls two generic WSs running into the server: each one of these, in turn, call two elementary WSs. AL 3 and 4 are constructed following the same procedure. The results in Figure 4 show a decreasing execution time as the AL increases, as expected. Indeed, the total execution time is composed by the sum of transmission and processing time. At low connection rates the transmission time has more

5 Fig. 3. Workflow implementation of the use case 1): Activation of a traffic delivery service in a single domain with QoS guaranteed Fig. 4. Execution time of the workflow of Figure 3 with different Web- Services aggregation levels importance than the processing time, which can be neglected in these cases. Results show the tradeoff between the WS separation and the WS aggregation. WS separation makes possible to have a more flexible architecture, deployable in a distributed system, as a geographical network, but with the disadvantage of bigger transmission times. Aggregation provides a less flexible but faster system, where the network transmission time has a reduced influence and the system management is concentrated in a single node, which represents a single point-of-failure. In addition, we have performed other tests for analyzing the performance of the elementary services composition involving also the use of the WP and real devices thanks to a Virtual Private Network (VPN) connection that can reach a remote MPLS capable network: the finalresultisthe setting of MPLS commands in physical devices. Following the SOA style, our system should be composed by only stateless services. However the creation of LSPs and the setting of TE parameters determine the setting of different states, which need to be stored in the system. Accordingly, in our implementation, the LSPRepository service is interrogated and refreshed during the LSP creation, as can be seen in the workflow of Figure 3. Figure 5 shows the results of the experiments: for different bitrate in the connection lines, the cumulative response time of every WS is shown. The curves have the similar shape, rescaled due to various bitrate allowed over the network by the traffic shaper. It can be clearly seen the time-step of the Fig. 5. Cumulative response time of workflow shown in Figure 3 CommandSending service: this service creates the connections to physical devices using the VPN connection. Indeed, the CommandSending service, that in turn calls the WP, essentially needs more time with respect to other services. VI. CONCLUSION In this paper we have proposed an architecture of four different layers for the implementation of the transport stratum in NGN, following a SOA-oriented design. The SOA approach can lead up to the development of a more flexible and dynamic transport stratum, without any impact to the upper service stratum.we have specifically referred to the DS-TE architecture, isolating the elementary services that can be composed to build complex services, which are then subsequently exposed to the service stratum. We have carried out a first experimental analysis with the intent to investigate the impact of the WS overhead and the importance of Elementary Services distribution in the managed network. REFERENCES [1] J. L. Salina and P. Salina, Next Generation Networks - Perspectives and Potentials. John Wiley and Sons, Ltd, [2] T. Erl, Service-Oriented Architecture: Concepts, Technology and Design. Prentice Hall PTR, August [3] T. Magedanz, N. Blum, and S. Dutkowski, Evolution of SOA Concepts in Telecommunications, IEEE Computer, vol. 40, no. 11, pp , Nov [4] D. Griffin and D. Pesch, A Survey on Web Services in Telecommunications, Communications Magazine, IEEE, vol. 45, no. 7, pp , July [5] F. Le Faucheur, Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering, RFC 4124, June [6] R. Vianna, E. Polina, C. Marquezan, L. Bertholdo, L. Tarouco, M. Almeida, and L. Granville, An Evaluation of Service Composition Technologies Applied to Network Management, in INM, 2007, pp [7] P. Rajesh, S. Ranjiith, P. Soumya, V. Karthik, and S. Datthathreya, Network Management System using Web Services and Service Oriented Architecture - A case study, in NOMS 2006, April 2006, pp [8] B. Thurm, Web Services for Network Management - A Universal Architecture and its Application to MPLS Networks, in LCN 2002, Nov. 2002, pp [9] The TINA consortium. [Online]. Available: [10] C. Fortuna and M. Mohorcic, Dynamic composition of services for endto-end information transport, IEEE Wireless Communication Magazine, vol. 16, no. 4, pp , [11] F. L. Faucheur and W. Lai, Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, [12] P. Anedda and L. Atzori, Network Administration Using Web Services, in Global Telecommunications Conference, GLOBECOM IEEE, nov. 2009, pp. 1 6.