Implementation and Evaluation of a Generic IP

Signaling ProtocolNadia BOUKHATEM" , Thanh Tra LUU 2

'Computer Science & Network Department, ENST -Telecom Paris46 rue Barrault, 75013 Paris, France

2Ho Chi Minh city University ofTechnology268 Ly Thuong Kiet, District 10, Ho Chi Minh city, Vietnam

boukhatem@enst.fr2luu@hcmut.edu.vn

Abstract - To contribute to the effort of the NSIS (Next Steps InSignaling) IETF working group in defining a generic IP signalingprotocol, we designed the GISP (Generic sIgnaling ServiceProtocol) protocol. In this paper, we summarize the GISPcharacteristics and focus on implementation aspects andperformance results of the GISP signaling system. We studyvarious performance aspects such session setup latency, memoryand CPU consumption. Our results highlight good performanceof the GISP and validate the implementation choices.

I. INTRODUCTIONThe evolution of the Internet towards a multi-service

network has lead to the development of a large number ofsignaling protocols [1][2][3][4][5][6]. RSVP [1] standard wasoriginally designed to support resource reservation, itsextension RSVP-TE [2] is to establish and maintain labelswitched paths in MPLS networks as many other protocolssuch as CR-LDP [3] ...Besides the QoS provisioningobjective, IP signaling protocols are currently needed toprovide dynamic configurations as middle-boxes(NAT/Firewalls) configuration [7]. To deal with the largenumber of IP signaling protocols, the IETF has created theNSIS (Next Steps in Signaling) working group [8] to designand standardize a generic signaling protocol supporting alarge variety of signaling objectives and managing general-purpose states. The development of a generic IP signalingprotocol which meets various signaling objectives canconstitute not only a flexible solution but also an effective onein term of development costs, signaling compatibility, andoperation/management costs.The NSIS WG is considering protocols for signaling

information about a data flow along its path in the network.This assumes that the path taken by the data flow is alreadydetermined (by routing, for example). The signaling concernsthe installation and/or manipulation of state related to the dataflow on the nodes along the data flow path. Thus, the NSISsignaling problem is very similar to that addressed by RSVP.However, the NSIS WG explicitly intends to simplify theRSVP signaling and generalize it to support various signalingapplications. In this paper, we present the implementation ofthe GISP (Generic sIgnaling Service Protocol) we developedfollowing the NSIS requirements and in concordance with theprotocol architecture suite defined by the NSIS workinggroup. To achieve generalization, the NSIS protocol stack isdecomposed into two layers [9]. The generic lower layer,NTLP (NSIS Transport Layer Protocol), is responsible fortransporting the signaling messages and supporting the statemanagement. These functions are independent of anyparticular signaling application. The upper layer, NSLP (NSIS

Signaling Layer Protocol) is specific to a signalingapplication. There can be an NSLP for resource reservation[10], an NSLP for middlebox configuration [11], etc.However, the NSLPs will use the common NTLP protocol totransport the signaling messages for their own signalingpurposes. The main advantage of this layer model is itsextensibility. Indeed, developing a new signaling applicationis reduced to implementing a new NSLP, but not the transportand state management functions which are provided by theNTLP layer. However, this requires that NTLP must beflexible and efficient enough to support existing and futuresignaling applications. The GISP protocol is animplementation of the NTLP layer. The complete specificationof the GISP protocol can be found in [12]. Details on transportmechanisms, state management and its performance are givenin [13, 14]. In this paper, we emphasise the implementationaspects and performance results of the GISP signaling system.This paper is organized as follows. Section II provides onoverview on the GISP functionality in term of signaling andtransport services. In section III, the implementation details ofthe GISP signaling system are provided. Section IV is devotedto the GISP implementation. Performance results and analysisare presented in section V. Section VI presents our conclusionand future work.

II. THE GISP FUNCTIONALITYIn the following section, we summarize the signaling and

transport services of GISP.

A. The GISP Signaling serviceThe GISP uses the soft-state model to manage the session

information in the signaling aware entities. This means thatafter being established on an entity, a state will be deleted onthat entity if it is not periodically refreshed during a specifictime interval.1) GISP state management modes and messages

The GISP defines various state management types toindicate how the state is established on the signaling path. Thestate management mode is specified by the state management(SM) field in the GISP message header (see [12] for moredetails). The GISP can request installing states on only thesignaling initiator and signaling responder (SM=O), on all theGISP-aware nodes of the data path (SM=1), on nodes whichsupport a specific NSLP (SM=2) and on NSLP-aware nodesaccording to the decision of the supported NSLP (SM=3).

In GISP two states are associated with a session: forwardstate and backward state. The forward state concerns the

information sent by the signaling initiator which initiates thesignaling session, along the downstream path. The backwardstate concerns the information sent by the signaling responderwhich terminates the signaling along the reverse data path.

Three message types are defined in GISP. The NEWmessage is defined to establish the forward state for thedownstream path between two signaling entities. In particular,it is dedicated to establish new sessions. The MOD message ismainly defined to modify a forward state of a session andestablish the backward state. The INFO message isresponsible for exchanging information between adjacentsignaling entities (SE). The information concerns statemanagement (refresh, delete an established state), reliablemessage delivery (acknowledge a message) or otherinformation (congestion control, error notification, etc).2) State refresh mechanism

One of the innovations of the GISP protocol lies in itsrefresh mechanism which improves those implemented inRSVP and RSVP extensions [2] by reducing the refresh cost.

In the GISP protocol, each signaling-aware node maintainsa common list of established sessions between a particularpeer of signaling-aware nodes. We refer to this list asRefresh list. Each entry of the list is referred to as Refresh_ID(index number). Each Refresh ID is associated with a sessionvalue to identify a specific established session between twoadjacent SEs. The signaling protocol chooses a Refresh IDfor each new session and this value is not reused until thesession is deleted. Rather than sending individual Refresh_IDsto refresh sessions, the signaling protocol sends ranges ofconsecutive Refresh IDs, each range is identified by the firstand the last Refresh IDs. This mechanism aims to reduce theoverhead of the signaling traffic used to refresh the statesbetween two nodes by sending the block of Refresh IDs. Tominimize the number of ranges (we refer to as blocks), whenestablishing a new session, the signaling protocol chooses theunused Refresh ID which locates right before the first block(if exists) or right behind the first block. The details on therefresh mechanism and its performance results, in term oftraffic overhead reduction, can be found in [14]

B. The GISP Transport serviceAs mentioned previously, the GISP is designed to directly

run on IP or UDP. These protocols do not meet all therequirements of the transport service defined by the NSISWG. The GISP therefore is designed to support all therequired NTLP transport services such as reliable messagedelivery, message bundling, message fragmentation andcongestion control.

1) Message BundlingThe GISP is designed to support message bundling. Indeed,

the GISP allows sending more than one NSLP message in asingle GISP message by wrapping the NSLP messages in theGISP message objects.

2) Message fragmentationIn the GISP, we defined a simple mechanism to detect the

MTU between signaling aware nodes. This MTU discoverymechanism avoids the messages being dropped when theirlength is larger than the link MTU [12]

3) Partial reliable message deliveryThe GISP supports the partial reliable message delivery.

After sending a signaling message, The GISP must wait forthe acknowledgement of the message. If the message is lost, itmust retransmit the message during a specific time interval. Incase of unreliable message delivery, the GISP does notretransmit the messages if lost.

4) Congestion controlThe GISP supports congestion control for the signaling

traffic to keep the network from congestion and to prevent theburst of signaling traffic. The GISP defines two congestioncontrol mechanisms for two different cases. In the first case,before sending a message, GISP cannot determine the nextsignaling entity along the data path. This can be since theforward state is not established yet or since the stateestablishment is not required. For this case, to avoidimplementing a complex mechanism, the GISP only limits themaximum signaling traffic rate and does not allow thesignaling traffic increment to be more aggressive than the TCPtraffic. In the second case, before sending a signalingmessage of a session, GISP can determine which SE willreceive the message. In this case, the GISP re-uses congestioncontrol principles of SCTP (RFC2960 [15], RFC3758 [16]),DCCP [17], and TCP (RFC2581 [18]) to control the signalingtraffic between two adjacent SEs.

III. THE GISP IMPLEMENTATION

A. The signaling system architectureThe overall GISP signaling architecture consists of the

following components. The GISP Block implements all thefunctionality of the GISP protocol and communicates with theNSLP Block. The latter represents the signaling applications(NSLPs) which rely on the GISP block to realize theirsignaling objective such as resource reservation, middleboxconfiguration, etc. The Application Block represents the userapplications which request a signaling service from the NSLPlayer for example, videoconferencing applications, VToIPapplications, etc. To ensure monitoring, configuration andsupervision of the GISP protocol, we also defined theManagement Block. It is responsible for acquiring informationon the GISP operation such as the number of establishedsessions, the active NSLPs, etc. It is also possible through thisblock to request installing and uninstalling specific NSLPs,etc.

* RequirementsImplementing a signaling system requires judicious choices

to be made so that the requirements in terms of efficiency andflexibility should be met. The GISP signaling system has beenimplemented considering the following requirements:

a. Modularity: as the GISP protocol is intended to supportseveral signaling applications, its implementation should beeasily extensible to support new NSLPs. The system must beimplemented in such a modular way that the modification,extension or addition of a specific NSLP only causes a limitedinfluence on the implementation. In addition, theimplementation of the GISP protocol must not place anyconstraint on the design of the NSLPs.

b. Performance: the performance is impacted by both the

implementation choices of the GISP protocol itself and theinter-block communication. These choices should: 1.Minimize the implementation complexity: especially thecommunication between the building blocks of the GISPsignaling architecture, 2. Optimize the memory consumption:the implementation of the GISP protocol should avoid themultiplication of memory space especially to maintain thesoft-state information such as session information, 3. Optimizethe global response time: responsiveness is tied to reduce thelayer interfacing cost and optimise the GISP main functionssuch as: optimisation of the refresh time, optimisation of thesession retrieval time, ...

B. GISP Signaling System ImplementationThe GISP signaling system is implemented under the Linux

operating system and the C programming language accordingto an open source GPL license [19]. The implementation ofthe GISP signaling system consists in developing the GISP,NSLP and Management blocks and the interfaces between. Inaddition, we implemented the GISP/kernel interface to allowcommunication between the user space and the kernel. Toimplement the GISP signaling, some choices related to theinter-blocks communications have been made since theysignificantly influence the performance of the overallsignaling system, in particular, the GISPINSLPcommunication. We identified two approaches for theimplementation of the GISPINSLP communication. In the firstapproach, each NSLP is implemented as an independentprocess which manages its own memory space. The GISP andNSLP communicate through a socket communication. Thisleads to two consequences: Firstly the inter-processcommunication induces implementation complexity andcommunication latency. The complexity is due to the need ofimplementing a specific communication between GISP andNSLP. The communication latency will affect the globalresponse time. Secondly, this approach does not optimise thememory utilisation. Indeed, the session information (data flowidentifier, next hop address, ...) should not only be saved inthe GISP process but also in the NSLP processes. In thesecond approach, each NSLP is implemented as a dynamicLibrary of the GISP process which initiates a thread onceinstalled. Since the NSLP threads run in the GISP's space, thisapproach allows an optimal usage of the memory spacecapacity and speeds up the GISP/NSLP communication. Thisallows an optimisation of the global response time andreducing the implementation complexity while still providingrequired modularity and extensibility.

In the GISP implementation, we adopted the secondapproach. The GISP block is implemented as a daemon whichinterfaces the NSLPs that are implemented as dynamiclibraries. They can be loaded and unloaded without disturbingthe GISP daemon. When a library is mounted, it initiates athread which implements the functionality of thecorresponding NSLP. The NSLP thread runs independently ofthe GISP daemon but shares with it the same operationalspace. Since the Management block is a process operatingindependently of the GISP daemon, the communicationbetween these two processes is implemented through a localsocket communication. The GISP daemon plays the role of a

the Management block. The communication between theGISP and the kernel allows the GISP to request specificinformation from the kernel such as network interfaceattributes, routing information, link MTU, route changenotification, etc. This communication is implemented throughsystem calls. Note that, in the current development, we do notimplement the Application/NSLP communication.Some tools available in Linux environment have been used

in the GISP implementation such as Netlink sockets andPOSIX thread libraries. The Netlink sockets are used totransfer information between the kernel modules and user

space processes The POSIX libraries which are standardthread APIs for C/C++ have been used to spawn the NSLPthreads.

IV. THE GISP PROTOCOL IMPLEMENTATIONThe GISP daemon performs three main jobs. First, it

receives/sends and processes external messages coming fromits adjacent nodes through the IP layer or from theManagement process. Second, it receives/sends and processes

messages coming from the NSLP layer (i.e. NSLP threads).Third, it implements its own internal (signaling and transport)functions such as session management, session refresh,message transport and delivery, etc. In this paper, we focus on

the implementation details of the main signaling functionswhich are session management and session refresh.

A. Session managementBy session management we mean session repository and

retrieval. When the GISP process receives a session setuprequest, it allocates memory to save the session relatedinformation. Once the session is established, to modify or

remove it, the GISP process launches a session retrievalprocess. This process is based on the use of the Session-IDwhich uniquely identifies the end-to-end signaling applicationstate on the whole data path. The Session-ID is a 128 bitglobally unique number generated by the NSLP in the nodeoriginating the signaling exchange.

1) Session repository and memory management

The GISP session related information includes the flowidentifier (source address, destination address, ports, etc), therefreshing period, the next/previous hop's address, and otheroperational information. In general, sessions can be frequentlyestablished and removed. To avoid memory fragmentation andimprove the memory usage, we develop a specific memory

management to allocate and deallocate memory rather thanusing the malloc/free commands. Established sessions needthe same amount of memory to store the session information.The GISP daemon allocates a seamless memory space whichis divided into several same-size blocks. Since it is hard toallocate a large memory space at a time, the GISP daemonallocates several small seamless portions of memory we referto as memory bars. Each bar contains the same number ofblocks. To allocate memory, the GISP daemon scans each barto find the non used blocks. To accelerate the scanning, eachbar is associated with a number which indicates how manyunused blocks are in the bar and each block in a bar isassociated with a flag indicating whether or not the block is in

server which is responsible for listening the commands from use.

2) Session retrievalSince the GISP daemon is intended to support a large

number of sessions, the retrieval of the sessions must be fast,scalable, and induce a low management overhead. Twocandidate methods can be used for session retrieval: balancedbinary tree search and hash table. The complexity of thehashing table is 0(1) in the best case. However, collisionsmay occur when multiple sessions have the same hashingvalue. In the worst case, the complexity of this method isO(n). For the balanced binary tree search, the complexity is0(log(n)) in the worst case and 0(1) in the best case. In GISPimplementation, the balanced binary tree search method isused for session retrieval through the Tree search tool ofLinux developed following the Knuth Algorithm T.

B. Session refreshThe Session refresh process is responsible for maintaining

the session states in the signaling nodes. It is based on the list-based refresh mechanism presented in section 1.2. Asmentioned earlier, this mechanism aims to reduce theoverhead of the signaling traffic used to refresh the statesbetween two nodes. Rather than using the Session-ID torefresh the session states, this mechanism uses the Refresh-IDwhich has a peer-to-peer scope. In addition, to refresh activesessions, the GISP sends ranges of consecutive correspondingRefresh IDs, each range is identified by the first and the lastRefresh IDs. Note that, the Refresh IDs are created so that tominimize the number of blocks with consecutive Refresh-IDs.To accelerate the session retrieval for refreshing the states, theGISP uses a hybrid data structure combining a block balancedtree and a block list as shown in figure 1.

BIO,t~k E3ockReeh tBaEarncecd tree linke-list

fi-rt=3i ,/ g

_I HLL ~ _ n[

--NULLC_77" C

i -2

=9_Nfir L77n < -I __

Figure List-based refresh mechanism data structure

Using this data structure, the complexity cost of the sessionretrieval is 0(log(B)), where B is the number of the blocks (B<=n, n being the number of sessions). Note that, to optimizethe performance of the retrieval mechanism, each node, whencreating a new state, chooses the Refresh-ID in such a waythat the number of blocks is minimized. The list-based refreshmechanism presents a low complexity cost compared to thesimplest solution which uses the session identifier in whichthe complexity cost is 0(nlog(n)) (n is the number ofsessions). It is worth stressing that, if our list-based refreshmechanism reducessthe complexity cost of session retrieval, itinduces, on the other hand, an overhead due to Refresh-IDallocation and removal. Indeed, when setting up a new state,

the GISP must find the unused Refresh-ID which minimizesthe number of blocks and associates it to the new state.Nevertheless, this overhead is not significant considering theconsiderable gain provided by the list-based mechanism interm of refresh traffic reduction [14].

V. EVALUATIONIn this section, we present performance evaluation of the

GISP signaling we have done using a runtime testbedenvironment. As depicted in figure 2, the testbed consists of 3PCs all with Intel CPU 500 Mhz, 128 MB RAM, 20GB HDD,10OMbps Realtek RTL 8139 NICs running linux 2.4.20.

In this paper, we focus on: the session setup latency whichis a significant performance aspect of a signaling protocol, therequired memory to maintain the signaling sessions, andfinally the CPU consumption by profiling the implementation.

vthdl vthd21010.004

vt'hd31O, 10.1.014

1 etlh 1

01 42

Figure 2 - Testbed topology

A. Signaling Round Trip Time measurementIn our tests, the Round Trip Time (RTT) to establish a new

session is measured to appreciate the session setup latency.More precisely, the RTT was measured starting from sendinga new session setup message by the signaling initiator to theresponder until the complete reception of a response. The RTTcomprises the delays to setup both the forward and backwardstate. For the forward direction, the RTT includes: the statesetup latency on vthdl for creating a session, the transmissiondelay of the message towards vthd2, the propagation delaybetween vthdl and vthd2, the state setup latency on vthd2, thetransmission delay of the message towards vthd3, thepropagation delay between vthd2 and vthd3, and the statesetup latency on vthd3. Figure 3 depicts the evolution of theaverage RTT value as a function of the number of establishedsessions. We measure the RTT for setting up a new sessionconsidering N already established sessions, N = {1, 1000,2000, ..., 10000}. Each measure is performed 10 times. Weobserve that the average RTT value increases with the numberof established sessions. This is due to the session processinglatency which increases when the number of states to processincreases. A depth analysis of the session processing latencyshows that this quantity comprises: First, the time to analysisthe session setup message: this time includes the time toreceive the message and verify its checksum. This timeincreases linearly with the number of messages. In our test,this time is constant. Second, the time to allocate the memoryto the sessions: this time depends on the implemented memorymanagement strategy (see section IV.1) and the number ofestablished sessions. Finally, the time to insert the session inthe session search tree: this time increases in 0(log(n)) wheren is the number of established sessions. The results show thatfor 1000 sessions the RTT is approximately 542 [ts. The pingcommand shows an average RTT of 191 [ts, thus the sessionprocessing time is approximately 351 [ts. For 10000 sessionsthis time is (558 - 191) 367 [ts. Even if a definite conclusion

cannot be drawn, we can point out that the session processingtime is rather low and sustaining 10000 sessions introduces areasonable overhead compared to 1000 sessions. These resultsconsolidate the design and implementation choices we madefor the GISP signalling system.

E

I-

0,5600,555-0,550-0,545-

0,540-0,53540,5300,5250,520

Number of sessions

Figure 3 - RTT variation

B. Memory consumptionMemory consumption of states is approximately 110 bytes

(session identification: 16 bytes, flow identification: 13 bytes(IPv4), adjacent node addresses: 8 bytes (IPv4), andimplementation related internal states (as the incominginterface, output interface, timer, ...): 73 bytes). The memory

consumption of the GISP process has been evaluated to 1

Mbyte. Thus, the memory consumption for 10000 sessionscan be approximately evaluated to 2 Mbytes. Even sustaininga large number of sessions, the memory consumption of theGISP process is low. This is particularly true considering thelarge memory capacity of the today's routers.

C. Program profilingTo profile the GISP implementation we used the gprof

Linux tool. The gprof produces an execution profile of theprogram and allows the amount of time spent for calling eachroutine and subroutine in terms of percentage of CPU to bedetermined. The profile is used to evaluate the performance ofthe GISP implementation, determine de cost attributes of eachroutine and identify how much CPU the routines consume

thereby optimizing their behavior. The analysis is done on theforwarding nodes. The results show that session refresh is theleast costly operation (8%) followed by the sessionmanagement with 110% CPU consumption. Receiving andsending messages through the network socket requires about40% of CPU. Almost the same cost 41% (20% + 21%) isrequired for the message processing operation. As expected,these results highlight the efficiency of the refresh and sessionmanagement operations mainly due to the optimizationspresented above. A further step in GISP implementationoptimization consists in improving the behavior of theremaining routines, i.e, receiving/sending message routine andmessage processing routine. The former routine isindependent of the GISP implementation since it relies on thenetwork socket communication. To further improve the GISPimplementation, the analysis should then concentrate on themessage processing routine thereby identifying the operationsto be optimized.

VI. CONCLUSION AND FUTURE WORK

This paper presented the implementation and performanceaspects of the GISP signaling system. The modular structureof the GISP implementation provides ease of integrating anddesigning signaling applications (NSLP). Along with theefficient memory management, the session management isimproved by avoiding memory fragmentation and optimizingthe session retrieval process. The state refreshing is alsoenhanced to reduce both the refresh traffic and the complexityof session retrieval by using the notion of session indexblocks. The profile of the implementation shows that the staterefreshing routine uses a small portion of CPU resources.Furthermore, even sustaining a large number of sessions, theimplementation requires a small memory usage for itsoperations and shows a very low response time. Althoughthese results validate our design and implementation choicesfurther investigation is planned with respect to moresophisticated scenarios (large number of nodes, large numberof sessions, congestion situations, etc.). More studies toimprove the GISP implementation have to be carried out, inparticular, the message processing routines. Finally, we arecurrently evaluating and comparing the performance of theGISP and its implementation with other IP signalingprotocols, in particular, the GIST (General Internet SignalingTransport) protocol [20] which is an NTLP implementationunder-development within the NSIS working group.

REFERENCES

[1] R. Braden et al., "Resource ReSerVation Protocol (RSVP)", RFC 2205,September 1997

[2] D.Awduche, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC3209, December 2001

[3] L.Anderson and al., "LDP specification", RFC 3036, January 2001[4] P. Pan et al.,"YESSIR: A Simple Reservation Mechanism for the Internet",

Proceeding ofNOSSDAS, July 1998[5] J. Bergkvist et al., "Boomerang Protocol Specification", Internet draft,

work in progress, June 1999[6] D.Durham and al., "The COPS (Common Open Policy Service)

protocol", RFC 2748, January 2000[7] P. Srisuresh, " Middlebox communication architecture and framework",

RFC 3303, August 2002[8] Next Steps in Signaling (NSIS) working group,

http://www.ietf org/html.charters/nsis-charter.html[9] R. Hancock et al., "Next Steps in Signaling: Framework", RFC4080,

June 2005[10] S. Van den Bosch et al.,"NSLP for Quality-of-Service signaling", draft-

ietf-nsis-qos-nslp-02, Internet Draft, work in progress, February 2004.[ 11] M. Stiemerling et al., "A NAT/Firewall NSIS Signaling Layer

Protocol (NSLP)", Internet draft, work in progress, draft-ietf-nsis-nslp-natfw-02, May 2003

[12] Thanh Tra Luu et al., "NTLP Considerations and Implementation",Internet Draft, work in progress, draft-luu-ntlp-con-imp-01, May 2004

[13] T.T Luu, N. Boukhatem,"Generic signaling service framework", IEEECCNCO4, Las Vegas, Nevada, USA, January 2005, p 290-295

[14] T.T Luu and N. Boukhatem,"Generic Signaling Service Protocol: Statemanagement and Transport mechanisms", IEEE QShineO4, Dallas, TX,USA, October 2004

[15] R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960,October 2000

[16] R. Stewart et al., "SCTP Partial Reliability Extension", RFC3758, May2004.

[17] Datagram Congestion Control Protocol working grouphttp: lwww.ietf org/html.charters/dccp-harter.html

[18] M. Allman et al., TCP Congestion Control, RFC 2581, April 1999[19] http://www.infres.enst.fr/ luu/IPSIG/GISP.html[20] H. Schulzrinne, R. Hancock, << GIST: General Internet Signaling

Transport >>, Internet draft, Apr 2007.