[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

HIP Research Group                                                Z. Cao
Internet-Draft                                                   H. Deng
Intended status: Informational                                    F. Cao
Expires: September 7, 2011                                  China Mobile
                                                           March 6, 2011


               HIP Extension for Flow Mobility Management
                    draft-cao-hiprg-flow-mobility-00

Abstract

   This document defines flow mobility extension to the Host Identity
   Protocol (HIP).  A multi-homed HIP host makes the binding of a flow
   and one or more locators, through the new parameter "E-LOCATOR",
   which is the extension of "LOCATOR" defined in RFC5206, the host can
   acknowledgement his peers with addresses available that fit for some
   traffic flow.  Peer hosts then selects the most appropriate address
   to transfer the traffic flow.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 7, 2011.

Copyright Notice

   Copyright (c) 2011 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
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Cao, et al.             Expires September 7, 2011               [Page 1]


Internet-Draft              HIP Flow Mobility                 March 2011


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Operations  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Flow binding . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Base Exchange  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Flow Mobility  . . . . . . . . . . . . . . . . . . . . . .  6
       3.3.1.  Readdress without Rekey  . . . . . . . . . . . . . . .  6
       3.3.2.  Readdress with Multi-homed-Initiated Rekey . . . . . .  7
       3.3.3.  Load balance . . . . . . . . . . . . . . . . . . . . .  7
   4.  E-Locator Definition . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






























Cao, et al.             Expires September 7, 2011               [Page 2]


Internet-Draft              HIP Flow Mobility                 March 2011


1.  Introduction

   The Host Identity Protocol (HIP) [RFC4423] uses a new identity, named
   host identities, instead of IP addresses, as host identities.
   Packets between two HIP hosts are forwarded by IP addresses but
   identified by the host identities.  Thereby when the IP address of a
   host is changed, the connections between the host and its peers can
   be sustained.  [RFC5206] encompasses messaging and elements of
   procedure for basic network-level mobility and simple multihoming.  A
   general "LOCATOR" parameter for HIP messages that allows for a HIP
   host to notify peers about alternate addresses at which it is
   reachable is defined.  The LOCATORs may be merely IP addresses, or
   they may have additional multiplexing and demultiplexing context to
   aid the packet handling in the lower layers.

   To enable the traffic control, HIP could be extended to support the
   flow mobility.  This document extends LOCATOR to support end-to-end
   flow mobility of HIP.  The extended LOCATOR, named as E-LOCATOR,
   includes locators defined in RFC5206 and a flow identifier mobility
   option, which defines the flow that is suitable transferred through
   the corresponding locator.  The detail format of E-LOCATOR is
   described in Section 4.

   The motivations to do HIP flow mobility include:

   o  Enable the flow mobility in HIP.  That means flow can be
      transferred through the most appropriate interface or redirected
      to a better interface or address according to some factors, such
      as address enable situations, user preference and operator policy,
      etc.

   o  Enable the load sharing.  The traffic to a certain interface of
      host can be distributed among different interfaces.  When the
      resource of one connection is limited, other interfaces can be
      used to help deliver the data together.

   A flow is defined as a set of IP packets matching a traffic selector.
   A traffic selector can identify the source and destination IP
   addresses, transport protocol number, the source and destination port
   numbers and other fields in IP and higher layer headers.  For more
   flow information, please refer to [RFC6089].


2.  Scenarios

   End-to-end flow mobility is important to HIP multihoming.  The
   traffic control, charging, QoS control and other operations can be
   operated based on flow.



Cao, et al.             Expires September 7, 2011               [Page 3]


Internet-Draft              HIP Flow Mobility                 March 2011


   A host that has one interface with multiple addresses, or a host that
   has multiple interfaces, each interface has a separate address are
   both multi-homed HIP hosts.  It is envisioned that a multi-homed host
   can use several addresses simultaneously to transfer flows.

   When different addresses are used simultaneously to transfer flows,
   first there must be policies in the multi-homed host about deciding a
   flow to be transferred through a certain address; we call this as
   flow binding.  Then end-to-end address chosen and readdress are both
   necessary.  Before a communication, the multi-homed host should be
   able to inform its peer about the reachable addresses, with the
   corresponding flow binding; peers should be able to choose the most
   suitable address for communication according to the flow going to be
   transferred; during the conversation, caused by IP address changing
   or in order to realize load balance, due to some mechanism, the
   multi-homed host may redirect some exiting flows with its peer from a
   previous interface or address to a new interface or address.

   These situations are typical flow mobility scenarios.  In these
   scenarios, there is a need for some helper functionality in the
   network, such as a HIP rendezvous server [RFC5204].  Such
   functionality is out of the scope of this document.


3.  Protocol Operations

   This protocol is based on "End-Host Mobility and Multihoming with the
   Host Identity Protocol" [RFC5206] .

   This section introduces the solution of flow mobility.  Using the
   parameters "E-LOCATOR" introduced in this specification, a multi-
   homed HIP host can notify peers about alternate addresses with
   corresponding flow mobility option; a flow can be identified by a FID
   in the mobility option.  We can assume this as flow binding.  Then
   the peers can select the most suitable address as the communication
   address.  During the communication, when the using address is changed
   or in order to make load balance, the multi-homed host can redirect
   the existing flows to other addresses by using E-LOCATOR.

3.1.  Flow binding

   It is assumed that there should be some policies of flow binding.  A
   flow binding in the multi-homed host is about a flow to be
   transferred through a certain address.  In E-LOCATOR, a locator is
   followed by a "Flow Identification Mobility Option", which means flow
   with FID in the option is going to be transferred through the
   locator.  The details of these policies are outside the scope of this
   document.



Cao, et al.             Expires September 7, 2011               [Page 4]


Internet-Draft              HIP Flow Mobility                 March 2011


   In this document, a host with HIP protocol that initializes a
   connection is Initiator; its peer host is Responder[RFC4423].

3.2.  Base Exchange

   Assuming that the Responder host has multiple addresses available at
   begin of the communication with its peer.  When Initiator initializes
   the Base Exchange, a Responder host may include an E-LOCATOR
   parameter in the R1 packet that it sends to the Initiator.  This
   parameter MUST be protected by the R1 signature.

   The procedure of Base Exchange with RVS is followed:

   1.  First of all, Responder registers a RVS service with a RVS
       server; its current available IP addresses are maintained by the
       RVS.
   2.  An Initiator initializes the Base Exchange.  First, it sends I1
       packet with Initiator's and may be Responder's HIT, to the RVS,
       with which the Responder registers.  The source IP address of I1
       is Initiator's IP address.  The destination IP address of I1 is
       RVS's IP address that can be got from a DNS server or other
       servers.
   3.  Then the RVS found that I1 is aimed to the Responder, so it
       updates the head of I1 packet and forwards it to the Responder.
       The source IP address of I1 is RVS's IP address.  The destination
       address is currently available IP address of the Responder
       [RFC5204].
   4.  After authentication, the Responder sends R1 packet to the
       Initiator; an E-LOCATOR parameter is included in R1.  This
       parameter is protected by the R1 signature.  Currently available
       IP addresses of the Responder with corresponding flow are list in
       E-LOCATOR.
   5.  When the Initiator gets the R1 packet, according to the flow that
       to be transferred, it chooses the most suitable address among the
       entire addresses list in the E-LOCATOR, that is to say, choose
       the locator with the FID the same as the flow to be transferred.
       If there is only one locator in the parameter, then the Initiator
       chooses it as the communication address.  If there is no locator
       with the corresponding flow, then the Initiator may choose the
       preferred locator to use.  The Initiator should set the status as
       ACTIVE once an address has been determined and send the I2 packet
       to the new choose address.  The I1 destination address and the
       new choose address may be identical.  All new other locators must
       still undergo address verification once the Base Exchange
       completes [RFC5206].

   During the Base Exchange, as the Initiator knows what kind of flow is
   to be transferred, it can make its most suitable address as the



Cao, et al.             Expires September 7, 2011               [Page 5]


Internet-Draft              HIP Flow Mobility                 March 2011


   source address.  The Initiator may include one or more E-LOCATOR
   parameters in the I2 packet, independent of whether or not there was
   a E-LOCATOR parameter in the R1.  These parameters must be protected
   by the I2 signature.  Even if the I2 packet contains E-LOCATOR
   parameters, the Responder must still send the R2 packet to the source
   address of the I2.  The new choosing address by the Responder should
   be identical to the I2 source address.  If the I2 packet contains
   E-LOCATOR parameters, all new locators must undergo address
   verification as usual, and the ESP traffic that subsequently follows
   should use the addresses determined during the Base Exchange.

3.3.  Flow Mobility

   When a multi-homed host moves to a new place, the available address
   may be changed or there may be a new address available and the new
   address is more suitable for the existing flow, the multi-homed host
   can send UPDATE message to its peer to inform the new available or
   new more suitable address and then redirect the existing flow to the
   new address.

3.3.1.  Readdress without Rekey

        Mobile Host                         Peer Host

                UPDATE(ESP_INFO, E-LOCATOR, SEQ)
           -----------------------------------v
                UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
           v-----------------------------------
                UPDATE(ACK, ECHO_RESPONSE)
           -----------------------------------v

                     Figure 1: Readdress without Rekey

   According to RFC5206, during the procedure of readdressing, hosts can
   use the old SAs or create new SAs.  The first example considers the
   case in which no rekeying occurs on the SAs and the new IP address
   are within the same address family (Ipv4 or Ipv6) as the first
   address.  The scenario is depicted in Figure 1.

   1.  The multi-homed host is disconnected from the peer host for a
       short period of time while it switches from one IP address to
       another.  Upon obtaining a new IP address, the multi-homed host
       sends an E-LOCATOR parameter to the peer host in an UPDATE
       message.  The same FID as existing flow must be included with the
       new locator.  Set of ESP_INFO and SEQ parameters are the same as
       RFC5206 3.2.1 depicts.





Cao, et al.             Expires September 7, 2011               [Page 6]


Internet-Draft              HIP Flow Mobility                 March 2011


   2.  When the peer host receives the UPDATE message, it performs as
       RFC5206 3.2.1 depicts.
   3.  The multi-homed host completes the readdress by processing the
       UPDATE ACK and echoing the nonce in an ECHO_RESPONSE.  Once the
       peer host receives this ECHO_RESPONSE, it considers the new
       address to be verified and can put the address into full use.
   4.  The existing ESP traffic flow is transferred to the new address.

3.3.2.  Readdress with Multi-homed-Initiated Rekey

   If the Multi-homed host decide to rekey the SAs at the same time that
   it notifies the peer of the new address.  In this case, the above
   procedure described in Figure 2 is slightly modified.  The UPDATE
   message sent from the Multi-homed host includes an ESP_INFO with the
   OLD SPI set to the previous SPI, the NEW SPI set to the desired new
   SPI value for the incoming SA, and the KEYMAT Index desired.
   Optionally, the host may include a DIFFIE_HELLMAN parameter for a new
   Diffie- Hellman key.  The peer completes the request for a rekey as
   is normally done for HIP rekeying, except that the new address is
   kept as UNVERIFIED until the UPDATE nonce challenge is received as
   described above.  Figure 2 illustrates this scenario.

        Mobile Host                         Peer Host
      UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])
           -----------------------------------v
      UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
           v-----------------------------------
      UPDATE(ACK, ECHO_RESPONSE)
           -----------------------------------v

           Figure 2: Readdress with Multi-homed-Initiated Rekey

3.3.3.  Load balance

                   / peer1                           / peer1
              IP1 +- peer2                      IP1 +
            /(FIDx)\ peer3                    /(FIDx)\ peer2
   Multi-  /                ---> Multi-homed /
   homed   \                     Host        \
   Host     \                                 \
             \                                 \
              IP2                               IP2 -- peer3
             (FIDx)                            (FIDx)

                          Figure 3: Load Balance






Cao, et al.             Expires September 7, 2011               [Page 7]


Internet-Draft              HIP Flow Mobility                 March 2011


        Mobile Host                         Peer 3
      UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])
           -----------------------------------v
      UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
           v-----------------------------------
      UPDATE(ACK, ECHO_RESPONSE)
           -----------------------------------v

                        Figure 4: Flow Redirection

   Considering the scenario that the multi-homed host has two address
   IP1, I23, which both are suitable for transferring flow X, identified
   by FIDx.  Peer1 host and Peer2 both have flow X with multi-homed host
   through IP1.  A new flow X is started between multi-homed host and
   Peer3, also using IP1.  Then in order to make load balance, multi-
   homed host decides to redirect flow X with Peer3 to IP3.  It then
   sends an UPDATE message to Peer 3.  E-LOCAOR is included in the
   message, and there is only one locator, carries IP3 with FIDx option
   in the parameter.  Once receiving the UPDATE message, since there is
   only one address available for FIDx, Peer3 redirects the flow X to
   IP3.  The scenario is depicted as Figure 3.  There must be policies
   for a multi-homed host to decide when to redirect the flow and which
   address is redirected to, the policies are out scope of this
   document.



























Cao, et al.             Expires September 7, 2011               [Page 8]


Internet-Draft              HIP Flow Mobility                 March 2011


4.  E-Locator Definition

        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             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Traffic Type   | Locator Type | Locator Length | Reserved |F|P|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Locator Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Locator                            |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 FLOW MOBILITY IDENTIFICATION OPTION           |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Traffic Type   | Locator Type | Locator Length | Reserved   |P|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Locator Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Locator                            |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 FLOW MOBILITY IDENTIFICATION OPTION           |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 5: E-Locator

   F Flag

   A new flag, when the locator carries a corresponding flow
   identification mobility option, it is set to 1; otherwise it is set
   to 0, that means the locator is suitble for all flow;

   Flow Identification Mobility Option: as defined in [RFC6089]




Cao, et al.             Expires September 7, 2011               [Page 9]


Internet-Draft              HIP Flow Mobility                 March 2011


5.  Security Considerations

   TBD.


6.  IANA Considerations

   This document does not require any IANA actions.


7.  Normative References

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", RFC 5204, April 2008.

   [RFC5205]  Nikander, P. and J. Laganier, "Host Identity Protocol
              (HIP) Domain Name System (DNS) Extensions", RFC 5205,
              April 2008.

   [RFC5206]  Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
              Host Mobility and Multihoming with the Host Identity
              Protocol", RFC 5206, April 2008.

   [RFC6089]  Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
              Network Mobility (NEMO) Basic Support", RFC 6089,
              January 2011.


Authors' Addresses

   Zhen Cao
   China Mobile
   28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: zehn.cao@gmail.com










Cao, et al.             Expires September 7, 2011              [Page 10]


Internet-Draft              HIP Flow Mobility                 March 2011


   Hui Deng
   China Mobile
   28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: denghui@chinamobile.com


   Feng Cao
   China Mobile
   28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: fengcao@chinamobile.com



































Cao, et al.             Expires September 7, 2011              [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/