KR20070001559A - Method of guarantee for end-to-end quality of service, using sip and rsvp-te - Google Patents

Abstract

A method for guaranteeing end-to-end QoS(Quality of Service) among terminals using SIP(Session Initiation Protocol) and RSVP-TE is provided to assure end-to-end QoS by setting a QoS guaranteed packet flow through UNI(User-Network Interface) signaling and RSVP-TE Server/CAC(Call Admission Control) of an ISP. According to a method for guaranteeing end-to-end QoS(Quality of Service) among terminals using SIP(Session Initiation Protocol) and RSVP-TE, a terminal provides SIP/SDP(Session Description Protocol), RSVP-TE(Resource Reservation Protocol-Traffic engineering) agent functions. A service provider constitutes all functions in one router or a switch.

Description

Method of guaranteeing end-to-end QOS between terminals using SIP and RSV-TI {Method of Guarantee for End-To-End Quality of Service, using SIP and RSVP-TE}

1 is a system architecture

2 is a resource allocation procedure interworking with SIP / SDP and RSVP-TE

3 is a configuration module between a terminal and a service provider proposed in the present invention

4 is Activity Diagram

This is to provide guaranteed service (QoS) in IP data communication between terminals such as PDAs and host PCs. In the past, attempts were made to provide QoS guarantees between end users using IntServ. However, due to the complexity problem, it is impossible to apply it to large-scale systems. To overcome this problem, Diffserv technology that aggregates user traffic by class has emerged. However, there is a limit to QoS guarantee to end-user level.

In the present invention, a session between terminals is established using an existing Session Initiation Protocol (SIP) / Session Description Protocol (SDP), and an RSVP-TE Server / CAC (Call) of an ISP is used by using an RSVP-TE agent for a terminal when establishing a session. QoS is guaranteed between end-to-end by setting QoS guaranteed packet flow through Admission Control) and UNI (User-Network Interface) signaling.

    The present invention is to provide end-to-end quality of service (QoS) between terminals in IP data communication. The present invention is divided into 4 parts as follows.

-MMCoordinator

SIP ProxyServer, Registration Server

-RSVP-TE (Resource Reservation Protocol-Traffic engineering) Server / CAC (Call Admission Control)

NMS (Network Management System)

   The overall architecture of the above 4 parts has the following configuration modules in detail as shown in FIG.

1.MMService Coordinator

1.1.SIP / SDP

1.2.RSVP-TE Agent

2.SIP ProxyServer / Registration Server

3.RSVP-TE Server / CAC (Call Admission Control)

3.1.SLA (Service Level Agreement) List

4.NMS (Network Management System)

4.1.Diffserv-over-MPLS

4.2.Network Information List

MMService Coordinator is divided into SIP / SDP, RSVP-TE agent module. SIP / SDP manages connection setting for QoS Guaranteed Session between terminals, sets basic session using SIP, and delivers additionally required QoS attributes using SDP. When establishing a QoS guaranteed session between terminals using SIP / SDP, RSVP-TE is used as a protocol for allocating resources. The RSVP-TE agent has a function of allocating resources to the RSVP-TE Server of the Service Provider after obtaining information on QoS attributes from the SIP / SDP.

Looking at SIP ProxyServer / Registration Server, ProxyServer is in charge of handling Session Initiation Protocol (SIP) messages between Terminal and SIP Servers. Registration Server is responsible for managing information about users.

  Looking at RSVP-TE Server / CAC (Call Admission Control), RSVP-TE Server processes the resource allocation request requested from the RSVP-TE Agent of the terminal. When the RSVP-TE Server receives a resource allocation request from the sending RSVP-TE agent, it transmits the IP address and TCP / UDP port number of the transceiver to the CAC. When the permission for the resource request is dropped from the CAC, the RSVP-TE server forwards the resource request signaling to the RSVP-TE agent of the receiving end. When the receiving end accepts the resource request, the RSVP-TE server manages the resource continuously configured. The CAC reviews the resource allocation requested from the RSVP-TE Server.

In this case, SLA (Service Level Agreement) List is used to review the contents of the contract between Service-Provider and Service-User, and if the contract is followed, resource request is made to NMS (Network Management System).

  Network Management System (NMS) provides QoS service between end users by using Diffserv-over-MPLS function, and additionally maintains network reach information list between QoS request terminals.

A resource allocation procedure interworking with SIP / SDP and RSVP-TE is shown in FIG.

  User Agent A invites User Agent B using INVITE as a Message. SIP ProxyServers provide the role of forwarding SIP messages. When User Agent A creates an INVITE message, it records information about QoS in SDP. Receiving the INVITE message, User Agent B analyzes the SDP information, confirms that there is a request for QoS, and sends a 183 Session Progress Message to User Agent A.

User Agent A receives the 183 message and sends a Prack message in response to User Agent B accepting the QoS request.

The user agent B receiving the prack message sets the one-way path from the user agent B-> user agent A through the RSVP-TE agent, and sends a 200 OK message to the user agent A as a response message to the prack message. User Agent A, which receives 200 OK message, knows that User Agent B is set between the path between User Agent B and User Agent A. Then, User Agent A and User Agent B set one-way path. After User Agent A sets the path, it actually sends an Update message to User Agent B to send and receive media streams between the two terminals.

User Agent B checks the update message and sends 200 OK to User Agent A in response. The received User Agent completes the session negotiation on INVITE and performs data communication with guaranteed QoS.

3 is a configuration module between a terminal and a service provider proposed in the present invention. According to FIG. 3, the terminal provides SIP / SDP and RSVP-TE Agent functions, and the Service Provider may configure all the above functions in one router or switch, or may divide and partially divide the above functions.

4 shows the RSVP-TE agent, RSVP-TE Server / CAC, and NMS interworking parts.

I. Introduction

Traffic usage has been growing at an exponential rate. The DiffServ model was proposed as a solution to the scalability problem of the IntServ model. In this case, packets are classified into a small number of service classes at the edge router according to their service requirements. The core router will differentiate between packets on a class-by-class rather than flow-by-flow. It avoids the scalability problem associated with IntServ.

At the same time, the Session Initiation Protocol (SIP) and Recourse Reservation Protocol (RSVP) have become the key components to provide the required QoS. In order to provide QoS-guaranteed realtime multimedia services on IP-based network: (i) end-to-end signaling to establish a session, and (ii) UNI / NNI signaling to establish QoS and bandwidth-guaranteed scheme for data flow. For the first purpose, SIP / SDP (Session Description Protocol) can be deployed, while RSVP-TE will be used to organize the UNI and NNI signaling to establish QoS-guaranteed connection.

The Session Initiation Protocol (SIP) is a new signaling, presence and instant messaging protocol developed to set up, modify, and tear down multimedia sessions, request and deliver presence and instant messages [1]. In order to establish multimedia communication session, SIP / SDP messages must be exchanged between session participants to check out the participant capability, media type negotiation and format type.

After negotiation of session parameters, QoS-quaranteed connection for the present session should be established between session participants. For that purpose RSVP-TE (Resource Reservation Protocol with extension of Traffic Engineering) will be used.

In this paper we propose a new functional model for QoS-guaranteed DiffServ Provisioning. Based on the proposed architecture, QoS-guaranteed DiffServ Provisioning can be efficiently implemented and deployed on the IP-based networks of different operators. We also analyze the issues related to the interaction between SIP / SDP and RSVP-TE protocols in the new developed model called Coordinator, focusing on the main features of the mentioned protocols.

The rest of this paper is organized as the follows. In section II, related works are briefly described. In section III, system architecture will be explained. Section IV is dedicated to implementation and analysis of proposed model. Finally, we will conclude this paper in section V.

II. Related Works

2.1 Session Initiation Protocol (SIP) and Session Description Protocol (SDP)

SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility-users can maintain a single externally visible identifier regardless of their network location [2].

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build complete multimedia architecture. SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For instance, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session.

SIP does not offer conference control services such as flow control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities.SDP was proposed to convey information about media streams in multimedia sessions to permit the recipients of a session description to take part in the session [3]. Session description information, such as information about the bandwidth to be used by the session, type of media, time (s) the session is active, transport protocol (RTP / UDP / IP, H.320, etc), the format of the media (H.261 video, MPEG video, etc) can be specified based on the SDP.

Since multimedia communication session will be fully determined by SIP / SDP, based on the required connection parameters connection establishment will be claimed by UNI signaling function.

2.2 RSVP-TE

The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path (s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path [4].

As the name suggests, the RSVP extensions are primarily intended for traffic engineering. In order to support traffic engineering, RSVP-TE makes a few additions to traditional RSVP. First, it expands the definition of traffic flows to include label switched paths. That lets and RSVP-capable router assign traffic to RSVP flow based on their MPLS label. Second, RSVP-TE modifies the protocol rules so path and reservation messages can travel between ingress and egress routers. In the RSVP-TE messages themselves, RSVP-TE adds fields that let path messages request label mappings and reservation messages return label values. The RSVP-TE extensions also allow an ingress router to specify an explicit route for the flow, much the same way as CR-LDP. Finally, RSVP-TE makes the actual resource reservation optional. With this flexibility, routers can use RSVP-TE to distribute labels even when the paths do not need reserved network resources [5].

After determination of QoS & traffic parameters for a multimedia session, QoS guaranteed per-class-type connections for the session must be establish among the participant terminals. In IP / MPLS network, connection establishment is accomplished by UNI (user-interface-interface) and NNI (network node interface) signaling. For UNI signaling between user terminal and ingress edge router, RSVP-TE can be used to carry the connection request. In order to support per-class-type DiffServ provisioning, RSVP-TE must provide traffic engineering extensions so as to deliver the traffic & QoS parameters

The multi-media coordinator must provide RSVP-TE client function, while the ingress edge IP / MPLS router must support the RSVP-TE server function. Since RSVP-TE establishes only unidirectional connection, two PATH-RESV message exchanges should be implemented to establish bi-directional path between user terminal and ingress router [6].

III. Architecture for SIP and RSVP-TE for QoS-guaranteed Diffserv

3.1 SIP with RSVP-TE architecture

This article presents QoS guaranteed realtime multimedia service architecture. (fig. 5) shows the proposed architecture to provide QoS guaranteed realtime multimedia service.

(fig. 5) Architecture for SIP with RSVP-TE

This architecture consists of three main modules: (iii) User Agent, (ii) SIP proxy server, and (iii) RSVP-TE server. User agent consists of: (i) coordinator, (ii) SIP, (iii) audio / video connections, and (IV) RSVP-TE. The coordinator manages these 3 modules to function systematically.

The SIP proxy server forwards message between user agents and takes care of user agent registration. The SIP module in the service requestor first sends INVITE message to the service recipient. In SIP module, the required bandwidth is usually sent SDP message during INVITE request.

For the resource allocation, the RSVP-TE user agent sends Path message to the RSVP server at NMS. The RSVP-TE server calls NMS's Call Admission control (CAC) to check the availability of the resources. The CAC checks with the available resources and notifies RSVP-Server. When requested resource is unavailable,

RSVP server notifies error message to the requestor. If resource is available, RSVP-server forwards the Path message to the recipient User agent. The user agent responds with RESV message to the RSVP server, which will make the resource allocated.

3.2 signaling mechanism between SIP and RSVP-TE

The basic idea is to let the terminals start a RSVP based bandwidth reservation during the SIP session setup. The SIP user agents, that should include the RSVP-TE support, are connected to an DiffServ based IP network; all routers are DiffServ aware and support RSVP-TE, per flow bandwidth reservation and per flow packet scheduling. According to this scenario, when the calling User Agent wants to establish a QoS call, it sends the SIP INVITE message to the callee, specifying that a bandwidth reservation is requested. Upon the receiving of the INVITE message, a 183 Session Progress response is sent from the callee and then the resource reservation procedure can start. Depending if the bandwidth reservation is requested for one or two-ways traffic flows, the caller or / and the callee starts a RSVP session by sending PATH messages to the peer party, followed by the RSVP signaling flow. Upon the reception of the RESV messages each user agent realizes that the reservation has been successfully setup and the SIP session setup can continue with the 180 Ringing message, the 200 OK and the caller ACK.

(fig. 6) shows the SIP / RSVP-TE signaling flow for the call setup between two SIP / RSVP-TE aware user agents. Figure. The SIP / RSVP call setup signaling flow.

(fig. 6) QoS setup with SIP messages

On the figure above, User Agent (UA) A sends INVITE message includes quality of service preconditions in the SDP. After receiving 183 Session Progress reply message UA A generates PRACK (Provisional Response ACKnowledgement) message indicates the receipt of the 183 Session Progress response message. From this point, both of the sides start resource reservation as mentioned above. When UA A finishes reserving resources in the A-> B direction, it sends an UPDATE to UA B. UA B returns a 200 (OK) response for the UPDATE, indicating that all the preconditions for the session have been met. indicating that all the preconditions for the session have been met.

IV. Implementation and Experiments

4.1 Implementation of SIP

The SIP agent has been implemented with Object Oriented design concepts. The SIP is referred to in RFC 3261. Especially the SIP agent design and implement for interaction with RSVP-TE (fig. 7). In this paper, SIP proxy server use VOCAL system without any modification in it.

(fig. 7) Class diagram for SIP user agent

4.2 Implementation of RSVP-TE

In this section the Implementation of RSVP Server & RSVP client modules for UNI signaling are explained. The RFCs 2205 and 3209 give details of RSVP and RSVP-TE respectively. RSVP function modules has 2 parts: (i) management part, and (ii) message part. The (fig. 8) shows UML Class diagram of management part.

(fig. 8) Class diagram for RSVP-TE application

And (fig. 9, 6) show implementation of RSVP's RESV and PATH message format respectively.

(fig. 9) RSVP Path Message formats

(fig. 10) RSVP Resv Message formats

The RSVP protocol ID is 46 and it uses RAW socket to transmit data through RAW IP datagram. RSVP-TE Server handles RSVP resource reservation and resource allocation through the NMS. In each established session,

the RSVP client sends one PATH message for resource reservation and one RESV message to allocate resource. To keep the reservation state persistent, a timer has been implemented which periodically sends PATH and RESV messages. For reservation tear down, the RESV TEAR and PATH TEAR messages have been implemented.

4.3 Multimedia coordinator

Multimedia co-ordinator in User agent manages SIP and RSVP-TE modules and Audio-Video connections. Media co-ordinator manages details of Session ID, Source address, Source port number, Destination address, Destination port number, Protocol ID, Service class, Bandwidth etc.

(fig. 11) shows a SIP User Agent's Register Invite Message GUI and the following figure shows User Agent of the receiver. Once invite message is accepted, the resource reservation will be carried out.

(fig. 11) RSVP Resv Message formats

We generated network traffic through traffic generator and tested best effort and QoS-guaranteed services in our lab. From the above (fig. 12), it has been clear that the Qos-guaranteed service does not suffer form packet loss.

(fig. 12) Comparison of QoS Guaranteed and Best Effort Services

V. Conclusion

In this paper we propose to use the existing SIP with RSVP-TE for implementing the guaranteed QoS between the user agents. In the proposed architecture, SIP and RSVP-TE is effectively used.

According to the present invention, a session between terminals is established using an existing Session Initiation Protocol (SIP) / Session Description Protocol (SDP), and an RSVP-TE server / CAC (ISP) of an ISP is used when a session is set up. QoS is guaranteed between end-to-end by setting QoS guaranteed packet flow through Call Admission Control) and UNI (User-Network Interface) signaling.

Claims (1)

Method of guaranteeing end-to-end QoS between terminals using SIP and RSVP-TE

Images