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]