Internet DRAFT - draft-xia-mipshop-fmip-ptp

draft-xia-mipshop-fmip-ptp






Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Intended status: Informational                                Huawei USA
Expires: February 6, 2010                                 August 5, 2009


Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links
                     draft-xia-mipshop-fmip-ptp-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 6, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Xia & Sarikaya          Expires February 6, 2010                [Page 1]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.















































Xia & Sarikaya          Expires February 6, 2010                [Page 2]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


Abstract

   Mobile IPv6 Fast Handovers specification currently does not
   explicitly define prefix management over point-to-point links when a
   mobile node uses a prefix to formulate a new care-of-address.  In
   this document a mechanism is developed for a previous access router
   to request unique prefixes from a new access router, and in turn, the
   previous access router advertises the prefixes to the mobile node for
   a new care-of-address configuration.  Extensions to Mobile IPv6 Fast
   Handovers specification are also specified in this document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Prefix Management on Point-to-Point Links  . . . . . . . . . .  6
     4.1.  Predictive mode  . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Reactive Mode  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  HI and Hack Extensions . . . . . . . . . . . . . . . . . . . .  8
     5.1.  HI Extension . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  HAck Extension . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Dedicated Prefix Option  . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13



















Xia & Sarikaya          Expires February 6, 2010                [Page 3]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


1.  Introduction

   Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] aims at reducing the
   handover latency by reducing the time to configure a new care-of
   address (NCoA) for a mobile node(MN).  In FMIPv6, the MN formulates a
   prospective NCoA when it is still present on a link of a previous
   access router (PAR).

   [RFC4968] provides different IPv6 link models that are suitable for
   IEEE802.16 based networks and provides analysis of various
   considerations for each link model and the applicability of each link
   model under different deployment scenarios.  [RFC5121] specifies the
   addressing and operation of IPv6 over the IPv6 specific part of the
   packet convergence sublayer of IEEE Std 802.16e [802.16e], and point-
   to-point link model is recommended.  Also, 3GPP and 3GPP2 have
   adopted the point-to-point link model based on the recommendations in
   [RFC3314].

   In this document, we first explain the problems associated with
   FMIPv6 on point-to-point links followed by a detailed description of
   prefix management for FMIPv6 operation on point-to-point links.

   In Section 3 we describe why the point-to-point link address
   formation procedures are needed in FMIPv6, in Section 4 we define a
   procedure that a new access router (NAR) can use to dynamically
   assign unique prefixes in point-to-point links and in Section 5 we
   define necessary messages/options for the operation in Section 4.


2.  Terminology

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

   The terminology in this document is based on the definitions in
   [RFC5568], in addition to the ones specified in this section.

   point-to-point link model:  In this model, a set of layer 2 transport
      connections between a MN and an access router (AR) are treated as
      a single link.  Each link is allocated a separate, unique prefix
      or a set of unique prefixes by the AR.  Please refer to [RFC4968]
      for details.








Xia & Sarikaya          Expires February 6, 2010                [Page 4]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


   shared link model:  In this model, one or more prefixes are shared by
      mobile nodes for constructing their global IPv6 addresses.  Please
      refer to [RFC4968] for details.

   dedicated prefix:  In point-to-point link model, a unique prefix used
      by a MN for formulating a NCoA while the MN is still on a PAR's
      link.



3.  Problem Statement

   The following are operations relating to prefix management as per
   [RFC5568]:

   o  Movement detection.  The protocol enables a MN to quickly detect
      that it has moved to a new subnet by providing the new access
      point and the associated subnet prefix information when the MN is
      still connected to its current subnet.  For instance, the MN may
      discover available access points using link-layer specific
      mechanisms (i.e., a "scan" in WLAN) and then request subnet
      information corresponding to one or more of those discovered
      access points.  The MN sends a Router Solicitation for Proxy
      Advertisement (RtSolPr) to its access router to resolve one or
      more Access Point Identifiers (AP-ID)to subnet-specific
      information.  In response, the access router sends a Proxy Router
      Advertisement (PrRtAdv) message containing one or more [AP-ID, AR-
      Info] tuples, which the MN can use in readily detecting movement:
      when attachment to an access point with AP-ID takes place, the MN
      knows the corresponding new router's coordinates including its
      prefix, IP address, and L2 address.

   o  NCoA configuration.  AR-Info contains the access router's L2 and
      IP addresses, and the prefix valid on the interface to which the
      Access Point (identified by AP-ID) is attached.  With the prefix
      provided in the PrRtAdv message, the MN formulates a prospective
      NCoA.

   In shared link model, the prefixes are manually configured in the
   previous access router.  This is not a problem because there is only
   a small number of adjacent access routers, and the prefix is shared
   by many mobile nodes.  However, it becomes a big problem when trying
   to configure prefixes manually in point-to-point link model.  In this
   model, each MN has one or more dedicated prefixes, that is, different
   MNs have different prefixes.  The prefixes could be allocated
   dynamically.  When a MN attaches to an AR, the AR should allocate one
   or more dedicated prefixes for it; when the MN detaches from the AR,
   the MN's prefixes are released, and can be reused by other MNs.  The



Xia & Sarikaya          Expires February 6, 2010                [Page 5]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


   number of unique prefixes in this operation can be huge.

   NCoA formulation in point-to-point links requires a PAR to
   dynamically request a dedicated prefix from a NAR, and then advertise
   it to the MN using a Proxy Router Advertisement (PrRtAdv) message.
   [RFC5568] does not specify such dependencies.


4.  Prefix Management on Point-to-Point Links

   Upon the indication of handover from the PAR to the NAR, the PAR uses
   Handover Initiate (HI)/ Handover Acknowledge (HAck) message exchange
   to get a dedicated prefix from the NAR.  The PAR then sends this
   prefix in the PrRtAdv message to the MN as described in [RFC5568].
   In the PrRtAdv message, A-bit and L-bit MUST be turned on.  The MN
   thus uses this prefix for movement detection and NCoA configuration
   as per [RFC5568].

4.1.  Predictive mode

   New FMIPv6 message exchange is introduced for the PAR to ask for MN's
   dedicated prefix as shown in Figure 1.  In [RFC5568], HI is assumed
   to be sent after the Fast Binding Update (FBU) for handover
   indication.  Here, modified HI/Hack messages are used for prefix
   request/response.  Details are described in Section 5.

   The NAR MAY use DHCPv6 prefix delegation to request/ release prefixes
   from a DHCPv6 server.  The DHCPv6 messages are triggered by the HI
   for prefix request.  The NAR MAY also use AAA prefix delegation to
   request/ release prefixes for this MN from an AAA server.  The
   mechanisms for the NAR to acquire the prefixes are outside the scope
   of this document.

   Lifetime in Dedicated Prefix Option in Figure 1 is used to prevent
   prefix depletion because of erroneous movement in which the mobile
   node receives a dedicated prefix prior to a handover that it is
   moving to a new access point but it either moves to a different one
   or it aborts movement altogether.  Not until timeout of the prefix
   does the NAR release it.












Xia & Sarikaya          Expires February 6, 2010                [Page 6]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


     MN                    PAR                      NAR   DHCP/AAA
      |                     |                        |      Server
      |                     |                        |          |
      |------RtSolPr------->|                        |          |
      |                     |   HI(Prefix Request)   |          |
      |                     |----------------------->|Prefix    |
      |                     |                        |-Request->|
      |                     |                        |<-Reply---|
      |                     |  HAck(Prefix Response) |          |
      |                     |<-----------------------|          |
      |<-----PrRtAdv--------|                        |          |
      |                     |                        |No FBU    |
      |                     |                        |Release   |
      |                     |                        |Prefix    |
      |------FBU----------->|--------HI------------->|          |
      |                     |<------HAck-------------|          |
      |          <--FBack---|--FBack--->             |          |
    disconnect            forward                    |          |
      |                   packets===================>|          |
      |                     |                        |          |
      |                     |                        |          |
    connect                 |                        |          |
      |                     |                        |          |
      |--------- UNA ------------------------------->|          |
      |<=================================== deliver packets     |
      |                                              |          |


                        Figure 1: Prefix Signaling

   In some wireless networks, the handover control may reside in the
   network even though the decision to undergo handover may be mutually
   agreed between the MN and the network.  In such a case, the PAR can
   send an unsolicited PrRtAdv containing the link-layer address, IP
   address, and dedicated prefix of the mobile node when the network
   decides that a handover is imminent.  In this network-initiated
   handover scenario, there isn't explicit RtSolPr to trigger PAR to
   request a prefix and implementation specific trigger MUST be used by
   PAR to send HI message for prefix request.

4.2.  Reactive Mode

   In the reactive mode, there are two cases.  A MN receives PrRtAdv
   message or otherwise.

   o  The MN receives PrRtAdv message and formulates NCoA before
      attaching to the NAR.  The MN and the NAR operate in line with the
      procedure defined in [RFC5568].



Xia & Sarikaya          Expires February 6, 2010                [Page 7]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


   o  The MN can't formulate NCoA before attaching to the NAR.  IP
      connectivity should be established first.  The MN can configure
      its IP address using stateless address configuration, or using
      stateful address configuration.  In the former case, the NAR
      SHOULD send un-solicited RA to expedite MN's address
      configuration.  Once NCoA formulation is finished, the MN operates
      according to [RFC5568].

   In both cases, the MN formulates NCoA from the dedicated prefix.
   Since the MN has already handed over to the NAR, this prefix is
   retained.


5.  HI and Hack Extensions

5.1.  HI Extension

   The Handover Initiate (HI),defined in [RFC5568], is a Mobility Header
   message sent by one Access Router to another to initiate the process
   of a MN's handover.

   In [RFC5568], the PAR uses a Code value of 0 when it processes an FBU
   with PCoA as source IP address, while uses a Code value of 1 when it
   processes an FBU whose source IP address is not PCoA.  A new Code
   value of TBD1 (to be assigned by IANA) is used for the dedicated
   prefix request.  Dedicated Prefix Option defined in Section 5.3 MAY
   be included as a hint for a requested preference.  The NAR MAY
   allocate a dedicated prefix based on the prefix preference in the
   option.  If the option is not included, the NAR allocates a prefix
   according to it's discretion.

5.2.  HAck Extension

   Handover Acknowledgment message defined in [RFC5568] is a Mobility
   Header message that MUST be sent as a reply to the Handover Initiate
   message.  In this document, HAck is extended as follows to respond to
   a dedicated prefix request:
   o  One new Code value is defined.  Here, a Code value of TBD2 (to be
      assigned by IANA) is used for dedicated prefix response.
   o  Dedicated Prefix Option defined in Section 5.3 MUST be included
      for prefix delegation.

5.3.  Dedicated Prefix Option

   This option is of the form shown in Figure 2.






Xia & Sarikaya          Expires February 6, 2010                [Page 8]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


       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     | Option-Code   | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Lifetime                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                        Prefix                                 +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 2: Dedicated Prefix Option



     Type       To be assigned by IANA

     Length     The length of the option in units of 8 octets.

     Prefix Length
                8-bit unsigned integer.  The number of leading bits
                in the Prefix that are valid.  The value ranges from 0
                to 128.

     Option-Code
                1    Dedicated Prefix

     Lifetime   32-bit unsigned integer.  The length of time in seconds
                (relative to the time the packet is sent).  A value of
                all one bits (0xffffffff) represents infinity.

     Prefix     An IP address or a prefix of an IP address. A MN uses it
                to formulate a NCoA.



6.  Security Considerations

   Prefix management for FMIPv6 operation on point-to-point links uses
   two messages (HI/Hack) for prefix request and response.  These
   messages are secured using FMIPv6 security mechanisms and hence do
   not introduce any new security threats and the security provided by



Xia & Sarikaya          Expires February 6, 2010                [Page 9]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


   FMIPv6 applies completely.


7.  IANA considerations

   This document extends existing HI/HAck messages, new HI Code (TBD1)
   and HAck Code (TBD2) values need to be assigned by IANA.

   The document also defines one new Mobility Option which needs type
   assignment from the Mobility Options Type registry at
   http://www.iana.org/assignments/mobility-parameters:

   1.  Dedicated Prefix Option described in Section 5.3.


8.  Acknowledgements

   The authors would like to thank Heejin Jang, Daniel Park, Vijay
   Devarapalli, Rajeev Koodli, Subir Das, and Spencer Dawkins for
   valuable comments.


9.  References

9.1.  Normative References

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

   [RFC5568]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

   [RFC5121]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
              Madanapalli, "Transmission of IPv6 via the IPv6
              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
              February 2008.

9.2.  Informative references

   [802.16e]  Institute of Electrical and Electronics Engineer,
              "Amendment for Physical and Medium Access Control Layers
              for Combined Fixed and Mobile Operation in Licensed
              Bands",  IEEE 802.16e/D12.

   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, September 2002.




Xia & Sarikaya          Expires February 6, 2010               [Page 10]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


   [RFC4968]  Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
              Based Networks", RFC 4968, August 2007.

















































Xia & Sarikaya          Expires February 6, 2010               [Page 11]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


Appendix A.  Change Log

   o  v03 Dedicated Prefix Option made compatible with [RFC5568].
















































Xia & Sarikaya          Expires February 6, 2010               [Page 12]

Internet-Draft    Prefix Mgmt for FMIPv6 over P2P Links      August 2009


Authors' Addresses

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org

































Xia & Sarikaya          Expires February 6, 2010               [Page 13]