wdiff rfc7109.original rfc7109.txt

Network Working Group
Independent Submission H. Yokota
Internet-Draft D. Kim
Intended status: Experimental
Request for Comments: 7109 KDDI Lab
Expires: May 21, 2014
Category: Experimental D. Kim
ISSN: 2070-1721 JEJU Technopark
B. Sarikaya
F. Xia
Huawei USA
November 17, 2013

Home Agent Initiated
February 2014

Flow Binding Bindings Initiated by Home Agents for Mobile IPv6
draft-yokota-mext-ha-init-flow-binding-11

Abstract

There are scenarios in which the home agent needs to trigger flow
binding operations towards the mobile node 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 Flow
bindings initiated by a home agent are supported for mobile nodes
enabled by both IPv4 and IPv6
enabled mobile nodes. IPv6.

Status of this This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 not an Internet Standards Track specification; it is
published for examination, experimental implementation, and BCP 79.

Internet-Drafts are working documents of
evaluation.

This document defines an Experimental Protocol for the Internet Engineering
Task Force (IETF). Note that
community. This is a contribution to the RFC Series, independently
of any other groups may also distribute
working documents as Internet-Drafts. RFC stream. The list of current Internet-
Drafts is RFC Editor has chosen to publish this
document at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a maximum candidate for any level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 May 21, 2014.
http://www.rfc-editor.org/info/rfc7109.

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

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.
Binding BU/BA (Binding Update (BU)/Binding Acknowledgement(BA) / Binding Acknowledgement)
messages are extended for the mobile node to add, delete, modify, remove
move, refresh, and refresh revoke flow binding bindings in a home agent. agent (HA). The
operations are always initiated by the mobile node.

While the mobile node manipulates flow bindings by 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 balancing, or maintenance in
mobility agent nodes. For the latter case, the mobile node is not
much
very aware of the transport network condition away from it or of the
policy and charging status controlled by the operator, thus operator; thus, the
network needs to request that 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 that the mobile node to initiate flow bindings
in a timely manner. Flow mobility is also supported for the mobile nodes
with an IPv4 home address and an IPv4 address of the home agent agent, as
described in
[RFC5555] is also supported. [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 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.

3.2. Traffic Offload from congested network Congested Network

The 3G operator may want to move traffic flows from the 3G access
network to another network (e.g., WiFi Wi-Fi network) due to instantaneous
traffic increase increases in the 3G access network. Fine-grained traffic
offload is desirable. For example, IMS-based VoIP Voice over IP (VoIP) flows based
on IP Multimedia Subsystems (IMS) must stay in the mobile core
network while video streaming video-streaming flows provided by servers on the
Internet could bypass the mobile core network via WiFi 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 Movement or deletion Deletion in emergency situation an 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 inquiries to
confirm the safety status of family and friends, while non-critical
services such as gaming could would be put considered lower priority. In order
to save the 3G/LTE 3G / Long Term Evolution (LTE) radio resources for
emergency services, non-
critical non-critical services may need to be moved to
another access network or closed down. The home agent requests that
the mobile node to use WiFi Wi-Fi access for non-critical application flows
or to terminate them gracefully gracefully, e.g., by letting it notify the user of
possible QoS degradation or ask him/
her him/her to finish the corresponding
applications before taking any action.

3.4. Service-specific data cap Service-Specific Data Cap

The mobile operator offers a mobile broadband service with a flat
rate subscription limited to 5G Byte 5 GB per month. Once the allotment is
used up, the service is downgraded to 64 K bits per second. kbits/s. This limitation,
however, is not applied to IMS-based services (e.g.,
VoLTE), 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 Binding Update (BU) / Binding Acknowledgement
(BA) signalling BU/BA signaling to forward, i.e. i.e., register or discard
discard, a flow binding in a home agent. Flow binding operations are
always initiated from the mobile node. In this document, the The basic principle of the 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) (FBA), are defined. An FBI is used
by the home agent to request flow binding operations to the mobile node
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 binding cache
entries for the mobile node before launching flow binding operations.

Due to access network access-network change on the mobile node mobile-node side, some interface 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 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 an FBI
message, the home agent MUST NOT use an FBI message with that mobile
node again.

4.1. Adding flow bindings 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 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 Flow FID#1 (Flow Identifier (FID)#1. #1).
Based on the operator's policy, the network determines if it needs to
provide separate QoS for the video flow 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 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 [RFC6088], and the video traffic is
exchanged over FID#2.

+----+ +----+
| 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 Call Flow for adding Adding a flow binding Flow Binding

4.2. Deleting flow bindings Flow Bindings

When removing a flow binding, the home agent sends a an FBI with a Flow
Identification Mobility option in which the Flow binding action 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 Flow Bindings

When modifying a flow binding (e.g., changing QoS attributes of the
flow as defined in [I-D.ietf-netext-pmip6-qos]) [PMIP6-QOS]) is needed, the home agent sends the
mobile node a 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
option and contain new attributes attributes, e.g., the in Quality of Service Option.
option.

4.4. Refreshing flow bindings 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
information. Hence, all information previously sent in the last
refreshing message need to be resent, otherwise resent; otherwise, such information
will be lost.

4.5. Moving flow bindings 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
an FBI message to the mobile node. The Action field of the flow binding
action Flow
Binding Action sub-option is set to Move Move, and the address of the
target interface is also included in the Target Care-of Address sub-option. 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. option.

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

Figure 2: Example call flow Call Flow for moving Moving a flow binding Flow Binding

4.6. Revoking flow bindings 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 an FBI message with a Flow
Identification Mobility option in which the Flow binding action 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.

The difference from between revoking and deleting flow bindings in Section 4.2
(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]. [RFC5846] even if the mobile node does
not take any action.

5. Handling of the Flow Bindings List

Flow

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

If an FBI contains a flow binding add 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 FID-PRI, and Action fields are taken from the Flow
Identification Mobility Option. BID 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 available, it may be
replaced by Care-of-Address. Target Care-of Address.

If an FBI contains a flow binding delete 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 where option with the action field is 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 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 entry, setting the values as defined in the Flow Identification
Mobility Option. option.

If an FBI contains a flow binding refresh 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 Active/
Inactive
the Active/Inactive Flag to Active.

If an FBI contains a flow binding move 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 care-of address in the Flow Identification
Mobility
Option. option.

If an FBI contains a flow binding switch 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 as well as 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 keepalives keepalive mechanisms defined in
[RFC5555] MUST be used. When the mobile node and home agent are in
IPv6-only and IPv4-only networks, 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 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

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) (21) for Flow Binding message
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
Sequence #
A 16-bit unsigned integer used by the home agent to match a
returned Flow Binding Acknowledgement with this the Flow Binding
Indication. It could be a random number.

Trigger
8-bit unsigned integer indicating the event which 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 Out-of-Sync BCE State

250-255 Reserved For for Testing Purposes only Only

All the other values are unassigned 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 options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Flow
Identification Mobility Options 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, add, delete, modify, refresh,
move, or Switch revoke a flow binding. On receiving messages with Flow
Identification Mobility Option(s), option(s), the mobile node should copy each
Flow Identification Mobility Option option to the Acknowledgement messages. message.
The Flow Binding Acknowledgement has the MH Type value (IANA-TBD1) (21) for Flow
Binding message 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:

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 of the Status field 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 Success

128 Binding (target CoA) Does NOT Exist

129 Action NOT Authorized

All the other values are unassigned unassigned.

Mobility Options 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 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 options as defined in [RFC6089] with the extensions defined
in this document.

6.2. New Options

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

6.2.1. Flow binding action sub-option 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 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.

Figure 5: Flow binding action sub-option Binding Action Sub-Option

Sub-opt Type
To be assigned by IANA (IANA-TBD2)
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 the other values are unassigned unassigned.

6.2.2. Target Care-of-Address sub-option Care-of Address Sub-Option

This section introduces the Target Care-of-Address Care-of Address sub-option, which
may be included in the Flow Identification Mobility Option. option. This
sub-option is used to indicate to the mobile node to move 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 Care-of Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Sub-opt Type
To be assigned by IANA (IANA-TBD3)
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 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] [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 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

This document requires the following Considerations

IANA actions. has taken the actions described below.

Action-1
This specification defines a new Mobility Header Type, "Flow
Binding message". Message". This mobility header Mobility Header message is described in
Section 6.1 6.1, and the type value for this messages is <IANA-TBD1> 21, which has
been assigned from in the Mobility "Mobility Header Types registry [to be removed
upon publication:
http://www.iana.org/assignments/mobility-parameters]. - for the MH Type
field in the Mobility Header" registry.

Action-2
This specification defines "Flow Binding Type" and requires Type". IANA has created
a new
registry as a sub-registry within the registry "Mobile IPv6
parameters". 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 | <this draft> [RFC7109] |
+-------+------------------------------+--------------+
| 2 | Flow Binding Acknowledgement | <this draft> [RFC7109] |
+-------+------------------------------+--------------+
| 3-255 | Unassigned | |
+--------------------------------------+--------------+

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

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

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

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

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

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

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

Action-5
This specification defines two new Flow Identification Sub- sub-
options: the "Flow binding action" Binding Action" sub-option and "Target Care-of- Care-of
Address" sub-option. These sub-options are described in Sections
6.2.1 and 6.2.2 6.2.2, and the sub-option values are <IANA-TBD2> 4 and
<IANA-TBD3>, 5,
respectively, as assigned from in the Flow "Flow Identification
Sub-options registry [to be removed upon publication:
http://www.iana.org/assignments/mobility-parameters]. Sub-options"
registry.

Action-6
This specification defines "Flow Binding Action Values" and
requires Values". IANA has
created a new registry as a sub-registry within the registry "Mobile IPv6 parameters". 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 | <this draft> [RFC7109] |
+--------+-------------------------------------+--------------+
| 12 | Delete a flow binding | <this draft> [RFC7109] |
+--------+-------------------------------------+--------------+
| 13 | Modify a flow binding | <this draft> [RFC7109] |
+--------+-------------------------------------+--------------+
| 14 | Refresh a flow binding | <this draft> [RFC7109] |
+--------+-------------------------------------+--------------+
| 15 | Move a flow binding | <this draft> [RFC7109] |
+--------+-------------------------------------+--------------+
| 16 | Revoke a flow binding | <this draft> [RFC7109] |
+--------+-------------------------------------+--------------+
| 17-255 | Unassigned | |
+--------+-------------------------------------+--------------+

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

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.

[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 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.

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

[RFC5226] Narten, T.

[RFC6146] Bagnulo, M., Matthews, P., and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section 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 RFCs", BCP 26, IPv6", RFC 5226,
May 2008. 6275, July 2011.

10.2. Informative references

[I-D.ietf-netext-pmip6-qos] References

[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-05 (work Work in progress),
November Progress, December 2013.

Authors' Addresses

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

Phone:
Email:
Japan

EMail: yokota@kddilabs.jp

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

Phone:
Email: da-kim@kddilabs.jp
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 Drive, Building 3
Plano, TX 75024
US

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

Frank Xia
Huawei USA
5430 Legacy Dr. Building 3
Plano, TX 75024 Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China

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