Journal of Signals, Information, and Systems. Vol. 11, No. 2, 2004.
URL: http://yu.ac.kr/˜jsis/ pp. 59 - 70.
Session and Connection Management for QoS-Guaranteed Multimedia Service Provisioning on IP/MPLS Networks 1 YOUNG -TAK K IM 2 , H AE -S UN K IM
AND
H YUN -H O S HIN
Department of Information and Communication Engineering Yeungnam University Kyongsan 712-749, Republic of Korea
(Communicated by J.H. Park) Abstract In order to provide QoS-guaranteed realtime multimedia services on IPbased transport network, tightly coupled interactions of session & connection management and CAC (connection admission control) is essential. Also, for efficient QoS-guaranteed DiffServ provisioning across multiple AS domain networks, a scalable transit networking scheme must be provided so as to configure per-class-type QoS-guaranteed packet processing and to provide scalable connection admission control (CAC). In this paper, we propose a functional architecture of session & connection management with SIP, RSVP-TE, CAC and QoS-guaranteed virtual networking. We also propose a per-class-type virtual networking scheme for scalable QoS-guaranteed DiffServ provisioning across multiple autonomous system (AS) domain networks. The implementations of the proposed distributed session & connection management functions are based on Web Service architecture and XML/SOAP-based network management. Keywords: QoS, DiffServ, UNI & NNI signaling, DiffServ-aware-MPLS traffic engineering, inter-AS traffic engineering.
1 Introduction In order to provide QoS-guaranteed realtime multimedia services on IP-based transport network, two signaling functions must be prepared: (i) end-to-end signaling to initialize a session, and (ii) UNI/NNI signaling to establish QoS & bandwidthguaranteed virtual circuit for media packet flow. And these signalings must be tightly coupled with CAC (connection admission control) that controls the overall traffic flow over a traffic engineering transit tunnels at appropriate operational level for guaranteed QoS provisioning. For end-to-end session initialization and description, SIP (session initiation protocol) / SDP (session description protocol) can be used, while RSVP-TE can be implemented as the UNI and NNI signaling to establish QoSguaranteed virtual circuit. Since current IP/MPLS implementations do not provide 1) Accepted 20 November 2004. 2) Corresponding author: E-mail:
[email protected].
Page 60
Young-Tak Kim et al.
per-class-type packet processing and NNI signaling across multiple AS (autonomous system) domain networks, an efficient alternative transit networking must be provided so as to configure per-class-type QoS-guaranteed DiffServ packet processing, and enable scalable connection admission control (CAC) and QoS-guaranteed transit networking across multiple AS domain networks. Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants[1, 2], such as VoIP telephone calls, multimedia distribution & conferences. SDP is used for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation [2]. In order to organize a multimedia communication session, SDP/SIP messages must be exchanged among participants to check the availability of participant, capability of terminal, and determination of media type, transport protocol, format of media, and related network & port addresses. After determination of parameters for a multimedia session, QoS-guaranteed connections for the session must be established among participant terminals. In IP/MPLS network, RSVP-TE (resource ReSerVation Protocol with extension of Traffic Engineering) can be used for UNI and intra-AS NNI signaling. MPLS NNI signaling standard for inter-AS domain networks, however, is not yet well standardized to establish per-class-type QoS-guaranteed connections across multiple AS domain networks. As a consequence, an efficient alternative transit networking scheme must be provided so as to configure per-class-type QoS-guaranteed DiffServ provisioning and to support scalable connection admission control (CAC). In this paper, we propose a functional architecture of session & connection management with SIP, RSVP-TE, CAC and QoS-guaranteed virtual networking. We also propose a per-class-type virtual networking scheme for scalable QoS-guaranteed DiffServ provisioning across multiple autonomous system (AS) domain networks. The implementations of the proposed distributed session & connection management functions are based on Web Service architecture and XML/SOAP-based network management. Based on the proposed architecture, DiffServ-aware-MPLS traffic engineering can be efficiently implemented across multiple AS domain networks of different network operators. The rest of this paper is organized as follows. In section 2, related works are briefly introduced. In section 3, QoS-guaranteed per-class-type virtual networking in intra-AS network and inter-AS networks, functional model of interactions among session and connection management protocols, QoS-routing, and CAC (connection admission control) functions are explained. In section 4, implementations of NMS (network management system), EMS (element management system) and CNM (customer network management) system for per-class-type virtual networking and end-toend connection management are explained. Also, configuration of DiffServ-awareMPLS TE at provider edge (PE) router is explained. Finally, we conclude this paper in section 5.
Session and Connection Management
Page 61
2 Related Works 2.1 Session Initiation Protocol (SIP) and Session Description Protocol (SDP) SIP is an application -layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants [1]. The session may be VoIP telephone calls, multimedia distribution & conferences. SIP supports five facets of establishing and terminating multimedia communications: user location, user availability, user capabilities, session setup, and session management. SIP makes use of proxy servers to help the routing request to the user’s current location, to authenticate and authorize users for services, to implement provider call-routing policies, and to provide features to users. SIP also provides a registration function that allows users to register their current locations for use by proxy servers. SIP may run on top of several different transport protocols, such as UDP and TCP. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SDP (session description protocol) [2] has been designed to convey session description information, such as session name and purpose, the time(s) when the session is active, the media comprising the session, information to receive those media (addresses, ports, format, etc), the type of media (video, audio, etc), the transport protocol (RTP/UDP/IP, H.320, etc), and the format of the media (H.261 video, MPEG video, etc). For a multicast session, multicast address and transport port for media are delivered; for a unicast session, remote address for media and transport port for contact address are delivered. SDP is not intended to support negotiation of session content or media encodings. When a multimedia communication session is determined by SDP/SIP, the network addresses of participants and the related traffic & QoS parameters are determined. Based on these connection parameters, connection establishment is requested using UNI signaling function. The traffic parameters will include committed information rate (CIR), committed burst size (CBS), excess burst size (EBS), and peak information rate (PIR). The QoS parameters will include end-to-end transfer delay, delay variation tolerance, packet error rate / bit error rate, service availability and protection mode. 2.2 UNI signaling with Traffic Engineering Extensions (RSVP-TE) After determination of QoS & traffic parameters for a multimedia session, QoSguaranteed per-class-type connections for the session must be established among the participant terminals. In IP/MPLS network, connection establishment is accomplished by UNI (user-network 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 [3]. 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 user agent in multimedia terminal 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
Page 62
Young-Tak Kim et al.
terminal and ingress router. 2.3 Differentiated Service provisioning with multiple virtual networks The realtime multimedia service will require guaranteed QoS provisioning and traffic parameters according to its applications [4]. The highly interactive realtime transaction service, such as user-to-user signaling and highly interactive transaction service, will require less than 50 msec of end-to-end delay. Highly interactive realtime CBR(constant bit rate) conversation service, such as VoIP, will require end-toend delay of 100 msec and jitter of 50 msec, and can be supported by EF (expedited forwarding) class-type in DiffServ standard. Highly interactive realtime VBR (variable bit rate) conversation service, such as multimedia phone, will require same QoS parameters, but may be provided by AF (assured forwarding) class-type that handles efficiently the variable bit rate (VBR) characteristics. Multimedia conference will require extended end-to-end delay of 400 msec, and jitter of 50 msec. Interactive transaction data, such as telnet session, will require endto-end delay of 400 msec without jitter constraints, while Web search or bulk data transfer will require much loose time constraints, such as more than 1 sec of end-toend delay. Finally, the best effort service is a class type for legacy Internet service that does not guarantee time constraints nor traffic parameters. As explained above, each class-type requires different QoS requirements; some service classes requires tight end-to-end delay of 100 or 400 msec and limited jitter, while the other non-realtime service classes do not require tight end-to-end delay. The different service class-type will require different fault restoration capability; highly interactive realtime transaction or conversational services will require fast restoration with 1+1, 1:1 or M:N backup path, while non-realtime services will require less strict fault restoration with 1:N or sometimes may allow no restoration. In order to provide QoS-guaranteed service while maintaining the network in optimal resource utilization level, we need to configure the MPLS transit network to provide multiple per-class-type virtual networks with different operation mode. Figure 1 shows the concept of multiple virtual network on MPLS network, where virtual networks for network control traffic (NCT), expedited forwarding (EF), and assured forwarding (AF) class-types are configured and managed separately [4].
3 Session and Connection Management for QoS-Guaranteed Multimedia Service Provisioning 3.1 QoS-guaranteed Per-Class-Type Virtual Networking in an Intra-AS Domain Network Configuration of scalable per-class-type virtual networks in an intra-AS domain network is one of the key traffic engineering function in QoS-guaranteed DiffServ provisioning. As shown in Figure 2, the NMS (network management system) in each AS domain network configures multiple virtual networks for each DiffServ classtype considering the QoS parameters. In a per-class-type virtual network, multiple
Session and Connection Management
Page 63
Figure 1: Differentiated service provisioning with multiple virtual networking QoS-guaranteed TE-LSPs are established among PE routers to configure connectivity of full mesh topology. The DiffServ-aware-MPLS AS domain network provides the network-view information of IP/MPLS routers, data links among routers, and CSPF (constraint-based shortest path first) routing function. The QoS-guaranteed per-class-type virtual network function can be provided as the connectivity management API (application programming interface) of Parlay/OSA (Open Service Architecture) standard [5].
Figure 2: QoS-guaranteed per-class-type virtual networking in an AS domain network 3.2 QoS-guaranteed Per-Class-Type Virtual Networking among Inter-AS Domain Networks The configuration of per-class-type virtual networks across multiple AS domain network is very important to support QoS-guaranteed DiffServ efficiently through
Page 64
Young-Tak Kim et al.
multiple AS domain networks without scalability problem. In order to configure virtual networks for DiffServ class-types, the NMS establishes edge-to-edge TE-LSP in two-level hierarchy: (i) establishment of ASBR (autonomous system boundary router)-to-ASBR trunk TE-LSP as inter-AS transit tunnels, and (ii) establishment of edge-to-edge QoS-guaranteed TE-LSP through the transit tunnels among ASBRs.
Figure 3: Configuration of transit virtual networks In order to establish QoS-guaranteed ASBR-to-ASBR transit TE-LSP, the network resource availability and traffic engineering parameters of each AS domain network must be collected. Current BGP (border gateway protocol), unfortunately, only provides reachability & route information, and does not provide traffic & QoS information of the route. As an alternative solution, Web-service architecture can be used to implement the interactions among NMSes for AS domain networks [6]. As shown in Figure 3, NMS of each AS domain network would register the available connectivity services among ASBR in the AS domain network through Web service registration. The ingress NMS queries the UDDI registry to get the URL of WSDL for the NMS of destination network to which the destination CPN (customer premises network) is attached. It then retrieves the information of neighbor NMS, recursively, until one of the neighbor of the intermediate NMS is itself. Based on the collected AS domain network connectivity information and the available transit networking attributes (i.e., available bandwidth, edge-to-edge transfer delay, etc.), the originating NMS can find the constraint-based shortest path between the ASBRs of the originating AS domain and the destination AS domain. Multiple ASBR-toASBR transit TE-LSPs may be configured with different route for the virtual transit networks according to DiffServ class-types. The ingress NMS then configures intra-AS DiffServ-aware-LSP in the originating AS domain network with configuration of DiffServ-aware packet processing at ingress provider edge (PE) router, requests the destination NMS to setup the LSP at destination domain network, and finally completes the edge-to-edge DiffServ-awareLSP through the transit trunk TE-LSP of transit virtual network for the requested
Session and Connection Management
Page 65
DiffServ class-type. 3.3 Session and Connection Management Figure 4 shows the overall interactions among session management functions and connection management functions. The user terminal will firstly discover required service from service directory that provides service profiles. If an appropriate application service is selected and agreed via SLA (service level agreement), session setup & control for the multimedia application will be initiated. SIP and SDP will be used to find the location of destination, to determine the availability and capability of the terminal. The SIP proxy server may utilize location server to provide some value-added service based on presence and availability management functions.
Figure 4: Interactions among session and connection management functions Once session establishment is agreed by participants, QoS-guaranteed per-classtype end-to-end connection ( or packet flow) establishment will be requested through UNI signaling. RSVP-TE may be used in IP/MPLS network. The edge IP/MPLS router of ingress provider network will contain connection control and management functions for on-demand connection establishments. When the customer premises network (CPN) or participant’s terminal does not support RSVP-TE signaling function, an end-to-end connection will not be established; instead, per-class-type packet flow must be registered and controlled by the connection management function of ingress PE router with CAC (connection admission control). The customer network management (CNM) system may support the procedure of per-class-type packet flow registration. 3.4 QoS-Routing and Connection Admission Control (CAC) When a QoS-guaranteed connection setup (or per-class-type packet flow registration) request is arrived, the connection management module must check the avail-
Page 66
Young-Tak Kim et al.
able network resource, find appropriate route for the requested QoS & traffic parameters using CSPF (constraint-based shortest path first) QoS-routing function, and finally make decision on the admission of the requested connection establishment. The CSPF for the requested connection will consider bandwidth (CIR/CBS, EBS), end-to-end delay, jitter, bit/packet error rate and required protection mode. When a connection establishment request is accepted, the DiffServ-aware-MPLS connection control function will establish an end-to-end LSP for the requested connection. The per-class-type virtual networking that has been explained in Section 2 will minimize the complexity of QoS-routing and scalability problem of CAC, and provides flexibility in the management of QoS-guaranteed transit network resources. Since near full-mesh topology can be configured among PE-PE pairs for each classtype, the user connection setup request can be handled easily based on the preestimated traffic between the ingress PE router and the egress PE router. Also, the per-class-type QoS-guaranteed virtual networking makes it easy to support the differentiated guaranteed bandwidth provisioning and controlled link utilization that manages the queuing delay and packet loss by buffer overflow. In the case of network link/node failure, it is much easier to reroute the TE-LSP for each class-type that contains multiple user traffic flows, instead of rerouting multiple LSPs for each user packet flow.
4 Implementations 4.1 Implementation of NMS, EMS and CNM In order to provide Web service based distributed connection management function, CNM (Customer Network Management) system and NMS (Network Management System) have been implemented based on JBuilder X with Apache AXIS toolkit, JAX-RPC for XML/SOAP messaging and DII (dynamic invocation interface). JWSDP with JAXR is used to configure private UDDI which provides the URL of neighbor NMS for neighbor AS domain network. Figure 5 shows the architecture of NMS with Web service functions. In order to support distributed connection management, each NMS registers the information of its client network addresses and related URLs of WSDL(Web Services Description Language) documents from which other NMSes can query for the availability to establish a connection with the requested QoS & traffic parameters to the destination. Each NMS also registers URLs of WSDL documents for the query of its neighbor AS domain networks with traffic & QoS parameters of the transit link (i.e., capacity, physical distance, supported DiffServ classes and their profiles). In each AS domain network, an NMS may control multiple EMSes, where each EMS controls a sub-domain MPLS network. EMS provides basic functions of network configuration, traffic engineering tunnel (TE-LSP) establishment, node/link protection mode setup, and configuration of fault notification and fast restoration. The EMS is tightly related with the signaling module for on-demand dynamic connection establishment. In the initial stage of MPLS network installation when MPLS
Session and Connection Management
Page 67
signaling function is not fully mature, the EMS may be used to provide traffic engineering tunnel establishments. The EMS may be implemented with various programming language and platforms. Usually, the network element (NE, i.e. MPLS LSR) is developed together with its related EMS function for local management and test purpose. The legacy EMS modules (i.e., configuration management, connection management, performance & fault management) which have been implemented by C++ on UNIX platform must be provided with adaptation function for XML/SOAP access from NMS. Figure 6 depicts the legacy EMS modules with adaptation functions.
Figure 5: Network Management System (NMS) with Web Service functions
Figure 6: Element Management System (EMS) for subnetwork management 4.2 Interactions among NMS, EMS and NE In the Web service architecture for distributed connection management across multiple AS networks, each AS domain network is assumed to be managed by an
Page 68
Young-Tak Kim et al.
NMS which takes care of the overall AS domain network, and several EMSes (Element Management System) that take care of one or more areas within the AS. The QoS-guaranteed connection across different AS domains is established by interactions between the neighbor NMSes of the AS networks which include inter-AS negotiation for differentiated packet processing and bandwidth allocations. Each intermediate NMS and the destination NMS must provide the information of reachability, available bandwidth and related QoS parameters between AS boundary edge points to the originating NMS that performs constraint-routed shortest path first (CSPF) route for the requested end-to-end connection with specific traffic & QoS parameters. To provide the connectivity among AS networks and the edge points, the dedicated NMS of each AS network registers to the UDDI registry. The interaction between NMS and EMS is implemented by XML/SOAP, and the interaction between EMS and network element nodes (i.e., MPLS router, host and switch) is implemented by XML/SOAP, SNMP or CLI (Command Line Interface). Currently, the SNMP interface is not fully supported in commercial MPLS routers. The CLI is usually proprietary standard which is specified by the equipment vendor; for specific equipments from a vendor, adaptation functional modules for CLI must be provided. CNM (Customer Network Management) system is used to manage the customer’s network, to configure differentiated services with appropriate SLA/SLS, and to generate end-to-end connection setup request for QoS-guaranteed service. 4.3 Configuration of DiffServ-aware-MPLS TE at Provider Edge (PE) Router Figure 7 depicts the configuration of DiffServ-aware-MPLS TE at ingress provider edge router. DiffServ-aware-MPLS traffic engineering is configured firstly at the provider edge (PE) router where incoming packet flow is classified by pre-defined classification options, metered and marked for each class-type. If the packet exceeds the committed information rate (CIR) of the class-type, it may be remapped to lower priority class-type or dropped. The packet flow of determined class-type is then enqueued in the specified output queue to be forwarded to the transit network where multiple virtual networks are configured for DiffServ class-types to the destination PE router. In a test-bed network with Cisco 7200 series IP/MPLS routers, the DiffServaware-MPLS TE configuration has been implemented with Class Map, Route Map, Access List and Policy Map [7]. Class-map command and its subcommands are applied on per-interface basis to define packet classification, marking, aggregate, and flow policing as part of a globally named service policy. Access lists perform packet filtering to control the flow of packets. A policy map associates a traffic class with one or more QoS actions. The router supports QoS policing functions such as class-based weighted fair queuing (CBWFQ). Paths among AS domain networks are created by applying the route-map to PE. Filtering of source IP address of packet and specification of destination IP address can be possible, using the route-map.
Session and Connection Management
Page 69
Figure 7: Configuration of DiffServ-aware-MPLS TE at provider edge (PE) router
5 Conclusions Since current IP/MPLS implementations do not provide per-class-type packet processing and NNI signaling among different AS (autonomous system) domain networks, an efficient alternative transit networking must be provided so as to support efficient per-class-type QoS-guaranteed DiffServ provisioning, scalable connection admission control and QoS-guaranteed transit networking. In this paper, we proposed per-class-type virtual networking scheme for efficient QoS-guaranteed DiffServ provisioning across multiple AS domain networks. We also proposed a functional model of interactions among SIP/SDP, RSVP-TE, CAC and QoS-guaranteed virtual networking. Currently, we are implementing NMS, EMS and CNM for virtual networking and distributed connection management to provision end-to-end QoS guaranteed realtime multimedia services across multiple AS domain networks. The interaction of NMSes among inter-AS domain networks is implemented based on Web Service architecture.
References [1] J. Rosenberg et. al., ”SIP: Session Initiation Protocol,” IETF RFC 3261, June 2002. [2] M. Handley and V. Jacobson, ”SDP: Session Description Protocol,” IETF RFC 2327, April 1998. [3] D. Awduche, et. al., ”RSVP-TE: Extensions to RSVP for LSP Tunnels,” IETF RFC 3209, December 2001.
Page 70
Young-Tak Kim et al.
[4] Young-Tak Kim, Hae-Sun Kim, ”Per-Class-type Virtual Networking for QoS-guaranteed DiffServ Provisioning on IP/MPLS Networks,” submitted to ICC‘2005. [5] Parlay version 4.0, Parlay Group, http://www.parlay.org. [6] Youngtak Kim, Hyun-Ho Shin, ”Web Service based Inter-AS Connection Managements for QoS-guaranteed DiffServ-aware-MPLS Internetworking,” Proc. of International Conference on Software Engineering Research, Management & Applications (SERA 2004), San Francisco, pp. 256-261. [7] Eric Osborne and Ajay Simha, Traffic Engineering with MPLS - Design, configure, and manage MPLS TE to optimize network performance, Cisco Press, 2003.
