NetLMM Working Group M. Liebsch
Internet-Draft NEC
Expires: February 1, 2008 C. Vogt
Ericsson
July 31, 2007
Context Transfer for Proxy MIPv6
draft-liebsch-netlmm-proxymip6ct-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 February 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Liebsch & Vogt Expires February 1, 2008 [Page 1]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
Abstract
The IETF is specifying a protocol for network-based localized
mobility management, which takes basic operation for registration,
tunnel management and de-registration into account. This document
specifies how the IETF's Context Transfer Protocol, which is
specified in RFC 4067, can be used with protocols for network-based
mobility management, taking proactive and reactive handover scenarios
into account. The protocol Proxy Mobile IPv6 is suitable to support
network-based mobility management, which is the reference protocol
solution for the integration of the context transfer mechanisms in
this document.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Functional Components . . . . . . . . . . . . 5
4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Reference Architecture . . . . . . . . . . . . . . . . . . 6
4.2. Deployment Options . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Reactive Handover - Case 1 . . . . . . . . . . . . . . . . 9
5.2. Reactive Handover - Case 2 . . . . . . . . . . . . . . . . 10
5.3. Proactive Handover - Case 1 . . . . . . . . . . . . . . . 11
5.4. Proactive Handover - Case 2 . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Liebsch & Vogt Expires February 1, 2008 [Page 2]
Internet-Draft Context Transfer for Proxy MIPv6 July 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 & Vogt Expires February 1, 2008 [Page 3]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
2. Introduction
The NetLMM WG is specifying a protocol for network-based localized
mobility management (NetLMM), taking basic support for registration,
de-registration and handover into account in a first protocol
release. The specification of extensions and optimization is for
further study and subject for either being incorporated into future
versions of the protocol or specified in separate documents. In
scope of the base protocol specification is the set up and
maintenance of a forwarding tunnel between an MN's Mobility Access
Gateway (MAG) and its selected Local Mobility Anchor (LMA).
The protocol Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is being
designed to suit basic operation of network-based localized mobility
management. According to [RFC4831], mobility management should not
depend on mobility-related signaling from mobile nodes (MNs), such as
location updates. However, it's considered as beneficial to support
transfer of an MN's context between the MN's previous and new access
routers in case the MN changes its point of attachment and this
change implies a change in the MN's access router. Other mechanisms
than receiving an explicit indication from the MN must be used to
initiate the transfer of context between access routers.
This document specifies, how context transfer can be achieved in a
Proxy MIPv6 enabled network. [RFC4067] is referred to as base and
generic protocol operation between access routers to perform context
transfer. The associated functional components for context transfer
are embedded into the Proxy MIPv6 architecture and protocol operation
to support context transfer efficiently by means of reusing Proxy
MIPv6 protocol elements and event indications, without the need to
rely on explicit indication from MNs.
This document first discusses different scenarios for context
transfer in a Proxy-MIPv6 enabled network, taking context push and
context pull operation, as well as support for proactive and reactive
handover into account. Subsequently, the integrated protocol
operation is described. Extensions to the Proxy MIPv6 protocol are
described in case they are required to support some of the reference
scenarios. If the integrated protocol operation relies on
information, which is not available on the relevant network
component, the source and means to retrieve such information is
described.
Liebsch & Vogt Expires February 1, 2008 [Page 4]
Internet-Draft Context Transfer for Proxy MIPv6 July 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 CT - Context Transfer. Means the transfer of any mobile node
related context from the mobile's previous access router to its
handover target access router.
o CR - Context Ready. Describes a state on an access router,
indicating that the router is ready to activate a context as soon
as it's available.
o CA - Context Activation. Describes a state on an access router,
indicating that the router has the complete context received and
activated.
o PHT - Proactive Handover Trigger. Describes an event on an access
router, which indicates the preparation or execution of a
proactive handover. Such indication provides further information
about the handover target access router, such as its IP address or
an unambiguous identifier.
o ATT - Attach. Describes an event on an access router, which
indicates that a mobile node has attached to the router and has a
fully functional layer-2 link established for bi-directional
traffic. Such indication provides further information, which is
required for the network-based mobility management protocol to
operate.
Liebsch & Vogt Expires February 1, 2008 [Page 5]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
4. Protocol Design
This section describes the integration of the IETF's Context Transfer
protocol [RFC4067] with Proxy Mobile IPv6
[I-D.ietf-netlmm-proxymip6]. The reference architecture is described
in Figure 1.
4.1. Reference Architecture
The reference architecture covers a mobile node (MN), which is
attached to a local domain operating Proxy Mobile IPv6. The MN's
Local Mobility Anchor (LMA) tracks the MN's location and maintains
associated forwarding states towards the MN's current MAG. MAGs are
assumed to be colocated with the domain's access routers. In case
the MN changes its MAG due to a handover, the procedure implies that
the MN detaches from its current access router, which implements the
MN's previous MAG (pMAG) and attaches to a handover target access
router, which implements the MN's new MAG (nMAG). The context
transfer (CT) protocol is supposed to transfer the MN's context from
its previous access router to its new access router. The reference
architecture is illustrated in Figure 1.
Liebsch & Vogt Expires February 1, 2008 [Page 6]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
Internet Backbone
:
:
|
+-----+
| LMA |
+-----+
| |
| |
+-------+ +--------+
| |
| |
+-------+ +-------+
|+-----+| |+-----+|
||pMAG || ||nMAG ||
|+-----+| CT |+-----+|
| AR |--------->| AR |
+-------+ +-------+
: .:
: .........:
. ....:
::
+--+
|MN|--------->
+--+
Figure 1: Reference architecture for context transfer in Proxy MIPv6.
Note: Within the context of the description in this document, pMAG
always refers to the network component, which is the MN's previous
access router, whereas nMAG refers to the MN's new access router.
4.2. Deployment Options
The integrated context transfer protocol leaves network operators
deployment liberties along three orthogonal axes:
1. Context transfer may happen reactively or proactively.
2. Context transfer may be initiated by the pMAG or by the nMAG.
3. The initiating pMAG/nMAG may obtain the IP address of the
correspondent nMAG/pMAG from any third entity.
Reactive context transfer is initiated either by the pMAG after the
mobile node has detached from the pMAG, or by the nMAG after the
Liebsch & Vogt Expires February 1, 2008 [Page 7]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
mobile node has attached to the nMAG. Proactive context transfer is
initiated either by the pMAG before the mobile node detaches from the
pMAG, or by the nMAG before the mobile node attaches to the nMAG.
Context transfer requires a trigger for the initiating MAG to
indicate when the transfer should start. In case the context
transfer is reactive, this trigger may be a notification from the
link layer. If the context transfer happens proactively, the trigger
is likely to originate from a handover prediction algorithm that runs
on the initiating MAG.
Context transfer furthermore requires a "MAG resolution mechanism"
through which the initiating MAG can obtain the IP address of the
correspondent MAG. If the IP address of the correspondent MAG is to
be obtained from the LMA, the MAG resolution mechanism may use
options to Proxy Mobile IPv6 messages. The IP address of the
correspondent MAG may also be obtained through a proprietary
mechanism from the policy store, or via a local trigger. The nature
of the MAG resolution mechanism determines whether the context
transfer begins in parallel with the corresponding proxy binding
update or afterwards.
Liebsch & Vogt Expires February 1, 2008 [Page 8]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
5. Protocol Operation
This section describes the operation of the integrated context
transfer protocol. The protocol operation is described for reactive
as well as proactive handover and assumes the required information
for context transfer is made available either through Proxy Mobile
IPv6 signaling or by means of a local event, which provides the
required information. The reactive handover can distinguish two
different scenarios. In one scenario, all information required to
operate Context Transfer on MAGs will be retrieved from the MN's LMA.
A different scenario might support the provision of some required
information from a local event, such as an ATTACH indication. The
proactive handover requires the pMAG to learn about the network
entity, which implements the MN's nMAG.
One general issue to be referred to is context deactivation and
deletion on an MN's previous access router. It needs to be ensured
that the context is not deleted before it has been completely
transferred to the MN's new access router. This could be achieved by
means of linking the lifetime of context information to the Proxy
Mobile IPv6 binding update list (BUL) on a MAG. If the MN's entry
expires in the BUL, the context can be deleted. This is somehow
save, as a BUL entry is not explicitly deleted under control of an
LMA, but has soft state characteristics, which expires. Deactivation
of context on the pMAG should be coordinated by the individual
component, which maintains the context.
5.1. Reactive Handover - Case 1
Figure 2 covers the integrated protocol operation for a reactive
handover, where the nMAG can initiate context transfer only after the
required information about the pMAG has been retrieved from the MN's
LMA.
As the LMA is aware of the MN's pMAG, it can inform the nMAG about
the pMAG's IP address. This information can be conveyed in a
Mobility Option of the Proxy BACK message. Possible option is a
pMAG_Address option, which carries the pMAG's IP address.
Alternatively, the pMAG can be identified by means of an identifier,
which can be resolved on the nMAG into the pMAG's IP address. For
this purpose, a pMAG_ID option can be specified. The nMAG is ready
to receive and activate context after the reception of the Proxy
BACK. The context can be activated after context data has been
transferred completely from the pMAG.
Liebsch & Vogt Expires February 1, 2008 [Page 9]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
+----+ +----+ +---+
|pMAG| |nMAG| |LMA|
+----+ +----+ +---+
| | |
| [ATT] |
| |-------- Proxy BU ------->|
| | |
| |<------ Proxy BACK -------|
| [CR] |
|<----- CT-Req ------| |
| | |
|-------- CTD ------>| |
| [CA] |
|<-------CTDR*-------| |
| | |
| | |
*Optional
Figure 2: Reactive Handover - Case 1
5.2. Reactive Handover - Case 2
Figure 3 covers the integrated protocol operation for a reactive
handover, where the nMAG retrieves information about the MN's pMAG
through a local event, which also triggers the Proxy BU. This
approach does not require any additional information from Proxy
Mobile IPv6 operation. The context transfer can be performed in
parallel to the Proxy Mobile IPv6 registration. The context can be
activated on the nMAG after the reception of the context data.
Liebsch & Vogt Expires February 1, 2008 [Page 10]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
+----+ +----+ +---+
|pMAG| |nMAG| |LMA|
+----+ +----+ +---+
| | |
| [ATT] |
| |-------- Proxy BU ------->|
|<----- CT-Req ------| |
| |<-------Proxy BACK--------|
| [CR] |
|-------- CTD ------>| |
| [CA] |
|<-------CTDR*-------| |
| | |
| | |
*Optional
Figure 3: Reactive Handover - Case 2
5.3. Proactive Handover - Case 1
Figure 4 covers the integrated protocol operation for a proactive
handover, where the pMAG can push an MN's context data to its target
access router even before the MN attaches to the pMAG. The pMAG
receives information about the MN's target access router through a
local indication. This approach does not require any additional
information from Proxy Mobile IPv6 operation. Advantageous of this
approach is, that the nMAG can learn about the MN's LMA even before
the MN attache MN attaches to the nMAG.
The nMAG is in this scenario permanently in CR mode for a set of
potential pMAGs. In a typical deployment scenario, MAGs that may
exchange contexts have preconfigured security associations. A
permanent CR mode between those MAGs that can authenticate each other
does not introduce new security risks. Garbage collection at the
nMAG ensures that transferred context will be removed automatically
in case the mobile node to which the context belongs never arrives at
the nMAG.
Liebsch & Vogt Expires February 1, 2008 [Page 11]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
+----+ +----+ +---+
|pMAG| |nMAG| |LMA|
+----+ +----+ +---+
| | |
[PHT] | |
|------- CTD ------->| |
| | |
|<------CTDR*--------| |
| [ATT] |
| |-------- Proxy BU ------->|
| | |
| |<------ Proxy BACK -------|
| | |
| | |
*Optional
Figure 4: Proactive Handover - Case 1
5.4. Proactive Handover - Case 2
Figure 5 covers the integrated protocol operation for a proactive
handover, where the nMAG retrieves information about the MN's pMAG
through a local event. This approach does not require additional
information from Proxy Mobile IPv6 operation. The context can be
activated on the nMAG after the reception of the context data. The
nMAG initiates the Proxy Mobile IPv6 registration once the mobile
node attaches to it.
Liebsch & Vogt Expires February 1, 2008 [Page 12]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
+----+ +----+ +---+
|pMAG| |nMAG| |LMA|
+----+ +----+ +---+
| | |
| [PHT] |
|<----- CT-Req ------| |
| [CR] |
|-------- CTD ------>| |
| [CA] |
|<-------CTDR*-------| |
| | |
| [ATT] |
| |-------- Proxy BU ------->|
| | |
| |<------ Proxy BACK -------|
| | |
| | |
*Optional
Figure 5: Proactive Handover - Case 2
Liebsch & Vogt Expires February 1, 2008 [Page 13]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
6. Security Considerations
The integrated scenario as described in this document must meet the
security requirements of the two individual protocol components,
namely context transfer [RFC4067] and Proxy MIPv6
[I-D.ietf-netlmm-proxymip6].
Information about an MN's previous access router must be
authenticated on the nMAG. If such information is retrieved from a
policy store, the access router which implements the nMAG should
share a security association with the policy store. Other mechanisms
to protect such information must be applied in case there is no
security association available between these network entities. The
same applies for information about the new access router, which is
used on the MN's pMAG to initiate context transfer in case of a
proactive handover scenario.
Liebsch & Vogt Expires February 1, 2008 [Page 14]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
7. IANA Considerations
This documents includes no request to IANA.
Liebsch & Vogt Expires February 1, 2008 [Page 15]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
8. Contributors
This document comprises valuable contributions from Julien Abeille
(abeille@netlab.nec.de).
Liebsch & Vogt Expires February 1, 2008 [Page 16]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
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-01 (work in progress),
June 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.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
Liebsch & Vogt Expires February 1, 2008 [Page 17]
Internet-Draft Context Transfer for Proxy MIPv6 July 2007
Authors' Addresses
Marco Liebsch
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: liebsch@netlab.nec.de
Christian Vogt
Ericsson Research, NomadicLab
Hirsalantie 11
02420 Jorvas
Finland
Email: christian.vogt@ericsson.com
Liebsch & Vogt Expires February 1, 2008 [Page 18]
Internet-Draft Context Transfer for Proxy MIPv6 July 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 & Vogt Expires February 1, 2008 [Page 19]