NETLMM Working Group A. Muhanna
Internet-Draft Nortel
Intended status: Standards Track S. Krishnan
Expires: August 21, 2008 Ericsson
K. Leung
Cisco
B. Patil
Nokia Siemens Networks
February 18, 2008
Proxy MIPv6 support for transient registrations
draft-muhanna-netlmm-pmipv6-support-transient-coa-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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Proxy Mobile IPv6 is a network-based mobility protocol which provides
IP mobility for a regular IPv6 mobile node without the involvement of
the IPv6 host. This document specify an enhancement to enable Proxy
Muhanna, et al. Expires August 21, 2008 [Page 1]
Internet-Draft PMIPv6 Transient Registration February 2008
MIPv6 protocol to support a transient proxy care-of address
registration. This process allows the target mobile access gateway
to request the local mobility anchor which host the mobile node
binding cache entry to register a transient proxy care-of address and
the direction of the associated traffic to enable the LMA to receive
uplink traffic from two different proxy care-of addresses at the same
time during the mobile node inter-MAG active handoff.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transient Care of Address Registration Procedure . . . . . . . 4
4. LMA Operation with transient binding cache entries . . . . . . 4
5. Removal of transient binding cache entries . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . . 5
10. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Muhanna, et al. Expires August 21, 2008 [Page 2]
Internet-Draft PMIPv6 Transient Registration February 2008
1. Conventions used in this document
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 [1].
All the general mobility terminologies and abbreviations are to be
interpreted as defined in IPv6 Mobility Support specification [RFC-
3775] and Proxy Mobile IPv6 [PMIP6-Base].
2. Introduction
Proxy Mobile IPv6 is a network-based mobility protocol which provides
IP mobility for a regular IPv6 mobile node without the involvement of
the IPv6 host. Whenever a mobile node is attached to a PMIPv6 domain
via a mobility access gateway, MAG, it appears to the mobile node as
if it is attached to the same home link and thus the mobile node may
think that it is not roaming away from home. In the case of mobile
node active handoff between two different MAGs, the target MAG
usually sends a proxy BU message to the mobile node local mobility
anchor to update the mobile node BCE with a new care-of address. As
soon as the LMA receives and successfully process the proxy BU from
the target MAG, LMA updates the mobile node BCE with the new care of
address and starts sending the mobile node downlink traffic to the
new care of address hosted at the target MAG and forward all of the
mobile node uplink reverse IP traffic to the internet as long as it
comes from the new care of address. However, during active handoff
scenario, some of the mobile node uplink traffic may be still in
transient through the previous MAG. Currently, the LMA forwards a
mobile node reverse uplink traffic to the internet as long as the
following two conditions are met:
o The mobile node has an active BCE with its current care of
address.
o The uplink traffic is received from the care of address saved in
the mobile node BCE.
This document defines a mechanism which allows Proxy MIPv6 to support
a transient care-of address registration which enables the mobile
access gateway to register an address as a transient proxy care-of
address for a short period of time during inter-MAG active handoff.
This new transient registration will enable the LMA to receive uplink
traffic for the same MN from two different MAGs at the same time. As
soon as inter-MAG handoff is complete, the mobile node BCE will be
updated to reflect the latest mobile node care of address and the
Muhanna, et al. Expires August 21, 2008 [Page 3]
Internet-Draft PMIPv6 Transient Registration February 2008
transient pCoA will be removed from the binding cache.
3. Transient Care of Address Registration Procedure
When the target MAG sends a PBU for the new MN that attaches it sets
a new value (6: Handoff with transient uplink) in the Handoff
Indicator field in the PBU. When the LMA receives this PBU, it
creates a new BCE entry with a new bit called the "Transient bit".
The LMA responds with a PBA message containing the same handoff
indicator value. If the LMA is not capable of performing transient
registrations it can ignore the transient registration and instead
process the message as if it contained the HI value of 3 (Handoff
between mobile access gateways for the same interface).
4. LMA Operation with transient binding cache entries
When an uplink packet is received from the MN through the target MAG,
the LMA MUST verify if the source address of the packet (i.e. the
pCoA of the target MAG) matches the transient pCoA. If the address
matches, the LMA MUST consider the packet to be valid and MUST
forward the packet appropriately based on the contents of the
decapsulated packet. The LMA SHOULD NOT use the transient binding
cache entries for sending out downlink traffic to the MN through the
target MAG.
5. Removal of transient binding cache entries
The transient binding cache entry, which was created by the procedure
described in this document, needs to be short lived. i.e. for the
duration of the handover. After the handover completes, this entry
needs to either be removed or promoted to a full blown binding cache
entry. There are three ways by which this can happen
1. The target MAG sends a new PBU with HI value 3 (Handoff between
mobile access gateways for the same interface): The transient
binding cache entry is converted into a full blown binding cache
entry and the BCE for the old MAG is removed
2. The old MAG sends a deregistraion PBU: The transient binding
cache entry is converted into a full blown binding cache entry
and the BCE for the old MAG is removed
3. A configurable timer expires: The transient binding cache entry
is converted into a full blown binding cache entry and the BCE
for the old MAG is removed
Muhanna, et al. Expires August 21, 2008 [Page 4]
Internet-Draft PMIPv6 Transient Registration February 2008
Alternately, if none of these happen, the transient binding cache
entry can simply be removed after a configurable timer expires.
6. IANA Considerations
This document does not require any IANA interaction.
7. Security Considerations
This document does not present any new security requirement on the
top of the security requirements listed in [PMIPv6-Base]. It only
present an a mechanism to allow a mobile node to be transitionally
multihomed at two care of addresses during an inter-MAG active
handoff using the same security requirements as per [PMIPv6-Base].
8. Acknowledgements
The ideas presented in the document came out of a discussion during
IETF70 at Vancouver in December 2007. The following people were
involved in the discussion (listed by last name) Kuntal Chowdhury,
Vijay Devarapalli, Sri Gundavelli, Lalit Kotecha, Suresh Krishnan,
Kent Leung and Ahmad Muhanna.
9. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PMIP6-Base] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-05
(work in progress), September 2007.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004.
Muhanna, et al. Expires August 21, 2008 [Page 5]
Internet-Draft PMIPv6 Transient Registration February 2008
10. Informative References
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R.
Droms,Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July
2003.
Authors' Addresses
Ahmad Muhanna
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Phone: +1 (972) 685-1416
Email: amuhanna@nortel.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 (514) 345-7900 x42871
Email: suresh.krishnan@ericsson.com
Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: kleung@cisco.com
Muhanna, et al. Expires August 21, 2008 [Page 6]
Internet-Draft PMIPv6 Transient Registration February 2008
Basavaraj Patil
Nokia Siemens Networks
6000 Connection Drive
Irving, TX 75039
USA
Email: basavaraj.patil@nsn.com
Muhanna, et al. Expires August 21, 2008 [Page 7]
Internet-Draft PMIPv6 Transient Registration February 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).
Muhanna, et al. Expires August 21, 2008 [Page 8]