Internet DRAFT - draft-decarolis-qoshandover
draft-decarolis-qoshandover
Mobile IP Working Group Andrea De Carolis
INTERNET DRAFT Luca Dell'Uomo
Fabio Pugini
Document: draft-decarolis-qoshandover-02.txt University of
Category: Informational Rome "La Sapienza"
April 2000
QoS-Aware handover for Mobile IP:
Secondary Home Agent
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Abstract
This document specifies an extension to the Mobile IPv6 [1] Protocol
that enables a Mobile Node to perform a particular kind of handover
called QoS-Aware handover. This kind of handover allows the Mobile
Node to change the current point of attachment to the Internet
without loosing the perceived QoS. This extension is part of a larger
effort toward the integration of Mobility and QoS over IP.
In this document a new mobile agent, the Secondary Home Agent (SHA),
is introduced. The SHA allows the mobile node (MN) to establish a new
QoS reservation before dropping the old one. This is realised without
reserving resources for both the new and the old data path.
We will show that the introduction of this new network entity is
useful to maintain the perceived QoS during the handover and it can
avoid some routing inefficiencies that MAY arise during this phase.
The amount of the improvement with respect to a plain Mobile IPv6
architecture is also taken into account.
It is important to remark that no modifications need to be applied to
the correspondent nodes in order to support the proposed way of
operation.
De Carolis Informational - September 2001 1
QoS-Aware handover for Mobile IP April 2001
Table Of Contents
Status of this Memo..........................................1
Abstract.....................................................1
Table Of Contents............................................2
1.Assumptions................................................3
2. Conventions used in this document.........................4
3. Introduction..............................................5
3.1 Non QoS-Aware Approach...................................7
3.2 QoS Aware Approach.......................................7
3.3 SHA operations for the uplink connections................9
3.4 SHA operations for the downlink connections.............10
4. Definition of the QoS Service:...........................11
4.1 Uplink QoS-Handover Procedure...........................12
4.2 Downlink QoS-Handover Procedure.........................13
5. Integrated Support for QoS and Mobility..................15
5.1 First Connection........................................15
5.2 Forced handover.........................................16
5.3 QoS-Aware HandOver Procedure (HOP procedure)............17
5.4 Resource Reservation on the new link....................21
5.4.1 Uplink Reservation....................................21
5.4.2 Downlink Reservation..................................24
6. Extensions concerning the Mobile IP Protocol.............25
7. Extensions concerning the RSVP Protocol..................25
8. Security Considerations, AAA.............................25
9. References...............................................26
10. Acknowledgments.........................................27
11. Author's Addresses......................................27
De Carolis Informational - September 2001 2
QoS-Aware handover for Mobile IP April 2001
1.Assumptions
In the following we assume that the RSVP signalling protocol
[RFC2205] is supported by both the Mobile Node and the Access Routers
and that it is used in order to setup the resource reservations and
guarantee the desired IP-QoS level. We also assume that wired or
wireless data link layers are able to support the same QoS levels, or
at least to signal to the RSVP modules that a certain reservation is
not possible.
Further background assumptions of this work are:
A mobile node can choose to access the Internet through more than one
link layer technology at the same time. This means, for example, that
in case of a wireless access network made up of different access
technologies (like UMTS/GPRS and WLAN IEEE 802.11), the coverage
areas MUST considerably overlap in order to achieve a QoS Handover.
For a successful completion of the QoS-aware handover, the router
hosting the SHA MUST belong to both the new and the old path
connecting the CN to the MN.
The last condition can be achieved in two different ways:
When the SHA will be placed in the GMA (in case of use of
Regionalised Registration [11] option) and in the MAP (in case of
Hierarchical Mobile IP [10] option)
When the above condition is satisfied by means of the routing
algorithm and by the particular topology of the network.
Furthermore to avoid modifications to the RSVP protocol that would
consider two PATH messages coming from different links as belonging
to the same session, the SHA should be placed at the path crossover
Router (i.e. before another RSVP router do merge the flows).
We will show that this assumption is important for the correct
functioning of the QoS-aware handover of downlink connections.
In this scenario it COULD be possible for a Mobile Node to perform a
handover because the link-layer connectivity has dropped, but also to
take handover decisions depending on QoS needs, Geographical Location
or other issues.
Performing an handover for the latter reasons makes sense only if
during the handover the IP QoS perceived on the old link is
maintained. The proposed solution to reach this goal is to test the
availability and QoS performance of the new link before dropping the
old one, that is to verify the resource availability along the data
path with the RSVP protocol PATH/RESV messages and, if the connection
De Carolis Informational - September 2001 3
QoS-Aware handover for Mobile IP April 2001
is accepted, reserve the needed resources before completing the
handover sequence. On the other hand when the drop in the QoS during
the handover cannot be avoided, then the handover SHOULD be performed
only for link-layer QoS considerations (for example when a fading of
the radio signal raises the Bit Error Rate).
2. Conventions used in this document
ISP - Internet Service Provider:
An entity that provides the following
services: IP Access, AAA, Billing,
Security and a temporary IP address.
SAP - Service Access Point:
It represents a particular interface
between two layers of the network
architecture where a particular service
is available.
SLA - Service Level Agreement:
This term refers to a particular
agreement between ISPs about QoS
policies between their networks.
IP-Level handover: The Mobile IP handover, needed in order
to take packets addressed to the Mobile
Node Home address up to its actual point
of attachment to the Internet
(represented by a CoA).
Link-Layer-Level handover: The switch between interfaces, driven by
the Mobile Node.
We want to underline the difference between IP-Level and Link-Layer-
Level handover: The former involves a change in the Care-of Address
but not necessarily a change in the type of access. An example is
when a Laptop is unplugged from a LAN and plugged in again, for
example, in a different building. The latter basically involves a
switch between two physical links available at the same time for the
node, for example the handover from a UMTS interface to a WLAN 802.11
one.
In order to integrate QoS and Mobility it is important to specify
some terms and aspects related to the handover:
Forced handover It occurs when there is a drop of the QoS in the
link layer (for example due to interference or
fading that occurs in a wireless radio signal,
or to the unplugging of the LAN connector). In
this case it is not possible to support IP QoS
or IP connectivity on the current link any
De Carolis Informational - September 2001 4
QoS-Aware handover for Mobile IP April 2001
longer. In this case a handover procedure is
started in order to connect to a new link, get a
new CoA and so on.
QoS-Aware handover It MAY occur for example when a "Better" (for
example with respect to QoS performances or
according to a precedence list of access
interfaces) link becomes available. In this case
the Mobility Support Module of the Operating
System installed inside the Mobile Node, SHOULD
verify the possibility to start an handover for
those active sessions that require QoS. If a
large bandwidth demanding session is still
active, and it cannot be served by the new Link
with the same QoS level that it is perceiving on
the old link, a QoS-Aware handover SHOULD NOT be
performed. On the other hand if the QoS
available on the new link is compatible with the
current needs of the application, a QoS-Aware
handover COULD be performed.
Access Router It is a router that sends in downlink the
Router Advertisements and provides IP
connectivity towards the Mobile nodes
Access Segment It is an access technology that allows a Mobile
Node to connect at data link layer to the
access router
3. Introduction
Let's assume that a Mobile Node is connected to a certain Access
Router AR1 by means of a wireless connection. This Access Router is
the Mobile NodeÆs fixed Point of Attachment to the Internet. This AR
is currently supporting a certain number of QoS Sessions belonging to
the Mobile Node.
After that the Mobile Node has performed some measurements on the
beacon signals received from base station controlled by AR1 and AR2,
it decides to move all the active QoS Sessions on the wireless link
towards the second Access Router AR2. We assume that the Mobile Node
MUST be able to activate the wireless link towards the AR2. The
situation is shown in Fig.1.
We assume that the QoS architecture is that of the Integrated Service
framework [RFC1633]. Thus, we will assume that QoS is provided by
means of explicit per-flow resource reservations that are installed
with RSVP signalling protocol. Guaranteed Service is a clear example
of such a strategy.
Further work is being carried out to consider also architectures
based on Differentiated Service [RFC 2474, 2475] approach in the
Access Network.
De Carolis Informational - September 2001 5
QoS-Aware handover for Mobile IP April 2001
We are also supposing that the Mobile Node is involved in a unicast
communication with the correspondent nodes.
In this context, before the mobile node could operate the handover of
its active sessions with QoS, it checks the availability of resources
on the new link toward which it is moving. If the new link is able to
uphold those sessions then the handover is performed. Otherwise the
current connection with the first AR is maintained.
+------------+ +------------+
| Access | < | Home Agent |
| Router |---- > ---+ +------------+
/| | < \ * * * * /
/ | AR1 | \ * * /
/ +------------+ \ * *
/ +------------+ * *
+----+ | | * IP *
| | | Secondary | * * +---------------+
| MN | | Home |-* Network *-| Correspondent |
| | | Agent | * * | Node |
| |\ | | * * +---------------+
+----+ \ +------------+ * *
\ / * *
\ +------------+ / * * *
\ | Access | < /
\| Router |-- > -+
| | <
| AR2 |
+------------+
Fig.1. The basic Secondary Home Agent architecture
This way of operation is called QoS-Aware handover. It is different
by a common handover because it is not triggered by events related to
radio link failures (like in the case of Forced handover).
We briefly summarise the RSVP way of operation: The sender end-system
issues a PATH message towards the receiver end-system.
The PATH message is modified by each router on the path towards the
receiver in order to insert particular parameters that will be used
by the RSVP module (of the receiver host) in order to determine the
needed resources (these are the error terms parameters).
Moreover in each RSVP-capable router, the PATH message is used to
install a soft state entry that is necessary to provide QoS to the
requesting flow.
This soft state includes the flow identifiers and the previous router
address from which the PATH message was received. In this way it is
De Carolis Informational - September 2001 6
QoS-Aware handover for Mobile IP April 2001
possible to correctly route the RESV messages that are the signalling
messages needed to reserve resources that are estimated by the
receiver and to refresh the soft state in each RSVP-capable router
along the path from the receiver to the source. This is a simple
solution to have the reverse path identical to the direct one. If the
packet is not dropped by any of the reverse path routers than the
connection is accepted.
The above mentioned operations imply that the PATH message is
associated to the path followed by the packets. This means that, if
the path changes after that an handover from AR1 to AR2 is performed,
then also the error terms parameters included in the PATH message
received by the destination end-system will change. Thus, also the
amount of resources that has been reserved to a particular flow on
the old path will probably change after the route change. Then if we
want to maintain the QoS perceived by a flow after a route change, it
is necessary to test resource availability on the new link before we
perform the handover, we need to send a PATH message through the new
link before making the real handover.
3.1 Non QoS-Aware Approach
The current approach to the Mobility does not consider the
possibility to send PATH messages on the new link, that Mobile node
built up with the AR2, before the handover is completed. More in
detail, as far as uplink connections are concerned, the mobile node
has to complete the handover in order to get a new Care-of Address
and correctly update the bindings both at its Home Agent and at its
correspondent node. After the completion of the location update
procedure, the Mobile Node can use the newly acquired Care-of Address
as source address in the new PATH message sent through AR2.
On the other side, for the downlink sessions, the correspondent node
keeps issuing PATH messages towards the known Care-of Address on the
old link towards AR1 until it receives a new binding update, i.e.
until the handover from AR1 to AR2 has been completed. Thus a QoS
connection denial (i.e. a RESVERR message [RFC 2205] sent on the new
path) could happen after the old link has been dropped. This implies
that the QoS level that the Mobile Node was perceiving on the old
path through AR1, cannot be guaranteed on the new link after that an
handover occurred.
3.2 QoS Aware Approach
LetÆs first consider uplink sessions.
In our proposal when a handover for uplink sessions is initiated, the
mobile node sends PATH messages on both the old and new link: on the
former to maintain the soft state reservations, on the latter to test
the resource availability. The two PATH messages will meet in a node,
that is shown in Fig.1, where the Secondary Home Agent (SHA)
De Carolis Informational - September 2001 7
QoS-Aware handover for Mobile IP April 2001
functionality is installed. This is a merging node for RSVP
signalling messages and for traffic packets.
In order to avoid a double resource reservation along the rest of the
path, i.e. from the SHA to the Correspondent node, the SHA has to be
aware of the particular handover that is undergoing. In our proposal
the handover is always Mobile Node driven, i.e. the Mobile Node sends
a signalling message called handover Initiation Messages (HIM) to the
SHA in order to start a QoS-Aware handover.
Then the Mobile Node can send PATH messages towards AR1 and AR2.
Upon receiving the PATH messages from both the old and the new link,
the SHA can recognise them as belonging to the same session for which
the Mobile Node asked a QoS-aware handover with the HIM message. Thus
the SHA will forward only one PATH message towards the correspondent
node. The SHA chooses to forward the PATH message that carries the
worst error terms, i.e. the PATH message that will generate, in the
receiver, the larger bandwidth R to be reserved along the data path;
the other PATH message is not forwarded. The chosen PATH message can
be the one from the old link or the one from the new link
indifferently.
It should be noted that the PATH messages SHOULD not meet before the
SHA, because intermediate routers (unaware of QoS handover Approach)
could assume that a change has occurred in the routing. The two PATH
messages can be distinguished at the SHA because the old and the new
path towards the receiver are different.
Then in the PATH message the previous router field is different.
The SHA forward towards destination only one PATH message: the one
that has the worst deviation parameters from the fluidic model.
When this message arrives to the receiver end-system, that is the
Correspondent Node the bandwidth R to be requested is evaluated
according to the Parekh and Gallagher formulas [23]. Then R is
inserted in a RESV message that is sent back along the path.
We define Rn as the bandwidth that has to be reserved on the new path
in order to guarantee the desired QoS level (that is the same that
the Mobile Node was perceiving on the old path) while Ro is the
amount of bandwidth that was previously reserved on the old path to
obtain a certain QoS level. Then it can be easily seen that the
following relationship holds:
R=max(Ro,Rn)
This choice is made because we donÆt want that the old reservation
along the old path to break: in other terms we want to be able to
come back to the old reservation in case that the handover on the new
link would fail for any reason.
De Carolis Informational - September 2001 8
QoS-Aware handover for Mobile IP April 2001
This relationship implies that during the QoS-aware handover, a
bandwidth R can be reserved which is larger than the necessary: this
leads to a temporary reserved resource waste. This waste, due to the
forwarding of the PATH message with worst case parameters, could
happen when:
1) Ro>Rn and the handover is completed (that is the mobile node
switches on the new link). In this case the reserved bandwidth on
the new link is less than the old bandwidth previously reserved
on the old link, but the old bandwidth has been reserved anyway
also on the new link.
2) Ro<Rn and the handover has failed (that is the mobile node wonÆt
switch on the new link). In this case the handover has failed but
the reserved bandwidth on the old link is greater than the
strictly necessary, because is the one that has been calculated
for the new path that has been reserved also for the old path.
This inefficiency is automatically recovered as the handover phase
ends (whatever the result is) because no more worst case PATH
messages choice will be performed at the SHA. When the RESV message
arrives at the SHA, it is forwarded to new link only.
If the mobile node receives the RESV message (that the SHA has
forwarded on both the old and the new path) it checks the resource
availability on its access interface towards the new path (i.e.: the
one that comprehends the AR2) according to the RSVP protocol.
At this moment the mobile node is aware that the resources has been
reserved along the new path and if this happens for each active
session, a QoS-aware handover is feasible (note that if more than one
QoS-session is active we can run the resource pre-reservation for all
the sessions simultaneously in order to reduce the overall duration
of the handover); otherwise, in the mobile node, a timer expires
(this timer has been set when the mobile Node has sent a HIM message
to the SHA. Its value is a project parameter) indicating that a QoS-
aware handover denial has occurred, due to lack of resources along
the new path. In this case the QoS handover can not be performed.
3.3 SHA operations for the uplink connections
These are the operation that the Secondary Home Agent (SHA) MUST
perform:
1. It chooses which PATH message to forward on the outgoing link,
towards the receiver, considering the worst case scenario. In
this way along the path from the SHA up to the correspondent node
only one reservation will be required. This means that the QoS
path is ready in both cases of successful or unsuccessful QoS-
aware handover.
2. It forwards the new RESV message only on the new path towards the
Mobile Node, while it forwards the old RESV message on the old link
to maintaining the soft state of the old reservation. Moreover, the
mobile node continues to send PATH messages on the old link: these
De Carolis Informational - September 2001 9
QoS-Aware handover for Mobile IP April 2001
are necessary to maintain the soft state reservations on that link.
This is necessary because the QoS-aware handover on the new link
could fail, and the mobile node SHOULD be able to continue to
perceive the QoS on the old link.
In order to support the above described operations, we suggest in
this draft to add a new integrated QoS & Mobility Support Agent in
one or more routers, that already support Hierarchical Mobile IPv6
[10]or Regionalised Registration v6 [11].
In this case, a Secondary Home Agent is an enhanced MAP node of the
Hierarchical Mobile IPv6 framework, that is able to manage the Mobile
Node mobility and to cooperate with the Mobile Node itself in order
to reserve resources on the new link before the handover is
performed.
3.4 SHA operations for the downlink connections
The handover procedure is slightly different for downlink
connections. The difference is due to the need to move logical flow
duplication (i.e. :PATH/RESV message duplication) in the SHA and the
handover decision functions in the MN.
For the above considerations, the case of handover of uplink
connections is quite complex and the relative mechanism is described
in the following.
De Carolis Informational - September 2001 10
QoS-Aware handover for Mobile IP April 2001
4. Definition of the QoS Service:
In order to provide QoS-Aware handover, we need to add to the Mobile
Node protocol stack a Service Access Point (SAP) where the IP packets
can access a particular Service. This Service is a specific kind of
QoS-Aware IP connectivity. This connectivity is transparent to IP
Mobility related issues.
This means that, in order to test the availability of resources
before the Mobile IP handover (no resources available implies a QoS-
Aware handover failure) we need to add also a set of functions to
test and manage resource availability.
Applications that connect (by means of the Mobile Node) to the SAP
where this Service is available, will not see drops in the perceived
QoS when the Mobile Node is performing, or has just performed, a QoS-
Aware handover. This means that if they received IP-QoS availability
confirmation they can trust the underlying systems to provide this IP
QoS for the time granted by the network, even if a QoS-Aware handover
occurred, and a new link is used to provide the connectivity.
This approach implies that a Mobile Node performing a QoS-Aware
handover, is in charge of supporting IP-QoS, for each active session,
even during the handover.
This is not possible using Mobile IPv6 framework as it is because the
QoS is managed end-to-end. Following that approach, it is possible to
understand if bandwidth is available on the new link for a certain
session, only after the handover has occurred (this means that IP-QoS
on the new end-to-end path is not present when the first packet is
sent on that link).
The full end-to-end approach (used for the Forced handover that is
what is referred to as "Handoff" in the baseline MIP protocol
description) is the best we can do if the handover takes place for
issues related to radio coverage (or if the Mobile Node is unplugged
from a network and plugged again in another one).
Forced handover is not the best solution in some other cases, for
example:
1. when the handover is aimed to move the QoS sessions to a new link
in order to provide QoS to a new RSVP session,
2. when the MN has the possibility to seamlessly move the QoS
sessions from the old link (that it is going to be lost) to a new
one.
In the latter case the use of the SHA is very important because it
allows to reserve the correct amount of bandwidth on the new link. If
we cannot perform a PATH/RESV iteration on the new path (the one
associated with the new link) before the handover, we have no way to
De Carolis Informational - September 2001 11
QoS-Aware handover for Mobile IP April 2001
know the exact bandwidth needed by the mobile node to support the QoS
requested by the application. This happens because the bandwidth
depends directly on the characteristics of the path.
Then in order to support this new kind of handover, we need a
particular HandOver Procedure (that we called HOP). This procedure
will interact with the network in order to discover and reserve the
needed amount of resources on the new link before the actual Mobile
IPv6 handover takes place. The procedure will also stop the QoS-
handover if the QoS on the new link is not available.
Logical-flow duplication is managed by the HOP procedure. This
duplication has two reasons:
1. transmitting RSVP signalling packets on the new link layer
to reserve new resources
2. transmitting RSVP signalling packets on the current link
layer to keep old resources
The issues related to the reservation of the new resources are
addressed in the following sections.
The HOP procedure is run both at Mobile Node side and at Network
side. This symmetry is due to the fact that (in the worst case that
is a duplex communication) both the Uplink and the Downlink will need
the Logical Flow duplication.
We need to separate Uplink and Downlink in order to describe the
interaction between the Mobile Node and the SHA needed for the
reservation of resources on the new link and for keeping the
resources reserved on the current link:
4.1 Uplink QoS-Handover Procedure
1. At the Mobile Node side we envisage to apply a duplication of the
RSVP PATH messages. Each generated PATH message MUST reflect the
actual characteristics of the next hop in the OPWA parameters.
This means that the PATH messages sent on different links by the
same Mobile Node will be different (for example if each link
introduces a different latency time);
It should be noted that even if the two PATH messages have different
source addresses (i.e.: the new and the old CoA are written in the
source address of the IPv6 packet that carries the PATH messages),
the RSVP SenderSpec field in the PATH message is the same (i.e.: the
Home address of the mobile node).
2. each PATH message will be received by a different Access Router,
will travel on a different path (this is quite important in order
De Carolis Informational - September 2001 12
QoS-Aware handover for Mobile IP April 2001
to make the HOP work correctly) and will be modified by different
routers, finally it will arrive at the Secondary Home Agent;
3. the SHA will receive the PATH messages from both the new and the
old link. The SHA will then merge the flows, in the sense that it
will decide which PATH message SHALL be propagated. After the SHA
only one PATH message will be used to request the establishment
of a QoS Session;
4.2 Downlink QoS-Handover Procedure
1. The same scheme, applied for the Uplink, can be used for the
downlink. This means that, for the Downlink, it is the Secondary
Home Agent that operates the logical flow duplication (i.e.: it
physically duplicates the RSVP PATH messages).
2. each PATH message belonging to a session in QoS-handover received
by the Secondary Home Agent will be duplicated and forwarded on
both outgoing links, these messages will travel on different
paths (being modified by different routers) and finally they will
arrive at the Mobile Node;
3. the Mobile Node will receive the PATH messages from both the new
and the old link. It will then merge the flows, operating a
decision on which message has to be processed.
Then in order to support the HOP procedure the following requirements
must be met:
1. the Secondary Home Agent functionality is added in a router of
the network (in each domain there could be one or more SHA
provided they respect the requirement reported in
Assumptions).
2. The IP address of the router where a SHA has been installed is
known by each Access Router that can use that particular SHA.
A SHA MUST be connected (even if non directly) to different
ARs and each AR COULD be connected to more than one SHA. In
this way it is possible to perform a QoS-aware handover among
all the cells controlled by the ARs that are connected to a
certain SHA. In case of handover between cells controlled by
two different ARs that are connected to different SHAs, it is
necessary a interoperation between SHAs that has not yet been
defined.
3. The AR can advertise the availability of a certain set of SHAs
to which it is connected to the Mobile Node as soon as it
assigns to the Mobile Node an IPv6 Address (CoA). The MN can
eventually solicit the AR to send the same information by
means of a solicitation message.
De Carolis Informational - September 2001 13
QoS-Aware handover for Mobile IP April 2001
4. The packets sent by the Secondary Home Agent do reach the
Mobile Node using both IP-QoS-Aware networks and Link Layer-
QoS-Aware connections (i.e. we are talking of data-links that
are able to respect QoS requirements imposed by the upper
layer).
5. The crossover point of the two paths MUST not merge the RSVP
PATH messages unless it is a SHA.
It is important to remark that the Secondary Home Agent functionality
is a set of functions used only during the QoS-Aware handover to
provide logical flow duplication (i.e. duplication of PATH and RESV
messages) and management, after the handover the Node that supports
this Agent continues to operate as a common router (supporting QoS by
means of RSVP).
De Carolis Informational - September 2001 14
QoS-Aware handover for Mobile IP April 2001
5. Integrated Support for QoS and Mobility
In this chapter we present the main points of an integrated Mobility
and QoS management. The "first connection", the "Forced handover" and
the "QoS Aware handover" and "Resource reservation on the new link"
procedures are examined.
Each procedure is explained following this convention:
Sentence: (stepcodeSTEPstepnumber)
The æstepcodeÆ is used to distinguish steps belonging to different
procedures while the æstepnumberÆ is used to enumerate the steps
belonging to the same procedure.
5.1 First Connection
When the Mobile Node is switched on for the first time, it is not
connected to the Internet, then it needs to obtain a first Point of
Attachment to the Internet network. When more than one access segment
is available the point of attachment can be selected according with a
segment selection procedure (fcSTEP0).
This procedure takes the decision about which interface to use for
the first connection (fcSTEP1).
After the link-layer connection is set up (fcSTEP2), an address is
generated and assigned to the current interface of the Mobile Node
(fcSTEP3).
This address is used to exchange information between the Access
Router (AR) and the Mobile Node. The Mobile Node MAY send
solicitations to the AR to trigger this exchange. The information
sent back to the Mobile node MUST contain the address of at least one
SHA and an associated list of the access-routers connected to that
SHA, this list is used in order to understand if an Agent
Advertisement received by the Mobile Node belongs to an AR that can
perform an QoS-handover in cooperation with the specific SHA
(fcSTEP4).
A SHA is selected taking into consideration that a SHA associated
with more Access Routers gives larger probability of QoS-Aware
handover (fcSTEP5).
The locally generated (or locally assigned) CoA is sent to the
selected SHA that performs a (Hierarchical/Regionalised) Binding
Update with the Home Agent of the Mobile Node (fcSTEP6).
De Carolis Informational - September 2001 15
QoS-Aware handover for Mobile IP April 2001
+-----------------+
| START |
+--------+--------+
+--------+--------+
| fcSTEP0 | Checks the beacons to verify coverage
+--------+--------+
+--------+--------+ Select the new
| fcSTEP1 | interface for example WLAN1
+--------+--------+
+--------+--------+
| fcSTEP2 | CoA assignment or generation
+--------+--------+
+--------+--------+
| fcSTEP3 | CoA assignment to the Mobile Node interface
+--------+--------+
+--------+--------+
| fcSTEP4 | Get the SHA list
+--------+--------+
+--------+--------+ SHA selection from received list
| fcSTEP5 | according to particular policies
+--------+--------+
+--------+--------+
| fcSTEP6 | (Hierarchical) Binding Update towards its
+--------+--------+ Home Agent
+--------+--------+
| END | First registration concluded!
+-----------------+
fc : first connection ;
Fig.2. First Connection procedure
5.2 Forced handover
When the link-layer connectivity is lost on the current Interface
(for example because the network connector is unplugged or because
the beacon signal of a WLAN Base Station is under a certain
threshold) a Forced handover procedure is started (see Figure 3) the
first connection procedure (illustrated in Figure 2) is followed,
from fcSTEP0 to fcSTEP4.
If the previous SHA is in the set of SHAs associated with the new AR,
a Binding Update with the new CoA is sent to the SHA (and to the
previous AR according to the procedure that manages the Smooth-
Handoff[12]) (fhSTEPa).
In this case there is no need to inform of the handover neither the
Home Agent nor the correspondent Node because the Mobile Node is
still in the same region controlled by the same SHA (the handover
SHOULD be Fast)
De Carolis Informational - September 2001 16
QoS-Aware handover for Mobile IP April 2001
If the previous SHA is not in the set of SHAs toward which the new AR
is connected, then fcSTEP5 and fcSTEP6 are executed again (fhSTEPb).
In this case it is necessary to inform the correspondent Nodes and
the Home agent of the handover (by performing a new registration with
the SHA and sending a Binding Update for each CN and HA). This is due
to the fact that the Mobile Node has moved into a region covered by a
different SHA (the handover COULD be slow).
+--------------------+
| START |
+----------+---------+
+----------+---------+
| fcSTEP0 -> fcSTEP4 | First connection steps
+----------+---------+
|
/ \ Is previous SHA in the set of SHAs
/ \ associated with the new AR ?
+----<-------+ ? +-------->--------+
| Y \ / N +-------+-----------------+
| \ / | +-----+-----+ |
Binding +-----+-----+ + | | fcSTEP5 | |
Update | fhSTEPa | | +-----+-----+ fhSTEPb |
to SHA +-----+-----+ | +-----+-----+ |
| | | fcSTEP6 | |
| | +-----+-----+ |
| +-------+-----------------+
| +-----------+ |
+-------->| END |<-------------+
+-----------+ Forced Handover concluded!
fc : first connection ; fh : forced handover ;
Fig.3. Forced Handover procedure
5.3 QoS-Aware HandOver Procedure (HOP procedure)
When the link-layer connectivity on the current Interface is still
good (i.e. is not under the threshold that would trigger an handover
for link disruption), the Mobile Node MAY start the HOP Procedure.
This procedure COULD be triggered, for example, when the Mobile Node
detects, according with a certain internal algorithm, that it is
using a data link that is no more adequate to the applications needs
or that is largely under exploited. It should be noted that the
connections towards the old AR1 in Fig.1 (and also the previously
reserved resources on the involved links) are not released until the
handover procedure is completed.
De Carolis Informational - September 2001 17
QoS-Aware handover for Mobile IP April 2001
The following steps are performed:
0). (hopSTEP0): A timer is started to limit the
procedure duration.
1). (hopSTEP1): Is the aggregation of the steps
fcSTEP0 (the current Link identifier
and the actual needs of bandwidth are
passed to a segment selection
algorithm together with the access-
routers list associated with the
current SHA), fcSTEP1, fcSTEP2,
fcSTEP3, and fcSTEP4
2). (hopSTEP2): the Mobile node examine the list of
SHA associated with the new Access
Router. This list is attached to
router advertisement or to DHCP
message in case the IPv6 CoA is
obtained from DHCP server. If the
current SHA is not in the above list
the QoS-handover fails. Future HOP
extensions can connect to this point,
for example for the integration with
hierarchical registration.
3). (hopSTEP3): If the current SHA is in the list then
the HOP procedure goes on,
individuating each RSVP Session that
is in active state on the Mobile Node
(both Uplink and Downlink MUST be
taken into consideration). Further
extensions of the HOP protocol could
modify the last statement limiting the
action of the QoS-Aware handover to a
sub-set of connections.
4). (hopSTEP4): For each session from the hopSTEP3,
the Mobile Node sends to the SHA a
QoS-Aware handover Initiation Message
(HIM).
5). (hopSTEP5): This step is the most important one.
It is supported by a distributed
procedure, and is described in detail
in the paragraph 5.4. In this step,
for each session individuated at the
hopSTEP3, QoS availability on the new
link is tested and both link-layer
resources and IP-layer resources are
reserved.
De Carolis Informational - September 2001 18
QoS-Aware handover for Mobile IP April 2001
6). (hopSTEP6): If the hopSTEP5 does not fail, the
Mobile Node sends to the SHA a Binding
Update (Mobile IP handover).Each
connection is automatically moved on
the new link and the resources
allocated on the previous link are
released (The SHA for the Downlink and
the MN for the Uplink issue an RSVP
PATHTEAR Message. It has to be
remarked that the SHA MUST NOT forward
the received RSVP PATHTEAR message
received by the Mobile node).
7). (hopSTEP7): The Mobile node communicates to the
SHA the successful completion of the
QoS-Aware handover by means of an
handover Completion Message (HCM).
8). (hopSTEP8): The resources used at link layer for
supporting QoS on the old link are
released using appropriate signalling
messages on the old link.
A flow chart of the HOP procedure is shown in Fig. 4.
De Carolis Informational - September 2001 19
QoS-Aware handover for Mobile IP April 2001
+-----------------+
| START |
+--------+--------+
+--------+--------+
| hopSTEP0 | a timeout timer is started
+--------+--------+
+--------+-------------------------------------+
| | +-------------------+| Select the new
| +--------------->| fcSTEP0 & fcSTEP1 || interface for example
| +---------+---------+| WLAN1
| +---------+---------+| Connection setup,
| hopSTEP1 | fcSTEP2 & fcSTEP3 || CoA Generation
| +---------+---------+|
| +---------+---------+|
| +---------<------| fcSTEP4 || Get the SHA list
| | +---------+---------+|
+--------+-------------------------------------+
+--------+--------+
| hopSTEP2 | check the new SHA list for the presence of the
+--------+--------+ current SHA
|
/ \ the current SHA is
/ ? \ not present in the list
\ /--------------------------------------> QoS handover fails!
\ /
| the current SHA is present in the list
+--------+--------+
| hopSTEP3 | list of active QoS Sessions
+--------+--------+ (uplink and downlink)
+--------+--------+
| hopSTEP4 | send HIM messages
+--------+--------+
+--------+--------+ start uplink and downlink
| hopSTEP5 | distributed QoS handover management procedures
+--------+--------+
+--------+--------+
| hopSTEP6 | send Binding Updates messages
+--------+--------+
+--------+--------+
| hopSTEP7 | send HCM message
+--------+--------+
+--------+--------+
| hopSTEP8 | release resources on the old link
+--------+--------+
+--------+--------+
| END | QoS handover completed
+-----------------+
fc : first connection ; hop : handover procedure;
Fig.4. QoS-Aware HandOver Procedure
De Carolis Informational - September 2001 20
QoS-Aware handover for Mobile IP April 2001
5.4 Resource Reservation on the new link
We now go in further detail into the of resources reservation on the
new link.
For the sake of simplicity, we separate the procedure for the Uplink
and for the Downlink.
5.4.1 Uplink Reservation
If the Time Out set at the beginning of the QoS-handover is exceeded
while waiting for all QoS connections to be transferred on the new
link, then the QoS-handover Fails.
0). (rrSTEP0): If new RESV message arrives to the mobile node
from the old link, indicating that there is a
new active reservation for an outgoing flow,
then the list of active QoS-flows, that has been
generated in hopSTEP3, is extended, and a new
HIM message for the new installed flow is sent
to the SHA. The MN selects the next uplink
session in the list generated in the hopSTEP3.
1). (rrSTEP1): The MN sends PATH messages related with the
selected session on both the new and the old
link. When using OPWA reservation style, each
PATH message MUST be properly adapted to the
underlying link layer, in particular the right
link Latency Time and the Error Terms MUST be
added to compute the new overall path Error
Terms.
2). (rrSTEP2): When the SHA receives the PATH messages from the
MN, worst case is selected with an external
algorithm which select the worst case PATH
message
3). (rrSTEP3): The SHA forwards only the worst case PATH
message.
4). (rrSTEP4): As long as the Sender template used in the two
PATH messages is the same, the SHA, that knows
that a QoS handover is in progress because it
received the HIM message from Mobile node, not
only considers the last received PATH message
(normal behaviour for plain RSVP router) but
operates a worst case merging. After this
selection, a single PATH message is forwarded
towards the receiver, on the path that is not
object of handover. This PATH message could
carry information about the new link, and, once
received, it could generate a RESV message with
De Carolis Informational - September 2001 21
QoS-Aware handover for Mobile IP April 2001
a larger bandwidth demand. Even if the network
discards this message because no resources are
available, the previous installed soft-state,
according to the RSVP protocol, is not cleared
since PATH messages, issued by the mobile node
on the old link, maintain the soft-state. Then,
even if the QoS-HandOver Procedure fails to
reserve resources for the new link, all the
applications continue to see the expected QoS on
the previous link. When the SHA receives the
RESV messages from the Correspondent Node, and
the sender description corresponds to a session
that is involved in a QoS-Aware handover, it
forwards the RESV message only on the new link,
otherwise it sends the RESV message only to the
old link. The set of sessions generated at
hopSTEP3 COULD be extended with the new session
only after the RESV message arrives to the
Mobile node. While the Mobile node is waiting
for RESV messages for a certain session it
continues to send PATH messages. From this
protocol step on, the HandOver Procedure
executed at the Mobile node, can run in
background and continue to transfer another
session on the new link, repeating all the shown
steps, starting from rrSTEP0.
5). (rrSTEP5): When the Mobile node receives RESV message on
the new link, it performs a Link-Layer QoS
reservation for the uplink
6). (rrSTEP6): If the Link-layer QoS reservation fails the QoS-
Aware handover fails
7). (rrSTEP7): In the case that the link-layer QoS reservation
is successful, and this is the last session in
the set generated at hopSTEP3, then the protocol
will continue with hopSTEP6.
If this is not the last session in the set from hopSTEP3 then the
procedure will continue with rrSTEP0.
De Carolis Informational - September 2001 22
QoS-Aware handover for Mobile IP April 2001
+-----------------+
| START | a timeout timer is started
+--------+--------+
+------------>+
| / \ timeout
| check / ? \-----------------------------> QoS handover fails!
| timer \ /
| \ /
| + no timeout
| +--------+--------+
| | rrSTEP0 | Select a QoS Session
| +--------+--------+
| +--------+--------+
| | rrSTEP1 | receive 2 PATH messages
| +--------+--------+
| +--------+--------+
| | rrSTEP2 | select 1 PATH message
| +--------+--------+
| +--------+--------+
| | rrSTEP3 | forward the PATH message
| +--------+--------+
| +--------+--------+ wait and receive the RESV message, while
| | rrSTEP4 | waiting another session can be processed
| +--------+--------+
| +--------+--------+
| | rrSTEP5 | try to reserve resources
| +--------+--------+
| / \ few resources
| / ? \-------------------------> QoS handover fails!
| \ /
| \ /
| | resources reserved correctly
| there are / \
| other / ? \
+---------- \ /
sessions \ /
| last session
+--------+--------+
| END | QoS handover completed for
+-----------------+ the Uplink
Fig.5. Resource Reservation procedure on the new link
De Carolis Informational - September 2001 23
QoS-Aware handover for Mobile IP April 2001
5.4.2 Downlink Reservation
If the Time Out set for the QoS-handover is exceeded while waiting,
then the QoS-handover Fails. If new PATH messages arrive to the MN
from the old link then the set of sessions generated at hopSTEP3 is
extended and a new handover Initiation Message is sent to the SHA in
order to describe the new sessions.
The MN selects the next Downlink session in the set from hopSTEP3
(rrSTEP0).
The SHA examines each PATH message, when it detects a Sender
Description conformant to the one specified in a HIM message, it
duplicates the PATH message and forwards them both on the new and the
old link. Each AR has the task to update each PATH message in such a
way that (once it is received at the MN) it will report the OPWA
parameters corresponding to the link layer it is going to use.
When the MN receives two PATH messages it propagates to the standard
RSVP module (or to the destination) only the worst case one (as
explained for the Uplink).
At Receiver side the Application (or the Operating System) computes
the needed bandwidth to be reserved, inserts this information in a
new RESV message and forwards it to the MN routing module.
If the RESV message generated by the applications does not contain a
ResvConf reservation confirm object, this is added.
The MN forwards the RESV packet only on the new link (the packets
that continue to arrive from the old link still perceive the expected
QoS because the soft state are maintained by the PATH messages issued
by the SHA).
If the RESV message is discarded by the network, a ResvError Message
is propagated back to the SHA and to the MN. The MN does not
propagate the ResvError to the applications, but it sends again the
PATH message of the first link to the applications that answer with a
RESV message that is propagated on the old link. The QoS-Aware
handover Fails (but the old link is still supporting the QoS
sessions).
A timer is set to wait for the ResvConf message, the QoS-Aware
handover Fails when the timeout is triggered by the timer.
If ResvConf message arrives at the Mobile Node and this is the last
element of the session set from hopSTEP3, the Mobile Node first
performs hopSTEPS6 and hopSTEPS7, then it sends to the application
the ResvConf message, finally it performs hopSTEPS8. If there are
other elements in the set from hopSTEP3, then the protocol goes back
to rrSTEP0.
De Carolis Informational - September 2001 24
QoS-Aware handover for Mobile IP April 2001
6. Extensions concerning the Mobile IP Protocol
Mobile Node
The Mobile Node needs to solicit SHA advertisements every time it
connects to an AR. The format of the packets used for this exchange
of information is not specified in this work.
The Mobile Node MUST support the HOP protocol, and be conformant to
the background assumptions (see section 1).
Secondary Home Agent
It needs to extend Regionalised Registration with the integration of
SHA functionality. It MUST be able to manage the QoS as required by
the HOP procedure.
Access Routers
The ARs need to be extended in order to exchange information about
the SHA they are connected to.
7. Extensions concerning the RSVP Protocol
No extension to the RSVP protocol is needed to perform QoS-aware
handover when SHA are adopted. Hence this is a remarkable point of
our proposal.
8. Security Considerations, AAA
In this proposal no further AAA considerations are needed since QoS-
aware handover does not introduce modifications in the actions needed
for the handover, but it simply modifies their sequence. Then the
security considerations of Mobile IP apply.
De Carolis Informational - September 2001 25
QoS-Aware handover for Mobile IP April 2001
9. References
[1] P. Conforto, G. Losquadro, C. Tocci, N. Blefari-Melazzi,
A. De Carolis, F. Di Cola, P.M.L. Chan, Y.F. Hu: "Mobility Management
in the SUITED/GMBS Multi-Segment System", Mobile Summit 2000
[2] P. White: "RSVP and integrated services in the Internet: a
tutorial", IEEE Communications magazine, Vol. 35, N. 5, May 1997.
[3] Charles E. Perkins: "Mobile IP", Communications Magazine,
May Æ97, pp.84-99.
[4] X.Xiao, L.M.Ni: "Internet QoS: a big picture", IEEE Network,
Mach/April 1999, pag.8-18.
[5] A. Parekh and R. Gallagher, "A Generalized Processor Sharing
Approach to Flow Control -- The Single Node Case," IEEE/ACM Trans.
Networking, vol. 1, no. 3, 1993, pp. 356-57.
[6] H. Soliman, C. Castelluccia, K. Malki, L. Bellier: "Hierarchical
MIPv6 mobility management", IETF-DRAFT, Nov 30, 2000 (work in
progress)
[7] R. Hinden, S. Deering: "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, December 1995
[8] D. Johnson, C. Perkins: "Mobility Support in IPv6", IETF-DRAFT,
(work in progress)
[9] C. Castelluccia, L. Bellier: "Mobile Networks Support in Mobile
IPv6", IETF-DRAFT, (work in progress)
[10] K. El-Malki, H. Soliman, C. Castelluccia, L. Bellier:
"Hierarchical MIPv6 mobility management", IETF-DRAFT, (work in
progress)
[11] J. T. Malinen, F. Le, C. Perkins: "Mobile IPv6 Regional
Registrations" IETF-DRAFT, (work in progress)
[12] G. Krishnamurthi, R. C. Chalmers, C. Perkins: "Buffer Management
for Smooth Handovers in IPv6" IETF-DRAFT, (work in progress)
De Carolis Informational - September 2001 26
QoS-Aware handover for Mobile IP April 2001
10. Acknowledgments
Thanks to Pietro Tou for the review of this document.
Special thanks to Charlie Perkins for his letters and suggestions.
11. Author's Addresses
Andrea De Carolis
E-Mail: ade_carolis@tin.it
Luca DellÆUomo
Fabio Pugini
University of Rome "La Sapienza" - INFOCOM Department
Via Cavour, 256
00100 - Rome
Italy
E-Mail: delluomo@infocom.uniroma1.it
E-Mail: pugini@infocom.uniroma1.it
Full Copyright Statement
"Copyright (C) The Internet Society 2001. 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.
De Carolis Informational - September 2001 27
