IETF MONAMI6 Working Group H. Soliman
Internet-Draft Qualcomm
Expires: April 26, 2007 N. Montavont
GET/ENST-B
N. Fikouras
K. Kuladinithi
University of Bremen
October 23, 2006
Flow Bindings in Mobile IPv6
draft-soliman-monami6-flow-binding-03.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 April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document introduces extensions to Mobile IPv6 [1] and Nemo Basic
Support [2] that allow nodes to bind one or more flows to a care-of
address. These extensions allow multihomed nodes to take full
advantage of the different properties associated with each of their
Soliman, et al. Expires April 26, 2007 [Page 1]
Internet-Draft Flow bind October 2006
interfaces.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 7
3.1. Flow Identification option . . . . . . . . . . . . . . . . 7
3.2. The Binding Reference Sub-option . . . . . . . . . . . . . 14
3.3. Binding Cache and Binding Update list extensions . . . . . 15
4. Protocol operations . . . . . . . . . . . . . . . . . . . . . 16
4.1. Interaction with the Multiple CoA bindings mechanism . . . 17
4.2. Flow binding storage . . . . . . . . . . . . . . . . . . . 17
4.3. Preferred Care-of address . . . . . . . . . . . . . . . . 18
4.4. Adding flow bindings . . . . . . . . . . . . . . . . . . . 18
4.5. Modifying flow bindings . . . . . . . . . . . . . . . . . 19
4.6. Removing flow bindings . . . . . . . . . . . . . . . . . . 19
4.7. Refreshing Flow Bindings . . . . . . . . . . . . . . . . . 19
4.8. Acknowledging flow identification options . . . . . . . . 19
5. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 23
6.1. Default Bindings . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. Managing Flow Bindings with the Home Agent and MAP . . 23
6.1.2. Managing Flow Bindings in Correspondent nodes . . . . 24
6.1.3. Using Alternate Care-Of Address . . . . . . . . . . . 24
6.1.4. Receiving Binding Acknowledgements . . . . . . . . . . 25
6.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Return Routability Procedure . . . . . . . . . . . . . . . 25
6.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 26
7. Applicability to Route Optimization . . . . . . . . . . . . . 27
7.1. Receiving Binding Udpate . . . . . . . . . . . . . . . . . 27
8. Home Agent operations . . . . . . . . . . . . . . . . . . . . 29
8.1. Receiving Binding Update with the Flow Identification
option . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Sending Binding Ackowledgement . . . . . . . . . . . . . . 30
8.3. Deleting an entry in the binding cache . . . . . . . . . . 30
8.3.1. Removing Flow Bindings . . . . . . . . . . . . . . . . 31
9. Applicability to Hierarchical Mobile IPv6 . . . . . . . . . . 32
Soliman, et al. Expires April 26, 2007 [Page 2]
Internet-Draft Flow bind October 2006
10. Security considerations . . . . . . . . . . . . . . . . . . . 33
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
Soliman, et al. Expires April 26, 2007 [Page 3]
Internet-Draft Flow bind October 2006
1. Introduction
Mobile IPv6 [1] and Nemo Basic Support [2] allow a mobile node /
mobile router 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. In Mobile
IPv6, the Binding Update can also be sent to correspondent node or to
a mobility anchor point [3]. The semantics of the binding update are
limited to address changes. That is, [1] and [2] do not allow a
mobile node / mobile router to bind more than one address to the home
address. Furthermore, the binding granularity is limited to the
address. Therefore, a mobile host cannot associate one of the
connections using the home address with a different care-of address.
In [4] Mobile IPv6 and Nemo Basic Support are extended to allow the
binding of more than one care-of address to a home address. This
specification extends Mobile IPv6 and Nemo Basic Support 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 / mobile router to
bind a particular flow to a care-of address without affecting other
flows using the same home address. In addition, we will see that
this specification allows to bind a particular flow to a particular
care-of address directly with correspondent node and mobility anchor
point in the case of a single mobile node.
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 [5] or the Security
Parameter Index (SPI) when IPsec is used.
Flow bindings are useful in cases where the mobile node / mobile
router has more than one address, probably due to being multihomed,
and wants to direct certain flows to certain addresses [6], [7].
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 / mobile router
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 / mobile router and based on the link characteristics and the
types of applications running at the time. Such policies are outside
the scope of this document.
Soliman, et al. Expires April 26, 2007 [Page 4]
Internet-Draft Flow bind October 2006
It should be noted that the flow identification option can be
associated with any binding update, whether it is sent to a
correspondent node (in the case of Mobile IPv6), home agent or
mobility anchor point (in the case of Hierarchical Mobile IPv6). A
Similar mechanism for Mobile IPv4 is described in [8].
In the rest of the document, the term "mobile node" is used to
designate either a mobile node as defined in [1] or a mobile router
[2] unless stated otherwise.
Soliman, et al. Expires April 26, 2007 [Page 5]
Internet-Draft Flow bind October 2006
2. Terminology
Terms used in this document are defined in [9] and [10]. The
following terms are also used in this document:
Flow
A flow is identified as a set of data packets that are exchanged
between two distant hosts.
Flow Identifier
A set of instructions that describe a flow.
Flow binding
A mobility binding extended with a Flow Identifier.
Soliman, et al. Expires April 26, 2007 [Page 6]
Internet-Draft Flow bind October 2006
3. Mobile IPv6 Extensions
This section introduces extensions to Mobile IPv6 that are necessary
for supporting the flow binding mechanism described in this document.
3.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 April 26, 2007 [Page 7]
Internet-Draft Flow bind October 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| PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID | Action | Status | PRO | CLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 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 April 26, 2007 [Page 8]
Internet-Draft Flow bind October 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 April 26, 2007 [Page 9]
Internet-Draft Flow bind October 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.
PRI
This is a 6-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.
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.
Soliman, et al. Expires April 26, 2007 [Page 10]
Internet-Draft Flow bind October 2006
PRO
This is a 4-bit field that describes the required processing for
the option. This field may indicate a request for adding,
deleting, modifying or refreshing the option. The details of
these requests are discussed below.
CLS
This is a 4-bit field that indicates the method used to describe
the flow sent in this option. The Flow identification option
allows for more than one method to describe a flow. The format
shown above is the only one described in this specification. For
the format shown in this section, the CLS field MUST be set to 1.
Other formats may also be used by allocating a new CLS value to
such definitions.
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.
Soliman, et al. Expires April 26, 2007 [Page 11]
Internet-Draft Flow bind October 2006
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
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 PRO field in this option:
Soliman, et al. Expires April 26, 2007 [Page 12]
Internet-Draft Flow bind October 2006
0 Add a flow binding
1 Replace a flow binding
2 Refresh the current binding
255 Remove a flow binding
The following values are reserved for the Action field in this
option:
1 Forward. This value indicates a request to forward a flow to the
address included or referred to by the option.
2 Discard. This value indicates a request to discard all packets in
the flow described by this option.
3 n-cast. This value indicates a request to replicate the flow to
several addresses. If this value is used, one or more Binding
Reference sub-options MUST exist. The Binding Reference sub-option
is described later in this specification.
The following values are reserved for the status field within the
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
137 Classifier language not supported.
138 Discard function not supported.
Soliman, et al. Expires April 26, 2007 [Page 13]
Internet-Draft Flow bind October 2006
139 N-cast function not supported.
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 [11]. 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.
3.2. The Binding Reference Sub-option
This section introduces the Binding Reference sub-option, which is
included in the Flow identification option. The Binding Reference
sub-option includes one or more BIDs as defined in [4]. When this
sub-option is included in the Flow identification option it
associates the flow described with one or more BIDs that where
already registered with the recipient of the BU. A BID sub-option is
not necessarily included in the same BU, but MUST be already known to
the receiver of the BU. The Binding Reference sub-option is shown
below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-opt Type | Sub-Opt Len | BID | ......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........
+-+-+-+-
Figure 2: The Binding Reference sub-option
Indicates the Sub-option type. For the Binding Reference sub-option,
this field MUST be set to 1.
Indicates the sub-option length in octets. This field includes the
entire length of the sub-option including the type and length fields.
The BID that the mobile node wants to associate with the flow
Soliman, et al. Expires April 26, 2007 [Page 14]
Internet-Draft Flow bind October 2006
identification option. One or more BID fields can be included in
this sub-option. .
3.3. 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. 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.
An entry in these structures is identified by the couple (home
address, FID).
Soliman, et al. Expires April 26, 2007 [Page 15]
Internet-Draft Flow bind October 2006
4. 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 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 April 26, 2007 [Page 16]
Internet-Draft Flow bind October 2006
This section discusses how mobile nodes 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.
4.1. Interaction with the Multiple CoA bindings mechanism
The solution presented in this specification can be used with or
without the solution in [4]. However, combining the mechanism in
this specification with the multiple CoA bindings allows for further
aggregation of bindings. For example, if a mobile node has several
flow identifiers bound to a single Care-of address identified by a
unique BID, the mobile node can change the Care-of address for all
these flows bindings just by changing the Care-of address associated
with the given BID.
Additionally, the combination of the two mechanisms allows for
additional features (e.g. n-casting) to take place with minimal
effort. Hence, this specification makes use of the BID option
described in [4].
4.2. 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 nodes maintain binding update list to record binding
between home address and care-of address. 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 and the binding update
list structures, 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.
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 the other 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 preferred 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.
Soliman, et al. Expires April 26, 2007 [Page 17]
Internet-Draft Flow bind October 2006
4.3. Preferred Care-of address
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. The default binding is indicated by the Priority
field in the BID option described in [4]. A mobile node is
responsible for having a preferred care-of address with the receiver
of the flow identification option.
4.4. Adding flow bindings
When adding a new flow binding, a mobile node 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 PRO field MUST
indicate an Add operation. Adding the flow binding implies
associating a flow with a particular care-of address for the mobile
node. The care-of address is present in the source address of the
packet or the alternate care-of address option. Alternatively, the
care-of address may be indicated by the BID (which is pointing to an
existing care-of address) when the Binding Reference sub-option of
the Flow Identification option is present.
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 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 (RCoA) in the case of [3].
The mobile node 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.
An Add operation implies that the FID is new and is not already used
by the mobile node for any other flow binding. If the Flow
identification option is sent with only the first 8-octets and with
Soliman, et al. Expires April 26, 2007 [Page 18]
Internet-Draft Flow bind October 2006
the PRO field indicating an Add opertion, this MUST be seen as a wild
card request by the sender. A wild card request implies that all
flows should be directed to the particular care-of address in the
packet.
4.5. Modifying flow bindings
When modifying a flow binding (either the care-of address or other
attributes of the flow), the mobile node sends the binding update
with a flow identification option. The option includes the FID for
the binding being modified, as well as the PRO field set to 1,
indicating a request to modify the binding. The flow identification
option contains the new attributes needed to classify the flow.
Hence, flow modification is essentially a process where an existing
flow definition is removed and a new flow (included in the option) is
added and given the same FID as the flow that was removed.
If one of the care-of addresses needs to be updated with a new one
(e.g., after a change of the IP point of attachment), the mobile node
may just need to register the new care-of address for the given BID.
4.6. Removing flow bindings
When removing a flow binding, the mobile node sends a binding update
message with the flow identification option. The PRO field MUST be
set to a value of 255, which indicates a request for removing 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.
4.7. Refreshing Flow Bindings
A flow binding is refreshed by simply including the Flow
identification option in the BU message. In this case the PRO field
is set to indicate a refresh operation. Only the first 8-octets need
to be present in this case.
The refresh operation is included in this specification due to the
nature of the BU message. The BU message updates existing bindings
with new information. Hence, all information previously sent in the
last BU message need to be resent in all new messages, otherwise such
information will be lost. To reduce the amount of information sent
unnecessarily, only the first 8-octets are sent when a refresh
operation is requested.
4.8. Acknowledging flow identification options
The home agent and mobility anchor point are required to ackowledge
Soliman, et al. Expires April 26, 2007 [Page 19]
Internet-Draft Flow bind October 2006
the reception of Binding Update by sending Binding Acknowledgment. A
correspondent node SHOULD also acknowledge Binding Update. The
Binding Acknowledgement is extended by this specification to indicate
to the mobile node 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 and
therefore MUST be interpreted as a negative acknowledgement.
Soliman, et al. Expires April 26, 2007 [Page 20]
Internet-Draft Flow bind October 2006
5. 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
numbers 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 BID
sub-option as described in [4]. This sub-option intends to set
the highest preference on the given 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 BID sub-option as described in section 6.2 of [4]. It then
registers the source address of the Binding Update as the
preferred care-of address for the given home address and sends
back a Binding Acknowledgement.
o Later, the mobile node sends additional Binding Update with both
Flow Identification options and BID sub-option of [4]. The BID
sub-option is used to indicate the priority of the new Care-of
address. In this example, the priority must be lower than the
priority of CoA2. The flow identification options are used to
indicate the Care-of address usage preferences. In order to
redirect source port numbers 22 and 443 to CoA1, the flow
identification options are set as follows:
Option 1: The option is 12 bytes in length. The flags F (source
port) is set to 1, PRI is set to 1, Action is set to 0 (forward),
PRO is set to 0 (add), FID is set to 1, 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 April 26, 2007 [Page 21]
Internet-Draft Flow bind October 2006
2, and source port-Min and source port-Max fields set to 443.
o When the home agent receives this second Binding Update, it first
checks the validity of the Binding Update as recommanded in
section 10.3 of [1] and section 6.2 of [4]. 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 April 26, 2007 [Page 22]
Internet-Draft Flow bind October 2006
6. Mobile Node operations
6.1. Default 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 preferred care-of address is determined through the
BID option described in [4].
6.1.1. Managing Flow Bindings with the Home Agent and MAP
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 contain at least 8 octets and
indicate valid FID, PRO field, and rule priority (PRI field). The
flags that are set indicate which field is present in the option.
The option MUST also include a valid Action field.
The PRO field of the Flow Identification option indicates the
processing that the targeted node has to perform to its Bindings
Cache List. A mobile node may request for any of the following
requests:
o 0: Add flow binding. Create a new Flow Binding with the indicated
FID and include the attached Flow. A mobile node MUST NOT issue a
Flow Identifier with the PRO field set to zero for an existing
FID.
o 1: Replace a flow binding. This request enables the mobile node
to replace attributes of the flow or the care-of address
associated with the FID. A mobile node MUST NOT issue a Flow
Identifier with the PRO field set to one for a non existent FID.
o 2: Refresh a flow binding. This request allows the mobile node to
inform the receiver of the BU message that the flow binding is
still valid. This request does not modify the flow option. A
flow identification option MUST NOT contain this value in the PRO
field for a non-existent FID.
o 255: Remove a flow binding. This action enables a mobile node to
remove the Flow Binding indicated by the FID from the targeted
node's Binding Cache List. A mobile node MUST not issue a Flow
Identifier with the PRO field set to 255 for a non existent FID.
When adding a flow binding in the home agent or MAP's binding caches,
the mobile node MUST ensure the following:
Soliman, et al. Expires April 26, 2007 [Page 23]
Internet-Draft Flow bind October 2006
o The PRO field MUST be set to indicate an Add operation.
o The FID field includes a value that does not already exist in the
mobile node's binding update list.
o The PRI field is set to indicate the priority of the rule in case
of an overlap between rules. An overlap can occur when one flow
matches multiple flow description options.
o If the destination address field is present, it must be set to an
address that the mobile node owns.
o If the Action field is set to indicate N-cast, the Binding
Reference sub-option must be present and it must contain one or
more BIDs. If the Binding Update sub-option includes only one
BID, it must be pointing to a care-of address other than the one
included in the binding update.
6.1.2. Managing Flow Bindings in Correspondent nodes
When route optimisation is used (see [1]), a mobile node sends the BU
message to the correspondent node after the return routability test.
When adding flow bindings in the BU sent to the correspondent node,
the mobile node MUST ensure the following:
o The FID field includes a value that is not already stored in the
binding update list with the correspondent node's address.
o The PRO field is set to indicate an Add operation.
o If either the source or destination address fields are present,
their prefixes MUST be set to 128, to indicate a single address.
A mobile node can also modify or delete flow bindings in a similar
manner to that described earlier with the home agent and MAP. When
Modifying a flow binding, the mobile node MUST ensure that the FID
used already exists. The rest of the rules for modifying flow
bindings are the same as those listed above for adding a flow
binding.
Refreshing and deleting flow bindings are done in the same manner as
that described for the home agent and MAP with one exception: the
mobile node MUST NOT refresh or delete bindings associated with any
care-of address other than the one included in the BU message.
6.1.3. Using Alternate Care-Of Address
If the Alternate Care-of Address option is used in the Binding
Soliman, et al. Expires April 26, 2007 [Page 24]
Internet-Draft Flow bind October 2006
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.
6.1.4. 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 in response to the
transmission of a Binding Update 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.
6.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 PRO field MUST be
set to 1 (MODIFY).
If the BID sub-option is used as defined in [4], the mobile node may
only need to update the care-of address associated with the given
BID. This would avoid to send a flow identification option per flow
binding.
6.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
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.
Soliman, et al. Expires April 26, 2007 [Page 25]
Internet-Draft Flow bind October 2006
This procedure is not affected by the extensions defined in this
document. However, since a Binding Update message is secured with
the key generated based on the home address and care-of address test,
a mobile node MUST NOT bind a flow to a care-of address whose keygen
token (see [1]) was not used to generate the key for securing the
Binding Update. This limitation prohibits the sender from requesting
the n-cast action before having registered each care-of address one
by one.
6.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
bindings that are linked to the home address, including the flow
bindings.
Soliman, et al. Expires April 26, 2007 [Page 26]
Internet-Draft Flow bind October 2006
7. Applicability to Route Optimization
The route optimization is only defined for mobile nodes ([1]), and
not mobile router ([2]). Thus, this section does not apply to mobile
routers. This section describes the correspondent node operations.
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.
7.1. 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 and contains the Flow identification option, the
correspondent node needs to check the content of the PRO field. If
the PRO field contains a value indicating a request to add a new flow
binding, the following checks are done:
o The FID field needs to contain a value that does not already
exist. If the FID contains a value that already exists, the
correspondent node MUST reject the option by sending that option
back in its Binding Acknowledgement with a Status field that
contains an error value.
o If the Action field indicated a request to n-cast the flow, the
correspondent node MUST reject the option by sending the option in
its binding acknowledgement with an appropriate error code.
o If both the FID and Action fields are valid, the correspondent
node checks the flags in the option, which tell it what fields are
included in the option. If the source or destination address
fields are present, the correspondent node checks if their
prefixes are set to 128 (indicating a single address). If the
prefix fields for either the source or destination addresses are
not set to 128, the binding is rejected by including an error code
in the Status field of the option and adding that option to the
binding acknowledgement.
Soliman, et al. Expires April 26, 2007 [Page 27]
Internet-Draft Flow bind October 2006
o If all of the checks above indicated a valid option, the
correspondent node should add the flow binding to its binding
cache.
If the PRO field in the option indicated a request to modify the
option, the following checks must be done by the correspondent node:
o The FID MUST include a value that already exists. If the FID
cannot be found in the correspondent node's binding cache, the
flow identification option MUST be rejected with an appropriate
error code.
o If the Action field indicated a request to n-cast the flow, the
correspondent node MUST reject the option by sending the option in
its binding acknowledgement with an appropriate error code.
o If the source or destination addresses are present in the option,
the correspondent node MUST verfiy that none of the prefixes
contains a value other than 128. If either of the prefix fields
contains a different value, the option MUST be rejected with an
appropriate error code.
o If the Binding Reference sub-option is present, the correspondent
node MUST ensure that the BID points to the care-of address in the
packet, or to an already authrozied care-of address. Otherwise
the option MUST be rejected with an appropriate error code.
o If all of the above checks returned a valid result, the
correspondent node should modify the binding as requested.
If the PRO field in the option contained a request to refresh a
binding, the correspondent node MUST ensure that the FID already
exists. If the FID did not exist, the correspondent node MUST reject
the option by sending it back in its binding acknowledgement with an
appropriate error code in the status field. Otherwise, if the FID
existed, the correspondent node must keep it in its binding cache.
No further checks need to be done in the option.
The correspondent node should 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 April 26, 2007 [Page 28]
Internet-Draft Flow bind October 2006
8. Home Agent operations
This specification allows the home agent to maintain several bindings
for a given home address and to direct packets to different care-of
addresses according to flow bindings. This section details the home
agent operations necessary to implement this specification.
8.1. Receiving Binding Update with the Flow Identification option
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 then checks the flow identification option.
If the PRO field in the option indicates an Add operation, the
following checks must be done:
o The FID field needs to contain a value that does not already
exist. If the FID contains a value that already exists, the home
agent MUST reject the option by sending that option back in its
Binding acknowledgement with a Status field that contains an error
value.
o If the FID field is valid, the home agent then checks the Action
field. If the Action field contains a request for n-cast and the
Binding Reference sub-option is not included in the option, the
flow binding MUST be rejected in the binding acknowledgement
containing an error code in the Status field.
o If both of the checks above indicate valid FID and Action fields,
the home agent checks the flags in the option, which tell it what
fields are included in the option. If the destination address
field is present the home agent MUST verify that the address/
prefix included is in fact assigned to the mobile node. If this
check fails (for the mobile host or if the prefix in the option is
not located in the Mobile Network Prefix table) The home agent
MUST reject the option with an appropriate error code in its
status field.
o If the flow option included an action field indicating a request
for n-cast, the home agent MUST check for the presence of the BID
sub-option. If the sub-option were not present, the option MUST
be rejected as a poorly formatted option. If one or more BIDs are
present in the BID Reference sub-option, the home agent needs to
create muliple logical entries in its binding cache. All flows
matching the one in the option would be n-cast to the care-of
addresses pointed to by the BIDs or the set of registered care-of
addresses. If only one BID were included in the Binding Reference
sub-option and it pointed to a different care-of address from the
Soliman, et al. Expires April 26, 2007 [Page 29]
Internet-Draft Flow bind October 2006
one included in the packet, then packets matching the flow would
be bicast to those two addresses. However, if only one BID were
present and it pointed to the same address in the BU, the n-cast
is essentially pointing to one address and therefore cannot be
performed. Such option MAY be rejected as a poorly formatted
option.
o If all of the checks above indicated a valid option, the home
agent should add the flow binding to its binding cache.
If the PRO field in the option contained a value indicating a request
to modify an existing binding, the following actions must be taken:
o The FID MUST include a value that already exists. If the FID
cannot be found in the home agent's binding cache, the flow
identification option MUST be rejected as a poorly formed option.
o If the FID is valid, the home agent MUST perform the same steps
described above for the Add operation.
If the PRO field indicated a refresh operation, the home agent MUST
ensure that the FID in the option already exists. If the FID field
did not exist, the option MUST be rejected as a poorly formed option.
If the FID existed, the home agent MUST keep the current flow binding
in its binding cache.
8.2. 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 specification. This status code
does not give information on the success or failure of the flow
binding.
In order to inform the status of the flow binding that where
requested by a mobile node, flow identification option is needed in
the Binding Acknowledgement message. The home agent must copy the
first 8 octets of each Flow Identification option received in the
Binding Update and set the status code to an approriate value. Each
option must be included in the Binding Acknowledgement message.
8.3. 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 explicitly 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.
Soliman, et al. Expires April 26, 2007 [Page 30]
Internet-Draft Flow bind October 2006
8.3.1. Removing Flow Bindings
If the home agent receives a valid Binding Update with a flow
Identification option where the PRO field 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 8.2. 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 April 26, 2007 [Page 31]
Internet-Draft Flow bind October 2006
9. Applicability to Hierarchical Mobile IPv6
This section describes the Mobility Anchor Point (MAP) operations.
The MAP operation is the same as 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 in Section 8.1. 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 April 26, 2007 [Page 32]
Internet-Draft Flow bind October 2006
10. 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.
Soliman, et al. Expires April 26, 2007 [Page 33]
Internet-Draft Flow bind October 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. Thanks to George Tsirtsis and Vince Park for their
thorough review and input to the draft. Gabor Fekete for the
analysis that led to the inclusion of the BID support. Henrik
Levkowetz for suggesting the equivalent of the CLS field to allow
other ways of describing flows.
12. References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Soliman, H., Castellucia, C., ElMalki, K., and L. Bellier,
"Hierarchical MIPv6 mobility management", RFC 4140,
August 2005.
[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration", draft-ietf-monami6-multiplecoa-00
(work in progress), June 2006.
[5] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6)", IETF RFC 2460, December 1998.
[6] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-01 (work in progress),
June 2006.
[7] Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of
Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-06 (work in progress),
June 2006.
[8] Zhao, X., Castelluccia, C., and M. Baker, "Flexible Network
Support for Mobile Hosts", Journal ACM MONET, April 2001.
[9] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[10] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
Soliman, et al. Expires April 26, 2007 [Page 34]
Internet-Draft Flow bind October 2006
draft-ietf-nemo-terminology-05 (work in progress), March 2006.
[11] Awduche, D., Malcolm, J., Agogbua, J., O Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[12] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
Kuladinithi, "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 April 26, 2007 [Page 35]
Internet-Draft Flow bind October 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 April 26, 2007 [Page 36]
Internet-Draft Flow bind October 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 April 26, 2007 [Page 37]