One document matched: draft-blume-netlmm-secondary-bce-proxymip6ho-00.txt
NetLMM Working Group O. Blume
Internet-Draft R. Sigle
Expires: Aug 21, 2008 Alcatel-Lucent Bell Labs
February 18, 2008
Secondary Binding Cache entries for Proxy MIPv6
draft-blume-netlmm-secondary-bce-proxymip6ho-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Aug 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Blume & Sigle Expires Aug 21, 2008 [Page 1]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
Abstract
The IETF is specifying Proxy Mobile IPv6 for network-based localized
mobility management, which takes basic operation for registration,
tunnel management and de-registration into account in a first
protocol release. This document proposes an extension to Proxy
Mobile IPv6 to suit MNs, which have multiple network interfaces
implemented and can be connected over more than one network interface
at the same time.
This extension introduces a secondary binding at the local Mobility
Anchor (LMA) that is valid for receiving uplink packets but is not
used for tunneling downlink packets towards the MN. This allows for
preparation of the new binding while avoiding that the LMA will
prematurely forward data packets to the mobile node's new interface
before the address configuration of this interface has completed.
Furthermore, secondary bindings can be used to avoid loss of delayed
packets arriving at the LMA after the Binding Cache has been updated
by a Proxy Binding Update from a new MAG.
With the proposed extension, packet buffering at the new MAG is not
necessary and packet losses during an inter-technology handover can
be mitigated.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Functional Components . . . . . . . . . . . . 5
4. Problem Statement and Solution . . . . . . . . . . . . . . . . 6
4.1. Secondary Binding Cache entries during PMIP handoff . . . . 8
4.2. State diagamm with Secondary Binding Cache entries in PMIP 10
4.3. Usage of Secondary Binding Cache entries in client MIP . . 12
5. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Protocol Extension for signalling of MBB handoff capability 13
5.2. Protocol Extension for Secondary Binding Cache Entries . . 14
5.3 Protocol Extension for the MN . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Normative References . . . . . . . . . . . . . . . . . . . .19
9.2 Informative References . . . . . . . . . . . . . . . . . . .19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Blume & Sigle Expires Aug 21, 2008 [Page 2]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
1. Requirements notation
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 [RFC2119].
Blume & Sigle Expires Aug 21, 2008 [Page 3]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
2. Introduction
The IETF NetLMM WG is specifying Proxy Mobile IPv6
[I-D.ietf-netlmm-proxymip6] for network-based localized mobility
management, which takes basic operation for registration, tunnel
management and de-registration into account in a first protocol
release. This document proposes an extension to Proxy Mobile IPv6 to
suit MNs, which have multiple network interfaces implemented and can
be connected over more than one network interface at the same time.
Such parallel use of interfaces allows for reduction of handoff
delay and packet loss during handoff across network interfaces.
As for Proxy Mobile IP the MN is not involved in the IP mobility
signalling, a timing issue between MN and LMA prevents taking full
benefit of the parallel interfaces, as discussed in the following.
For inter-technology handover, the mobile node needs to perform
address configuration for the new interface. For IPv6, the mobile
node needs to wait for a Router Advertisement and to perform
duplicate address detection. During this time, the mobile node's new
interface is not yet ready to receive data packets, while the
previous interface is still able to send and receive data. If the LMA
decides to forward data packets for the mobile node via the new MAG,
packet losses can occur.
This extension introduces a "secondary binding" at the local Mobility
Anchor (LMA) that is valid for receiving uplink packets but is not
used for tunneling downlink packets towards the MN. This allows for
preparation of the new binding while avoiding that the LMA will
prematurely forward data packets to the mobile node's new interface
before the address configuration of this interface has completed.
Furthermore, secondary bindings can be used to avoid loss of delayed
packets arriving at the LMA after the Binding Cache has been updated
by a Proxy Binding Update from a new MAG. With the proposed
extension, it is not necessary that the MN is aware of the point in
time, when the Binding Cache entry is updated at the LMA, but still
packet buffering at the new MAG is not necessary and packet losses
during an inter-technology handover can be mitigated.
This document is based on an previous document submitted to 3GPP SA2
working group [1], which described a use case for secondary bindings
during handoff between an interface with client based Mobile IPv6
bindings and an interface applying Proxy Mobile IPv6 bindings. A
similar proposal has been described in an Internet Draft [2], where
the secondary bindings are denomimated as "preliminary bindings". In
that draft secondary bindings where not used after the Proxy Binding
Update and it was not discussed how to discriminate multi-homing from
intertechnology handoff between interfaces with simultaneous
transmission capability.
Blume & Sigle Expires Aug 21, 2008 [Page 4]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
3. Terminology and Functional Components
o MAG - Mobility Access Gateway. PMIPv6 functional component
defined in [I-D.ietf-netlmm-proxymip6]. The MAG function is
assumed to be located on the PMIPv6 domain's access routers.
o LMA - Local Mobility Anchor. PMIPv6 functional component defined
in [I-D.ietf-netlmm-proxymip6].
o pAR - Previous Access Router. Equivalent to current access
router. In a layer 3 handover situation, the access router which
the mobile node is leaving from.
o nAR - New Access Router. Equivalent to handover target access
router. In a layer 3 handover situation, the access router
towards which the mobile node is moving to.
o pMAG - previous MAG. In a layer 3 handover situation, the MAG
function located on the previous access router
o nMAG - new MAG. In a layer 3 handover situation, the MAG function
located on the new access router.
o IF - Interface. Any network interface, which offers an MN
wireless or wired access to the network infrastructure. In case
an MN has multiple interfaces implemented, they are numbered (IF1,
IF2, ...)
o Inter-RAT handover. Handover between different radio access
technologies.
o BBM - Break-Before-Break. In a BBM-handover sequence the radio
and IP connectivity to the nMAG can only be estabished after the
connectivity to the pMAG is released. This requires only oeration
of one interface at any time, but causes significant interruption
during handoff performance.
o MBB - Make-Before-Break. In a MBB-handover sequence the radio
and IP connectivity to the nMAG are estabished while the
connectivity to the pMAG is still maintained. This allows for
seamless handoff performance but requires the capability of the MN
to operate two radio links simultaneously.
Blume & Sigle Expires Aug 21, 2008 [Page 5]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
4. Problem Statement and Solution
Traditional radio mobility schemes only support radio layer mobility
between base stations or access points within the same IP access
network. IP mobility protocols based on MIPv4 or MIPv6 also allow to
handoff an IP session to another L2 access technology. If
the mobile node supports only the operation of a single radio
interface the old IP and radio connection has to be torn down before
setup of the new radio connection and an interruption time is
inevitable (break-before-make handoff). But for mobile nodes
supporting simultaneous radio transmission the handover sequence can
be optimised by using multiple Care of Addresses to maintain
communication seamlessly and losslessly throughout the handoff
procedure (make-before-break handoff). In the ideal case, radio and
IP connectivity are fully established and the impact of handoff
execution is minimised to the change of the Binding Cache entry at
the HA respectively the localised mobility agent (LMA).
In client based mobility protocols the handoff sequence is fully
controlled by the mobile node and the mobile node updates the binding
update after IP connectivity has been established on the new link. On
the contrary, Proxy Mobile IP aims to relieve the mobile node from
the L3 mobility signalling, while the mobile node is still
controlling the changing of the L2 configuration. This introduces a
problem for HO optimisations using simultaneous radio transmission:
According to the PMIP protocol [I-D.ietf-netlmm-proxymip6], the
Access Authentication and the Proxy BU are triggered in the access
network by the radio attach procedure, transparently for the MN. For
a mobile node with simultaneous radio transmission this PMIP BU will
disrupt the ability of the MN to communicate on the other interface
during the IP configuration of the new interface.
Figure 1 shows the interruption time that occurs in a PMIP handoff
between interfaces with simultaneous radio capability. After the
attachment of IF2 to the nMAG the LMA updates the Binding Cache and
downlink packages will be inserted into the tunnel towards the nMAG.
These packets can not be transmitted to the mobile node until it has
finalised address configuration with Neighbourhood Advertisment to
the nMAG. Depending on the RAT type, this may involve multiple
roundtrips of signalling for configuration of the link. Even if the
nMAG buffers the downlink packages until then there will be a
perceivable delay in the packet flow. On the other hand, uplink
packets the mobile node still sends on IF1 (not shown in figure 1)
towards the pMAG will be rejected at the LMA because the binding has
been replaced by the new binding with a different CoA.
Blume & Sigle Expires Aug 21, 2008 [Page 6]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
Delaying the PBU of the nMAG to the LMA may seem to be a way to avoid
the interruption of IP connectivity. In many cases the nMAG will be
aware of the finalisation of IP connectivity in the mobile node (e.g.
due to NAdv or 3GPP radio and S1 bearer setup complete message) and
the nMAG might delay the PBU until this point in time. However,
uplink packets from the new link on IF2 will get lost or need to be
buffered in the nMAG because the mobile node is unaware of the Proxy
Binding Update and may start sending IP packets to the nMAG before
the Proxy Binding Update is finalised. This could only be avoided by
signalling to the mobile node that the PBAck has been received at the
nMAG, but such signalling is in contradiction to the aim of PMIP not
to involve the mobile node in the mobility signalling.
+------+ +----+ +----+ +---+
| MN | |pMAG| |nMAG| |LMA|
+------+ +----+ +----+ +---+
IF2 IF1 | | |
| | | | |
| |- - - - - - - - - Attach | |
| | |---------------PBU--------------->|
| | |<--------------PBA----------------|
| |--------RtSol------->| | |
| |<-------RtAdv--------| | |
| Addr. | | |
| Conf. | | |
| |<===================>|<=================data===========>|--
| | | | |
|- - - - - - - - - - - - - - - - - Attach |
| | | |----------PBU-------->|
+--- | | | |<---------PBA---------|
| |------RAT configuration--------------| |
| | | |<=====data============|--
| | | | | |
IP | | | |<=====data============|--
inter- | | | | |
rupted |-----------RtSol(optional)---------->|<=====data============|--
| |<----------RtAdv---------------------| |
| Addr. | | |<=====data============|--
| Conf. | | | |
+--- | | | | |
|<===================================>|<=====data===========>|--
| | | | |
| |- - - - - - - - - Detach | |
| | |---------------PBU(lifetime 0)--->|
| | |<--------------PBA----------------|
| | | | |
Figure 1: Inter-RAT HO interruption during PMIP handoff
Blume & Sigle Expires Aug 21, 2008 [Page 7]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
4.1. Secondary Binding Cache entries during PMIP handoff
Therefore, as an optimisation for simultaneous radio handoffs this
internet draft proposes a separation of the updating of the Binding
Cache entry for uplink and downlink traffic. The change of the
Binding Cache at the LMA is split into two steps before and after
the setup of radio and IP connectivity between mobile node and nMAG.
On the one hand, the LMA shall be able to accept uplink packets of
the mobile node as soon as the mobile node has finalised address
configuration and may start using the new IF2 for data traffic, i.e.
the Proxy BU for the uplink shall be done before the radio setup
procedure is finalised, as shown in figure 1. But, to allow the
mobile to keep sending its data traffic on IF1 during the handover,
UL packets with the previously existing binding on IF1 shall still
be accepted by the LMA until the mobile node detaches IF1. This is
important because the Proxy BU is transparent to the mobile node,
i.e. the mobile node does not know when the BU has been performed.
On the other hand, the switching of the downlink packets shall be
performed at the LMA only after completion of the IP connectivity
between mobile node and nMAG. How long this takes depends on the
duration of target system radio layer protocols and this is
transparent to the LMA. Thus, a second message to the LMA is
required for the activation of the binding for the downlink traffic.
Up to then, downlink packets are still routed into the previous
tunnel to IF1, to avoid downlink packet loss or buffering in nMAG.
As shown in figure 2, this is perceived by double signalling of the
PBU from the nMAG to the LMA signalling. First a secondary PBU is
indicated, used only for uplink traffic until a further PBU is
requesting the switching of downlink traffic into the new PMIP
tunnel. During this period it is up to the MN when to start using
IF2 for uplink data.
This handover sequence is only useful for handoff of mobile nodes
with the capability of using simultaneous radio connectivity. If
used for a single radio mobile node, the data sent to the pMAG
after the secondary Proxy Binding update will be lost due to
detachment of the radio link. (In some cases there may be additional
mechanisms in place to forward data to nMAG to avoid the loss, but
context transfer is required between pMAG and nMAG and still data is
unnecessary delayed by this routing.)
Only the MN can tell whether IF1 and IF2 are operated simultaneously:
The nMAG is not aware of the state of the link on IF1. While the LMA
does know about the binding of the link on IF1 it currently (section
5.4 of [I-D.ietf-netlmm-proxymip6]) cannot discriminate whether the
new attachment is due to the beginning of a multihoming session of
the MN or whether it is due to a simultaneous radio inter-RAT
handoff. Therefore, the handoff between interfaces shall be performed
as in figure 1, unless the mobile node indicates a simultaneous radio
handoff during attachment with the nMAG, as with the extensions
Blume & Sigle Expires Aug 21, 2008 [Page 8]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
described in section 5 of this internet draft. If the handoff type is
unknown (as specified in PMIP [I-D.ietf-netlmm-proxymip6]), the LMA
shall leave the binding of IF1 unchanged and assign a different home
network prefix to the nMAG for IF2.
+------+ +----+ +----+ +---+
| MN | |pMAG| |nMAG| |LMA|
+------+ +----+ +----+ +---+
IF2 IF1 | | |
| | | | |
| |- - - - - - - - - Attach | |
| | |---------------PBU--------------->|
| | |<--------------PBA----------------|
| |--------RtSol------->| | |
| |<-------RtAdv--------| | |
| Addr. | | |
| Conf. | | |
| |<====================|==================data===========>|--
| | | | |
|- - - - - - - - - - - - - - - - Attach (simultaneous radio) |
| | | |----PBU(secondary)--->|
| | | |<---PBA(secondary)----|
|------RAT configuration--------------| |
| |<====================|==================data===========>|--
| | | |
| |<====================|==================data===========>|--
| | | | |
|-----------RtSol(optional)---------->| |
|<----------RtAdv---------------------| |
Addr. | | | |
Conf |<====================|<=================data============|--
|====================================>|======data===========>|--
| | | | |
|--------optional Trigger ----------->| |
| | | |----------PBU-------->|
| | | |<---------PBA---------|
|<====================================|======data===========>|--
| | | | |
| |- - - - - - --- - Detach | |
| | |---------------PBU(lifetime 0)--->|
| | |<--------------PBA----------------|
| | | | |
Figure 2: PMIP for make-before-break handoff.
Blume & Sigle Expires Aug 21, 2008 [Page 9]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
The introduction of primary and secondary Binding Cache entries
allows for a further improvement of make-before-break handoff with
PMIP. During inter-RAT handoff the round trip time between mobile
node and LMA can change significantly. For example the round trip
time of 3GPP GSM is in the order of 150msec, while for IEEE WLAN it
is in the order of a few milliseconds. Packets on the fly on a slow
radio link may thus be overtaken by the handoff to a fast radio link
and can arrive hundreds of milliseconds after the PBU, as has been
experimentally verified [3]. As the binding chache entry has already
been updated, these packets are dropped (Fig. 3). Such packet loss
is avoided, if the second PBU in figure 2 does not delete the
previous binding of the link on IF1, but turns this binding into a
secondary binding, that is not used for downlink packets but allows
for accepting delayed uplink packets. The secondary binding can be
deleted after a timer runs out or when the pMAG signals detachment
of this link in a PBU with lifetime 0.
+------+ +----+ +---+
| MN | |nMAG| |LMA|
+------+ +----+ +---+
IF2 IF1 | |
| |\ | |
| | \ | |
|- -|- - - - \- - - - Attach |
| | s\ |---------PBU--------->|primary binding
| | l\ |<--------PBA----------|of IF2
| | o\ |
| | | w\ |
| | | d\ |
| | | a\ |
| | | t \ |packet still
| | | a ->|accepted due to
| | | |secondary binding
| | | |of IF1
| | | |
Figure 3: secondary binding for packets overtaken by PBU.
4.2. State diagamm with Secondary Binding Cache entries in PMIP
Figure 4 shows the state diagramm of the Binding Cache entries that
can exist in the LMA for one HNP of a MN with interfaces IF1 and IF2.
The upper part shows the states as specified in PMIP [I-D.ietf-
netlmm-proxymip6] with registration, BU refeshment, deregistration
and BBM-handoff.
Blume & Sigle Expires Aug 21, 2008 [Page 10]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
PBU(IF1,LT=0) +------------+ PBU(IF2,LT=0)
+---------->| |<-----------+
| | no entry | |
| +--------| |---------+ |
BU(IF1,HI=5) | | +------------+ | | PBU(IF2,HI=5)
+------+ | |PBU(IF1) PBU(IF2)| | +------+
| | | | | | | |
| v | v v | v |
| +----------------+ PBU(IF1,HI=2) +----------------+ |
| | |<-----------------------| | |
+--| IF1 (active) | <--BBM handoff--> | IF2 (active) |--+
| |----------------------->| |
+----------------+ PBU(IF2,HI=2) +----------------+
| ^ | ^
| | | |
| | | |
| | <--MBB handoff--> | |
| | | |
| | | |
PBU(IF2,HI=6) | |PBU(IF2,LT=0) PBU(IF1,HI=6)| |PBU(IF1,LT=0)
| | | |
v | v |
+----------------+ PBU(IF1,HI=2) +----------------+
| |<-----------------------| |
+--| IF1 (active) | | IF2 (active) |--+
| | IF2 (secondary)|----------------------->| IF1 (secondary)| |
| +----------------+ PBU(IF2,HI=2) +----------------+ |
| ^ ^ |
| | | |
+-----+ +-----+
PBU(IF1,HI=5) PBU(IF1,HI=5)
PBU(IF2,HI=5) PBU(IF2,HI=5)
Figure 4 State diagamm for Binding Cache entries of one HNP of a MN
The lower shows the two new states that occur during a MBB handoff.
If a MN with active binding of IF1 starts a MBB handoff to interface
IF2, nMAG requests a secondary binding request for IF2 (handoff
indicator is 6). After the IP configuration of IF2 is finalised, nMAG
requests in a subsequent binding request (with handoff indicator 2)
to turn the secondary binding for IF2 into an active binding, which
starts tunneling of DL packets to IF2. LMA simultaneously degrades
the binding of IF1 into a secondary binding, so that late UL-packets
from IF1 are still accepted. Finally, at the dissociation of IF1 pMAG
will send a PBU with lifetime 0 for IF1. The secondary binding for
IF1 is deleted. Now the MBB handoff is finalised, Binding Cache entry
is for IF2 and normal operation of PMIP is resumed.
Blume & Sigle Expires Aug 21, 2008 [Page 11]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
4.3. Usage of Secondary Binding Cache entries in client MIP
Secondary Binding Cache entries during radio setup can also be
applied for handoff from client MIP binding to PMIP binding. During
handoff from PMIP binding to client MIP binding secondary Binding
Cache entries are not required during IP address configuration,
because the mobile node is controlling the point in time when to
send the BU and obviously will only do so after IP connectivity on
IF2 is finalised.
Nevertheless, secondary Binding Cache entries would be useful in
client MIP for avoiding loss of packets overtaken by the BU. This
would require to allow for secondary bindings also in Mobile IPv6 HA
behaviour [RFC3775], without need of additional signalling between MN
and HA (deletion of secondary binding can be done after a timer runs
out or when a Binding Update with lifetime 0 for IF1 is received.)
Blume & Sigle Expires Aug 21, 2008 [Page 12]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
5. PMIPv6 Extensions
This section describes an extension to [I-D.ietf-netlmm-proxymip6] to
solve the problem of packet loss due to missing synchronisation
between MN and LMA, as resulting from the exclusion of the MN from
mobility signalling in Proxy Mobile IP. The key extension is to
introduce a secondary MN's Binding Cache entry that is not used for
tunneling packets to the MN.
Section 5.1 describes the extension for signalling between MAG and
LMA that a MBB handover shall be executed. Section 5.2. describes
Protocol Extension for Secondary Binding Cache Entries in the LMA.
Finally, section 5.3. names issues for the MN but Protocol
Extensions for the MN are out of scope of the current version of
this internet draft.
5.1. Protocol Extension for signalling of MBB handoff capability
When a PBU arrives at the LMA and there already exists a Binding
Cache entry for the MN identifier contained in the PBU, a handoff
procedure between interfaces needs to be executed at the LMA in
three cases (according to [I-D.ietf-netlmm-proxymip6]):
o if a NON_ZERO HNP value is present in the received proxy Binding
Update message and this value matches the HNP in an existing
Binding Cache Entry and the Handoff Indicator Option is set to
value 2 (Handoff between interfaces) (see 5.4.1.1. in [I-D.ietf-
netlmm-proxymip6]).
[PBU(HNP) == BCE(HNP) AND HI=2]
o if an ALL_ZERO HNP value is present in the received proxy
Binding Update message and if an interface ID is present in the
received proxy Binding Update message and there is no Binding
Cache entry for that interface identifier and there exists one
and only one currently active Binding Cache entry for the mobile
node, and the Handoff Indicator Option is set to value 2
(Handoff between interfaces) (see 5.4.1.2. in [I-D.ietf-
netlmm-proxymip6]).
[PBU(HNP) == ALL_ZERO AND PBU(IF-ID) != BCE(IF-ID) AND
exists_one_and_only_one(BCE) AND HI=2]
o if an ALL_ZERO HNP value is present in the received proxy
Binding Update message and if no interface ID is present in the
received proxy Binding Update message and and there exists one
and only one currently active Binding Cache entry for the mobile
node, and the Handoff Indicator Option is set to value 2
(Handoff between interfaces) (see 5.4.1.3. in [I-D.ietf-
netlmm-proxymip6]).
[PBU(HNP) == ALL_ZERO AND PBU(IF-ID) == ALL_ZERO AND
exists_one_and_only_one(BCE) AND HI=2]
Blume & Sigle Expires Aug 21, 2008 [Page 13]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
Neither of these signalling options implies the simultaneous usage of
the interfaces in the MN. Furthermore, this information cannot be
taken from policy store, because the MBB ability may depend on the
signal strength of the radio link between MN and pMAG and on the
battery state of the MN. Thus, a make-before-break-handoff seqence
acording to figure 2 MUST only be used if the MN has signalled in the
radio attachment that IF1 and IF2 are used simultaneously during the
handoff. Such MBB handoff hint requires according ammendments in the
RAT standardisation, e.g. this could be perceived in the 3GPP RRC
connection request [3GPP TS 25.331] as a new ESTABLISHMENT_CAUSE
"Inter-RAT cell change withMBB". As another example, an "MBB-
handoff"-reason code could be introduced into IEEE 802.11
MLME-associate.request (similar to the reason codes already used in
the MLME-dissociate.request, see section 7.3.1.7. in [IEEE802.11]).
When the MAG receives an attachment from a MN indicating a make-
before-break-handoff, it shall send a secondary Proxy Binding Update
request to the LMA. The secondary type of the Binding request could
be indicated in two ways:
o Assigning a new Indicator value in the Handoff Indicator Option
The mandatory Handoff Indicator Option (section 8.4 in [I-D.
ietf-netlmm-proxymip6] specifies the type of handoff. If IANA
assigns a new value for "Handoff between interfaces with
simultaneous operation" to the PMIP specification, this could be
set by the MAG to indicate the MN's decison for a Make-Before-
Break-handoff.
o Specification of a new flag in the PBU request
Alternatively a new "S"-Flag (simultaneous) could be specified
for the PBU request (in addition to the "P"-Flag specified in
section 8.1 in I-D.ietf-netlmm-proxymip6]). If the flag is set
to one, this indicates both Interfaces operate simultaneously
to perform a Make-before-Break-handoff execution.
As the indication is closely related to the Handoff Indicator the
former way is preferable to a flag in the PBU.
5.2. Protocol Extension for Secondary Binding Cache Entries
Upon accepting of a Proxy Binding Update request with the MBB-
indication of section 5.1 for a currently active binding entry the
LMA SHALL create a Secondary Binding Cache Entry:
o The LMA MUST create a binding chache entry for the new IF and
MUST create a tunnel to the new mobile access gateway, as
described in [RFC2473].
Blume & Sigle Expires Aug 21, 2008 [Page 14]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
o The LMA must assign the same HNP to this interface as is
assigned to the currently active Binding Cache entry.
o Instead of overwriting the previous Binding Cache entry and of
deleting its tunnel to the pMAG after MinDelayBeforeBCEDelete
wait period, the LMA SHALL keep the previous Binding Cache entry
and mark the new Binding Cache entry as secondary. The LMA SHALL
keep routing downlink traffic to the MN into the previously
existing (primary) tunnel. The LMA SHALL continue to de-
encapsulate and route the mobile nodes's uplink data traffic
that arrives from that tunnel.
o LMA MUST send a Proxy Binding Update Acknowledgement to the nMAG
with the new Handoff Indicator value in the Handoff Indicator
Option. From this nMAG learns that a secondary Binding Cache
entry has been created and that nMAG MUST send a successive
Proxy Binding Update request to turn this entry into primary.
When the MN has completed address configuration (indicated to the
nMAG by RAT specific L2 signalling, by a RAT specific timer in the
nMAG, by transmission of a first IP packet or by other means) the
o nMAG MUST send another Proxy Binding Update request to the LMA.
The nMAG MUST NOT set the Handoff Indicator value to the new
state (Handoff between interfaces with simultaneous operation),
but MUST set it to state 2 (Handoff between two different
interfaces of the mobile node).
Upon reception of a successive Proxy Binding Update request with
handoff indicator state 5 (Handoff state not changed (Re-
registration) for which already a secondary Binding Cache entry
exists :
o the LMA MUST ignore this and leave the secondary Binding
Cache entry and the tunnel routing unchanged.
Upon accepting of the successive Proxy Binding Update request with
handoff indicator state 2 (Handoff between two different interfaces
of the mobile node) for which already a secondary Binding Cache entry
exists the LMA switches the states of the Binding Cache entry:
o the LMA MUST mark the previously secondary Binding Cache entry
now as primary (active). It MUST route downlink traffic to the
MN into the tunnel of this Binding Cache entry.
o the LMA MUST mark the previously primary Binding Cache entry for
the same MN's Home Network Prefix entry now as secondary Binding
Cache entry. The LMA SHALL continue to route the mobile nodes's
uplink data traffic that arrives from the tunnel of the
secondary Binding Cache Entry.
Blume & Sigle Expires Aug 21, 2008 [Page 15]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
When the MN detaches its connectivity to the pMAG, the pMAG SHALL
send a Proxy Binding Update request with lifetime 0. When this
arrives at the LMA for the now secondary Binding Cache entry or
MinDelayBeforeBCEDelete amount of time after the successive Proxy
Binding Update was received (whatever comes first) :
o the LMA MUST remove the secondary Binding Cache entry and also
delete the still existing tunnel.
5.3. Protocol Extension for the MN
This internet draft focuses on extensions required in the MAG and in
the LMA. It is out of the scope of the current version of this
internet draft how the MN can perform address configuration of the
IP addresses for the simultaneously attached interfaces.
This issue is not specific for the MBB handoff from IF1 to IF2 with
secondary Binding Cache entries, but already occurs in a BBM handoff
for any of the three case described above in section in 5.1.
PMIP [I-D. ietf-netlmm-proxymip6] specifies in these cases that LMA
MUST assigne the same HNP as previously assigned to the pMAG. But
still this may lead to a change of the IP address of the MN. For
example, if stateless address autoconfiguration is used, the MN will
configure a new IP address using the MAC address of the IF2 which
will usually be different from the MAC address of IF 1. It is ffs how
the MN can assure continuation of the ongoing IP sessions with its
corresponding nodes.
A further issues specific to the MBB handoff is related to the
question whether the MN can handle the same IP address for both
interfaces simultaneously during the MBB handoff or whether the MN is
required to operate a shim layer between the IP layer and the L2
interfaces to hide the change of the interface from the IP stack.
Blume & Sigle Expires Aug 21, 2008 [Page 16]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
6. Security Considerations
Protocol extensions according to this internet draft do not change
the security requirements of Proxy Mobile IP. Signaling between MAGs
and LMAs as well as information carried by PBU and PBA messages is
protected and authenticated according to the mechanisms described in
[I-D.ietf-netlmm-proxymip6].
Blume & Sigle Expires Aug 21, 2008 [Page 17]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
7. IANA Considerations
This documents introduces a new value to the Handoff Indicator Option
in section 8.4 of [I-D.ietf-netlmm-proxymip6]. These values will be
allocated and managed by IANA.
Blume & Sigle Expires Aug 21, 2008 [Page 18]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
8. Acknowledgement
The autors would like to thank Kuntal Chowdhury for his encouraging
support of the idea, a detailed review and for fruitful discussions.
9. References
9.1 Normative References
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-10 (work in progress),
February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC2473] IETF Network Working Group, Conta, A., Deering S.
"Generic Packet Tunneling in IPv6. Specification"
December 1998
[3GPP TS 25.331]
3rd Generation Partnership Project;
Technical Specification Group Radio Access Network;
"Radio Resource Control (RRC) Protocol Specification",
Technical Specification 3GPP TS 25.331 V8.1.0 (2007-12)
[IEEE802.11]
ANSI/IEEE Std 802.11, "Local and metropolitan area
networks - Specific requirements. Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, 1999
9.2 Informative Reference
[1] S2-074410 "Seamless Inter-technology Handover with simultaneous
radio support", Alcatel-Lucent. 3GPP TSG SA WG2 Architecture,
meeting S2#60, Kobe Oct. 2007
[2] "Inter-Technology Handover for Proxy MIPv6", M. Liebsch, L. Le.
Internet-Draft draft-liebsch-netlmm-intertech-proxymip6ho-00.txt
IETF NetLMM, Nov. 2007, work in progress
[3] Measurements of packet arrival time and packet loss with OWPing
tool in a testbed setup with multi-radio MN using 3GPP HSDPA and
IEEE WLAN radio interfaces and Mobile IPv6 as handoff protocol.
Alcatel-Lucent, 2007, unpublished results
Blume & Sigle Expires Aug 21, 2008 [Page 19]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
Authors' Addresses
Oliver Blume
Alcatel-Lucent Deutschland AG
Bell Labs
Lorenzstr. 10
70435 Stuttgart
Germany
Phone: +49 711 821-47177
Email: oliver.blume@alcatel-lucent.de
Rolf Sigle
Alcatel-Lucent Deutschland AG
Bell Labs
Lorenzstr. 10
70435 Stuttgart
Germany
Phone: +49 711 821-36609
Email: rolf.sigle@alcatel-lucent.de
Blume & Sigle Expires Aug 21, 2008 [Page 20]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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 any 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Blume & Sigle Expires Aug 21, 2008 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 13:07:00 |