One document matched: draft-wakikawa-pmip-ct-00.txt
MIPSHOP Working Group R. Wakikawa
Internet-Draft Toyota ITC
Expires: May 21, 2009 S. Kiriyama
Keio Univ.
J. Xia
Huawei
November 17, 2008
Context Reflection: Context Transfer for Proxy Mobile IPv6
draft-wakikawa-pmip-ct-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 21, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Wakikawa, et al. Expires May 21, 2009 [Page 1]
Internet-Draft Context Transfer for PMIP November 2008
Abstract
This document introduces a simple Context Transfer mechanism for
Proxy Mobile IPv6. This context transfer mechanism can carry
information of a mobile node between mobility anchor gateways without
any assumption of inter-MAG trust nor direct connectivity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Context Reflection Mobility Message . . . . . . . . . . . 9
4.2. Context Data Option . . . . . . . . . . . . . . . . . . . 10
4.3. New option-code for the IP address option . . . . . . . . 11
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 13
A.1. Normative References . . . . . . . . . . . . . . . . . . . 13
A.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Wakikawa, et al. Expires May 21, 2009 [Page 2]
Internet-Draft Context Transfer for PMIP November 2008
1. Introduction
In Proxy Mobile IPv6, a Context Transfer mechanism is not specified
in [RFC-5213], though it is somehow expected to be available. For
instance, policy profile or the sequence number of a binding update
list for a mobile node are ideally exchanged between mobile access
gateways during mobile node's handover. Whenever a mobile node
changes the attached mobile access gateway, the mobile node's policy
profile is fetched by a new mobile access gateway. If a context
transfer mechanism is available in Proxy Mobile IPv6, many
optimization can be expected to handover performance.
On the proposed context transfer mechanism, we introduce neither new
trust nor physical link among mobile anchor gateways. All the
contexts are transferred between mobile access gateways always via a
local mobility anchor as shown in Figure 1-b). Context Notification
and Reflection are defined as independent signaling, but they carry
the same mobile node's context. Each mobile access gateways
establishes trust (ex. IPsec Security Association) with its local
mobility anchor, but it does not maintain security association with
the other mobile access gateways according to [RFC-5213]. The
overhead of trust and link establishments between mobile access
gateways cannot be negligible. Specially in Proxy Mobile IPv6, we
should promote more effective use of trust between LMA and MAG. In
addition, if we consider to support different wireless access
technology in a single NETLMM domain, it is better not to assume any
trust and links between MAGs.
+-------+ +-------+
| LMA | | LMA |
+-------+ +-------+
/ \ ^ \\
/ \ // \\
/ \ context // \\ context
/ \ Notification// \\ Reflection
/ \ // v
+------+ context +------+ +------+ +------+
| pMAG |==========>| nMAG | | pMAG | | nMAG |
+------+ +------+ +------+ +------+
a) b)
Figure 1: Layer 3 topology for Proxy Mobile IPv6
On the other hand, since the contexts are always routed via a local
mobility anchor, from the network (layer3) topology point of view,
there is a concern that the path between mobile access gateways
Wakikawa, et al. Expires May 21, 2009 [Page 3]
Internet-Draft Context Transfer for PMIP November 2008
becomes redundant. However, if we carefully look the physical
topology of Proxy Mobile IPv6 domain, it is not such common to have
the direct physical links among mobile access gateways. Even if a
message is directly sent between mobile access gateways like
Figure 1-a), the message might be sent via a network core. Figure 2
shows that the logical topology is not always matched to layer-1
topology. Note that each MAG need to have links to all the
neighboring MAGs to which a mobile node can handover. We draw only
two links per MAG due to the limit of ASCII art in Figure 2-a).
_.--'''MAG''''`-. MAG
..MAG | MAG MAG | MAG
: \_____ |_____/ `. \_____ |_____/
: _------LMA____ : _------LMA____
MAG-/ __/ ||__ \------MAG MAG-/ __/ ||__ \------MAG
| / | \__ .: / | \__
'---MAG MAG MAG..: MAG MAG MAG
-...'' `....'
a) Logical Topology b) Layer-1 Topology
Figure 2: Layer 1 topology for Proxy Mobile IPv6
In addition, if contexts are always relayed by LMA, LMA can verify
and control the context transfer. For instance, if LMA finds an
error in one of contexts, it can prefent reflecting context to a new
MAG.
Since our context reflection mechanism can carry any kinds of mobile
node's context including mobile node's policy profile, and binding
states, etc., it can optimize the handover, too. However, optimizing
handover is out of scope in this document.
Wakikawa, et al. Expires May 21, 2009 [Page 4]
Internet-Draft Context Transfer for PMIP November 2008
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
All terms in this document are defined in [RFC-5213] and [ID-PFMIP].
Wakikawa, et al. Expires May 21, 2009 [Page 5]
Internet-Draft Context Transfer for PMIP November 2008
3. Protocol Overview
Context Reflector requires the following assumptions.
o pMAG MUST detect MN's detachment.
o pMAG MUST obtain nMAG information. How to get NMAG address is out
of scope in this document. Similar approach of [ID-PFMIP] can be
used.
o A single LMA is always used for a mobile node in a NETLMM domain.
Figure 3 shows the signal sequence of the Context Reflector
mechanism. Since LMA, pMAG and nMAG share certain security
association, all the messages for the context reflection mechanism
can be securely exchanged.
MN PMAG NMAG LMA
| | | |
| [DETACHED] | |
| *---------------------->* 1. dereg-PBU w/ context
| * | *
| *<----------------------* 2. PBA
| * *<----------* 3. Context Reflection
| * * *
| * [ATTACHED] *
| * *---------->| 4. reg-PBU
| * *<----------| 5. PBA
| |<----------*-----------| 6. Binding Revocation
| | | |
* Contexts are being stored.
Figure 3: Signaling Sequence
1. As soon as PMAG detects detachment of a mobile node, it sends a
deregistration Proxy Binding Update to LMA (showin in Figure 4).
In that Proxy Binding Update, PMAG stores all the required
context of the mobile node as mobility options. It also stores
the new MAG address in an IP address option. In this document,
we piggyback the context information in the PBU, but we can
define a separate message (ex. Context Notification message) for
context transfer purpose if needed.
Wakikawa, et al. Expires May 21, 2009 [Page 6]
Internet-Draft Context Transfer for PMIP November 2008
IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header
- BU /* P & A flags MUST be set to value 1 */
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
[NEW MOBILITY OPTIONS for Context Reflection]
+ IP address option*
* option-code is set to 6, see Section 4.3
+ Context Data options
Figure 4: Proxy Binding Update Message Format
2. LMA verifies the Proxy Binding Update and removes the proxy
binding cache for the mobile node. In addition, it caches the
contexts of the mobile node for the context reflection. Then,
LMA replies a proxy binding acknowledgment to PMAG.
3. After LMA obtains context of the mobile node carried in the proxy
binding de-registration message from PMAG, it reflects the
contexts to NMAG. In order to notify the contexts to NMAG, a new
mobility header message named Context Reflection message is
define. When NMAG receives the Context Reflection message as
shown in Figure 5, it caches the context until MN attaches to the
NMAG. LMA learn the NMAG's IP address from the IP address option
carried in the deregistration PBU from PMAG.
IPv6 header (src=LMAA, dst=NMAG-Proxy-CoA)
Mobility header
- Context Reflection
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
+ Context Data options (mandatory)
Wakikawa, et al. Expires May 21, 2009 [Page 7]
Internet-Draft Context Transfer for PMIP November 2008
Figure 5: Context Reflection Message Format
4. When the mobile node attaches to the NMAG, NMAG sends a proxy
binding update as [RFC-5213]. This proxy binding update
indicates the completion of the mobile node's handover and let
LMA to remove all the cached context for the mobile node.
5. After processing proxy binding registration, LMA MAY send a
modified binding revocation message [ID-REVCATION] to PMAG as a
notification of handover completion. After this explicit
notification, PMAG MAY remove the cached context of the mobile
node. Alternatively, PMAG MAY manage the mobile node's context
with certain lifetime. We will specifiy the detailed operation
of context removal from PMAG in the next revision.
Wakikawa, et al. Expires May 21, 2009 [Page 8]
Internet-Draft Context Transfer for PMIP November 2008
4. Messages
This section defines extensions to the Proxy Mobile IPv6 [RFC-5213]
protocol messages.
4.1. Context Reflection Mobility Message
The Context Reflection message is used by LMA to notify MN's context
to NMAG. It MUST be unicasted and MUST be authenticated by IPsec
ESP. This message has the MH Type value TBD. Note that this message
can be implemented as a generic notification message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Context Reflection Mobility Message
Lifetime
16-bit unsigned integer indicating the lifetime of the mobile
node's context. If lifetime is expired, this context will be
discarded even during the mobile node's handover.
Sequence #
16-bit unsigned integer indicating the sequence number of a proxy
binding cache for the mobile node. This value MUST be copied from
the corresponding received Proxy Binding Update message.
Reserved
This 16-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
Wakikawa, et al. Expires May 21, 2009 [Page 9]
Internet-Draft Context Transfer for PMIP November 2008
Mobility Options
This field contains zero or more TLV-encoded mobility options.
The encoding and format of defined options are described in
section 6.2 of [RFC-3775]. Figure 5 shows the required mobility
options in the Context Reflection message
4.2. Context Data Option
A new option, Context Data option is defined for use with the Proxy
Binding Update message and the Context Reflection message. This
option is used for exchanging the mobile node's context data. There
can be multiple Context Data options present in the message.
The format of the Context Data option is shown below. Based on the
size of the data, the option MUST be aligned appropriately, as per
mobility option alignment requirements specified in [RFC-3775].
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 | Feature Profile Type (FPT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Context Data Option
Type
IANA
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields.
Feature Profile Type (FPT)
Wakikawa, et al. Expires May 21, 2009 [Page 10]
Internet-Draft Context Transfer for PMIP November 2008
16-bit integer, assigned by IANA, indicating the type of data
included in the Data field, as specified in [RFC-4067].
Data
A variable length field containing the data specific to the mobile
node's context type-dependent data.
4.3. New option-code for the IP address option
New option-code for the IP address mobility option [RFC-5268] is
defined to convey the NMAG's IP address from PMAG to LMA.
Option-Code
6 MAG
Wakikawa, et al. Expires May 21, 2009 [Page 11]
Internet-Draft Context Transfer for PMIP November 2008
5. IANA considerations
TBA
Wakikawa, et al. Expires May 21, 2009 [Page 12]
Internet-Draft Context Transfer for PMIP November 2008
6. Security Considerations
No security vulnerability is introduced in this specification. All
the signaling for context reflection are exchanged between LMA and
MAG and are protected by IPsec as [RFC-5213].
Appendix A. References
A.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC5213,
August 2008.
[ID-DSMIP6] Soliman, H., et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05.txt
,July 2007.
[RFC-4067] J. Loughney, et al, "Context Transfer Protocol (CXTP)",
RFC4067, July 2005.
[RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC5268, June
2008.
[ID-REVOCATION] A. Muhanna, et al, "Binding Revocation for IPv6
Mobility", draft-ietf-mext-binding-revocation-01.txt, August 2008.
A.2. Informative References
[ID-PFMIP] H. Yokota et.al, "Fast Handovers for PMIPv6",
draft-yokota-mipshop-pfmipv6-03.txt, July 2008.
Wakikawa, et al. Expires May 21, 2009 [Page 13]
Internet-Draft Context Transfer for PMIP November 2008
Authors' Addresses
Ryuji Wakikawa
Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Sawako Kiriyama
Graduate School of Science and Technology, Keio University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Email: kiri@tera.ics.keio.ac.jp
Jinwei Xia
Huawei Technologies Co., Ltd.
Huihong Mansion, No.91 Baixia Rd. Nanjing,
Jiangsu 21001
China
Email: xiajinwei@huawei.com
Wakikawa, et al. Expires May 21, 2009 [Page 14]
Internet-Draft Context Transfer for PMIP November 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).
Wakikawa, et al. Expires May 21, 2009 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 13:34:10 |