draft-ietf-mext-flow-binding-03.txt   draft-ietf-mext-flow-binding-04.txt 
IETF MEXT Working Group H. Soliman IETF MEXT Working Group H. Soliman
Internet-Draft Elevate Technologies Internet-Draft Elevate Technologies
Intended status: Standards Track G. Tsirtsis Intended status: Standards Track G. Tsirtsis
Expires: January 14, 2010 Qualcomm Expires: May 13, 2010 Qualcomm
N. Montavont N. Montavont
IT/TB IT/TB
G. Giaretta G. Giaretta
Qualcomm Qualcomm
K. Kuladinithi K. Kuladinithi
University of Bremen University of Bremen
July 13, 2009 November 9, 2009
Flow Bindings in Mobile IPv6 and NEMO Basic Support Flow Bindings in Mobile IPv6 and NEMO Basic Support
draft-ietf-mext-flow-binding-03.txt draft-ietf-mext-flow-binding-04.txt
Abstract
This document introduces extensions to Mobile IPv6 that allow nodes
to bind one or more flows to a care-of address. These extensions
allow multihomed nodes to instruct home agents and other Mobile IPv6
entities to direct inbound flows to specific addresses.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 39 skipping to change at page 1, line 46
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 January 14, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document introduces extensions to Mobile IPv6 that allow nodes described in the BSD License.
to bind one or more flows to a care-of address. These extensions
allow multihomed nodes to instruct home agents and other Mobile IPv6
entities to direct inbound flows to specific addresses.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8
4.1. Definition Update for Binding Identifier Mobility 4.1. Definition Update for Binding Identifier Mobility
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8
4.2.1. Binding Reference Sub-option . . . . . . . . . . . . . 11 4.2.1. Flow Identification Sub-Options definition . . . . . . 11
4.2.2. Flow Description Sub-option . . . . . . . . . . . . . 12 4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 15
4.3. Flow Identification Summary Mobility Option . . . . . . . 12 4.3. Flow Bindings entries list and its relationship to
4.4. Flow Bindings entries list and its relationship to Binding Cache . . . . . . . . . . . . . . . . . . . . . . 16
Binding Cache . . . . . . . . . . . . . . . . . . . . . . 13 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 19
5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 16 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 19
5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 16 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 19
5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 16 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 20
5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 17 5.2.2. Sending BU with Flow Identification Mobility
5.2.2. Sending BU with Flow Identification Options . . . . . 17 Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 19 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 22
5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 19 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 23
5.2.5. Receiving Binding Acknowledgements . . . . . . . . . . 20 5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 23
5.2.6. Return Routability Procedure . . . . . . . . . . . . . 20 5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 23
5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 21 5.2.7. Return Routability Procedure . . . . . . . . . . . . . 24
5.3.1. Receiving BU with BID Options . . . . . . . . . . . . 21 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24
5.3.2. Receiving BU with Flow Identification Options . . . . 21 5.3.1. Handling Binding Identifier Mobility Options . . . . . 24
5.3.3. Receiving BU with Flow Summary Option . . . . . . . . 24 5.3.2. Handling Flow Identification Mobility Options . . . . 25
5.3.4. Handling flow binding Removals . . . . . . . . . . . . 24 5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 28
5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 25 5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 28
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 25 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 29
6. Security considerations . . . . . . . . . . . . . . . . . . . 27 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. Security considerations . . . . . . . . . . . . . . . . . . . 31
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support
NEMO Basic Support [RFC3963] allow a mobile node / mobile router to [RFC3963] allow a mobile node / mobile router to manage its mobility
manage its mobility using the binding update message, which binds one using the binding update message, which binds one care-of address to
care-of address to one home address. The binding update message can one home address and associated mobile networks. The binding update
be sent to the home agent. In Mobile IPv6, the binding update can message can be sent to the home agent. In Mobile IPv6, the binding
also be sent to correspondent node or to a mobility anchor point (see update can also be sent to correspondent node or to a mobility anchor
[RFC5380]). The semantics of the binding update are limited to point (see [RFC5380]). The semantics of the binding update are
care-of address changes. That is, [RFC3775], limited to care-of address changes. That is, [RFC3775], [RFC5555],
[I-D.ietf-mext-nemo-v4traversal], and [RFC3963] do not allow a mobile and [RFC3963] do not allow a mobile node / mobile router to bind more
node / mobile router to bind more than one address to the home than one address to the home address. In [RFC5648] Mobile IPv6 and
address. In [I-D.ietf-monami6-multiplecoa] Mobile IPv6 and NEMO NEMO Basic Support are extended to allow the binding of more than one
Basic Support are extended to allow the binding of more than one
care-of address to a home address. This specification further care-of address to a home address. This specification further
extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow it to extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow it to
specify policies associated with each binding. A policy can contain specify policies associated with each binding. A policy can contain
a request for a special treatment of a particular IPv4 or IPv6 flow, a request for special treatment of a particular IPv4 or IPv6 flow,
which is viewed as a group of packets matching a flow descriptor. which is viewed as a group of packets matching a traffic selector.
Hence, this specification allows a mobile node / mobile router to Hence, this specification allows a mobile node / mobile router to
bind a particular flow to a care-of address without affecting other bind a particular flow to a care-of address without affecting other
flows using the same home address. In addition, this specification flows using the same home address. In addition, this specification
allows to bind a particular flow to a particular care-of address allows to bind a particular flow to a particular care-of address
directly with correspondent node and mobility anchor point. directly with correspondent node and mobility agents (i.e., home
agents [RFC3775] and mobility anchor points [RFC5380]).
In this document, a flow is defined as a set of IP packets matching a In this document, a flow is defined as a set of IP packets matching a
flow descriptor. A flow descriptor can identify the source and traffic selector. A traffic selector can identify the source and
destination IP addresses, transport protocol number, the source and destination IP addresses, transport protocol number, the source and
destination port numbers and other fields in IP and higher layer destination port numbers and other fields in IP and higher layer
headers. This specification, however, does not define flow headers. This specification, however, does not define traffic
descriptors and it is assumed that one or more ways of defining flow selectors and it is assumed that one or more ways of defining traffic
descriptors are going to be defined in other specifications. This selectors are going to be defined in other specifications. This
specification, however, does define the sub-option extension format specification, however, does define the traffic selector sub-option
to be used for any defined flows descriptors. format to be used for any defined traffic selectors.
Using the flow identifier option introduced in this specification a Using the flow identifier option introduced in this specification a
mobile node / mobile router can bind one or more flows to a care-of mobile node / mobile router can bind one or more flows to a care-of
address while maintaining the reception of other flows on another address while maintaining the reception of other flows on another
care-of address. Requesting the flow binding can be decided based on care-of address. The mobile node / mobile router assembles the flow
local policies within the mobile node / mobile router and based on binding request based local policies, link characteristics and the
the link characteristics and the types of applications running at the types of applications running at the time. Such policies are outside
time. Such policies are outside the scope of this document. the scope of this document.
It should be noted that the flow identification option can be It should be noted that the flow identification mobility option can
associated with any binding update, whether it is sent to a home be associated with any binding update, whether it is sent to a
agent, correspondent node (in the case of Mobile IPv6), or mobility mobility agent or a correspondent node.
anchor point (in the case of Hierarchical Mobile IPv6).
Note that per-packet load balancing may have negative impacts on TCP Note that per-packet load balancing may have negative impacts on TCP
congestion avoidance mechanisms as it is desirable to maintain order congestion avoidance mechanisms as it is desirable to maintain order
between packets belonging to the same TCP connection. This behaviour between packets belonging to the same TCP connection. This behaviour
is specified in [RFC2702]. Other negative impacts are also is specified in [RFC2702]. Other negative impacts are also foreseen
foreseen for other types of real time connections due to the for other types of real time connections due to the potential
potential variations in RTT between packets. Moreover, per-packet variations in round trip time between packets. Moreover, per-packet
load-balancing will negatively affect traffic with ant-replay load-balancing will negatively affect traffic with anti-reply
protection mechanisms. Hence, per-packet load balancing is not protection mechanisms. Hence, per-packet load balancing is not
currently supported in this extension. envisioned in this specification.
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] or a mobile designate either a mobile node as defined in [RFC3775] and [RFC5648],
router as defined in [RFC3963] unless stated otherwise. or a mobile router as defined in [RFC3963] unless stated otherwise.
3. Terminology 3. Terminology
Terms used in this document are defined in [RFC3753] and [RFC4885]. Terms used in this document are defined in [RFC3753] and [RFC4885].
The following terms are also used in this document: The following terms are also used in this document:
Flow: A flow is identified as a set of data packets that are Flow: A flow is as a set of data packets that are exchanged
exchanged between two nodes and match a given flow description between two nodes. In the context of this specification the term
"flow" is some times used to refer to a plurality of flows as well
as a single flow.
Flow Description: Information that identifies one or more IP Traffic Selector: Information that identifies one or more flows.
packets. The identification can use the source address,
destination port, protocol number, DSCP value, or other
information from the packet with predefined values.
Flow Identifier: An unsigned integer. Flow binding: It consists of a traffic selector, and an action.
IP packets from one or more flows that match the traffic selector
associated with the flow binding, are processed according to the
action associated with the same flow binding.
Flow binding: A triplet consisting of a flow identifier, a flow Flow Identifier: A flow identifier uniquely identifies a flow
descriptor, and an action. An IP packet that matches the triplet binding associated with a mobile node. It is generated by a
will be processed according to the action. mobile node and is cached in the table of flow binding entries
maintained by the MN, HA, CN or MAP.
4. Mobile IPv6 Extensions 4. 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.
4.1. Definition Update for Binding Identifier Mobility Option 4.1. Definition Update for Binding Identifier Mobility Option
This specification updates the definition of the Binding Identifier This specification updates the definition of the Binding Identifier
Mobility option defined in [I-D.ietf-monami6-multiplecoa], as Mobility option defined in [RFC5648], as follows:
follows:
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | Type = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| BID-PRI | | Binding ID (BID) | Status |H| BID-PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
: IPv4 or IPv6 care-of address (CoA) : : IPv4 or IPv6 care-of address (CoA) :
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: The Binding Identifier Mobility option Figure 1: The Binding Identifier Mobility option
BID-PRI BID-PRI
This is a 7-bit unsigned integer placing each BID to a relative This is a 7-bit unsigned integer placing each BID to a relative
priority with other registered BIDs. Value "0" is reserved. A priority with other registered BIDs. Value '0' is reserved and
lower number in this field indicates higher priority, while SHOULD NOT be used. A lower number in this field indicates a
BIDs with the same BID-PRI value have equal priority. This is higher priority, while BIDs with the same BID-PRI value have
consistent with current practice in packet classifiers. equal priority meaning that, the BID used is an implementation
issue. This is consistent with current practice in packet
classifiers.
4.2. Flow Identification Mobility Option 4.2. Flow Identification Mobility Option
The Flow identification mobility option is included in the binding The flow identification mobility option is a new mobility option
update and acknowledgement messages. This option contains [RFC3775] and it is included in the binding update and
information that allows the receiver of a binding update to install acknowledgement messages. This option contains information that
policies on a traffic flow and route it to a given care-of address. allows the receiver of a binding update to install policies on a
Multiple options may exist within the same binding update message. traffic flow and route it to a given care-of address. Multiple
The alignment requirement for this option is 4n. options may exist within the same binding update message. The
alignment requirement for this option is 2n.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID | | Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID-PRI | Action | Rsvd | Status | | FID-PRI | Action | Rsvd | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The flow identification mobility option Figure 2: The Flow Identification Mobility Option
Option Type Option Type
TBD To be assigned by IANA
Option Len Option Len
Length of option, including any sub-options, in 8-octet units Length of the option in octets as per [RFC3775].
FID FID
The Flow Identifier field is an 16-bit unsigned integer that The Flow Identifier field is a 16-bit unsigned integer that
includes the identifier for the flow binding. This field is includes the unique identifier for the flow binding. This
used to refer to an existing binding or to create a new field is used to refer to an existing flow binding or to create
binding. The value of this field is set by the mobile node. a new flow binding. The value of this field is set by the
FID = 0 is reserved and MUST NOT be used. mobile node. FID = 0 is reserved and SHOULD NOT be used.
FID-PRI FID-PRI
This is an unsigned 8-bit priority field to indicate the This is an 8-bit unsigned priority field to indicate the
priority of a particular option. This field is needed in cases priority of a particular option. This field is needed in cases
where two different flow descriptions in two different options where two different flow descriptions in two different options
overlap. The priority field decides which policy should be in overlap. The priority field decides which policy should be in
those cases. A lower number in this field indicates a higher those cases. A lower number in this field indicates a higher
priority. priority. Value '0' is reserved and SHOULD NOT be used. FID-
PRI MUST be unique to each of the flows pertaining to a given
MN.
Action Action
This field specifies the action that needs to be taken by the This 8-bit unsigned integer field specifies the action that
receiver of the binding update containing the flow needs to be taken by the receiver of the binding update
identification option. The details of these requests are containing the flow identification option. The details of
discussed below. these requests are discussed below. The following values are
reserved for the Action field in this option:
0 Reserved and SHOULD NOT be used
1 'Discard'. This value indicates a request to discard all
packets in the flow described by the option. No BIDs are
associated with this Action. Care should be taken when
using this Action as it will lead to disrupting applications
communication. Implementations may consider notifying
impacted applications in mobile nodes.
2 'Forward'. This value indicates a request to send the
flow to one or more addresses indicated in the binding
reference sub-option (see Section 4.2.1.3). One or more
BIDs MUST be associated with this Action. If only one BID
is associated with this action then it is essentially a
request to forward packets to that CoA, otherwise matching
packets are replicated and forwarded to all of the indicated
CoAs. Care should be taken when multiple BIDs are used in
combination with the 'Forward' action as some transport
layers may not be able to handle packet duplication and this
can affect their performance.
3-255 Reserved for future use
Rsvd Rsvd
This field is unused. It MUST be set to zero by the sender and This field is unused. It SHOULD be set to zero by the sender
MUST be ignored by the receiver. and ignored by the receiver.
Status Status
This field indicates the success or failure of the flow binding This 8-bit unsigned integer field indicates the success or
operation for the particular flow in the option. This field is failure of the flow binding operation for the particular flow
not relevant to the binding update message as a whole or to in the option. This field is not relevant to the binding
other flow identification options. Values from 0 to 127 update message as a whole or to other flow identification
indicate success. Values of 128 and higher indicate failure. options. This field is only relevant when included in the
This field is only relevant when included in the Binding Binding Acknowledgement message and must be ignored in the
Acknowledgement message and must be ignored in the binding binding update message. The following values are reserved for
update message. the status field within the flow identification mobility
option:
The following values are reserved for the Action field in this 0 Flow binding successful
option:
1 Discard. This value indicates a request to discard all packets 128 Administratively prohibited
in the flow described by the option. No BIDs are associated with
this Action.
2 n-cast. This value indicates a request to send the flow to one 129 Flow binding rejected, reason unspecified
or more addresses indicated in the Binding Reference sub-option. 130 Flow identification mobility option malformed
One or more BIDs MUST be associated with this Action. If only one
BID is associated with this action then it is essentially a
request to forward packets to that CoA. Care should be taken when
the n-cast action is used as some transport layers may not be able
to handle packet duplication and this can affect their
performance.
The following values are reserved for the status field within the 131 BID not found
flow identification option:
0 Flow binding successful. 132 FID not found
128 Flow binding rejected, reason unspecified. 133 Traffic selector format not supported
129 Flow identification option malformed. 134 Discard function not supported
130 Administratively prohibited. 135 Forward function not supported
135 FID already in use Sub-options (optional)
136 FID not found zero or more sub-options, defined in Section 4.2.1
137 FD-Type not supported. 4.2.1. Flow Identification Sub-Options definition
138 Discard function not supported. Flow identification sub-options are encoded within the remaining
space of the flow identification mobility option, using a sub-option
type-length-value (TLV) format as follows:
139 N-cast function not supported. 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 Length | Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A number of sub-options can follow the option defined in this Figure 3: Flow Identification Sub-Option format
section. These are defined below.
4.2.1. Binding Reference Sub-option Sub-opt Type
This section introduces the Binding Reference sub-option, which may 8-bit unsigned integer indicating the sub-option Type. When
be included in the Flow identification option. The Binding Reference processing a flow identification mobility option containing an
sub-option includes one or more BIDs defined in MCoA option for which the sub-option Type value is not recognized by
[I-D.ietf-monami6-multiplecoa]. When this sub-option is included in the receiver, the receiver MUST quietly ignore and skip over
the Flow identification option it associates the flow described with the option, correctly handling any remaining sub-options in the
one or more registered BIDs. same option.
Sub-opt Len
8-bit unsigned integer, representing the length in octets of
the flow identification sub-option. This field indicates the
length of the sub-option not including the Sub-opt Type and
Sub-opt Length fields. Note that Sub-opt Type '0'
(Section 4.2.1.1) is a special case that does not take a Sub-
opt Length field.
Sub-Option Data
A variable length field that contains data specific to the sub-
option
The following subsections specify the sub-option types which are
currently defined for use in the flow identification option.
Implementations MUST silently ignore any sub-options that they do not
understand.
These sub-options may have alignment requirements. Following the
convention in [RFC3775], regarding mobility options, these sub-
options are aligned in a packet so that multi-octet values within the
sub-option Data field of each sub-option fall on natural boundaries
(i.e., fields of width n octets are placed at an integer multiple of
n octets from the start of the header, for n = 1, 2, 4, or 8) .
4.2.1.1. Pad1
The Pad1 sub-option does not have any alignment requirements. Its
format is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Sub-Opt Type |
+-+-+-+-+-+-+-+-+
Sub-opt Type
0
NOTE! the format of the Pad1 sub-option is a special case - it has
neither sub-option Length nor sub-option Data fields.
The Pad1 sub-option is used to insert one octet of padding in the
flow identification option. If more than one octet of padding is
required, the PadN sub-option, described next, should be used rather
than multiple Pad1 sub-options.
4.2.1.2. PadN
The PadN sub-option does not have any alignment requirements. Its
format is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Sub-Opt Type | Sub-Opt Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Sub-opt Type
1
Sub-opt Len
set to the length of the sub-option
Sub-opt Data
0 or more bytes set to 0 by the sender and ignored by the
receiver.
The PadN sub-option is used to insert two or more octets of padding
in the flow identification mobility option. For N octets of padding,
the sub-option Length field contains the value N, and the sub-option
data consists of N-2 zero-valued octets. PadN sub-option data MUST
be ignored by the receiver.
4.2.1.3. Binding Reference Sub-option
This section introduces the binding reference sub-option, which may
be included in the flow identification mobility option. A node MUST
NOT include more than one binding reference sub-options in a given
flow binding identification option. The binding reference sub-option
includes one or more BIDs defined in MCoA [RFC5648]. When this sub-
option is included in the flow identification mobility option it
associates the flow described with one or more registered BIDs.
When binding a flow using this sub-option, the binding identifier When binding a flow using this sub-option, the binding identifier
option, defined in [I-D.ietf-monami6-multiplecoa], MUST be defined in mobility option, defined in [RFC5648], MUST be included in either the
either the same or an earlier BU. The Binding Reference sub-option same or an earlier BU. The binding reference sub-option is shown
is shown below. below. The alignment requirement for this sub-option is 2n.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID ........ | BID ........
+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-
Figure 4: The Binding Reference sub-option
Figure 3: The Binding Reference sub-option
Sub-opt Type Sub-opt Type
Indicates the Sub-option type. For the Binding Reference sub- 2
option, this field MUST be set to 1.
Sub-opt Len Sub-opt Len
Indicates the sub-option length in octets. This field includes Variable
the entire length of the sub-option including the Sub-opt Type
and Sub-opt-Len fields.
BID BID
The BID that the mobile node wants to associate with the flow A 16-bit unsigned integer indicating the BID that the mobile
identification option. One or more BID fields can be included node wants to associate with the flow identification option.
in this sub-option. Since each BID is 2 byte long, the value One or more BID fields can be included in this sub-option.
of the Sub-opt Len field indicates the number of BIDs present. Since each BID is 2 bytes long, the value of the Sub-opt Len
Number of BIDs = (Sub-opt Len-2)/2. field indicates the number of BIDs present. Number of BIDs =
Sub-opt Len/2.
4.2.2. Flow Description Sub-option 4.2.1.4. Traffic Selector sub-option
The Flow description sub-option(s) include the parameters used to The traffic selector sub-option includes the parameters used to match
match packets for a specific flow binding. packets for a specific flow binding. A node MUST NOT include more
than one traffic selector sub-option in a given flow binding
identification option.
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 | Flow Description ... |Sub-opt Type | Sub-Opt Len | TS Format | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Selector ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Flow Description sub-option Figure 5: The Traffic Selector sub-option
Sub-opt Type Sub-opt Type
Indicates the Sub-option type. For the flow description sub- 3
option, this field SHOULD be set to one of the FD types defined
below.
Sub-opt Len Sub-opt Len
Indicates the sub-option length in octets. This field includes variable
the entire length of the sub-option including the Sub-opt Type
and Sub-opt-Len fields.
Flow Description TS Format
The flow description corresponding to the type indicated by the An 8-bit unsigned integer indicating the Traffic Selector Format.
Sub-opt Type field. Flow description is out of scope of this Value "0" is reserved and SHOULD NOT be used.
document.
The following values are reserved for the sub-option Type values are Reserved
defined for Flow Description:
17-32 reserved for Flow Description formats. An 8-bit reserved field. It SHOULD be set to zero by the sender
and ignored by the receiver.
4.3. Flow Identification Summary Mobility Option Traffic Selector
The Flow Identification Summary Mobility option includes one or more A variable length field, the format and content of which is out of
flow identifiers (FIDs) for the purpose of refresing their state scope for this specification.
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 4.2.2. Flow Summary Mobility Option
The flow summary mobility option is a new mobility option [RFC3775],
which includes one or more flow identifiers (FIDs) for the purpose of
refreshing their state. A node MUST NOT include more than one flow
summary mobility option in a given binding update message. The
alignment requirement for this option is 2n.
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 | FID | | Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID ........ | FID ........
+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-
Figure 5: The Flow Identification Summary Option Figure 6: The Flow Summary Mobility Option
Option Type Option Type
TBD To be assigned by IANA
Option Length Option Length
Length of option, including any sub-options, in 8-octet units Length of the option in octets as per [RFC3775]
FID FID
A registered FID. One or more FID fields can be included in A 16-bit unsigned integer indicating a registered FID. One or
this option. Since each FID is 2 bytes long, the value of the more FID fields can be included in this option. Number of FIDs
Option Len field indicates the number of FIDs present. = Option Len/2
4.4. Flow Bindings entries list and its relationship to Binding Cache 4.3. Flow Bindings entries list and its relationship to Binding Cache
The conceptual mobile IPv6 binding cache was defined in [RFC3775] to The conceptual mobile IPv6 binding cache was defined in [RFC3775] to
identify the mobile IP state maintained by the mobile node, home identify the mobile IP state maintained by the mobile node, mobility
agent, and corresponding node. The binding cache includes, between agent, and correspondent node. The binding cache includes, between
others, the mobile node's home address, the registered care-of others, the mobile node's home address, the registered care-of
address, and the lifetime of the binding. The binding cache was then address, and the lifetime of the binding. The binding cache has been
extended by [I-D.ietf-monami6-multiplecoa] to include more than one extended by [RFC5648] to include more than one care-of addresses and
care-of addresses and to associate each of them with a Binding to associate each of them with a Binding Identifier (BID).
Identifier (BID).
This specification does not modify the mobile IPv6 binding cache any This specification does not modify the mobile IPv6 binding cache any
further. further.
Flow bindings can be thought of as a conceptual list of entries that Flow bindings can be thought of as a conceptual list of entries that
is separate from the binding cache. The flow bindings list contains is separate from the binding cache. The flow bindings list contains
an entry for each of the registered flow binding. Flow binding an entry for each of the registered flow bindings. Flow binding
entries can point to an entry in the binding cache by means of the entries can point to an entry in the binding cache by means of the
BID. Each flow binding entry include the following parameters : BID. Each flow binding entry includes the following parameters :
* FID (Flow Identifier): For a given mobile node, identified by o FID (Flow Identifier): For a given mobile node, identified by its
its primary home address, the FID MUST uniquely identify an home address, the FID MUST uniquely identify an entry, i.e. a
entry, i.e. a unique flow binding. Each mobile node can only unique flow binding. Each mobile node can only have a single
have a single entry identified by a given FID at any one time. entry identified by a given FID at any one time. Different mobile
Different mobile nodes can use the same FID number space. nodes can use the same FID number space.
* A Flow Descriptor: Included in a Flow Description sub-option. o A Traffic Selector: Included in a traffic selector sub-option.
* BID(s): The list of BIDs associated with the entry as defined o BID(s): The list of BIDs associated with the entry as defined by
by the Binding Reference sub-option included in the FID option the binding reference sub-option included in the FID option that
that created it. created it.
* Action: The action associated with a given entry as defined by o Action: The action associated with a given entry as defined by the
the Action field of the FID option that created it Action field of the FID option that created it
* Active/Inactive flag: This flag indicates whether the entry is o Active/Inactive flag: This flag indicates whether the entry is
active or inactive. active or inactive.
* FID-PRI: This field indicates the priority of the flow and is o FID-PRI: This field indicates the priority of the flow and is used
used to break the tie between overlapping flows. to break the tie between overlapping flows.
The flow bindings list is associated with a given mobile node, and The flow bindings list is associated with a given mobile node, and
the corresponding binding cache. An entry in the flow bindings list, the correspondent binding cache. An entry in the flow bindings list,
however, is identified by the FID and the list is ordered according however, is identified by the FID and the list is ordered according
to the FID-PRI field as defined in the FID option that created each to the FID-PRI field as defined in the FID option that created each
entry. entry.
A valid BID is required to make the entry "active". If all of the For entries that take BIDs (i.e., entries that do not indicate a
BIDs pointed to by a given entry are not valid BIDs in the binding 'Discard' action), a valid BID is required to make the entry
cache, the flow binding entry becomes "inactive", in other words it 'Active'. If all of the BIDs pointed to by a given entry are
does not affect data traffic. Note that if the action parameter in deregistered [RFC5648], the flow binding entry becomes 'Inactive', in
an entry indicates "n-cast" then the entry becomes inactive only if other words it does not affect data traffic. Note that if the action
none of the BIDs is valid. If only some of the BIDs are valid, the parameter in an entry indicates 'Forward' then the entry becomes
invalid BIDs are simply ignored. 'Inactive' only if all of the BIDs are deregistered. If only some of
the BIDs are still valid, the invalid BIDs are simply ignored.
Also note that the state described in this section is maintained by Also note that the state described in this section is maintained by
the mobile node as well as in mobility agents and corresponding the mobile node as well as in mobility agents and correspondent
nodes. As such the mobile node is fully aware of which are the valid nodes. As such the mobile node is fully aware of which are the valid
BIDs at any time and which flow binding entries are active/inactive. BIDs at any time and which flow binding entries are active/inactive.
Section 5 defines how these flow binding entries are manipulated by Section 5 defines how these flow binding entries are manipulated by
the mobile node in detail. the mobile node in detail.
As an example the following represents an ordered flow bindings As an example the following represents an ordered flow binding entry
entries table for a mobile node that has registered multiple care-of table for a mobile node that has registered multiple care-of
addresses and flow bindings. addresses and flow bindings.
FID-PRI FID Flow Description BIDs Action A/I FID-PRI FID Traffic Selector BIDs Action A/I
------- --- ---------------- ---- ------- ------ ------- --- ---------------- ---- ------- ------
10 4 TCP 2 Forward Active 10 4 TCP 2 Forward Active
20 3 srcAddr=IPx N/A Discard Active 20 3 srcAddr=IPx N/A Discard Active
30 2 srcAddr=IPy 4 Forward Inactive 30 2 srcAddr=IPy 4 Forward Inactive
40 5 UDP 1,3 N-Cast Active 40 5 UDP 1,3 Forward Active
Ordered Flow Binding Entries Ordered Flow Binding Entries
According to the above list of flow binding entries, all TCP traffic According to the above list of flow binding entries, all TCP traffic
will match the first entry, and according to the Action indicated it will match the first entry, and according to the Action indicated it
will be forwarded to BID2, corresponding to a given care-of address will be forwarded to BID2, corresponding to a given care-of address
(IP3), as shown below. Any traffic that is not TCP, but has as (IP3), as shown below. Any traffic that is not TCP, but has as
source address IPx will match the second entry, and according to the source address IPx will match the second entry, and according to the
associated Action it will be discarded. Note that any TCP traffic associated Action it will be discarded. Note that any TCP traffic
with source address IPx will match the first entry and thus it will with source address IPx will match the first entry and thus it will
be forwarded as per that entry. be forwarded as per that entry.
The third entry is marked as Inactive since the BID 4 does not exist The third entry is marked as Inactive since the BID 4 does not exist
in the ordered list of BID entries below. Inactive entries do not in the ordered list of BID entries below. Inactive entries do not
affect traffic, i.e., packets are not matched against them. affect traffic, i.e., packets are not matched against them.
Any UDP traffic that does not match any of the earlier entries will Any UDP traffic that does not match any of the earlier entries will
match the third rule and according to the Action indicated it will be match the forth rule and according to the Action indicated, it will
replicated and forwarded to BIDs 1 and 3, corresponding to care-of be replicated and forwarded to BIDs 1 and 3, corresponding to care-of
addresses IP1 and IP2 shown below. addresses IP1 and IP2 shown below.
Finally any remaining packets that do not match any of the entries Finally any remaining packets that do not match any of the entries
above will be simply forwarded to the care-of address indicated by above will be simply forwarded to the care-of address indicated by
the highest order BID in the table below. In the example, such the highest order BID in the table below. In the example, such
packets will be forwarded to BID 1, corresponding to care-of address packets will be forwarded to BID1 corresponding to care-of address
IP1. IP1.
BID-PRI BID CoA BID-PRI BID CoA
--------- --- --- --------- --- ---
20 1 IP1 20 1 IP1
30 3 IP2 30 3 IP2
30 2 IP3 30 2 IP3
Ordered BID Entries Ordered BID Entries
Mobility agent and corresponding node implementations should take
care to avoid flow binding rules affecting the fundamental operation
of Mobile IPv6 and its extensions. In particular, flow binding rules
MUST NOT apply to Mobile IPv6 signaling generated by mobility agents
and corresponding nodes communicating with a given mobile node, since
that could adversely affect the operation of the protocol. Other,
non Mobile IPv6 traffic generated by these entities SHOULD be matched
against the mobile node's flow binding rules as normal.
5. Protocol operations 5. Protocol operations
5.1. General 5.1. General
This specification introduces a flow bindings list of entries and an This specification introduces a flow bindings list of entries and an
ordered list of binding identifiers, allowing mobile nodes to ordered list of flow binding identifiers, allowing mobile nodes to
associate flow binding policies with the registered care-of associate flow binding policies with the registered care-of
addresses. addresses.
The flow identification option defines how the mobile node can The flow identification mobility option defines how the mobile node
control a set of flow binding entries maintained in a home agent, can control a set of flow binding entries maintained in a mobility
correspondent node, or mobility anchor points, on its behalf. The agent, or correspondent node. The fields of the flow identification
fields of the flow identification option are necessary for ordering mobility option are necessary for ordering flow identification
flow identification options, indicating the sort of action that mobility options, indicating the sort of action that should be
should be undertaken to the recipient's flow binding list of entries undertaken to the recipient's flow binding list of entries or for
or for carrying the results of such a petition. carrying the results of such a petition.
This specification allows mobile nodes to direct flows to a This specification allows mobile nodes to direct flows to a
particular care-of address. The granularity of what constitutes a particular care-of address. The granularity of what constitutes a
flow depends on the flow descriptor used. As indicated earlier the flow depends on the traffic selector used.
flow description itself is defined in another document.
The remaining of this section discusses how mobile nodes can use the The remainder of this section discusses how mobile nodes can use the
options and sub-options defined in this document when sending binding options and sub-options defined in this document when sending binding
updates to the correspondent node, home agent or mobility anchor updates to the correspondent node, home agent, or mobility anchor
point. In addition, refresh, deletion, and modification of bindings point. In addition, refresh, deletion, and modification of flow
are all discussed below. binding entries are all discussed below.
5.1.1. Preferred Care-of address 5.1.1. Preferred Care-of address
Any node that supports this specification MUST maintain an ordered Any node that supports this specification MUST maintain an ordered
list of care-of addresses for each mobile node it maintains a list of list of care-of addresses for each mobile node it maintains a list of
flow bindings for. The ordered list of care-of addresses is built flow bindings for. The ordered list of care-of addresses is built
based on the BID-PRI field of the Binding Identifier option (see based on the BID-PRI field of the binding identifier mobility option
Section 4.1). (see Section 4.1).
The ordered list of BIDs is used to determine how to forward a packet The ordered list of BIDs is used to determine how to forward a packet
to a given mobile node when the packet does not match any of the flow to a given mobile node when the packet does not match any of the flow
binding entries defined in Section 4.4. A packet that does not match binding entries defined in Section 4.3. A packet that does not match
any of the flow binding entries SHOULD be forwarded to the care-of any of the flow binding entries SHOULD be forwarded to the care-of
address identified by the BID with the highest priority i.e., lowest address identified by the BID with the highest priority i.e., lowest
BID-PRI value. BID-PRI value.
5.2. Mobile Node Considerations 5.2. Mobile Node Considerations
This specification allows the mobile node to maintain several This specification allows the mobile node to maintain several
bindings with its home agent, MAP and correspondent nodes and to bindings with its mobility agent, and correspondent nodes and to
direct packets to different care-of addresses according to flow direct packets to different care-of addresses according to flow
bindings. This section details the mobile node operations necessary bindings. This section details the mobile node operations necessary
to implement this specification. to implement this specification.
The home agent list of flow bindings is manipulated by the mobile The mobility agent and correspondent node list of flow bindings is
node, via flow identification and flow summary options included in manipulated by the mobile node, via flow identification and flow
binding update messages. Each flow binding update can add, modify, summary mobility options included in binding update messages. Each
refresh, or delete a given binding. More than one flow flow binding update can add, modify, refresh, or delete a given
identification options MAY be included in the same binding update but binding. More than one flow identification mobility options MAY be
each of them MUST include a different FID. In other words, two flow included in the same binding update but each of them MUST include a
identification options in the same message can not be about the same different FID. In other words, two flow identification options in
flow binding. the same message can not be about the same flow binding.
All flow binding state MUST be refreshed in every binding update the All flow binding state MUST be refreshed in every binding update the
mobile node sends. Any previously registered flow binding that is mobile node sends. Any previously registered flow binding that is
not included in a given binding update will be deleted. So, any flow not included in a given binding update will be deleted. So, any flow
bindings that are not added or modified by a flow identification bindings that are not added or modified by a flow identification
option, but have previously registered and need to be maintained MUST mobility option, but have previously registered and need to be
be included in a flow summary option. Only one flow summary option maintained MUST be included in a flow summary mobility option. Only
can be included in a given binding update. one flow summary mobility option can be included in a given binding
update.
5.2.1. Sending BU with BID Options 5.2.1. Sending BU with BID Options
This specification (see Section 4.1) updates the definition of the This specification (see Section 4.1) updates the definition of the
Binding Identifier option, originally defined in binding identifier mobility option, originally defined in [RFC5648].
[I-D.ietf-monami6-multiplecoa]. According to this specification the According to this specification the BID option includes a BID-PRI
BID option includes a BID-PRI field assigning each registered care-of field assigning each registered care-of address a priority, and thus
address a priority, and thus placing them in an ordered list as also placing them in an ordered list as also described in Section 4.3.
described in Section 4.4.
Mobile nodes supporting this specification MUST use the BID option Mobile nodes supporting this specification MUST use the BID option
format defined in Section 4.1. Mobiles nodes MUST also register all format defined in Section 4.1. Mobile nodes MUST also register all
care-of addresses using the updated BID option format, either in the care-of addresses using the updated BID option format, either in the
same BU as any flow identification options using them, or in earlier same BU as any flow identification mobility options using them, or in
BUs. earlier BUs.
5.2.2. Sending BU with Flow Identification Options 5.2.2. Sending BU with Flow Identification Mobility Options
5.2.2.1. Adding flow bindings 5.2.2.1. New 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 mobility option in the binding update, with the FID
concerned with each flow identification option in the binding update, field set to a value that is not already present in the list of flow
must be logically registered by this binding update, or must have binding entries maintained by the receiver. The care-of address(es)
already been registered by the receiver of the binding update in an associated with each flow identification mobility options in the
earlier binding update , as defined in Section 5.2.1. binding update, must be logically registered by this binding update,
or must have already been registered by the receiver of the binding
update in an earlier binding update, as defined in Section 5.2.1.
The flow identification option MUST include a unique Flow Identifier The flow identification mobility option MUST include a unique flow
in the FID field. The FID needs only be unique for the receiver of identifier in the FID field. The FID needs only be unique for the
the binding update and for the same sender, i.e. the same FID can be receiver of the binding update and for the same sender, i.e. the same
used across different receivers of the binding update, for the same FID can be used across different receivers of the binding update, for
sender. the same sender.
The FID-PRI field is set to the desired unique priority of the The FID-PRI field is set to the desired unique priority of the
FID, defining the order of the binding to be added in the list of FID, defining the order of the flow binding to be added in the
flow binding entries as defined in Section 4.4. list of flow binding entries as defined in Section 4.3.
The Action field is set to one of the defined action codes (see The Action field is set to one of the defined action codes (see
Section 4.2). Section 4.2).
The Status filed is set to zero in all binding update messages. The Status field is set to zero in all binding update messages.
The mobile node MUST include exactly one Flow Description sub-option Since this flow identification mobility option is requesting the
(see Section 4.2.2) describing the flow associated with the new addition of a new flow binding in the list of flow bindings
binding. maintained by the receiver, the mobile node MUST include exactly one
Traffic Selector sub-option (see Section 4.2.1.4) describing the flow
associated with the new flow binding. The TS Format field of the
Traffic Selector sub-option MUST be set to the non-zero value of the
format used by the mobile node.
The mobile node MAY also include exactly one BID Reference sub-option The mobile node MAY also include up to one BID Reference sub-option
(see Section 4.2.1) to associate the flow binding with a given set of (see Section 4.2.1.3) to associate the flow binding with a given set
BIDs and corresponding CoAs. Depending on the Action field of the of BIDs and corresponding CoAs. Depending on the Action field of the
Flow Binding Identifier option, the following rules MUST be followed flow identification mobility option, the following rules MUST be
with respect to the Binding Reference sub-option: followed with respect to the binding reference sub-option:
- if the Action indicates 'Discard', the Binding Reference sub- - if the Action indicates 'Discard', the binding reference sub-
option SHOULD NOT be included. If it is included it will be option SHOULD NOT be included. If it is included it will be
ignored by the receiver. ignored by the receiver.
- if the Action indicates 'n-cast', a single Binding Reference - if the Action indicates 'Forward', a single binding reference
sub-option with one or more BIDs MUST be included. sub-option with one or more BIDs MUST be included.
5.2.2.2. Modifying flow bindings 5.2.2.2. Updating Flow Bindings
Flow binding modification is essentially a process where an existing Flow binding modification is essentially a process where parameters
flow binding is removed from the list of flow binding entries and a associated with an existing flow binding in the list of flow binding
new flow binding (included in the option) is added, and given the entries is replaced by parameters included in the flow identification
same FID as the flow that was removed. With this procedure the mobility option, and the same FID is maintained. With this procedure
mobile node can change the action, the priority, the BID, or the flow the mobile node can change the action, the priority, the BID, and/or
description associated with a flow binding. the traffic selector associated with a flow binding.
To modify an existing flow binding the mobile node MUST send a To modify an existing flow binding the mobile node MUST send a
binding update with a flow identification option, with the FID field binding update with a flow identification option, with the FID field
set to one of the FID values already in the list of flow binding set to one of the FID values already in the list of flow binding
entries. entries.
The FID-PRI and Action fields MUST be set to the unique desired The FID-PRI and Action fields MUST be set to the priority value
value to be implemented with this modification. for the flow binding entry.
The Status field is set to zero since this option is in a binding The Status field is set to zero since this option is in a binding
update. update.
The mobile node MAY include exactly one Flow Description sub-option The mobile node MAY include exactly one traffic selector sub-option
(see Section 4.2.2) describing the modified flow to be associated (see Section 4.2.1.4) describing the updated flow to be associated
with the binding. with the flow binding. The mobile node MAY, however, omit the
traffic selector sub-option if it wants the traffic selector
currently associated with the flow binding entry identified by the
FID field to be maintained.
The mobile node MAY also include exactly one BID Reference sub-option The mobile node MAY include exactly one binding reference sub-option
(see Section 4.2.1) to associate the existing binding with a new set (see Section 4.2.1.3) to associate the existing flow binding with a
of CoAs. The rules regarding the Binding Reference sub-option in new set of CoAs. If the mobile node includes a binding reference
this case are identical to those described from flow binding addition sub-option then it should follow the rules described in
in Section 5.2.2.1 . Section 5.2.2.1. The mobile node MAY omit the binding reference sub-
option if it wants the BIDs currently associated with the flow
binding entry identified by the FID field to be maintained.
Note that it is also possible for the mobile node to effectively Note that it is also possible for the mobile node to effectively
modify the effect of a flow binding entry without actually changing modify the effect of a flow binding entry without actually changing
the entry itself. This can be done by changing the CoA associated the entry itself. This can be done by changing the CoA associated
with a given BID, which is a process defined in detail in with a given BID, which is a process defined in detail in [RFC5648].
[I-D.ietf-monami6-multiplecoa].
5.2.3. Sending BU with a Flow Summary Option 5.2.3. Sending BU with a Flow Summary Option
When the mobile node sends a binding update it MUST refresh all flow When the mobile node sends a binding update it MUST refresh all flow
bindings it wants to maintain even if it does not want to change any bindings it wants to maintain even if it does not want to change any
of their parameters. of their parameters.
To refresh an existing flow binding the mobile node MUST send a To refresh an existing flow binding the mobile node MUST send a
binding update with a flow summary option. The flow summary option binding update with a flow summary option. The flow summary option
MUST include one or more FID fields as indicated in Section 4.3. MUST include one or more FID fields as indicated in Section 4.2.2.
Each FID field included MUST be set to one of the FID values already Each FID field included MUST be set to one of the FID values already
in the list of flow binding entries. in the list of flow binding entries.
Any flow bindings (active or inactive) that are not included in a Any flow bindings (active or inactive) that are not included in a
binding update will be removed from the list of flow binding entries. binding update will be removed from the list of flow binding entries.
Note that any inactive flow bindings, i.e., flow bindings without Note that any inactive flow bindings, i.e., flow bindings without
associated BIDs that are marked as Inactive in the list of flow associated BIDs that are marked as Inactive in the list of flow
binding entries (see Section 4.4), MUST also be refreshed, or binding entries (see Section 4.3), MUST also be refreshed, or
modified, to be maintained. If they are not included in a BU they modified, to be maintained. If they are not included in a BU they
will be removed. will be removed.
5.2.4. Removing flow bindings 5.2.4. Removing flow bindings
Removal of flow binging entries is performed implicitly by omission Removal of flow binding entries is performed implicitly by omission
of a given FID from a binding update. of a given FID from a binding update.
To remove a flow binding the MN simply sends a binding update that To remove a flow binding the MN simply sends a binding update that
includes flow identification and flow summary options for all the includes flow identification and flow summary mobility options for
FIDs that need to be refreshed, modified, or added, and simply omits all the FIDs that need to be refreshed, modified, or added, and
any FIDs that need to be removed. simply omits any FIDs that need to be removed.
Note that a mobile node can also remove the BIDs associated with a Note that a mobile node can also render a flow binding inactive by
given Flow Binding, without removing the flow binding itself. The removing the BIDs associated with it, without removing the flow
procedure for removing a BID is defined in detail in binding itself. The procedure for removing a BID is defined in
[I-D.ietf-monami6-multiplecoa]. detail in [RFC5648].
When all the BIDs associated with a flow binding are removed, the When all the BIDs associated with a flow binding are removed, the
flow binding MUST be marked as inactive in the list of flow binding flow binding MUST be marked as inactive in the list of flow binding
entries as shown in Section 4.4. In other words the state associated entries as shown in Section 4.3. In other words the state associated
with the flow binding MUST be maintained but it does no longer affect with the flow binding MUST be maintained but it does no longer affect
the mobile node's traffic. The MN can return an inactive flow the mobile node's traffic. The MN can return an inactive flow
binding to the active state by using the flow binding modification binding to the active state by using the flow binding modification
process described in Section 5.2.2.2, to associate it again with one process described in Section 5.2.2.2, to associate it again with one
or more valid BIDs. or more valid BIDs. Remember that flow bindings indicating a
'Discard' action do not take BIDs and thus cannot be rendered
inactive. Instead these entries can only be removed by omitting
their FID from a subsequent BU.
5.2.5. Receiving Binding Acknowledgements 5.2.5. Returning Home
This specification is compatible to the home registration procedures
defined in [RFC3775] and [RFC5648]. More specifically, if the mobile
node performs an [RFC3775] style deregistration, all of its bindings,
including flow bindings are deleted. If the mobile node, however,
performs an [RFC5648] style home registration, then the home link is
associated with a specific BID and so, as far as this specification
is concerned, it is treated as any other link associated with a given
BID.
5.2.6. Receiving Binding Acknowledgements
According to [RFC3775] all nodes are required to silently ignore According to [RFC3775] all nodes are required to silently ignore
mobility options not understood while processing binding updates. As mobility options not understood while processing binding updates. As
such a mobile node receiving a Binding Acknowledgement in response to such a mobile node receiving a Binding Acknowledgement in response to
the 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 every flow identification options Acknowledgement contains a copy of every flow identification mobility
included in the binding update. A Binding Acknowledgement without options included in the binding update. A Binding Acknowledgement
flow identification option(s), in response to a Binding Update with without flow identification option(s), in response to a Binding
flow identification option, would indicate inability (or Update with flow identification mobility option, would indicate
unwillingness) on behalf of the source node to support the extensions inability (or unwillingness) on behalf of the source node to support
presented in this document. the extensions presented in this document.
If a received Binding Acknowledgement contains a copy of each flow If a received Binding Acknowledgement contains a copy of each flow
identification option that was sent within the binding update, the identification mobility option that was sent within the binding
status field of each flow identification option indicates the status update, the status field of each flow identification option indicates
of the flow binding on the distant node. the status of the flow binding on the distant node.
5.2.6. Return Routability Procedure 5.2.7. Return Routability Procedure
A mobile node may perform route optimization with correspondent nodes A mobile node may perform route optimization with correspondent nodes
as defined in [RFC3775]. Route optimization allows a mobile node to as defined in [RFC3775]. Route optimization allows a mobile node to
bind a care-of address to a home address in order to allow the 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 correspondent node to direct the traffic to the current location of
the mobile node. Before sending a Binding Update to correspondent the mobile node. Before sending a Binding Update to correspondent
node, the Return Routability Procedure needs to be performed between node, the Return Routability Procedure needs to be performed between
the mobile node and the correspondent node. the mobile node and the 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 [RFC3775]) was not used to generate the key for token (see RFC3775 [RFC3775]) was not used to generate the key for
securing the Binding Update. This limitation prohibits the sender securing the Binding Update. This limitation prohibits the sender
from requesting the n-cast action for multiple addresses before from requesting the 'Forward' action for multiple addresses before
having registered each care-of address one by one. having registered each care-of address one by one.
5.3. HA, MAP, and CN Considerations 5.3. HA, MAP, and CN Considerations
This specification allows the home agents, mobility anchor points, This specification allows the mobility agents (Home Agents and
and corresponding nodes to maintain several bindings for a given home Mobility Anchor Points), and correspondent nodes to maintain several
address and to direct packets to different care-of addresses flow bindings for a given home address and to direct packets to
according to flow bindings. This section details the home agent different care-of addresses according to flow bindings. This section
operations necessary to implement this specification. These details the home agent operations necessary to implement this
operations are identical for MAPs and CNs unless otherwise stated. specification. These operations are identical for MAPs and CNs
unless otherwise stated.
Note that route optimization is only defined for mobile nodes (MIPv6 Note that route optimization is only defined for mobile nodes (MIPv6
[RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these
sections only apply to correspondent nodes with respect to mobile sections only apply to correspondent nodes with respect to mobile
nodes and not for mobile routers. nodes and not for mobile routers.
5.3.1. Receiving BU with BID Options 5.3.1. Handling Binding Identifier Mobility Options
This specification (see Section 4.1) updates the definition of the This specification (see Section 4.1) updates the definition of the
Binding Identifier option, originally defined in binding identifier mobility option, originally defined in [RFC5648].
[I-D.ietf-monami6-multiplecoa]. According to this specification the According to this specification the BID option includes a BID-PRI
BID option includes a BID-PRI field assigning each registered care-of field assigning each registered care-of address a priority, and thus
address a priority, and thus placing them in an ordered list (see placing them in an ordered list (see Section 4.3).
Section 4.4).
Home agents receiving BUs including BID options and flow Home agents receiving BUs including BID options and flow
identification options MUST logically process BID options first. identification options MUST logically process BID options first.
This is because BID Reference sub-options included in the flow This is because BID Reference sub-options included in the flow
identification options might refer to BIDs defined in BID options identification mobility options might refer to BIDs defined in BID
included in the same message. options included in the same message.
The BID option is processed as defined in The BID option is processed as defined in [RFC5648] but then the BID
[I-D.ietf-monami6-multiplecoa] but then the BID to care-of address to care-of address mapping is placed in an ordered list according to
mapping is placed in an ordered list according to the BID-PRI field the BID-PRI field of the BID option.
of the BID option.
5.3.2. Receiving BU with Flow Identification Options Binding Identifier registrations and deregistrations indirectly
affect the MN's flow binding entries. The home agent MUST update the
flow binding entries table accordingly as BIDs are added or removed (
[RFC5648]). For example, as discussed in Section 4.3, if all of the
BIDs associated with a given flow binding entry are removed (i.e.,
become invalid) the entry MUST be marked as inactive. While if any
of the invalid BIDs associated with an inactive flow binding entry
are registered (i.e., become valid), the entry MUST be marked as
active.
5.3.2. Handling Flow Identification Mobility Options
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 mobility option, it first performs the
described in section 10.3.1 of RFC3775. operation described in section 10.3.1 of RFC3775, followed by the
operations defined in Section 5.3.1 of this document.
Home agents that do not support this specification will ignore the Home agents that do not support this specification will ignore the
flow identification options and all their suboption, having no effect flow identification mobility options and all their sub-options,
on the operation of the rest of the protocol. having no effect on the operation of the rest of the protocol.
If the binding update is accepted, and the home agent is willing to If the binding update is accepted, and the home agent is willing to
support flow bindings for this MN, the home agent checks the flow support flow bindings for this MN, the home agent checks the flow
identification options. identification mobility options.
If more than one flow identification option in the same BU, has the If more than one flow identification mobility option in the same BU,
same value in the FID field, all the flow identification options MUST has the same value in the FID field, all the flow identification
be rejected. mobility options MUST be rejected.
If all FID fields have different values the flow identification If all FID fields have different values the flow identification
options can be processed further and in any order, as defined by the mobility options can be processed further and in any order, as
following subsections. defined by the following subsections.
5.3.2.1. Handling Flow Binding Add Requests
If the FID field of the flow identification option is already present
in the list of flow binding entries for this mobile node, the home
agent MUST reject this flow binding add request by copying the flow
identification option in the BA, and setting the Status field to 135
(FID already in use).
If the flow identification option does not include a flow description
sub-option, the home agent MUST again reject this request by copying
the flow identification option in the BA, and setting the Status
field to 129 (Flow identification option malformed).
If the flow identification option does include a flow description
sub-option, but the flow description type is not supported, the home
agent MUST also reject this request by copying the flow
identification option in the BA, and setting the Status field to 137
(FD-Type not supported).
If the FID value is new the home agent MUST check the Action field in 5.3.2.1. Handling new FIDs
combination with the Binding Reference sub-option if present.
- if the Action indicates 'Forward' If the FID field of the flow identification mobility option is not
already present in the list of flow binding entries for this mobile
node, then this is a request for a new entry.
If the Binding reference sub-option is not included or if it is If the flow identification mobility option does not include a traffic
included but it contains more than a single BID, the home agent selector sub-option, the home agent MUST reject this request by
MUST reject this flow binding add request by copying the flow copying the flow identification mobility option in the BA, and
identification option in the BA, and setting the Status field to setting the Status field to the value defined in Figure 2 for "Flow
129 (Flow identification option malformed). identification option malformed".
If the Binding Reference sub-option is present and includes a If the flow identification option does include a traffic selector
single BID, but the BID is not present in the binding cache of the sub-option, but the format indicated in the TS Format field is not
mobile node the home agent MUST reject this flow binding add supported, the home agent MUST reject this request by copying the
request by copying the flow identification option in the BA, and flow identification mobility option in the BA, and setting the Status
setting the Status field to TBD (BID not known). field to the value defined in Figure 2 for "Traffic Selector format
not supported".
If the Binding Reference sub-option is present and includes a Then the home agent MUST check the Action field in combination with
single BID, and the BID exists in the mobile node's binding cache, the Binding Reference sub-option if present.
the home agent SHOULD add a new entry in the mobile node's list of
flow binding entries, as defined below.
- if the Action indicates 'Discard', - if the Action indicates 'Discard',
Any Binding Reference sub-options that might be present SHOULD be Any binding reference sub-options that might be present SHOULD be
ignored. ignored.
The home agent SHOULD add a new entry in the mobile node's list of The home agent SHOULD add a new entry in the mobile node's list of
flow binding entries, as defined below. flow binding entries, as defined below.
- if the Action indicates 'n-cast', - if the Action indicates 'Forward",
If the Binding reference sub-option is not included, the home If the Binding reference sub-option is not included, the home
agent MUST reject this flow binding add request by copying the agent MUST reject this request by copying the flow identification
flow identification option in the BA, and setting the Status field mobility option in the BA, and setting the Status field to the
to 129 (Flow identification option malformed). value defined for "Flow identification mobility option malformed"
in Section 4.2.
If the Binding Reference sub-option is present and includes one or If the binding reference sub-option is present and includes one or
more BIDs that are not present in the binding cache of the mobile more BIDs that are not present in the binding cache of the mobile
node the home agent MUST reject this flow binding add request by node the home agent MUST reject this request by copying the flow
copying the flow identification option in the BA, and setting the identification option in the BA, and setting the Status field to
Status field to TBD (BID not known). the value defined for "BID not found" in Section 4.2.
If the Binding Reference sub-option is present and includes one or If the binding reference sub-option is present and includes one or
more BIDs, and the BIDs exist in the mobile node's binding cache, more BIDs, and the BIDs exist in the mobile node's binding cache,
the home agent SHOULD add a new entry in the mobile node's list of the home agent SHOULD add a new entry in the mobile node's list of
flow binding entries, as defined below. flow binding entries, as defined below.
When the home agent decides to add an entry in the mobile node's list When the home agent decides to add an entry in the mobile node's list
of flow binding entries, as discussed above, it MUST do it according of flow binding entries, as discussed above, it MUST do it according
to the following rules: The entry MUST be placed according to the to the following rules: The entry MUST be placed according to the
order indicated by the FID-PRI field of the flow identification order indicated by the FID-PRI field of the flow identification
option and it MUST include: mobility option and it MUST include:
the FID as a key to the entry the FID as a key to the entry
The flow description included in the corresponding sub-option The traffic selector included in the corresponding sub-option
the action indicated in the Action field the action indicated in the Action field
the BIDs indicated in the binding reference sub-option the BIDs, depending on action field, indicated in the binding
reference sub-option
the entry MUST be marked as Active, as shown in Section 4.4 the entry MUST be marked as Active, as shown in Section 4.3
5.3.2.2. Handling flow binding Modification Requests 5.3.2.2. Handling known FIDs
The flow binding modification is essentially a process where an If the FID field of the flow identification mobility option is
existing flow binding is removed from the list of flow binding already present in the list of flow binding entries for this mobile
entries and a new flow binding (included in the option) is added, and node, then this is a request to update the existing entry.
given the same FID as the flow that was removed.
If the value of the FID field of the flow identification option is The flow binding modification is essentially a process where
not present in the binding cache entries for this mobile node, the parameters associated with an existing flow binding entry are
home agent MUST reject this flow binding modify request by copying replaced by the parameters included in a flow identification mobility
the flow identification option in the BA, and setting the Status option with the same FID as the existing entry.
field to 135 (FID not found).
If the value of the FID field is present in the mobile nodes list of The home agent MUST:
flow binding entries, the home agent SHOULD first remove the flow
binding entry identified by the FID. The home agent SHOULD then
processes this flow identification option as defined in
Section 5.3.2.1.
5.3.3. Receiving BU with Flow Summary Option Change the priority of the entry according to the FID-PRI field of
the flow identification mobility option.
When the home agent receives a binding update which includes a Flow Change the action associated with the entry according to the
Summary option, it first performs the operation described in section Action field of the flow identification mobility option.
10.3.1 of RFC3775. Binding update messages including more than one
flow summary option MUST be rejected. A de-registration binding Since this flow identification mobility option is designed to update
update (with a zero lifetime) would result in deleting all bindings an existing entry it may not include a traffic selector sub-option.
regardless of the presence of the Flow summary option.
If a traffic selector sub-option is not included in the flow
identification mobility option, then the traffic selector already
associated with entry MUST be maintained,
otherwise the traffic selector in the entry MUST be replaced by
the traffic selector in the sub-option.
Like Section 5.3.2.1, if the Action field in the flow identification
mobility option is set to 'Discard' if a binding reference sub-option
is included in the option, it SHOULD be ignored; and any BIDs
associated with the existing flow binding entry SHOULD be removed.
Unlike Section 5.3.2.1, however, if the Action field in the flow
identification mobility option is set to 'Forward', and since this
flow identification mobility option is designed to update an existing
entry, it may not include a binding reference sub-option.
If a binding reference sub-option is not included in the flow
identification mobility option, then the BIDs already associated
with entry MUST be maintained,
otherwise the BIDs in the entry MUST be replaced by the BIDs in
the sub-option.
5.3.3. Handling Flow Summary Mobility Option
When the home agent receives a binding update which includes a flow
summary mobility option, it first performs the operation described in
section 10.3.1 of RFC3775. Binding update messages including more
than one flow summary mobility option MUST be rejected. A de-
registration binding update (with a zero lifetime) would result in
deleting all bindings, including all flow bindings regardless of the
presence of the flow summary mobility option.
If the value of any of the FID fields included in the flow summary If the value of any of the FID fields included in the flow summary
option is not present in the list of flow binding entries for this mobility option is not present in the list of flow binding entries
mobile node, the home agent MUST reject this flow binding refresh by for this mobile node, the home agent MUST reject this flow binding
including a flow identification option in the BA, and setting the FID refresh by including a flow identification mobility option in the BA
field in the value of the FID that is not found and the Status field for each FID that is not found, and by setting the FID field to the
to 135 (FID not found). value of the FID that is not found and the Status field to the value
defined for "FID not found" in Section 4.2.
If the value of the FID field is present in the mobile nodes list of If the value of the FID field is present in the mobile nodes list of
slow binding entries the, home agent SHOULD refresh the binding entry flow binding entries the, home agent SHOULD refresh the flow binding
identified by the FID without changing any of the other parameters entry identified by the FID without changing any of the other
associated with it. parameters associated with it.
5.3.4. Handling flow binding Removals 5.3.4. Flow Binding Removals
Removal of flow bindings is performed implicitly by omission of a Removal of flow bindings is performed implicitly by omission of a
given FID from a binding update. given FID from a binding update.
When a valid binding update is received, any registered FIDs that are When a valid binding update is received, any registered FIDs that are
not explicitly referred to in a flow identification option or in a not explicitly referred to in a flow identification mobility option
flow summary option, MUST be removed from the list of flow binding or in a flow summary mobility option, MUST be removed from the list
entries for the mobile node. of flow binding entries for the mobile node.
5.3.5. Sending Binding Acknowledgements 5.3.5. Sending Binding Acknowledgements
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 recommended in [RFC3775]. This status Acknowledgement must be set as recommended in [RFC3775]. This status
code does not give information on the success or failure of flow code does not give information on the success or failure of flow
bindings. bindings.
In order to inform the mobile node about the status of the flow In order to inform the mobile node about the status of the flow
binding(s) requested by a mobile node, flow identification options binding(s) requested by a mobile node, flow identification options
MUST be included in the Binding Acknowledgement message. SHOULD be included in the Binding Acknowledgement message.
Specifically, the home agent MUST copy each flow identification Specifically, the home agent SHOULD copy each flow identification
option received in the binding update and set its status code to an mobility option received in the binding update and set its status
appropriate value. If an operation requested in a flow code to an appropriate value. If an operation requested in a flow
identification option by a mobile node is performed successfully by identification option by a mobile node is performed successfully by
the home agent, the status field on the copied flow identification the home agent, the status field on the copied flow identification
option in the BA, SHOULD be set to 0 (Flow binding successful), mobility option in the BA, SHOULD be set to the value defined for
otherwise it SHOULD be set to one of the rejection codes defined. "Flow binding successful" in Section 4.2, otherwise it SHOULD be set
to one of the rejection codes also defined in Section 4.2.
Section 5.3.2 identifies a number of cases where specific error codes Section 5.3.2 identifies a number of cases where specific error codes
should be used. should be used.
Home agents that support this specification MAY refuse to maintain Home agents that support this specification MAY refuse to maintain
flow bindings by setting the status field of any flow identification flow bindings by setting the status field of any flow identification
options to 130 (Administratively prohibited), or by just ignoring all mobility options to the value defined for "Administratively
the flow binding options. prohibited" in Section 4.2, or by just ignoring all the flow binding
options.
Note that BID options and their Status field are handled as defined Note that BID options and their Status field are handled as defined
in [I-D.ietf-monami6-multiplecoa]. in [RFC5648].
5.3.6. Packet Processing 5.3.6. Packet Processing
This section defines packet processing rules according to this This section defines packet processing rules according to this
specification. This specification does not change any of the packet specification. This specification does not change any of the packet
interception rules defined in [RFC3775], and interception rules defined in [RFC3775], and [RFC5555]. These rules
[I-D.ietf-mext-nemo-v4traversal]. These rules apply to HAs, MAPs, apply to HAs, MAPs, and CNs, as part of the routing process for any
and CNs, as part of the routing process for any packet with packet with destination address set to a valid home address of the
destination address set to a valid home address of the mobile node. mobile node. For nodes other than CNs this also applies to packets
For nodes other than CNs this also applies to packets with with destination address set to an address under any of the
destination address set to an address under any of the registered registered prefixes. These rules apply equally to IPv6 packets as
prefixes. These rules apply equally to IPv6 packets as well as to well as to IPv4 packets as per [RFC5555].
IPv4 packets when [I-D.ietf-mext-nemo-v4traversal].
Before a packet is forwarded to the mobile node it MUST be matched Before a packet is forwarded to the mobile node it MUST be matched
against the ordered list of flow bindings stored in the list of flow against the ordered list of flow bindings stored in the list of flow
binding entries for this mobile node (see Section 4.4). A match is binding entries for this mobile node (see Section 4.3). A match is
attempted with the flow description included in the first line attempted with the traffic selector included in the first line
(highest order) of the table. If the packet matches the flow (highest order) of the table. If the packet matches the traffic
description, the action defined by the action parameter of the table selector, the action defined by the action parameter of the table
SHOULD be performed. SHOULD be performed.
- if the Action indicates 'Discard', the packet is silently - if the Action indicates 'Discard', the packet is silently
discarded discarded
- if the Action indicates 'n-cast', a copy of the packet is - if the Action indicates 'Forward", a copy of the packet is
forwarded to each of the care-of addresses associated with the forwarded to each of the care-of addresses associated with the
BIDs indicated in the same line of the table. BIDs indicated in the same line of the table.
If the action indicated in one of the entries in the list of flow If the action indicated in one of the entries in the list of flow
bindings is "Discard" then, no BIDs needs to be indicated in the same bindings is 'Discard' then, no BIDs need to be indicated in the same
entry since the packet is not forwarded. If, however, the action entry since the packet is not forwarded. If, however, the action
indicated in an entry of the list of flow bindings is "n-cast", the indicated in an entry of the list of flow bindings is 'Forward", the
entry must indicated a BID. For "n-cast" if any of the BIDs entry should indicate one or more valid BIDs. For 'Forward' if any
indicated does not correspond to a valid care-of address, e.g., the of the BIDs indicated does not correspond to a valid care-of address,
BID was deregistered then that BID has no effect on the traffic. In e.g., the BID was deregistered then that BID has no effect on the
other words, packets matching the flow binding are n-casted to the traffic. In other words, packets matching the flow binding are
other BIDs, pointing to registered care-of addresses. If none of the forwarded to the remaining BIDs, pointing to registered care-of
BIDs pointed to in a flow binding entry is valid then the entry is addresses. If none of the BIDs pointed to in a flow binding entry is
considered to be inactive (as defined in Section 4.4) and is skipped. valid then the entry is considered to be inactive (as defined in
In other words packets should not be matched against that entry. Section 4.3) and is skipped. In other words packets should not be
matched against that entry.
If a packet does not match any of the active flow binding entries for
the given MN, the packet SHOULD be forwarded to the care-of address
associated with the BID with the highest BID-PRI.
If a packet is fragmented, only the first fragment contains all IP
and transport layer headers, while subsequent fragments only contain
an IP header without transport layer headers. For this reason it is
possible that subsequent fragments do not match the same traffic
selector as the initial fragment of such a packet. Unless specific
measures are taken the likely outcome is that the initial fragment is
routed as the MN intended while subsequent fragments are routed
differently, and probably based on the default flow binding. HAs,
MAPs, and CNs SHOULD take care to forward all fragments of a given
packet the same way, and in accordance to the flow binding matching
the first fragment of said packet. This should be possible given the
fact that fragment headers include enough information to identify a
fragment as part of a specific packet, but the details of how this is
ensured are implementation specific and are not defined in this
specification.
6. Security considerations 6. Security considerations
This draft introduces a new option that adds more granularity to the This draft introduces a new option that adds more granularity to the
binding update message. The new option allows the mobile node to binding update message. The new option allows the mobile node to
associate some flows to one interface and other flows to another associate some flows to one interface and other flows to another
interface. Since the flow Identification option is part of the interface. Since the flow identification mobility option is part of
mobility header, it uses the same security as the Binding Update, the mobility header, it uses the same security as the Binding Update,
whether it is sent to the home agent, correspondent node, or MAP. whether it is sent to a mobility agent, or to a correspondent node.
7. IANA Considerations 7. IANA Considerations
A Type number (TBD) for Flow Identification Mobility Option and This specification requires the following IANA assignments on
another Type number (TBD) for Flow Summary Mobility Option has been existing namespaces as well as the creation of some new namespaces.
registered from the space of numbers for mobility options, defined
for Mobile IPv6 [RFC3775]. This registry is available from
http://www.iana.org under "Mobile IPv6 parameters".
A new sub-type space for the type number of the Flow Identification 1) New Mobility Options [RFC3775]: This registry is available from
Mobility Option has been created: "Flow Identification Mobility http://www.iana.org under "Mobile IPv6 parameters". The following
Option Sub-Options". The suboption values 1, and 2, are defined in type numbers need to be assigned for:
this specification, and the values 16-32 are reserved for flow
description sub-options to defined in separate documents. The rest
of the sub-options are reserved and available for allocation based on
Expert Review.
Finally, a new space for the status field of the Flow Identification Flow Identification Mobility Option, define in Section 4.2
Mobility Option has been created: "Flow Identification Mobility
Option Status codes". Values 0, 128-130 and 135-139 are defined in Flow Summary Mobility Option, defined in Section 4.2.2
this specification. The rest of the values below 128 are reserved
for accept codes, and values from 128 and above are reserved for 2) New "Flow Identification Mobility Option Action codes"
reject codes. namespace needs to be created. The following 'Action' codes are
defined in this specification, in Section 4.2:
0 Reserved
1 Discard
2 Forward
3-255 reserved and available for allocation based on Expert
Review
3) New "Flow Identification Mobility Option Status codes"
namespace needs to be created. The following 'Status' codes are
defined in this specification, in Section 4.2:
0-127 reserved for success codes
128-255 reserved for reject codes
a number of specific codes have been defined in Section 4.2
4) New "Flow Identification Sub-Options" namespace for the Flow
Identification Mobility Option. The sub-option space is defined
in Figure 3. The following Sub-option Type values are defined in
this specification:
0 Pad
1 PadN
2 BID Reference
3 Traffic Selector
4-255 reserved and available for allocation based on Expert
Review
5) New "Traffic Selector Format" namespace for the Traffic
Selector sub-option. The traffic selector format space is defined
by the TS Format field in Figure 5. The following values are
defined in this specification:
0 Reserved
1-255 reserved and available for allocation based on Expert
Review
Similar to the procedures specified for Mobile IPv6 [RFC3775] number Similar to the procedures specified for Mobile IPv6 [RFC3775] number
spaces, future allocations from the two number spaces require Expert spaces, future allocations from the new number spaces requires Expert
Review [RFC5226]. Review as defined i [RFC5226].
8. Contributors 8. Contributors
We would like to explicitly acknowledge the following person who co- We would like to explicitly acknowledge the following person who co-
authored one of the documents used as source material for this authored one of the documents used as source material for this
document. document.
Nikolaus A. Fikouras, niko@comnets.uni-bremen.de Nikolaus A. Fikouras, niko@comnets.uni-bremen.de
9. Acknowledgements 9. Acknowledgements
We would also like to acknowledge the following people in We would also like to acknowledge the following people in
alphabetical order: C. Castelluccia, K. ElMalki, K. Georgios, , C. alphabetical order for their contributions to this specification: C.
Goerg, C. Kaas-Petersen, T. Noel, F.-N. Pavlidou, V. Park. Gabor Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas-
Fekete for the analysis that led to the inclusion of the BIDRef sub- Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar.
option. Henrik Levkowetz for suggesting support for other ways of Also, Gabor Fekete for the analysis that led to the inclusion of the
describing flows. BIDRef sub-option, and Henrik Levkowetz for suggesting support for
other ways of describing flows.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-mext-nemo-v4traversal]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-10 (work in
progress), April 2009.
[I-D.ietf-monami6-multiplecoa]
Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-13 (work in progress),
April 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Routers", RFC 5555, June 2009.
Management", RFC 5380, October 2008.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
10.2. Informative References 10.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3753] 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.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
Authors' Addresses Authors' Addresses
Hesham Soliman Hesham Soliman
Elevate Technologies Elevate Technologies
Email: hesham@elevatemobile.com Email: hesham@elevatemobile.com
George George Tsirtsis
Qualcomm Qualcomm
Email: tsirtsis@gmail.com Email: tsirtsis@gmail.com
Nicolas Montavont Nicolas Montavont
Institut Telecom / Telecom Bretagne Institut Telecom / Telecom 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@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~nmontavo// URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
Gerardo Gerardo Giaretta
Qualcomm Qualcomm
Email: gerardog@qualcomm.com Email: gerardog@qualcomm.com
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
 End of changes. 195 change blocks. 
551 lines changed or deleted 788 lines changed or added

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