Network Working Group                                        S. Krishnan
Internet-Draft                                                 S. Touati
Intended status: Informational                                  Z. Qiang
Expires: August 28, 2008                                        Ericsson
                                                       February 25, 2008


              Redirecting Proxy Binding Updates in PMIPv6
                   draft-krishnan-mext-ha-redirect-01

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 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document specifies a new LMA Redirect mechanism, where an
   initially contacted LMA can let the MAG know that it needs to connect
   to an alternate LMA to get mobility services, either for overload
   prevention and/or load balancing purposes.  This document proposes a
   new error code for the proxy binding acknowledgement message and a
   new mobility option to be carried on the binding acknowledgement
   message for this purpose.



Krishnan, et al.         Expires August 28, 2008                [Page 1]


Internet-Draft             PMIPv6 LMA Redirect             February 2008


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Proposed method . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Alternate LMA List Option . . . . . . . . . . . . . . . . . . . 3
   5.  LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Operational Considerations  . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9





































Krishnan, et al.         Expires August 28, 2008                [Page 2]


Internet-Draft             PMIPv6 LMA Redirect             February 2008


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].


2.  Introduction

   In PMIPv6 [PMIPv6], LMAs are responsible for the registration of
   mobile nodes in the home network, intercepting packets destined for
   them, and tunneling these packets to their proxy care-of address
   hosted on a MAG.  When the LMA has to support a large number of
   mobile nodes and actively tunnel traffic to them, it could become
   overloaded, leading to dropped packets and connections.

   An LMA might not want to accept any new bindings of mobile nodes
   other than the ones it is currently supporting, for various reasons.
   i.e., it might be overloaded, it wants to achieve better load
   balancing with another known LMA in the same network, or it has some
   scheduled maintenance coming up soon.

   [RFC5142] provides a mechanism that allows a Home Agent to signal the
   Mobile Node that it should contact a new Home Agent, but it is not
   clear if this mechanism can be used for PMIPv6 in the interaction
   between the MAG and the LMA.


3.  Proposed method

   When an LMA receives a PBU message from a MAG and is not able to
   serve the MN specified in the PBU, it sends a PBA message back with
   an error code describing the cause for why it cannot accept the
   binding.  Along with the status code, the LMA optionally includes a
   mobility option called the Alternate LMA list, that contains a list
   of LMA addresses that the MAG can contact to obtain mobility service
   for the MN.  The method by which the alternate LMA list is created on
   the LMA is out of scope of this document.

   A new status code is defined in this document.  The PMIPV6-LMA-
   REDIRECT status code is used when the LMA wishes to redirect the MAG.


4.  Alternate LMA List Option

   This document defines a new mobility option called the Alternate LMA
   List Option.  This option MUST be used only in PBA messages sent from
   a LMA towards the MAG.  This option SHOULD be present if the status



Krishnan, et al.         Expires August 28, 2008                [Page 3]


Internet-Draft             PMIPv6 LMA Redirect             February 2008


   code is PMIPV6-LMA-REDIRECT.  It MUST NOT be present if the status
   code is not PMIPV6-LMA-REDIRECT.

















































Krishnan, et al.         Expires August 28, 2008                [Page 4]


Internet-Draft             PMIPv6 LMA Redirect             February 2008


        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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |  Option Type  | Option Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Num LMAs    |                Reserved                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       :                                                               :
       :                          LMA1 Address                         :
       :                                                               :
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       :                                                               :
       :                          LMA2 Address                         :
       :                                                               :
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                                                               :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       :                                                               :
       :                          LMAn Address                         :
       :                                                               :
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Option Type
       TBA3

    Option Length
       Length of the Alternate LMA List mobility option.

    Num LMAs
       Number of LMA addresses in the following list

    Reserved
       This field MUST be set to zero and ignored on reception

    LMA1 Address
       128 bit address of the first LMA

    LMAn Address
       128 bit address of the nth LMA




Krishnan, et al.         Expires August 28, 2008                [Page 5]


Internet-Draft             PMIPv6 LMA Redirect             February 2008


                Figure 1: Alternate LMA List Option Format


5.  LMA Operation

   Upon receiving a Proxy Binding Update message from a MAG, the LMA may
   reject the binding and provide a list of alternate LMAs.  This may be
   done for various reasons like administrative, load balancing, or
   policy reasons as described earlier.

   The LMA MUST prepare a Proxy Binding Acknowledgment message, as
   described in [PMIPv6], with a status code PMIPV6-LMA-REDIRECT.  The
   LMA needs to be aware of alternate LMAs that can serve the MN, and it
   MUST include an Alternate LMA List option containing the addresses of
   the alternate LMAs.


6.  MAG Operation

   Upon receiving the Proxy Binding Acknowledgment from the LMA with the
   status code set to PMIPV6-LMA-REDIRECT, the MAG SHOULD parse the
   Alternate LMA List Option, and extract the IPv6 addresses of the
   LMA(s).

   The MAG MUST then send a Proxy Binding Update message to the first
   LMA address received in the Alternate LMA List Option, containing the
   same information as the initial PBU message.

   If the connection to the alternate LMA fails and the Status code is
   not PMIPV6-LMA-REDIRECT, the Mobile node MUST select, if available,
   the next LMAA address received in the initial PBA message.  This
   process continues until the exhaustion of the list of LMAs.

   If the MAG receives a Proxy Binding acknowledgment message from an
   alternate LMA with status code PMIPV6-LMA-REDIRECT, then this newly
   received list of LMAs MUST override the previously received one.  The
   MAG MUST select the first LMA in the newly received list, and send it
   a Proxy Binding Update message.

   In general, each time a new redirect is received by the MAG it will
   override the previously received redirect(s) if any and the MAG
   always acts only upon the latest Alternate LMA List.


7.  Operational Considerations

   In case the Redirect Mobility Option is used for redirect purposes,
   the potential LMA that can be returned to a MAG MUST be able to



Krishnan, et al.         Expires August 28, 2008                [Page 6]


Internet-Draft             PMIPv6 LMA Redirect             February 2008


   handle the Home Prefix of the Home Address of the Mobile Node.

   There could be a limit to how many redirects can be accepted by a MAG
   before it gives up.  This can be configured on the MAG.  This doesn't
   preclude the LMA from sending the Redirect Mobility Option.

   It is possible that two or more LMAs can send redirects that can send
   an MAG on a loop.  This can be avoided by careful configuration of
   the network.  A protocol based solution is possible but will
   unnecessarily complicate the MAG.


8.  IANA Considerations

   This document requests the assignment of the following status code
   from the Mobile IPv6 parameters Status Codes registry located at
   http://www.iana.org/assignments/mobility-parameters .

   TBA2 PMIPV6-LMA-REDIRECT

   This also requests the assignment of the following option code from
   the Mobile IPv6 parameters Mobility Options registry located at
   http://www.iana.org/assignments/mobility-parameters .

   TBA3 Alternate LMAA List


9.  Security Considerations

   This document specifies an option in the proxy binding
   acknowledgement message that redirects the MAG towards another LMA.
   A malicious or compromised LMA can send this message to redirect an
   MAG towards a possibly unavailable set of LMA addresses.


10.  Normative References

   [PMIPv6]   Gundavelli, S., "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-11 (work in progress),
              March 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5142]  Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
              "Mobility Header Home Agent Switch Message", RFC 5142,
              January 2008.




Krishnan, et al.         Expires August 28, 2008                [Page 7]


Internet-Draft             PMIPv6 LMA Redirect             February 2008


Authors' Addresses

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com


   Samy Touati
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42366
   Email: samy.touati@ericsson.com


   Zu Qiang
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x47370
   Email: zu.qiang@ericsson.com





















Krishnan, et al.         Expires August 28, 2008                [Page 8]


Internet-Draft             PMIPv6 LMA Redirect             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).





Krishnan, et al.         Expires August 28, 2008                [Page 9]