Skip to main content

Home Agent Initiated Flow Binding for Mobile IPv6
draft-yokota-mext-ha-init-flow-binding-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7109.
Authors Hidetoshi Yokota , Dae-Sun Kim , Behcet Sarikaya , Frank Xia
Last updated 2013-06-04
RFC stream Independent Submission
Formats
IETF conflict review conflict-review-yokota-mext-ha-init-flow-binding, conflict-review-yokota-mext-ha-init-flow-binding, conflict-review-yokota-mext-ha-init-flow-binding, conflict-review-yokota-mext-ha-init-flow-binding, conflict-review-yokota-mext-ha-init-flow-binding, conflict-review-yokota-mext-ha-init-flow-binding
Additional resources
Stream ISE state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 7109 (Experimental)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-yokota-mext-ha-init-flow-binding-04
Network Working Group                                          H. Yokota
Internet-Draft                                                    D. Kim
Intended status: Standards Track                                KDDI Lab
Expires: December 6, 2013                                    B. Sarikaya
                                                                  F. Xia
                                                              Huawei USA
                                                            June 4, 2013

           Home Agent Initiated Flow Binding for Mobile IPv6
               draft-yokota-mext-ha-init-flow-binding-04

Abstract

   There are scenarios in which the home agent needs to trigger flow
   binding operations towards the mobile node such as moving a flow from
   one access network to another based on the network resource
   availability.  In order for the home agent to be able to initiate
   interactions for flow bindings with the mobile node, this document
   defines new signaling messages and sub-options for Mobile IPv6.  Home
   agent initiated flow bindings are supported for both IPv4 and IPv6
   enabled mobile nodes.

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 December 6, 2013.

Copyright Notice

   Copyright (c) 2013 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

Yokota, et al.          Expires December 6, 2013                [Page 1]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

   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
   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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  QoS provisioning . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Traffic Offload from congested network . . . . . . . . . .  4
     3.3.  Flow movement or deletion in emergency situation . . . . .  4
     3.4.  Service-specific data cap  . . . . . . . . . . . . . . . .  4
   4.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Adding flow bindings . . . . . . . . . . . . . . . . . . .  5
     4.2.  Deleting flow bindings . . . . . . . . . . . . . . . . . .  6
     4.3.  Modifying flow bindings  . . . . . . . . . . . . . . . . .  6
     4.4.  Refreshing flow bindings . . . . . . . . . . . . . . . . .  6
     4.5.  Moving flow bindings . . . . . . . . . . . . . . . . . . .  7
     4.6.  Revoking flow bindings . . . . . . . . . . . . . . . . . .  7
   5.  Handling of the Flow Bindings List . . . . . . . . . . . . . .  8
   6.  Flow Binding Messages and Options  . . . . . . . . . . . . . .  9
     6.1.  Mobility Header  . . . . . . . . . . . . . . . . . . . . .  9
       6.1.1.  Flow Binding Indication  . . . . . . . . . . . . . . .  9
       6.1.2.  Flow Binding Acknowledgement . . . . . . . . . . . . . 10
       6.1.3.  Flow Binding Revocation Extensions . . . . . . . . . . 11
     6.2.  New Options  . . . . . . . . . . . . . . . . . . . . . . . 11
       6.2.1.  Flow binding action sub-option . . . . . . . . . . . . 11
       6.2.2.  Target Care-of-Address sub-option  . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Protocol constants . . . . . . . . . . . . . . . . . . . . . . 13
   9.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative references . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Yokota, et al.          Expires December 6, 2013                [Page 2]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

1.  Introduction

   [RFC6089] allows a mobile node to bind a particular flow to a care-of
   address without affecting other flows using the same home address.
   Binding Update (BU)/Binding Acknowledgement(BA) messages are extended
   for the mobile node to add, modify, remove and refresh flow binding
   in a home agent.  The operations are always initiated by the mobile
   node.

   While the mobile node manipulates flow bindings by e.g., the user
   interaction or the change of the attached link condition, these
   operations are also required for network-related reasons such as
   dynamic QoS control in the network, load balancing or maintenance in
   mobility agent nodes.  For the latter case, the mobile node is not
   much aware of the transport network condition away from it or policy
   and charging status controlled by the operator, thus the network
   needs to request the mobile node to handle proper flow bindings.

   This document defines a new Mobility Header and messages in order for
   the home agent to request the mobile node to initiate flow bindings
   in a timely manner.  Flow mobility for the mobile nodes with IPv4
   home address and IPv4 address of the home agent as described in
   [RFC5555] is also supported.

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
   [RFC6275] and [RFC6089].

3.  Use Cases

3.1.  QoS provisioning

   When the user launches a video chat application and starts sending
   voice and video to the other end, the network may need to provide
   different QoS treatments to these media based on the operator's
   policy.  In such a case, the network needs to request the user or
   mobile node to establish separate flows for voice and video.

Yokota, et al.          Expires December 6, 2013                [Page 3]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

3.2.  Traffic Offload from congested network

   The 3G operator may want to move traffic flows from the 3G access to
   another (e.g., WiFi network) due to instantaneous traffic increase in
   the 3G access network.  Fine-grained traffic offload is desirable.
   For example, IMS-based VoIP flows must stay in the mobile core
   network while video streaming flows provided by servers on the
   Internet could bypass the mobile core network via WiFi access.  Since
   the network knows more about its conditions and has access to the
   policy server, more timely and well-controlled traffic offloading is
   possible.  The home agent sends an updated flow descriptor to be
   offloaded to the mobile node.

3.3.  Flow movement or deletion in emergency situation

   In an emergency situation caused by a natural disaster, it is
   necessary to accept as many voice calls as possible for safety
   inquiry to confirm the safety status of family and friends, while
   non-critical services such as gaming could be put lower priority.  In
   order to save the 3G/LTE radio resources for emergency services, non-
   critical services may need to be moved to another access or closed
   down.  The home agent requests the mobile node to use WiFi access for
   non-critical application flows or to terminate them gracefully e.g.,
   by letting it notify the user of possible QoS degradation or ask him/
   her to finish the corresponding applications before taking any
   action.

3.4.  Service-specific data cap

   The mobile operator offers a mobile broadband service with a flat
   rate subscription limited to 5G Byte per month.  Once the allotment
   is used up, the service is downgraded to 64 K bits per second.  This
   limitation, however, is not applied to IMS-based services (e.g.,
   VoLTE), while video conversations over the Internet will be affected.
   The operator can indicate this to the user by sending modified flow
   descriptors as a proposal to adjust the communication data rate or
   change access for an ongoing session.

4.  Protocol Operation

   [RFC6089] makes use of Binding Update (BU) / Binding Acknowledgement
   (BA) signalling to forward, i.e. register or discard a flow binding
   in a home agent.  Flow binding operations are always initiated from
   the mobile node.  In this document, the basic principle of the
   specification is that the home agent prompts the mobile node to
   perform flow binding operations.  For this purpose, a new Mobility
   Header and two new messages, that is, Flow Binding Indication (FBI)

Yokota, et al.          Expires December 6, 2013                [Page 4]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

   and Flow Binding Acknowledgement (FBA) are defined.  FBI is used by
   the home agent to request flow binding operations to the mobile node
   and FBA is used for acknowledging FBI.  In order for the flow binding
   operation to be complete, BU/BA exchange MUST be initiated by the
   mobile node after FBI/FBA exchange.

   It is assumed that the home agent has already created Binding Cache
   entries for the mobile node before launching flow binding operations.

   Due to access network change on the mobile node side, some interface
   that used to be active may not be valid at the time of flow binding
   operation by the home agent, in which case, even if the HA sends the
   FBI to the MN, the FBA will not return.  After retransmitting the
   FBIs for MAX_FBI_RETRIES times and not receiving the FBA, the HA
   determines that the target interface is not available.

   If the mobile node does not support the FBI message, it responds with
   a Binding Error message with status set to 2 (unrecognized mobility
   header (MH) type value) as described in [RFC6275].  When the Binding
   Error message with status set to 2 is received in response to a FBI
   message, the home agent MUST NOT use FBI message with that mobile
   node again.

4.1.  Adding flow bindings

   Adding the flow binding implies associating a particular flow with
   one of the care-of addresses on the mobile node.  The care-of address
   concerned with the flow binding is present in the destination address
   of the packet or the alternate care-of address option.
   Alternatively, the care-of address may be indicated by the Target
   Care-of Address sub-option defined in Section 6.2.2.

   When adding a new flow binding, the home agent sends a FBI with a
   Flow Identification Mobility option to the mobile node.  In Figure 1,
   which is shown as an example for this operation, the mobile node
   exchanges both voice and video over Flow Identifier (FID)#1.  Based
   on the operator's policy, the network determines to provide separate
   QoS for the video flow and the home agent sends the FBI to the mobile
   node.  The Flow Identification Mobility option defined in [RFC6089]
   includes the current FID and the Traffic Selector (TS) to specify the
   video flow.  The Flow binding action sub-option MUST indicate Add
   operation defined in Section 6.2.1.  The mobile node returns the FBA
   to the home agent with the same options.  The BU/BA exchange follows
   afterwards to perform the actual flow binding as defined in RFC6088
   and the video traffic is exchanged over FID#2.

Yokota, et al.          Expires December 6, 2013                [Page 5]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

                  +----+                           +----+
                  | MN |                           | HA |
                  +----+                           +----+
                    |       FID#1(voice+video)       |
                    |/==============================\|
                    |\==============================/|
                    |                                |
                    |    FBI(add,FID#1,TS[video])    |
                    |<-------------------------------|
                    |      FBA(FID#1,TS[video])      |
                    |------------------------------->|
                    |       BU(FID#2,TS[video])      |
                    |------------------------------->|
                    |       BA(FID#2,TS[video])      |
                    |<-------------------------------|
                    |                                |
                    |         FID#1(voice)           |
                    |<==============================>|
                    |         FID#2(video)           |
                    |<==============================>|

           Figure 1: Example call flow for adding a flow binding

4.2.  Deleting flow bindings

   When removing a flow binding, the home agent sends a FBI with a Flow
   Identification Mobility option in which the Flow binding action sub-
   option indicates Delete operation.  The Flow Identification Mobility
   option includes a unique FID for the mobile node to locate the flow
   binding and remove it.

4.3.  Modifying flow bindings

   When modifying a flow binding (e.g., changing QoS attributes of the
   flow as defined in [I-D.ietf-netext-pmip6-qos]) is needed, the home
   agent sends the mobile node a FBI message with Flow Identification
   Mobility option.  The option includes the FID to be modified.  A
   Traffic Selector sub-option MAY come with the Flow Identification
   Mobility Option and contain new attributes e.g., in Quality of
   Service Option.

4.4.  Refreshing flow bindings

   A flow binding is refreshed by simply including the Flow
   Identification Mobility option with Refresh Action field in the FBI
   message.  The message should be sent before the expiration of the
   flow binding.  The message updates existing bindings with new
   information.  Hence, all information previously sent in the last

Yokota, et al.          Expires December 6, 2013                [Page 6]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

   refreshing message need to be resent, otherwise such information will
   be lost.

4.5.  Moving flow bindings

   The home agent can request to move a flow associated with one
   interface of the multi-interfaced mobile node to another by sending a
   FBI message to the mobile node.  The Action field of the flow binding
   action sub-option is set to Move and the address of the target
   interface is also included in Target Care-of Address sub-option.
   After the FBA is returned to the home agent, the flow mobility is
   performed by the mobile node.  Figure 2 shows the movement of a flow
   label as FID from the interface with sCoA to that with tCoA, which is
   stored in the Binding Identity Mobility Option.

                  +----+                           +----+
                  | MN |                           | HA |
                  +----+                           +----+
                   |<=sCoA                           |
                   | |<=tCoA                         |
                   | |         FBI(FID,tCoA)         |
                   |<--------------------------------|
                   | |         FBA(FID,tCoA)         |
                   |-------------------------------->|
                   | |                               |
                   | |        BU(BID[tCoA],FID)      |
                   | |------------------------------>|
                   | |        BA(BID[tCoA],FID)      |
                   | |<------------------------------|
                   | |                               |

           Figure 2: Example call flow for moving a flow binding

4.6.  Revoking flow bindings

   When the home agent or the network attached to it is overloaded, the
   home agent can revoke a flow binding registered by the mobile node.
   The home agent sends the mobile node a FBI message with a Flow
   Identification Mobility option in which the Flow binding action sub-
   option indicates Revoke operation.  When the MN receives the FBI
   message with Revoke operation, it decides whether the flow should be
   removed (de-registration) or moved to another interface and returns
   the FBA with an appropriate status code.  The mobile node SHOULD take
   an action by sending a new BU, for example, to deregister the flow.

   The difference from deleting flow bindings in Section 4.2 is that
   even if the mobile node does not take any action, the target flow may
   be revoked by the network with the procedures defined in [RFC5846].

Yokota, et al.          Expires December 6, 2013                [Page 7]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

5.  Handling of the Flow Bindings List

   Flow bindings list defined in [RFC6089] needs to be modified after
   each protocol operation defined above as follows:

   If FBI contains a flow binding add operation and if the corresponding
   FBA has a status code equal to zero, home agent MUST add a new entry
   to the flow bindings list.  FID, Flow Descriptor, FID-PRI and Action
   fields are taken from the Flow Identification Mobility Option.  BID
   is copied from the Binding Reference sub-option.  Active/Inactive
   Flag is set to Active.  Note that if BID is not available it may be
   replaced by Care-of-Address.

   If FBI contains a flow binding delete operation and if the
   corresponding FBA has a status code equal to zero, home agent MUST
   locate the list entry corresponding to this flow and then delete the
   entry.

   If the home agent sends a Binding Revocation Indication message with
   Flow Mobility Option where the action field is set to Revoke and if
   the corresponding Binding Revocation Acknowledgement message
   indicates acceptance, home agent MUST locate the list entry
   corresponding to this flow and then delete the entry.

   If FBI contains a flow binding modify operation and if the
   corresponding FBA has a status code equal to zero, home agent MUST
   delete the list entry corresponding to this flow and then add a new
   entry setting the values as defined in the Flow Identification
   Mobility Option.

   If FBI contains a flow binding refresh operation and if the
   corresponding FBA has a status code equal to zero, home agent MUST
   locate the list entry corresponding to this flow and then set Active/
   Inactive Flag to Active.

   If FBI contains a flow binding move operation and if the
   corresponding FBA has a status code equal to zero, home agent MUST
   locate the list entry corresponding to this flow and then change the
   BID value to the Care-of-Address in the Flow Identification Mobility
   Option.

   If FBI contains a flow binding switch operation and if the
   corresponding FBA has a status code equal to zero, home agent MUST
   locate the list entry corresponding to this flow and then delete the
   entry.

   Flow binding operations apply equally to IPv6 packets as well as IPv4
   packets as in Dual-Stack Mobile IPv6 [RFC5555].

Yokota, et al.          Expires December 6, 2013                [Page 8]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

6.  Flow Binding Messages and Options

6.1.  Mobility Header

   The messages described below follow the Mobility Header format
   specified in Section 6.1 of [RFC6275].

6.1.1.  Flow Binding Indication

   The Flow Binding Indication messages are used by the home agent to
   initiate flow binding operations to the mobile node.  The Flow
   Binding Indication messages use the MH Type value (IANA-TBD1) for
   Flow Binding message and a Flow Binding Type value of 1, and the
   format of the Message Data field in the Mobility Header is as
   follows:

      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
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |      Flow Binding Type = 1    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Sequence #           |   Trigger     |A|  Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3: Flow Binding Indication Mobility Header Format

   Sequence #
      A 16-bit unsigned integer used by the home agent to match a
      returned Flow Binding Acknowledgement with this Flow Binding
      Indication.  It could be a random number.

   Trigger
      8-bit unsigned integer indicating the event which triggered the
      home agent to send the Flow Binding Indication message.  The
      following Trigger values are currently defined:

      0  Reserved
      1  Unspecified
      2  Administrative Reason

Yokota, et al.          Expires December 6, 2013                [Page 9]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

      3  Possible Out-of Sync BCE State
      250-255 Reserved For Testing Purposes only
      All the other values are reserved

   Acknowledge (A)
      The Acknowledge (A) bit is set by the home agent to request a Flow
      Binding Acknowledgement be returned upon receipt of the Flow
      Binding Indication.

   Reserved
      These fields are unused.  They MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   Mobility Options
      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  Flow
      Identification Mobility Options are included in this field.

6.1.2.  Flow Binding Acknowledgement

   The Flow Binding Acknowledgement is used to acknowledge receipt of a
   Flow Binding Indication.  The mobile node sends FBA message to
   acknowledge the reception of FBI to Add, Delete, Modify, Refresh,
   Move, or Switch a flow binding.  On receiving messages with Flow
   Identification Mobility Option(s), the mobile node should copy each
   Flow Identification Mobility Option to the Acknowledgement messages.
   The Flow Binding Acknowledgement has the MH Type value (IANA-TBD1)
   for Flow Binding message and a Flow Binding Type value of 2.  When
   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:

      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
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |       Flow Binding Type = 2   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Sequence #           |   Status      |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4: Flow Binding Acknowledgement Mobility Header Format

Yokota, et al.          Expires December 6, 2013               [Page 10]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

   Sequence #
      The sequence number in the Flow Binding Acknowledgement is copied
      from the Sequence Number field in the Flow Binding Indication.

   Status
      8-bit unsigned integer indicating the result of processing the
      Flow Binding Indication message by the receiving mobile node.
      Values of the Status field less than 128 indicate that the Flow
      Binding Indication was processed successfully by the receiving
      node.  Values greater than or equal to 128 indicate that the Flow
      Binding Indication was rejected by the receiving node.  The
      following status values are currently defined:

      0  success
      128  Binding (target CoA) Does NOT Exist
      129  Action NOT Authorized
      All the other values are reserved

   Mobility Options
      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  Flow
      Identification Mobility Options are included in this field.

6.1.3.  Flow Binding Revocation Extensions

   This specification enables Binding Revocation Indication and Binding
   Revocation Acknowledgement messages to carry Flow Identification
   Mobility Options as defined in [RFC6089] with extensions defined in
   this document.

6.2.  New Options

   This document defines new Flow Indication Sub-Options that are
   included in Flow Identification Mobility Option specified in
   [RFC6089].

6.2.1.  Flow binding action sub-option

   This section defines a new sub-option for flow binding actions, which
   MUST be included in the Flow Identification Mobility Option when it
   is sent from the home agent to the mobile node via the FBI message.
   The format of this sub-option is shown in Figure 5.

Yokota, et al.          Expires December 6, 2013               [Page 11]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Sub-opt Type   |Sub-opt Length |  Reserved   |     Action      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5: Flow binding action sub-option

   Sub-opt Type
      To be assigned by IANA (IANA-TBD2)

   Sub-opt Length
      Length of the sub-option in octets, excluding the Sub-opt Type and
      Sub-opt Length fields.

   Action
      This is a 8-bit field that describes the required processing for
      the option.  It can be assigned one of the following new values:

      11  Add a flow binding
      12  Delete a flow binding
      13  Modify a flow binding
      14  Refresh a flow binding
      15  Move a flow binding
      16  Revoke a flow binding
      All the other values are reserved for future use

6.2.2.  Target Care-of-Address sub-option

   This section introduces the Target Care-of-Address sub-option, which
   may be included in the Flow Identification Mobility Option.  This
   sub-option is used to indicate the mobile node to move a flow binding
   from one interface to another.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Sub-opt Type   |Sub-opt Length |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Target Care-of-Address                        |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 6: Target Care-of-Address Sub-option

Yokota, et al.          Expires December 6, 2013               [Page 12]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

   Sub-opt Type
      To be assigned by IANA (IANA-TBD3)

   Sub-opt Length
      Length of the sub-option in octets, excluding the Sub-opt Type and
      Sub-opt Length fields.

   Reserved
      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   Target Care-of-Address
      The address of an interface that the flow is moved to.  This
      address could be IPv4 or IPv6 address.  This sub-option MUST be
      included when the action taken is "15 Move a flow binding".

7.  Security Considerations

   Security issues for this document follow those of [RFC6088],[RFC6089]
   and [RFC5846].  This specification allows the home agent to
   manipulate only the binding of a flow(s) that is currently registered
   with it, which is the same principle described in [RFC5846].  No
   additional security issue specific to this document is identified.

8.  Protocol constants

   Maximum FBI retries (MAX_FBI_RETRIES)
      This variable specifies the maximum number of times the HA MAY
      retransmit a Flow Binding Indication message when FBA is not
      returned within the time period specified by MAX_FBA_TIMEOUT.  The
      default value for this parameter is 3.

   Maximum FBA timeout (MAX_FBA_TIMEOUT)
      This variable specifies the maximum time in seconds the HA MUST
      wait before retransmitting another FBI message.  The default for
      this parameter is 3 seconds.

9.  IANA considerations

   This document defines one new Mobility Header and two new mobility
   options to be used in Flow Binding Initiate and Flow Binding
   Acknowledge messages.  A new Mobility Header Type and two new sub-opt
   type values (IANA-TBD1 through IANA-TBD3) need to be assigned by
   IANA.

Yokota, et al.          Expires December 6, 2013               [Page 13]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

10.  References

10.1.  Normative References

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

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC5846]  Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
              and P. Yegani, "Binding Revocation for IPv6 Mobility",
              RFC 5846, June 2010.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088,
              January 2011.

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

10.2.  Informative references

   [I-D.ietf-netext-pmip6-qos]
              Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
              Gundavelli, "Quality of Service Option for Proxy Mobile
              IPv6", draft-ietf-netext-pmip6-qos-01 (work in progress),
              October 2012.

Yokota, et al.          Expires December 6, 2013               [Page 14]
Internet-Draft  HA Initiated Flow Binding for Mobile IPv6      June 2013

Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara
   Fujimino
   Saitama, Japan  356-8502

   Phone:
   Email: yokota@kddilabs.jp

   Dae-Sun Kim
   KDDI Lab
   2-1-15 Ohara
   Fujimino
   Saitama, Japan  356-8502

   Phone:
   Email: da-kim@kddilabs.jp

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Drive Building 3
   Plano, TX  75024

   Phone: +1 469-277-5839
   Email: sarikaya@ieee.org

   Frank Xia
   Huawei USA
   5430 Legacy Dr. Building 3
   Plano, TX  75024

   Phone:
   Email: xiayangsong@huawei.com

Yokota, et al.          Expires December 6, 2013               [Page 15]