Flow Bindings Initiated by Home Agents for Mobile IPv6
KDDI Lab2-1-15 OharaFujiminoSaitamaJapan356-8502yokota@kddilabs.jpJEJU Technopark217, Jungang-ro (St)JejusiJeju Special Self-Governing ProvinceKorea690-787dskim@jejutp.or.krHuawei USA5340 Legacy Drive, Building 3PlanoTX75024US+1 469-277-5839sarikaya@ieee.orgHuawei Technologies Co., Ltd.101 Software Avenue, Yuhua DistrictNanjingJiangsu210012China+86-25-56625443xiayangsong@huawei.comThere 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. 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 .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 .The terminology in this document is based on the definitions in and .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.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.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.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. 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 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 . 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.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 .When adding a new flow binding, the home agent sends an FBI with a
Flow Identification Mobility option to the mobile node. In , 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 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 .
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 , and the video traffic is exchanged
over FID#2.
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.When modifying a flow binding (e.g., changing QoS attributes of the
flow as defined in ) 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.
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, such information will be lost.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. 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.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.The difference between revoking and deleting flow bindings () is that the target flow may be revoked by the network with the
procedures defined in even if the mobile node
does not take any action.The flow bindings list defined in 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.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 . 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 MUST be used. When the mobile node and home
agent are in IPv6-only and IPv4-only networks respectively and NAT64
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 , 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.The messages described below follow the Mobility Header format
specified in Section 6.1 of .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: 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. 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: 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. These fields are
unused. They MUST be initialized to zero by the sender and MUST
be ignored by the receiver.
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.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: The sequence
number in the Flow Binding Acknowledgement is copied from the
Sequence Number field in the Flow Binding Indication.
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:
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.This specification enables Binding Revocation Indication and
Binding Revocation Acknowledgement messages to carry Flow
Identification Mobility options as defined in with the extensions defined in this document.This document defines new Flow Identification sub-options that are
included in the Flow Identification Mobility option specified in .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 .4 Length of
the sub-option in octets, excluding the Sub-opt Type and Sub-opt
Length fields. This is a 8-bit
field that describes the required processing for the option. It
can be assigned one of the following new values:
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.
5 Length of
the sub-option in octets, excluding the Sub-opt Type and Sub-opt
Length fields. This field is
unused. It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.
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".Security issues for this document follow those of , , and . 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 . No additional security issue specific to this
document is identified.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.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.IANA has taken the actions described below.This specification defines a new
Mobility Header Type, "Flow Binding Message". This Mobility Header
message is described in , 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.
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 and , which reserve the following
values:
Future assignments in the "Flow
Binding Type" registry are to be made through RFC Required .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 , which reserves the
following values:
Future assignments in the "Flow
Binding Indication Triggers" registry are to be made through RFC Required
.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 , which reserves the
following values:
Future assignments in the "Flow
Binding Acknowledgement Status Codes" are to be made through RFC
Required .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 and , and the sub-option values are
4 and 5, respectively, as assigned in
the "Flow Identification Sub-options" registry.
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 , which reserves the following
values:
Future assignments in the "Flow
Binding Action Values" registry are to be made through RFC Required .Quality of Service Option for Proxy Mobile IPv6