draft-ietf-mext-flow-binding-00.txt   draft-ietf-mext-flow-binding-01.txt 
IETF MEXT Working Group H. Soliman IETF MEXT Working Group H. Soliman, Ed.
Internet-Draft Elevate Technologies Internet-Draft Elevate Technologies
Expires: November 17, 2008 N. Montavont Intended status: Standards Track N. Montavont
IT/Telecom Bretagne Expires: August 17, 2009 GET/ENST-B
N. Fikouras N. Fikouras
K. Kuladinithi K. Kuladinithi
University of Bremen University of Bremen
May 16, 2008 February 13, 2009
Flow Bindings in Mobile IPv6 and Nemo Basic Support Flow Bindings in Mobile IPv6 and Nemo Basic Support
draft-ietf-mext-flow-binding-00.txt draft-ietf-mext-flow-binding-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 17, 2008. This Internet-Draft will expire on August 17, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document introduces extensions to Mobile IPv6 [1] and Nemo Basic This document introduces extensions to Mobile IPv6 and Nemo Basic
Support [2] that allow nodes to bind one or more flows to a care-of Support that allow nodes to bind one or more flows to a care-of
address. These extensions allow multihomed nodes to take full address. These extensions allow multihomed nodes to take full
advantage of the different properties associated with each of their advantage of the different properties associated with each of their
interfaces. interfaces.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 7 3. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 7
3.1. Flow Identification option . . . . . . . . . . . . . . . . 7 3.1. Flow Identification option . . . . . . . . . . . . . . . . 7
3.2. The Binding Reference Sub-option . . . . . . . . . . . . . 10 3.2. The Binding Reference Sub-option . . . . . . . . . . . . . 10
3.3. Binding Cache and Binding Update list extensions . . . . . 10 3.3. Binding Cache and Binding Update list extensions . . . . . 11
4. Protocol operations . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol operations . . . . . . . . . . . . . . . . . . . . . 12
4.1. Interaction with the Multiple CoA bindings mechanism . . . 12 4.1. Interaction with the Multiple CoA bindings mechanism . . . 12
4.2. Flow binding storage . . . . . . . . . . . . . . . . . . . 12 4.2. Flow binding storage . . . . . . . . . . . . . . . . . . . 13
4.3. Preferred Care-of address . . . . . . . . . . . . . . . . 13 4.3. Preferred Care-of address . . . . . . . . . . . . . . . . 13
4.4. Adding flow bindings . . . . . . . . . . . . . . . . . . . 13 4.4. Adding flow bindings . . . . . . . . . . . . . . . . . . . 13
4.5. Modifying flow bindings . . . . . . . . . . . . . . . . . 14 4.5. Modifying flow bindings . . . . . . . . . . . . . . . . . 14
4.6. Removing flow bindings . . . . . . . . . . . . . . . . . . 14 4.6. Removing flow bindings . . . . . . . . . . . . . . . . . . 15
4.7. Refreshing Flow Bindings . . . . . . . . . . . . . . . . . 15 4.7. Refreshing Flow Bindings . . . . . . . . . . . . . . . . . 15
4.8. Acknowledging flow identification options . . . . . . . . 15 4.8. Acknowledging flow identification options . . . . . . . . 15
5. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 18 6. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 18
6.1. Default Bindings . . . . . . . . . . . . . . . . . . . . . 18 6.1. Default Bindings . . . . . . . . . . . . . . . . . . . . . 18
6.1.1. Managing Flow Bindings with the Home Agent and MAP . . 18 6.1.1. Managing Flow Bindings with the Home Agent and MAP . . 18
6.1.2. Managing Flow Bindings in Correspondent nodes . . . . 19 6.1.2. Managing Flow Bindings in Correspondent nodes . . . . 19
6.1.3. Using Alternate Care-Of Address . . . . . . . . . . . 19 6.1.3. Using Alternate Care-Of Address . . . . . . . . . . . 20
6.1.4. Receiving Binding Acknowledgements . . . . . . . . . . 20 6.1.4. Receiving Binding Acknowledgements . . . . . . . . . . 20
6.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Return Routability Procedure . . . . . . . . . . . . . . . 20 6.3. Return Routability Procedure . . . . . . . . . . . . . . . 20
6.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 21 6.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 21
7. Applicability to Route Optimization . . . . . . . . . . . . . 22 7. Applicability to Route Optimization . . . . . . . . . . . . . 22
7.1. Receiving Binding Udpate . . . . . . . . . . . . . . . . . 22 7.1. Receiving Binding Udpate . . . . . . . . . . . . . . . . . 22
8. Home Agent operations . . . . . . . . . . . . . . . . . . . . 24 8. Home Agent operations . . . . . . . . . . . . . . . . . . . . 24
8.1. Receiving Binding Update with the Flow Identification 8.1. Receiving Binding Update with the Flow Identification
option . . . . . . . . . . . . . . . . . . . . . . . . . . 24 option . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Sending Binding Ackowledgement . . . . . . . . . . . . . . 25 8.2. Sending Binding Ackowledgement . . . . . . . . . . . . . . 25
8.3. Deleting an entry in the binding cache . . . . . . . . . . 25 8.3. Deleting an entry in the binding cache . . . . . . . . . . 25
8.3.1. Removing Flow Bindings . . . . . . . . . . . . . . . . 25 8.3.1. Removing Flow Bindings . . . . . . . . . . . . . . . . 26
9. Applicability to Hierarchical Mobile IPv6 . . . . . . . . . . 27 9. Applicability to Hierarchical Mobile IPv6 . . . . . . . . . . 27
10. Security considerations . . . . . . . . . . . . . . . . . . . 28 10. Security considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
12. Informative References . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
Mobile IPv6 (RFC3775) [1] and Nemo Basic Support (RFC3963) [2] allow Mobile IPv6 (RFC3775) [RFC3775] and Nemo Basic Support (RFC3963)
a mobile node / mobile router to manage its mobility using the [RFC3963] allow a mobile node / mobile router to manage its mobility
binding update message, which binds one care-of address to one home using the binding update message, which binds one care-of address to
address. The binding update message can be sent to the home agent. one home address. The binding update message can be sent to the home
In Mobile IPv6, the Binding Update can also be sent to correspondent agent. In Mobile IPv6, the Binding Update can also be sent to
node or to a mobility anchor point (see RFC4140 [3]). The semantics correspondent node or to a mobility anchor point (see RFC4140
of the binding update are limited to address changes. That is, [RFC4140]). The semantics of the binding update are limited to
RFC3775 [1] and RFC3963 [2] do not allow a mobile node / mobile address changes. That is, RFC3775 [RFC3775] and RFC3963 [RFC3963] do
router to bind more than one address to the home address. not allow a mobile node / mobile router to bind more than one address
Furthermore, the binding granularity is limited to the address. to the home address. Furthermore, the binding granularity is limited
Therefore, a mobile host cannot associate one of the connections to the address. Therefore, a mobile host cannot associate one of the
using the home address with a different care-of address. In connections using the home address with a different care-of address.
draft-ietf-monami6-multiplecoa [4] Mobile IPv6 and Nemo Basic Support In draft-ietf-monami6-multiplecoa Mobile IPv6 and Nemo Basic Support
are extended to allow the binding of more than one care-of address to are extended to allow the binding of more than one care-of address to
a home address. This specification extends Mobile IPv6 and Nemo a home address. This specification extends Mobile IPv6 and Nemo
Basic Support to allow it to specify policies associated with each Basic Support to allow it to specify policies associated with each
binding. A policy can contain a request for a special treatment of a binding. A policy can contain a request for a special treatment of a
particular flow. Hence, this specification allows a mobile node / particular flow. Hence, this specification allows a mobile node /
mobile router to bind a particular flow to a care-of address without mobile router to bind a particular flow to a care-of address without
affecting other flows using the same home address. In addition, we affecting other flows using the same home address. In addition, we
will see that this specification allows to bind a particular flow to will see that this specification allows to bind a particular flow to
a particular care-of address directly with correspondent node and a particular care-of address directly with correspondent node and
mobility anchor point in the case of a single mobile node. mobility anchor point in the case of a single mobile node.
In this document, a flow is defined as one or more connections that In this document, a flow is defined as one or more connections that
are identified by a flow identifier. A single connection is are identified by a flow identifier. A single connection is
typically identified by the source and destination IP addresses, typically identified by the source and destination IP addresses,
transport protocol number and the source and destination port transport protocol number and the source and destination port
numbers. Alternatively a flow can be identified in a simpler manner numbers. Alternatively a flow can be identified in a simpler manner
using the flow label field in the IPv6 header [5] or the Security using the flow label field in the IPv6 header [RFC2460] or the
Parameter Index (SPI) when IPsec is used. Security Parameter Index (SPI) when IPsec is used.
Flow bindings are useful in cases where the mobile node / mobile Flow bindings are useful in cases where the mobile node / mobile
router has more than one address, probably due to being multihomed, router has more than one address, probably due to being multihomed,
and wants to direct certain flows to certain addresses [6], [7]. and wants to direct certain flows to certain addresses. This may be
This may be done because some flows are better suited to certain link done because some flows are better suited to certain link layers or
layers or simply to load balance flows between different interfaces. simply to load balance flows between different interfaces. This
This specification introduces the flow identifier option, which is specification introduces the flow identifier option, which is
included in the binding update message and used to distribute included in the binding update message and used to distribute
policies to the recipient of the binding update. However, this policies to the recipient of the binding update. However, this
document does not define the flow itself but only the action to take document does not define the flow itself but only the action to take
on this flow. The flow description will be defined in another on this flow. The flow description will be defined in another
document. This will allow to use the same flow description in document. This will allow to use the same flow description in
several protocols. Using the flow identifier option introduced in several protocols. Using the flow identifier option introduced in
this specification a mobile node / mobile router can bind one or more 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 to a care-of address while maintaining the reception of other
flows on another care-of address. Requesting the flow binding can be flows on another care-of address. Requesting the flow binding can be
decided based on local policies within the mobile node / mobile decided based on local policies within the mobile node / mobile
router and based on the link characteristics and the types of router and based on the link characteristics and the types of
applications running at the time. Such policies are outside the applications running at the time. Such policies are outside the
scope of this document. scope of this document.
It should be noted that the flow identification option can be It should be noted that the flow identification option can be
associated with any binding update, whether it is sent to a associated with any binding update, whether it is sent to a
correspondent node (in the case of Mobile IPv6), home agent or correspondent node (in the case of Mobile IPv6), home agent or
mobility anchor point (in the case of Hierarchical Mobile IPv6). A mobility anchor point (in the case of Hierarchical Mobile IPv6).
Similar mechanism for Mobile IPv4 is described in [8].
In the rest of the document, the term "mobile node" is used to In the rest of the document, the term "mobile node" is used to
designate either a mobile node as defined in RFC3775 [1] or a mobile designate either a mobile node as defined in RFC3775 [RFC3775] or a
router as defined in RFC3963 [2] unless stated otherwise. mobile router as defined in RFC3963 [RFC3963] unless stated
otherwise.
2. Terminology 2. Terminology
Terms used in this document are defined in [9] and [10]. The Terms used in this document are defined in [RFC3753] and
following terms are also used in this document: [I-D.ietf-nemo-terminology]. 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 Description
A set of instructions that describes a flow.
Flow Identifier Flow: A flow is identified as a set of data packets that are
exchanged between two distant hosts
Identifier of a flow binding. Flow Description: A set of instructions that describes a flow.
Flow binding Flow Identifier: Identifier of a flow binding.
A mobility binding extended with a flow identifier and flow Flow binding: A mobility binding extended with a flow identifier
description. and flow description.
3. Mobile IPv6 Extensions 3. Mobile IPv6 Extensions
This section introduces extensions to Mobile IPv6 that are necessary This section introduces extensions to Mobile IPv6 that are necessary
for supporting the flow binding mechanism described in this document. for supporting the flow binding mechanism described in this document.
3.1. Flow Identification option 3.1. Flow Identification option
The Flow identification option is included in the binding update and The Flow identification option is included in the binding update and
acknowledgement messages. This option contains information that acknowledgement messages. This option contains information that
skipping to change at page 7, line 44 skipping to change at page 7, line 44
TBD TBD
Option Len Option Len
Length of option in 8-octet units Length of option in 8-octet units
PRI PRI
This is a 8-bit priority field to indicate the priority of a This is a 8-bit priority field to indicate the priority of a
particular option. This field is needed in cases where two particular option. This field is needed in cases where two
different flow descriptions in two different options overlap. The different flow descriptions in two different options overlap.
priority field decides which policy should be in those cases. A The priority field decides which policy should be in those
lower number in this field indicates a higher priority. cases. A lower number in this field indicates a higher
priority.
FID FID
The Flow Identifier field is an 8-bit unsigned integer that The Flow Identifier field is an 8-bit unsigned integer that
includes the identifier for the flow binding. This field is used includes the identifier for the flow binding. This field is
to refer to an existing binding or to create a new binding. used to refer to an existing binding or to create a new
binding.
Action Action
This field specifies the action that needs to be taken by the This field specifies the action that needs to be taken by the
receiver of the binding update containing the flow identification receiver of the binding update containing the flow
option. identification option.
Status Status
This field indicates the success or failure of the flow binding This field indicates the success or failure of the flow binding
operation for the particular flow in the option. This field is operation for the particular flow in the option. This field is
not relevant to the binding update message as a whole or to other not relevant to the binding update message as a whole or to
flow identification options. Values from 0 to 127 indicate other flow identification options. Values from 0 to 127
success. Values of 128 and higher indicate failure. This field indicate success. Values of 128 and higher indicate failure.
is only relevant when included in the Binding Acknowledgement This field is only relevant when included in the Binding
message and must be ignored in the binding update message. Acknowledgement message and must be ignored in the binding
update message.
PRO PRO
This is a 4-bit field that describes the required processing for This is a 4-bit field that describes the required processing
the option. This field may indicate a request for adding, for the option. This field may indicate a request for adding,
deleting, modifying or refreshing the option. The details of deleting, modifying or refreshing the option. The details of
these requests are discussed below. these requests are discussed below.
Res. Res.
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
The following values are reserved for the PRO field in this option: The following values are reserved for the PRO field in this option:
skipping to change at page 8, line 47 skipping to change at page 9, line 5
1 Replace a flow binding 1 Replace a flow binding
2 Refresh the current binding 2 Refresh the current binding
15 Remove a flow binding 15 Remove a flow binding
The following values are reserved for the Action field in this The following values are reserved for the Action field in this
option: option:
1 Forward. This value indicates a request to forward a flow to the 1 Forward. This value indicates a request to forward a flow to
address included or referred to by the option. the address included or referred by the option.
2 Discard. This value indicates a request to discard all packets in 2 Discard. This value indicates a request to discard all packets
the flow described by this option. in the flow described by the option.
3 n-cast. This value indicates a request to replicate the flow to 2 n-cast. his value indicates a request to replicate the flow to
several addresses. If this value is used, one or more Binding several addresses. If this value is used, one or more Binding
Reference sub-options MUST exist. The Binding Reference sub-option Reference sub-options MUST exist. The Binding Reference sub-
is described later in this specification. option is described later in this specification
The following values are reserved for the status field within the The following values are reserved for the status field within the
flow identification option: flow identification option:
0 Flow binding successful. 0 Flow binding successful.
128 Flow binding rejected, reason unspecified. 128 Flow binding rejected, reason unspecified.
129 Flow binding option poorly formed. 129 Flow binding option poorly formed.
skipping to change at page 9, line 42 skipping to change at page 9, line 48
137 Classifier language not supported. 137 Classifier language not supported.
138 Discard function not supported. 138 Discard function not supported.
139 N-cast function not supported. 139 N-cast function not supported.
It should be noted that per-packet load balancing has negative It should be noted that per-packet load balancing has negative
impacts on TCP congestion avoidance mechanisms as it is desirable to impacts on TCP congestion avoidance mechanisms as it is desirable to
maintain order between packets belonging to the same TCP connection. maintain order between packets belonging to the same TCP connection.
This behaviour is specified in RFC2702 [11]. Other negative impacts This behaviour is specified in RFC2702 [RFC2702]. Other negative
are also foreseen for other types of real time connections due to the impacts are also foreseen for other types of real time connections
potential variations in RTT between packets. Hence per-packet load due to the potential variations in RTT between packets. Hence per-
balancing is not allowed in this extension. However, the MN can packet load balancing is not allowed in this extension. However, the
still request per-flow load balancing provided that the entire flow MN can still request per-flow load balancing provided that the entire
is moved to the new interface. flow is moved to the new interface.
3.2. The Binding Reference Sub-option 3.2. The Binding Reference Sub-option
This section introduces the Binding Reference sub-option, which may This section introduces the Binding Reference sub-option, which may
be included in the Flow identification option. The Binding Reference be included in the Flow identification option. The Binding Reference
sub-option includes one or more BIDs as defined in [4]. When this sub-option includes one or more BIDs as defined in the MCoA document.
sub-option is included in the Flow identification option it When this sub-option is included in the Flow identification option it
associates the flow described with one or more BIDs that where associates the flow described with one or more BIDs that where
already registered with the recipient of the BU. A BID sub-option is 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 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 the receiver of the BU. The Binding Reference sub-option is shown
below. below.
0 1 2 3 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 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 | ...... |Sub-opt Type | Sub-Opt Len | BID | ......
skipping to change at page 10, line 35 skipping to change at page 10, line 36
Figure 2: The Binding Reference sub-option Figure 2: The Binding Reference sub-option
Sub-opt Type Sub-opt Type
Indicates the Sub-option type. For the Binding Reference sub- Indicates the Sub-option type. For the Binding Reference sub-
option, this field MUST be set to 1. option, this field MUST be set to 1.
Sub-opt Len Sub-opt Len
Indicates the sub-option length in octets. This field includes Indicates the sub-option length in octets. This field includes
the entire length of the sub-option including the type and length the entire length of the sub-option including the type and
fields. length fields.
BID BID
The BID that the mobile node wants to associate with the flow The BID that the mobile node wants to associate with the flow
identification option. One or more BID fields can be included in identification option. One or more BID fields can be included
this sub-option. in this sub-option.
3.3. Binding Cache and Binding Update list extensions 3.3. Binding Cache and Binding Update list extensions
Flow bindings are conceptually stored in Binding Cache of home agent, Flow bindings are conceptually stored in Binding Cache of home agent,
mobility anchor point and correspondent node, and in Binding Update mobility anchor point and correspondent node, and in Binding Update
List of mobile node. These logical structures need to be extended to List of mobile node. These logical structures need to be extended to
include the following parameters (in addition to those described in include the following parameters (in addition to those described in
RFC3775 [1]): RFC3775 [RFC3775]):
o FID (Flow Identifier). For a given home address, the FID MUST * FID (Flow Identifier). For a given home address, the FID MUST
uniquely identify an entry, i.e. a unique flow binding. An FID is uniquely identify an entry, i.e. a unique flow binding. An FID
only unique for a given home address. Different mobile nodes can is only unique for a given home address. Different mobile
use the same FID value. nodes can use the same FID value.
o Each attribute that constitutes the flow dsecription (and that are * Each attribute that constitutes the flow dsecription (and that
defined in a separate document). are defined in a separate document).
An entry in these structures is identified by the couple (home An entry in these structures is identified by the couple (home
address, FID). address, FID).
4. Protocol operations 4. Protocol operations
The flow identification option defines the controls on flow bindings. The flow identification option defines the controls on flow bindings.
The fields of the flow identification option are necessary for The fields of the flow identification option are necessary for
indexing flow identification options, indicating the sort of action indexing flow identification options, indicating the sort of action
that should be undertaken to the recipient's Binding Cache or for that should be undertaken to the recipient's Binding Cache or for
skipping to change at page 12, line 30 skipping to change at page 12, line 30
The remaining of this section discusses how mobile nodes can use the The remaining of this section discusses how mobile nodes can use the
flow identification option when sending binding updates to the flow identification option when sending binding updates to the
correspondent node, home agent or mobility anchor point. In correspondent node, home agent or mobility anchor point. In
addition, deletion and modification of bindings are all discussed addition, deletion and modification of bindings are all discussed
below. below.
4.1. Interaction with the Multiple CoA bindings mechanism 4.1. Interaction with the Multiple CoA bindings mechanism
Flow binding presented in this specification MUST be used with the Flow binding presented in this specification MUST be used with the
solution in [4]. The main reason why is to avoid the duplication of solution in draft-ietf-monami6-multiplecoa. The main reason why is
the default binding to be used when none of the registered rules can to avoid the duplication of the default binding to be used when none
apply to a flow. As the multiple CoA bindings document already of the registered rules can apply to a flow. As the multiple CoA
defines a prority field which indicates which care-of address is bindings document already defines a prority field which indicates
preferred, flow binding uses this priority field in order to maintain which care-of address is preferred, flow binding uses this priority
a primary Care-of address (see below section Section 4.3). field in order to maintain a primary Care-of address (see below
section Section 4.3).
Moreover, combining the mechanism in this specification with the Moreover, combining the mechanism in this specification with the
multiple CoA bindings allows for further aggregation of bindings. multiple CoA bindings allows for further aggregation of bindings.
For example, if a mobile node has several flow identifiers bound to a 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 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 can change the Care-of address for all these flows bindings just by
changing the Care-of address associated with the given BID. changing the Care-of address associated with the given BID.
Additionally, the combination of the two mechanisms allows for Additionally, the combination of the two mechanisms allows for
additional features (e.g., n-casting) to take place with minimal additional features (e.g., n-casting) to take place with minimal
effort. Hence, this specification makes use of the BID option effort. Hence, this specification makes use of the BID option
described in [4]. described in draft-ietf-monami6-multiplecoa.
4.2. Flow binding storage 4.2. Flow binding storage
Home agent, correspondent node and mobility anchor point maintain Home agent, correspondent node and mobility anchor point maintain
Binding Cache in order to record associations between home addresses Binding Cache in order to record associations between home addresses
and care-of addresses of mobile nodes that are away from the home and care-of addresses of mobile nodes that are away from the home
link. Mobile nodes maintain binding update list to record binding link. Mobile nodes maintain binding update list to record binding
between home address and care-of address. RFC 3775 [1] allows mobile between home address and care-of address. RFC 3775 [RFC3775] allows
nodes to register only one care-of address per home address. Thus a mobile nodes to register only one care-of address per home address.
binding cache entry is uniquely identified by the home address. Thus a binding cache entry is uniquely identified by the home
address.
This specification extends the binding cache and the binding update This specification extends the binding cache and the binding update
list structures, and allows mobile node to (1) register multiple list structures, and allows mobile node to (1) register multiple
care-of addresses for a given home address and (2) associate flow care-of addresses for a given home address and (2) associate flow
binding policies with the registered care-of addresses. binding policies with the registered care-of addresses.
New parameters are added to these conceptual structures in order to New parameters are added to these conceptual structures in order to
list the particular rule associated with a standard binding. On one list the particular rule associated with a standard binding. On one
hand, an entry is now identified by the pair (home address, FID) hand, an entry is now identified by the pair (home address, FID)
because several Care-of addresses may be bound to a single home because several Care-of addresses may be bound to a single home
skipping to change at page 13, line 39 skipping to change at page 13, line 45
maintain a default binding per home address. A default binding maintain a default binding per home address. A default binding
indicates an association between a home address and a Care-of indicates an association between a home address and a Care-of
address. In addition to the default binding, several bindings may address. In addition to the default binding, several bindings may
co-exist within a binding cache for the same home address, each of co-exist within a binding cache for the same home address, each of
them indicating different bindings between flows and Care-of them indicating different bindings between flows and Care-of
addresses. When a data flow is intercepted by a home agent or addresses. When a data flow is intercepted by a home agent or
initiated by a correspondent node, if the said data flow does not initiated by a correspondent node, if the said data flow does not
match an existing flow identification option, the care-of address match an existing flow identification option, the care-of address
indicated in the default binding is used as destination address for indicated in the default binding is used as destination address for
the mobile node. The default binding is indicated by the Priority the mobile node. The default binding is indicated by the Priority
field in the BID option described in [4]. A mobile node is field in the BID option described in draft-ietf-monami6-multiplecoa.
responsible for having a preferred care-of address with the receiver A mobile node is responsible for having a preferred care-of address
of the flow identification option. with the receiver of the flow identification option.
4.4. Adding flow bindings 4.4. Adding flow bindings
When adding a new flow binding, a mobile node sends the flow When adding a new flow binding, a mobile node sends the flow
identification option in the binding update. The care-of address identification option in the binding update. The care-of address
concerned with this binding update must already be registered by the concerned with this binding update must already be registered by the
receiver of the binding update (i.e., must already be associated with receiver of the binding update (i.e., must already be associated with
a BID), or a BID sub-option MUST be present in the binding update (as a BID), or a BID sub-option MUST be present in the binding update (as
defined in [4]). The flow identification option MUST include a defined in draft-ietf-multiplecoa"). The flow identification option
unique FID. The FID needs only be unique for the receiver of the MUST include a unique FID. The FID needs only be unique for the
binding update, i.e. the same FID can be used across different receiver of the binding update, i.e. the same FID can be used across
receivers of the binding update. The PRO field MUST indicate an Add different receivers of the binding update. The PRO field MUST
operation. Adding the flow binding implies associating a flow with a indicate an Add operation. Adding the flow binding implies
particular care-of address for the mobile node. The care-of address associating a flow with a particular care-of address for the mobile
concerned with the flow binding is present in the source address of node. The care-of address concerned with the flow binding is present
the packet or the alternate care-of address option. Alternatively, in the source address of the packet or the alternate care-of address
the care-of address may be indicated by the BID (which is pointing to option. Alternatively, the care-of address may be indicated by the
an existing care-of address) when the Binding Reference sub-option of BID (which is pointing to an existing care-of address) when the
the Flow Identification option is present. Binding Reference sub-option of the Flow Identification option is
present.
The mobile node may need to define the flow partially or entirely The mobile node may need to define the flow partially or entirely
based on the source and destination addresses in packets. For based on the source and destination addresses in packets. For
instance, a mobile node may choose to forward all flows from address instance, a mobile node may choose to forward all flows from address
A to address B to a particular care-of address. Alternatively, more A to address B to a particular care-of address. Alternatively, more
granularity can be added by including port numbers and protocol. granularity can be added by including port numbers and protocol.
These descriptions will be given in another document. These descriptions will be given in another document.
An Add operation implies that the FID is new and is not already used 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 by the mobile node for any other flow binding. If the Flow
skipping to change at page 16, line 25 skipping to change at page 16, line 25
security association is set up betweeen the mobile node and its home security association is set up betweeen the mobile node and its home
agent. We assume that the mobile node wants to exchange secure data 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 flows over CoA1 and insecure data flows over CoA2. To do so, the
mobile node may request its home agent to redirect packets intended mobile node may request its home agent to redirect packets intended
to the mobile node's home address to a different care-of address, to the mobile node's home address to a different care-of address,
depending on the type of the communication. For example, port depending on the type of the communication. For example, port
numbers 22 (ssh) and 443 (https) may be tunneled to CoA1 while other 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 communications may be tunneled to CoA2. In order to set up these
flow bindings, the following messages are exchanged: flow bindings, the following messages are exchanged:
o The mobile node sends a Binding Update through If2, with the * The mobile node sends a Binding Update through If2, with the
source address set to CoA2. The Binding Update includes a BID source address set to CoA2. The Binding Update includes a BID
sub-option as described in [4]. This sub-option intends to set sub-option as described in draft-ietf-monami6-multiplecoa.
the highest preference on the given Care-of address. 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 * When the home agent receives the Binding Update, it first
validates the Binding Update as recommanded in section 10.3 of validates the Binding Update as recommanded in section 10.3 of
[1]. If the Binding Update is accepted, the home agent processes [RFC3775]. If the Binding Update is accepted, the home agent
the BID sub-option as described in section 6.2 of [4]. It then processes the BID sub-option as described in section 6.2 of
registers the source address of the Binding Update as the draft-ietf-monami6-multiplecoa. It then registers the source
preferred care-of address for the given home address and sends address of the Binding Update as the preferred care-of address
back a Binding Acknowledgement. for the given home address and sends back a Binding
Acknowledgement.
o Later, the mobile node sends additional Binding Update with both * Later, the mobile node sends additional Binding Update with
Flow Identification options and BID sub-option of [4]. The BID both Flow Identification options and BID sub-option. The BID
sub-option is used to indicate the priority of the new Care-of sub-option is used to indicate the priority of the new Care-of
address. In this example, the priority must be lower than the address. In this example, the priority must be lower than the
priority of CoA2. The flow identification options are used to priority of CoA2. The flow identification options are used to
indicate the Care-of address usage preferences. In order to indicate the Care-of address usage preferences. In order to
redirect source port numbers 22 and 443 to CoA1, two flow redirect source port numbers 22 and 443 to CoA1, two flow
identification options need to be transported as well in the identification options need to be transported as well in the
Binding Update. These flow identification options are set as Binding Update. These flow identification options are set as
follows: PRI is set to 1, Action is set to 0 (forward), PRO is set follows: PRI is set to 1, Action is set to 0 (forward), PRO is
to 0 (add), FID is set to 1 (and 2 for the second option), and the set to 0 (add), FID is set to 1 (and 2 for the second option),
following flow description option should indicate port number 22 and the following flow description option should indicate port
and 443. number 22 and 443.
o When the home agent receives this second Binding Update, it first * When the home agent receives this second Binding Update, it
checks the validity of the Binding Update as recommanded in first checks the validity of the Binding Update as recommanded
section 10.3 of [1] and section 6.2 of [4]. If the Binding Update in section 10.3 of [RFC3775] and section 6.2 of
is accepted, the Flow Identification options are treated. If draft-ietf-monami6-multiplecoa. 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 these options are accepted by the home agent, it will return a
Binding Acknowledgement with Flow Identification options, each of Binding Acknowledgement with Flow Identification options, each
them having the same first 8 bytes, and the Status field set to 0 of them having the same first 8 bytes, and the Status field set
(success). to 0 (success).
Thereafter, if a data flow is destinated to the home address of Thereafter, if a data flow is destinated to the home address of
the mobile node, the home agent will determine if the source port the mobile node, the home agent will determine if the source
number is equal to 22 or 443. If yes, the home agent will tunnel port number is equal to 22 or 443. If yes, the home agent will
the data flow to CoA1. If not, the data flow will be forwarded to tunnel the data flow to CoA1. If not, the data flow will be
CoA2. forwarded to CoA2.
6. Mobile Node operations 6. Mobile Node operations
6.1. Default Bindings 6.1. Default Bindings
A default binding is always maintained between a MN and its peers A default binding is always maintained between a MN and its peers
(home agent, correspondent node if RO is used and mobility anchor (home agent, correspondent node if RO is used and mobility anchor
point if applicable). The default entry indicates which care-of 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 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 bindings. The preferred care-of address is determined through the
BID option described in [4]. BID option.
6.1.1. Managing Flow Bindings with the Home Agent and MAP 6.1.1. Managing Flow Bindings with the Home Agent and MAP
A mobile node may establish a Flow Binding by issuing a Binding A mobile node may establish a Flow Binding by issuing a Binding
Update containing a Flow Identifier (possibly associated with a Flow Update containing a Flow Identifier (possibly associated with a Flow
Description) in its mobility options. The Flow Identification option Description) in its mobility options. The Flow Identification option
MUST indicate valid FID, PRO, PRI (rule priority) and Action fields. MUST indicate valid FID, PRO, PRI (rule priority) and Action fields.
The PRO field of the Flow Identification option indicates the The PRO field of the Flow Identification option indicates the
processing that the targeted node has to perform to its Bindings processing that the targeted node has to perform to its Bindings
Cache List. A mobile node may request for any of the following Cache List. A mobile node may request for any of the following
requests: requests:
o 0: Add flow binding. Create a new Flow Binding with the indicated * 0: Add flow binding. Create a new Flow Binding with the
FID and include the attached Flow. A mobile node MUST NOT issue a indicated FID and include the attached Flow. A mobile node
Flow Identifier with the PRO field set to zero for an existing MUST NOT issue a Flow Identifier with the PRO field set to zero
FID. for an existing FID.
o 1: Replace a flow binding. This request enables the mobile node * 1: Replace a flow binding. This request enables the mobile
to replace attributes of the flow or the care-of address node to replace attributes of the flow or the care-of address
associated with the FID. A mobile node MUST NOT issue a Flow 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. 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 * 2: Refresh a flow binding. This request allows the mobile node
inform the receiver of the BU message that the flow binding is to inform the receiver of the BU message that the flow binding
still valid. This request does not modify the flow option. A is still valid. This request does not modify the flow option.
flow identification option MUST NOT contain this value in the PRO A flow identification option MUST NOT contain this value in the
field for a non-existent FID. PRO field for a non-existent FID.
o 15: Remove a flow binding. This action enables a mobile node to * 15: Remove a flow binding. This action enables a mobile node
remove the Flow Binding indicated by the FID on the targeted node. to remove the Flow Binding indicated by the FID on the targeted
A mobile node MUST not issue a Flow Identifier with the PRO field node. A mobile node MUST not issue a Flow Identifier with the
set to 15 for a non existent FID. PRO field set to 15 for a non existent FID.
When adding a flow binding on the home agent or MAP, the mobile node When adding a flow binding on the home agent or MAP, the mobile node
MUST ensure the following: MUST ensure the following:
o The PRO field MUST be set to indicate an Add operation. * 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 * The FID field includes a value that does not already exist in
mobile node's binding update list. the mobile node's binding update list.
o The PRI field is set to indicate the priority of the rule in case * The PRI field is set to indicate the priority of the rule in
of an overlap between rules. An overlap can occur when one flow case of an overlap between rules. An overlap can occur when
matches multiple flow description options. one flow matches multiple flow description options.
o If the Action field is set to indicate N-cast, the Binding * If the Action field is set to indicate N-cast, the Binding
Reference sub-option must be present and it must contain one or Reference sub-option must be present and it must contain one or
more BIDs. If the Binding Update sub-option includes only one 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 BID, it must be pointing to a care-of address other than the
included in the binding update. one included in the binding update.
6.1.2. Managing Flow Bindings in Correspondent nodes 6.1.2. Managing Flow Bindings in Correspondent nodes
When route optimisation is used (see RFC3775 [1]), a mobile node When route optimisation is used (see RFC3775 [RFC3775]), a mobile
sends the BU message to the correspondent node after the return node sends the BU message to the correspondent node after the return
routability test procedure. When adding flow bindings in the BU sent routability test procedure. When adding flow bindings in the BU sent
to the correspondent node, the mobile node MUST ensure the following: 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 * The FID field includes a value that is not already stored in
binding update list with the correspondent node's address. the binding update list with the correspondent node's address.
o The PRO field is set to indicate an Add operation. * The PRO field is set to indicate an Add operation.
A mobile node can also modify or delete flow bindings in a similar 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 manner to that described earlier with the home agent and MAP. When
Modifying a flow binding, the mobile node MUST ensure that the FID Modifying a flow binding, the mobile node MUST ensure that the FID
used already exists. The rest of the rules for modifying flow used already exists. The rest of the rules for modifying flow
bindings are the same as those listed above for adding a flow bindings are the same as those listed above for adding a flow
binding. binding.
Refreshing and deleting flow bindings are done in the same manner as Refreshing and deleting flow bindings are done in the same manner as
that described for the home agent and MAP with one exception: the that described for the home agent and MAP with one exception: the
skipping to change at page 20, line 7 skipping to change at page 20, line 14
6.1.3. Using Alternate Care-Of Address 6.1.3. Using Alternate Care-Of Address
If the Alternate Care-of Address option is used in the Binding If the Alternate Care-of Address option is used in the Binding
Update, it shall indicate the care-of address to be associated with Update, it shall indicate the care-of address to be associated with
the Flow Identification options. The Flow Identification options the Flow Identification options. The Flow Identification options
shall contain the FID to be allocated to the Flow Binding. shall contain the FID to be allocated to the Flow Binding.
6.1.4. Receiving Binding Acknowledgements 6.1.4. Receiving Binding Acknowledgements
According to [1] all nodes are required to silently ignore mobility According to [RFC3775] all nodes are required to silently ignore
options not understood while processing Binding Updates. As such a mobility options not understood while processing Binding Updates. As
mobile node receiving a Binding Acknowledgement in response to the such a mobile node receiving a Binding Acknowledgement in response to
transmission of a Binding Update MUST determine if the Binding the transmission of a Binding Update MUST determine if the Binding
Acknowledgement contains a copy of the 8 bytes of every Flow Acknowledgement contains a copy of the 8 bytes of every Flow
Identification options included in the Binding Update. A Binding Identification options included in the Binding Update. A Binding
Acknowledgement without Flow Identification option(s) would indicate Acknowledgement without Flow Identification option(s) would indicate
inabillity on behalf of the source node to support the extensions inabillity on behalf of the source node to support the extensions
presented in this document. presented in this document.
If a received Binding Acknowledgement contains a copy of the 8 bytes If a received Binding Acknowledgement contains a copy of the 8 bytes
of each flow identification option that was sent within the Binding of each flow identification option that was sent within the Binding
Update, the status field of each flow identification option indicates Update, the status field of each flow identification option indicates
the status of the flow binding on the distant node. the status of the flow binding on the distant node.
skipping to change at page 20, line 35 skipping to change at page 20, line 42
Care-of address(es) may become invalid and need to be updated. All 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 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 need to be udpated with a new Care-of address. This can be achieved
by adding flow identification options in Binding Update. One flow by adding flow identification options in Binding Update. One flow
identification is needed per flow binding. The flow description may identification is needed per flow binding. The flow description may
not be needed if only the Care-of address is changed, and not the not be needed if only the Care-of address is changed, and not the
filter itself. The FID must be set to the flow binding that needs to filter itself. The FID must be set to the flow binding that needs to
be udpated and the PRO field MUST be set to 1 (i.e., MODIFY). be udpated and the PRO field MUST be set to 1 (i.e., MODIFY).
Another solution is to take advantage of the multiple care-of Another solution is to take advantage of the multiple care-of
addresses bindings [4] to aggregate updates; the mobile node may only addresses bindings to aggregate updates; the mobile node may only
need to update the care-of address associated with the given BID. need to update the care-of address associated with the given BID.
This would avoid to send a flow identification option per flow This would avoid to send a flow identification option per flow
binding. binding.
6.3. Return Routability Procedure 6.3. Return Routability Procedure
A mobile node may perform route optimization with correpondent nodes. A mobile node may perform route optimization with correpondent nodes.
Route optimization allows a mobile node to bind a care-of address to 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 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 traffic to the current location of the mobile node. Before sending a
Binding Update to correspondent node, the Return Routability Binding Update to correspondent node, the Return Routability
Procedure needs to be performed between the mobile node and the Procedure needs to be performed between the mobile node and the
correspondent node. correspondent node.
This procedure is not affected by the extensions defined in this This procedure is not affected by the extensions defined in this
document. However, since a Binding Update message is secured with document. However, since a Binding Update message is secured with
the key generated based on the home address and care-of address test, 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 a mobile node MUST NOT bind a flow to a care-of address whose keygen
token (see RFC3775 [1]) was not used to generate the key for securing token (see RFC3775 [RFC3775]) was not used to generate the key for
the Binding Update. This limitation prohibits the sender from securing the Binding Update. This limitation prohibits the sender
requesting the n-cast action before having registered each care-of from requesting the n-cast action before having registered each
address one by one. care-of address one by one.
6.4. Returning Home 6.4. Returning Home
Whenever a mobile node acquires a point of attachment to the home Whenever a mobile node acquires a point of attachment to the home
network and wishes to abolish all Flow Bindings associated with the network and wishes to abolish all Flow Bindings associated with the
respective home address, it is required to act as described in respective home address, it is required to act as described in
Section 11.5.4 of RFC3775 [1]. This will cause the home agent to Section 11.5.4 of RFC3775 [RFC3775]. This will cause the home agent
remove all bindings that are linked to the home address, including to remove all bindings that are linked to the home address, including
the flow bindings. the flow bindings.
7. Applicability to Route Optimization 7. Applicability to Route Optimization
The route optimization is only defined for mobile nodes (RFC3775 The route optimization is only defined for mobile nodes (RFC3775
[1]), and not mobile router (RFC3963 [2]). Thus, this section does [RFC3775]), and not mobile router (RFC3963 [RFC3963]). Thus, this
not apply to mobile routers. This section describes the section does not apply to mobile routers. This section describes the
correspondent node operations. correspondent node operations.
Every correspondent node is required to maintain a Binding Cache Every correspondent node is required to maintain a Binding Cache
containing records of associations between mobile node home addresses containing records of associations between mobile node home addresses
and care-of addresses (bindings) as they roam away from the home and care-of addresses (bindings) as they roam away from the home
network. RFC3775 [1] allows mobile nodes to register only a single network. RFC3775 [RFC3775] allows mobile nodes to register only a
binding per home address with each correspondent node. single binding per home address with each correspondent node.
This specification extends the binding cache structure, and enables This specification extends the binding cache structure, and enables
correspondent nodes to (i) maintain multiple bindings for a given correspondent nodes to (i) maintain multiple bindings for a given
home address and (ii) to associate multiple Flow Identification / home address and (ii) to associate multiple Flow Identification /
description options with every binding, termed as Flow Binding. A description options with every binding, termed as Flow Binding. A
flow matching a Flow Description should be directed to the Care-of flow matching a Flow Description should be directed to the Care-of
address indicated by the Flow Binding. address indicated by the Flow Binding.
7.1. Receiving Binding Udpate 7.1. Receiving Binding Udpate
When a correspondant node receives a Binding Update, it first When a correspondant node receives a Binding Update, it first
performs the same operation as defined in RFC3775 [1]. If the performs the same operation as defined in RFC3775 [RFC3775]. If the
Binding Update is valid and contains a Flow identification option, Binding Update is valid and contains a Flow identification option,
the correspondent node needs to check the content of the PRO field. 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 If the PRO field contains a value indicating a request to add a new
flow binding, the following checks are done: flow binding, the following checks are done:
o The FID field needs to contain a value that does not already * The FID field includes a value that is not already stored in
the binding update list with the correspondent node's address.
* The PRO field is set to indicate an Add operation.
+ The FID field needs to contain a value that does not already
exist. If the FID contains a value that already exists, the exist. If the FID contains a value that already exists, the
correspondent node MUST reject the option by sending that option correspondent node MUST reject the option by sending that
back in its Binding Acknowledgement with a Status field that option back in its Binding Acknowledgement with a Status
contains an error value. field that contains an error value.
o If the Action field indicates a request to n-cast the flow, the + If the Action field indicates a request to n-cast the flow,
correspondent node MUST reject the option by sending the option in the correspondent node MUST reject the option by sending the
its binding acknowledgement with an appropriate error code. option in its binding acknowledgement with an appropriate
error code.
o If both the FID and Action fields are valid, the correspondent + If both the FID and Action fields are valid, the
node checks the flow description that must follow the flow correspondent node checks the flow description that must
identification option. If all of the checks above indicated a follow the flow identification option. If all of the checks
valid option, the correspondent node should add the flow binding above indicated a valid option, the correspondent node
to its binding cache. should add the flow binding to its binding cache.
If the PRO field in the option indicates a request to modify the + The FID MUST include a value that already exists. If the
option, the following checks must be done by the correspondent node: FID cannot be found in the correspondent node's binding
cache, the flow identification option MUST be rejected with
an appropriate error code.
o The FID MUST include a value that already exists. If the FID + If the Action field indicates a request to n-cast the flow,
cannot be found in the correspondent node's binding cache, the the correspondent node MUST reject the option by sending the
flow identification option MUST be rejected with an appropriate option in its binding acknowledgement with an appropriate
error code. error code.
o If the Action field indicates a request to n-cast the flow, the + If the Binding Reference sub-option is present, the
correspondent node MUST reject the option by sending the option in correspondent node MUST ensure that the BID points to the
its binding acknowledgement with an appropriate error code. care-of address in the packet, or to an already authrozied
care-of address. Otherwise the option MUST be rejected with
o If the Binding Reference sub-option is present, the correspondent an appropriate error code.
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 + If all of the above checks returned a valid result, the
correspondent node should modify the binding as requested. correspondent node should modify the binding as requested.
If the PRO field in the option indicates a request to modify the
option, the following checks must be done by the correspondent node:
If the PRO field in the option contains a request to refresh a If the PRO field in the option contains a request to refresh a
binding, the correspondent node MUST ensure that the FID already binding, the correspondent node MUST ensure that the FID already
exists. If the FID does not exist, the correspondent node MUST exists. If the FID does not exist, the correspondent node MUST
reject the option by sending it back in its binding acknowledgement reject the option by sending it back in its binding acknowledgement
with an appropriate error code in the status field. Otherwise, if with an appropriate error code in the status field. Otherwise, if
the FID exists, the correspondent node must keep it in its binding the FID exists, the correspondent node must keep it in its binding
cache. No further checks need to be done in the option. cache. No further checks need to be done in the option.
The correspondent node should reply with a Binding Acknowledgement The correspondent node should reply with a Binding Acknowledgement
message. This Binding Acknowlegement message must contain a copy of message. This Binding Acknowlegement message must contain a copy of
skipping to change at page 24, line 21 skipping to change at page 24, line 21
8.1. Receiving Binding Update with the Flow Identification option 8.1. Receiving Binding Update with the Flow Identification option
When the home agent receives a Binding Update which includes at least When the home agent receives a Binding Update which includes at least
one Flow Identification option, it first performs the operation one Flow Identification option, it first performs the operation
described in section 10.3.1 of RFC3775. If the Binding Update is described in section 10.3.1 of RFC3775. If the Binding Update is
accepted, the home agent then checks the flow identification option. accepted, the home agent then checks the flow identification option.
If the PRO field in the option indicates an Add operation, the If the PRO field in the option indicates an Add operation, the
following checks must be done: following checks must be done:
o The FID field needs to contain a value that does not already * The FID field needs to contain a value that does not already
exist. If the FID contains a value that already exists, the home exist. If the FID contains a value that already exists, the
agent MUST reject the option by sending that option back in its home agent MUST reject the option by sending that option back
Binding acknowledgement with a Status field that contains an in its Binding acknowledgement with a Status field that
appropriate error value. contains an appropriate error value.
o If the FID field is valid, the home agent then checks the Action * If the FID field is valid, the home agent then checks the
field. If the Action field contains a request for n-cast and the Action field. If the Action field contains a request for
Binding Reference sub-option is not included in the option, the n-cast and the Binding Reference sub-option is not included in
flow binding MUST be rejected in the binding acknowledgement the option, the flow binding MUST be rejected in the binding
containing an error code in the Status field. acknowledgement containing an error code in the Status field.
o If both of the checks above indicate valid FID and Action fields, * If both of the checks above indicate valid FID and Action
the home agent checks the flow description following the flow fields, the home agent checks the flow description following
identification option, and identifies the filter that needs to be the flow identification option, and identifies the filter that
set up. needs to be set up.
o If the flow option includes an action field that requests * If the flow option includes an action field that requests
n-casting, the home agent MUST check for the presence of the BID n-casting, the home agent MUST check for the presence of the
sub-option(s). If the sub-options are not present, the flow BID sub-option(s). If the sub-options are not present, the
identification option MUST be rejected as a poorly formatted flow identification option MUST be rejected as a poorly
option. If one or more BIDs are present in the BID Reference sub- formatted option. If one or more BIDs are present in the BID
option, the home agent needs to create multiple logical entries in Reference sub-option, the home agent needs to create multiple
its binding cache. All flows matching the one in the option would logical entries in its binding cache. All flows matching the
be n-cast to the care-of addresses pointed to by the BIDs or the one in the option would be n-cast to the care-of addresses
set of registered care-of addresses. If only one BID were pointed to by the BIDs or the set of registered care-of
included in the Binding Reference sub-option and it pointed to a addresses. If only one BID were included in the Binding
different care-of address from the one included in the packet, Reference sub-option and it pointed to a different care-of
then packets matching the flow would be bicast to those two address from the one included in the packet, then packets
addresses. However, if only one BID is present and points to the matching the flow would be bicast to those two addresses.
same address in the BU, the n-cast is essentially pointing to one
However, if only one BID is present and points 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 address and therefore cannot be performed. Such option MAY be
rejected as a poorly formatted option. rejected as a poorly formatted option.
o If all of the checks above indicated a valid option, the home * If all of the checks above indicated a valid option, the home
agent should add the flow binding to its binding cache. agent should add the flow binding to its binding cache.
If the PRO field in the option contains a value indicating a request If the PRO field in the option contains a value indicating a request
to modify an existing binding, the following actions must be taken: to modify an existing binding, the following actions must be taken:
o The FID MUST include a value that already exists. If the FID * The FID MUST include a value that already exists. If the FID
cannot be found in the home agent's binding cache, the flow cannot be found in the home agent's binding cache, the flow
identification option MUST be rejected as a poorly formed option. identification option MUST be rejected as a poorly formed
option.
o If the FID is valid, the home agent MUST perform the same steps * If the FID is valid, the home agent MUST perform the same steps
described above for the Add operation. described above for the Add operation.
If the PRO field indicates a refresh operation, the home agent MUST If the PRO field indicates a refresh operation, the home agent MUST
ensure that the FID in the option already exists. If the FID field 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. 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 If the FID existed, the home agent MUST keep the current flow binding
in its binding cache. in its binding cache.
8.2. Sending Binding Ackowledgement 8.2. Sending Binding Ackowledgement
Upon the reception of a Binding Update, the home agent is required to Upon the reception of a Binding Update, the home agent is required to
send back a Binding Acknowledgment. The status code in the Binding send back a Binding Acknowledgment. The status code in the Binding
Acknowledgement must be set as recommanded in [1] and is not modified Acknowledgement must be set as recommanded in [RFC3775] and is not
by the extension defined in this specification. This status code modified by the extension defined in this specification. This status
does not give information on the success or failure of the flow code does not give information on the success or failure of the flow
binding. binding.
In order to inform about the status of the flow binding that was In order to inform about the status of the flow binding that was
requested by a mobile node, a flow identification option MUST be set requested by a mobile node, a flow identification option MUST be set
in the Binding Acknowledgement message. The home agent must copy the in the Binding Acknowledgement message. The home agent must copy the
8 octets of each Flow Identification option received in the Binding 8 octets of each Flow Identification option received in the Binding
Update and set the status code to an approriate value. Each option Update and set the status code to an approriate value. Each option
must be included in the Binding Acknowledgement message. must be included in the Binding Acknowledgement message.
8.3. Deleting an entry in the binding cache 8.3. Deleting an entry in the binding cache
skipping to change at page 30, line 5 skipping to change at page 30, line 5
We would like to thank all authors of initial I-Ds that were merged We would like to thank all authors of initial I-Ds that were merged
together to create this document; in alphabetical order: C. together to create this document; in alphabetical order: C.
Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N. Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N.
Pavlidou. Thanks to George Tsirtsis and Vince Park for their Pavlidou. Thanks to George Tsirtsis and Vince Park for their
thorough review and input to the draft. Gabor Fekete for the thorough review and input to the draft. Gabor Fekete for the
analysis that led to the inclusion of the BID support. Henrik analysis that led to the inclusion of the BID support. Henrik
Levkowetz for suggesting the equivalent of the CLS field to allow Levkowetz for suggesting the equivalent of the CLS field to allow
other ways of describing flows. other ways of describing flows.
12. References 12. Informative 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. [I-D.ietf-nemo-terminology]
Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Ernst, T. and H. Lach, "Network Mobility Support
draft-ietf-monami6-mipv6-analysis-01 (work in progress), Terminology", draft-ietf-nemo-terminology-06 (work in
June 2006. progress), November 2006.
[7] Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Multihoming in Network Mobility Support", (IPv6) Specification", RFC 2460, December 1998.
draft-ietf-nemo-multihoming-issues-06 (work in progress),
June 2006.
[8] Zhao, X., Castelluccia, C., and M. Baker, "Flexible Network [RFC2702] "", 2005.
Support for Mobile Hosts", Journal ACM MONET, April 2001.
[9] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[10] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
draft-ietf-nemo-terminology-05 (work in progress), March 2006. in IPv6", RFC 3775, June 2004.
[11] Awduche, D., Malcolm, J., Agogbua, J., O Dell, M., and J. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
McManus, "Requirements for Traffic Engineering Over MPLS", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 2702, September 1999. RFC 3963, January 2005.
[12] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. [RFC4140] "RF", 2005.
Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivations-scenarios (work in
progress), February 2006.
Authors' Addresses Authors' Addresses
Hesham Soliman Hesham Soliman (editor)
Elevate Technologies Elevate Technologies
Phone: Email: hesham@elevatemobile.com
Email: Hesham@elevatemobile.com
URI:
Nicolas Montavont Nicolas Montavont
IT / Telecom Bretagne Ecole Nationale Superieure des telecommunications de Bretagne
2, rue de la chataigneraie 2, rue de la chataigneraie
Cesson Sevigne 35576 Cesson Sevigne 35576
France France
Phone: (+33) 2 99 12 70 23 Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@telecom-bretagne.eu Email: nicolas.montavont@enst-bretagne.fr
URI: http://www.rennes.telecom-bretagne.eu/~montavont/ URI: http://www-r2.u-strasbg.fr/~montavont/
Nikolaus A. Fikouras Nikolaus A. Fikouras
University of Bremen University of Bremen
ComNets-ikom,University of Bremen. ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1 Otto-Hahn-Allee NW 1
Bremen, Bremen 28359 Bremen, Bremen 28359
Germany Germany
Phone: +49-421-218-8264 Phone: +49-421-218-8264
Fax: +49-421-218-3601 Fax: +49-421-218-3601
Email: niko@comnets.uni-bremen.de Email: niko@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de URI: http://www.comnets.uni-bremen.de
Koojana Kuladinithi Koojana Kuladinithi
University of Bremen University of Bremen
ComNets-ikom,University of Bremen. ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1 Otto-Hahn-Allee NW 1
Bremen, Bremen 28359 Bremen, Bremen 28359
Germany Germany
Phone: +49-421-218-8251 Phone: +49-421-218-8264
Fax: +49-421-218-3601 Fax: +49-421-218-3601
Email: koo@comnets.uni-bremen.de Email: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/ URI: http://www.comnets.uni-bremen.de/~koo/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 116 change blocks. 
317 lines changed or deleted 297 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/