Internet DRAFT - draft-iponair-dna-polimand
draft-iponair-dna-polimand
DNA Working Group S. Aust
Internet-Draft C. G÷rg
Expires: August 25, 2005 ComNets-ikom, Uni Bremen
C. Pampu
Siemens AG
February 21, 2005
Policy Based Mobile IPv6 Handover Decision (POLIMAND)
draft-iponair-dna-polimand-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2005.
Abstract
A handover is the process during which a mobile node is handed over
between access networks. Especially for vertical handovers in overlay
networks the mobile node changes the access network using multiple
interfaces including different link layers, e.g., WLAN, GPRS, and
UMTS. Handovers occur as a consequence of lower layer (i.e., link-
layer) handovers that signify a switch of the physical connection to
a new location. For the duration of a handover, a mobile node is
unable to send or receive traffic. The length of this disruption is
considered critical because it affects the performance of the
communication. An additional factor is the link layer selection. It
implies the selection of the most suitable link layer from which a
mobile node should receive services.
With the help of DNA it is possible on one side to provide proactive
handover decision for mobility protocols (e.g., for MIPv6) and on the
other side to select the best link layer including multiple interface
support. This draft describes a method that allows seamless handovers
IPonAir Expires August 25, 2005 [Page 1]
Internet-Draft POLIMAND February 2005
and optimal link layer selection using a proactive handover decision
that is based on a policy. The policy considers L2 information and
DNA assumptions.
Table of Contents
1. Introduction....................................................2
2. Conventions used in this document...............................2
3. Terminology.....................................................3
4. Seamless Handovers in Wireless Networks û Problem Overview......3
5. Reactive/Proactive Handover Decision............................4
5.1 Reactive Handover Decision.....................................5
5.2 Proactive Handover Decision....................................5
6. Link Layer Information..........................................6
7. Handover Policy.................................................6
7.1 Handover Policy Decision Function..............................7
7.2 Definition of the Handover Policy Decision Function............7
7.3 Handover Policy Enhancements...................................8
8. Security Considerations.........................................8
9. References......................................................8
Authors' Addresses.................................................8
Intellectual Property Statement....................................9
Disclaimer of Validity.............................................9
Full Copyright Statement...........................................9
Acknowledgment.....................................................9
1. Introduction
In cellular and wireless networks, handover decision can benefit from
DNA information that is available for each link layer. Proactive
handover decision reduces the packet loss during handovers. This
draft describes a method that considers the aforementioned DNA
information that is indicative of the status of any underlying link
layer to determine when a handover should be forced.
Due to the wide range of wireless technologies such as WLAN, GPRS,
and UMTS, a mobile node will have multiple interfaces to include such
systems for seamless mobility support. However, seamless handovers
have to be forced defined by system or user requirements and mainly
based on the available bearer information, e.g., link layer
information. Link layer information can be derived by DNA and allow
the control of handover for seamless mobility support, e.g., for
Mobile IPv6. Especially for vertical handover in overlay networks,
e.g., handover between WLAN hot spots and cellular systems, a
handover decision based on DNA consideration is required. Hence, this
draft includes a problem analysis and describes a policy for handover
decisions for mobile terminals with different link layers.
2. Conventions used in this document
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 [1].
IPonAir Expires August 25, 2005 [Page 2]
Internet-Draft POLIMAND February 2005
3. Terminology
This document uses the following terms:
Home Agent (HA)
As defined in [2].
Correspondent Node (CN)
As defined in [2].
Mobile Node (MN)
As defined in [2].
Neighbor Discovery (ND)
As defined in [3].
Neighbor Unreachablility Detection
As defined in [3].
Router Advertisement (RA)
As defined in [3].
Router
As defined in [4].
Host
As defined in [4].
Link
As defined in [4].
Address
As defined in [4].
Stateful/Stateless IPv6 Address Autoconfiguration
As described in [4].
4. Seamless Handovers in Wireless Networks û Problem Overview
Seamless handovers in heterogeneous wireless networks are mainly
based on movement detection that forces handovers from the previous
network to the new network. Movement detection in Mobile IPv6 uses
agent advertisements [2] that are used by mobile nodes to detect
whether an access network is reachable for data transmission or not.
The statements in [2] have to be considered to determine whether the
movement detection is appropriate for seamless handovers in
heterogeneous and overlay networks. The conclusion is that generic
movement detection is not suitable to support seamless handovers with
a reduction of packet loss during handovers. In [2] it is described
how often the router advertisements have to be broadcasted by access
routers to support movement detection in heterogeneous networks, so-
called unsolicited router advertisements.
Movement detection which is described in [2] is based on Neighbor
Discovery/Neighbor Unreachability Detection [3] and on router
advertisements which are frequently broadcasted by the access
routers. Movement detection which is based on Neighbor Unreachability
Detection is not appropriate for seamless mobility due to the fact
IPonAir Expires August 25, 2005 [Page 3]
Internet-Draft POLIMAND February 2005
that the previous link breaks before the handover is performed. This
causes too long service disruptions, because the Neighbor
Unreachability Detection detects that the link cannot be used for
further communication only after the previous link breaks.
It has to be understood that all statements in [2] and [3] describe
movement detection and neighbor unreachability detection after the
previous link breaks. However, a decision how to trigger a Mobile
IPv6 handover between access networks or interfaces is not defined in
[2]. Handover decision that is defined in the following is based on
L2 information that is derived from DNA policies. The following
describes how the handover decision can be enhanced by using so-
called proactive handovers in heterogeneous networks without major
changes to the mobility protocols.
In fig.1 a mobility scenario is described which is the basis for the
assumptions within this draft. Although there are only two different
access routers (AR) described in fig.1, the mobile node (MN) includes
different wireless interfaces for current and future wireless bearer
technologies. The mobile node is able to force horizontal handovers
within the same bearer technology and vertical handovers in overlay
networks.
+-----+
+--+ | | +--+
|CN|------|Inter|------|HA|
+--+ | net | +--+
--------| |--------
| +-----+ |
previous | | new
network | * * | network
| * * |
+-------+ * * +-------+
| AR(n) | ** |AR(n+1)|
+-------+ ** +-------+
. ** .
Link(n) . * * . Link(n+1)
+--+ * * +--+
|MN| ==*======*=> |MN|
+--+ *movement* +--+
AR(n) coverage * * AR(n+1) coverage
area * * area
* * * * * * * * * *
Figure 1: Handover scenario from Link(n) to Link (n+1).
5. Reactive/Proactive Handover Decision
There are two different handover decisions which have to be
considered for the design of seamless and lossless handovers,
reactive and proactive handover decision. The reactive handover
provides an active link connection to the previous access network
until the previous link breaks. Afterwards it establishes an active
link to the new access network.
For the proactive handover the mobile node has an active link
connection to the new access network before the link breaks and
maintains the previous link even when the handover from the previous
IPonAir Expires August 25, 2005 [Page 4]
Internet-Draft POLIMAND February 2005
access network to the new access network has been established. In
that case the handover can be established before the previous link
breaks. The proactive handover from one access network to another may
be forced due to DNA assumptions which are based on link layer
information about the link conditions. A list of link layer
parameters which are available in different bearer systems is given
in [5].
In the following the reactive handover decision and the proactive
handover decision are described to show the advantages on the
proactive handover decision to reduce packet loss during Mobile IPv6
handovers.
5.1 Reactive Handover Decision
In fig.2 the mobile node roams between (n) different access networks.
Link(n) is the connection to the router in network(n) and Link(n+1)
is the connection to the router in network(n+1). While Link(n) is
permanently reachable, Link(n+1) changes its link characteristics
(good/bad link layer conditions). When the previous link breaks due
to bad conditions, the mobile node starts the stateful/stateless IPv6
address autoconfiguration [4] to the new link. After successful
address configuration the new IPv6 address is used by the mobile node
for data transmission via the new link.
The handover duration between the previous link and the new link is
named as link disruption. Link disruption is the reason for packet
loss during handovers between the previous network and the new
network. It should be reduced to minimize packet loss during Mobile
IPv6 handovers.
Active Link(n)
Link(n) |----------------------------------------------------
Active Link(n+1) Link(n+1) stale
| Link(n+1) |----------|----------|
| Good Bad
| Conditions Conditions Lifetime Addr. Link(n)
| expires config. active
| |--------|-------|-------------
| Handover Link
| Link(n+1)/Link(n) disruption
\|/ |----------------|
Figure 2: Handover from Link(n+1) to Link (n) based on a reactive
handover scenario.
In [6] a reactive handover design is described which is based on link
layer hints for L3 handovers after the previous link breaks. It
forces an IPv6 address autoconfiguration during the handover to the
new access router after the previous link is lost by the mobile node.
5.2 Proactive Handover Decision
For the proactive handover decision the mobile node has a link
connection to a new network before the link of the previous network
breaks (simultaneous use of wireless interfaces). Hence, the
proactive handover decision differs from the reactive scenario that
has no link connection during the handover.
IPonAir Expires August 25, 2005 [Page 5]
Internet-Draft POLIMAND February 2005
In fig. 3 the characteristic of Link(n+1) changes and a hint is used
to establish a handover. The hint contains information (e.g., L2
information and DNA considerations) about the link characteristic and
is used to control L3 handovers.
The hint triggers an anticipated IPv6 (stateful/stateless) address
configuration [4]. When the new IPv6 address is available and is used
by the mobile node (Link(n+1)), the handover is established and the
new link is used for data transmission.
Active Link(n)
Link(n) |----------------------------------------------------
Active Link(n+1) Link(n+1) stale
| Link(n+1) |----------|----------|
| Good Bad
| Conditions|Conditions
| |
| Link(n+1) Hint |Lifetime Addr. Link(n)
| \|/expires config. active
| |--------|-------|------------------------
| Hanover Link
| Link(n+1)/Link(n) disruption
\|/ |-----|
Figure 3: Handover from Link(n+1) to Link(n) based on a proactive
handover scenario.
The proactive handover decision reduces link disruption to a minimum
because a new link will be established for ongoing data transmission
while the previous link is still in use. It reduces the packet loss
during handovers and supports anticipated handover scenarios.
6. Link Layer Information
There are different bearer systems available which provide different
link layer information. Different bearer systems like IEEE
802.11a/b/g, hiperLAN2, GSM, GPRS and UMTS are currently available
and are used in IP networks. These bearer systems use various link
layers with different types of link layer information.
Different link layer information requires a generic platform which
combines link layer information from different link layer systems.
However, a list of different link layer parameters from various
network systems is required that simplifies the control of L3
handovers between different access networks. A detailed list of
different link layer parameters is given in [5].
7. Handover Policy
This draft proposes a so-called Handover Policy Decision Function. It
is a proactive and seamless handover decision method, which is the
basis for less or zero packet loss during vertical handovers in
heterogeneous overlay networks. This method forces L3 handovers
before the previous link breaks based on a policy. The policy based
handover has the advantage of using a more suitable link instead of
the previous link, which may not provide adequate link conditions or
may be stale. It minimizes packet loss and provides seamless and
reliable link connectivity of the mobile node during movements.
IPonAir Expires August 25, 2005 [Page 6]
Internet-Draft POLIMAND February 2005
The Handover Policy Decision Function uses L2 information to decide
if there is a handover required from the previous network to a new
network. Fig. 4 shows the control of L3 handovers based on link layer
information and considers DNA assumptions.
+--------------------------------------------+
| Network Layer |
+--------------------------------------------+
| Handover Policy Decision Function |
+--------------+--------------+--------------+
| Link Layer 1 | Link Layer 2 | Link Layer n |
| L2/DNA | L2/DNA | L2/DNA |
| WLAN 802.11x | 2,2.5,3G | 3G Beyond |
+--------------+--------------+--------------+
Figure 4: Interaction of the Handover Policy Decision Function
between different link layers and the network layer
7.1 Handover Policy Decision Function
The Handover Policy Decision Function establishes L3 handovers from
the previous network to the new network when the link characteristic
is no longer adequate for data transmission. Hence, a policy is
required when the handover has to be forced. The policy should be
based on a combination of different link layer information to control
the handovers.
7.2 Definition of the Handover Policy Decision Function
In the following the Handover Policy Decision Function is defined. It
is a generic definition that includes assumptions about available and
future wireless link layer technologies.
Generic handover policy function:
Handover(a1*Link Layer 1, a2*Link Layer 2, ..., an*Link Layer n)
The Handover Policy Decision Function considers different link layer
technologies. Each link layer contains a number of different L2 hints
(matrix h) that is listed in [5]. Due to system or user requirements
the L2 information is differently weighted (matrix a).
Handover policy definition:
Link Layer 1= a11*h11 + a12*h12 + ...+ a1n*h1n
Link Layer 2= a21*h21 + a22*h22 + ...+ a2n*h2n
...
Link Layer n= am1*hm1 + am2*hm2 + ...+ amn*hmn
The handover decision is based on the policy definition and the link
layer characteristic. The characteristic of each link layer is
considered by the vector l. The policy of the handover definition is
used to select the target link layer from the available wireless
interfaces.
Handover policy:
IPonAir Expires August 25, 2005 [Page 7]
Internet-Draft POLIMAND February 2005
Target Link Layer = (l1*Link Layer 1 + l2*Link Layer 2 + , ..., +
ln*Link Layer n)
The target link layer is the new link layer at the mobile node. A
handover has to be forced from the previous link layer to the new
target link layer when the link layer characteristic has changed due
to policy considerations.
7.3 Handover Policy Enhancements
The Handover Policy Decision Function should be enhanced to consider
the functionality of other mobility protocols, e.g., Hierarchical
Mobile IPv6 [7] and Fast Mobile IPv6 [8]. HMIPv6 and FMIPv6 may use
the Handover Policy Decision Function to reduce link disruption and
to minimize packet loss during vertical handovers in heterogeneous
overlay networks.
8. Security Considerations
This document discusses considerations for handover decisions based
on DNA assumptions for multiple link layers. The associated security
issues will be discussed as future work.
9. References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, IETF, March 1997.
[2] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IP6. RFC
3775, June 2004.
[3] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP
Version 6 (IPv6). RFC 2461, December 1998.
[4] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration.
RFC 2462, December 1998.
[5] P. Bertin, T. Noel, N. Montavont. Parameters for Link Hints.
Internet Draft (work in progress), August 2003.
[6] S. D. Park, E. Njedjou, N. Montavont. L2 Triggers Optimized
Mobile IPv6 Vertical Handover. Internet Draft (work in
progress), January 2004.
[7] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier.
Hierarchical Mobile IPv6 Mobility Management (HMIPv6). Internet
Draft (work in progress), December 2004.
[8] R. Koodli. Fast Handovers for Mobile IPv6. Internet Draft (work
in progress), October 2004.
Authors' Addresses
Stefan Aust
Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen
D-28359 Bremen Phone: +49-421-218-8264
Germany Email: aust@comnets.uni-bremen.de
Carmelita Goerg
Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen
IPonAir Expires August 25, 2005 [Page 8]
Internet-Draft POLIMAND February 2005
28359 Bremen Phone: +49-421-218-2277
Germany Email: cg@comnets.uni-bremen.de
Cornel Pampu
Siemens AG
ICM N PG NT RC PN
Siemensdamm 62
D-13623 Berlin Phone: +49-30-386-20265
Germany Email: Cornel.Pampu@siemens.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify an such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein is provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY); THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE NAY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
This work was done within the framework of the IPonAir project which
is partly funded by the German Ministry of Education and Research
(BMB+F), http://www.iponair.de
IPonAir Expires August 25, 2005 [Page 9]
Internet-Draft POLIMAND February 2005
IPonAir Expires August 25, 2005 [Page 10]
Internet-Draft POLIMAND February 2005
