Internet DRAFT - draft-ehjoo-fr-rsvp
draft-ehjoo-fr-rsvp
IETF Mobile IP Working Group Eunhee Joo
INTERNET-DRAFT Dr Robert Edwards
Expires: May 2002 University of Sheffield
Chern Nam Yap
Seamoby Forum
2 November 2001
A Fast Reacting Mechanism for Terminal Mobility
with Extended-RSVP
<draft-ehjoo-fr-rsvp-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 made obsolete 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.
Abstract
Numerous studies have been done to improve RSVP performance.
However, most of this research concentrates on fixed hosts.
As mobility of hosts is having a significant impact on the
Quality of Services, it is necessary to develop a new mechanism
having the capabilities to support terminal mobility with RSVP.
This document suggests a fast reacting mechanism for terminal
mobility with Extended-RSVP. Fast reaction RSVP can be achieved
using PathResv messages, which are novel. The process begins with
a minimum reservation request but also retains old reservation.
Higher possibility of acceptance from intermediate routers is
gained by applying the minimum request first. For existing
reservation, it is suggested that RSVP could use other
information to identify a flow: for example, effective source
address and effective destination address. The IP option field
can also be used for this purpose.
Eunhee Joo et al. Expires 2 May 2002 [Page i]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
Table of Contents
Status of this Memo
Abstract
1. Introduction
2. The Requirements to Support End-to-End QoS for Mobile Hosts
2.1 QoS Classification regarding Mobility
2.2 Mobility Consideration
2.3 QoS Requirements
3. Mobile-aware Resource Reservation Protocol
3.1 Interoperability Problems of Mobile IP and RSVP
3.1.1 Inefficiencies occurred by RSVP
3.1.2 Inefficiencies occurred by Mobile IP
3.1.3 Other protocols providing IP Mobility
3.1.4 SIP Mobility Support
3.2 A Flexible Framework
3.3 A Fast Reacting Mechanism for Terminal Mobility with
Extended-RSVP
3.3.1 Additional Message type: PathResv
3.3.2 Basic Idea
3.3.3 Operation Procedures
3.3.3.1 In the Unicast Session
3.3.3.2 In the Multicast Session
3.3.4 Comparison with RSVP
3.4 Implementation Consideration
3.4.1 Implementation with using IP option field
3.4.1.1 IPv4 Option Field Layout
3.4.1.2 IPv6 Option Field Layout
3.4.2 Implementation with using RSVP Adaptation Layer
3.4.3 Router Alert Option
3.4.4 Requirements for All RSVP Hosts and Routers
3.4.5 PathResv Messages
4. IANA Consideration
5. Conclusions
References
Eunhee Joo et al. Expires 2 May 2002 [Page ii]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
1. Introduction
RSVP (Resource reSerVation Protocol) was designed to play a role
as a resource reservation protocol in the Integrated Services Network.
RSVP has many excellent features such as soft-state maintaining and
receiver-oriented nature and etc. However, RSVP cannot support
mobility independent reservations as originally designed.
RSVP assumes that the users are always attached to the same point
in the network. Therefore if terminal mobility is introduced to RSVP,
some additional issues MUST be considered. For example,
when RSVP-capable node moves to different subnet while in service,
RSVP gets routing reply from Mobile IP. Mobile IP is the most popular
protocol to provide terminal mobility, however, it is not QoS-aware.
One could think that the combination of two technologies brings us
an appropriate method to satisfy both requirements. We address the
potential problems of interoperation of RSVP and Mobile IP in a later
section.
Whilst we have tried to design a bigger frame of a Mobile-aware
Resource Reservation Protocol, as a first step, a fast reacting
mechanism for terminal mobility is proposed with Extended-RSVP.
A RSVP session is established in a faster and a more efficient way
with using newly defined PathResv message and with the strategy
that request with minimum QoS first and the mechanism to be able to
retain old reservation when a host is moving.
The organization of the rest of this document is as follows.
Firstly, the requirements to support end-to-end QoS for mobile
hosts are addressed with the consideration of mobility in section 2.
Section 3 describes a mobile-aware resource reservation protocol.
This section includes a discussion of the interoperability problems
of Mobile IP and RSVP, our future framework, a novel fast reacting
mechanism for terminal mobility with Extended-RSVP. Implementation
related issues are also in section 3. IANA consideration is handled
in section 4, and finally we provide conclusions in section 5.
2. The Requirements to support End-to-End QoS for mobile hosts
2.1 QoS Classification regarding Mobility
Wireless QoS Wired QoS
<--------------------------------><-------------------------------->
+-------------+------------+------------+------------+-------------+
| | | | | |
| No mobility | Mobility | Mobility | Plug-in/ | No mobility |
| in Wireless | Within | Between | Plug-out | in Wired |
| | Subnet | Subnets | mobility | |
| | | | | |
+-------------+------------+------------+------------+-------------+
<-------------------------------------->
QoS Mobility
Figure [1]: QoS Classification regarding Mobility
Eunhee Joo et al. Expires 2 May 2002 [Page 1]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
We here classified QoS related research area into five categories
according to mobility. Note that the classification that we show
does not include the movement of a user in the plain or train that is
connected through wireless devices. And also there is no consideration
of RF interface. Therefore we assume that handover is unambiguous.
- No mobility in Wireless: Note that "wireless" does not mean
"mobile". Desktop computers could be connected with wireless network
devices. For example, a wireless network might be installed
in an old building where it is difficult to install a wired network
in that building. Or, people prefer a wireless network due to
reasonable costs in some situations. In this case, QoS mechanism
MAY have to deal with the nature of wireless network such as
high packet loss rate, high packet delay and packet delay variation,
but no need to worry about mobility portion.
- Mobility Within Subnet: In the case where mobile hosts moves
around either within a cell or between cells, but within the same
subnet, there is no change of IP address by movement of the host.
Users might move to different technology domain such as from 802.11
to wireless ATM. Further, there might not be enough bandwidth
available in the new cell when handoff occurs. Wireless network
QoS technologies SHOULD cover this kind of affect by movement
of the host in addition to the nature of a wireless network.
However, the movement of this category does not affect QoS
in the wired network. This is often called Layer 2 QoS as a result.
- Mobility Between Subnets: In the case where mobile hosts moves
between subnets, there is a change of IP addresses during the
lifetime of the connection. In order to support QoS with
Mobility Between Subnets, we need to consider not just Layer 2 QoS
but also Layer 3+ QoS mechanism. For example, in the case where
RSVP is used to provide QoS, having different IP address
could cause making resource reservation along the new end-to-end
path whenever the host moves. Of course, there still needs QoS
support from Layer 2.
- Plug-in/Plug-out Mobility: For example, assume that a user
is in the videoconferencing with a desktop computer. The user
moves to another office during the conference for some reasons,
but the user wants to continue to join the conference in another
room. In the sight of this kind of scenario, the application
in the computer in another room has to handle this connection
request. QoS mechanisms might be required depending on the location
where the user moves. If the user moves into a different subnet,
we need to consider Layer 3+ QoS, but Wireless QoS is not involved
in this category of movement. The old connection and resources
reserved in the previous place where the mobile user was
would be disconnected and released after timeout. However,
when the user moves into a different subnet, they might need
an additional mechanism in order to provide mobility transparent
services to the hosts, or the plug-in host might be treated
as a new host.
- No Mobility in Wired: Conventional QoS in wired network where
Eunhee Joo et al. Expires 2 May 2002 [Page 2]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
there is no movement, consequently there is no IP address changes
SHOULD be applied.
As we addressed above, QoS Mobility is overlapping area between
wireless and wired QoS. In the light of this knowledge, to enable
end-to-end QoS requires the cooperation of all network layers from
top-to-bottom (from layer 2 to layer 3+), as well as every network
element from end-to-end.
2.2 Mobility Consideration
Providing QoS for a mobile user is a big challenge.
The knowledge of a user's movement pattern would be a great help
to accomplish this task. We briefly classify mobility pattern
into 4 types to understand the relationship of movement and QoS.
- Walking around: non-directional, not speedy
- Driving a car: directional/non-directional, speedy
- In a train/plane: directional, speedy, maybe use wired network
between a mobile user and a train/plane, train/plane communicates
through wireless network (It is assumed that one subnet covers
a whole plane/train.)
- Plug-out/Plug-in to another computer (in this case, terminal
itself does not move)
In the case where driving speed is faster than the speed of resource
reservation, it is wasteful to perform resource reservation mechanism.
While intermediate routers in path are trying to make reservations,
if the mobile node already moved to another place, they MAY have to
delete the resources reserved if necessary. Therefore when neighbouring
cells reserve channels in advance, they SHOULD consider the speed
of the vehicle. Just one cell ahead MAY not be enough. This problem
becomes even more challenging as making reservation in advance scheme
is performed in Layer 3. For example, in the case where we are using
RSVP for Layer 3 resource reservation, it is required to compute
how ahead we SHOULD reserve resources with the consideration of
propagation and processing delay.
2.3 QoS Requirements
In order to provide end-to-end QoS to a mobile host, it is necessary
to identify concrete QoS requirements.
1) Lightweight signalling protocol
Lightweight signalling protocol is needed for faster connection
set-up especially in mobile environment. And it SHOULD be independent
of network service model.
2) Flexible QoS specification/Adaptive application
Specifications are often inexact as resource usage and flow
characteristics are not generally completely defined in advance.
It is suggested that due to the nature of mobile communications
it is not practical to guarantee QoS levels. Instead, an adaptive
approach is needed, where QoS management specifies a range of
acceptable results.
Eunhee Joo et al. Expires 2 May 2002 [Page 3]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
3) Efficient resource reservation in advance
To support mobility independent QoS guarantees, advance reservation
is needed. It SHOULD be done in an efficient way in terms of
resource utilization, and in accurate ways in terms of mobility
prediction.
3. Mobile-aware Resource Reservation Protocol
3.1 Interoperability Problems of Mobile IP and RSVP
Currently we have RSVP to provide QoS and Mobile IP to support
terminal mobility as actual protocols. However, just applying
a combination of these protocols cannot achieve our final goal,
end-to-end QoS for mobile users. We address the predictable
inefficiencies when RSVP with Mobile IP is applied for mobile
hosts in this section.
3.1.1 Inefficiencies occurred by RSVP
1) Long Session Establishment Delay
RSVP needs at least one round-trip time between a sender and
a receiver to establish a session even every router accepts
a reservation request. If any of the routers rejects reservation
request, longer delay would be taken. Such latency MAY not be
very problematic when session is initiated (when the service begins),
but could cause unacceptable service disruption in the middle of
an active session.
2) RSVP Flow Identifier
Since RSVP generally uses the 5-tuple (Source Address,
Destination Address, IP Protocol Id, Source Port, Destination Port)
to identify a specific flow, the change of any of elements in 5-tuple
makes the flow become a different one. The old reservation cannot
be retained when the source or the destination moves from one subnet
to another due to a different source or destination address.
Currently there is no mechanism that RSVP can distinguish between
"really new session" and "actually no new session".
3) No Mechanism Supporting Mobility
Conventional RSVP reserves only the resources along with the data
path for the reason that the receiver's attached point on the network
will not change during communication with senders. In order to acquire
mobility independent service guarantees, resource reservation
in advance is required. However, conventional RSVP is not able to
handle resource reservation in advance.
3.1.2 Inefficiencies occurred by Mobile IP
1) Problems of Tunnelling
Tunnelling causes outer header overheads. This could cause packet
fragmentation and low network utilization as a result. This could
affect QoS. In the case where Mobile IP and original plain RSVP is
used, packets are always served in a best-effort way inside of the
tunnel. This situation leads to large latency by non-optimal routes
Eunhee Joo et al. Expires 2 May 2002 [Page 4]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
and non-guaranteed QoS in tunnels. And more important as regards to
RSVP is that tunnelling makes the RSVP session become
different due to outer packet header.
2) Triangular Routing
Even when RSVP over tunnels is possible, there are still several
problems to be solved.
First, every packet sent to the mobile host has to go through
a home agent in Mobile IP, non-optimal triangular routing problem
has been resulted in. This situation increases not only
end-to-end delay but it also generates wasted bandwidth
in non-optimal paths that could be used for other connections.
Second, resource reservation requests over the tunnel could
possibly fail. The links or routers in the tunnel MAY not support
due to the lack of available bandwidth or for other reasons.
3) When the mobile node moves from the foreign network
to another foreign network
There is no mechanism for the packets in flight from home agent
to old foreign agent to be delivered to the mobile node.
They are likely to be lost and needed to retransmit later.
These lost packets could cause QoS degradation.
3.1.3 Other protocols providing IP mobility
As support for mobility in the Internet has been topical, extended
or modified versions of Mobile IP have been presented that
claim enhanced performance. We describe these protocols briefly
how these differ from Mobile IP and address potential
problems of these protocols when used with RSVP.
1) Mobile-IPv4 Route Optimisation
Even Route Optimisation provides an optimal route and foreign agent
smooth handoff, there are still tunnelling overheads in each end nodes
and the network link. Unless IP mobility protocol uses tunnelling,
there would be inefficiencies when it is used with RSVP due to the way
identifies a flow. And even it is possible to use an optimal route
between a correspondent node and a mobile node, it takes time
to set-up binding cache element in the correspondent nodes
because all Binding Updates go home agent first. This kind of set-up
delay could be very critical in terms of QoS.
2) Mobility Support in IPv6
Support for Route Optimisation is built in as a fundamental part of
the IPv6. As mentioned above, it eliminates the problem of
triangle routing present in the base Mobile IPv4 protocol.
Additionally, most packets sent to a mobile node in Mobile IPv6
are sent using an IPv6 Routing Header rather than IP-IP encapsulation,
whereas Mobile IPv4 MUST use IP-IP encapsulation for all packets.
The use of Routing Header creates less overheads.
However, the packets in flights are delivered by the encapsulation.
In the context of RSVP, the use of Routing Header still cause
The same problems as IP-IP encapsulation causes since the destination
of IP packet is the care-of address of a mobile node, rather than
the original destination address of a mobile node.
Eunhee Joo et al. Expires 2 May 2002 [Page 5]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
3) Mobile-IP with Hierarchical Model
While Mobile-IP has been trying to solve the macro mobility management
problem, which is a more general mobility problem, in the Internet,
micro mobility protocol is for a mobile node when it moves in a limited
area such as a campus or a company. This method allows the home agent
to remain unaware of the exact care-of address in use by the mobile
node, as long as the mobile node stays within the same hierarchy.
RSVP can keep the resources reserved for the session before moving
between the correspondent node and the local foreign agent,
and make a reservation for the new path between the local foreign
agent and the mobile node.
3.2 A Flexible Framework
We investigated potential problems of interoperability of Mobile IP
and RSVP in the above section. Such problems arise because RSVP
signalling for QoS was designed without consideration of mobility
and Mobile IP does not support QoS with mobility. For example,
the way Mobile IP uses tunnelling to support IP mobility does not
work well with RSVP as we investigated above. Therefore a new
approach is needed to support mobility independent QoS
rather than applying two different protocols having different
design purposes. We address a flexible framework for providing QoS
in the mobile Internet. As a first step, we tried to figure out the
mechanism which can achieve better performance with existing protocols
without significant modifications of current protocols. The new
suggested mechanism will be described in the next section.
Applications SHOULD be able to choose an appropriate routing and
QoS strategy among possible mechanisms. There are several protocols
available that provide IP-level mobility as mentioned above,
and there are various models deployed for providing QoS in different
parts of the Internet such as IntServ, DiffServ or MPLS network.
As a mobile user could move from one domain to another,
it is not practical to assume for a mobile node to move always
within the same domains.
We can have better results of QoS with mobility in co-operation with
these routing protocols since QoSs could be significantly affected
by the protocol used. For example, we would have a better solution
by using RSVP and Mobile IP hierarchical model instead of basic
Mobile IP, if the mobile node moves within the network having
Mobile IP hierarchical model and if QoS mechanism knows this
situation. If an application is mission-critical,
guaranteeing 100% QoS is much more important than considering
efficient resource utilization. Then we could choose the protocol
that provides resource reservation mechanism in advance.
The problem is that "Is there a mechanism to know which IP mobility
protocol is available in the subnet where MN (mobile node) is
currently visiting?". The Quality of Service mechanism or Security
mechanism developed to operate with a specific IP mobility protocol
cannot work with others having different IP mobility protocols.
In order to solve this problem, the senders and the receivers SHOULD
consult a special-purpose server that provides this environmental
Eunhee Joo et al. Expires 2 May 2002 [Page 6]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
information by queries. We call this server
an "Information Broker (IB)". The router in the subnet could do
this job since the Information Broker can work well within the
same subnet. When the senders and the receivers construct Path or
Resv messages, consult the Information Broker first to get the
information needed. In addition, IB provides mobility specifications
for mobile applications according to the link status and some
direction or speed information given by mobile applications.
Mobility independent QoS can be provided with the incorporation of a
signalling protocol such as FR-RSVP (Fast Reacting Mechanism to
Terminal Mobility with Extended-RSVP) and the Information Broker.
This is because mobility prediction is executed concurrently with
actual movement of the hosts, and lightweight signalling protocol
which makes a reservation in a flexible and simple way to adapt
well in varying mobile situations.
3.3 A Fast Reacting Mechanism to Terminal Mobility
with Extended-RSVP
This section describes a new approach to make resource reservation
using RSVP for providing terminal mobility. We define a new message
type, PathResv, in addition to two primary RSVP messages (Path, Resv)
for our mechanism.
3.3.1 Additional Message type: PathResv
A PathResv message is initiated by a sender host and travels
downstream. Unlike a Path message it creates path state and a Resv
message creates reservation state in each node, a PathResv message
creates path state and also reservation state in each node.
It contains SENDER_TEMPLATE object defining the format of the data
packets and a SENDER_TSPEC object, specifying the traffic
characteristics of the flow. And it also contains FLOW_SPEC object
to create reservation state in the intermediate nodes. Note that
PathResv message does not carry FILTER_SPEC object since
SENDER_TEMPLATE have exactly the same expressive power and
format as FILTER_SPEC. PathResv Messages are used temporarily.
Once the sender receives a confirm message, it stops refreshing
PathResv. And every operation will continue the same as the
original RSVP operation.
3.3.2 Basic Idea
There are three basic ideas in this suggested mechanism.
The first one is that "Let's use known useful information
such as receiver's QoS requirement when establish a session
after moving". We let the sender initiate PathResv messages
with known parameter information from the previous session.
The second one is "Begin with minimum reservation request first"
with minimum and maximum QoS requirement and the unit for
increasing requirement each refreshing when the previous request
is successful. The third one is "Keep the old reservation
in the routers for the same flow having different flow
identification".
Eunhee Joo et al. Expires 2 May 2002 [Page 7]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
1) The use of a combined message: PathResv
Once a RSVP connection has been established between a sender and
a receiver, it is reasonable to presume that both end hosts know
about traffic characteristics or requirements given by exchanging
Path and Resv messages. It is unnecessary to establish a RSVP session
in the same way as normal RSVP set-up procedures, i.e. it is possible
to create path state and reservation state in the routers with
one message (PathResv). The crucial point is which end host SHOULD
initiate PathResv messages. We decide to let a sender do this job.
These are the reasons we chose a sender :
- The sender already knows the receiver's requirements from
the previous RESV messages.
- It is the sender that is reported mobile node's new location.
If a receiver initiates a PathResv message after moving,
there is no guarantee that a sender has binding information of
receiver's new address. When the sender receives binding
information, there is an optimal route they can use.
Therefore it is the fastest way to let the sender initiate
a PathResv message just after it knows the receiver's new address.
When the receiver host get the PathResv message, it sends
a confirm message back to the sender. Then the sender stops
refreshing PathResv messages.
- The route chosen from a receiver to a sender may not be the same
as the route from a sender to a receiver.
The main reason for RSVP having Path messages to build path states
in the routers and letting Resv messages make reservations is
to provide receiver heterogeneity. This suggested mechanism keeps
RSVP's this feature to support various receiver's requirements.
Additionally it provides an efficient way to setup a new RSVP session
after moving. It would be much faster to omit (skip) one processing
phase and combine two processing steps into one.
2) We begin with Minimum Reservation Request
When the sender initiates a PathResv message, the message is sent with
a minimum reservation request. Such minimum requests result in a higher
probability of acceptance from intermediate routers. Subsequently,
if acceptance is achieved, the sender gradually increases requests of
resources. The RSVP keeps an existing reservation in place
when making an admission control decision for a replacement reservation.
If the new reservation fails, a ResvErr message is sent back
but the original reservation is left in place.
We use this mechanism in mobile Internet environment in order to have
faster reaction from RSVP. The rejection from the routers causes
delay to establish the session. Therefore, the less the reservation
requests are rejected, the more the data transmitted can enjoy
pipe-liked link, and the better service they can provide.
3) Retain the Old Reservation
Even though the path between the correspondent node and the
mobile node is different as the mobile node moves, most intermediate
routers between CN and MN are still common . Being able to keep
Eunhee Joo et al. Expires 2 May 2002 [Page 8]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
previous reservation is important not just because of time
but also resource availability.
For example, before the resources that were reserved for a previous
flow are released, the reservation for another flows are requested,
and if there is not sufficient bandwidth available, the request
after moving would be rejected. As a result, this would cause
QoS degradation. In common routers between an old path and a new path,
there is no risk to be rejected due to lack of available bandwidth.
There has been some research to combine RSVP and Mobile IP regional
registration to better support for a mobile node in region [5].
This research has limitation to have to use a specific IP mobility
protocol in a restricted environment. However, our mechanism can
better support in more general mobility environments.
We describe three possible choices for retaining resources:
1. Use IP option field for carrying effective addresses.
Since options are not copied from the inner IP header in most
encapsulation cases [7], add IP option into an IP outer
header. The contents of this option field are effective
source and destination address. More detail mechanism
is described in section 3.4. RSVP control packets are
encapsulated with Router Alert Option and Effective Address
Option. Data packets are encapsulated with just Effective
Address Option. This method has processing and bandwidth
overhead due to additional Effective Address IP option.
2. Manage flow state information in routers.
Routers manage some binding information between the IP
addresses before moving and after moving for flows
additionally. When a router receives RSVP control messages,
the router refers its binding information to decide whether
to create new state for it or just refresh it.
The encapsulation point adds Router Alert Option
in the outer IP header. By doing this, all intermediate
RSVP-capable routers in the tunnel would take a look
encapsulated RSVP messages more closely. Even the packets
including RSVP messages are arrived with tunnel endpoint
IP addresses, intermediate routers process them by the binding
information. This method requires routers to manage binding
information, therefore causes processing overhead
in the routers.
3. Use IP addresses of inner IP headers as a flow identifier.
To avoid bandwidth wasted by additional Effective Address
option, it would be another solution to let the routers
use IP address field of inner IP header as a flow identifier.
When a router receives a packet, it knows whether this packet
is encapsulated or not by protocol id of outer IP header.
If the packet is encapsulated, the router checks inner the
IP header to distinguish it. With this method, no more
additional bandwidth is required even the packets are still
needed to be encapsulated with Router Alert Option in outer
header. However, this solution requires modifications at
Eunhee Joo et al. Expires 2 May 2002 [Page 9]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
all routers and imposes further processing overheads
on the packet distinguishing process.
3.3.3 Operation Procedures
It is assumed that we use Mobile IPv4 route optimization/Mobile-IPv6
as a IP mobility protocol to avoid triangular routing.
3.3.3.1 In the Unicast Session
1) Receiver is moving
subnet1
+------+ Path +-------+ Path +--------+ Path +--------+
| |----->| |----->| |----->| |
| CN | |Router1| |Router2 | | MN |
| |<-----| |<-----| |<-----| |
| | Resv | | Resv +--------+ Resv +--------+
| | | | |
| |=====>+-------+\\ | moved
+------+ PathResv \\ V
\\ +--------+ PathResv +--------+
pathResv\\ | |=========>| |
\\|Router3 | | MN |
\| | | |
+--------+ +--------+
subnet2
CN: Correspondent Node
MN: Mobile Node
Figure [2]: Sample Operation Procedures of Suggested Mechanism
when Receiver is moving
The following sequence illustrates the process by which a sender and
a receiver establish RSVP session when the receiver is moving
from one subnet to another.
- A sender host sends Path messges to a receiver along through
Router1, Router2(Same as RSVP).
- A receiver sends Resv messages to the sender (Same as RSVP).
- A receiver in subnet1 moves to subnet2.
- The receiver informs the sender of its new location by IP mobility
protocol. (e.g. Mobile IP)
- The sender creates PathResv message using the information from
previous Resv messages exchanged with minimum QoS request.
- The sender transmits PathResv messages to the receiver's new
location along through Router1, Router3.
- When Router1, which is common router between an old path and
a new path, receives a PathResv message, Router1 checks
its effective field and will find out there is a matching state.
So it just refreshes the path and reservation state and
forwards it.
Eunhee Joo et al. Expires 2 May 2002 [Page 10]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
- When Router3, which is a new router, receives a PathResv message,
it creates path and reservation state and forwards it.
- When the PathResv arrives in the receiver's side, the receiver
sends a confirm message to the sender.
- Once the sender transmits PathResv, the sender refreshes it
until receiving ResvConf. After the sender receives ResvConf,
the sender stops refreshing PathResv.
2) Sender is moving
When a sender is moving, basically same operation procedures
are applied.
3.3.3.2 In the Multicast Session
In the multicast session, when a receiver is mobile we can consider
terminal mobility as joining a new member and leaving an old member.
However when the mobile user moved to a different network which has
no member, it SHOULD make resource reservation as it joined
the multicast group first. It causes some delay to complete
the reservation using RSVP. Furthermore, in the case where the
sender moves, the flow id becomes different due to different sender's
IP address. New resource reservation SHOULD be performed along
the new path between the new sender's location and receivers.
If we cannot retain the resource for previous flow id, it MAY not be
possible to reserve resources in the same intermediate routers due to
lack of available resource.
3.3.4 Comparison with RSVP
In a case where there is no PathErr and ResvErr, the delay to
establish RSVP session is essentially 1 round trip time between
a sender and a receiver. This is because since RSVP path messages
are sent to the receiver and then the receiver sends RSVP resv
messages to the sender.
With FR-RSVP, the set-up delay is 1 PathResv delay since the
PathResv messages make Path and reservation state.
Note that the processing time of PathResv messages is not exactly
half of the 1 Round Trip time since a PathResv message does more jobs
than each Path and Resv message does. However PathResv could save
at least propagation delay of one transmission direction.
In the case where one of the intermediate routers rejects
the reservation request, the time when the receiver is notified
the error is 1 Path Delay and Return time from the router reject
to the receiver with RSVP. However, with FR-RSVP, return time
is needed for the receiver to know the error.
In order to send data with reservation guaranteed, the sender needs
to wait for 1 Round Trip time with RSVP no matter where there is any
router reject the request. However with FR-RSVP, the sender can send
data with guarantee just after sending PathResv messages if there
is enough resources. If any router rejects the reservation request,
the data sent are served by Best Effort mode.
Eunhee Joo et al. Expires 2 May 2002 [Page 11]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
3.4 Implementation Consideration
In this section, we describe first two methods addressed in 3.3.2
which use the IP option field and RSVP adaptation layer
in detail. We also define the PathResv message format.
3.4.1 Implementation with using IP option field
(Effective Address Option)
Our mechanism can be implemented both in IPv4 and IPv6.
In this section, the layout of option field is shown in both cases.
3.4.1.1 IPv4 Option Field Layout
There MAY be a number of options at the end of the header in IPv4.
The presence or absence of options MAY be determined by examining
the header length field. When there are no options, the header is
20 bytes long. If there are no other options except Effective
Address Option, the header SHOULD be 32 bytes.
0 8 16 17 31
+------------+-------------+---+-----------------------------+
| Type | Length | M | Reserved |
+------------+-------------+---+-----------------------------+
| Effective Source Address |
+------------------------------------------------------------+
| Effective Destination Address |
+------------------------------------------------------------+
Type
8 bits
copied flag (1 bit) : 1 (all fragments must carry the option)
option class (2 bits) : 0 (control)
option number (5 bits) : decimal number
Length
8 bits
12 (The length of this entire extension in bytes)
M bit
0 : Both source and destination addresses are same as
the effective addresses (No mobility happens, When M bit
is 0, following Effective Source and Destination Address
fields could be omitted)
1 : Either source or destination address is different from the
effective address (Mobility happened)
Reserved
15 bits
Effective Source Address
32 bits
Effective Destination Address
32 bits
Eunhee Joo et al. Expires 2 May 2002 [Page 12]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
3.4.1.2 IPv6 Option Field Layout
IPv6 Extension headers except for Hop-by-Hop options header are not
examined until the packet reaches the node specified by the
Destination Address field. In order for the intermediate routers
to look closer the RSVP control messages, Hop-by-hop option header
is used in IPv6 (Router Alert Option is defined within the IPv6
Hop-by-hop) header. Further, in order for the data packets destined
to the mobile node having new care-of address to use the resources
reserved before moving, each data packet SHOULD carry original
IP addresses in Hop-by-hop options header.
0 16 24 31
+---------------+--------------+
| Option Type | Option Data |
| | Length |
+-----------------------------+---------------+--------------+
| Effective Source Address |
+------------------------------------------------------------+
| |
+------------------------------------------------------------+
| |
+------------------------------------------------------------+
| |
+------------------------------------------------------------+
| Effective Destination Address |
+------------------------------------------------------------+
| |
+------------------------------------------------------------+
| |
+------------------------------------------------------------+
| |
+------------------------------------------------------------+
Option Type
8-bit identifier that specifies the option type
Option Data Length
8-bit integer that indicates the length of the option
data field
Effective Source Address
128 bits
Effective Destination Address
128 bits
Eunhee Joo et al. Expires 2 May 2002 [Page 13]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
3.4.2 Implementation with using RSVP Adaptation Layer
Just like Mobile IP manages home address and care-of address and
Home Agent manages binding information between them,
RSVP Adaptation Layer manages RSVP Binding Table.
A PathResv message carries binding information. When a router
receives a RSVP PathResv message, it creates or updates binding
information in the Biding Table. If there is no matching entry
in the table, a new entry will be created, and if there is
a matching entry (i.e. a mobile node moves once more) but having
different new flow identification, the existing entry will be replaced
with the one carried by an arriving PathResv message. A binding entry
will be deleted accordingly when a path or reservation state
is deleted. This layer replaces filter spec of the original flow
with new filter spec by the addresses found in the Binding Table.
Therefore, the modified filter spec is passed to the packet
classifier in the IntServ model.
+----------------------------+------------------------------+
| Original Flow Identifier | Flow Identifier after moving |
+----------------------------+------------------------------+
| SA+DA+SP+DP+PI | SA+DA(new)+SP+DP+PI |
+----------------------------+------------------------------+
| . | . |
| . | . |
| . | . |
+----------------------------+------------------------------+
SA: Source Address
DA: Destination Address
SP: Source Port Number
DP: Destination Port Number
PI: Protocol Number
3.4.3 Router Alert Option
The router alert option SHOULD be set to indicate that the routers
SHOULD investigate this message [6]. In IPv6, the Router Alert Option
is used in Hop-by-hop option header.
3.4.4 Requirements for All RSVP Hosts and Routers
- Every RSVP node MUST be able to process a Effective Address Option
received in any packet upon using IP option field, otherwise every
RSVP node MUST be implemented RSVP Adaptation Layer
- Every RSVP node MUST be able to process a PathResv message
3.4.5 PathResv Messages
In order to make PathResv message recognized, Message Type Field
of RSVP common header SHOULD be extended. Currently there are seven
message types.
Eunhee Joo et al. Expires 2 May 2002 [Page 14]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf
In addition to these seven[R1] types, we need to define PathResv and
PathResvErr types as follows.
8 = PathResv
9 = PathResvErr
The format of a PathResv message is as follows:
<PathResv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE>]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
[ <sender descriptor> ]
<flow descriptor list> ::= <empty> |
<flow descriptor list> < flow descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
Note that objects used to define PathResv are from
"Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification (RFC 2205)".
4. IANA Consideration
This document defines one new type of IP destination option,
which MUST be assigned an Option Type value.
5. Conclusion and Future works
We have suggested a new mechanism providing faster reaction for the
terminal mobility with Extended-RSVP. For this mechanism we defined
a new message type PathResv. We expect this mechanism to react
in a faster way for the mobile user for following reasons:
First, this mechanism allows the sender to make a reservation
at the same time creating path states in the routers with known
information from the previous communication.
Second, this mechanism starts to request with minimum QoS to make
the request of resource accepted with higher probability.
Therefore it can minimize the set-up time due to the resource
request rejection from the intermediate routers.
Eunhee Joo et al. Expires 2 May 2002 [Page 15]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
Third, the resources for the previous flow in the routers can be
retained for the flow in the new path. This feature reduces
not only the delay to establish a new connection but also the
probability of failure of resource request in the shared routers
between the old path and the new path.
We identified that three important requirements in related to
resource reservation in mobile computing by investigating
existing research about QoS and mobility protocols.
1. It is not appropriate to use IP addresses as an identification
key of a flow due to their dependences on location
(e.g. There is inefficiencies to use RSVP in mobile computing
environment because RSVP use IP addresses to identify a flow).
2. Fast reservation is more important in mobile computing
environment because reservation set-up MAY need to be done
during active service (e.g. RSVP is not appropriate due to
its set-up delay time). It SHOULD be minimum to handle errors
or re-negotiate QoS requirements after handoff.
3. Advance reservation scheme SHOULD be supported for guaranteed
QoS. It provides not only fast reservation set-up but also more
importantly network resource availability in the newly
connected network. Therefore in order to support mobility
independent end-to-end QoS guarantees, advance reservation
SHOULD be supported.
Also we have proposed an alternate way to improve the performance of
RSVP when it is used in mobile computing environment.
However, too many add-ons may degrade network performance and
thus an add-on may not be the most efficient way to bring QoS
to mobile hosts.[R2] QoS SHOULD be considered as the fundamental
function of network architecture. Therefore it is needed to design
a new lightweight reservation protocol that works well in mobile
computing environment.
References
[1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
ReSerVation Protocol (RSVP) - Version 1 Functional
Specification", RFC 2205, Sep. 1997
[2] The Design of the RSVP Protocol, R. Braden, D. Estrin,
S. Berson, S. Herzog, D. Zappala, ISI Final Technical Report,
July 1996.
[3] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, Jan. 2000
[4] C. E. Perkins, "Mobile Networking Through Mobile IP",
IEEE Internet Computing, January/February 1998, pp58-69
Eunhee Joo et al. Expires 2 May 2002 [Page 16]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
[5] C. Tseng, G. Lee, R. Liu, "HMRSVP: A Hierarchical Mobile RSVP
Protocol", International Workshop on Wireless Networks and
Mobile Computing (WNMC2001), April 16-19, 2000
[6] D. Katz, "IP Router Alert Option", RFC 2113, February 1997
[7] C. Perkins, "IP Encapsulation within IP", RFC 2003,
October 1996
[8] David B. Johnson, Charles Perkins, "Mobility Support in IPv6"
Internet Draft, Internet Engineering Task Force,
draft-ietf-mobileip-ipv6-12.txt, work in progress, April 2000
[9] S. Deering, R. Hinden, "IPv6 Specification", RFC 2460,
December 1998
[10] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998
[11] A.K.Talukdar, B.R.Badrinath, A.Acharya, "MRSVP: A Resource
Reservation Protocol for an Integrated Services Network with
Mobile Hosts", Rutgers University Technical Report, July 1997.
[12] H. Chaskar, R. Koodli, "A Framework for QoS Support in
Mobile IPv6", Internet Draft, Internet Engineering Task Force,
draft-chaskar-mobileip-qos-01.txt, work in progress,
March 2001
[13] H. Chaskar, "Requirements of a QoS Solution for Mobile IP",
Internet Draft, Internet Engineering Task Force,
draft-chaskar-mobileip-qos-requirements-00.txt, work in progress,
June 2001
Eunhee Joo et al. Expires 2 May 2002 [Page 17]
INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001
Authors' Addresses
Questions about this document can also be directed to the authors:
Eunhee Joo
University of Sheffield
Department of Electronic and Electrical Engineering
Mappin Street, Sheffield
S1 3JD, United Kingdom
Phone: +44 114 222 5826
Fax: +44 114 272 6391
Web: http://www.c4mcr.shef.ac.uk
E-mail: elp99ej@shef.ac.uk
Rob Edwards
University of Sheffield
Department of Electronic and Electrical Engineering
Mappin Street, Sheffield
S1 3JD, United Kingdom
Phone: +44 114 222 5813
Fax: +44 114 272 6391
Web: http://www.c4mcr.shef.ac.uk
E-mail: r.Edwards@shef.ac.uk
Chern Nam Yap
Seamoby Forum
Tulpenstr. 4,
D-63128 Dietzenbach,
Germany
Phone: +49 173 967 3381
Web: http://www.seamoby.org
E-mail: cny@ieee.org
Eunhee Joo et al. Expires 2 May 2002 [Page 18]
