NetLMM Working Group M. Liebsch
Internet-Draft NEC
Expires: January 15, 2009 A. Muhanna
Nortel
O. Blume
Alcatel-Lucent Bell Labs
July 14, 2008
Transient Binding for Proxy Mobile IPv6
draft-liebsch-netlmm-transient-bce-pmipv6-01.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 January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Liebsch, et al. Expires January 15, 2009 [Page 1]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
Abstract
This document specifies a mechanism which enhances Proxy Mobile IPv6
protocol signaling to support the creation of a transient binding
cache entry which is used for inter-MAG handover optimization. This
mechanism is applicable to the mobile node's inter-MAG handover while
using a single interface or different interfaces. The handover
problem space using the Proxy Mobile IPv6 base protocol is analyzed
and the use of transient binding cache entries at a mobility anchor
is described. The specified extension to the Proxy Mobile IPv6
protocol ensures optimized forwarding of downlink as well as uplink
packets between mobile nodes and the network infrastructure and
avoids superfluous packet forwarding delay or even packet loss.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Conventions used in this document . . . . . . . . . . . . 5
2.2. Terminology and Functional Components . . . . . . . . . . 5
3. Analysis of the Problem Space . . . . . . . . . . . . . . . . 6
3.1. Handover with a single interface . . . . . . . . . . . . . 6
3.2. Handover between interfaces . . . . . . . . . . . . . . . 6
3.2.1. Issues with downlink traffic . . . . . . . . . . . . . 6
3.2.2. Issues with uplink traffic . . . . . . . . . . . . . . 9
3.3. Demand for a common solution . . . . . . . . . . . . . . . 10
4. Use of Transient Binding Cache Entries . . . . . . . . . . . . 11
4.1. General Approach . . . . . . . . . . . . . . . . . . . . . 11
4.2. Specified Use Cases for Transient BCEs . . . . . . . . . . 16
4.2.1. Use case 1 . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Use case 2 . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Use case 3 . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Impact to Binding Management . . . . . . . . . . . . . . . 17
4.4. MAG operation . . . . . . . . . . . . . . . . . . . . . . 18
4.5. LMA operation . . . . . . . . . . . . . . . . . . . . . . 19
4.5.1. Configuration of a transient BCE . . . . . . . . . . . 19
4.5.2. Activation of a transient BCE . . . . . . . . . . . . 21
4.5.3. Forwarding state diagram . . . . . . . . . . . . . . . 22
4.6. MN operation . . . . . . . . . . . . . . . . . . . . . . . 25
4.7. Status values . . . . . . . . . . . . . . . . . . . . . . 25
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Transient Binding option . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Protocol Configuration Variables . . . . . . . . . . . . . . . 29
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Normative References . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Liebsch, et al. Expires January 15, 2009 [Page 2]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Liebsch, et al. Expires January 15, 2009 [Page 3]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
1. Introduction
The IETF NetLMM WG is specifying Proxy Mobile IPv6 (PMIPv6)
[I-D.ietf-netlmm-proxymip6] for network-based localized mobility
management, which takes basic operation for registration, tunnel
management and deregistration into account. This document specifies
an extension to PMIPv6 to eliminate the risk of lost packets, which
are sent by a mobile node towards the network infrastructure. These
packets may get dropped by the mobile node's LMA due to an already
updated binding cache entry (BCE) from the mobile node's handover
target Mobility Access Gateway (MAG). Moreover, the extension suits
MNs, which have multiple network interfaces implemented and hand over
from one interface to the other while remaining anchored with their
previously assigned Local Mobility Anchor (LMA).
According to the PMIPv6 base specification, an LMA updates a mobile
node's BCE after having received the Proxy Binding Update (PBU)
message from the mobile node's new MAG (nMAG). At the same time the
LMA disables the forwarding entry towards the mobile node's previous
MAG (pMAG). In case of an inter-technology handover, the mobile
node's handover target interface must be configured according to the
Router Advertisement being sent by the nMAG. Address configuration
as well as possible access technology specific radio bearer setup may
delay the complete set up of the mobile node's new interface before
it is ready to receive or send data packets. In case the LMA
prematurely forwards packets towards the mobile node's new interface,
some packets may get lost or experience major packet delay.
This document specifies advanced binding cache management at LMAs
according to well defined transient BCE states and use cases to
adjust forwarding states at LMAs to different handover conditions.
During a transient state, a mobile node's BCE refers to two co-
existing proxy-Care-of-Address (pCoA) entries, one from the mobile
node's pMAG, an other from its nMAG. A transient binding on an LMA
can be controlled remotely, such as from a MAG, or by local
information, such as events. This document specifies advanced
binding cache control by means of a Transient Binding option, which
can be used with Proxy Mobile IPv6 (PMIPv6) signaling, to support
transient BCEs. Furthermore, this document specifies forwarding
characteristics according to the current state of a binding to switch
the forwarding tunnel at the LMA from the pMAG to the nMAG during
inter-MAG handover according to the handover conditions. As a result
of transient binding support, handover performance can be
considerably improved to smooth an MN's handover without introducing
major complexity into the system.
Liebsch, et al. Expires January 15, 2009 [Page 4]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
2. Conventions and Terminology
2.1. 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 [RFC2119].
2.2. Terminology and Functional Components
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 Transient Binding Cache Entry. A temporary state of the mobile
node Binding Cache Entry which defines the forwarding
characteristics of the mobile node forwarding tunnels to the nMAG
and pMAG. A Transient BCE state is set up by means of including a
Transient Binding option in the PBU and PBA. The LMA forwards the
mobile node traffic according to current transient BCE
characteristics as specified in this document. The change of
Binding Cache Entry state is either controlled remotely by the
MAGs or through a local process on the LMA. The transient state
is transparent for pMAG and usage of the Transient Binding option
is restricted to signalling between nMAG and LMA.
Liebsch, et al. Expires January 15, 2009 [Page 5]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
3. Analysis of the Problem Space
This section summarizes the analysis of the handover problem space
for inter-technology handover as well as intra-technology handover
when using the PMIPv6 base protocol.
3.1. Handover with a single interface
During an intra-technology handover, some of the MN's uplink traffic
may still be in transit through the pMAG. In addition, in some
active handoff scenarios, it is necessary to prepare the handover
target MAG prior to completion of link layer handoff procedures. In
some systems, the target MAG will be the recipient of uplink traffic
prior to the completion of the procedure that would result in the
PBU/PBA handshake. Currently and as per PMIPv6 base protocol
[I-D.ietf-netlmm-proxymip6], the LMA forwards the MN's uplink traffic
received from a tunnel only as long as the source IP address of the
MN's uplink traffic matches the IP address of the mobile node's
registered Proxy-CoA in the associated BCE. As a result, packets
being forwarded by the MN's pMAG and arriving at the LMA after the
LMA has updated the MN's BCE according to the received PBU from the
nMAG will be dropped.
3.2. Handover between interfaces
In client based mobility protocols the handoff sequence is fully
controlled by the MN and the MN updates its binding and associated
routing information at its mobility anchor after IP connectivity has
been established on the new link. On the contrary, PMIPv6 aims to
relieve the MN from the IP mobility signaling, while the mobile node
still controls link configuration during a handover. This introduces
a problem during an MN's handover between interfaces. According to
the PMIPv6 base protocol [I-D.ietf-netlmm-proxymip6], the Access
Authentication and the Proxy Binding Update (PBU) are triggered in
the access network by the radio attach procedure, transparently for
the MN. Additional delay for the MN's new interface's address
configuration is not considered. As a consequence, the immediate
update of the MN's BCE after the PBU from the MN's new MAG has been
received has impact to the performance of the MN's downlink traffic
as well as its uplink traffic. Performance aspects of downlink as
well as uplink traffic during a handover between interfaces is
analyzed in the subsequent subsections.
3.2.1. Issues with downlink traffic
Delaying availability of an MN's network interface can be caused by
certain protocol operations that the MN needs to perform to configure
its new interface and these operations can take time. In order to
Liebsch, et al. Expires January 15, 2009 [Page 6]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
complete the address auto-configuration on its new interface, the MN
needs to send a router solicitation and awaits a router
advertisement. Upon receiving a router advertisement from the new
MAG, the MN can complete its address configuration and perform
Duplicate Address Detection (DAD) [RFC4862] on the new interface.
Only then the MN's new interface is ready to receive packets.
Address configuration can take more than a second to complete. If
the LMA and the new MAG have already established a tunnel and the LMA
starts forwarding data packets for the MN to the new MAG during this
time, these data packets may get delayed or lost because the MN's new
interface is not yet ready to receive data. However, delaying the
PBU, which is sent from the new MAG to the LMA after the MN's new
interface has attached to the network, is not possible, as the new
MAG retrieves configuration data for the MN from the LMA in the PBA.
With host-based mobility protocols, such as Mobile IPv6 [RFC3775],
MNs can easily control when a binding is updated. This is different
for network-based mobility management, where hosts are not involved
in IP mobility management [RFC4831]
The aforementioned problem is exemplarily illustrated in Figure 1,
which assumes that the HNP will be assigned under control of the LMA.
Hence, the HNP option in the PBU, which is sent by the new MAG to the
LMA, is set to ALL_ZERO. An MN has attached to the network with
interface (IF) IF1 and receives data on this interface. When the
MN's new interface IF2 comes up and is detected by the new MAG, the
new MAG sends a PBU and receives a PBA from the LMA. If the LMA
decides to forward data packets for the MN via the new MAG, the new
MAG has to buffer these packets until address configuration of the
MN's new interface has completed and the MN's new interface is ready
to receive packets. While setting up IF2, the MN may not reply to
address resolution signaling [RFC4861], as sent by the new MAG (A).
If the MAG's buffer overflows or the MN cannot reply to address
resolution signaling for too long, data packets for the MN are
dropped and the MN can experience severe packet losses during an
inter-technology handover (B) until IF2 is ready to receive and send
data (C).
Liebsch, et al. Expires January 15, 2009 [Page 7]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
+------+ +----+ +----+ +---+
| MN | |pMAG| |nMAG| |LMA|
+------+ +----+ +----+ +---+
IF2 IF1 | | |
| | | | |
| |- - - - - - - - - Attach | |
| | |---------------PBU--------------->|
| | |<--------------PBA----------------|
| |--------RtSol------->| | |
| |<-------RtAdv--------| | |
| Addr. | | |
| Conf. | | |
| |<--------------------|==================data============|--
| | | | |
|- - - - - - - - - - - - - - - - - Attach |
| | | |----------PBU-------->|
| | | |<---------PBA---------|
| | | |<-====data============|--
[A]?|<-----------NSol---------------------|<-====data============|--
| | | [B] ?|<-====data============|--
| | | ?|<-====data============|--
|-----------RtSol-------------------->|<-====data============|--
|<----------RtAdv---------------------| : |
Addr. | | | : |
Conf. | | | : |
|<-----------NSol---------------------| : |
|------------NAdv------------------->[C] |
!|<------------------------------------|======data============|--
| | | | |
| | | | |
Figure 1: Issue with inter-RAT mobility.
Another risk for a delay in forwarding data packets from a new MAG to
the MN's IF2 can be some latency in setting up a particular access
technology's radio bearer or access specific security associations
after the new MAG received the MN's HNP from the LMA via the PBA
signaling message.
In case an access technology needs the MN's IP address or HNP to set
up a radio bearer between an MN's IF2 and the network infrastructure,
the responsible network component might have to wait until the nMAG
has received the associated information from the LMA in the Proxy
Binding Acknowledgment. Delay in forwarding packets from the nMAG to
the MN's IF2 depends now on the latency in setting up the radio
bearer.
A similar problem can occur in case the set up of a required security
Liebsch, et al. Expires January 15, 2009 [Page 8]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
association between the MN's IF2 and the network takes time and such
set up can be performed only after the MN's IP address or HNP is
available on the nMAG.
3.2.2. Issues with uplink traffic
In case of an inter-technology handover between two interfaces the MN
may be able to maintain connectivity on IF1 while it is completing
address configuration on IF2. Such HO mechanism is called make-
before-break and can avoid UL packet loss in client based MIP. On
the contrary, in a PMIP domain the attachment of the MN on IF2 will
cause the nMAG to send a PBU to LMA and LMA will update the BCE for
this mobility session of the MN. According to section 5.3.5 of the
PMIPv6 base specification [I-D.ietf-netlmm-proxymip6], the LMA will
drop all subsequent packets being forwarded by the MN's pMAG due to
the updated BCE, which refers now to the nMAG as Proxy-CoA. Thus
make-before-break handover is currently not supported by PMIP.
A further issue for uplink packets arises from differences in the
time of travel between nMAG and LMA resp. pMAG and LMA. Even if the
MN stops sending packets on IF1 before the PBU is sent (i.e. before
it attaches IF2 to nMAG), uplink packets from pMAG may arrive at LMA
after the PBU from nMAG. Such situation can in particular occur when
the MN's previous link has a high delay (e.g. a GSM link) and is slow
compared to the handover target link. This characteristic is
exemplarily illustrated in Figure 1. All packets forwarded from pMAG
that arrive at the LMA after the PBU from nMAG has been processed
have to be dropped according to section 5.3.5 of the PMIPv6 base
specification [I-D.ietf-netlmm-proxymip6].
Liebsch, et al. Expires January 15, 2009 [Page 9]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
+------+ +----+ +---+
| MN | |nMAG| |LMA|
+------+ +----+ +---+
IF2 IF1 | |
| |\ | |BCE exists
| | \ | | for pMAG
|- -|- - - - \- - - - Attach |
| | s\ |---------PBU----------->|BCE update
| | l\ |<--------PBA------------| for nMAG
| | o\ |
| | | w\ |
| | | l\ |
| | | i\ |
| | | n \ |packet dropped
| | | k --->| as BCE has only
| | | | entry for nMAG
| | | |
| | | |
Figure 2: Uplink traffic issue with slow links.
3.3. Demand for a common solution
To reduce the risk of packet loss, some settings on an MN could be
chosen appropriately to speed up the process of network interface
configuration. Also tuning some network parameters, such as
increasing the buffer capability on MAG components, could improve the
handover performance. However, some network characteristics, such as
access link delay or bearer setup latency, cannot be easily fine
tuned to suit a particular handover scenario. Preferable is a
general solution based on a simple extension to the PMIPv6 base
protocol, which performs well in different handover situations.
This document specifies transient BCEs as extension to the PMIPv6
base protocol. Set up and configuration of a transient BCE can be
performed by means of standard PMIPv6 signaling messages between a
MAG and an LMA component having a new Transient Binding option
included. The specification of transient BCEs covers support for
three clearly distinguished use cases to suit various handover
scenarios and to improve handover performance for both, inter- and
intra-technology handover. As a result of using transient BCEs,
excessive packet buffering at a handover target MAG is not necessary
and packet losses and major jitter during an MN's handover can be
avoided.
Liebsch, et al. Expires January 15, 2009 [Page 10]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
4. Use of Transient Binding Cache Entries
4.1. General Approach
The use of transient BCEs during an MN's handover enables controlled
forwarding of uplink and downlink traffic to harmonize handover
performance characteristics with the capabilities of the handover
source and target access networks. Updating of an MN's BCE at an LMA
is split into different phases before and after the radio setup and
IP configuration being associated with the MN's handover from a pMAG
to a nMAG.
During an inter-technology handover, the LMA shall on one hand be
able to accept uplink packets of the MN as soon as the MN has
finalized address configuration at the new IF2 and may start using
the new interface for data traffic, i.e. the PBU for the uplink shall
be done before the radio setup procedure is finalized. But, to allow
the MN to keep sending its data traffic on IF1 during the handover,
uplink packets with the previously existing binding on IF1 shall
still be accepted by the LMA until the MN detaches from pMAG with IF1
and the pMAG has deregistered the MN's attachment at the LMA by means
of sending a PBU with lifetime 0. This is of particular importance
as sending the registration PBU from the nMAG is transparent to the
mobile node, i.e. the MN does not know when the PBU has been sent.
On the other hand, switching the downlink path from the pMAG to the
nMAG shall be performed at the LMA only after completion of the IP
configuration at the MN's IF2 and after a complete setup of the
access link between the MN and the nMAG. How long this takes depends
on some interface specific settings on the MN as well as on the
duration of the target system's radio layer protocols, which is
transparent to the LMA but may be known to MAGs.
Thus, the use of a transient BCE during an MN's handover splits into
a configuration phase and an activation phase. As a result of the
MN's attachment at the nMAG, the first PBU from the MN's nMAG
performs configuration at the LMA and the nMAG. The LMA enters the
nMAG as a further forwarding entry to the MN's BCE without deleting
the existing forwarding entry and marks the BCE state as 'transient'.
After reception of the PBA, the nMAG enters the MN's configuration
data, such as the assigned HNP, into its BUL and marks the MN's
binding with the LMA as 'transient', which serves as an indication to
the nMAG that the transient BCE needs activation. During the
transient state, the LMA accepts uplink packets from both MAGs, the
pMAG and the nMAG, for forwarding. To benefit from the still
available downlink path from pMAG to MN, the LMA forwards downlink
packets towards the pMAG until the transient BCE gets activated.
Such downlink forwarding characteristic is denoted as 'Late path
switch' (L).
Liebsch, et al. Expires January 15, 2009 [Page 11]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
Decision about classification of an MN's BCE as transient can be done
either by the nMAG or the LMA. In case the nMAG takes the decision
to perform a handover according to the transient BCE specification,
the MN's nMAG includes the Transient Binding option in the PBU. In
case the LMA receives a PBU from the nMAG which has no Transient
Binding option included, it may still take the decision to create a
transient BCE for the MN. In such case, the LMA includes the
Transient Binding option in the PBA message to notify the nMAG about
the classification of the MN's BCE as transient. Description of a
detailed mechanism how a nMAG or an LMA decides to use a transient
BCE is out of scope of this document. The detailed use of the
Transient Binding option is described in Section 4.4 and Section 4.5.
A transient BCE can be activated by different means, such as a
timeout at the LMA, a PBU from the nMAG, which has no Transient
Binding option attached or a deregistration PBU from the pMAG. As
soon as the MN's BCE gets activated, the LMA switches the forwarding
path for downlink packets from the pMAG to the nMAG. This
specification considers an optional state during the activation (A),
which keeps the forwarding entry to the pMAG for some more time as a
transient BCE, solely to ensure forwarding of delayed uplink packets
from the pMAG.
The use of a transient BCE for an inter-technology handover is
exemplarily illustrated in Figure 3. The MN attaches to the PMIPv6
network with IF1 according to the procedure described in [I-D.ietf-
netlmm-proxymip6]. The MN starts receiving data packets on IF1.
When the MN activates IF2 to prepare an inter-technology handover,
the nMAG receives an attach indication and sends the PBU to the LMA
to retrieve configuration information for the MN (e.g. HNP). The
LMA is able to identify an inter-technology handover by means of
processing the HI option coming along with the PBU sent by the nMAG.
As in this example the nMAG includes the Transient Binding option in
the PBU to control the transient BCE at the LMA, the LMA updates the
MN's BCE according to the transient BCE specification described in
this document and marks the state of the BCE as 'transient' [A].
As a result of the transient BCE, the LMA keeps using the previous
forwarding information towards the pMAG binding as forwarding
information until the transient BCE gets activated. The LMA
acknowledges the PBU by means of sending a PBA to the nMAG. The nMAG
has now relevant information available, such as the MN's HNP, to set
up a radio bearer and send a Router Advertisement to the MN. While
the MN's BCE at the LMA has transient characteristic, the LMA
forwards uplink packets from the MN's pMAG as well as from its nMAG.
The nMAG may recognize when the MN's IF2 is able to send and receive
data packets and sends an updating PBU to the LMA without including
the Transient Binding option, which results in activation of the MN's
Liebsch, et al. Expires January 15, 2009 [Page 12]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
transient BCE [B]. From that moment, downlink packets will be
forwarded towards the MN's IF2 via the nMAG [C].
+------+ +----+ +----+ +---+
| MN | |pMAG| |nMAG| |LMA|
+------+ +----+ +----+ +---+
IF2 IF1 | | |
| | | | |
| |- - - - - - - - - Attach | |
| | |---------------PBU--------------->|
| | |<--------------PBA----------------|
| |--------RtSol------->| | |
| |<-------RtAdv--------| | |
| Addr. | | |
| Conf. | | |
| |<------------------->|==================data============|<---
| | | | |
|- - - - - - - - - - - - - - - - - Attach |
| | | |----PBU(transient)--->|
| | | |<---PBA(transient)---[A]
|------RAT Configuration--------------| |
| |<--------------------|==================data============|<---
|-------RtSol-(optional)------------->| |
|<-----------RtAdv--------------------| |
Addr. | | | |
Conf | | | |
|------------NSol-------------------->|---------PBU-------->[B]
| | | |<--------PBA----------|
|<------------------------------------|========data=========[C]<--
| | | | |
| | | | |
| | | | |
Figure 3: Late path switch with PMIPv6 transient BCEs.
An example of using a transient BCE for intra-technology handover is
illustrated in Figure 4. When the nMAG receives the indication that
the MN is moving from the pMAG's access network to the nMAG's area,
the nMAG sends a PBU on behalf of the MN to the MN's LMA. In this
PBU, the nMAG includes the MN-ID, the HNP, and the interface ID as
per PMIPv6 base protocol [I-D.ietf-netlmm-proxymip6].
Furthermore, the nMAG indicates an intra-technology handover by means
of the HI option and includes the Transient Binding option to
indicate to the LMA that this registration should result in a
transient BCE. The nMAG sets the value of the transient BCE lifetime
to a value that is dependent on the deployment and operator specific
Liebsch, et al. Expires January 15, 2009 [Page 13]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
[D].
After the nMAG receives an indication that the MN has completed the
handover process and the data path is ready to move the tunnel
completely from the pMAG to the nMAG, the nMAG SHOULD send a PBU to
allow the LMA to activate the MN's BCE to a regular BCE and to switch
the data path completely to be delivered through the new Proxy-CoA.
In this case, the nMAG sends a PBU with the MN-ID, Interface ID, HNP
and at the same time indicates an intra-technology handover by means
of the HI option. The nMAG does not include the Transient Binding
option again, as shown in Figure 4 [E].
In the event that the nMAG receives downlink traffic destined to the
MN from the LMA after sending a PBU with Transient Binding option
included, the nMAG MUST deliver the downlink traffic to the MN. In
this case, the nMAG SHOULD send a PBU to ensure that the transient
BCE has been activated.
Liebsch, et al. Expires January 15, 2009 [Page 14]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
+-----+ +----+ +-----+ +-----+
| MN | |pMAG| |nMAG| | LMA |
+-----+ +----+ +-----+ +-----+
| | | bi-directional |
| |<<<<<<<<======================>>>>>>>>|<-->
| | | |
| | | |
[Handoff Event] | | |
| [MN HO Event] | |
| | [HO Event Acquire] |
| | | |
[LL Attach to | | |
nMAG] | |----PBU (transient)----->|
| | | [D]
| | |<-----PBA(transient)-----|
| | | |
| | bi-directional |
| |<<<<<<<<======================>>>>>>>>|<-->
| | | |
| | | uplink only |
| | |>>>>>>===========>>>>>>>>|-->
| | | |
| | [HO Complete] |
| | |----------PBU----------->|
| | | [E]
| | |<---------PBA -----------|
| |` | |
| | |<<<<<<<<=========>>>>>>>>|<-->
| | | |
Figure 4: Transient BCE support for an intra-technology handover
The current specification of transient BCEs covers three use cases.
Each use case characterizes a particular transition and walk through
the transient forwarding state model during an MN's handover. Each
state implies a dedicated characteristic regarding forwarding
entries, in which forwarding rules for uplink traffic are maintained
separately from downlink traffic. Use case 1 implies a late downlink
path switch from the pMAG to the nMAG. Use case 2 implies a late
downlink path switch as well as a subsequent intermediate activation
state to ensure forwarding of delayed uplink packets at the LMA even
after activation of the transient BCE has been initiated. Use case 3
does not perform late path switching, but ensures forwarding of
delayed uplink packets from the pMAG while the MN is already able to
send and receive packets through the nMAG. The following section
describes these use cases in more detail.
Liebsch, et al. Expires January 15, 2009 [Page 15]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
4.2. Specified Use Cases for Transient BCEs
4.2.1. Use case 1
In some systems, PMIPv6 is supported for providing network based
mobility between the Serving Gateway (MAG) and the PDN-GW (LMA). In
such system and during active inter-MAG handoff, it is critical to
reduce handoff latency and packet loss for real-time applications
such as VoIP. In such case, the LMA is required to forward the
mobile node uplink traffic from the nMAG without completely switching
the tunnel from the pMAG.
A context transfer mechanism may be used to provide the nMAG with the
mobile node's current session information, that is anchored at the
local mobility anchor, e.g. LMA IP address, allocated HNP, GRE keys,
etc. This information with the specific link layer events informs
the MAG of the mobile node movement and attachment which allows the
nMAG to send a PBU to the local mobility anchor to create a transient
BCE which allows uplink traffic from the proxy CoA that is hosted at
the nMAG without switching the tunnel from the pMAG. During the
lifetime of the transient BCE, the LMA continues to accept uplink
traffic from both previous and new MAG while forwarding downlink
traffic to the pMAG only. While during an inter-technology handover
the MN is possibly able to receive downlink traffic via the pMAG, the
mechanism used in the pMAG's access network to forward downlink
traffic to the current location of the mobile node in the nMAG's
access network during an intra-technology handover is out of scope.
When the nMAG receives an indication that the inter-MAG handoff
process has completed, the nMAG sends another PBU without including a
Transient Binding option to update the mobile node's transient BCE to
a regular PMIPv6 BCE with bi-directional capabilities. This
mechanism is used by the LMA as an indication to switch the tunnel to
point to the nMAG, which results in a smoother handover for the MN.
4.2.2. Use case 2
Similar to use case 1, a transient BCE can be utilized for MNs with
dual radio capability. Such MNs are still able to send and receive
data on the previous interface during the new address configuration.
Forwarding between nMAG and pMAG is not required, but it has to be
avoided that the LMA immediately starts forwarding downlink data
packets to the nMAG. This is enabled by a PBU which has the
Transient Binding option included, so that it is not necessary that
MN and LMA synchronize the point in time for switching interfaces and
activating the BCE.
When the handover is finalized, the nMAG sends a second PBU without
Liebsch, et al. Expires January 15, 2009 [Page 16]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
including the Transient Binding option and the LMA activates the MN's
BCE. This PBU may overtake packets-on-the-fly from MN to LMA via
pMAG (e.g. if the previous interface was of type GSM or UMTS with up
to 150msec uplink delay). The LMA has to drop all these packets from
the pMAG due to the activation of the MN's BCE. This can be avoided
by another transient BCE state for uplink packets from pMAG, that is
characteristic to this use case and created by the PBU from nMAG and
terminated by a preconfigured lifetime.
4.2.3. Use case 3
This use case applies when an MN performs a handover from its pMAG to
a nMAG and can neither maintain its connection to the pMAG to receive
downlink packets nor the network ensures forwarding of downlink
packets from the MN's previous to its new point of attachment. The
MN's nMAG sends a PBU with the Transient Binding option included to
the LMA, which results in a transient BCE for the MN. The LMA starts
forwarding downlink packets towards the nMAG, which represents the
MN's new Proxy-CoA. The key characteristic of the MN's transient BCE
in this use case is that the LMA accepts uplink packets from the MN's
pMAG as well as from its nMAG for a certain period to forward them
into the network infrastructure. This ensures forwarding of delayed
uplink packets, which are still on the way from the pMAG to the LMA.
The LMA activates the MN's BCE after a pre-configured lifetime of the
transient BCE or after it has received a deregistration PBU (lifetime
= 0) from the pMAG. After the MN's BCE state has turned from
transient state to active state, the LMA deletes the forwarding entry
to the pMAG and performs forwarding of the MN's uplink and downlink
packets only from and to the Proxy-CoA being associated with the MN's
nMAG.
4.3. Impact to Binding Management
The use of a transient BCE requires temporary maintenance of two
forwarding entries in the MN's BCE at the LMA, one referring to the
MN's pMAG, the other referring to its nMAG. Forwarding entries are
represented according to [I-D.ietf-netlmm-proxymip6] and comprise the
interface identifier of the associated tunnel interface towards each
MAG, as well as the associated access technology information. Each
forwarding entry is assigned a forwarding rule to admit and control
forwarding of uplink and downlink traffic to and from the associated
MAG. Hence, according to this specification, a forwarding entry can
have either a rule that allows only forwarding of uplink traffic from
the associated MAG, or a rule that allows bidirectional forwarding
from and to the associated MAG. The interface identifier and access
technology type info can be taken from the PBU received at the LMA
and linked to each forwarding entry accordingly.
Liebsch, et al. Expires January 15, 2009 [Page 17]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
MAGs should maintain the status of an MN's binding and the lifetime
associated with a transient BCE at the LMA in their binding update
list. This is in particular important in case a new MAG needs to
explicitly activate a binding after the associated MN's new interface
has proven to be ready to handle IP traffic.
4.4. MAG operation
In case of a handover, the MN's nMAG may decide to control the MN's
handover at the LMA according to any of the three use cases for
transient BCEs described above. In such case, the nMAG includes the
Transient Binding option in the PBU message it sends to the MN's LMA.
If the nMAG wants the LMA to perform a late path switch, it sets the
L-flag of the Transient Binding option to 1. If the nMAG wants the
LMA to enter a temporary activation state after the activation of a
transient BCE has been initiated to follow use case 2, the nMAG sets
the A-flag along with the L-flag in the Transient Binding option to
1. Otherwise, the nMAG may set the L-flag to 1 and the A-flag to 0
to perform a handover according to use case 1. In case the nMAG does
not control the LMA to perform a late path switch, but wants to
ensure temporary forwarding of uplink traffic at the LMA from the
pMAG and from the nMAG according to the use case 3, it sets the
L-flag to 0 and the A-flag to 1. The nMAG SHOULD NOT use the
Transient Binding option with both flags set to 0. In any case where
the nMAG includes the Transient Binding option in the PBU with the
L-Flag set to 1, it MUST set the Lifetime field of the Transient
Binding option to a value larger than 0 to propose a maximum lifetime
of the transient BCE. The chosen lifetime value for the Transient
Binding option SHOULD be smaller than the chosen lifetime value for
the PBU registration. If the L-Flag of the Transient Binding option
is set to 0, the timer SHALL be set to 0. Other fields and options
of the PBU are used according to [I-D.ietf-netlmm-proxymip6]
In case the nMAG does not include a Transient Binding option but the
LMA decides to perform a handover according to any of the three use
cases for transient BCEs, the nMAG may receive a Transient Binding
option along with the PBA from the LMA as a result of the PBU it sent
to the LMA.
In case the nMAG receives a PBA with a Transient Binding option, it
SHOULD link the information about the transient BCE use case and the
associated transient BCE lifetime with the MN's entry in the BUL.
Only in case the L-flag of the Transient Binding option is set to 1,
the nMAG MAY activate the MNs transient BCE before expiration of the
transient BCE lifetime by means of sending an updating PBU to the LMA
without including a Transient Binding option. All fields of the PBU
MAY be set according to the procedure for binding lifetime extension
described in section 5.3.3 of [I-D.ietf-netlmm-proxymip6]. In case
Liebsch, et al. Expires January 15, 2009 [Page 18]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
the lifetime of a transient BCE expires or the LMA approves the
activation of a transient BCE as a result of PBU sent by the nMAG,
the nMAG MUST delete all information associated with a transient BCE
from the MN's BUL entry.
In any case where the nMAG decides to add a Transient Binding option
to the PBU, the amount of Transient Binding options per message is
limited to one.
A MAG, which serves to an MN already as pCoA and the LMA has already
a binding for the MN referring to this MAG, SHALL NOT include a
Transient Binding option in any subsequent PBU being associated with
the MN's registration.
4.5. LMA operation
4.5.1. Configuration of a transient BCE
In case the LMA receives a handover PBU from a MN's nMAG which has no
Transient Binding option included and the associated MN's BCE is
active and not in transient state, the LMA MAY take the decision to
use a transient BCE and inform the nMAG about the transient BCE
characteristics by means of including a Transient Binding option in
the PBA. In such case, configuration of the MN's transient BCE is
done according to the description in this section and the selected
use case. Otherwise, the LMA processes the PBU according to the
PMIPv6 base protocol [I-D.ietf-netlmm-proxymip6] and performs normal
update of the MN's BCE, which represents an active BCE after the LMA
has sent the PBA back to the nMAG after a successful registration.
In case the PBU from the nMAG has a Transient Binding option
included, the LMA must identify the use case of the transient BCE
registration according to the L-flag and the A-flag settings in the
Transient Binding option. In case the LMA finds the L-flag set to 1,
but the A-flag set to 0, the LMA configures the MN's transient BCE
and the forwarding rules to support use case 1. Accordingly, the LMA
performs a late path switch and forwards downlink packets for the MN
towards the MN's pMAG, whereas uplink packets being forwarded from
both Proxy-CoAs, the MN's pMAG as well as from its nMAG, will be
routed by the LMA. The LMA sets the lifetime of the transient BCE
according to the lifetime indicated by the nMAG in the Transient
Binding option's lifetime field or may decide to reduce the lifetime
according to its policy. If the lifetime value in the Transient
Binding option exceeds the lifetime value associated with the PBU
message, the LMA MUST reduce the lifetime of the transient BCE to a
value smaller than the registration lifetime value in the PBU
message. In case of a successful transient BCE registration, the LMA
sends a PBA with a Transient Binding option back to the nMAG. The
Liebsch, et al. Expires January 15, 2009 [Page 19]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
L-flag and the A-flag of the Transient Binding option included in the
PBA are set according to the values received in the PBU, whereas the
lifetime field is set to the value finally chosen by the LMA.
In case the LMA finds the L-flag and the A-flag set to 1, the LMA
configures the MN's transient BCE and the forwarding rules to support
use case 2. Accordingly, the LMA performs a late path switch and
forwards downlink packets for the MN towards the MN's pMAG, whereas
uplink packets being forwarded from both Proxy-CoAs, the MN's pMAG as
well as from its nMAG, will be routed by the LMA. In addition, the
LMA marks the transient BCE to enter a temporary activation phase
after the LMA receives an indication to activate a transient BCE.
The LMA sets the lifetime of the transient BCE according to the
lifetime indicated by the nMAG in the Transient Binding option's
lifetime field or may decide to reduce the lifetime. If the lifetime
value in the Transient Binding option exceeds the lifetime value
associated with the PBU message, the LMA MUST reduce the lifetime of
the transient BCE to a value smaller than the registration lifetime
value in the PBU message. In case of a successful transient BCE
registration, the LMA sends a PBA with a Transient Binding option
back to the nMAG. The L-flag and the A-flag of the Transient Binding
option included in the PBA are set according to the values received
in the PBU, whereas the lifetime field is set to the value finally
chosen by the LMA.
In case the LMA finds the L-flag of the received Transient Binding
option set to 0 but the A-flag set to 1, the LMA configures the MN's
transient BCE and the forwarding rules to to support use case 3.
Accordingly, the LMA forwards downlink packets for the MN towards the
MN's nMAG, whereas uplink packets being forwarded from both Proxy-
CoAs, the MN's pMAG as well as from its nMAG, will be routed by the
LMA. The LMA sends a PBA with a Transient Binding option included
back to the nMAG. The L-flag and the A-flag of the Transient Binding
option included in the PBA are set according to the values received
in the PBU, whereas the lifetime field is set to 0 by the LMA.
In any case where the LMA finds the L-flag of the received Transient
Binding option set to 1, but the lifetime field of the Transient
Binding option is set to 0, the LMA MUST ignore the Transient Binding
option and process the PBU according to [I-D.ietf-netlmm-proxymip6].
After the PBU has been processed successfully, the LMA sends back a
PBA with the status field set to PBU_ACCEPTED_TB_IGNORED.
In case the LMA finds the L-flag as well as the A-flag of the
received Transient Binding option set to 0, the LMA MUST ignore the
Transient Binding option and process the PBU according to the PMIPv6
base protocol [I-D.ietf-netlmm-proxymip6]. After the PBU has been
processed successfully, the LMA sends back a PBA with the status
Liebsch, et al. Expires January 15, 2009 [Page 20]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
field set to PBU_ACCEPTED_TB_IGNORED.
In case the LMA receives a PBU with a Transient Binding option
included from a MAG which serves already as pCoA to the associated
MN, the LMA MUST ignore the Transient Binding option and process the
PBU according to [I-D.ietf-netlmm-proxymip6]. After the PBU has been
processed successfully, the LMA sends back a PBA with the status
field set to PBU_ACCEPTED_TB_IGNORED.
In any case where the LMA adds a Transient Binding option to the PBA,
the amount of Transient Binding options per message is limited to
one.
4.5.2. Activation of a transient BCE
When the LMA receives a PBU from an MN's nMAG which has no Transient
option included, the LMA should check whether the MN's BCE is in any
of the specified transient states. If the MN's BCE is not transient,
the LMA performs processing and BCE update according to the PMIPv6
base protocol [I-D.ietf-netlmm-proxymip6]. When the LMA receives a
PBU from the MN's pMAG and the MN's BCE is not transient, the LMA
performs protocol operation and an update of the MN's BCE according
to the PMIPv6 base protocol [I-D.ietf-netlmm-proxymip6].
When the LMA receives a PBU from the MN's nMAG which has no Transient
option included but the MN's BCE is in a transient state or the LMA
receives a local event trigger due to expiration of MN's transient
BCE, the LMA should check whether the forwarding rules for the
associated MN are set to route the MN's downlink traffic to the MN's
pMAG. If the forwarding entry for downlink packets refers to the
MN's pMAG, the LMA must update the forwarding information to forward
downlink packets towards the MN's nMAG. After the forwarding path
has been switched, the LMA must update the MN's BCE accordingly. If
the transient BCE indicates that the LMA must consider an activation
phase after leaving a transient BCE has been initiated, the LMA must
keep both forwarding entries for the pMAG and the nMAG for uplink
packets and perform forwarding of packets it receives from both
Proxy-CoAs. If the activation phase can be omitted, the LMA sets the
state of the MN's BCE to active and deletes any forwarding entry
referring to the MN's pMAG. The LMA must delete any scheduled
timeout event for the MN which are associated with a transient BCE.
When the LMA receives a deregistration PBU from the MN's pMAG, which
has the registration lifetime set to 0 and the MN's BCE is in
transient state, the LMA must update the forwarding rules for the MN
and switch the downlink traffic path from the pMAG to the nMAG.
Furthermore, the LMA sets the state of the MN's BCE to active and
removes any forwarding entry towards the pMAG from the MN's BCE,
Liebsch, et al. Expires January 15, 2009 [Page 21]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
irrespective whether or not the transient BCE was configured to enter
a temporary activation state.
When the LMA receives a local event trigger due to expiration of a
timer which has been set to ACTIVATIONDELAY and scheduled to
terminate the activation state of an MN's transient BCE, the LMA sets
the state of the MN's BCE to active and removes any forwarding entry
towards the pMAG from the MN's BCE.
4.5.3. Forwarding state diagram
Figure 5 illustrates the forwarding state diagram for the three
transient BCE use cases based on the assumption that the nMAG
controls the use of a transient BCE during an MN's handover by means
of including a Transient Binding option in the PBU message.
The same diagram applies for the case that the LMA takes the decision
to use any of the specified transient BCE use cases. The LMA
indicates the use of a transient BCE by means of including the
Transient Binding option in the PBA it sends back to the MN's nMAG.
As the forwarding characteristics according to the transient BCE
states is independent of whether a MAG or an LMA takes the decision
to use a transient BCE during a handover, LMA-initiated use and
indication of a transient BCE is not explicitly covered in the
diagram.
According to this specification, each BCE has a state associated,
which can be either 'Active' or any of the specified transient states
'Transient-L', 'Transient-LA' or 'Transient-A'. In case a BCE is in
state 'Active', the information in a BCE and associated forwarding
conforms to [I-D.ietf-netlmm-proxymip6]. Any of the transient states
implies that the transient BCE has two forwarding entries, which are
denoted as pMAG and nMAG in the forwarding state diagram. The
forwarding diagram includes information about the forwarding rule
along with each forwarding entry. This rule indicates whether a
forwarding entry is meant to perform forwarding only for Uplink (Ul)
traffic or to perform bi-directional forwarding for Uplink (Ul) and
Downlink (Dl) traffic.
State transitions can be triggered as a result of processing a
received PBU or by a local timeout event on the LMA. Presence of a
Transient Binding option in a PBU is indicated by 'Topt' as argument
to a PBU or PBA respectively. As a further argument to a PBU
message, the source of the message is indicated, which can be either
the MN's nMAG or its pMAG. The values of the Transient Binding
option flags are indicated in brackets as argument to the Topt.
The diagram refers to two timeout events. TIMEOUT_1 is set according
Liebsch, et al. Expires January 15, 2009 [Page 22]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
to the Lifetime value in a Transient Binding option, whereas
TIMEOUT_2 is set to ACTIVATIONDELAY (see Section 7 for the default
value).
The three specified use cases for a transient BCE are reflected in
the diagram. Use case 1 implies going through state Transient-L to
support a late path switch. State Transient-LA is entered to support
use case 2, which considers an activation state Transient-A. Use
case 3 neither enters state Transient-L nor state Transient-LA, but
enters state Transient-A directly.
Liebsch, et al. Expires January 15, 2009 [Page 23]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
+----------+
| No Entry |
+----------+
|
| PBU(pMAG)
V
+----------------+
PBU(nMAG) | Active |
+------------------------------------| |
| | pMAG [Dl,Ul] |
| +----------------+
| PBU(nMAG, Topt[L=1,A=0]) | | |
| +--------------------------+ | |
| | | |PBU(nMAG,
| | PBU(nMAG, Topt[L=1,A=1])| |Topt[L=0,A=1])
| V V |
| +--------------+ +--------------+ |
| | Transient-L | | Transient-LA | |
| | | | | |
| | pMAG [Dl,Ul] | +---| pMAG [Dl,Ul] | |
| | nMAG [Ul] | | | nMAG [Ul] | |
| +--------------+ | +--------------+ |
| | | | |
| | PBU(pMAG, | | |
| | lifetime=0)| PBU(nMAG)|TIMEOUT_1 |
| | | | |
| | | V V
| | | +--------------+
| | | | Transient-A |
| PBU(nMAG)|TIMEOUT_1 | | |
| | | | nMAG [Dl,Ul] |
| |PBU(pMAG, | | pMAG [Ul] |
| | lifetime=0) | +--------------+
| | | |
| | | PBU(pMAG, |
| | | lifetime=0) | TIMEOUT_2
| | | V
| | | +--------------+
| | +--------->| Active |
| +------------------------>| |
+------------------------------------>| nMAG [Dl,Ul] |
+--------------+
Figure 5
Liebsch, et al. Expires January 15, 2009 [Page 24]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
4.6. MN operation
Operation of MN to support handover and choosing appropriate settings
for a transient BCE is out of scope of this specification. The same
applies to mechanisms for the nMAG to detect the presence of any of
the use cases for transient BCEs, e.g. the simultaneous usage of two
interfaces during the handover. One solution is that the MN signals
its intent for transient bindings to the MAG, either using radio
layer protocols between MN and MAG or with dedicated IP-based
signalling.
This document focuses on extensions required in the MAG and in the
LMA. Other documents address issues of the MN operation with PMIPv6,
such as [I-D.premec-netlmm-intertech-handover] and
[I-D.sarikaya-netlmm-itho].
It is further out of the scope of this document how the MN can
perform address configuration of the same IP address for two
simultaneously attached interfaces.
4.7. Status values
This section specifies the following PBA status value for transient
binding cache entry support. This status value must be smaller than
128 and adds to the set of status values specified in
[I-D.ietf-netlmm-proxymip6].
o PBU_ACCEPTED_TB_IGNORED: [IANA] The LMA has processed and accepted
the PBU, but the attached Transient Binding option has been
ignored.
Liebsch, et al. Expires January 15, 2009 [Page 25]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
5. Message Format
5.1. Transient Binding option
This section describes the format of the Transient Binding option,
which can be present in a Proxy Binding Update message and a Proxy
Binding Acknowledge message.
The Transient Binding option can be included in a PBU message which
is sent by a MN's nMAG as a result of a handover. In such case, the
nMAG controls the transient BCE on the LMA and specifies the
associated use case by means of setting the L-flag and the A-flag
accordingly. Alternatively, the LMA may attach the Transient Binding
option in a PBA for two reasons. Either it replies to a received PBU
with an attached Transient Binding option to approve or correct the
transient BCE lifetime, or it notifies the nMAG about its decision to
enter a transient BCE without having received a Transient Binding
option from the nMAG in the associated PBU beforehand.
The format of the Transient Binding option is as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |A|L| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Type: Identifies the Transient Binding option. To be assigned by
IANA.
Length: 8-bit unsigned integer indicating the length of the option in
octets, excluding the Type and the Length fields.
L-Flag: Indicates that the LMA applies late path switch according to
the transient BCE state. It the L-flag is set to 1, the LMA
continues to forward downlink packets towards the pMAG. In case the
L-flag is set to 0, the LMA will switch the downlink path immediately
to the nMAG after the PBU has been processed.
A-Flag: Indicates that the LMA must enter the Transient-A state
before entering Active state when set to 1. The LMA omits the
Transient-A state during activation of a transient BCE state when set
Liebsch, et al. Expires January 15, 2009 [Page 26]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
to 0.
Lifetime: Lifetime of a Transient-L state in multiple of 100ms. In
case the L-Flag of the Transient Binding option is set to 1, the
Lifetime field MUST be set to a non-zero value.
Liebsch, et al. Expires January 15, 2009 [Page 27]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
6. Security Considerations
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].
In case MAGs or LMAs make use of a further protocol interface to an
external component, such as for support of transient BCE control, the
associated protocol must be protected and information must be
authenticated.
Liebsch, et al. Expires January 15, 2009 [Page 28]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
7. Protocol Configuration Variables
LMA values:
o 'ACTIVATIONDELAY' : This value is set by default to 2000 ms and
can be administratively adjusted.
Liebsch, et al. Expires January 15, 2009 [Page 29]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
8. Contributors
Many thanks to Jun Awano, Suresh Krishnan, Long Le, Kent Leung,
Basavaraj Patil and Rolf Sigle for contributing to this document.
Liebsch, et al. Expires January 15, 2009 [Page 30]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
9. 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-18 (work in progress),
May 2008.
[I-D.premec-netlmm-intertech-handover]
Premec, D. and T. Savolainen, "Inter-technology handover
in netlmm domain",
draft-premec-netlmm-intertech-handover-00 (work in
progress), April 2008.
[I-D.sarikaya-netlmm-itho]
Sarikaya, B. and F. Xia, "Proxy Mobile IPv6 Inter-
Technology Handover Issue", draft-sarikaya-netlmm-itho-00
(work in progress), June 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.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
Liebsch, et al. Expires January 15, 2009 [Page 31]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
Authors' Addresses
Marco Liebsch
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: liebsch@nw.neclab.eu
Ahmad Muhanna
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082,
USA
Phone: +1 (972) 685-1416
Email: amuhanna@nortel.com
Oliver Blume
Alcatel-Lucent Deutschland AG
Bell Labs
Lorenzstr. 10
70435 Stuttgart,
Germany
Phone: +49 711 821-47177
Email: oliver.blume@alcatel-lucent.de
Liebsch, et al. Expires January 15, 2009 [Page 32]
Internet-Draft Transient Binding for Proxy Mobile IPv6 July 2008
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).
Liebsch, et al. Expires January 15, 2009 [Page 33]