IETF Next Steps in Signaling S. Lee Working Group J. Bang Internet-Draft SAMSUNG AIT Expires: December 22, 2003 S. Jeong HUFS June 23, 2003 QoS Signaling for IP-based Radio Access Networks draft-lee-nsis-signaling-ran-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 22, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IETF NSIS WG is standardizing IP signaling protocols with QoS signaling as the first use case. It is desirable to consider QoS signaling procedures for resource reservations in an IP-based RAN where mobide nodes undergo frequent handoffs. In this draft, we describe general QoS signaling procedures for an IP-based RAN, which are based on the analysis of the existing QoS signaling solutions in mobile wireless networks. We also present a specific QoS signaling scheme based on the proposed general signaling procedures. Lee, et al. Expires December 22, 2003 [Page 1] Internet-Draft Mobile QoS Signaling June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Mobility and QoS . . . . . . . . . . . . . . . . . . . . . . 5 2.1 The Impact of mobility on QoS . . . . . . . . . . . . . . . 5 2.2 Relationship between mobility and QoS signaling . . . . . . 5 2.3 Brief analysis of some existing solutions based on RSVP . . 5 3. QoS Signaling Procedures for IP-based RANs . . . . . . . . . 7 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Mobile Proxy Agent (MPA) Discovery . . . . . . . . . . . . . 8 3.3 Resource Reservation Setup . . . . . . . . . . . . . . . . . 8 3.3.1 Generation of path setup messages . . . . . . . . . . . . . 9 3.3.2 Generation of resource reservation messages . . . . . . . . 9 3.4 Generation of Reservation Confirmation Messages . . . . . . 9 3.5 Soft State Maintenance . . . . . . . . . . . . . . . . . . . 9 3.6 Fast QoS re-establishment after handoff . . . . . . . . . . 9 3.7 Fast Release of Resources . . . . . . . . . . . . . . . . . 10 3.8 Generation of Error Messages . . . . . . . . . . . . . . . . 10 4. An Approach for QoS Signaling in IP-based RANs . . . . . . . 11 4.1 Fast Resource Reservation and Release . . . . . . . . . . . 11 4.1.1 Basic Functional Entities . . . . . . . . . . . . . . . . . 11 4.1.2 Notification of Handoff Initiation . . . . . . . . . . . . . 12 4.1.3 Message Types . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.4 Fast Resource Reservation . . . . . . . . . . . . . . . . . 14 4.1.5 Fast Resource Release . . . . . . . . . . . . . . . . . . . 19 4.1.6 The Session of the FREE . . . . . . . . . . . . . . . . . . 20 4.1.7 The location of FREE module . . . . . . . . . . . . . . . . 20 4.1.8 FREE Message Formats . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . 23 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24 References . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Lee, et al. Expires December 22, 2003 [Page 2] Internet-Draft Mobile QoS Signaling June 2003 1. Introduction There has been intensive research in the area of mobile computing to provide mobile users access to the Internet. The rapidly growing popularity of IP and its flexibility make it a good candidate for transmission in radio access networks (RANs) which provide the radio access to mobile nodes (MNs)[7]. Recently, there is a growing interest in supporting real-time services in mobile wireless networks. In order for the real-time services to function satisfactorily in an IP-based RAN, we need to ensure that there are adequate resources on the links available in the RAN even after handoff. Since mobility of hosts has significant impact on the quality of service (QoS) provided to a real-time service, it is necessary to provide mobility independent service guarantees. To achieve this, resources should be reserved along the new paths in a very fast manner. Pre-allocation of resources at all locations it may visit during the lifetime of the connection would be one solution. However, in this case, too much bandwidth may be wasted. Although the well-known resource reservation protocol, RSVP [1], sets up resource reservation for realí¨time traffic in the Internet, RSVP is not adequate to make resource reservations for mobile hosts. If RSVP is used in the mobile Internet, a change in the location of the MN may make the reserved path useless and a new path has to be established. This overhead results in inefficient use of network resources and also introduces additional delay. To overcome the drawbacks of RSVP, many solutions have been proposed which are based on the modification or extension of RSVP [4, 5, 6]. However, most RSVP-based solutions for mobility support yet do not have appropriate QoS mechanisms in preventing service disruption at a new location during handoff. The IETF NSIS WG is currently working on general signaling protocols based on the signaling requirements and framework. It is desirable to consider general signaling procedures for resource reservations in an IP-based RAN. In this draft, we describe general QoS signaling procedures for an IP-based RAN, which are based on the analysis of the existing QoS signaling solutions in mobile wireless networks. We also present a specific QoS signaling scheme based on the proposed general signaling procedures. 1.1 Problem Statement Most existing work on QoS guarantees for the Internet did not consider the mobility issue. The mobility problem is concerned with Lee, et al. Expires December 22, 2003 [Page 3] Internet-Draft Mobile QoS Signaling June 2003 maintaining a flow path when the MN moves around geographically. When an MN undergoes handoff from one access router (AR) to another, the path traversed by the MN's packet stream in the network may change. Such a change needs to be limited (or localized) to a small segment of the end-to-end path near the extremity, or it could also have an end-to-end impact. It is also important to rapidly re-reserve resources along the new path after handoff to minimize the impact of handoff on QoS. In addition, the packets belonging to the MN's ongoing session may start using a new care-of address (CoA) after handoff. Therefore, they may not be recognized by some forwarding functions in the nodes even along that segment of the end-to-end path that remains unaltered after handoff[3]. 1.2 Terminology AR: Access Router CN: Correspondent Node CoA: Care of Address CR: Crossover Router LCoA: Local CoA MH: Mobile Host MN: Mobile Node MPA: Mobility Proxy Agent RCoA: Regional CoA Lee, et al. Expires December 22, 2003 [Page 4] Internet-Draft Mobile QoS Signaling June 2003 2. Mobility and QoS 2.1 The Impact of mobility on QoS Mobility of a host has a significant impact on the QoS parameters including packet delay, packet loss, jitter, and throughput. Specifically, when an MN moves from one location to another, the data flow path changes. As a result, the propagation delay of packets may change. The congestion delay at the routers along the new path may be different from that in the previous path. If the new location into which the MN moves, is overcrowded, the available bandwidth in the new location may not be sufficient to provide the throughput it was receiving at the previous location. In addition, the mobile user may suffer temporary disruption of service during handoff while the connection is torn down along the old path and established along the new path. Therefore, the mobile users may have to adapt to these changes as they move with their connections open. In some extreme cases, some connections to the mobile users may have to be dropped if the minimum QoS requirements of all users cannot be satisfied. 2.2 Relationship between mobility and QoS signaling To minimize the QoS re-establishment delays and reduce the packet loss ratio, QoS signaling schemes and mobility mechanisms need to be combined effectively. In this way, resource reservations along the new data path can be installed faster, reducing the disruption to the data flows. This also can improve scalability and reduce signaling overhead because only a small number ofupdate/signaling messages are required. Furthermore, they can be localized to the affected areas of the network only. 2.3 Brief analysis of some existing solutions based on RSVP Like many of previously proposed solutions, our approach is also based on RSVP. In this section, we describe the key features and drawbacks of some existing solutions based on RSVP. This analysis is used in providing general QoS signaling procedures for fast QoS re-establishment in an IP-based RAN. Mobile RSVP (MRSVP)[4], an RSVP extension, was proposed to support. The major feature of MRSVP is passive reservation. This special RSVP session is pre-established to prepare for the possible movement of the mobile host to a new location. In passive reservation, each mobile host must maintain a mobility specification (MSPEC) that includes information on all locations which a mobile host may visit during the lifetime of a connection. MRSVP requires special hosts, Lee, et al. Expires December 22, 2003 [Page 5] Internet-Draft Mobile QoS Signaling June 2003 called proxy agent, to make active/passive reservations along the paths from the locations in the MSPEC of a sender to the locations in the MSPEC of a receiver on behalf of the mobile host. The major drawback of this approach is that the intermediate routers along the reservation paths must manage all state information in the passive reservation. Furthermore, the architecture requires all routers to support passive reservation, and the mobile host is also required to have prior knowledge of its mobility. A method similar to MRSVP was proposed in [5], which employs a predictive reservation and temporary reservation scheme. With this mechanism, a mobile host makes predictive resource reservation in advance at the locations where it may visit during the lifetime of the connection. These locations become the leaves of a multicast tree and the mobility of a host is modeled as transitions in the multicast group membership. To make more efficient use of wireless resources, temporary reservations can temporarily use the inactive bandwidth reserved by the predictive reservations. An architecture for QoS in mobile networks using RSVP and CBQ [6] was proposed, which requires fewer passive reservation-capable routers compared to MRSVP. The major feature of this approach is to use RSVP path extension to guarantee QoS in the mobile Internet. With this mechanism, a reservation path may be extended continuously if the mobile host keeps moving within a QoS domain. Every gateway router also needs to be able to make passive reservations. In addition, there is no way to maintain and extend an existing RSVP session when the mobile host moves into a different administrative domain. Lee, et al. Expires December 22, 2003 [Page 6] Internet-Draft Mobile QoS Signaling June 2003 3. QoS Signaling Procedures for IP-based RANs 3.1 Overview In this section, we give an overview of the general QoS signaling procedures for IP-based RANs. Here we assume that the proposed QoS signaling mechanism is based on RSVP as in many of existing signaling solutions. For simplicity, with the proposed signaling procedures, it is assumed that the MN acts as a receiver. Mobility protocols such as Mobile IPv6 require home agents and foreign agents to aid in routing. Similarly, it is desirable to have Mobility Proxy Agents (MPAs) to manage resources along the paths from the sender to the locations which the MN may visit. The MPA is the key functional entity which is mobility-aware and responsible for handling QoS signaling messages in an IP-based RAN. The MPA's functionalities can be installed at any intermediate router, e.g., a crossover router (CR). The basic functionalities of the MPA include the following: - The MPA keeps track of the valid bindings between the Regional CoA (RCoA) and the local CoA (LCoA) of a MN. The IP address of the MN is always represented by its RCoA format, and the reservation is based on the RCoA [2]. The MPA performs dynamic address translation between the RCoA and the LCoA of the MN as necessary. The MPA keeps RCoAs in its internal reservation state block for MNs. - All signaling messages to the MN in the subnet are delivered via the MPA to which the MN belongs. - The MPA initiates fast pre-reservation on behalf of the MN which is not currently present in the locations that the MN may visit. We assume that the MN knows the locations which it is likely to visit. - The MPA needs to communicate with the ARs which the MN may visit to obtain resource availability information (optional) and to send pre-reservation request messages to them in advance. - A resource reservation is set up from the sender to the MN via the MPA. An important issue is how the MN determines who will be its MPA. To determine the IP address of the MPA, an MPA discovery mechanism can be used. After the MN finds the IP address of its MPA, the next task is to setup the path from the sender to its current location via the MPA using a path setup message (e.g., PATH) from the sender. Resource reservations will be set up along the determined path. On receiving Lee, et al. Expires December 22, 2003 [Page 7] Internet-Draft Mobile QoS Signaling June 2003 the path setup message, the MN sends a resource reservation message (e.g., RESV) for the current reservation. The resource reservation message contains the detailed reservation specification. When the MPA receives a path setup message for an MN, it forwards the path message to the MN. At the same time, the MPA communicates with neighboring ARs which the MN may visit and obtains resource availability information from them. The resource availability information may be forwarded to the MN. In summary, there are several procedures involved in the signaling. These include MPA discovery, initial end-to-end resource reservation setup, reservation confirmation, fast pre-reservation before the handoff is completed, soft state maintenance, fast release of previously reserved resources, and handling of error messages. In the following subsections, we describe each of these procedures in detail. 3.2 Mobile Proxy Agent (MPA) Discovery The MPA manages resources on behalf of an MN. As described above, the MPA is the key functional entity in an IP-based RAN because the resources are managed by the MPA and actual reservations are set up through the MPA. Thus, an MN needs to discover its MPA first. The MPA can be discovered using a multicast address. The MN sends an MPA discovery message, and then an MPA which receives the MPA discovery message responds with a confirmation or reject message. After the MPA sends a confirmation message with its IP address, the MPA and the MN can communicate with each other and exchange necessary information for resource reservations. After the IP address of the MPA is discovered, the next step is to set up a reservation path from the sender to the MPA and the MN. 3.3 Resource Reservation Setup To initiate the actual end-to-end reservation process, the sender has to be informed of the destination IP address of the application flow. If we assume that unicast routing scheme is used, the RCoA of the MN is used as the destination IP address of the application flow. In the unicast routing scheme for unicast flows, the MN will send its LCoA to its MPA, because MPA also needs to know the LCoA of the MN for forwarding all the messages destined for the MN. After the initial communication between the MPA and the MN is completed, signaling messages for actual resource reservation are generated. The following two subsections describe the detailed procedures for generating and processing signaling messages. Lee, et al. Expires December 22, 2003 [Page 8] Internet-Draft Mobile QoS Signaling June 2003 3.3.1 Generation of path setup messages Path setup messages are generated and processed in a way similar to RSVP. That is, they are periodically generated by the sender and intermediate routers along the path to the receiver. The MPA will start receiving the path setup message. The destination IP address in the path setup message should be the RCoA of the MN. 3.3.2 Generation of resource reservation messages On receiving a path setup message, the receiver (e.g., an MN) will generate a resource reservation message (e.g., RESV) and forward it to the previous hop upstream via the current AR and the MPA. This resource reservation message will setup reservation at the routers including the MPA as it travels upstream. When the MPA receives the resource reservation message, it will try to create reservation states for the reservation on the downstream interface. If it fails, it will send a reservation error message to the MN. Otherwise, it will send the resource reservation message for reservation upstream. The reservation error message may contain enough information so that the MN can decide its future direction. 3.4 Generation of Reservation Confirmation Messages As in RSVP, the MN can send a request for confirmation for its reservation request. In this case, the request for confirmation is included in the resource reservation messages. 3.5 Soft State Maintenance The soft state similar to RSVP is maintained to manage the reservation state at routers, MNs, and MPAs. On receiving the resource reservation message, a router sets up state for fast reservation. This state is deleted unless it is refreshed by a new resource reservation message before the refresh timer expires. In addition, for fast QoS re-establishment, pre-reservation state is maintained for a short period. Specifically, the MPA sends a pre-reservation request message to ARs that the MN may visit, and a pre-reservation state is temporarily maintained until the handoff is completed. 3.6 Fast QoS re-establishment after handoff The MPA is responsible for immediate QoS re-establishment after handoff and fast release of resources reserved along the old path. The MPA knows when the handoff begins by receiving a handoff Lee, et al. Expires December 22, 2003 [Page 9] Internet-Draft Mobile QoS Signaling June 2003 initiation message from an MN through the current AR. The MPA then sends a pre-reservation message to all neighboring ARs which the MN may visit, to pre-reserve resources along the new path, in response to the handoff initiation message. 3.7 Fast Release of Resources As in RSVP, reservation states are explicitly torn down when a flow terminates or when the admission control rejects a reservation. In addition, it is needed to release the previously reserved resources along the old path immediately after handoff. To release the previously reserved resources along the old path after handoff, the MPA first needs to receive the binding update message from the MN which arrived at a new AR. On receiving the message, the MPA immediately deletes reservation states of the old session and transmits a reservation release message toward the old AR at the same time. 3.8 Generation of Error Messages If any reservation fails, a reservation error message will be delivered to the MN. The reservation error message may contain enough information so that the MN can decide its future direction. Lee, et al. Expires December 22, 2003 [Page 10] Internet-Draft Mobile QoS Signaling June 2003 4. An Approach for QoS Signaling in IP-based RANs The goal of this protocol is to allow MN to obtain a DAD-free NCoA as soon as it establishes connectivity on a new link. This section describes our protocol in detail.Based on the general QoS signaling procedures described above, we propose a specific signaling scheme for immediate QoS re-establishment and fast release of previously reserved resources along the old path in an IP-based RAN. Like many other solutions, our approach is also based on RSVP. 4.1 Fast Resource Reservation and Release The proposed signaling scheme, called FREE (Fast resource REservation and rElease), pre-reserves resources along the new path and releases resources reserved along the old path before the handoff is completed. The following subsection describes the basic functional entities of FREE. 4.1.1 Basic Functional Entities (1) FREE Manager (FM) As described above, the MPA is the key functional entity for QoS signaling in an IP-based RAN. In our proposed scheme, FREE Manager (FM) plays the role of MPA. The FM is responsible for resource reservation and release in an IP-based RAN. The FM knows when the handoff begins by receiving a FREE_Initiation message from an MN via the its old AR. And then the FM sends a Path_Req message to all neighboring ARs which the MN may visit to pre-reserve resources during the specified timeout period. On receiving a binding update (BU) message, the FM transmits Reverse_Path_Teardown message (or Path_Teardown message) and Resv Teardown message (or Reverse_Resv_Teardown message) if MN is a receiver (or MN is a sender), and deletes path and reservation states of the old session. The FM can be located at any intermediate routers in an IP-based RAN. To optimize the proposed FREE mechanism, the FM can be installed at a CR which connects the old AR with a new AR. The FM also maintains the reservation session from MN to CN as described in Section 4.1.6. If both end terminals are mobile, the FM maintains the reservation session by dividing the state of the reservation session into three subsessions after establishing an end-to-end resource reservation session: MN-to-FM, FM-to-FM, and FM-to-CN. The FM-to-FM is the fixed subsession while the MN-to-FM and the FM-to-CN are the subsessions which change dynamically according Lee, et al. Expires December 22, 2003 [Page 11] Internet-Draft Mobile QoS Signaling June 2003 to MN's handoffs. (2) FREE module of Access Router (FAR) An AR has a FREE-related entity, called FREE module of Access Router (FAR). The FAR forwards the FREE_Initiation message received from the MN to the FM. The FAR can also pre-reserve new resources from the FAR to the FM. If the MN is a receiver, the FAR of a new AR transmits a Resv message to the FM on receiving a Path_Req message from the FM to pre-serve new resources during a certain time interval. However, the FAR forwards the Path_Req message to the MN if it does not establish any new reservation path during the time interval. And then the MN newly re-establishes the necessary resource reservation by only transmitting the Resv message to the FM through the new AR. If the MN is a sender, the FAR transfers the Path_Req message to the FM in response to the FREE_Initiation message from the FM. The FAR does not forward the Path_Req message to the MN although it does not establish any new reservation since the MN is a sender. In this case, the MN re-establishes a new resource reservation by sending the Path message to the FM (via the FAR). 4.1.2 Notification of Handoff Initiation The time when the handoff begins should be known to avoid the excessive resource reservation. The FM can efficiently pre-reserve the requested resources if it knows the time when the MN's handoff starts in advance. To notify the handoff initiation, the MN transmits a FREE_Initiation message to the FAR of the old AR. It is possible for the MN to determine the time when the handoff begins by comparing SNR strength with the threshold value in the hard handoff (e.g., IEEE 802.11). 4.1.3 Message Types TIn order to support our proposed signaling scheme, the following messages need to be defined. The detailed formats of these FREE messages are described in Section 4.1.8 (1) FREE_Initiation message FREE_Initiation message is used to inform the FM of the time when the handoff begins and request the fast pre-reservation before handoff is completed. An MN sends the FREE_Initiation message to the old AR when the handoff begins, and then the old AR forwards it to the FM which may be installed at a CR. On receiving the FREE_Initiation message, Lee, et al. Expires December 22, 2003 [Page 12] Internet-Draft Mobile QoS Signaling June 2003 the FM sends Path_Req message to the neighboring ARs which the MN (as a recevier) may visit. (2) Path_Req message Path_Req message is used to request pre-reservation of resources on the new paths between new ARs and the FM during a certain time interval. If the MN is a receiver, for instance, the FM sends this message to neighboring ARs which the MN may visit afterreceiving FREE_Initiation message from the old AR. The FM's refresh timer is set to a value when the Path_Req message is transmitted. The refresh timer value in the Path_Req message for pre-reservation should be optimized such that pre-reserved resources can be released immediately after the MN's handoff except the resources on the location visited by the MN. For instance, the refresh timer value can be the actual handoff delay of the MN, Which is approximately 3 to 4(seconds if Mobile IPv6 is used as a mobility protocol. After the timeout, the FM retransmits the Path-Req message to neighboring ARs which the MN may visit unless it receives BU message. However, on receiving the BU or Resv message from the MN, the value of refresh timer is reset to the previous RSVP refresh timer value (e.g., 30s). (3) Reverse_Path_Teardown message Reverse_Path_Teardown message is used to delete the old path state and travels upstream when the MN is a sender. The FM transmits this message together with Resv Teardown message in response to the BU message in order to delete the old path state and transmits it to the old AR (in the reverse direction of Path Teardown message transmission). (4) Reverse_Resv_Teardown message Reverse_Path_Teardown message is used to delete the old path state and travels upstream when the MN is a sender. The FM transmits this message together with Resv Teardown message in response to the BU message in order to delete the old path state and transmits it to the old AR (in the reverse direction of Path Teardown message transmission). +---------+ ||FREE || ||Manager|| +-------+ +----+ |Crossover| |Core | |CN | | router |--------|router |-----| | +---------+ +-------+ +----+ $/ \$ Lee, et al. Expires December 22, 2003 [Page 13] Internet-Draft Mobile QoS Signaling June 2003 $/ \$ $/ \$ +-----+ +-----+ | OAR | | NAR | ||FAR|| ||FAR|| +-----+ +-----+ / / - - / / +----+ +----+ | MN | --> | MN | +----+ +----+ Figure 1. Network topology of FREE 4.1.4 Fast Resource Reservation We basically assume that both sender and receiver may be mobile. However, we mainly focus on the event where an MN undergoes only handoffs between ARs. 4.1.4.1 Upstream Data Transfer The MN can also act as a receiver which receives real-time traffic. After the initial end-to-end RSVP session between the MN and the CN is established, the FM commences to dividethe RSVP session into two subsessions: MN-to-FM and FM-to-CN. The FM is responsible for establishing the RSVP session and eliminating the old reservation path in an IP-based RAN while maintaining the fixed FM-to-FM subsession of the core network. +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | MN | | OAR | | NAR | | Other | | FM | | CN | | | | | | | | ARs | | | | | +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | | | | | | | | RSVP | Session | | | |<==========|===========|===========|===========|============>| | | | | | | | | FREE_Initation | | | |---------->|-----------|-----------|---------->| | | | | | |*Resource of | | | | | Path_Req |other ARs is | | | | ||<---------|released | | | | x|| Resv |after the | | | | ||--------->|timeout | | | | Path_Req | | | | | |<----------|-----------| | Lee, et al. Expires December 22, 2003 [Page 14] Internet-Draft Mobile QoS Signaling June 2003 | | | Resv | | | | | |-----------|---------->| | | | Binding | Update | | | |-----------|---------->|-----------|---------->|* Reset the | | | | | |timeout into | | | | | |the old | | | | | |refresh time | | | | | | | | |MN-to-FM FREE Session | | FM-to-CM | |<==========|===========|===========|==========>|<===========>| | | | | | | | | PathTear/Reverse_Resv_Tear | | | |<----------|-----------|-----------| | | | | | | | Figure 2. Pre-reservation and Fast release when MN is a receiver If the MN starts to move to a new AR as shown in Figure 2, the MN first determines the time when the handoff begins and transmits the FREE_Initiation message to the old AR. And then the old AR forwards the FREE_Initiation message to the FM in order to immediately inform the FM of the impending handoff event of the MN. The FM transmits the Path_Req message to neighboring ARs which the MN may visit to ask them to rapidly reserve the resources, and then the neighboring ARs pre-reserve resources by sending Resv message to the FM. As soon as the FM transmits the Path_Req message, the FM may set the refresh timer value to the optimized one for pre-reservation, as described above After the MN moves to a new AR, seamless QoS can be provided using pre-reservation. After handoff, the MN transmits a BU message to the FM via the new AR as shown in Figure 2. And then, the FM resets the refresh timer value to the previous RSVP refresh timer value after receiving the BU message. In this way the FM is able to keep the new RSVP (FREE) session adequately. Next, the FM accommodates the new MN-to-FM subsession and the fixed FM-to-CN (or FM-to-FM if the CN is mobile) subsession, and finally a complete end-to-end is established. On receiving the BU message, the FM starts to delete the old path and reservation states, as described in Section 4.1.5. If the MN does not move to any new AR during the timeout interval (e.g., if it returns to the old AR), the pre-reserved resources among the neighboring ARs and the FM are released by the expiration of the refresh timer. At the same time, the FM tries again to pre-reserve the required resources by re-transmitting the Path_Req message to the neighboring ARs which the MN may visit. This process is repeated until the FM receives any BU message. Lee, et al. Expires December 22, 2003 [Page 15] Internet-Draft Mobile QoS Signaling June 2003 +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | MN | | OAR | | NAR | | Other | | FM | | CN | | | | | | | | ARs | | | | | +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | | | | | | | | RSVP | Session | | | |<==========|===========|===========|===========|============>| | | | | | | | | FREE_Initation | | | |---------->|-----------|-----------|---------->| | | | | | |Path_Req mesg| | | | | Path_Req |of other ARs | | | | x|<----------|is deleted | | | | Path_Req | |after the | | Path_Req |<----------|-----------|timeout | |<----------|-----------| | | | | | | | | | | | Binding | Update | | | ||----------|---------->|-----------|---------->|* Reset the | || Resv | | |timeout into | ||----------|---------->| Resv |the old | | | |-----------|---------->|refresh time | | | | | | | | |MN-to-FM FREE Session | | FM-to-CM | |<==========|===========|===========|==========>|<===========>| | | | | | | | | PathTear/Reverse_Resv_Tear | | | |<----------|-----------|-----------| | | | | | | | Figure 3. Fast resource reservation and release when MN is a receiver If the ARs in the neighborhood of the old AR do not grab the required resources during the timeout interval after receiving the Path_Req message, they will just forward the Path_Req message to the arriving MN as shown in Figure 3. As soon as the MN moves to a new AR, it will receive the Path_Req message from the new AR. On receiving the message, the MN only sends the Resv message (and BU message) to the FM via the new AR and finally establishes a new RSVP session for the FM. Since the resource reservation isaccomplished by only transferring the Resv message after handoff, the re-establishment delay for resource reservation is reduced compared to the existing mechanisms. On receiving the BU message, the FM deletes the old path and reservation state, as described in Section 4.1.5. If the MN does not arrive at any new AR during the timeout interval, the Path_Req messages at the neighboring ARs are discarded if the refresh timer expires. Afterwards, the FM retries to pre-reserve the required resources by re-transmitting the Path_Req message with the same Lee, et al. Expires December 22, 2003 [Page 16] Internet-Draft Mobile QoS Signaling June 2003 timeout value to the neighboring ARs. 4.1.4.2 Downstream Data Transfer If the MN acts as a sender and transfers downstream data as shown in Figure 4, the procedure for processing the FREE_Initiation message is the same as the case of the upstream data transfer except that the information of the sender descriptor in the FREE_Initiation message is checked (see Section 4.1.8.4). The neighboring ARs use the sender descriptor of the FREE_Initiation message to initiate the Path_Req message in response to the FREE_Initiation message (from the FM). As soon as the FREE_Initiation message is received, the FM forwards this message to the neighboring ARs to inform of the MN's impending handoff event. And then, the neighboring ARs transfer the Path_Req message to the FM to pre-reserve the required resources after receiving the FREE_Initiation message (from the FM). Finally, the required resources are (pre-)reserved when the FM sends the Resv message to the neighboring ARs during the timeout interval. +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | MN | | OAR | | NAR | | Other | | FM | | CN | | | | | | | | ARs | | | | | +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | | | | | | | | RSVP | Session | | | |<==========|===========|===========|===========|============>| | | | | | | | | FREE_Initation | | | |---------->|-----------|-----------|---------->| | | | | FREE_Initation | | | | | |<----------| | | | |<----------|-----------| | | | | | |*Resource of | | | | | Path_Req |other ARs is | | | | ||--------->|released | | | | x||Resv |after the | | | | ||<---------|timeout | | | | Path_Req | | | | | |-----------|---------->| | | | | Resv | | | | | |<----------|-----------| | | | Binding | Update | | | |-----------|---------->|-----------|---------->|* Reset the | | | | | |timeout into | | | | | |the old | | | | | |refresh time | | | | | | | | |MN-to-FM FREE Session | | FM-to-CM | Lee, et al. Expires December 22, 2003 [Page 17] Internet-Draft Mobile QoS Signaling June 2003 |<==========|===========|===========|==========>|<===========>| | | | | | | | | PathTear/Reverse_Resv_Tear | | | |<----------|-----------|-----------| | | | | | | | Figure 4. Pre-reservation and Fast release when MN is a sender After the MN moves to a new AR, seamless QoS can be provided using pre-reservation. After handoff, the MN transmits a BU message to the FM via the new AR as shown in Figure 4.. As soon as the BU message arrives in, the FM resets the refresh timer to the existing RSVP refresh timer value. Next, the FM accommodates the new MN-to-FM session and the fixed FM-to-CN (or FM-to-FM if the CN is mobile) subsession, and manages the two subsessions like the downstream transfer described above. +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | MN | | OAR | | NAR | | Other | | FM | | CN | | | | | | | | ARs | | | | | +-----+ +-----+ +-----+ +-------+ +-----+ +-----+ | | | | | | | | RSVP | Session | | | |<==========|===========|===========|===========|============>| | | | | | | | | FREE_Initation | | | |---------->|-----------|-----------|---------->| | | | | FREE_Initation | | | | | |<----------| | | | |<----------|-----------| | | | | | |Path_Req mesg| | | | | Path_Req |of other ARs | | | | x|---------->|is deleted | | | | Path_Req | |after the | | | x|-----------|---------->|timeout | | | | | | | | | Binding Update | | | ||----------|---------->|-----------|---------->| | || Path | | | | ||----------|---------->| Path | | | | |-----------|---------->| | | | | Resv | | | Resv |<----------|----------|| | |<----------|-----------| | || | | | PathTear/Reverse_Resv_Tear || | | |<----------|-----------|----------|| | | | | | | | | |MN-to-FM FREE Session | | FM-to-CM | Lee, et al. Expires December 22, 2003 [Page 18] Internet-Draft Mobile QoS Signaling June 2003 |<==========|===========|===========|==========>|<===========>| | | | | | | Figure 5. Resource reservation and release when MN is a receiver If the MN does not arrive at any new AR until the refresh timer expires, the pre-reserved resources among the neighboring ARs and the FM are released by expiration of the refresh timer. At the same time, the FAR of the ARs reattempts to pre-reserve the required resources by re-transmitting the Path_Req message to the FM. This process is repeated until the FM receive any BU message (via any new AR). The MN transmits the Path message to the FM through the new AR if the required resources can not be pre-reserved. The FM then responds to the Path message by transferring the Resv message. At the same time, the FM also initiates the process of releasingthe old reservation path as described in Section 4.1.5.2. 4.1.5 Fast Resource Release The MN transmits the Path message to the FM through the new AR if the required resources can not be pre-reserved. The FM then responds to the Path message by transferring the Resv message. At the same time, the FM also initiates the process of releasingthe old reservation path as described in Section 4.1.5.2. 4.1.5.1 Upstream Data Transfer First, if the MN starts to move to a new AR as shown in Figure 2 and 3, the MN determines the starting point of handoff and begins to transmit the FREE_Initiation message to the old AR. And then, the old AR forwards the FREE_Initiation message to the FM to immediately request the release of unused RSVP path after handoff. Note that the transfer of the FREE_Initiation message is only to request the release of reserved resource, not to release. In this case, since origination of the FREE_Initiation message indicates the re-establishment of end-to-FM reservation session, not an end-to-end session, the FM can prepare the release messages, the Reverse_Path_Teardown and Resv Teardown messages, to remove the old path and reservation states before receiving the BU message After receiving the BU message, the FM then releases the unused resources by transmitting both Resv Teardown and Reverse_Path_Teardown messages to the old AR. Afterwards, other MNs can use the released resources. 4.1.5.2 Downstream Data Transfer Lee, et al. Expires December 22, 2003 [Page 19] Internet-Draft Mobile QoS Signaling June 2003 In the downstream data transfer, the procedure for processing the FREE_Initiation message is the same as the case of the upstream data transfer. To release the old path and reservation states as shown in Figure 4 and 5, the FM transmits the Path Teardown message and Reverse_Resv_Teardown message to the old AR in response to the BU message if the FM pre-reserves the request resources. If the FM does not pre-reserve the resources, the procedure for resource release is initiated after the FM receives the Path message from the MN (via a new AR). 4.1.6 The Session of the FREE The session of the FREE is divided into subsessions according to the mobility characteristics of end terminals If both end terminals are mobile, the FM commences to divide the RSVP session into three subsessions after the initial end-to-end RSVP session is established between the MN and the CN: MN-to-FM, FM-to-FM, and FM-to-CN. The FM is responsible for converting the LCoA into the RCoA to associate the MN-to-FM (or the FM-to-CN) session of an IP-based RAN with the fixed FM-to-FM session of the core network [2]. In this way, an end-to-end session is established with the conversion between RCoA and LCoA. 4.1.7 The location of FREE module The FM can be placed at any intermediate router (as an internal module) in an IP-based RAN. To optimize the proposed mechanism, it may be necessary that the FM is installed at a crossover router which connects the old AR and the new AR. 4.1.8 FREE Message Formats Here we define four additional messages to support the proposed mechanism. These messages basically conform to the existing RSVP message formats, except the Msg Tpye value of common header [1]. The added value of Msg Type can be set using the Reserved field of common header. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Flags | Msg Type | RSVP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send_TTL | (Reserved) | RSVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. Common Header Lee, et al. Expires December 22, 2003 [Page 20] Internet-Draft Mobile QoS Signaling June 2003 4.1.8.1 Path_Req message Each router in IP-based RAN periodically sends a Path_Req message for each data flow it originates. A Path_Req message travels from an FM to AR(s) along the same path(s) used by the data packets, and vice versa. This message is used to pre-reserve resources on the new paths during the timeout interval, and the Msg Type value of common header is 8. Except the value of Msg Type, it conforms to the format of the Path message of the existing RSVP [1]. 4.1.8.2 Reverse_Path_Teardown message On receiving a Reverse_Path_Teardown message, the path state of the old session is deleted. The old matching state must have a match of the SESSION, SENDER_TEMPLATE, and RSVP HOP objects. If there is no matching path state, a Reverse_Path_Teardown message should be discarded and not be forwarded. The messages are explicitly generated by the FM , and they travel upstream from the FM to the old AR. Therefore, its IP destination address must be the address of the old AR, and its IP source address must be the address of the FM from the path state being torn down. The Msg value of common header is 9, and it conforms to the format of the Path Teardown message of the existing RSVP except having the RSVP HOP object in the reverse direction of Path Teardown message transmission. 4.1.8.3 Reverse_Resv_Teardown message On receiving a Reverse_Resv_Teardown message matching reservation state of the old session is deleted. The old matching reservation state must have a match of the SESSION, STYLE, FILTER_SPEC, and PHOP objects. If there is no matching reservation state, a Reverse_Resv_Teardown message should be discarded. Reverse_Resv_Teardown messages are initiated explicitly by the FM, and they travel upstream from the FM to the old AR. Therefore, its IP destination address must be the address of the old AR, and its IP source address must be the address of the FM from the path state being torn down. The Msg value of common header is 10, and it conforms the format of the Resv Teardown message of the existing RSVP except having PHOP object in the reverse direction of Resv Teardown message transmission. 4.1.8.4 FREE_Initiation message A FREE_Initiation messages are sent to inform the starting point of the handoff. It contains a SENDER_TEMPLATE object which defines the Lee, et al. Expires December 22, 2003 [Page 21] Internet-Draft Mobile QoS Signaling June 2003 format of the data packets and a SENDER_TSPEC object specifying the traffic characteristics of the flow. A FREE_Initiation message travels from an MN to the FM(s) along the old path(s) used by the data packets. If the MN as a sender performs downstream data transfer, the FREE_Initiation message is transferred to request the transmission of the Path_Req message to the neighboring ARs (from the FM). In this case, FAR duplicates the SENDER_TEMPLATE object and a SENDER_TSPEC object of the FREE_Initiation message to generate the Path_Req message. The format of a FREE_Initiation message is as follows: (FREE_Initiaion Message) ::= (Common Header) [ (INTEGRITY) ] (SESSION) (MOBILITY_SPEC) (TIME_VALUES) [ (POLICY_DATA) ... ] [ (sender descriptor) ] (sender descriptor) ::= (SENDER_TEMPLATE)(SENDER_TSPEC)[(ADSPEC)] The Msg value of common header is 11, and the Mobility_Spec contains the information of ARs in the neighborhood of current AR that the MN stays. Lee, et al. Expires December 22, 2003 [Page 22] Internet-Draft Mobile QoS Signaling June 2003 5. Security Considerations The resource pre-reservation triggered by a handoff initiation message MUST be guarded against security attacks. Such attacks could be made by malicious nodes that spoof the QoS signaling to make it appear to a mobility proxy agent that the MN has undergone handoff. Such an attack could disrupt the QoS offered to MN's ongoing sessions as the intermediate nodes may then tear down the QoS along some segments of the current true packet paths among MN, MPA, and CN. Furthermore, network resources may be wasted or used in an unauthorized manner by the malicious nodes that spoof MN's handoff. To prevent this, QoS mechanism MUST provide means for intermeidate nodes to verify the authenticity of handoff-induced resource pre-reservation. Lee, et al. Expires December 22, 2003 [Page 23] Internet-Draft Mobile QoS Signaling June 2003 6. Conclusion The IETF NSIS WG is currently designing general signaling protocols based on the signaling requirements and framework. It is desirable to provide necessary signaling procedures for resource reservations in an IP-based RAN. In this draft, we described general QoS signaling procedures in an IP-based RAN, which are based on the analysis of the existing QoS signaling solutions in mobile wireless networks. We also presented a specific QoS signaling scheme based on the proposed signaling procedures. Lee, et al. Expires December 22, 2003 [Page 24] Internet-Draft Mobile QoS Signaling June 2003 Normative References [1] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [2] Paskalis, S., "RSVP Mobility Proxy", draft-paskalis-rsvpmp-00 (work in progress), December 2001. [3] Chaskar, H., "Requirements of a QoS Solution for Mobile IP", draft-ietf-nsis-qos-requirements-01 (work in progress), June 2003. [4] Talukdar, A., Badrinath, B., and Acharya, A., "MRSVP: A Resource Reservation Protocol for an Integrated Services Packet Network with Mobile Hosts", Technical report DCS-TR-337, Rutgers University, 1997. [5] W. Chen and L. Huang, "RSVP Mobility Support: A Signaling Protocol for Integrated Services Internet with Mobile Hosts", Proc. IEEE Conference on Computer Communications, Vol. 3, pp. 1283-1292, 2000. [6] I. Mahadevan and K. M. Sivalingam, "Architecture and Experimental Results for Quality of Service in Mobile Networks using RSVP and CBQí˜, ACM Wireless Networks 6, pp. 221-234, July 2000. [7] D. Partain, G. Karagiannis, P. Wallentin, L. Westberg, "Resource Reservation Issues in Cellular Radio Access Networks", draft-westberg-rmd-cellular-issues-01.txt (work in progress), June 2002. Lee, et al. Expires December 22, 2003 [Page 25] Internet-Draft Mobile QoS Signaling June 2003 Authors' Addresses Sung Hyuck Lee SAMSUNG Advanced Institute of Technology i-Networking Laboratory San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9585 EMail: starsu.lee@samsung.com Jongho Bang SAMSUNG Advanced Institute of Technology i-Networking Laboratory San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9585 EMail: jh0278.bang@samsung.com Seong-Ho Jeong Hankuk University of FS 89 Wangsan Mohyun Yongin-si, Gyeonggi-do 449-791 KOREA Phone: +82 31 330 4642 EMail: shjeong@hufs.ac.kr Lee, et al. Expires December 22, 2003 [Page 26] Internet-Draft Mobile QoS Signaling June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Lee, et al. Expires December 22, 2003 [Page 27] Internet-Draft Mobile QoS Signaling June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Lee, et al. Expires December 22, 2003 [Page 28]