Configuration of Network Resources for Future Internet ... - IEEE Xplore

Future Network and MobileSummit 2010 Conference Proceedings Paul Cunningham and Miriam Cunningham (Eds) IIMC International Information Management Corporation, 2010 ISBN: 978-1-905824-18-2

Conguration of Network Resources for Future Internet Application Services F. Callegati1 , W. Cerroni1 , B. Martini2 , M. Gharbaoui3 , A. Campi1 , P. Castoldi3 , 1 DEIS University of Bologna, via Venezia 52, 47521 Cesena (FC), Italy Tel: +39 0547 339209, Fax: +39 0547 339208, Email: walter.cerroni,aldo.campi,[email protected] 2 CNIT, via G. Moruzzi 1 56124 Pisa, Italy Tel: +39 050 5492245, Fax: +39 050 5492194, Email: [email protected] 3 Scuola Superiore Sant’Anna, via G. Moruzzi 1 56124 Pisa, Italy Tel: +39 050 5492152, Fax: +39 050 5492250, Email: m.gharbaoui,[email protected] Abstract: This paper describes a possible approach to provide application- awareness capabilities to the transport network infrastructures of the Future Internet. This is achieved by introducing a signalling scheme enabling the application to automatically negotiate with the network the transport resources they require. The signalling workow is detailed and the scalability of the proposed solution is evaluated through an experimental test-bed. Keywords: networks.

1.

Application oriented networking, Future Internet, SIP, NGN, Optical

Introduction

The current Internet offers an end-to-end transport service able to interconnect different and heterogeneous applications on top of a flat network layer focusing on packet routing. IP provided a unified access to networking facilities and has indeed been the stronghold of the Internet success. Nonetheless, the effectiveness of this approach is starting to vanish today, as a consequence of the introduction in the network of functions and sub-blocks (e.g., NATs, firewalls or even application layer switching) not envisaged at the time IP was designed [1]. As a result the transparent access to the networking technology is vanishing and applications need to be more and more network-aware. This goes together with the evolution of the applications towards often requiring effective support of Quality of Service (QoS) and large scale bandwidth provisioning from the network. The deployment of new communication services (as well as communication service management) must take the aforementioned issues into account. In current scenarios, applications typically talk end-to-end and resource management is provided by means of centralized application services (e.g. web-services in Grid computing [2]). This is a typical overlay approach, that may result in inefficiencies in the use of the network resources and in limited functionalities. A more integrated and effective approach assumes that the current Internet evolves into a more applicationaware networking infrastructure. To this end a whole set of new signalling schemes has to be conceived, which enables the applications to interact with the network and to negotiate the resources needed to activate the requested communication service. Therefore the Future Internet should be more service-aware, providing built-in functionalities to match communication resources with service requests [3]. This is in line c The authors Copyright 

www.FutureNetworkSummit.eu/2010

1 of 8

with the Next Generation Network (NGN) specifications, which outlines a clear separation between the service stratum responsible of network service provisioning and the transport stratum responsible of IP-based packet forwarding [4]. The service stratum addresses the management and creation of network services, in order to enable direct invocation of network resources with proper grade of service in the transport stratum [5]. The final vision includes a new generation of IT applications capable to trigger the set-up of connectivity services across high-capacity transport networks during the set-up phase, i.e., to perform “on-demand” service provisioning, possibly negotiating Quality of Service (QoS) requirements. Unfortunately applications and networks speak very different languages today, so the question is: what is needed to allow this further step forward? Indeed the answer has to be in the definition of a proper signalling layer, which should be responsible of: • making the applications capable of exchanging semantically rich messages with the network to issue service requests for the negotiation and reservation of the needed resources; • defining a “technology-independent” methodology to provision the network resources by mapping the service requests into network control plane directives. This paper describes the experimental set-up of a novel signalling architecture that may provide an answer to the aforementioned needs and reports some quantitative results on its performance. The proposal stems from the merging of preliminary works which addressed the design of application-oriented signalling over high performance networks [6] and the translation of service requests into network-specific directives by means of a service architecture for transport networks, called Service Oriented Optical Network (JOCN2009) [7]. The basic idea is to enrich the network with new functionalities into a signalling plane tailored to service configuration.

2.

Proposed Signalling Platform

The functional architecture of the proposed service signalling platform has been extensively discussed in [6], [7], [8] and here it is briefly described referring to the test-bed set-up shown in Fig. 1. From an architectural point of view, the service platform can be decomposed in three functional layers, or planes: • Application-Oriented Plane (AOP), which manages session-based signalling among applications enhanced with resource management capabilities (large dashed arrows in Figure 1), regarding both IT resources (i.e., remote storage space, multimedia content) and network resources (i.e., QoS-enabled media flows). The Application-Oriented Plane signalling is processed into specialized network nodes called Application-Oriented Module (AO-M), where different sub-modules are in charge of: – processing the incoming resource requests (APP-M); – managing the service sessions by means of the SIP protocol (SIP-M);

c The authors Copyright 

www.FutureNetworkSummit.eu/2010

2 of 8



  

 



 





 

  

 

Figure 1: Architecture of the SIP-based service-oriented network test-bed.

– interacting with the underlying Service Plane for issuing connectivity service requests to activate the QoS-enabled media flow transfer (NET-M). The latter requests trigger the actual network resource provisioning across the network and are specified in terms of end-host addresses and perceived quality of service. • Service Plane (SP), which elaborates the connectivity service requests issued by the AO-M (small dashed arrows in Figure 1). Specifically, the SP performs the admission control and, in case of resource availability, it fulfils each request by configuring the network-specific traffic policies on the relevant edge routers in a consistent way (continuous arrows in Figure 1), in order to enable a data flow with the required QoS assurances between end-hosts. This operation is based on a distributed signalling (dotted arrows in Figure 1) among “service nodes” called Distributed Service Elements (DSE). • Network Layer, which is responsible for data forwarding (thick line as an examples of data path in the network). In addition to the layers specified above, a framework to describe both networks and non-networks resources in an abstract way at the application level is required. This was implemented by exploiting the Resource Description Framework (RDF)1. The idea of using RDF to describe network-related concepts is not new. The Network Description Language (NDL) [9] provides ontology for computer networks and can be used to easily describe, for instance, a network topology. Nonetheless, NDL focuses on the description of network elements and does not cope with network resource requests. Therefore a new RDF syntax has been proposed that is able to describe “communication needs” and is general enough to provide network information exchange independently of the underlying networking technology. This language was called Network Resource Description Language (NRDL) and is described in some detail in [10]. Thanks to NRDL 1

RDF is a general-purpose language, dened by W3C, for representing information and provides general method of modelling information through a variety of syntax formats, allowing the formalization of a wide variety of resources as well as resource states. c The authors Copyright 

www.FutureNetworkSummit.eu/2010

3 of 8

each communication can be enriched with detailed information about QoS and network requirements (i.e. bandwidth, jitter, delay, etc...).

3.

The signalling test-bed

3.1 Test-bed architecture In the test-bed set-up used for experimental validation both the AO-M and the DSEs are implemented by means of Linux boxes. Without lack of generality the test-ebd deploys one AO-M managing and three DSEs, coupled with 3 edge routers. The AO-M has been implemented by extending common open-source SIP software. The SIP-M is a SIP proxy based on the OpenSIPs distribution, version 1.4.2. The NET-M and APP-M are modules of the OpenSIPs software, written in C++. The APP-M uses the Raptor 1.4 library to parse NRDL messages. The SIP User Agent used to emulate the applications is built starting from the PJSIP stack library. The DSEs are connected to both the public Internet and to the Edge Router (ER) of the transport network. Each DSE controls the corresponding edge router by issuing NETCONF directives [11] while inter-DSEs communication is based on XML messages. The metro-core network comprises six IP/MPLS commercial routers, of which three are configured as provider edge routers and three are configured as core routers. All routers support MPLS, OSPF and RSVP with extension for DiffServ-aware Traffic Engineering (DS-TE) [12] for enabling the reservation of network resources on a pertraffic class basis. The SIP User Agents are connected to the transport network via routers configured as Customer Edge (CE) nodes, connected to the transport network through VLANs that isolate the traffic flows of different application categories, e.g., video, voice, data. In the experiment the case of video traffic was considered. An LSP is established between ER1 and ER2 (LSP-video) with reserved bandwidth of 80Mbit/s and with queue schedulers configured accordingly in both core and edge routers to guarantee rate assurance to video packet delivery. Upon service request, a portion of such bandwidth is guaranteed for the media flow between the UAC and UAS through traffic policy settings. 3.2 Signalling workow and Call Set-up Delay The signalling workflow is shown in Fig. 2. When the UAC sends, at time t1 , a requests for a given service (e.g., HD video) to be provided by the UAS, an INVITE message is forwarded to the AO-M including the description of the required network resources (e.g., media flow with HD video quality). The SIP-M sub-module, acting as an enhanced SIP Proxy Server (PS), processes the INVITE message, extracts its content and passes the network resource specifications (using NRDL) to the NET-M, thus triggering NET-M to issue a connectivity service request (SRQ) to the DSE3 for network resource reservation. The service request consists of an XML file including the UAC and UAS IP addresses and the service requirements: service type (i.e., video flow) and quality level (i.e., HD). The DSE3 determines the edge routers to be involved as well as the traffic category and amount of bandwidth (e.g., 20 Mbit/s for HD video) to be reserved within LSPvideo. The DSE3 verifies (RARQ), with the support of DSE1, whether such bandwidth is available across the network (BARQ) and, in case of positive response, it triggers the bandwidth reservation by asking the DSE1 and the DSE2 (CSRQ) to enforce traffic

c The authors Copyright 

www.FutureNetworkSummit.eu/2010

4 of 8

Figure 2: Message ow used by the SIP-based signalling scheme and list of acronyms used.

policies on both ER1 and ER2 (NSRQ) that assure the proper forwarding of video packets across the LSP carrying video traffic. When the reservation is complete, DSE3 confirms to the NET-M that the requested resources are available (SRP) and the NET-M triggers the SIP-M to complete the session set-up (NRDL carries the details of the resources now available to the service request). The INVITE message is then received at time t2 by the UAS that replies with an OK message at t3 , as required by the SIP three-way handshake. The ACK sent by UAC at t5 concludes the session setup and data can now flow on the LSP-video with the required QoS. ITU-T recommendation Y.1531 [13] reports the specifications for the performance parameters defined for call processing, where by call is intended a generic media session between end-users established using SIP or H.323. The Call Set-up Delay (CSD) is defined as the overall time needed to establish the call between the end-hosts (i.e., SIP terminals). Specifically, the CSD is the time elapsed between the caller’s issuance of a SIP INVITE message at the caller UNI and the callee’s receipt of the corresponding SIP ACK message at the callee UNI, excluding: • the callee delay, between the callee’s receipt of the INVITE message and issuance of the corresponding 200 OK message; c The authors Copyright 

www.FutureNetworkSummit.eu/2010

5 of 8

• the caller delay, between the caller’s receipt of the 200 OK message and issuance of the corresponding ACK. Using the notation of Fig. 2, the formal definition of the CSD is CSD = (t6 − t1 ) − (t3 − t2 ) − (t5 − t4 )

(1)

Basically the CSD takes into account the transfers and delays associated with the internal network functions that occur between end-hosts, which implement admission control and resource reservation across the transit networks, i.e., the IP/MPLS network. The ITU specification is taken as the reference against which the performance of the proposed service platform has to be validated.

4.

Experimental results and discussion

The experimental validation of the proposed service platform was carried out in the testbed of Fig. 1. The experiments focused on the evaluation of the CSD to be compared with the ITU-T specifications. It is important to outline that the CSD is the result of the sum of two main contributions: the SIP signalling response time and the router configuration response time during the commitment phase. In practice, the signalling messages are elaborated in the AO-M and in the DSEs, and this processing takes some time. Then the DSEs check for bandwidth availability and send NETCONF directives to the routers, which take some time to reconfigure themselves in order to deploy the required settings. The latency due to this commitment phase is crucial in determining the CSD, as shown in the remainder of this section. In the experiments the CSD was obtained as the average of N samples, that are N call set-up requests, generated according to two different traffic profiles: deterministic, with N = 30 requests periodically generated from the UAC and interleaved by a fixed inter-arrival time (IAT) value; Poisson, with N = 100 requests spaced by exponentially distributed inter-arrival time with a given average value. All requests are related to the same LSP-video resource as previously described. In order to evaluate the latency due to the signalling in the AOP and SP only, a first set of experiments have been executed by neglecting the time required by the commitment phase, i.e. assuming a zero delay due to bandwidth availability check and router configuration operations. The software implementations of SIP-M and DSE have been designed to execute a suitable number of threads in parallel, so they do not become bottlenecks due to the lack of computational resources in the service plane. Common up-to-date computing hardware has been used to run such processes with satisfactory performance obtained for fixed or average inter-arrival times in the range between 0.5 and 2.5 seconds, demonstrating the scalability of the proposed signalling scheme. In fact, the average CSD, measured with 95% confidence interval, was 1.68 ± 0.24 s and 2.74 ±0.46 s for deterministic and Poisson arrivals respectively. Therefore the measured CSD stays well below the 7.5 s threshold recommended by ITU-T in Y.1530 [14], even in case of high request rates (e.g., two per second) asking for the same network resource. Indeed, a more realistic evaluation of the CSD needs to include also the latency due to the commitment tasks executed in the routers. This is a quantity that depends on many factors: router manufacturer, router hardware equipment, type of router network interfaces, complexity of the reconfiguration to be performed, etc. Therefore, since a blind evaluation of the CSD in the existing experimental set-up would be of little c The authors Copyright 

www.FutureNetworkSummit.eu/2010

6 of 8

40 35

IAT = 5s IAT = 6s IAT = 8s IAT = 10s

Average CSD (s)

30 25 20 15 10 5 0

1.5

2

2.5

3

3.5

Router configuration latency (s)

Figure 3: Impact of the committment phase latency on CSD.

meaning, it was decided to emulate the time required by the commitment phase in the routers by setting it to increasing values from 1.5 to 3.5 seconds, while evaluating the whole CSD. The goal is to understand at which point the commitment response time becomes critical for the overall CSD as a function of the request load. The results are reported in Fig. 3 where the CSD is plotted as a function of the router configuration latency (i.e. the duration of the commitment phase), varying the average inter arrival time as a parameter. The figure also shows the 95% confidence intervals. From the graphs in the figure it is easy to see that the router latency does not impact the CSD when the IAT is rather low (for an IAT=10 s the CSD is below or in the range of the ITU threshold). However, when the IAT decreases the router latency becomes more and more important to determine the CSD and may have a rather detrimental effect on the overall performance. Given the response time of the router configuration, the plot allows to dimension the rate of requests asking for a given network resource that can be satisfied while maintaining the CSD under the recommended threshold. The upper bound of 3.5 s chosen for the router configuration delay refers to the value attainable with the current technology, as resulted from measurements performed on our test-bed.

5.

Conclusion

A possible approach to the implementation of application-aware network architectures suitable for the Future Internet services was presented in this paper. The proposed signalling scheme allows users and applications to automatically negotiate and dynamically obtain network resources based on their needs. A SIP-based implementation of the required signalling scheme has been presented and its scalability evaluated through an experimental test-bed. In particular, the role of the commitment phase has been assessed with reference to the latency perceived by the user/application.

c The authors Copyright 

www.FutureNetworkSummit.eu/2010

7 of 8

6.

Acknowledgements

The work described in this paper was carried out with the support of 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.

References [1] J. Rosenberg, “UDP and TCP as the new waist of the internet hourglass,” IETF draft (expired), IETF, February 2008. [2] I. Foster, H. Kishimoto, and A. S. (eds), “Open grid service architecture v1.0,” Tech. Rep. GFD-I.030, OGF, January 2004. [3] A. Galis, H. Abramowicz, and M. B. (eds.), “Management and service-aware networking architectures for future internet,” position paper, MANA Future Internet group, 2009. [4] K. Knightson, “NGN architecture: Generic principles functional architecture, and implementation,” IEEE Communications Magazine, vol. 43, no. 10, 2005. [5] J. Song, M. Chang, S. Lee, and J. Joung, “Overview of ITU-T NGN QoS control,” IEEE Communicaion Magazine, vol. 45, 2007. [6] F. Callegati, A. Campi, G. Corazza, D. Simeonidou, G. Zervas, Y. Qin, and R. Nejabati, “SIP-empowered optical networks for future it services and applications,” IEEE Communication Magazine, vol. 47, pp. 48 – 54, May 2009. [7] B. Martini, “Application-driven control of resources in multiservice optical networks,” IEEE/OSA Journal of Optical Communications and Networking (JOCN), vol. 1, pp. 270–283, July 2009. [8] B. Martini, A. Campi, F. Baroncelli, V. Martini, K. Torkman, F. Zangheri, W. Cerroni, P. Castoldi, and F. Callegati, “Sip-based service platform for on-demand optical network services,” in Optical Fiber Communication Conference (OFC), (San Diego, USA), OSA, March 22 - 26 2009. [9] J. van der Ham, P. Grosso, R. van der Pol, A. Toonk, and C. de Laat, “Using the network description language in optical networks,” in Proc. of Integrated Network Management (IM), May 2007. [10] A. Campi and F. Callegati, “Network resource description language,” in Proc. IEEE GLOBECOM Workshops, pp. 1–6, Nov. 30 2009–Dec. 4 2009. [11] “Rfc 4741 - NETCONF configuration protocol,” RFC 4741, IETF, 2006. [12] “Rfc 3564 - requirements for support of differentiated service aware MPLS traffic engineering,” RFC 3564, IETF, 2003. [13] ITU-T, “SIP-based call processing performance,” Tech. Rep. Y.1531, ITU, 2007. [14] ITU-T, “Call processing performance for voice service in hybrid IP networks,” Tech. Rep. Y.1530, ITU, 2007. c The authors Copyright 

www.FutureNetworkSummit.eu/2010

8 of 8