draft-ietf-mext-flow-binding-04.txt   draft-ietf-mext-flow-binding-05.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: May 13, 2010 Qualcomm Expires: August 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
November 9, 2009 February 9, 2010
Flow Bindings in Mobile IPv6 and NEMO Basic Support Flow Bindings in Mobile IPv6 and NEMO Basic Support
draft-ietf-mext-flow-binding-04.txt draft-ietf-mext-flow-binding-05.txt
Abstract Abstract
This document introduces extensions to Mobile IPv6 that allow nodes This document introduces extensions to Mobile IPv6 that allow nodes
to bind one or more flows to a care-of address. These extensions to bind one or more flows to a care-of address. These extensions
allow multihomed nodes to instruct home agents and other Mobile IPv6 allow multihomed nodes to instruct home agents and other Mobile IPv6
entities to direct inbound flows to specific addresses. entities to direct inbound flows to specific addresses.
Status of this Memo Status of this Memo
skipping to change at page 1, line 46 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 May 13, 2010. This Internet-Draft will expire on August 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 35 skipping to change at page 3, line 35
5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 22 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 22
5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 23 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 23
5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 23 5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 23
5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 23 5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 23
5.2.7. Return Routability Procedure . . . . . . . . . . . . . 24 5.2.7. Return Routability Procedure . . . . . . . . . . . . . 24
5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24
5.3.1. Handling Binding Identifier Mobility Options . . . . . 24 5.3.1. Handling Binding Identifier Mobility Options . . . . . 24
5.3.2. Handling Flow Identification Mobility Options . . . . 25 5.3.2. Handling Flow Identification Mobility Options . . . . 25
5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 28 5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 28
5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 28 5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 28
5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 29 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 28
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29
6. Security considerations . . . . . . . . . . . . . . . . . . . 31 6. Security considerations . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
skipping to change at page 7, line 10 skipping to change at page 7, line 10
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] and [RFC5648], designate either a mobile node as defined in [RFC3775] and [RFC5648],
or a mobile 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 as a set of data packets that are exchanged Flow: A flow is a sequence of packets for which the MN desires
between two nodes. In the context of this specification the term special handling either by the HA, the CN or the MAP.
"flow" is some times used to refer to a plurality of flows as well
as a single flow.
Traffic Selector: Information that identifies one or more flows. Traffic Selector: One or more parameters that can be matched
against fields in the packet's headers for the purpose of
classifying a packet. Examples of such parameters include the
source and destination IP addresses, transport protocol number,
the source and destination port numbers and other fields in IP and
higher layer headers.
Flow binding: It consists of a traffic selector, and an action. Flow binding: It consists of a traffic selector, and an action.
IP packets from one or more flows that match the traffic selector IP packets from one or more flows that match the traffic selector
associated with the flow binding, are processed according to the associated with the flow binding, are processed according to the
action associated with the same flow binding. action associated with the same flow binding.
Flow Identifier: A flow identifier uniquely identifies a flow Flow Identifier: A flow identifier uniquely identifies a flow
binding associated with a mobile node. It is generated by a binding associated with a mobile node. It is generated by a
mobile node and is cached in the table of flow binding entries mobile node and is cached in the table of flow binding entries
maintained by the MN, HA, CN or MAP. maintained by the MN, HA, CN or MAP.
skipping to change at page 16, line 25 skipping to change at page 16, line 25
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 bindings. 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 includes the following parameters : BID. Each flow binding entry includes the following parameters :
o FID (Flow Identifier): For a given mobile node, identified by its o FID (Flow Identifier): For a given mobile node, identified by its
home address, the FID MUST uniquely identify an entry, i.e. a primary home address, the FID MUST uniquely identify an entry,
unique flow binding. Each mobile node can only have a single i.e. a unique flow binding. Each mobile node can only have a
entry identified by a given FID at any one time. Different mobile single entry identified by a given FID at any one time. A given
nodes can use the same FID number space. FID number space is used for all the addresses associated to a
given MN by the HA (e.g., via [RFC3963]). Different mobile nodes
use the same FID number space.
o A Traffic Selector: Included in a traffic selector sub-option. o A Traffic Selector: Included in a traffic selector sub-option.
o BID(s): The list of BIDs associated with the entry as defined by o BID(s): The list of BIDs associated with the entry as defined by
the binding reference sub-option included in the FID option that the binding reference sub-option included in the FID option that
created it. created it.
o Action: The action associated with a given entry as defined by the o Action: The action associated with a given entry as defined by the
Action field of the FID option that created it Action field of the FID option that created it
skipping to change at page 24, line 20 skipping to change at page 24, line 20
the status of the flow binding on the distant node. the status of the flow binding on the distant node.
5.2.7. 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 document.
This procedure is not affected by the extensions defined in this
document. However, since a binding update message is secured with
the key generated based on the home address and care-of address test,
a mobile node MUST NOT bind a flow to a care-of address whose keygen
token (see RFC3775 [RFC3775]) was not used to generate the key for
securing the Binding Update. This limitation prohibits the sender
from requesting the 'Forward' action for multiple addresses before
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 mobility agents (Home Agents and This specification allows the mobility agents (Home Agents and
Mobility Anchor Points), and correspondent nodes to maintain several Mobility Anchor Points), and correspondent nodes to maintain several
flow bindings for a given home address and to direct packets to flow bindings for a given home address and to direct packets to
different care-of addresses according to flow bindings. This section different care-of addresses according to flow bindings. This section
details the home agent operations necessary to implement this details the home agent operations necessary to implement this
specification. These operations are identical for MAPs and CNs specification. These operations are identical for MAPs and CNs
unless otherwise stated. unless otherwise stated.
skipping to change at page 32, line 28 skipping to change at page 32, line 28
2) New "Flow Identification Mobility Option Action codes" 2) New "Flow Identification Mobility Option Action codes"
namespace needs to be created. The following 'Action' codes are namespace needs to be created. The following 'Action' codes are
defined in this specification, in Section 4.2: defined in this specification, in Section 4.2:
0 Reserved 0 Reserved
1 Discard 1 Discard
2 Forward 2 Forward
3-255 reserved and available for allocation based on Expert 3-250 unassigned and available for allocation based on STD
Review action
251-255 reserved for experimental use
3) New "Flow Identification Mobility Option Status codes" 3) New "Flow Identification Mobility Option Status codes"
namespace needs to be created. The following 'Status' codes are namespace needs to be created. The following 'Status' codes are
defined in this specification, in Section 4.2: defined in this specification, in Section 4.2:
0-127 reserved for success codes 0 Flow binding successful
128-255 reserved for reject codes 1-127 unassigned and available for success codes to be
allocated via STD action
a number of specific codes have been defined in Section 4.2 128 Administratively prohibited
129 Flow binding rejected, reason unspecified
130 Flow identification mobility option malformed
131 BID not found
132 FID not found
133 Traffic selector format not supported
134 Discard function not supported
135 Forward function not supported
126-250 unassigned and available for reject codes to be
allocated via STD action
251-255 reserved for experimental use
4) New "Flow Identification Sub-Options" namespace for the Flow 4) New "Flow Identification Sub-Options" namespace for the Flow
Identification Mobility Option. The sub-option space is defined Identification Mobility Option. The sub-option space is defined
in Figure 3. The following Sub-option Type values are defined in in Figure 3. The following Sub-option Type values are defined in
this specification: this specification:
0 Pad 0 Pad
1 PadN 1 PadN
skipping to change at page 33, line 4 skipping to change at page 33, line 25
4) New "Flow Identification Sub-Options" namespace for the Flow 4) New "Flow Identification Sub-Options" namespace for the Flow
Identification Mobility Option. The sub-option space is defined Identification Mobility Option. The sub-option space is defined
in Figure 3. The following Sub-option Type values are defined in in Figure 3. The following Sub-option Type values are defined in
this specification: this specification:
0 Pad 0 Pad
1 PadN 1 PadN
2 BID Reference 2 BID Reference
3 Traffic Selector 3 Traffic Selector
4-255 reserved and available for allocation based on Expert 4-250 unassigned and available for allocation based on STD
Review action
251-255 reserved for experimental use
5) New "Traffic Selector Format" namespace for the Traffic 5) New "Traffic Selector Format" namespace for the Traffic
Selector sub-option. The traffic selector format space is defined Selector sub-option. The traffic selector format space is defined
by the TS Format field in Figure 5. The following values are by the TS Format field in Figure 5. The following values are
defined in this specification: defined in this specification:
0 Reserved 0 Reserved
1-255 reserved and available for allocation based on Expert 1-250 unassigned and available for allocation based on STD
Review action
251-255 reserved for experimental use
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 new number spaces requires Expert spaces, future allocations from the new number spaces requires Expert
Review as defined i [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.
 End of changes. 17 change blocks. 
34 lines changed or deleted 57 lines changed or added

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