One document matched: draft-liebsch-netlmm-intertech-proxymip6ho-00.txt
NetLMM Working Group M. Liebsch
Internet-Draft L. Le
Expires: May 12, 2008 NEC
November 9, 2007
Inter-Technology Handover for Proxy MIPv6
draft-liebsch-netlmm-intertech-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 May 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Liebsch & Le Expires May 12, 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 hand over from one network interface to another
network interface while remaining anchored at the same Local Mobility
Anchor. This extension avoids that the LMA will prematurely forward
data packets for the mobile node to the mobile node's new interface
before the address configuration of this interface has completed.
With the proposed extension, packet buffering at the new MAG is not
necessary and packet losses during an inter-technology handover can
be avoided.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Functional Components . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
5. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Description and use of extensions . . . . . . . . . . . . 8
5.2. Protocol extensions . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Liebsch & Le Expires May 12, 2008 [Page 2]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 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].
Liebsch & Le Expires May 12, 2008 [Page 3]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
2. Introduction
The NetLMM WG is specifying Proxy Mobile IPv6 for network-based
localized mobility management (NetLMM), taking basic support for
registration, de-registration and handover 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 hand over from one network interface to another
network interface while remaining anchored at the same Local Mobility
Anchor. Without such extension, inter-technology handover could
result in tremendous packet loss.
When an inter-technology handover occurs, the mobile node needs to
perform address configuration for the new interface. For IPv6, this
typically requires the mobile node to send a Router Solicitation and
awaits a Router Advertisement. The mobile node also needs to perform
duplicate address detection. During this time, the mobile node's new
interface is not fully configured and not yet ready to receive data
packets. If the LMA decides to forward data packets for the mobile
node via the new MAG, severe packet losses can occur.
This document proposes an extension to Proxy Mobile IPv6 that allows
classification of a new binding as 'preliminary' and to 'activate'
such binding only when the MN's new interface is fully configured and
ready to receive data packets. Thanks to this extension, the LMA
will not prematurely forward data packets for the MN to the new MAG
before the address configuration for the MN's new interface is not
completed. The result of this proposed extension is that packet
buffering at the new MAG is not necessary and packet losses during an
inter-technology handover can be avoided.
Liebsch & Le Expires May 12, 2008 [Page 4]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 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.
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.
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.
Liebsch & Le Expires May 12, 2008 [Page 5]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
4. Problem Statement
A problem that can occur during an inter-technology handover is that
the MN's new interface may not be ready to receive packets
immediately after the handover. The reason is that the MN needs to
perform certain protocol operations to configure its new interface
and these operations can take time. In order to complete the address
configuration of 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 the MN's new interface is now ready to
receive packets.
During the address configuration of the MN's interface, if the LMA
and the new MAG already establishes a tunnel and the LMA starts
forwarding data packets for the MN to the new MAG, these data packets
will be lost (since address configuration of the MN's new interface
is not completed and the new interface is not yet ready to receive
data). However, delaying the registration signaling, 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. Host-based mobility
protocols, such as Mobile IPv6 [RFC3775] 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 illustrated in Figure 1. An MN has
attached to the network with interface 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 is 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, 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, all data packets for the MN are
dropped and the MN can experience severe packet losses during an
inter-technology handover (B).
This document proposes an extension to Proxy Mobile IPv6 that
provides the new MAG with a signaling mechanism to notify the LMA
when the MN's new interface is fully configured and ready to receive
data packets. Thanks to this signaling mechanism, the LMA will not
prematurely forward data packets for the MN to the new MAG before the
address configuration of the MN's new interface is not completed.
The result of this proposed extension is that packet buffering at the
Liebsch & Le Expires May 12, 2008 [Page 6]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
new MAG is not necessary and packet losses during an inter-technology
handover can be avoided.
+------+ +----+ +----+ +---+
| 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============|--
|<------------------------------------| : |
Addr. | | | : |
Conf. | | | : |
|<-----------NSol---------------------| : |
|------------NAdv-------------------->| |
!|<------------------------------------|======data============|--
| | | | |
| | | | |
Figure 1: Issue with inter-RAT mobility.
Liebsch & Le Expires May 12, 2008 [Page 7]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
5. PMIPv6 Extensions
This section describes an extension to [I-D.ietf-netlmm-proxymip6] to
solve the problem of using a handover target technology before it is
ready to receive and send IP packets. The key extension is to allow
classification of an MN's binding cache entry on the LMA as
'preliminary' or 'active'. Classification can be performed either
locally on the LMA or on a network component, which is not colocated
with the LMA. An example about how classification can be controlled
and signaled is described in Section 5.1, whereas Section 5.2
describes associated extensions to existing signaling and states.
5.1. Description and use of extensions
In an inter-technology handover scenario, an MN activates a network
interface, which is different from the currently used one. The new
interface should serve as interface through which the MN sends and
receives packets. After a handover, the MN shuts down the previously
used interface. The extension to the base PMIPv6 protocol as
described in this document forwards downlink packets to an MN's new
interface only when the new interface is ready to receive and send IP
packets.
Figure 2 illustrates the components of a PMIPv6 network, which
comprises the MN's LMA as well as its pMAG and the nMAG. The pMAG is
supposed to support an access network, which conforms to the
technology of Interface 1 (IF1) of the MN, whereas the nMAG supports
an access network, which conforms to the technology of IF2.
The MN attaches to the PMIPv6 network with IF1 according to the
procedure 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 should be able to identify a technology change
for the MN's binding. This can be done by means of processing the
Access Technology Type option, which comes along with the PBU. The
PBU may also carry an MN Interface Identifier option, which helps the
LMA also to identify a technology change. Alternative mechanisms to
learn about the nature of a handover are possible, such as the
explicit notification from the nMAG or from any other network
component. This requires the LMA to maintain information about the
MN's currently used technology into the MN's binding cache entry, as
it is considered in [I-D.ietf-netlmm-proxymip6].
If the LMA detects a technology change for the same MN, it enters the
nMAG as forwarding information into the binding cache, but classifies
this binding as 'preliminary' (A). The status 'preliminary' causes
Liebsch & Le Expires May 12, 2008 [Page 8]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
the LMA to keep using the previous binding as forwarding information
until the preliminary binding will be activated. The LMA
acknowledges the PBU by means of sending a PBA to the nMAG. The PBA
carries the MN's HNP as well as a flag, which indicates the status
'preliminary' to the nMAG (B). The nMAG learns through the PBA, that
an explicit activation of the binding is required. If explicit
activation of the binding is expected from the nMAG, the nMAG should
find out when the MN's new interface has been set up and configured
completely. For example, the nMAG could listen to Neighbor
Solicitations from the MN's IF2, which indicate that the MN has
configured a global address at IF2 and performs duplicate address
detection. Details about how the nMAG finds out that IF2 is ready
for being used is out of scope of this version of the document.
As soon as IF2 has been set up completely (C), the nMAG sends a
further PBU to the LMA to 'activate' the previously as 'preliminary'
classified binding. The PBU should indicate explicit activation by
means of a flag. The activation causes the LMA to change forwarding
information to refer to the nMAG and adjust the MN's binding cache
entry accordingly (D). From that moment, downlink packets will be
forwarded towards the MN's IF2 (E).
Note: As the status 'preliminary' needs to be explicitly changed to
'active' before the LMA uses the new forwarding information, this
example makes use of a further PBU/PBA handshake between the nMAG and
the LMA. Alternative mechanisms are possible to activate the new
state on the LMA.
Liebsch & Le Expires May 12, 2008 [Page 9]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
+------+ +----+ +----+ +---+
| MN | |pMAG| |nMAG| |LMA|
+------+ +----+ +----+ +---+
IF2 IF1 | | |
| | | | |
| |- - - - - - --- - Attach | |
| | |---------------PBU--------------->|
| | |<--------------PBA----------------|
| |--------RtSol------->| | |
| |<-------RtAdv--------| | |
| Addr. | | |
| Conf. | | |
| |<--------------------|==================data============|--
| | | | |
|- - - - - - - - --- - - - - - - - Attach |
| | | |----------PBU-------->(A)
| | | (B) |<-----PBA(prelim)-----|
| | | | |
| |<--------------------|==================================|--
|------------RtSol------------------->| |
|<-----------RtAdv--------------------| |
Addr. | | | |
Conf | | (C) | |
|------------NSol-------------------->|----PBU(activate)---->(D)
| | | |<-------PBA-----------|
|<------------------------------------|======================|--
| | | (E) | |
| | | | |
| | | | |
Figure 2: Solution for inter-RAT mobility.
5.2. Protocol extensions
The extension proposed in Section 5.1 requires maintenance of two
forwarding entries on the LMA during an inter-technology handover
procedure. One of these entries is marked as 'active', whereas the
other one is 'preliminary'. Extensions to an MN's entry in the LMA's
binding cache should comprise the interface identifier of the
associated tunnel towards a MAG, as well as the associated access
technology. If the MN Interface Identifier option is present in the
PBU, this information should be linked to each forwarding entry
accordingly.
MAGs should maintain the status of an MN's binding in their binding
update list. This is in particular important in case a new MAG needs
Liebsch & Le Expires May 12, 2008 [Page 10]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
to explicitly activate a binding after the associated MN's new
interface has proven to be ready for IP traffic.
The PBU message should carry a binding status flag to allow
indication of a binding status or the change of a binding status.
The flag can be set to 1, which indicates 'activate'. A flag
indicating '0' means 'preliminary'. In the PBU, the flag can in
particular be used from a MAG to signal activation of a binding after
the MN's new interface has been set up completely. If a MAG is not
sure about the status of a binding, the MAG should indicate
'preliminary' in the PBU and learn about the status from the PBA sent
by the LMA.
Also the PBA message should carry the binding status flag to allow
indication of a binding status. When set to '0', an LMA can indicate
status 'preliminary' to a MAG when replying to a PBU. After the MAG
explicitly activated a binding with a PBU, the LMA should set the
flag to '1' in the PBA when the binding can be activated.
Liebsch & Le Expires May 12, 2008 [Page 11]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
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, the associated protocol must be protected and
information must be authenticated. Such protocol interface may for
example be used by an LMA or a MAG to learn about the nature of a
handover or about the status of an MN's interface.
Liebsch & Le Expires May 12, 2008 [Page 12]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
7. IANA Considerations
This documents includes no request to IANA.
Liebsch & Le Expires May 12, 2008 [Page 13]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
8. 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-07 (work in progress),
November 2007.
[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.
Liebsch & Le Expires May 12, 2008 [Page 14]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
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
Long Le
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342224
Email: le@nw.neclab.eu
Liebsch & Le Expires May 12, 2008 [Page 15]
Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 & Le Expires May 12, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 14:54:29 |