IETF MONAMI6 Working Group H. Soliman
Internet-Draft Qualcomm
Expires: December 28, 2006 N. Montavont
GET/ENST-B
N. Fikouras
K. Kuladinithi
University of Bremen
June 26, 2006
Flow Bindings in Mobile IPv6
draft-soliman-monami6-flow-binding-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document introduces extensions to Mobile IPv6 [1] that allow
nodes to bind a particular flow to a care-of address. These
extensions allow multihomed nodes to take full advantage of the
different properties associated with each of their interfaces.
Soliman, et al. Expires December 28, 2006 [Page 1]
Internet-Draft Flow bind June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 5
2.1. Flow Identification option . . . . . . . . . . . . . . . . 5
2.2. Binding Cache and Binding Update list extensions . . . . . 11
3. Protocol operations . . . . . . . . . . . . . . . . . . . . . 13
3.1. Flow binding storage . . . . . . . . . . . . . . . . . . . 14
3.2. Default binding . . . . . . . . . . . . . . . . . . . . . 14
3.3. Adding flow bindings . . . . . . . . . . . . . . . . . . . 15
3.4. Replacing flow bindings . . . . . . . . . . . . . . . . . 15
3.5. Deleting flow bindings . . . . . . . . . . . . . . . . . . 16
3.6. Acknowledging flow identification options . . . . . . . . 16
4. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 19
5.1. Establishing Flow Bindings . . . . . . . . . . . . . . . . 19
5.1.1. Sending Flow Identification options to Home Agents
and Correspondent Nodes . . . . . . . . . . . . . . . 19
5.1.2. Using Alternate Care-Of Address . . . . . . . . . . . 20
5.1.3. Receiving Binding Acknowledgements . . . . . . . . . . 20
5.1.4. Receiving Binding Refresh Requests . . . . . . . . . . 20
5.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Return Routability Procedure . . . . . . . . . . . . . . . 20
5.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 21
6. Correspondant node operations . . . . . . . . . . . . . . . . 22
6.1. Return Routability Procedure . . . . . . . . . . . . . . . 22
6.2. Receiving Binding Udpate . . . . . . . . . . . . . . . . . 22
7. Home Agent operations . . . . . . . . . . . . . . . . . . . . 24
7.1. Receiving Binding Update without flow identification
option . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Receiving Binding Update with flow identification
option(s) . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Sending Binding Ackowledgement . . . . . . . . . . . . . . 25
7.4. Deleting an entry in the binding cache . . . . . . . . . . 25
7.4.1. A binding cache entry expires . . . . . . . . . . . . 25
7.4.2. The mobile node explicitly requests to remove a
binding . . . . . . . . . . . . . . . . . . . . . . . 26
8. Mobility Anchor Point operations . . . . . . . . . . . . . . . 27
9. Security considerations . . . . . . . . . . . . . . . . . . . 28
Soliman, et al. Expires December 28, 2006 [Page 2]
Internet-Draft Flow bind June 2006
10. Open discussion - future work . . . . . . . . . . . . . . . . 29
10.1. Usage of the FID . . . . . . . . . . . . . . . . . . . . . 29
10.2. Multiple Care-of addresses . . . . . . . . . . . . . . . . 29
10.3. Network in Motion . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Soliman, et al. Expires December 28, 2006 [Page 3]
Internet-Draft Flow bind June 2006
1. Introduction
Mobile IPv6 [1]allows a mobile node to manage its mobility using the
binding update message, which binds one care-of address to one home
address. The binding update message can be sent to the home agent or
a correspondent node or to a mobility anchor point [2]. The
semantics of the binding update in Mobile IPv6 are limited to address
changes. That is, [1] does not allow a mobile node to bind more than
one address to the home address. Furthermore, the binding
granularity is limited to the address. Therefore, a mobile node
cannot associate one of the connections using the home address with a
different care-of address. In [3] Mobile IPv6 is extended to allow
the binding of more than one care-of address to a home address. This
specification extends Mobile IPv6 to allow it to specify policies
associated with each binding. A policy can contain a request for a
special treatment of a particular flow. Hence, this specification
allows a mobile node to bind a particular flow to a care-of address
without affecting other flows using the same home address.
In this document, a flow is defined as one or more connections that
are identified by a flow identifier. A single connection is
typically identified by the source and destination IP addresses,
transport protocol number and the source and destination port
numbers. Alternatively a flow can be identified in a simpler manner
using the flow label field in the IPv6 header [4] or the Security
Parameter Index (SPI) when IPsec is used.
Flow bindings are useful in cases where the mobile node has more than
one address, probably due to being multihomed and wants to direct
certain flows to certain addresses. This may be done because some
flows are better suited to certain link layers or simply to load
balance flows between different interfaces. This specification
introduces the flow identifier option, which is included in the
binding update message and used to describe a flow to the recipient
of the binding update. Using the flow identifier option introduced
in this specification a mobile node can bind one or more flows to a
care-of address while maintaining the reception of other flows on
another care-of address. Requesting the flow binding can be decided
based on local policies within the mobile node and based on the link
characteristics and the types of applications running at the time.
Such policies are outside the scope of this document.
It should be noted that the flow identification option can be
associated with any binding update, whether it is sent to a
correspondent node, home agent or mobility anchor point. A Similar
mechanism for Mobile IPv4 is described in [5].
Soliman, et al. Expires December 28, 2006 [Page 4]
Internet-Draft Flow bind June 2006
2. Mobile IPv6 Extensions
This section introduces extensions to Mobile IPv6 that are necessary
for supporting the flow binding mechanism described in this document.
2.1. Flow Identification option
The Flow identification option is included in the binding update and
acknowledgement messages. This option contains information that
allows the receiver of a binding update to identify a traffic flow
and route it to a given address. Multiple options may exist within a
binding update message.
The Flow identification option has a flexible format that allows
different fields to appear in the option based on the way the mobile
node chooses to represent the flow. The flags following the option
length field indicate which of the fields used to identify the flow
are present in the option. As a result, there is no fixed format for
the flow identification option. This may result in slight complexity
in the implementation; however, this option will minimise the size of
the option sent, which is particularly important for bandwidth-
limited wireless links.
Soliman, et al. Expires December 28, 2006 [Page 5]
Internet-Draft Flow bind June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Type | Option Len |S|E|F|L|O|W|T|I|R|H| DEF | PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID | Action | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Res1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Res2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port - Min | Source port - Max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst port - Min | Dst port - Max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Label | Res3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | C. S. | Res4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The flow identification option
Option Type
TBD
Soliman, et al. Expires December 28, 2006 [Page 6]
Internet-Draft Flow bind June 2006
Option Len
Length of option in 8-octet units
S
When set, this flag indicates the presence of the Source address
and Prefix fields in this option.
E
When set, this flag indicates the presence of the Destination
address and prefix fields in this option.
F
When set, this flag indicates the presence of the minimum and
maximum Source port fields in this option. These two fields
express the range of port numbers included in the option.
L
When set, this flag indicates the presence of the minimum and
maximum Destination port fields in this option.
O
When set, this flag indicates the presence of the Protocol field
in this option.
W
When set, this flag indicates the presence of the Flow label field
in this option. The Flow label is always represented by the most
significant 20-bits in a 4-octet field.
T
When set, this flag indicates the presence of the Class of Service
field in this option.
I
When set, this flag indicates the presence of the SPI field in
this option.
Soliman, et al. Expires December 28, 2006 [Page 7]
Internet-Draft Flow bind June 2006
R
When set, this flag indicates that the source address associated
with this flow is the address of the node receiving this binding
update, which is the ultimate destination address in the packet
and MUST be used to identify the flow. The ultimate destination
address is present in the destination address field of the header,
or the routing header type 2 when route optimisation is used.
H
When set, this flag indicates that the destination address
associated with this flow is the source address of this binding
update. This address MUST be used to identify the flow.
DEF
This field indicates the default care-of address entry. It
indicates that the source address of the binding update, or the
address included in the alternate Care-of address option, is the
default address that the receiving node MUST use to redirect a
flow which does not map a flow binding. Default entries can be
ranked when multiple care-of addresses are present. A value of 1
indicates the first priority. Hence, if three addresses are
present, the mobile node can rank them from 1 to 3, where the
address ranked one will be the default address. The address
ranked 2 will become the default address if the binding for the
address ranked 1 is removed for any reason.
PRI
This is a 3-bit priority field to indicate the priority of a
particular option. This field is needed in cases where two
different flow descriptions in two different options overlap. The
priority field decides which policy should be in those cases. A
lower number in this field indicates a higher priority.
FID
The Flow Identifier field is an 8-bit unsigned integer that
includes the identifier for the flow binding. This field is used
to refer to an existing binding or to create a new binding.
Action
This field specifies the action that needs to be taken by the
receiver of the binding update containing the flow identification
option.
Soliman, et al. Expires December 28, 2006 [Page 8]
Internet-Draft Flow bind June 2006
Status
This field indicates the success or failure of the flow binding
operation for the particular flow in the option. This field is
not relevant to the binding update message as a whole or to other
flow identification options. Values from 0 to 127 indicate
success. Values of 128 and higher indicate failure. This field
is only relevant when included in the Binding Acknowledgement
message and must be ignored in the binding update message.
Source Address
This field identifies the source address of data packets as seen
by the receiver of this binding update. That is, the address of
the correspondent node. An IPv4 address of the correspondent must
be included in the IPv4-mapped IPv6 address format.
Source Prefix
This field includes the prefix for the source address. Hence the
combination of those two fields allows for the support of a single
128-bit address or a number of addresses within a prefix.
Destination Address
This field identifies the destination address of the data packet
as seen by the receiver of the binding update. When the host is a
mobile node, this parameter is not relevant: for a correspondent
node, the destination is the home address of the mobile node. For
a mobility anchor point, the destination address would be the
regional care-of address of the mobile node.
Destination Prefix
This field includes the prefix for the destination address. Hence
the combination of those two fields allows for the support of a
single 128-bit address or a number of addresses within a prefix.
Source Port - Min
This field identifies the lowest source port number within a range
of port numbers that will be used in data packets, as seen by the
receiver of the binding update.
Source Port - Max
This field identifies the highest source port number within a
range of port numbers that will be used in data packets, as seen
Soliman, et al. Expires December 28, 2006 [Page 9]
Internet-Draft Flow bind June 2006
by the receiver of the binding update.
Dst Port - Min
This field identifies the lowest destination port number within a
range of port numbers that will be used in data packets as seen by
the receiver of the binding update.
Dst Port - Max
This field identifies the highest destination port number within a
range of port numbers that will be used in data packets as seen by
the receiver of the binding update.
SPI
A 32-bits unsigned integer indicating the Security Parameter Index
present in the IPsec header of the data packet seen by the
receiver of the binding update.
Flow Label
A 20-bit unsigned integer indicating the Flow label present in the
IPv6 header of the data packet seen by the receiver of the binding
update. The next 12 bits are reserved for the alignment of this
field.
Protocol
An 8-bit unsigned integer representing value of the transport
protocol number associated with the port numbers in data packets.
C. S. (Class of Service)
The Class of Service field in the data packet as seen by the
receiver of the binding update.
The following values are reserved for the Action field in this
option:
0 Add a flow binding
1 Replace a flow binding
255 Remove a flow binding
The following values are reserved for the status field within the
Soliman, et al. Expires December 28, 2006 [Page 10]
Internet-Draft Flow bind June 2006
flow identification option:
0 Flow binding successful.
128 Flow binding rejected, reason unspecified.
129 Flow binding option poorly formed.
130 Administratively prohibited.
131 Flow identification by IPv6 prefix is not supported.
132 Flow identification by port numbers is not supported.
133 Flow identification with Flow label is not supported.
134 Flow identification with SPI is not supported.
135 FID already in use
136 FID not found
It should be noted that per-packet load balancing has negative
impacts on TCP congestion avoidance mechanisms as it is desirable to
maintain order between packets belonging to the same TCP connection.
This behaviour is specified in [6]. Other negative impacts are also
foreseen for other types of real time connections due to the
potential variations in RTT between packets. Hence per-packet load
balancing is not allowed in this extension. However, the MN can
still request per-flow load balancing provided that the entire flow
is moved to the new interface.
2.2. Binding Cache and Binding Update list extensions
Flow bindings are conceptually stored in Binding Cache of home agent,
mobility anchor point and correspondent node, and in Binding Update
List of mobile node / mobile router. These logical structures need
to be extended to include the following parameters (in addition to
those described in [1]):
o FID (Flow Identifier). For a given home address, the FID MUST
uniquely identify an entry, i.e. a unique flow binding. An FID is
only unique for a given home address . Different mobile nodes can
use the same FID value.
o Each attribute that constitutes the flow binding. These
attributes were transported in the Flow Identification option.
Soliman, et al. Expires December 28, 2006 [Page 11]
Internet-Draft Flow bind June 2006
An entry in these structures is identified by the couple (home
address, FID).
Soliman, et al. Expires December 28, 2006 [Page 12]
Internet-Draft Flow bind June 2006
3. Protocol operations
This specification allows mobile hosts and routers to direct flows to
a particular care-of address. This can be done by aggregating many
flows in the flow identification option (e.g. all TCP traffic), or by
uniquely identifying a flow in the flow identification option. The
flow identification option is transported within a Binding Update and
can be sent with one or more parameters. The first 8 octets of the
option MUST be present in all cases, while the rest of the parameters
are optional. For instance, the following constructions of the
option, among others (following the first 8 octets), are all legal:
Option 1: Flow label.
Option 2: SPI
Option 3: Source Port - Min, Source Port - Max
Option 4: Source Port - Min, Source Port - Max, Dst Port - Min, Dst
Port - Max
Option 5: Source Port - Min, Source Port - Max, Dst Port - Min, Dst
Port - Max, Protocol
Option 6: Source Address/Prefix, Destination Address/Prefix, Source
Port-Min, Source Port-Max, Dst Port-Min, Dst Port-Max
Option 7: Protocol
In order to respect the alignment rules, the following fields MUST be
followed by reserved bits that MUST be ignored upon reception:
o Source prefix: followed by 24 reserved bits
o Destination prefix : followed by 24 reserved bits
o Protocol: followed by the C.S. field and 16 reserved bits. Note
that the C.S. field can be present and ignored if the T flag was
cleared. The C.S field would only be present for alignment
reasons.
o C.S.: This field is always preceded by the Protocol field and
followed by 12 reserved bits. The Protocol field is always
present and must be ignored if the O flag is cleared.
o Flow label: followed by 12 reserved bits
Soliman, et al. Expires December 28, 2006 [Page 13]
Internet-Draft Flow bind June 2006
This section discusses how mobile hosts and routers can use the flow
identification option when sending binding updates to the
correspondent node, home agent or mobility anchor point. In
Addition, deletion and modification of bindings are all discussed
below.
3.1. Flow binding storage
Home agent, correspondent node and mobility anchor point maintain
Binding Cache in order to record associations between home addresses
and care-of addresses of mobile nodes that are away from the home
link. Mobile node and mobile router maintain binding update list to
record binding between home address and care-of address. RFC 3775
[1] allows mobile nodes and mobile routers to register only one
care-of address per home address. Thus a binding cache entry is
uniquely identified by the home address.
This specification extends the binding cache and the binding update
list structures, and allows mobile node and mobile router to (1)
register multiple care-of addresses for a given home address and (2)
associate flow binding policies with the registered care-of
addresses.
New parameters are added to these conceptual structures in order to
list the particular rule associated with a standard binding. On one
hand, an entry is now identified by the pair (home address, FID)
because several Care-of addresses may be bound to a single home
address. On a second hand, the Care-of address is selected according
to the best match between the packets that need to be sent, and the
existing flow bindings. If no matching is found between the flow
bindings and the data packet, a default entry is used (see next
subsection). If a flow matches two different flow bindings, the PRI
field indicates which action is preferred by the mobile node.
3.2. Default binding
Any distant node which supports the flow identification option MUST
maintain a default binding per home address. A default binding
indicates an association between a home address and a Care-of
address. In addition to the default binding, several bindings may
co-exist within a binding cache for the same home address, each of
them indicating different bindings between flows and Care-of
addresses. When a data flow is intercepted by a home agent or
initiated by a correspondent node, if the said data flow does not
match an existing flow identification option, the care-of address
indicated in the default binding is used as destination address for
the mobile node / mobile router. The default binding is indicated in
the flow identification option by setting the DEF field to an
Soliman, et al. Expires December 28, 2006 [Page 14]
Internet-Draft Flow bind June 2006
appropriate value. A mobile node is responsible for having a default
care-of address with the receiver of the flow identification option.
When the correspondent node, home agent, or mobility anchor point
send packets to the mobile node that do not match any flow
description, they would send it to the care-of address with the
lowest DEF value in the binding cache. The lowest possible value is
1.
3.3. Adding flow bindings
When adding a new flow binding, a mobile node / mobile router sends
the flow identification option in the binding update. The option
MUST include the first 8 bytes, with a unique FID. The FID need only
be unique for the receiver of the binding update, i.e. the same FID
can be used across different receivers of the binding update. The
Action field MUST indicate an Add operation. Adding the flow binding
implies associating a flow with a particular care-of address for the
mobile node / mobile router. Therefore, the care-of address MUST be
present in the packet. The care-of address is present in the source
address of the packet or the alternate care-of address option.
The mobile node / mobile router may need to define the flow partially
or entirely based on the source and destination addresses in packets.
For instance, a mobile node may choose to forward all flows from
address A to address B (the latter being one of the addresses that
belong to the mobile node) to a particular care-of address.
Alternatively, more granularity can be added by including port
numbers and protocol. The destination address seen by the sender is
usually the home address, and may be the regional care-of address in
the case of [2]. The mobile node / mobile router can either include
the source and destination addresses in the flow identification
option, or refer to those addresses using the R and H flags in the
flow identification option. The latter method reduces the overall
packet size and makes it more efficient to add a flow.
3.4. Replacing flow bindings
When replacing a flow binding (either the care-of address or the
attribute of the flow), the mobile node / mobile router sends the
binding update with a flow identification option. The option
includes the FID for the binding being replaced, as well as the
Action field set to 1, indicating a request to replace the binding.
The flow identification option may contain the attributes needed to
classify the flow. If the attributes must be changed, then the
attributes MUST be contained within the option. But if the
attributes do not change and only the care-of address need to be
updated with an alternative address, the Flow Identification option
MAY include only the first 8 octets.
Soliman, et al. Expires December 28, 2006 [Page 15]
Internet-Draft Flow bind June 2006
3.5. Deleting flow bindings
When deleting a flow binding, the mobile node / mobile router sends a
binding update message with the flow identification option. The
Action field MUST be set to a value of 255, which indicates a request
for deleting a flow binding. Only the first 8 octets in the option
are required. This will provide enough information for the receiver
to locate the flow binding using the FID and remove it.
3.6. Acknowledging flow identification options
Home agent and mobility anchor point are required to ackowledge the
reception of Binding Update by sending Binding Acknowledgment. A
correspondent node may also have to acknowledge Binding Update if
requested. Binding Acknowledgement is also extended by this
specification to indicate to the mobile node / mobile router the
success of the flow binding. If a Binding Acknowledgement needs to
be sent in response to a Binding Update that contained flow
identification option(s), a copy of the first 8 bytes of each flow
identification MUST be included. Only the Status field needs to be
changed to the appropriate value. The absence of flow identification
option in Binding Acknwoledgement indicates that the sender does not
support the extension descibed in this document.
Soliman, et al. Expires December 28, 2006 [Page 16]
Internet-Draft Flow bind June 2006
4. Usage scenario
In this section, we highlight a use case of the flow identification
option.
Assume a mobile node equipped with two interfaces namely If1 and If2,
each connected to a different foreign network. The mobile node
configures one global IPv6 address on each interface, namely CoA1 and
CoA2 respectively. The mobile node runs Mobile IPv6 with a home
agent located in its home network. We assume that an existing IPsec
security association is set up betweeen the mobile node and its home
agent. We assume that the mobile node wants to exchange secure data
flows over CoA1 and insecure data flows over CoA2. To do so, the
mobile node may request its home agent to redirect packets intended
to the mobile node's home address to a different care-of address,
depending on the type of the communication. For example, port number
22 (ssh) and 443 (https) may be tunneled to CoA1 while other
communications may be tunneled to CoA2. In order to set up these
flow bindings, the following messages are exchanged:
o The mobile node sends a Binding Update through If2, with the
source address set to CoA2. The Binding Update includes a Flow
Identification option which only consists of the 8 first bytes.
The DEF field is set to 1 which indicates that CoA2 is considered
as the default care-of address.
o When the home agent receives the Binding Update, it first
validates the Binding Update as recommanded in section 10.3 of
[1]. If the Binding Update is accepted, the home agent processes
the Flow Identification option. It then registers the source
address of the Binding Update as the default care-of address for
the given home address and sends back a Binding Acknowledgement
with exactly the same Flow Identifiaction option (with the status
code = 0).
o Later, the mobile node sends additional Binding Update with Flow
Identifaction options in order to indicate its usage preferences.
In order to redirect source port number 22 and 443 to CoA1, the
mobile node sends a Binding Update through If1, with the source
address set to CoA1, with the following Flow Identification
options:
Option 1: The option is 12 bytes in length. Only the flags F
(source port) is set to 1, Action is set to 0 (add), FID is set to
1, Default priority is set to 2, the source port-Min and the
source Port-Max fields are set to 22.
Option 2: the option is the same option as above, with the FID =
Soliman, et al. Expires December 28, 2006 [Page 17]
Internet-Draft Flow bind June 2006
2, and source port-Min and source port-Max fields set to 443.
o When the home agent receives the last Binding Update which
contains two Flow Identification options, it first checks the
validity of the Binding Update as recommanded in section 10.3 of
[1]. If the Binding Update is accepted, the Flow Identification
options are treated. If these options are accepted by the home
agent, it will return a Binding Acknowledgement with Flow
Identification options, each of them having at least the same
first 8 bytes, and the status field set to 0 (success).
Thereafter, if a data flow is destinated to the home address of
the mobile node, the home agent will determine if the source port
number is equal to 22 or 443. If yes, the home agent will tunnel
the data flow to CoA1. If not, the data flow will be forwarded to
CoA2.
Soliman, et al. Expires December 28, 2006 [Page 18]
Internet-Draft Flow bind June 2006
5. Mobile Node operations
5.1. Establishing Flow Bindings
A default binding is always maintained between a MN and its peers
(home agent, correspondent node if RO is used and mobility anchor
point if applicable). The default entry indicates which care-of
address to use for a data flow that does not match any of the flow
bindings. The default care-of address is determined by the lowest
value of the DEF field in the flow identification option.
5.1.1. Sending Flow Identification options to Home Agents and
Correspondent Nodes
A mobile node may establish a Flow Binding by issuing a Binding
Update containing a Flow Identifier in its mobility options. The
Flow Identification option MUST at least be 8 bytes in length, and
indicate valid FID, action, default priority (DEF field) and rule
priority (PRI field). The flags that are set indicate which field is
present in the option. Flow bindings maintained for the same home
address may not contain overlapping policies. Mobile nodes are
required to scan their Binding Update List for overlapping entries
prior to requesting a Flow Binding. The PRI field of the Flow
Identification option may also be used to set priorities on the flow
bindings. A lower value indicates a prefered flow binding when
overlapping rules co-exist.
The ACTION field of the Flow Identification option indicates the
action that the targeted node has to perform to its Bindings Cache
List. A mobile node / mobile router may request for any of the
following actions:
o Action = 0: Add flow binding. Create a new Flow Binding with the
indicated FID and include the attached Flow Identifier. A mobile
node / mobile router may not issue a Flow Identifier with the
ACTION field set to zero for an existing FID.
o Action = 1: Replace a flow binding. This action enables the
mobile node / mobile router to replace attributes of the flow or
the care-of address associated with the FID. A mobile node /
mobile router MUST NOT issue a Flow Identifier with the ACTION
field set to one for a non existent FID.
o Action = 255: Remove a flow binding. This action enables a mobile
node / mobile router to remove the Flow Binding indicated by the
FID from the targeted node's Binding Cache List. A mobile node /
mobile router MUST not issue a Flow Identifier with the ACTION
field set to 255 for a non existent FID.
Soliman, et al. Expires December 28, 2006 [Page 19]
Internet-Draft Flow bind June 2006
5.1.2. Using Alternate Care-Of Address
If the Alternate Care-of Address option is used in the Binding
Update, it shall indicate the care-of address to be associated with
the Flow Identification options. The Flow Identification options
shall contain the FID to be allocated to the Flow Binding.
5.1.3. Receiving Binding Acknowledgements
According to [1] all nodes are required to silently ignore mobility
options not understood while processing Binding Updates. As such a
mobile node / mobile router receiving a Binding Acknowledgement in
response to the transmission of a Binding Request MUST determine if
the Binding Acknowledgement contains a copy of the first 8 bytes of
every Flow Identification option included in the Binding Update. A
Binding Acknowledgement without Flow Identification option(s) would
indicate inabillity on behalf of the source node to support the
extensions presented in this document.
If received Binding Acknowledgement contains a copy of the first 8
bytes of each flow identification option that was sent within the
Binding Update, the status field of each flow identification option
indicates the status of the flow binding on the distant node.
5.1.4. Receiving Binding Refresh Requests
Upon the reception of a Binding Refresh Request, the mobile node /
mobile router is required to renew the lifetime of all entries in its
binding update list related to the source address of the binding
refresh request.
5.2. Movement
When a MN changes its point of attachment to the Internet, its
Care-of address(es) may become invalid and need to be updated. All
the flow bindings that are attached to such an old Care-of address
need to be udpated with a new Care-of address. This can be achieved
by adding flow identification options in Binding Update. One flow
identification is needed per flow binding. Only the first 8 octets
of the flow identification option are needed. The FID must be set to
the flow binding that needs to be udpated and the action field must
be set to 1 (MODIFY).
5.3. Return Routability Procedure
A Mobile node may perform route optimization with correpondent nodes.
Route optimization allows a mobile node to bind a care-of address to
a home address in order to allow the correspondent node to direct the
Soliman, et al. Expires December 28, 2006 [Page 20]
Internet-Draft Flow bind June 2006
traffic to the current location of the mobile node. Before sending a
Binding Update to correspondent node, the Return Routability
Procedure needs to be performed between the mobile node and the
correspondent node.
This procedure is not affected by the extensions defined in this
document. However, it can be noted that the home test init message
needs to be sent only once per home address, and the care-of address
test init message needs to be sent only once per care-of address.
5.4. Returning Home
Whenever a mobile node acquires a point of attachment to the home
network and wishes to abolish all Flow Bindings associated with the
respective home address, it is required to act as described in
Section 11.5.4 of [1]. This will cause the home agent to remove all
Flow Bindings that are linked to the home address.
Soliman, et al. Expires December 28, 2006 [Page 21]
Internet-Draft Flow bind June 2006
6. Correspondant node operations
The route optimization is only defined for mobile nodes, and not
mobile router. Thus, this section only applies to Mobile IPv6 and
NEMO is not considered. Moreover, if route optimization is not used,
correspondent node sends packets to the home address of mobile nodes
without any processing involved in mobility management. The
extensions defined in this document do not affect nodes that do not
support Route Optimization.
Every correspondent node is required to maintain a Binding Cache
containing records of associations between mobile node home addresses
and care-of addresses (bindings) as they roam away from the home
network. [1] allows mobile nodes to register only a single binding
per home address with every correspondent node.
This specification extends the binding cache structure, and enables
correspondent nodes to (i) maintain multiple bindings for a given
home address and (ii) to associate multiple Flow Identification
options with every binding, termed as Flow Binding. A flow matching
a Flow Identification policy would be directed to the Care-of address
indicated by the Flow Binding.
6.1. Return Routability Procedure
RFC 3775 [1] describes the Return Routability Procedure, a mechanism
that enables the correspondent node to confirm that a mobile node is
addressable at its aclaimed care-of address as well as at its home
address. The Return Routability Procedure dictates that every
correspondent node should transmit a Home Test and Care-of Test
messages in response to the receipt of a Home Test Init and Care-of
Test Init messages from a mobile node.
Note that the home test and home test init messages need to be
exchanged only once for the same home address. The Care-of test and
care-of test init messages need to be exchanged only once for the
same care-of address. Once this messages exchange is done, several
binding udpates for the same home address / care-of address may be
received by the correspondent node.
6.2. Receiving Binding Udpate
When a correspondant node receives a Binding Update, it first
performs the same operation as defined in [1]. If the Binding Update
is valid, then the following cases may occur:
o If the Binding Update contains a Flow Identification option and
there is no existing binding for the given home address, a new
Soliman, et al. Expires December 28, 2006 [Page 22]
Internet-Draft Flow bind June 2006
entry is created in the binding cache for the home address with
the associated flow policy (if the Flow Identification option is
well formed).
o If the Binding Update contains a Flow Identification option and
there is existing bindings in the correspondent node's Binding
Cache for the same home address, these entries may be updated /
removed according to the ACTION field of the Flow Identification
option. If the existing entries do not have a flow binding
extension, such an existing entry is removed from the binding
cache of the correspondent node and new flow binding are stored
(if the Flow Identification option is well formed).
o If the Binding Update does not contain a Flow Identification
option but the binding cache of the correspondent node records
flow bindings, all entries corresponding to the same home address
must be removed. The new care-of address that must be uniquely
associated with the home address is the source address of the
Binding Update or the address transported in the Alternate Care-of
address option.
If the Acknowledge (A) bit is set in the Binding Update, and the
Binding Update was accepted by the correspondent node, the
correspondent node must reply with a Binding Acknowledgement message.
This Binding Acknowlegement message must contain a copy of the first
8 bytes of each flow identification option that was included in the
Binding Udpate. The STATUS field of each Flow Identification option
must be set to an appropriate value.
Soliman, et al. Expires December 28, 2006 [Page 23]
Internet-Draft Flow bind June 2006
7. Home Agent operations
The home agent is the central entity in Mobile IPv6. It is supposed
to keep bindings between home addresses and care-of addresses for
mobile node / mobile router away from the home link. This
specification allows home agent to maintain several bindings for a
given home address and to direct packets to different care-of
addresses according to flow characteristics.
7.1. Receiving Binding Update without flow identification option
When the home agent receives a Binding Update without a flow
identification option, it must follow the rules specified in section
10.2 of [1]. If the Binding Update is accepted, the home agent will
create, delete or update an entry in its Binding Cache. Three
situations may occur:
o No existing binding for the given home address: the Binding Update
is treated as specified in [1].
o Exising bindings without flow identification option for the given
home address: the Binding Update is treated as specified in [1].
o Existing bindings with flow identification option for the given
home address: the Binding Update is treated as specified in [1].
If the Binding Update is accepted, all existing bindings
associated with the given home address are deleted and the Care-of
address transported in the Binding Update is uniquely associated
with the home address. A Binding Acknowledgement is sent back to
the mobile node, as specified in [1]
7.2. Receiving Binding Update with flow identification option(s)
When the home agent receives a Binding Update which includes at least
one Flow Identification option, it first performs the operation
described in section 10.3.1 of RFC3775. If the Binding Update is
accepted, the home agent checks if the FID of the Flow Identification
option is already used in its binding cache. If yes, the Binding
Update should delete or update an existing entry, otherwise it should
add a new entry.
Then the home agent identifies which fields are set in the flow
identification option and which action to take:
o Action = 0: add flow binding. If the FID in the Binding Update is
the same as the FID in an existing binding cache entry for the
same home address, the home agent sends back to the mobile node a
Binding Acknowledgement with an error code 136 (FID already in
Soliman, et al. Expires December 28, 2006 [Page 24]
Internet-Draft Flow bind June 2006
use). Otherwise, if the FID is not already in use, the home agent
needs to create a new entry in the binding cache with the
associated flow policies. A Binding Acknowledgement is sent back
to the mobile node / mobile router as described in section
Section 7.3
o Action = 1: Replace a flow binding. If the FID in the Binding
Update is not already identifying an existing entry in the binding
cache for the same home address, the home agent sends back to the
mobile node a Binding Acknowledgement with error code 137 (FID not
found). Otherwise, the home agent updates the existing entry.
This update may update the lifetime of the binding or to change
the CoA if the flow policies are the same, and/or extend the flow
policies.
o Action = 255: Remove a flow binding. If the FID in the Binding
Update is not already identifying an existing entry in the binding
cache for the same home address, the home agent sends back to the
mobile node a Binding Acknowledgement with error code 137 (FID not
found). Otherwise, the home agent removes the corresponding entry
in the binding cache.
7.3. Sending Binding Ackowledgement
Upon the reception of a Binding Update, the home agent is required to
send back a Binding Acknowledgment. The status code in the Binding
Acknowledgement must be set as recommanded in [1] and is not modified
by the extension defined in this document. This status code does not
give information on the success of the flow binding.
In order to inform the status of the flow binding that where
requested by a mobile node / mobile router, flow identification
option is needed in the Binding Acknowledgement message. The home
agent must copy the first 8 bytes of each Flow Identification options
received in Binding Update and set the status code to an approriate
value. Each option must be included in the Binding Acknowledgement
message.
7.4. Deleting an entry in the binding cache
A home agent might delete an entry in its binding cache for two
reasons: either an entry expires, or the MN explitly requests the
home agent to remove a specific entry. If an entry is going to
expire, the home agent SHOULD send a Binding Refresh Advice.
7.4.1. A binding cache entry expires
If the binding cache entry that has the lower value for the DEF field
Soliman, et al. Expires December 28, 2006 [Page 25]
Internet-Draft Flow bind June 2006
(i.e., the default entry) expires, the home agent MUST delete the
entry and select another default entry based on the DEF field.
If an entry other than the default entry expires, the home agent MUST
delete the entry. This does not affect other bindings that might be
present for the same home address.
7.4.2. The mobile node explicitly requests to remove a binding
If the home agent receives a valid Binding Update with a flow
Identification option where action is set to 255 (Remove), the home
agent MUST remove the corresponding entry. The home agent looks up
the entry corresponding to the FID of the Binding Update. If an
entry is found, the entry is removed from the Binding cache and a
Binding Acknowledgement is sent back to the mobile node with a
success value for the status of the flow Identification option (see
section Section 7.3. This operation does not modify any other
binding that may appear with the same home address. If the FID is
not present in the binding cache entry for the corresponding home
address, the home agent MUST send back to the mobile node a Binding
Acknowledgement with error code 137 (FID not found) in the flow
identification option.
Soliman, et al. Expires December 28, 2006 [Page 26]
Internet-Draft Flow bind June 2006
8. Mobility Anchor Point operations
The MAP operation is very similar to the home agent operation. Flow
bindings sent to the MAP are associated with the regional care-of
address.
When a MAP receives a Binding Update that includes the flow
Identification option, it checks if such option is valid according to
the requirements above. If the option is valid, the MAP installs the
flow binding associated with the flow identified in the option. The
lifetime of the binding is the lifetime of the Binding Update. Once
the binding is successfully installed, the MAP sends the binding
acknowledgement and includes the flow Identification option. Only
the first eight bytes are required in the option. The MAP sets the
status field to a value indicating success.
In all cases, a flow identification option SHOULD be included in the
Binding Acknowledgement to indicate success or failure of the flow
binding installation.
Soliman, et al. Expires December 28, 2006 [Page 27]
Internet-Draft Flow bind June 2006
9. Security considerations
This draft introduces a new option that adds more granularity to the
Binding Update message. The new option allows the mobile node to
associate some flows to an interface and other flow to another
interface. Since the flow Identification option is part of the
mobility header, it uses the same security as the Binding Update,
whether it is sent to the home agent, correspondent node, or MAP.
However, since the flow Identification option can optionally include
an address identifying the mobile node (the destination address
field), it is pertinent for the receiver of the Binding Update to
ensure that such address (if included) is in fact assigned to the
mobile node. For instance, the home agent must check that the
address included in the flow identification option is assigned to the
mobile node as one of its home addresses.
When sending a Binding Update to the correspondent node, the message
is authenticated using the two tokens associated with the home and
care-of addresses. Hence, if a new care-of address is being added, a
new care-of address test must be run to produce an appropriate keygen
token [1].
Soliman, et al. Expires December 28, 2006 [Page 28]
Internet-Draft Flow bind June 2006
10. Open discussion - future work
10.1. Usage of the FID
The document [3] defines extensions to Mobile IPv6 to register
multiple Care-of addresses to a single home address. Flags included
in the Binding Update indicate to the receiver how to treat the new
Care-of address: either the Care-of address will be added to the
existing entries, or the new Care-of address will replace an old
Care-of address. In order to differentiate between several bindings
for the same home address, a Binding Identifier (BID) is used. It
can be noted that [3] does not define policies for multiple Care-of
addresses usage.
Considering the registration of flow policies as presented in this
document, it can be considered to use the Binding Identifier as
defined in [3] to select a care-of address to register a flow
policies. This solution is currently under discussion.
10.2. Multiple Care-of addresses
Multiple flow identification options may co-exist in Binding Update/
Binding Acknowledgement. However, all these flow identification
options indicate policies for the usage of a single CoA (either the
source address of the Binding Update, or the address included in the
Alternate care-of address sub-option). It could be considered to
propose a method to combine a flow identification option with a
care-of address option in order to transport multiple Flow
Identification options associated with different care-of addresses in
the same Binding Update.
10.3. Network in Motion
NEMO Basic Support proposes extensions to Mobile IPv6 to provide a
continuous access to an entire IPv6 network which is in motion.
Mobility of the entire network is hidden to the mobile network nodes
inside the mobile network by mobile router(s). The Binding Update
message has been extended with a new option to convey a Mobile Node
Prefix to mobile routers' home agent(s). Bi-directionnal tunnels are
set up between mobile router(s) and their respective home agent(s).
Packets from / to mobile network nodes are encapsulated to and from
the home network between the home agent and mobile router(s).
A Mobile network can be multihomed for various reasons, including
redundancy, ubiquitous access or to get more aggregated bandwidth[7].
A mobile network is said multihomed when (i) a single mobile router
has several egress interfaces, (ii) when several mobile networks are
operating the same mobile network, (iii) the mobile network is
Soliman, et al. Expires December 28, 2006 [Page 29]
Internet-Draft Flow bind June 2006
associated with multiple home agents, or (iv) multiple global
prefixes are available in the mobile network.
The application of the flow binding option to mobile network will be
studied in the forthcoming revsion of this document. In particular,
solution for binding a particular flow to a mobile router's care-of
address, or to a mobile network prefix will be further analysed.
Soliman, et al. Expires December 28, 2006 [Page 30]
Internet-Draft Flow bind June 2006
11. Acknowledgements
We would like to thank all authors of initial I-Ds that were merged
together to create this document; in alphabetical order: C.
Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N.
Pavlidou.
12. References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Soliman, H., Castellucia, C., ElMalki, K., and L. Bellier,
"Hierarchical MIPv6 mobility management", RFC 4140, August 2005.
[3] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005.
[4] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",
IETF RFC 2460, December 1998.
[5] Zhao, X., Castelluccia, C., and M. Baker, "Flexible Network
Support for Mobile Hosts", Journal ACM MONET, April 2001.
[6] Awduche, D., Malcolm, J., Agogbua, J., O Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[7] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivations-scenarios (work in
progress), February 2006.
Soliman, et al. Expires December 28, 2006 [Page 31]
Internet-Draft Flow bind June 2006
Authors' Addresses
Hesham Soliman
Qualcomm Flarion
Phone:
Email: H.Soliman@flarion.com
URI:
Nicolas Montavont
Ecole Nationale Superieure des telecommunications de Bretagne
2, rue de la chataigneraie
Cesson Sevigne 35576
France
Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@enst-bretagne.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Nikolaus A. Fikouras
University of Bremen
ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1
Bremen, Bremen 28359
Germany
Phone: +49-421-218-8264
Fax: +49-421-218-3601
Email: niko@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de
Koojana Kuladinithi
University of Bremen
ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1
Bremen, Bremen 28359
Germany
Phone: +49-421-218-8264
Fax: +49-421-218-3601
Email: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/
Soliman, et al. Expires December 28, 2006 [Page 32]
Internet-Draft Flow bind June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Soliman, et al. Expires December 28, 2006 [Page 33]