Design and Implementation of Dynamic Service Negotiation Protocol (DSNP)∗ Jyh-Cheng Chen1 , Venkatesh Sarangan2 , Anthony McAuley3, Shinichi Baba4 , Yoshihiro Ohba5 , and Zong-Hua Liu1 1 2 3
National Tsing Hua University, Hsinchu, Taiwan
Oklahoma State University, Stillwater, OK 74078, USA
Telcordia Technologies, Inc., Piscataway, NJ 08854, USA 4
5
Toshiba Corporation, Tokyo, Japan
Toshiba America Research, Inc., Piscataway, NJ 08854, USA Abstract
This paper describes the design principles and implementation of Dynamic Service Negotiation Protocol (DSNP). DSNP is a protocol to negotiate the Service Level Specification (SLS) at the IP layer. It can be used for service negotiation from host to network, network to host, and network to network. Dynamic negotiation not only provides flexibility to the users, but also lets service providers better utilize their network resources. DSNP can be used in both wireline and wireless networks. It is, however, particularly useful in a mobile environment on account of its light-weight. The usefulness of DSNP is demonstrated on a DiffServ-based wireless testbed.
Key Words: Dynamic Service Negotiation, Wireless Differentiated Service, QoS in Heterogeneous Networks, All-IP Wireless Networks. Contact Author: Prof. Jyh-Cheng Chen Department of Computer Science, National Tsing Hua University, Hsinchu 300, Taiwan Phone: +886-3-574-2961, Fax: +886-3-572-3694, Email:
[email protected]
∗
A preliminary version of this paper was presented at IEEE ICC 2002 in New York, NY, USA.
1 Introduction Today many different wireless systems exist, ranging from wireless Personal Area Networks (PANs), wireless Local Area Networks (LANs) to outdoor cellular systems. Even though these systems are evolving now, they are being developed independently and are incompatible with one another. In spite of ITU IMT-2000’s efforts to unify the third generation (3G) wireless systems, it is widely believed that the incompatibility will continue to exist in future. No wireless technology has emerged as a common and long-term universal solution. As a result, a mobile user with ubiquitous connectivity is expected to have multiple radio interfaces, so that the user can choose the interface that provides the best instantaneous connectivity. While this will ensure ubiquitous connectivity, the mobile user will experience varied levels of service depending on the wireless system. It is also expected that a user will maintain connectivity through devices with diverse abilities. For example, a Personal Computer (PC) may be used at home or inside an office. While driving, a small handset will be more suitable. A Personal Digital Assistant (PDA) or laptop can be used when traveling. These devices differ not only in their processing and communication capabilities, but also in the applications they can run. Thus, ubiquitous connectivity results in heterogeneous link layer technologies and diverse user terminals. In such a dynamic environment, it is hardly possible for a service provider to envision the service requirements of the users and provision the network accordingly. Users are also hardly to project what level of service they really need. As the user will be charged for the services offered, a user would not want to pay for a high grade of service and not enjoy them due to limitations in the link layer or the device. Also, the user does not want to be serviced at a lower grade, if a higher grade of service is feasible. Such requirements can be satisfied only if the user is allowed to negotiate the service requirements dynamically. For example, a premium user carrying a device with limited capabilities can dynamically lower the service quality that matches with the user’s device. The user can again upgrade the service quality, once the user obtains a device with superior capabilities. Similarly, a service provider may advertise a lower price for the services, if the network resources are underutilized. During periods of 2
overload, the service provider can negotiate with users to lower their service grade. Dynamic service negotiation offers flexibility in providing quality of service (QoS) to a mobile user. Realizing this, next generation wireless initiatives such as 3GPP and 3GPP2 have mandated dynamic service negotiation capability. For instance it says in 3GPP TS 23.107 that “QoS behaviour should be dynamic , i.e., it shall be possible to modify QoS attributes during an active session.” [1]. Similarly, 3GPP2 X.S0013-002 specifies that “Dynamic QoS Negotiation and Resource Allocation: Changes (upgrading or downgrading) of QoS provided to an active IMS session shall be supported based on either the request from the IM application or the current network loads or radio link quality.” [2]. This dynamic service negotiation should be supported in the time scale of user mobility and a mobile user should be able to negotiate with the home and visiting service providers dynamically. When the user is roaming, the home and visiting providers should also be able to negotiate with each other to decide the service that can be offered to the user. While the advantages of dynamic service negotiation have been accepted, there is no universal standard protocol for carrying out the same in an end-to-end fashion. Although the 3GPP initiative has proposed a protocol for negotiating the Radio Access Bearer (RAB) [3, 4], it is specific for the UMTS architecture and is restricted only to the radio link in 3GPP networks. As IP (Internet Protocol) is becoming a promising universal network-layer protocol over all wireless systems, in this paper we propose Dynamic Service Negotiation Protocol (DSNP) – a protocol to negotiate Service Level Specifications (SLS)† at the IP layer. DSNP can be used for dynamic service negotiation from host to network, network to network, and network to host. Since DSNP negotiates at layer three, it can be used for end-to-end service negotiation in a network with heterogeneous link layers. In addition, as it is based on IP, DSNP could be used for any IP-based network including 3GPP, 3GPP2, and the Internet. The rest of the paper is organized as follows. In section 2, we enumerate the essential characteristics of any service negotiation protocol. Under section 3, we compare and contrast DSNP A SLS [5] is a set of parameters. The parameters and their values together define the service offered to a traffic stream by a Differentiated-Service domain. †
3
with other related protocols. Section 4 provides an overview of DSNP, while section 5 describes the details of the protocol. We discuss our experimentation on a real-life testbed in section 6, and finally conclude in section 7.
2 Characteristics of a Service Negotiation Protocol In this section, we delineate the essential characteristics of any protocol for dynamic service negotiation. 1. Transparency to link layer technologies: Although diverse wireless communications systems exist, they essentially consist of several Radio Access Networks (RANs) and a Core Network. A RAN provides radio resources (e.g., radio channels) for mobile users to access the core network. The core network is typically a wireline network used to interconnect RANs and to connect the RANs to other networks such as the Internet. It is expected that different kinds of RANs, each optimized for distinctive environments and service requirements, will coexist in the future. To inter-operate and support universal roaming, the core network potentially will be based on IP. Figure 1 gives a schematic representation of a heterogeneous wireless network. The RAN could be based on any link layer such as WLAN, 2.5G, or 3G technologies. If a mobile in RAN 1 is communicating to another mobile in RAN 2, the traffic has to go through heterogeneous link layers, namely through RAN 1, the IP core network, and finally through RAN 2. Hence it is required that any protocol aiming to do end-to-end service negotiation should be compatible with all layer-2 technologies. Such a protocol will also provide the needed transparency for a user moving between disparate wireless environments. 2. Generic QoS Architecture: Traffic between the end hosts may have to pass through networks owned by several service providers. Hence for compatibility, the protocol used for end-toend service negotiation should adopt a QoS architecture that is commonly used.
4
Figure 1: An exemplary heterogeneous wireless network 3. Light-weight: The service negotiation protocol will be used across devices with varying capabilities in terms of battery, computing power, and memory. Therefore, it should be lightweight. Extending protocols that are originally developed for other purposes to do service negotiation might become too complex for a mobile device, when compared to a protocol dedicated just for this purpose. 4. Reduced Signaling Overhead: The protocol should be scalable in terms of the signaling required between the mobile and the service provider. For example, consider a mobile enjoying a certain service that has moved to an adjacent network/cell with enough resources. The mobile should not be required to negotiate for the same service again, just because it has moved to a new network/cell. In addition, the protocol should not demand periodic signaling between network entities to refresh a service that has already been agreed upon. Signaling consumes precious resource like bandwidth and battery power, and hence should 5
be minimized.
3 Related Work Several protocols have been proposed in the literature for dynamic service negotiation. The Resource Negotiation And Pricing (RNAP) protocol developed by Wang et al [6] enables a user/service provider to dynamically negotiate a contracted service, allowing price and transmission parameters to be adjusted according to changes in network conditions and user requirements. RNAP requires the routers along the signaling path to maintain a soft state, resulting in an increased storage overhead. Furthermore, the protocol necessitates a host to periodically send messages to refresh the soft state, wasting bandwidth and energy, both of which are at a premium in wireless networks. In addition, this protocol does not take mobility into consideration. As a result, whenever a mobile moves to a new location, additional signaling is required between the user and the network for establishing an already negotiated service. Another protocol that has been proposed in the literature for service negotiation is COPSSLS [7], which is an extension of the Common Open Policy Service (COPS) [8] protocol. While such an extension to COPS does enable a network entity to negotiate, it increases the complexity of the already sophisticated protocol. Hence, it remains to be seen if COPS-SLS will be viable for devices with limited resources such as PDAs. Service negotiation protocol (SrNP) [9] is a protocol dedicated for service negotiation in wired networks. This protocol is not specific to any SLS format and is general enough to be applied for negotiating any document which in the form of attributevalue pairs. On account of the generality, SrNP messages could potentially have computationally expensive, verbose textual encodings which affects the protocol’s applicability for devices with limited capabilities. Simple Inter-domain Bandwidth Broker Signaling (SIBBS) [10] is a protocol proposed by the QBone group to enable communication between two bandwidth broker peers in adjacent domains. This protocol requires the signaling end-points to maintain long lived TCP connections, and there6
fore may not be suitable for a wireless environment with mobile hosts. IETF’s Next Step in Signaling (NSIS) charter has recently proposed a QoS signaling protocol referred to as “QoS NSIS Signalling Layer Protocol (QoS-NSLP)” [11]. QoS-NSLP too uses soft-state, peer-to-peer refresh messages as the primary state management mechanism. As said earlier, such periodic refresh messages consume both wireless bandwidth as well as the battery power of a wireless device. Hence QoS-NSLP may not be well suited for wireless environments. A comparison of some service negotiation protocols can be found in [12]. In designing DSNP, we have taken into consideration both user mobility and the wireless environment’s constraints on bandwidth and power. A mobile using DSNP for service negotiation is not required to maintain a continuous TCP connection, nor is it required to send periodic refresh messages. Also, when the mobile moves to a new location, it is not expected to do any additional signaling to establish an already negotiated service, provided the new network has enough resources to support the service. Thus, DSNP is more suited to wireless settings than the existing protocols. In addition to the above, several link layer service negotiation protocols have also been proposed. 3GPP has proposed a protocol for dynamically negotiating and re-negotiating the RAB service in 3GPP networks [3, 4]. However, it is a link-layer protocol and can be used only for negotiating services over the Iu interface in 3GPP networks. At the IP layer, the PDP (Packet Data Protocol) Context Modification in 3GPP networks can modify the QoS profile of an active session [13, 14]. However, the PDP context is confined between mobile station and Gateway GPRS Support Node (GGSN) only. It cannot be used for end-to-end service negotiation in heterogeneous networks. Both RAB negotiation and PDP context modification can be used only in 3GPP networks, and cannot be used in different wireless environments. There are other work in the open literature that discuss QoS negotiation [15–17]. They primarily focus on devising strategies for accepting or rejecting a request so that the system utilization is maximized. They do not describe the mechanics of QoS negotiation. Our work is not concerned with devising optimal strategies for admission control. We aim at developing a standard 7
methodology for service negotiation.
4 Overview of DSNP In this section we provide an overview of DSNP, in terms of its features and operation.
4.1 Compatibility with Link Layer Technologies As stated earlier, an end-to-end service negotiation protocol should be independent of the link layer. DSNP achieves this by carrying out the service negotiation at the network layer, and IP is taken as the network layer protocol. IP, already an universal network-layer protocol for wireline packet networks, is also becoming a promising universal network-layer protocol over all wireless systems. The access networks and the core networks in the next generation initiatives like 3GPP and 3GPP2 will be based on IP. IP is envisioned to provide a globally successful open infrastructure for services and applications. Such an all-IP wireless and wireline network could also make wireless networks more robust, scalable, and cost effective. Thus it is viable to consider IP as the network layer protocol. The advantage of negotiating at the network layer is that, users only need to understand one protocol and negotiate at the IP layer when roaming in a heterogeneous environment. They need not know the specific radio negotiation protocol for roaming into a particular radio access network. This does not mean that if DSNP is used, negotiation at the radio link layer is not useful or a radio negotiation protocol is not necessary. The strength of DSNP lies in providing a common platform for dynamically negotiating end-to-end services across incompatible wireless networks. This also implies that the mapping/inter-working between DSNP and the radio QoS protocols needs to be defined. However, this subject matter is outside the scope of this paper.
8
4.2 QoS Architecture As the negotiation takes place at the IP layer, DSNP’s QoS architecture should work well in an IP setting. The IETF has proposed various frameworks for providing QoS on IP networks, such as Differentiated Services (DiffServ or DS) [18], Integrated Services (IntServ) [19] with RSVP [20], and Multi-Protocol Label Switching (MPLS) with Constraint-based Label Distribution Protocol (CR-LDP) [21]. It is well known that the per-flow reservation strategy of IntServ with RSVP for signaling and reservation is not scalable to large networks. DiffServ is a promising technology for providing QoS over IP networks in a scalable manner. It is very likely that QoS will be provided in the core networks of 3GPP and 3GPP2 architectures through DiffServ [22, 23]. Consequently it follows to design DSNP’s QoS architecture in the framework of DiffServ. Figure 2 shows the QoS architecture of DSNP, which consists of three major components: • Mobile Station (MS): MS is the device that allows users to communicate, and also provides means of interaction between users and the networks. Traffic is generated/received by MS and may be queued in the MS while waiting for transmission/reception. • QoS Global Server (QGS): As shown in Figure 2, there is one QGS in each administrative domain. The QGS has the global information of the resource available in the whole domain ‡ . Essentially, it is a Bandwidth Broker (BB) with extension for wireless networks. The MS interacts with the QGS when it requests certain degree of QoS in the domain. The QGS is the entity for QoS negotiation and signaling between the MS and the network control system, i.e. it is in the control plane. The QGS decides what services are available for each MS and sends the decision to the related edge nodes. The QGS is an intelligent entity for decision making, and it essentially functions like a Policy Decision Point (PDP) in the Policy Framework [8, 26]. The exact mechanisms employed by the QGS to gather this information are outside the scope of this paper. For instance, the QGS can use protocols such as SNMP [24] or QOSPF [25] to collect information about the resources available in the domain. ‡
9
Figure 2: QoS architecture followed in DSNP. • QoS Local Node (QLN): QLN is the edge router residing in the boundary of the DS domain as depicted in Figure 2. QLN does not interact with MS directly for QoS negotiation and signaling. It provides the local resource availability information to the QGS, which takes decisions on admitting a request. After allocating a certain degree of QoS to a MS, QGS sends this information to the QLN serving that MS. Based on this information, QLN performs conditioning on the traffic originating/terminating at the MS. It functions like a Policy Enforcement Point (PEP) defined in the Policy Framework [8, 26]. In contrast to QGS, QLN handles the actual traffic, and thus it is in the transport plane.
10
Other components in a wireless DiffServ network such as DHCP [27] server and Authentication, Authorization, and Accounting (AAA) server are assumed to be present. By separating the control and transport planes, the architecture becomes flexible for adding new services, and offers easy interoperability with legacy networks. Given the centralized nature of QGS, one may wonder about this architecture’s scalability. It is to be observed that the above architecture separates signaling traffic from data traffic and the QGS is responsible for handling only the signaling traffic. When compared to data traffic, the signaling traffic is much smaller and hence QGS should be able to handle a large number of users. It is also to be noted that such centralized controllers have been successfully employed in other IETF protocols such as Megaco [28], COPS [8], and Middlebox [29]. Therefore, implementing a centralized QGS is certainly scalable. Alternatively, if need be, the QGS can be implemented in a distributed set-up too. Multiple QGSs can be installed around the domain, and their databases can be kept synchronized through synchronization protocols such as Server Cache Synchronization Protocol (SCSP) [30]. With synchronized databases, the responsibility of servicing different RANs in the network can then be partitioned among the different QGSs. The architecture discussed in this section is generic and could be applied to any QoS framework based on DiffServ and policy-based QoS management. Despite there being many differences between 3GPP and 3GPP2 networks, a generic packet-switched network of 3GPP and 3GPP2 could be presented by Figure 3 [14, 31, 32]. In Figure 3, the Policy Decision Function (PDF) in both 3GPP and 3GPP2 networks functions as the PDP/QGS [22, 23]. The PEP/QLN might reside on GGSN/PDSN or other components. Although DSNP is illustrated by using the architecture depicted in Figure 2, it should be applicable to other DiffServ and policy-based QoS architectures such as 3GPP and 3GPP2 networks.
11
Figure 3: Generic architecture of 3GPP and 3GPP2 networks
4.3 QoS Management and Mobility in DSNP In a DiffServ network, traffic with different service requirements are marked differently, and are treated differently at each router. The marking is done at the edge router where the traffic first enters the domain. At this edge router, the traffic is also checked for conformance, and shaped accordingly. Since DSNP’s QoS architecture is based on DiffServ, the ingress router serving a specific MS should be aware of its QoS requirements, so that the traffic can be appropriately marked for service. In wired networks, it is easy to identify the edge router that has to do the traffic conditioning for a specific user. However, in wireless networks, the edge router that serves a MS keeps changing due to mobility. The problem in wireless networks is to track the location of the user and inform the appropriate edge router about the MS’s QoS profile. One way of solving this problem is to relocate the edge router and transfer the MS’s QoS profile to the new edge router each time when the user moves. This approach, however, may increase the 12
hand-off delay. The other way of solving this problem is to let all edge routers in the domain know the service requirements of a MS. Each time the MS negotiates for a new service, the updated requirements are broadcast to all edge routers. Thus it can be made sure that irrespective of the MS’s location, its traffic will always be conditioned as per the latest QoS profile. While such an approach is simple, it is plagued with inefficiencies. It is far from being effective to replicate the same QoS profile in all the edge routers, as many edge routers may never have traffic coming from or going to a given MS. Also, the database in the edge routers will be huge if there are many mobile users in the domain. In addition, once a MS changes its QoS profile, the same transaction for updating the database must be performed at all the edge routers, which is time consuming. The QGS is a centralized repository that retains the QoS profile of all the users in the domain. It may also know the network topology. Based on this centralized availability of location and QoS information, we can devise a simple, yet scalable, mobility management scheme. Let E U (t) denote the edge router that serves the RAN RU (t) where a MS U is located at time t. Let NU (t) be the set of edge routers that serve the RANs neighboring RU (t). Let us assume that the sub-networks served by RU (t) and NU (t) have enough resources to support the MS’s QoS profile. If the MS chooses to roam, with probability 1.0 it will move in to a RAN served by either E U (t) or one of the members of NU (t). If EU (t) and the routers in NU (t) are all informed about the MS’s QoS profile, the MS can continue to enjoy the negotiated service in the new RAN without any delay. Thus it is sufficient if EU (t) and NU (t) alone maintain the MS’s QoS profile. There are various ways to keep track of EU (t) and NU (t). Assuming each RAN forms an IP subnet on its own, and has a set of associated IP addresses. If a MS moves from one RAN to another, it could obtain a new IP address from the DHCP server in the new RAN. On receiving the request for a new IP address from a MS, the new DHCP server could inform the QGS about the MS’s new IP address. The QGS thus understands that the MS has moved into a new RAN, and updates the new EU (t) and NU (t) with the MS’s QoS profile. Therefore the MS can move freely in the new network enjoying the services, without itself having to perform any additional signaling
13
for the QoS support§ . The routers in the set of NU (t) and EU (t) are collectively referred to as the potential edge routers. We note that while the above scheme is more scalable than the naive broadcast, it is not the optimal. The optimum update scheme is the one wherein the QGS accurately predicts the new location of a MS and updates the relevant E(t) router alone. However, such a scheme would also introduce additional load on the QGS, in terms of running prediction algorithms for determining the location of each of the MSs in the network. While the proposed mechanism of advertising a MS’s QoS profile is not optimum, it does not introduce any computational overheads on the QGS. In other words, the proposed scheme tries to achieve a balance between storage overhead in the edge routers and computational overhead at the QGS.
4.4 DSNP’s Working Having discussed the QoS architecture and mobility management, we now describe DSNP’s working under different scenarios. As indicated in Figure 2, we assume DHCP and AAA servers are present. New IP address is obtained from DHCP server. Initial negotiation after powering up When a MS is powered up, it registers with the DHCP server to obtain an IP address. Before the MS can communicate with any other node, it has to negotiate the services for its traffic. Negotiation is initiated with the QGS if the MS does not have any existing services. On receiving a request from a MS, the QGS checks to see if enough resources are available in the domain to provide the necessary service. The mechanism by which the QGS allocates resources for a MS, and arrives at the decision of admitting a new request is outside the scope of this work. This can be done in many different ways, for example local predictive resource reservation presented in [33]. The QGS may also consult with the AAA servers (for accounting and authorization purposes) The MS may have to initiate additional QoS signaling if the sub-network into which it moves is congested. We shall discuss this scenario in section 4.4. §
14
DHCP Server
MS
AAA Server
QGS
QLNi
DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPACK SLS_LIST_REQUEST SLS_LIST_RESPONSE SLS_NEGO_REQUEST AAA REQUEST AAA RESPOND UPDATE ACK SLS_NEGO_RESPONSE
actual traffic
Figure 4: Example flow for initial set-up or with QGS in other domains (should the MS send/receive traffic to/from other domains), before deciding to offer the requested services to the MS. If there are not enough resources to provide the service, or if the MS is not authorized to receive the requested service, the QGS sends back a negative acknowledgment to the MS. The negative acknowledgment also includes the reason for turning down the request, and a list of services that the MS can currently subscribe to. Including such information might induce the MS to negotiate again for a different service, which otherwise, may not renegotiate at all. If the QGS accepts the service request of the MS, it informs the the related QLNs so that they can condition the MS’s traffic accordingly. COPS [8] or SNMP [24] can be used for communication between the QGS and the edge routers. The QGS then sends a positive acknowledgment to the MS, after which the MS can start enjoying the new service. This sequence of operations is 15
MS
AAA Server
QGS
SLS_NEGO_REQUEST
AAA REQUEST
AAA RESPOND
QLNi
UPDATE
ACK
SLS_NEGO_RESPONSE
actual traffic
Figure 5: Example flow for re-negotiating SLS within the same domain conceptually shown in Figure 4. Re-negotiating an existing QoS Once a MS is up and the QoS negotiation is done, the MS is free to move within the same domain without any QoS signaling. However, the MS may want to change the SLS and renegotiate with the network for new service level. Figure 5 plots an example flow for this purpose. It is similar to Figure 4 except that the MS has the IP address and the list of SLS already. Intra-domain mobility When a MS roams in to a new RAN within the same administrative domain, i.e., the domain served by the same QGS, the MS may obtain a new IP address. As discussed in section 4.3, its QoS profile would have been sent to all the potential QLNs by the QGS. If the networks served by the potential QLNs have the required amount of resources to support the MS’s QoS profile, then the MS can transmit/receive traffic without any additional QoS signaling. Figure 6 depicts an example flow for moving within the same domain but different IP subnet. 16
DHCP Server
MS
QLNi
QGS
DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPACK actual traffic
Figure 6: Example flow for moving within the same domain Let us now consider the case in which a MS moves from subnet R to a new subnet R 0 , such that R0 does not have enough resources to support the MS’s current QoS profile. In this scenario, as soon as the MS moves into R0 , the QGS negotiates with the MS for a reduced level of service. Since the QGS has a global knowledge of the resources available in the entire network, it can present a new service level that can be supported by R 0 . The mobile can either choose to accept this new (reduced) service level or terminate its contract altogether. The mobile can re-negotiate for an improved service once it has moved out of R 0 . Inter-domain mobility When a MS moves to a new administrative domain, usually it needs to initiate the QoS signaling with the new QGS. The new QGS checks for the resource availability and may also consult with the new AAA server, old AAA server, and the old QGS to decide whether it should admit or reject the QoS request. After that, the operation is similar to what has been described above. Figure 7 illustrates an example flow when a MS roams into a new domain.
4.5 Inter-working between DSNP and RAN admission control mechanisms This section briefly comments on the inter-play between DSNP and RAN admission control mechanisms, although this topic is outside the scope of this paper. In a 3G wireless network, an user 17
New DHCP Server
MS
New QGS
New AAA Server
Previous QGS
Previous AAA Server
QLNi
DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPACK
SLS_NEGO_REQUEST AAA REQUEST AAA REQUEST AAA RESPOND AAA RESPOND SLS_NEGO_REQUEST SLS_NEGO_RESPONSE UPDATE ACK SLS_NEGO_RESPONSE actual traffic
Figure 7: Example flow for roaming into a new domain would negotiate his/her service requirements with the QGS in the core network using DSNP. Since the QGS has a complete knowledge of the resources available in the entire network (including the RANs), it can decide through some admission control mechanism the admissibility of the negotiated service. DSNP’s operation is independent of the admission control mechanisms used by the QGS and the RANs. Consequently, its deployment does not conflict with the operation of any admission controller. However, conflicts between the QGS and RAN admission controllers can arise, either when the QGS does not have a complete knowledge of the resource availability or when the QGS and RAN admission controllers use dissimilar admission control mechanisms. In either case, the conflict can be resolved by having the QGS check with the QLN controlling the MS’s RAN before accepting the requested service. If the RAN does not have enough resources, the QGS can then use DSNP to re-negotiate the service with the user to a level that can be supported by the 18
RAN.
5 Protocol Details In this section, we discuss the service model of DSNP and DSNP’s messages.
5.1 DSNP Service Model So far, we have used the terms QoS profile, and service agreement to allude to the services offered by the network to a user. In DSNP, the “QoS profile” of a user is referred to as the user’s Service Level Specifications (SLS) [5]. SLS describes the traffic characteristics of IP flows originating from/terminating at the user’s equipment, and the service guarantees offered by the network for these flows. It is this SLS that gets negotiated using DSNP. The SLS is composed of various attributes, and so far no standard models have been accepted in the literature for defining it. In DSNP, we follow a model similar to the one found in [34], and characterize SLS by the following attributes: 1. Scope Specification: The scope of a SLS refers to the topology or the geographical area over which the service has to be offered. The scope is specified by enumerating the ingress and egress routers for the traffic associated with the SLS. The ingress and egress points respectively denote the entry and exit points of the traffic relative to the network. It is not necessary that a user should be aware of the scope of his/her traffic. In case the user does not have any knowledge about the ingress/egress points, the protocol offers an option of specifying a wild-card address in the scope. This specification also offers a mechanism for carrying out QoS management for a mobile user. For example, if a MS can define the ingress/egress points for its traffic, then it is clear that, its mobility is restricted to those RANs served by the ingress routers. Thus it is sufficient if only those edge routers listed in the scope are informed of the MS’s service requirements. 19
2. Flow Specification: A flow is defined as a distinguishable stream of related datagrams requiring the same QoS. Associated with each SLS are a set of flows. The flow specification attribute identifies the flows that belong to the SLS being negotiated. The flows are identified by specifying one or more of the parameters such as source and destination IP addresses, source and destination port numbers, and DS code points. Based on these specifications, the ingress router classifies the packets and marks them with the appropriate DS code so that the packets belonging to these flows enjoy the negotiated service. The set of allowed values for flow and scope specifications can be influenced by the IP routing scheme used in the domain. For example, if the flow is specified by the source (S) and destination (D) addresses, and the scope is left unspecified, then it implies that the traffic between S and D need not use any specific ingress and egress points. The ingress and egress are decided by the underlying routing scheme based on the address of S and D. On the other hand, if the scope is defined by specific ingress (I) and egress (E) points, then it is clear that the traffic must go through the path S → I → E → D, which may or may not be allowed by the underlying routing scheme. 3. Traffic Specification: The traffic specification provides an effective description of the flows associated with the SLS. The flows in a SLS are characterized by their peak rate, average rate, and minimum packet size. Based on these traffic specifications, the ingress nodes at the network do a conformance testing on the packets that belong to the specified flows. Only those packets that conform to the traffic specifications enjoy the negotiated service. Packets that do not conform to the negotiated traffic parameters can be dropped, shaped and/or remarked. 4. Performance Guarantee Specification: This describes the service guarantees that the flows identified by the flow ID and conforming to the traffic specifications will enjoy over the geographical region given by the scope. The service guarantees are given in terms of parameters like delay, jitter, packet loss and throughput, and can be specified either quantitatively or 20
qualitatively. A parameter is said to be quantified if a definitive numerical value is assigned to it. A qualitative parameter is one whose value is set in comparison with others. In other words, the value for a qualitative parameter cannot be quantified. 5. Service Schedule Specification: This elucidates the start and end times of the negotiated service, i.e., it indicates when the service will become available. This attribute helps in the negotiation of futuristic service guarantees. 6. SLS Identifier: Each SLS is recognized by a unique identifier. This offers flexibility in terms of enabling a client to negotiate a particular attribute of a SLS. The SLS ID is usually decided by the network service provider.
5.2 DSNP Messages DSNP has several messages defined in order to carry out different aspects of negotiation. This section describes the various messages specified in DSNP. Before that, we will introduce the terms of DSNP Client and DSNP Server. • DSNP Client : A DSNP client is the one that initiates the SLS negotiation. • DSNP Server : A DSNP server is the one that responds to the SLS negotiation. The term client does not always refer to the user¶ . It can refer to either a host or the network. For example, when a host wants to negotiate with the service provider for a SLS, the host acts as the DSNP client. The service provider acts as the DSNP server. When a service provider initiates the SLS negotiation with a host, the service provider acts as the DSNP client and the host acts as the DSNP server. When a service provider negotiates a SLS with another service provider, the former acts as the DSNP client and the latter acts as the DSNP server. Thus the entities referred to by the terms client and server are context sensitive. We now explain the DSNP messages in the context of an intra-domain service negotiation. ¶
The terms of host and user have been used interchangeably in this paper.
21
• SLS LIST REQUEST: This message is sent by a DSNP client to the DSNP server to request for a list of SLSs offered by the DSNP server. A DSNP client may send this message when it has just booted up and does not have any SLS parameters. • SLS LIST RESPONSE: This message is sent in response to the SLS LIST REQUEST message, by the DSNP server. This message lists all the SLSs that are provided by the DSNP server. The time of availability for each service may also be included in the list. • SLS NEGO REQUEST: This message is usually sent by a DSNP client to the DSNP server to request a particular SLS. The requested SLS could be one of those listed in the SLS LIST RESPONSE message. Alternatively, it could also be customized to include a set of predefined SLSs. This message is used in both requesting for a new SLS as well as for updating an existing one. This message can be sent by both the user as well as the network. For example, if resources in the network become scarce, the network sends this message to the hosts requesting them to update their existing SLS to suit the current network conditions. The DSNP server could offer cost incentives to the hosts that accept the suggested SLS. Similarly, when there are unused resources available, the network could also offer them at a lower price to the users. It could do an advertisement by sending out SLS NEGO REQUEST messages with the available SLSs and the cost. Additionally, if the network wants to forcefully terminate a SLS of a user due to some reason, it sends a SLS NEGO REQUEST message to the user with appropriate fields set to ZERO. • SLS NEGO RESPONSE: This message is sent in response to the SLS NEGO REQUEST. This message indicates whether the requested SLS is accepted or not. If the requested SLS is not accepted, then the reason for not accepting is also provided. For example, if the DSNP server does not accept the SLS of a DSNP client due to lack of resources, it sends back a response indicating a reject along with the maximum SLS that could be supported. Including such information might induce the client to negotiate again for a different service, which otherwise, may not renegotiate at all. 22
• SLS STAT REQUEST: This message is sent by a DSNP client to the DSNP server asking for a feedback on the statistics of the actual usage of each SLS. The DSNP client could ask for statistics like packet loss, throughput, average delay, and jitter for the traffic flows associated with a particular SLS of the client. • SLS STAT RESPONSE: This message is sent in response to the SLS STAT REQUEST message, by the DSNP server. The server collects the necessary information and sends it to the DSNP client that requested the information. The above messages can also be used for an inter-domain negotiation between two service providers. The service provider that requests for some service acts as the DSNP client, and the other one providing the requested service acts as the DSNP server. The nature of interaction remains the same as described above.
5.3 DSNP Message Format Within each of the messages discussed in Section 5.2, there are several sub-types. Each sub-type is concerned with one of the several attributes of SLS described under Section 5.1 and has an associated message format. Due to space limitations, we haven’t presented the message formats here. Please refer to [35] for a detailed discussion on the DSNP message formats.
6 Testbed and Experimental Results We have implemented DSNP on a wireless DiffServ testbed consisting of a number of laptops, base stations, and routers. The radio layer transport is carried over an IEEE 802.11 complaint WaveLAN system. A cdma2000 emulator that emulates the Packet Data Layer in the Link Access Control (LAC) sublayer of cdma2000 is incorporated. Mobility management for the MS is done using either Mobile IP or Session Initiation Protocol (SIP) [36]. Each MS is equipped with a
23
digital video camera and is capable of running video conferencing tools. Section 6.1 outlines the experiments, while Section 6.2 presents the experimental results.
6.1 Experiment Outline Detailed experiments have been performed on the testbed to test the efficacy of DSNP. We have a single domain with three wireless subnets S1, S2 and S3, in the testbed. We have a QGS for the entire domain and three QLNs, one for each of the subnets. The QLNs are at the edge of the domain. The domain is DiffServ enabled. As mentioned earlier, the subnets are 802.11 compliant WaveLAN systems. As we have only one QGS in the testbed, we restrict ourselves in using DSNP for host to network negotiations. Also we negotiate only for bandwidth in our experiments. Bandwidth is allocated at the edge routers using filters implementing Class Based Queueing (CBQ). Initially, the MS is in its home subnet. It negotiates for some service with the QGS using DSNP. Once the service is negotiated, it starts different multimedia sessions with different service requirements. Then, the MS begins to roam. On the way, it terminates some of its ongoing sessions and starts new ones. It also dynamically negotiates new service rates for its ongoing sessions using DSNP. It roams through the other two subnets and finally comes back to its home subnet.
6.2 Experimental Results We performed experiments by using real multimedia applications as well as traffic generators. We first discuss the results from traffic generators as they bring out more clearly the various characteristics of the DSNP. The measurements reported in this paper were made at the Correspondent Host (CH). Figures 8–12 illustrate experimental results by using traffic generators. Figure 13 demonstrates results from a real video application. Figure 8 shows the result from UDP traffic with three different service types. The total capacity of the wireless link connecting the MS to the wired network is around 1.2 Mbps. To start with, the MS is in its home subnet S1, and does not negotiate any service with the QGS. Using the traffic 24
1200 Best Effort (UDP) QoS − I (UDP) QoS − II (UDP) Handoffs
Throughput (Kbps)
1000
800
600
400
200
0
0
100
200
300
400
500
600
Time (seconds)
700
800
900
1000
Figure 8: DSNP experiment with traffic generator (all UDP) generator, the MS starts a UDP session BE (best effort) with the CH. This UDP session constantly pumps in data into the network at a rate of 1.5 Mbps. Note that, as there is no SLS set-up, this session will be treated as best-effort by the DiffServ network. As there is no other competing traffic, the traffic from BE enjoys the entire bandwidth of 1.2 Mbps. We can see this in the graph between the times t = 0 and t = 50 sec. Then around t = 50 sec, the MS negotiates a bandwidth of 600 Kbps for a new flow QoS − I. The MS uses DSNP for negotiating bandwidth with the QGS. The QGS on accepting this negotiation, sends the service profile to the the set of potential QLNs. After a successful negotiation, the MS starts the QoS − I flow, which is another UDP session. The data for QoS − I session is pumped into the network at 800 Kbps. From the graph, we notice two points: 1. Even though the data for QoS − I session is pumped at 800 Kbps, only the negotiated rate of 600 Kbps reaches the CH. This means, the network ONLY provides the negotiated service to the user. The excess 200 Kbps is dropped at the network ingress by the QLNs. 2. Before the start of QoS − I session, the session BE enjoyed a bit rate of 1.2 Mbps. As soon as QoS − I started, the bandwidth enjoyed by BE falls to 600 Kbps. This is because, the 25
session QoS −I has a negotiated service from the network and hence is treated preferentially when compared to BE. The excess data from BE is dropped at the domain edge. After starting QoS − I, the MS begins to roam. As it roams, it moves from its home subnet S1 to another subnet S2. As it moves into S2, the base station in S1, hands it over to the base station in S2. This is the first handoff and occurs around t = 170 sec. The QGS in the network detects this movement of the MS and instructs the QLN in subnet S2 to deliver the negotiated service for the MS. From the graph, we can see that the flows BE and QoS − I from the MS continue to enjoy the same negotiated service in the new subnet too. This validates that even across handoffs, the same negotiated service can be maintained without additional QoS signaling. After moving into S2, the MS negotiates with the QGS using DSNP asking a bandwidth of 200 Kbps for a new UDP flow QoS − II. After a successful negotiation, the MS starts QoS − II around t = 250 sec. The data for QoS − II session is pumped into the network at the rate of 500 Kbps. Again, excess packets are dropped. From the graph, we can see that as soon as QoS − II is started, the bandwidth enjoyed by BE falls from 600 Kbps to 400 Kbps. However, QoS − I still continues to enjoy the same bandwidth of 600 Kbps. This means that any QoS traffic in the network continues to enjoy the negotiated level of service even in the presence of other QoS traffic. Only the best-effort traffic suffers in the presence of other QoS traffic. The MS then starts roaming again and moves into subnet S3. This is the second handoff and occurs around time t = 350 sec. We again notice here, all the flow enjoy their negotiated QoS even in the new subnet without any additionally signaling. After staying in S3 for some time, the MS turns back and retraces its path. It moves into subnet S2 from S3 around time t = 470 sec. From the graph, we see that all the three flows BE, QoS − I, and QoS − II still continue to enjoy the same levels of service across the two handoffs. In subnet S2, the MS terminates the flow QoS − II around time t = 540 sec. As soon as this flow is terminated, the traffic from BE allowed in the network increases from 400 Kbps to 600 Kbps. After roaming into S2 for some time, at time t = 650 sec, the MS uses DSNP to dynamically negotiate a bandwidth of 400 Kbps for its ongoing QoS − I. We see that after a successful dynamic negotiation, the bandwidth enjoyed by QoS − I 26
1200
Best Effort (TCP) QoS − I (TCP) QoS − II (TCP) Handoffs
Throughput (Kbps)
1000
800
600
400
200
0
0
200
400
600
Time (seconds)
800
1000
1200
Figure 9: DSNP experiment with traffic generator (all TCP) falls to 400 Kbps from 600 Kbps. As before, the traffic from BE increases from 600 Kbps to 800 Kbps to utilize the additional bandwidth. The MS then comes back to its home subnet S1 and this final handoff occurs around time t = 780 sec. The session QoS − I is terminated by the MS around t = 860 sec. As soon as QoS − I is terminated, the traffic from BE increases to its initial bit rate of 1.2 Mbps. With this experiment, we show that using DSNP we can dynamically negotiate the service at any instant. We also demonstrate that the proposed scheme for managing QoS in a mobile environment can indeed maintain the negotiated service for various flows even across handoffs without any additional QoS signaling. We repeated the same experiment with all TCP flows, and a mixture of TCP and UDP flows. The results for the case where all the service types are TCP are shown in Figure 9. The maximum bandwidth on the wireless link during this experiment was found to be only 1.0 Mbps as opposed to 1.2 Mbps. This can be attributed to the unusually strong noise in the wireless link. For the case where the traffic is a mixture of UDP and TCP, one of the results is shown in Figure 10. The same discussions above can be extended to these results as well.
27
1200
Best Effort (TCP) QoS − I (UDP) QoS − II (UDP) Handoffs
Throughput (Kbps)
1000
800
600
400
200
0
0
200
400
600
Time (seconds)
800
1000
1200
Figure 10: DSNP experiment with traffic generator (TCP and UDP) The figures shown above are based on the results of one MS. Figures 11–12 present the experimental results with different number of mobile stations. Figure 11 depicts the QGS response time when the number of mobile stations increases. The QGS response time was measured from the time the MS sent out SLS LIST REQUEST until the time the MS received the SLS NEGO RESPONSE as shown in Figure 4. The QGS response time would be determined by the QGS processing power and the link capacity of the wired and wireless networks. In the experiments, the wired network was constructed by using 100 M bps Ethernet. The wireless network was based on 802.11b with 11 M bps. The QGS was a PC with Pentium IV 2.8 GHz CPU and 256 M B RAM. As the number of mobile stations increases, the wireless link access delay could be significant because of many competing MSs. In addition, the QGS would need to process many requests simultaneously. Therefore, the QGS response time increases when the number of mobile stations increases. Figure 11 shows that in our testbed the QGS could support around 10 mobile stations. After that, the QGS response time increases significantly. Figure 12 shows the handoff delay which includes the QGS response time plus the Mobile IP handoff delay. In the experiment, we assume that each MS roams into a domain which does
28
QGS Rsponse Time (second)
2.2 2.1 2.0 1.9 1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Number of MS
Figure 11: QGS response time vs. number of mobile stations not have the MS’s QoS profile. Therefore, the MS needs to negotiate with the new domain after handing off. Thus, in addition to Mobile IP handoff delay, the QGS response time is also included. Similar to Figure 11, Figure 12 shows that the handoff delay increases when the number of mobile stations increases. Figure 12 shows that in our testbed the QGS could support around 9 mobile stations. Figure 13 shows the experimental results of using vic, a real-time video-conferencing application. The data rates reported in the graph are obtained by collecting the tcpdump output on the RTP packets of the vic. Using the time stamps available in the dump, the data rate at various instants were calculated. Initially, both MS and CH are in the same subnet. The MS negotiates with the QGS by using DSNP for a video rate of 200 Kbps. Once the request is admitted, the MS roams away from the CH. The MS changes subnet twice therefore there are two IP handoffs which are performed by Mobile IP. The MS then negotiates with the QGS by DSNP again for a video rate of 100 Kbps. After it is accepted, the MS roams back to the same subnet of the CH. There are two IP handoffs on the way back too. Figure 13 indicates that there are two major different video rates: 200 Kbps and
29
Handoff delay (second)
2.2 2.1 2.0 1.9 1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Number of MS
Figure 12: Handoff delay vs. number of mobile stations 100 Kbps. It also indicates that the similar rate can be maintained after handoffs. During handoff, however, the video rate drops and then reaches a peak point. This is because packets are stopped when Mobile IP performs the IP handoff. Excess packets pass through QLN immediately after the IP handoff is done.
7 Conclusion and Future Work Dynamic service negotiation allows users to adapt their needs dynamically. It also allows service providers to better utilize the network. In this paper we have presented a new protocol, DSNP, for dynamic service negotiation. The strength of DSNP is that it is independent of the underlying link layers, and hence can be very useful for a mobile user moving in a heterogeneous wireless environment. Also, the proposed protocol has less overhead in terms of the state information stored at the routers, and the amount of signaling required. Through experimental results on a wireless testbed, we validated the usefulness of DSNP. Our experimental results show that DSNP indeed achieves its design objective of providing scalable service negotiation in mobile networks. An important aspect of service negotiation is pricing. Pricing of network services is quite com30
Figure 13: DSNP experiment with real application plicated and is a research area by itself. It is not clear at this point as how to quantify the price, since the basic unit (currency) may vary geographically. The current version of DSNP does not include pricing, and more work is needed to extend the protocol to cover this important aspect. Another relevant issue in service negotiation, especially in wireless environments, is security. There should be an authentication mechanism for both DSNP client and server to ensure that indeed they are talking to the correct entities. The protocol in its present form, does not perform any kind of authentication. Additional efforts are needed to enhance DSNP by incorporating security.
References [1] 3rd Generation Partnership Project (3GPP), Technical Specification Group, Services and System Aspects, “Quality of service (QoS) concept and architecture (release 6).” 3GPP TS 23.107, Version 6.1.0, Mar. 2004. [2] 3rd Generation Partnership Project 2 (3GPP2), “All-IP core network multimedia domain: IP multimedia subsystem - stage 2.” 3GPP2 X.S0013-002-0, Version 1.0, Dec. 2003. 31
[3] 3rd Generation Partnership Project (3GPP), Technical Specification Group (TSG) RAN, “RAB quality of service negotiation over Iu (release 4).” 3GPP TR 25.946 Version 4.0.0, Mar. 2001. [4] 3rd Generation Partnership Project (3GPP), Technical Specification Group Radio Access Network, “RAB quality of service renegotiation over Iu (release 4).” 3GPP TR 25.851 Version 4.0.0, Mar. 2001. [5] D. Grossman, “New terminology and clarifications for diffserv.” IETF RFC 3260, Apr. 2002. [6] X. Wang and H. Schulzrinne, “RNAP: a resource negotiation and pricing protcol,” in Proc. of International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), (Basking Ridge, NJ), pp. 77–93, June 1999. [7] T. M. T. Nguyen, N. Boukhatem, Y. G. Doudane, and G. Pujolle, “COPS-SLS: a service level negotiation protocol for the Internet,” IEEE Communications Magazine, pp. 158–165, May 2002. [8] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, and . Sastry, “The COPS (common open policy service) protocol.” IETF RFC 2748, Jan. 2000. [9] Tequila
Consortium,
“SrNP:
Service
Negotiation
Protocol.”
http://www.ist-
tequila.org/deliverables (last accessed on April 20, 2005), Oct. 2001. [10] QBone Signaling Design Team, “SIBBS: Simple Inter-domain Bandwidth Broker Signaling.” http://qbone.internet2.edu/bb/index.shtml (last accessed on April 20, 2005), July 2002. [11] S. V. den Bosch, G. Karagiannis, and A. McDonald, “NSLP for Quality-of-Service signalling.” IETF Internet Draft, , work in progress, Feb. 2005. [12] V. Sarangan and J.-C. Chen, “Comparative study of protocols for dynamic service negotiation in next generation Internet,” IEEE Communications Magazine, pp. 151–156, Mar. 2006. 32
[13] 3rd Generation Partnership Project (3GPP), Technical Specification Group, Services and System Aspects, “General packet radio service (GPRS); service description; stage 2 (release 6).” 3GPP TS 23.060, Version 6.5.0, June 2004. [14] J.-C. Chen and T. Zhang, IP-Based Next-Generation Wireless Networks. Wiley, Jan. 2004. [15] T. F. Abdelzaher, E. M. Atkins, and K. G. Shin, “QoS negotiation in real-time systems and its application to automated flight control,” IEEE Transactions on Computers, pp. 1170–1183, Nov. 2000. [16] A. Hafid, G. von Bochmann, and B. Kerherve, “A quality of service negotiation procedure for distributed multimedia presentational applications,” in Proc. of 5th IEEE International Symposium on High Performance Distributed Computing (HPDC-5), (Syracuse, NY), pp. 330– 339, Aug. 1996. [17] T. Plagemann, K. A. Saethre, and V. Goebel, “Application requirements and QoS negotiation in multimedia systems,” in Proc. of 2nd International Workshop on Protocols for Multimedia Systems (PROMS), (Salzburg, Austria), Oct. 1995. [18] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An architecture for differentiated services.” IETF RFC 2475, Dec. 1998. [19] R. Braden, D. Clark, and S. Shenker, “Integrated services in the Internet architecture: an overview.” IETF RFC 1633, June 1994. [20] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource reservation protocol (RSVP).” IETF RFC 2205, Sept. 1997. [21] E. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol label switching architecture.” IETF RFC 3031, Jan. 2001.
33
[22] 3rd Generation Partnership Project (3GPP), Technical Specification Group, Services and System Aspects, “End-to-end quality of service (QoS) concept and architecture (release 6).” 3GPP TS 23.207, Version 6.3.0, June 2004. [23] 3rd Generation Partnership Project 2 (3GPP2), “Support for end-to-end QoS, stage 1 requirements.” 3GPP2 S.R0079-0, Version 1.0, May 2004. [24] J. Case, R. Mundy, D. Partain, and B. Stewart, “Introduction to version 3 of the Internetstandard network management framework.” IETF RFC 2570, Apr. 1999. [25] G. Apostolopoulos, R. Guerin, and S. Kamat, “Implementation and performance measurements of QoS routing extensions to OSPF,” in Proc. of IEEE INFOCOM, 1999. [26] R. Yavatkar, D. Pendarakis, and R. Guerin, “A framework for policy-based admission control.” IETF RFC 2753, Jan. 2000. [27] R. Droms, “Dynamic host configuration protocol.” IETF RFC 2131, Mar. 1997. [28] F. Cuervo, et al., “Megaco protocol version 1.0.” IETF RFC 3015, Nov. 2000. [29] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, “Middlebox communication architecture and framework.” IETF RFC 3303, Aug. 2002. [30] J. Luciani et al., “Server Cache Synchronization Protocol (SCSP).” IETF RFC 2334, Apr. 1998. [31] 3rd Generation Partnership Project (3GPP), Technical Specification Group, Services and System Aspects, “Network architecture (release 6).” 3GPP TS 23.002, Version 6.5.0, June 2004. [32] 3rd Generation Partnership Project 2 (3GPP2), “Network reference model for cdma2000 spread spectrum systems.” 3GPP2 S.R0005-B, Version 1.0, Revision B, Apr. 2001.
34
[33] T. Zhang, E. van den Berg, J. Chennikara, P. Agrawal, J.-C. Chen, and T. Kodama, “Local predictive resource reservation for handoff in multimedia wireless IP networks,” IEEE Journal on Selected Areas in Communications, pp. 1931–1941, Aug. 2001. [34] D Goderis et al., “Service level specification semantics, parameters and negotiation requirements.” IETF Internet Draft, , work in progress, June 2001. [35] J.-C. Chen, A. McAuley, V. Sarangan, S. Baba, and Y. Ohba, “Dynamic service negotiation protocol (DSNP).” IETF Internet Draft, , work in progress, Feb. 2006. [36] J. Rosenberg et al., “SIP: session initiation protocol.” IETF RFC 3261, June 2002.
35
