Mobile IP Working Group Karim El Malki
INTERNET-DRAFT Hesham Soliman
Expires: February 2002 Ericsson Radio Systems
July 2001
Simultaneous Bindings for Mobile IPv6 Fast Handoffs
<draft-elmalki-mobileip-bicasting-v6-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF.
Abstract
Fast Handover for Mobile IPv6 [Fastv6] describes a protocol to
minimise the amount of service disruption when performing layer-3
handoffs. This draft extends this protocol by adding the simultaneous
bindings functionality as a handoff smoothing technique. Traffic for
the MN is therefore bicast or n-cast for a short period to its
current location and to one or more locations where the MN is
expected to move to shortly. This removes the timing ambiguity
regarding when to start sending traffic for the MN to its new point
of attachment and allows the decoupling of layer-2 and layer-3
handoffs. It also saves the MN periods of service disruption in the
case of ping-pong movement.
El Malki and Soliman [Page 1]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
TABLE OF CONTENTS
1. Introduction.....................................................2
1.1 Terminology.....................................................2
2. Simultaneous Bindings............................................3
3. Fast Handovers in Mobile IPv6....................................4
4. Decoupling L3 Handoffs from L2 handoffs using Simultaneous
Bindings ...........................................................5
5. Avoiding service disruption due to ping-pong movement............6
6. Operation........................................................6
6.1 MN Operation....................................................6
6.1 HA/MAP and CN Operation.........................................7
7. Simultaneous Bindings Flag in Fast Binding Update (F-BU) message.7
8. Simultaneous Bindings suboption for Fast Binding Acknowledgement
(F-BACK) message....................................................8
9. Multiple copies of packets received at AR........................8
10. References......................................................9
11. Authors' Addresses..............................................9
12. Full Copyright Statement.......................................10
1. Introduction
Fast Handover for Mobile IPv6 [Fastv6] describes a protocol to
minimise the amount of service disruption when performing layer-3
handoffs. This draft extends this protocol by adding the simultaneous
bindings functionality as a handoff smoothing technique. Traffic for
the MN is therefore bicast or n-cast for a short period to its
current location and to one or more locations where the MN is
expected to move to shortly. This removes the timing ambiguity
regarding when to start sending traffic for the MN to its new point
of attachment and allows the decoupling of layer-2 and layer-3
handoffs. It also saves the MN periods of service disruption in the
case of ping-pong movement.
1.1 Terminology
This section presents a few terms used throughout the document,
applied from [Fastv4].
El Malki and Soliman [Page 2]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
oAR _ old Access Router.
nAR - new Access Router.
L2 handoff - Movement of a MN's point of Layer 2 (L2)
connection from one wireless access point to another.
L3 handoff - Movement of the FA handling a MN's care of address
at Layer 3 (L3) from oAR to nAR.
L2 trigger - Information from L2 that informs L3 of particular
events before and after L2 handoff. The descriptions of L2
triggers in this document are not specific to any particular
L2, but rather represent generalizations of L2 information
available from a wide variety of L2 protocols.
Bicasting/n-casting - The splitting of a stream of packets
destined for a MN via its current AR (the oAR) into two or
more streams, and the simultaneous transmission of the
streams to oAR and one or more nAR. Bicasting is a handoff
smoothing technique used to reduce packet loss during
handover.
ping-ponging - Rapid back and forth movement between two
wireless access points due to failure of L2 handoff. Ping-
ponging can occur if radio conditions for both the old and
new access points are about equivalent and less than optimal
for establishing a good, low error L2 connection.
2. Simultaneous Bindings
Simultaneous bindings are built into the Mobile IPv4 protocol
[MIPv4]. To enable multiple simultaneous bindings using Mobile IPv4
the MN simply sends a first normal Registration Request for a care-of
address and then send other Registration messages for another set of
care-of addresses having the `S' bit set. The receiver of the
Registration Requests, the HA or GFA, will then maintain all these
care-of address bindings for the MN contemporarily rather than only
servicing the MN at the care-of address in its most recent
Registration Request, which would be the case had the `S' bit not
been set. This results in bicasting or n-casting of packets to all
the care-f addresses. This draft extends the Mobile IPv6 protocol
[MIPv6] with similar functionality and describes a new Simultaneous
Bindings flag for the Fast Binding Update [Fastv6].
Multiple simultaneous bindings can be an important tool to decouple
L3 handoffs from L2 handoffs and to reduce packet loss. This
mechanism instructs the recipient of the BU with the simultaneous
bindings flag, the HA, MAP [HMIPv6] or AR to make multiple copies of
El Malki and Soliman [Page 3]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
packets destined to the MN and send them to multiple potential future
MN locations (care-of addresses) before the MN actually moves there.
This allows a smoothing of the L3 handoff, in that packet loss is
minimised or even eliminated. Simultaneous bindings and bicasting are
also useful to support ping-ponging as described later.
3. Fast Handovers in Mobile IPv6
The mechanism to obtain fast L3 handoffs for Mobile IPv6 is described
in [Fastv6]. This mechanism involves the use of L2 triggers which
allow the L3 handoff to be anticipated rather than being performed
after the L2 handoff completion as normal. Fast Handoffs are required
to ensure that the layer 3 (Mobile IP) handoff delay is minimised,
thus also minimising and possibly eliminating the period of service
disruption which normally occurs when a MN moves between two ARs.
This period of service disruption usually occurs due to the time
required by the MN to update its HA after it moves between ARs.
During this time period the MN cannot resume or continue
communications. Following is a short summary of the Fast Handover
mechanism described in [Fastv6].
While the MN is connected to its old Access Router (oAR) and is about
to move to a new Access Router (nAR), the Fast Handoffs in Mobile
IPv6 requires:
- the MN to obtain a new care-of address at the nAR while connected
to the oAR the MN to send a BU to its old anchor point (e.g. oAR) to
update its binding cache with the MN's new care-of address.
- the old anchor point (e.g. oAR) to start forwarding packets
destined for the MN to nAR.
+-----------+ 1a. HI +-----+
| | ---------------->| nAR |
| oAR | 1b. HAck | |
+-----------+ <----------------+-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement
Figure 1 _ Fast MIPv6 Handover Protocol
El Malki and Soliman [Page 4]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
The MN or oAR may initiate the Fast Handoff procedure by using
wireless link-layer information or link-layer _triggers_ which inform
that the MN will soon be handed off between two wireless access
points respectively attached to oAR and nAR. If the _trigger_ is
received at the MN, the MN will initiate the layer-3 handoff process
by sending a Proxy Router Solicitation message to oAR. Instead if the
_trigger_ is received at oAR then it will transmit a Proxy Router
Advertisement to the approproate MN, without the need for
solicitations.
The MN obtains a new care-of address while connected to oAR by means
of router advertisements containing information from the nAR (Proxy
Router Advertisement, PrRtAdv, which may be sent due to a Proxy
Router Solicitation, RtSolPr). The oAR will validate the MN's new
COA by sending a Handoff Initiate (HI) message to the nAR. Based on
the response generated in the Handoff Acknowledge (HAck) message, the
oAR will either generate a tunnel to the MN's new COA (if the address
was valid) or generate a tunnel to the nAR's address (if the address
was already in use on the new subnet). If the address was already in
use on the new subnet, the nAR will generate a host route for the MN
using its old COA. The new COA sent in the HI message is formed by
appending the MN's _current_ interface identifier to the nAR's
prefix. Note that the HI/HAck exchange is decoupled from the handoff
procedure and should be performed in advance so as not to add latency
to the protocol exchange.
This mechanism allows the anticipation of the layer 3 handoff such
that data traffic can be redirected to the MN's new location before
it moves there. However it is not easy to determine the correct time
to start forwarding between oAR and nAR, which has an impact on how
smooth the handoff will be. Packet loss will occur if this is
performed too late or too early with respect to the time in which the
MN detaches from oAR and attaches to nAR. Also, some measure is
needed to support the case in which the MN moves quickly back-and-
forth between ARs (ping-pong). Simultaneous bindings provides a
solution to these issues as described in the following sections.
4. Decoupling L3 Handoffs from L2 handoffs using Simultaneous Bindings
In many wireless networks it is not possible to know exactly when a
MN has detached from the wireless link to oAR and has attached to the
one connected to nAR. Therefore determining the time when to start
forwarding packets between oAR and nAR is not possible. Certain
wireless technologies involve layer-2 messages which instruct the MN
to handoff immediately or simply identify that the MN has
detached/attached. However even if the ARs could extract this
information, there would not be sufficient time for the oAR to detect
the MN's detachment and start getting packets tunnelled over to nAR
before the MN attaches to nAR. This is because wireless layer-2
handoff times are quite small (i.e. range from 10's to 100's ms).
El Malki and Soliman [Page 5]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
Thus a period of service disruption is most probable due to this
timing uncertainty unless further enhancements are made to the
handoff mechanism. If the L3 handoff is anticipated and the oAR
starts forwarding data to nAR upon receipt of the Fast BU, then the
period of service disruption will be according to the following:
A = L3 handoff anticipation
h = L2 handoff time
Approximate period before MN receives packets again = A + h
It is therefore necessary to decouple layer-3 handoff timing from
layer-2 handoff timing. One solution is to bicast or n-cast packets
destined to the MN for a short period from the old anchor point (e.g.
oAR) to one or more potential future MN locations (e.g. nAR/s) before
the MN actually moves there. This means that the handoff procedure
described previously would be enhanced by having the old anchor point
(e.g. oAR) send one copy of packets to the MN's old on-link care-of
address and another copy of the packets to the MN's new care-of
address (or addresses) connected to nAR. The MN is thus able to
receive traffic independently of the exact layer-2 handoff timing
during the handoff period.
5. Avoiding service disruption due to ping-pong movement
It is possible that the layer-2 handoff procedure may fail or
terminate abruptly in wireless systems. Therefore a MN which expects
to move between oAR and nAR may unexpectedly never complete the
layer-2 handoff and find itself connected to oAR. Another undesired
effect is that the MN could ping-pong between ARs due to layer-2
mobility issues. Both these cases would leave the MN unable to resume
communication and have to transmit a new BU before resuming
communications.
This may be solved through the use of simultaneous bindings which
allow the MN to maintain layer-3 connectivity with the oAR during the
affected handoff period, thus smoothing the handoff. This eliminates
the need for continuous transmission of Binding Updates and foregoes
the possibility that the period of service disruption be extended due
to the effect of the above link-layer issues on L3 handoff.
6. Operation
6.1 MN Operation
The MN operation will be the same as for [fastv6] but with the
difference that all Fast Binding Updates (F-BUs) will have the
Simultaneous Bindings flag set (_B_ flag). This is described in
section 7. In addition the MN should be able to process the new
El Malki and Soliman [Page 6]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
simultaneous bindings suboption in the Fast Binding Acknowledgement
message described in section 8. The lifetime field returned in this
suboption MUST be used by the MN to identify the lifetime of the
simultaneous binding requested. Two BU lifetime values will be
returned: Bicasting lifetime (in the simultaneous bindings suboption)
and new CoA lifetime (in the BA option) as described in the following
sections. The new CoA lifetime (placed in the BA option as specified
in MIPv6) starts after the Bicasting lifetime ends. Hence, when the
bicasting lifetime ends, the MN will remove this entry from the
Binding Update list and simply keep one entry for the new CoA with
the lifetime returned from the HA/MAP/AR.
6.1 HA/MAP/AR Operation
The HA [MIPv6], MAP [HMIPv6] and AR [Fastv6] are the possible
recipients of a F-BU message. Upon receiving a F-BU message having
the _B_ flag set (see section 7), the HA/MAP should create a new
binding cache sub-entry (linked to the original entry for the old
CoA) for the MN's new CoA in the alternate-CoA suboption. This entry
MUST not replace any existing entries for the MN. The new entry will
have two lifetimes: normal BU lifetime (sent in the BA) and a
Bicasting lifetime equal to SHORT_BINDING_LIFETIME. When the
SHORT_BINDING_LIFETIME expires, the MAP/HA/AR MUST replace it with
the lifetime for the new CoA sent in the BA and remove the old entry
for the old CoA. As a result, the HA/MAP/AR will end up with one
entry for the MN's CoA.
The default value for SHORT_BINDING_LIFETIME is 2s. This parameter
MUST be configurable as it my vary depending on the type of radio
link in the system.
7. Simultaneous Bindings Flag in Fast Binding Update (F-BU) message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv |B|Rsv| Prefix Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Description of extension to the F-BU option:
B When set indicates a request for bicasting all
packets to both COAs of the MN (in the source
address field and the alternate-CoA suboption).
El Malki and Soliman [Page 7]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
This BU will add another COA to the Binding
Cache.
8. Simultaneous Bindings suboption for Fast Binding Acknowledgement
(F-BA) message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type TBD
Sub-Option Len
Lifetime The short (bicasting) lifetime for the
simultaneous binding requested in the
F-BU.
Status Indicates success (0) or failure (128
and above).
9. Multiple copies of packets received at AR
If the MN has simultaneous active bindings with HA/MAP/AR, it could
(but preferably should not) receive multiple copies of the same
traffic directed to it. The use of simultaneous bindings does not
mean that the MN is receiving packets contemporarily from multiple
sources. This depends on the characteristics of the access (L2)
technology. The bicasting of packets involves sending a copy of the
data to the AR which the MN is moving to (the nAR). Until the MN
actually completes the L2 handoff to the nAR and fully establishes
the new L2 link, the nAR MAY receive packets for a MN to which it
does not have a direct link layer connection. If the new AR is aware
that the MN is performing a handover (due to earlier reception of the
HI message) The AR MAY:
- drop all packets for the MN, or
- buffer packets for the MN.
The choice of which action to take may depend on the type of traffic
involved, but this is outside the scope of this document. The AR MAY
also in parallel attempt to establish a link-layer connection with
the MN. However an AR MUST NOT send ICMP Destination Unreachable
messages if it drops packets or is unable to deliver the received IP
El Malki and Soliman [Page 8]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
packets due to unavailability of direct layer connection with the MN.
This is because the MN will be receiving one copy of the packets.
10. Reception of multiple copies in the MN
In some rare scenarios it may be possible that the MN receives more
than one copy of the same packet. Generally the Internet routing
mechanisms can not guarantee a delivery of a single copy of an IP
packet to a node. However some TCP congestion avoidance
implementations are known to react negatively to the reception of 3
duplicate acknowledgements. The algorithm in [Eifel] addresses this
problem. When using [Eifel] bicasting should not cause any negative
performance impacts for TCP.
11. References
[HMIPv6] H. Soliman, C. Castelluccia, K. ElMalki and L. Bellier,
_Hierarchical MIPv6 mobility management_, draft-ietf-mobileip-hmipv6-
03.txt, work in progress, February 2001.
[MIPv6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-
ietf-mobileip-ipv6-13.txt, work in progress, February 2000.
[Fastv6] G. Tsirtsis (Editor) et al, _Fast Handovers for Mobile
IPv6_, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April
2001.
[Fastv4] K. El Malki (Editor) et al, _Low latency Handoffs in Mobile
IPv4_, draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt, work in
progress, May 2001.
[MIPv4] C. Perkins (Editor), _IP Mobility Support_, RFC2002, October
1996.
[Eifel] R. Ludwig, _The Eifel algorithm for TCP_,
draft-ietf-tsvwg-tcp-eifel-alg-01.txt, work in progress.
12. Authors' Addresses
The authors may be contacted at the addresses below:
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
El Malki and Soliman [Page 9]
INTERNET-DRAFT Simultaneous Bindings for MIPv6 Fast Handovers May 2001
Hesham Soliman
Ericsson Radio Systems
Torshamnsgatan 29, Kista
Stockholm
SWEDEN
Phone: +46 8 7578162
Fax: +46 8 4043630
E-mail: Hesham.Soliman@era.ericsson.se
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Megisto Systems Inc.
6000 Connection Drive EMail: proberts@megisto.com
Irving, TX 75039
USA
Phone: +1 972-894-6709
EMail: Raj.Patil@nokia.com
Fax : +1 972-894-5349
13. 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 anyway, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided onan
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
El Malki and Soliman [Page 10]