path: root/doc/rfc/rfc7109.txt

Independent Submission                                         H. Yokota
Request for Comments: 7109                                      KDDI Lab
Category: Experimental                                            D. Kim
ISSN: 2070-1721                                          JEJU Technopark
                                                             B. Sarikaya
                                                                  F. Xia
                                                                  Huawei
                                                           February 2014


         Flow Bindings Initiated by Home Agents for Mobile IPv6

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 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.  Flow
   bindings initiated by a home agent are supported for mobile nodes
   enabled by both IPv4 and IPv6.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This is a contribution to the RFC Series, independently
   of any other RFC stream.  The RFC Editor has chosen to publish this
   document at its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7109.











Yokota, et al.                Experimental                      [Page 1]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


Copyright Notice

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

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 an 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 ...............................................12
           6.2.1. Flow Binding Action Sub-Option .....................12
           6.2.2. Target Care-of Address Sub-Option ..................13
   7. Security Considerations ........................................13
   8. Protocol Constants .............................................14
   9. IANA Considerations ............................................14
   10. References ....................................................16
      10.1. Normative References .....................................16
      10.2. Informative References ...................................17








Yokota, et al.                Experimental                      [Page 2]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


1.  Introduction

   [RFC6089] allows a mobile node (MN) to bind a particular flow to a
   care-of address (CoA) without affecting other flows using the same
   home address.  BU/BA (Binding Update / Binding Acknowledgement)
   messages are extended for the mobile node to add, delete, modify,
   move, refresh, and revoke flow bindings in a home agent (HA).  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
   very aware of the transport network condition away from it or of the
   policy and charging status controlled by the operator; thus, the
   network needs to request that the mobile node handle proper flow
   bindings.

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

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.                Experimental                      [Page 3]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


3.2.  Traffic Offload from Congested Network

   The 3G operator may want to move traffic flows from the 3G access
   network to another network (e.g., Wi-Fi network) due to instantaneous
   traffic increases in the 3G access network.  Fine-grained traffic
   offload is desirable.  For example, Voice over IP (VoIP) flows based
   on IP Multimedia Subsystems (IMS) must stay in the mobile core
   network while video-streaming flows provided by servers on the
   Internet could bypass the mobile core network via Wi-Fi 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 an Emergency Situation

   In an emergency situation caused by a natural disaster, it is
   necessary to accept as many voice calls as possible for inquiries to
   confirm the safety status of family and friends, while non-critical
   services such as gaming would be considered lower priority.  In order
   to save the 3G / Long Term Evolution (LTE) radio resources for
   emergency services, non-critical services may need to be moved to
   another access network or closed down.  The home agent requests that
   the mobile node use Wi-Fi access for non-critical application flows
   or 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 5 GB per month.  Once the allotment is
   used up, the service is downgraded to 64 kbits/s.  This limitation,
   however, is not applied to IMS-based services (e.g., Voice over LTE
   (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 BU/BA signaling to forward, i.e., register or
   discard, a flow binding in a home agent.  Flow binding operations are
   always initiated from the mobile node.  The basic principle of this
   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)
   and Flow Binding Acknowledgement (FBA), are defined.  An FBI is used



Yokota, et al.                Experimental                      [Page 4]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


   by the home agent to request flow binding operations to the mobile
   node, and an FBA is used for acknowledging an FBI.  In order for the
   flow binding operation to be complete, a BU/BA exchange MUST be
   initiated by the mobile node after an 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 interfaces
   that used to be active may not be valid at the time of the 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 an FBI
   message, the home agent MUST NOT use an 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 an 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 FID#1 (Flow Identifier #1).
   Based on the operator's policy, the network determines if it needs 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 the 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.                Experimental                      [Page 5]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


                  +----+                           +----+
                  | 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 an FBI with a Flow
   Identification Mobility option in which the Flow Binding Action sub-
   option indicates the 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 [PMIP6-QOS]) is needed, the home agent sends the
   mobile node an FBI message with the 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., the in Quality of Service
   option.

4.4.  Refreshing Flow Bindings

   A flow binding is refreshed by simply including the Flow
   Identification Mobility option with the 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




Yokota, et al.                Experimental                      [Page 6]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


   information.  Hence, all information previously sent in the last
   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
   an 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 the 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 an FBI message with a Flow
   Identification Mobility option in which the Flow Binding Action sub-
   option indicates the Revoke operation.  When the MN receives the FBI
   message with the 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.





Yokota, et al.                Experimental                      [Page 7]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


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

5.  Handling of the Flow Bindings List

   The flow bindings list defined in [RFC6089] needs to be updated as
   follows after each protocol operation defined above is performed:

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

   If an FBI contains a flow binding Delete operation and if the
   corresponding FBA has a status code equal to zero, the 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
   the Flow Identification Mobility option with the action field set to
   Revoke and if the corresponding Binding Revocation Acknowledgement
   message indicates acceptance, the home agent MUST locate the list
   entry corresponding to this flow and then delete the entry.

   If an FBI contains a flow binding Modify operation and if the
   corresponding FBA has a status code equal to zero, the 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 an FBI contains a flow binding Refresh operation and if the
   corresponding FBA has a status code equal to zero, the home agent
   MUST locate the list entry corresponding to this flow and then set
   the Active/Inactive Flag to Active.

   If an FBI contains a flow binding Move operation and if the
   corresponding FBA has a status code equal to zero, the 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.





Yokota, et al.                Experimental                      [Page 8]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


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

   Flow binding operations apply equally to IPv4 packets and IPv6
   packets as per Dual-Stack Mobile IPv6 [RFC5555].  In order to support
   the situation where there is a NAT/firewall between the mobile node
   and home agent, NAT detection and NAT keepalive mechanisms defined in
   [RFC5555] MUST be used.  When the mobile node and home agent are in
   IPv6-only and IPv4-only networks respectively and NAT64 [RFC6146]
   resides in between, each node would behave as if the other node was
   in the same network domain.  Even though this scenario is not fully
   described in [RFC5555], the initial mobility binding is always
   performed by the mobile node, and the binding cache is created in the
   home agent.  The destination address of the FBI SHALL be the mobile
   node's IPv4 care-of address in the binding cache entry.

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

   Flow Binding Indication messages are used by the home agent to
   initiate flow binding operations to the mobile node.  Flow Binding
   Indication messages use the MH Type value (21) for Flow Binding
   messages 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




Yokota, et al.                Experimental                      [Page 9]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


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

   Trigger
      8-bit unsigned integer indicating the event that 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

      3  Possible Out-of-Sync BCE State

      250-255 Reserved for Testing Purposes Only

      All other values are unassigned.

   Acknowledge (A)
      The Acknowledge (A) bit is set by the home agent to request that 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 an FBA message to
   acknowledge the reception of an FBI to add, delete, modify, refresh,
   move, or revoke 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 message.
   The Flow Binding Acknowledgement has the MH Type value (21) for Flow
   Binding messages 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:



Yokota, et al.                Experimental                     [Page 10]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


      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

   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 less than 128 in the Status field 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 other values are unassigned.

   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 the extensions defined
   in this document.



Yokota, et al.                Experimental                     [Page 11]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


6.2.  New Options

   This document defines new Flow Identification sub-options that are
   included in the 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.

      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
      4

   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 other values are unassigned.






Yokota, et al.                Experimental                     [Page 12]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


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 to the mobile node that a flow binding
   is to be moved 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

   Sub-opt Type
      5

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









Yokota, et al.                Experimental                     [Page 13]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


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 the 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

   IANA has taken the actions described below.

   Action-1
      This specification defines a new Mobility Header Type, "Flow
      Binding Message".  This Mobility Header message is described in
      Section 6.1, and the type value for this messages is 21, which has
      been assigned in the "Mobility Header Types - for the MH Type
      field in the Mobility Header" registry.

   Action-2
      This specification defines "Flow Binding Type".  IANA has created
      a new sub-registry within the "Mobile IPv6 parameters" registry.
      Flow Binding Type is described in Sections 6.1.1 and 6.1.2, which
      reserve the following values:

          +-------+------------------------------+--------------+
          | Value |          Description         |   Reference  |
          +-------+------------------------------+--------------+
          |   0   |          Unassigned          |              |
          +-------+------------------------------+--------------+
          |   1   |   Flow Binding Indication    |   [RFC7109]  |
          +-------+------------------------------+--------------+
          |   2   | Flow Binding Acknowledgement |   [RFC7109]  |
          +-------+------------------------------+--------------+
          | 3-255 |          Unassigned          |              |
          +--------------------------------------+--------------+

      Future assignments in the "Flow Binding Type" registry are to be
      made through RFC Required [RFC5226].







Yokota, et al.                Experimental                     [Page 14]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


   Action-3
      This specification defines "Flow Binding Indication Triggers".
      IANA has created a new sub-registry within the "Mobile IPv6
      parameters" registry.  The trigger values are described in
      Section 6.1.1, which reserves the following values:

      +---------+------------------------------------+--------------+
      |  Value  |             Description            |   Reference  |
      +---------+------------------------------------+--------------+
      |    0    |             Reserved               |   [RFC7109]  |
      +---------+------------------------------------+--------------+
      |    1    |            Unspecified             |   [RFC7109]  |
      +---------+------------------------------------+--------------+
      |    2    |      Administrative Reason         |   [RFC7109]  |
      +---------+------------------------------------+--------------+
      |    3    |   Possible Out-of-Sync BCE State   |   [RFC7109]  |
      +---------+------------------------------------+--------------+
      |  4-249  |             Unassigned             |              |
      +---------+------------------------------------+--------------+
      | 250-255 | Reserved for Testing Purposes Only |   [RFC7109]  |
      +----------------------------------------------+--------------+

      Future assignments in the "Flow Binding Indication Triggers"
      registry are to be made through RFC Required [RFC5226].

   Action-4
      This specification defines "Flow Binding Acknowledgement Status
      Codes".  IANA has created a new sub-registry within the "Mobile
      IPv6 parameters" registry.  The status codes are described in
      Section 6.1.2, which reserves the following values:

     +---------+-------------------------------------+--------------+
     |  Value  |             Description             |   Reference  |
     +---------+-------------------------------------+--------------+
     |    0    |              Success                |   [RFC7109]  |
     +---------+-------------------------------------+--------------+
     |  1-127  |             Unassigned              |              |
     +---------+-------------------------------------+--------------+
     |   128   | Binding (target CoA) Does NOT Exist |   [RFC7109]  |
     +---------+-------------------------------------+--------------+
     |   129   |       Action NOT Authorized         |   [RFC7109]  |
     +---------+-------------------------------------+--------------+
     | 130-255 |             Unassigned              |              |
     +---------+-------------------------------------+--------------+

      Future assignments in the "Flow Binding Acknowledgement Status
      Codes" are to be made through RFC Required [RFC5226].




Yokota, et al.                Experimental                     [Page 15]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


   Action-5
      This specification defines two new Flow Identification sub-
      options: the "Flow Binding Action" sub-option and "Target Care-of
      Address" sub-option.  These sub-options are described in Sections
      6.2.1 and 6.2.2, and the sub-option values are 4 and 5,
      respectively, as assigned in the "Flow Identification Sub-options"
      registry.

   Action-6
      This specification defines "Flow Binding Action Values".  IANA has
      created a new sub-registry within the "Mobile IPv6 parameters"
      registry.  The action values are described in Section 6.2.1, which
      reserves the following values:

      +--------+-------------------------------------+--------------+
      |  Value |             Description             |   Reference  |
      +--------+-------------------------------------+--------------+
      |  0-10  |              Unassigned             |              |
      +--------+-------------------------------------+--------------+
      |   11   |           Add a flow binding        |   [RFC7109]  |
      +--------+-------------------------------------+--------------+
      |   12   |         Delete a flow binding       |   [RFC7109]  |
      +--------+-------------------------------------+--------------+
      |   13   |         Modify a flow binding       |   [RFC7109]  |
      +--------+-------------------------------------+--------------+
      |   14   |       Refresh a flow binding        |   [RFC7109]  |
      +--------+-------------------------------------+--------------+
      |   15   |          Move a flow binding        |   [RFC7109]  |
      +--------+-------------------------------------+--------------+
      |   16   |        Revoke a flow binding        |   [RFC7109]  |
      +--------+-------------------------------------+--------------+
      | 17-255 |             Unassigned              |              |
      +--------+-------------------------------------+--------------+

      Future assignments in the "Flow Binding Action Values" registry
      are to be made through RFC Required [RFC5226].















Yokota, et al.                Experimental                     [Page 16]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


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.

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

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

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

   [RFC6146]    Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
                NAT64: Network Address and Protocol Translation from
                IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.

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

10.2.  Informative References

   [PMIP6-QOS]  Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
                Gundavelli, "Quality of Service Option for Proxy Mobile
                IPv6", Work in Progress, December 2013.












Yokota, et al.                Experimental                     [Page 17]
^L
RFC 7109           HA-Initiated Flow Binding for MIPv6     February 2014


Authors' Addresses

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

   EMail: yokota@kddilabs.jp


   Dae-Sun Kim
   JEJU Technopark
   217, Jungang-ro (St)
   Jejusi, Jeju Special Self-Governing Province  690-787
   Korea

   EMail: dskim@jejutp.or.kr


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

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


   Frank Xia
   Huawei Technologies Co., Ltd.
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Phone: +86-25-56625443
   EMail: xiayangsong@huawei.com













Yokota, et al.                Experimental                     [Page 18]
^L