IETF MONAMI6 Working Group H. Soliman
Internet-Draft Qualcomm
Expires: August 31, 2006 N. Montavont
GET/ENST-B
N. Fikouras
K. Kuladinithi
University of Bremen
February 27, 2006
Flow Bindings in Mobile IPv6
draft-soliman-monami6-flow-binding-00.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 August 31, 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 August 31, 2006 [Page 1]
Internet-Draft Flow bind February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Flow Identification option . . . . . . . . . . . . . . . . . . 5
3. Protocol operations . . . . . . . . . . . . . . . . . . . . . 11
3.1. Default binding . . . . . . . . . . . . . . . . . . . . . 11
3.2. Adding flow bindings . . . . . . . . . . . . . . . . . . . 12
3.3. Replacing flow bindings . . . . . . . . . . . . . . . . . 12
3.4. Deleting flow bindings . . . . . . . . . . . . . . . . . . 12
4. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 16
5.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 16
5.2. Establishing Flow Bindings . . . . . . . . . . . . . . . . 16
5.2.1. Sending Flow Identifications to Home Agents and
Correspondent Nodes . . . . . . . . . . . . . . . . . 16
5.2.2. Using Alternate Care-Of Address . . . . . . . . . . . 17
5.2.3. Receiving Binding Acknowledgements . . . . . . . . . . 17
5.2.4. Receiving Binding Refresh Requests . . . . . . . . . . 18
5.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 18
5.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. Returning Home . . . . . . . . . . . . . . . . . . . . . . 18
6. Correspondant node operations . . . . . . . . . . . . . . . . 19
6.1. Modification to the binding cache . . . . . . . . . . . . 19
6.2. Return Routability Procedure . . . . . . . . . . . . . . . 19
7. Home Agent operations . . . . . . . . . . . . . . . . . . . . 20
7.1. Modification to the binding cache . . . . . . . . . . . . 20
7.2. Receiving BU without flow identification option . . . . . 21
7.3. Receiving BU with flow identification option(s) . . . . . 21
7.4. Deleting an entry in the binding cache . . . . . . . . . . 22
7.4.1. A binding cache entry expires . . . . . . . . . . . . 22
7.4.2. The mobile node explicitly requests to remove a
binding . . . . . . . . . . . . . . . . . . . . . . . 23
8. Mobility Anchor Point operations . . . . . . . . . . . . . . . 24
9. Security considerations . . . . . . . . . . . . . . . . . . . 25
10. Open discussion - future work . . . . . . . . . . . . . . . . 26
10.1. Usage of the FID . . . . . . . . . . . . . . . . . . . . . 26
10.2. Multiple Care-of addresses . . . . . . . . . . . . . . . . 26
10.3. Network in Motion . . . . . . . . . . . . . . . . . . . . 26
Soliman, et al. Expires August 31, 2006 [Page 2]
Internet-Draft Flow bind February 2006
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Soliman, et al. Expires August 31, 2006 [Page 3]
Internet-Draft Flow bind February 2006
1. Introduction
Mobile IPv6 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 MN is connected to
different access technologies with different characteristics. When
using the flow identifier option introduced in this specification, a
mobile node is able to bind one flow to an interface while
maintaining the reception of other flows on another interface.
Requesting the flow binding can be decided based on local policies
within the MN and based on the link characteristics and the types of
applications running at the time.
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].
Note that this specification is an ongoing work and some parts of the
document are still under discussion.
Soliman, et al. Expires August 31, 2006 [Page 4]
Internet-Draft Flow bind February 2006
2. 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 BU 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 links.
Soliman, et al. Expires August 31, 2006 [Page 5]
Internet-Draft Flow bind February 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| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID | Status |R|H|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Flow Label | C. S. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+
Figure 1: The flow identification option
Option Type
TBD
Option Len
Length of option in 8-octet units
S
When set, this flag indicates the presence of the Source address
field in this option.
Soliman, et al. Expires August 31, 2006 [Page 6]
Internet-Draft Flow bind February 2006
E
When set, this flag indicates the presence of the Destination
address field in this option.
F
When set, this flag indicates the presence of the Source port
field in this option.
L
When set, this flag indicates the presence of the Destination port
field 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.
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.
Action
This field specifies the action that needs to be taken by the
receiver of the binding update containing the flow identification
option.
FID
The Flow Identifier field is a 16-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.
Soliman, et al. Expires August 31, 2006 [Page 7]
Internet-Draft Flow bind February 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 and MUST be used to identify the flow.
H
When set, this flag indicates that the destination address
associated with this flow is the address included in the home
address option in the binding update and MUST be used to identify
the flow.
D
When set, this flag indicates the default 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.
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.
Source Address
This field identifies the source address of the data packet 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.
Destination Address
This field identifies the destination address of the data packet
as seen by the receiver of the binding update. For a
correspondent node, the destination is the home address of the
mobile node. However, a mobility anchor point would see the
destination address as the regional care-of address of the mobile
node. Hence, the mobile node needs to specify this field as seen
by the receiver of the binding update.
Soliman, et al. Expires August 31, 2006 [Page 8]
Internet-Draft Flow bind February 2006
Source Port
This field identifies the source port number that will be used in
data packets, as seen by the receiver of the binding update.
Destination Port
This field identifies the destination port number that will be
used in data packets as seen by the receiver of the binding
update.
Protocol
A 16-bit unsigned integer representing value of the transport
protocol number associated with the port numbers in data packets.
Flow Label
The Flow label present in the IPv6 header of the data packet seen
by the receiver of the binding update.
C.S. (Class of Service)
The Class of Service field in the data packet as seen by the
receiver of the binding update.
SPI
The Security Parameter Index present in the IPsec header of the
data packet 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
2 Discard a flow
255 Remove a flow binding
The following values are reserved for the status field within the
flow movement option:
0 Flow binding successful.
Soliman, et al. Expires August 31, 2006 [Page 9]
Internet-Draft Flow bind February 2006
128 Flow binding rejected, reason unspecified.
129 Flow binding option poorly formed.
130 Administratively prohibited.
131 Flow identification by port numbers is not supported.
132 Flow identification with Class of service field is not supported.
133 Flow identification with Flow label is not supported.
134 Flow identification with SPI is not supported.
135 No default entry for the home address.
136 FID already in use
137 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.
Soliman, et al. Expires August 31, 2006 [Page 10]
Internet-Draft Flow bind February 2006
3. Protocol operations
This specification allows mobile nodes 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 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
Option 4: Source Port, Destination Port
Option 5: Source Port, Destination Port, Protocol
Option 6: Source Address, Destination Address, Source Port,
Destination Port
Option 7: Protocol
This section discusses how the mobile node can use the flow
identification option when sending binding updates to the
correspondent node, home agent or mobility anchor point. Addition,
deletion and modification of bindings are all discussed below.
3.1. 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.
A default care-of address is identified in a flow identification
option with the D flag set to 1. Only the first 8 bytes in the
Soliman, et al. Expires August 31, 2006 [Page 11]
Internet-Draft Flow bind February 2006
options are required. A mobile node MUST first register a default
care-of address before sending any other flow identification options.
When a distant node receives a BU with a flow identification option
without the D flag set, and if this node has not already a default
binding for the same home address in its binding cache, the Binding
Update must be rejected. A BA with the status code 135 MUST be
returned to the mobile node.
3.2. Adding flow bindings
When adding a new flow binding, the mobile node sends the flow
identification option in the binding update. The option MUST include
the first 8 octets, 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. 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 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 can either include the source and destination
addresses in the flow identification option, or refer to those
addresses using the H and R flags in the flow identification option.
The latter method reduces the overall packet size and makes it more
efficient to add a flow.
3.3. Replacing flow bindings
When replacing a flow binding, the mobile node sends the binding
update with the 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 MUST contain the attributes needed to classify
the flow.
3.4. Deleting flow bindings
When deleting a flow binding, the mobile node sends a binding update
Soliman, et al. Expires August 31, 2006 [Page 12]
Internet-Draft Flow bind February 2006
message with the flow identification option. The Action field MUST
be set to a value of 2, 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.
Soliman, et al. Expires August 31, 2006 [Page 13]
Internet-Draft Flow bind February 2006
4. Usage scenario
In this section, we hihglight a usage case of the flow identification
option to illustrate how to use the option.
Let assume a mobile node which is equipped with two interfaces namely
If1 and If2, both of them connected to a different visited 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 unsecure 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 BU includes a Flow Identification
option which only consists of the 8 first bytes. The D flag
(Default entry) is set to 1.
o When the home agent receives the BU, it first validates the BU as
recommanded in section 10.3 of [1]. If the BU is acecpted, the
home agent processes the Flow Identification option. It then
registers the source address of the BU as the default care-of
address for the given home address and sends back a BA with
exactly the same Flow Identifiaction option (with the status code
= 0).
o Then, the mobile node can send additional BU 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 BU through If1, with the source address set to
CoA1, with the following Flow Identification options:
Option 1: The option is 9 bytes in length. Only the flags F
(source port) is set to 1, Action is set to 0 (add), FID is set to
1 and the source port number is set to 22.
Option 2: the option is the same option as above, with the FID =
2, and source port number = 443. If the home agent accepts these
Flow binding options, it will return a BA with a Flow
Identification option with the success flag in the status field.
Soliman, et al. Expires August 31, 2006 [Page 14]
Internet-Draft Flow bind February 2006
o When the home agent receives the last BU which contains two Flow
Identification options, it first checks the validity of the BU as
recommanded in section 10.3 of [1]. If the BU is accepted, the
Flow Identification options are treated. If these options are
accepted by the home agent, the home agent sends back a BA to the
mobile node with the same Flow Identification options (the status
code is kept to 0).
Thereafter, if a data flow is intended to the home address of the
mobile node, the home agent will identify 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 August 31, 2006 [Page 15]
Internet-Draft Flow bind February 2006
5. Mobile Node operations
5.1. Conceptual Data Structures
Each mobile node is required by [1] to maintain a Binding Udate List
containing a record of Binding Updates sent by the mobile node for
which the lifetime has not expired. The fields of a Binding Update
List entry are presented in detail in [1]. This draft extends the
Binding Update List entry data structure to include Flow
Identifications. A Flow Identification has a flexible format
depending on the fields required to identify a flow or an aggregate
of flows. The different fields that constitute a Flow Identification
option are presented in detail in Section 2.
For the support of the extensions presented in this draft, all
Binding Update List entries MUST maintain a valid FID and a valid
value for at least one of the rest of the fields.
5.2. Establishing Flow Bindings
A mobile node MUST maintain a Default Binding in the Binding Update
List for each home address retained. The Default Binding indicates
the preferred Care-of Address where the mobile node wishes to receive
all flows for which none of the registered flow bindings apply.
Should the Default Binding expire or be removed then all bindings
related to the home address are automatically removed from the
Binding Update List.
5.2.1. Sending Flow Identifications to Home Agents and Correspondent
Nodes
A mobile node may establish a Flow Binding by issuing a Binding
Update (BU) containing a Flow Identifier in its mobility options. If
the mobile node does not already maintain a Default Binding with the
targeted node then the the D flag MUST be enabled. The Flow
Identifier option MUST indicate the FID to be associated with the
registered Flow Binding. A Flow Identifier option is considered
valid when it contains a valid FID and values for at least one of the
rest of its fields indicating the flows to be associated with the
binding. 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 ACTION field of the Flow Identifier option indicates the action
that the targeted node has to perform to its Bindings Cache List upon
processing the Flow Identifier. A mobile node may request for any of
the following actions:
Soliman, et al. Expires August 31, 2006 [Page 16]
Internet-Draft Flow bind February 2006
o Action = 0: Add flow binding. Create a new Flow Binding with the
indicated FID and include the attached Flow Identifier. A mobile
node 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 to replace the Filter Identifiers associated with the
Filter Binding indicated by FID. A mobile node may 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 to remove the Flow Binding indicated by FID from the targeted
node's Binding Cache List. All associated Flow Identifiers are
also removed automatically. A mobile node requesting for the
Default Binding to be removed will cause all other bindings for
its home address to be removed from the Binding Cache List of the
targeted node. A mobile node may not issue a Flow Identifier with
the ACTION field set to 255 for a non existent FID.
5.2.2. Using Alternate Care-Of Address
A mobile node can use an alternate care-of address to issue a Flow
Identifier for a different Flow Binding. For that a mobile node is
required to send a Binding Update including an Alternate Care-of
Address option followed by the Flow Identifier option. The Alternate
Care-of Address option shall indicate the care-of address to be
associated with the Flow Identifier options. The Flow Identifier
options shall contain the FID to be allocated to the Flow Binding.
5.2.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 receiving a Binding Acknowledgement (BA) in response to
the transmission of a Binding Request MUST determine if the BA
contains a copy of every Flow Identification option included in the
BU. A BA without Filter Identification options would indicate
inabillity on behalf of the source node to support the extensions
presented in this document.
In addition to the Status values presented in [1] the following
Status values are defined:
TBD Flow Binding successfully established. Flow Binding was created
in the Binding Cache List and Flow Identifier was successfully
associated,
Soliman, et al. Expires August 31, 2006 [Page 17]
Internet-Draft Flow bind February 2006
TBD +1 No Default Binding found. Mobile node may not establish a
Flow Binding because it does not maintain a Default Binding.
TBD +2 FID not found. Mobile node has requested an action for a FID
that does not exist.
5.2.4. Receiving Binding Refresh Requests
Upon receiving a Binding Refresh Request the mobile node is required
to act as described in Section 11.7.4 of [1].
5.3. Packet Processing
The extensions presented in this draft affect the manner in which a
mobile node manages bindings in order to influence the point of
delivery of incoming flows. The policies that drive these extensions
are considered beyond the scope of this specification. Similarly,
the mechanisms the affect the mobile node's choice on the return path
are also considered out of scope.
5.4. Movement
As described in Section 11.5.2 of [1], a mobile node MAY use more
than one care-of address at a time. The extensions presented in this
draft are compatible with the multiple care-of addresses facility. A
mobile node may associate a different Flow Identifier with each
available care-of address to register Flow Bindings. Each Flow
Binding is allocated a FID that is unique for each home address
retained by the mobile node. It is noted that, for a given home
address a mobile node may not maintain overlapping Flow Identifiers.
5.5. 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 as well as all related Flow Identifiers.
Soliman, et al. Expires August 31, 2006 [Page 18]
Internet-Draft Flow bind February 2006
6. Correspondant node operations
Every Correspondent Node (CN) 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 CN.
This specification extends the binding cache structure, and enables
CNs to (1) maintain multiple bindings for a given home address and
(2) to associate multiple Flow Identification options with every
binding, termed as Flow Binding. A flow matching the a Flow
Identification policy would be directed to the Care-of address
indicated by the Flow Binding.
A CN may maintain one ore more Flow Bindings for a mobile node in
their Binding Cache. However, only one of the Flow Bindings is
considered as the Default Bindind. The Default Binding is applicable
for all flows for which no other Flow Binding is applicable.
6.1. Modification to the binding cache
The binding cache structure needs to be extended to include the
fields of the flow identification option described in Section 2.
6.2. Return Routability Procedure
RFC 3775 [1] describes the Return Routability Procedure, a mechanism
that enables the CN 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 CN 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.
Regarding the extensions described in this document, the exchange of
the Home Test and Home Test Init messages will only be necessary for
the registration of the first Flow Binding for a gieven home address.
Any subsequent Flow Bindings will require only the exchange of the
Care-of Test and Care-of Init messages.
Soliman, et al. Expires August 31, 2006 [Page 19]
Internet-Draft Flow bind February 2006
7. Home Agent operations
A home agent maintains a Binding Cache in order to record
associations between home addresses and care-of addresses of mobile
nodes that are away from the home link. RFC 3775 [1] allows mobile
nodes 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 structure, and allows
mobile node to (1) register multiple care-of addresses for a given
home address and (2) associate flow binding policies with the
registered care-of addresses. As several entries for the same home
address may co-exist in the binding cache of a home agent, an entry
is uniquely identified by the pair (mobile node's home address, FID).
The home agent MUST maintain a default binding for each home address
as explained in Section 3.1. This default binding associates a home
address with a default (or primary) care-of address of the mobile
node. This entry is used by the home agent when incoming data
packets are intended to a home address and does not match any
registered flow binding policies.
7.1. Modification to the binding cache
The binding cache structure needs to be extended to include the flow
identification fields. In addition to the fields described in
section 9.1 of [1], a binding cache entry MUST contain:
o Flow Binding identifier (FID): identifies an entry in the binding
cache, in association with a home address
o Source address
o Destination address
o Source port number
o Destination port number
o Protocol number
o IPv6 flow label
o Class of Service
o SPI
Soliman, et al. Expires August 31, 2006 [Page 20]
Internet-Draft Flow bind February 2006
7.2. Receiving BU without flow identification option
When the home agent receives a BU without a flow identification
option, it must follow the rules specified in section 10.2 of RFC
3775. If the BU 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 BU is treated
as specified in [1].
o Exising bindings without flow identification option for the given
home address: the BU is treated as specified in [1].
o Existing bindings with flow identification option for the given
home address: all existing bindings associated with the given home
address are deleted and the Care-of address transported in the BU
is uniquely associated with the home address.
7.3. Receiving BU with flow identification option(s)
When the home agent receives a BU which includes at least one Flow
Identification option, it first performs the operation described in
section 10.3.1 of RFC3775. If the BU is accepted, the home agent
checks if the FID of the Flow Identification option is already used
in its binding cache. If yes, the BU should delete or update an
existing entry, otherwise it should add a new entry.
Then the home agent checks if the D flag (Default binding) is set.
If the D flag is not set, the BU is rejected if the home agent has
not an existing entry for the given home address, or if the home
agent has a standard entry for the given home address, without any
flow identification information.
If the D flag is set, different operations may be performed depending
on the status of the home agent's binding cache:
o The home agent's binding cache does not have any entry for the
given home address: the home agent may create a new default entry
in its binding cache depending on the action defined in the Flow
Identification option (see below)
o The home agent's binding cache contains an association between the
given home address and a Care-of address without any information
on flow identification: the home agent may udpate the exisintg
entry with a new default entry in its binding cache depending on
the action defined in the Flow Identification option (see below)
Soliman, et al. Expires August 31, 2006 [Page 21]
Internet-Draft Flow bind February 2006
o The home agent's binding cache contains one or several
associations between the given home address and one or several
Care-of address(es) with flow identification information. The
home agent may update/delete these existing association depending
on the action field of the Flow Identitification option (see
below).
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 BU 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 BA with a
error code 136 (FID already in use). Otherwise, the home agent
needs to create a new entry in the binding cache with the
associated flow policies.
o Action = 1: Replace a flow binding. If the FID in the BU 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
BA 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 = 2: TBD
o Action = 255: Remove a flow binding. If the FID in the BU 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
BA with error code 137 (FID not found). Otherwise, the home agent
removes the corresponding entry in the binding cache.
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 default entry in the binding cache expires, the home agent
MUST delete all other entries associated with the same home address,
even for different CoAs.
If an entry other than the default entry expires (i.e., with a flow
binding policies), the home agent MUST delete the entry. This does
Soliman, et al. Expires August 31, 2006 [Page 22]
Internet-Draft Flow bind February 2006
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 BU 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 BU. If an entry is found, the entry
is removed from the Binding cache and a BA is sent back to the mobile
node with a success value for the status of the flow identification
option. 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 BA with error code 137 (FID
not found).
Soliman, et al. Expires August 31, 2006 [Page 23]
Internet-Draft Flow bind February 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 octets 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 August 31, 2006 [Page 24]
Internet-Draft Flow bind February 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 August 31, 2006 [Page 25]
Internet-Draft Flow bind February 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 Flow Identifier (FID) 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 Flow Identifier as defined
in [3] to select a CoA 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 BU/BA. However,
all these flow identification options indicate policies for the usage
of a single CoA (either the source address of the BU, 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 BU.
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 moible 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
associated with multiple home agents, or (iv) multiple global
Soliman, et al. Expires August 31, 2006 [Page 26]
Internet-Draft Flow bind February 2006
prefixes are available in the mobile network.
The application of the flow binding option to mobile network will be
studied in the next 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 analysed.
Soliman, et al. Expires August 31, 2006 [Page 27]
Internet-Draft Flow bind February 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 August 31, 2006 [Page 28]
Internet-Draft Flow bind February 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 August 31, 2006 [Page 29]
Internet-Draft Flow bind February 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 August 31, 2006 [Page 30]