SIP-based Service Architecture for Applicationaware Optical Network

Transcription

1 1 SIP-based Service Architecture for Applicationaware Optical Network A. Campi, W. Cerroni, G. Corazza, F. Callegati DEIS University of Bologna Bologna, ITALY {aldo.campi,walter.cerroni, B. Martini, F. Baroncelli, V. Martini, P. Castoldi CNIT Pisa, Italy {barbara.martini, fabio.baroncelli Scuola Superiore Sant'Anna Pisa, ITALY {valerio.martini, Abstract This papers reports a test-bed implementation of an application-aware optical network where IT applications may request a given resource (i.e. remote storage space, remote computation, media stream, etc.) and the communication facilities required to connect to it with proper grade of service, fully relying on the network infrastructure. Index Terms GMPLS, SOON, SIP, NGN, Optical network, application aware F I. INTRODUCTION uture IT services aim at the integration and management of resources and services within distributed, heterogeneous, dynamic environments. The realization of this goal requires the disintegration of numerous barriers that normally separate computing systems and application services from data network infrastructures. One of the key issues is to provide solutions on bridging remote IT/Grid systems and services (e.g. supercomputers, data centers, IPTV) with emerging and promising optical transport network technologies (e.g. Intelligent Optical Networks) These networks are equipped with Control Plane (CP) functionality, e.g. typically based on the Generalized MultiProtocol Label Switching (GMPLS) protocol suite V, which basically automates the circuit provisioning across the network and exposes such capabilities to client nodes through User to Network Interface (UNI). However these networks still lack the capabilities to fulfill connectivity service requests issued by IT applications due to different grain in the resource description carried by application service request and that handled by the network service primitives of CP. This suggests the need for new network elements providing a new set of functionality supporting application-to-network interaction. The core proposal of this paper is to provide full application aware networking. This term has been used quite extensively in the last decade, often with slightly different focus. This work has been was partially funded by the BONE-project ("Building the Future Optical Network in Europe), a Network of Excellence funded by the European Commission through the 7th ICT-Framework Programme. According to the previous statements, the goal here is to provide the application with the opportunity to request a given resource (i.e. remote storage space, remote computation, media stream, etc.) and the communication facilities required to connect to it with proper grade of service fully relying on the network infrastructure. The following action points are crucial to this end: make the application capable of exchanging semantically rich messages with the network to issue service requests for the negotiation and reservation of needed resources choose a semantically rich language that is general enough to be useable by any sort of application for any possible kind enable the technology independent control of network resources by mapping the service request into CP directives. It would be of great value to solve these action points without any major implementation effort, but using existing building blocks, suitably arranged. We believe one of the crucial results of this work is that we are able to prove by means of a test-bed implementation that this is possible. In the proposed architecture the network resource reservation is realized during the application signaling thus realizing the on-demand service provisioning to applications with the required quality of service. The application signaling is based on Session Initiation Protocol (SIP). The session management messages carry a general resource description payload that contains the application request to the network in a user oriented language. This work proposes to use the Resource Description Framework (RDF) language V following the ideas presented in V. The service requests issued by applications need to be translated in a consistent and network-specific directives. A service architecture for CP-enable transport network, called Service Oriented Optical Network (SOON) V is exploited to fulfil the service requests issued by applications while masking the transport related implementation details from the abstract request of the service. SOON allows network technologies to be independent from future evolution of the network services and the CP to be unburdened of the service-related

2 2 functionality. A nice and important feature of the architecture proposed here is that it is also consistent with the Next Generation Network specifications by ITU-T as will be discussed later in the paper. The solution presented in the paper is supported by the description of a prototype implementation. The experiments described show that the network can be made application aware rather easily exploiting existing technology. The paper is organized as follows II.APPLICATION AWARE NETWORK ARCHITECTURE AND BUILDING BLOCKS This section describes the proposed architecture and the relevant building blocks. The logical architecture is presented in Fig. 1 where three logical layers are in evidence. A session layer managing the application signaling, the service plane managing the mapping between service and network requests and the GMPLS-enabled optical network. The network coupled with the service layer constitutes the Service Oriented Optical Network (SOON) architecture. A. Application Oriented Network module We assume the network is equipped with Application Oriented Modules (AO-M) to manage application aware networking. This is where the session concept and the SIP protocol get into play: sessions are used to handle the communication requests and maintain their state by mapping it into session attributes; the SIP protocol is used to manage the sessions since it provides all the primitives for user authentication, session set-up, suspension and retrieval. This approach already proved successful in a previous experiment referring to a scenario fo Grid applications over Optical Burst Switched network V. End-user application Figure 1. DSE M I Edge router Session layer Service Plane Optical Transport network APP-M NET-M AO-M SIP-M DSE Resource SOON Application oriented network architecture, showing the various modules and their intercation. The logical scheme is shown in Figure 1. The AO-M is above the SOON and talks directly with the end user applications. It is logically sub-divided into three modules: SIP module (SIP-M): is a standard SIP proxy implementation enhanced with interfaces towards the upper and lower modules. Application module (APP-M): parses and understands the application protocols that may be encapsulated in the SIP messages; Network module (NET-M): is able to interact with the network, i.e. the SOON DSE in this work. Given the nature of a SIP proxy, in principle a network domain could have just one SIP-M managing the whole domain or many of them co-located with (some of) the network nodes. Combining the communication capabilities of APP-M and SIP-M the AO-M may assist applications into publishing, searching and reserving resources, thus understanding the related communication needs and mapping them into sessions. Thanks to the NET-M the SIP-M may send the information about the service profile of a given session to the SOON DSE, that will trigger the networks into creating the connections required to transport the data flow. As outlined previously this architecture may manage both application resources and network resources. Nonetheless in this work we focus on the network resource provisioning and in the following will refer to this specific case only. A discussion of how could be managed application resources is described (in a similar architecture) in V. B. The Resource Description Framework The Resource Description Framework (RDF) is a generalpurpose language, defined by W3C, for representing information V. RDF provides general method of modeling information through a variety of syntax formats, allowing the formalization of a wide variety of resources as well as resources state. The idea to use RDF to describe networks related concepts is not new. The Network Description Language (NDL) proposed in V provides ontology for computer networks and can be used to easily describe, for instance, a network topology. We follow here the same principle, nonetheless NDL alone is not enough for our purposes, since it focuses on the description of network elements. Here we need to cope with network resource requests. Therefore we need a RDF syntax that is able to describe communication needs, general enough to provide network information exchange independently from the networking technology. We call this language Network Resource Description Language (NRDL). Thanks to NRDL each communication can be enrich with detailed information about QoS and network requirements (i.e. Bandwidth, jitter, delay, etc...). Because of space reasons we can not go into a detailed description of the NRDL ontology, that will be the subject of a further work. C. Overview of SOON The SOON V mediates the interaction between qualified pplications, e.g., Proxy SIP Server, and (G)MPLS networks for the invocation of QoS-enabled and high-bandwidth connectivity services. The SOON architecture implements a Service Plane (SP), acting on top of the (G)MPLS CP (see A). Specifically the

3 3 SP exploits the source-initiated GMPLS CP signaling for providing on-demand transport network services with a level of abstraction suitable for being invoked by applications, i.e. in terms of end-host address and perceived quality of service. This is achieved through a distributed signaling among service elements that consists in one Centralized Service Element (CSE) and a number of Distributed Service Elements (DSEs), one for each edge network node. The CSE, not shown in the figure, performs application identification and authorizes the relevant service requests using the information stored in its Service Level Agreement (SLA) database. The DSE processes network service requests issued by applications, AO-M in this work. To fulfil the service request, the DSE triggers a signalling message exchange with the CSE to authenticate and authorize the application, and with the DSEs involved in the service provisioning in order to agree on the network wide settings to be performed on the edge network nodes. Then the involved DSEs issue the technology-dependent primitives to the controlled edge network nodes. These primitives may include configuration commands, e.g., circuit set-up, as well as the resource status monitoring, e.g., link bandwidth availability check. The involved DSEs are obtained from the information stored in the Network Topology Resource Database (NTRD). The implementation of DSE and CSE and how the NTRD is filled has been described in V. D. Principle of operation The proposed architectures follows in principles three different phases. For sake of simplicity in Fig. 2 there is an example of an user wanting to transfer a bulk of data to a storage location over a data communication channel of given characteristics. In order to start the communication session the following steps should be performed; Publish: the Resource User Agent (UA 2 ) should publish to the AO-M its own application resources by means of a NRDL description encapsulated into the body of a generic SIP PUBLISH message. This stage allows the collection of the application resources in the Application Oriented Network module. The AO-M must know the availability of the storage location that has been published (Fig. 2 (a)). Search: since AO-M is aware about the application resources submitted into its own domain, the user (UA 1 ) investigates such resources availability sending a SIP SUBSRIBE message to the AO-M including the required communication needs to finalize the transfer (Fig. 2 (b)). The SUBSCRIBE message transport in its body an NRDL description collecting both the enquiries to the application resources and the network details. The AO-M search into the published resources if the requested application resources are available and subsequently dialog with SOON to check the required transport resources (Fig. 2 (b )). The user will be advised by means of SIP NOTIFY message regarding the detailed position and availability of the resources (Fig. 2 (c)). Reserve: the user can apply for a reservation as soon as the position and the availability of the resource is found into the network. The reservation phase follows an enriched reservation schema of a standard SIP network. The starting of any communication session is realized by means of a multipart INVITE SIP message encapsulating an application protocol and a NRDL document (Fig. 2 (d)). The standard INVITE request couples with the NRDL document is able to specify a set of network requirements that are preconditions to application session. The AO-M will dialog with SOON to reserve the required network resources expressed into the NRDL (Fig. 2 (d )). The detailed procedure will be explained in Section IV. AO-M SIP-M SOON User (UA 1 ) Resource (UA 2 ) (b) (c) (d) SUBSCRIBE NOTIFY INVITE PUBLISH CHECK (b ) RESERVE (d ) (a) Figure 2. Example of operation at the application level: publication, discovery, notification and reservation, all supported by the SIP protocol and centered on the AO-M. III. MAPPING TO NGN This section provides the mapping between implemented building blocks with NGN functionalities to show the correspondence of this research work with standard NGN principles V. NGN NGN terminal terminal Customer Customer Premises Premises Equipment Equipment End-User Functions Service Stratum Service Control Function (SCF) NACF NACF Figure 3. Rs RACF Transport Function Transport Stratum The NGN architecture Referring to Fig. 1, the NGN architecture is composed of two sets of functionalities, named Service Stratum and Transport Stratum. To the purpose of this work, the main Service Stratum functional entity is the Service Control Function (SCF). The SCFs include resource control, registration, and authentication and authorization functions Other NGN

4 UA UEA A (1) INVITE SIP-M NRDL Service Resource Availability (2) (3) at the service (1 ) level and trigger the network resources reservation by interacting with the Transport Stratum V. The SCF is responsible for extracting service requirements Service NRDL from service (11) signaling and (11 ) INVITE sending a (12) request to RACF for (13) network resource authorization (14) and ACK reservation. (15) Practically, the SCF DATA TRANSFER represents the signalling within a service provider infrastructure among, e.g., SIP Proxy Server or Video Server, for the control of application resources involved in the content transmission, such as codec, delay bound, max bandwidth, during a e.g., SIP-based call or multimedia transfer. From a functional point of view the SCF corresponds to the AO-M, specifically to the SIP-M and NET-M. The Transport Stratum provides IP-based connectivity services for the benefit of SCFs with the support of the Network Attachment Control Function (NACF) and the Resource and Admission Control Function (RACF). NACF support RACF with information related to subscription profile. RACF provides an abstract view of transport network infrastructure to the SCF such as network transport technology, network topology, connectivity, resource utilization and QoS mechanisms. The RACF executes policybased transport resource control upon the request of SCF, determines transport resource availability, makes admission decision, and applies controls to transport functions. V. From this we can argue that from a functional point of view the RACF and NACF correspond to the SP for (G)MPLSenable transport networks V. NET-M UA b DSE PD-FE 3 DSE TRC 1 G - FE 2 ICC2009, Hammamet Tunisia, May 2009 Resource (6) Availability Network reservation through DSE 3 Connectivity set-up Bandwith availability (4) Bandwith availability (5) Connectivity set-up Connectivity (7) set-up (7) (10) (8) (9) ER1 PE1 DSE 2 We start with a few implementation details: the SIP-M has been built using an opensource SIP proxy ( the APP-M and the NET-M has been implemented by means of an ad-hoc opensips external modules which define an NRDL parser and the interface to SOON. The SIP User Agents (UA) used as end-user terminals are based on the PJSIP stack ( enhanced with the capability to send a multipart INVITE massage and an NRDL module. The NRDL modules have been implemented exploiting the RAPTOR RDF parser ( In this proof of concept test-bed the NRDL has been provided with the capability to request a predefined bandwidth and Class of service only. The Service Plane is composed by 3 Linux Boxes, each of them running an instance of the DSE module and equipped with Linux v2.6 operating system and have public IP addresses to assure the complete reachability. The DSEX controls the ERX (with X=1, 2, 3) issuing NETCONF directives V. Each Linux Box has been provided with Ethernet interface connected to the controlled ER and set with a public IP. ER2 PE3 4 (8) (9) IV. EXPERIMENTAL ACTIVITY A. Test-bed Description This section presents the testbed used to validate the proposed architecture and examines a signalling example.

5 5 UA a CE SP DSE1 DSE3 AO-M ER3 ER1 CR CR CR FE IP/ MPLS Metro Network Figure 4. ER2 DSE2 Test-bed architecture CE UAb The metro-core network comprises six IP/MPLS routers that are interconnected as shown in Fig. 4. The routers called ER1, ER2 and ER3 are configured as provider Edge Router (ER). The routers named CR are configured as core routers. All the six routers are equipped with Fast Ethernet (FE) interfaces and support MPLS, OSPF, and RSVP protocols with extension for DS-TE V. Without lacking in generality, we consider only one AO-M couples to DSE3. B. Use Case An example of how the test-bed works is provided with reference to Figure 5. Here a UA A and UA B are pre-registered as authorized users in the SIP-M. At some stage UA A wants to establish a communication session with the UE B (e.g. if UA B is video server UA A wants to download a video). UA A sends an INVITE message made of two parts; an application protocol describing the session (e.g. SDP) and an NRDL document containing the network resource requests. Then, the SIP-M decouples the message body and sends the NRDL part to the NET-M (1 ). The NET-M sends a Service (2) to DSE3 to reserve resources for a QoS-enabled data transfer across the MPLS network. Such a request contains the IP addresses of UA A and UA B (available at SIP-M upon registration) as well as the service parameters extracted from (1), i.e. bandwidth, grade of service, etc... DSE3 obtains the addresses of the relevant ERs (i.e., ER 1, ER 2 ), and of the DSEs connected to those ERs (i.e., DSE 1, DSE 2 ) thanks to the information stored in NTRD. Then, DSE3 translates the service parameters into network resource requirements, i.e. needed bandwidth (e.g., 20Mbit/s for HD video transfer) and category of traffic (e.g.., delay-sensitive traffic). Subsequently sends a Resource Availability (3) to DSE 1 linked to ER1 containing such requirements. Upon receiving Resource Availability, the TRC- FE 1 sends a Bandwidth Availability (4) to the ER1 to get the bandwidth that is actually used by existing voice packet transfers between ER1 and ER2. Specifically, the transmit rate is requested of queue dedicated to transfer delaysensitive packets at the output interface towards ER2. When receiving the Bandwidth Availability (5), the DSE 1 compares the available bandwidth with the requested bandwidth and sends the Resource Availability (6) to DSE3. If the bandwidth is available, the DSE3 sends to the DSE1 and DSE2 the Connectivity Set-up (7) to enforce the proper traffic policy that enable the media flow generated by UE terminals to be mapped to the pact connecting ER1 and ER2. Accordingly DSE1 and DSE2 issues the NETCONF directives, i.e., (8) to the correspondent ERs that in turn performs the requested configuration and sends back the (8) containing information about the success or failure of such configuration. Accordingly, the DSE1 and DSE2 the result of router configuration to DSE3 that in turn sends the Service (11) to NET-M with the value ACK if the configuration has been properly performed, otherwise it sends a NACK. When the resource reservation has been successfully realized, the NET-M sends back to SIP-M a NRDL document with the current network status (11 ). The NRDL is reattached to the body of the INVITE message in order to keep the network status along the SIP path. Then, the INVITE message is forward to the destination (12). UE b replies with a message to the SIP-M encapsulating, in the body, its own application protocol and an NRDL document containing the network requirements from the UE b point of view (13). The message goes through the SIP-M which extract the NRDL in order to perform the network reservation by means of NET-M. When the transport has been reserved the is forwarded to the UE a (14) and an ACK follow to positively close the session (15). The data exchange can start into the reserved channel across the transport network. V. CONCLUSION In this paper we have shown an architectural implementation of an application-aware optical network. To this end the Session Initiation Protocol is used on top of the SOON architecture to establish application sessions according to the application requirements and then the network control plane is triggered, exploting the DSEs, to create the required transport network. This approach in principle enriches the network with a number of application oriented features thanks to the rich session oriented semantic of SIP and RDF. ACKNOWLEDGMENT The Authors wish to thank Mr. Filippo Zangheri and Mr. Karim Torkman for their contribution to the implementation of the test-bed. REFERENCES [1] RFC 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture IETF, October [2] G. Klyne, J.J. Carroll, Resource Description Framework (RDF): Concepts and Abstract Syntax. W3C Recommendation, 2004, [3] Jeroen van der Ham, Paola Grosso, Ronald van der Pol, Andree Toonk and Cees de Laat. Using the Network Description Language in Optical Networks. In: Tenth IFIP/IEEE Symposium on Integrated Network Management, May 2007 [4] B. Martini, F. Baroncelli, P. Castoldi "A Novel Service Oriented Framework for Automatically Switched Transport Network" 9th IFIP/IEEE International Symposium on Integrated Network Management (IM), May 2005, Nice, France.

6 6 [5] G. Zervas et al., SIP-enabled Optical Burst Switching architectures and protocols for application-aware optical networks, Computer Networks, 2008, doi: /j.comnet [6] Keith Knightson et al NGN Architecture: Generic Principles Functional Architecture, and Implementation. Communications Magazine, IEEE, Oct. 2005, Volume 43, Issue 10. [7] F. Baroncelli, B. Martini, V. Martini, and P. Castoldi A distributed signaling for the provisioning of on-demand VPN services in transport networks, Integrated Network Management (IM) 2007, Germany, Munich, May 2007 [8] F. Baroncelli, B. Martini, V. Martini, and P. Castoldi "Supporting Control Plane-enabled Transport Networks within ITU-T Next Generation Network (NGN) architecture, Network Operation and Management Symposium (NOMS) 2008, Brazil, Salvador, April 2008 [9] ITU-T Y.2001, General overview of NGN. December 2004 [10] ITU-T Y.2012, Functional requirements and architecture of the NGN release 1, September 2006 [11] ITU-T Y.2111, Resource and admission control functions in next generation networks, September 2006 [12] R. Enns, NETCONF Configuration Protocol, IETF RFC 4741, December 2006 [13] F. Le Faucheur, W. Lai, Requirements for Support of Differentiated Service Aware MPLS Traffic Engineering, IETF RFC 3564, July 2003