draft-ietf-mext-flow-binding-05.txt   draft-ietf-mext-flow-binding-06.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: August 13, 2010 Qualcomm Expires: September 2, 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
February 9, 2010 March 1, 2010
Flow Bindings in Mobile IPv6 and NEMO Basic Support Flow Bindings in Mobile IPv6 and NEMO Basic Support
draft-ietf-mext-flow-binding-05.txt draft-ietf-mext-flow-binding-06.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 August 13, 2010. This Internet-Draft will expire on September 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 3, line 37 skipping to change at page 3, line 37
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 . . . . . . . . . . . 28 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 28
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29
6. Security considerations . . . . . . . . . . . . . . . . . . . 31 6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. Security considerations . . . . . . . . . . . . . . . . . . . 32
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 11.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
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 [RFC5555] and NEMO Basic Support Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support
skipping to change at page 20, line 32 skipping to change at page 20, line 32
update. 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 mobility option, originally defined in [RFC5648]. binding identifier mobility option, originally defined in [RFC5648].
According to this specification the BID option includes a BID-PRI According to this specification the BID option includes a BID-PRI
field assigning each registered care-of address a priority, and thus field assigning each registered care-of address a priority, and thus
placing them in an ordered list as also described in Section 4.3. placing them in an ordered list as also described in Section 4.3.
To ensure backwards compatibility with [RFC5648] for the purpose of
this specification the field BID-PRI SHOULD NOT be set to zero.
Receiver implementation of this specification will take a BID-PRI
field of value zero as an indication that this is a BID option of the
format defined in [RFC5648].
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. Mobile 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 mobility options using them, or in same BU as any flow identification mobility options using them, or in
earlier BUs. earlier BUs.
5.2.2. Sending BU with Flow Identification Mobility Options 5.2.2. Sending BU with Flow Identification Mobility Options
5.2.2.1. New Flow Bindings 5.2.2.1. New Flow Bindings
skipping to change at page 28, line 39 skipping to change at page 28, line 43
entry identified by the FID without changing any of the other entry identified by the FID without changing any of the other
parameters associated with it. parameters associated with it.
5.3.4. 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 mobility option not explicitly referred to in a flow identification mobility option
or in a flow summary mobility option, MUST be removed from the list or in a flow summary mobility option, in the same binding update,
of flow binding entries for the mobile node. MUST be removed from the list 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
skipping to change at page 31, line 5 skipping to change at page 31, line 5
routed as the MN intended while subsequent fragments are routed routed as the MN intended while subsequent fragments are routed
differently, and probably based on the default flow binding. HAs, differently, and probably based on the default flow binding. HAs,
MAPs, and CNs SHOULD take care to forward all fragments of a given 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 packet the same way, and in accordance to the flow binding matching
the first fragment of said packet. This should be possible given the the first fragment of said packet. This should be possible given the
fact that fragment headers include enough information to identify a fact that fragment headers include enough information to identify a
fragment as part of a specific packet, but the details of how this is fragment as part of a specific packet, but the details of how this is
ensured are implementation specific and are not defined in this ensured are implementation specific and are not defined in this
specification. specification.
6. Security considerations 6. MTU Considerations
The options and sub-options defined in this specification add to
those defined in [RFC3775] and other related specifications, all of
which potentially adds to the size of binding update messages.
Implementations SHOULD take care to minimize fragmentation by forming
binding updates that are shorter than what the path MTU allows
whenever possible.
This specification offers a number of mechanisms for reducing the
size of binding updates. The operations defined in this
specification that require the most verbose options are those
registering new BIDs Section 4.1 and identifying new flows
Section 4.2.1.4. Implementations are encouradged to keep binding
updates to sizes below than that of the path's MTU by making full use
of BID Reference Section 4.2.1.3 and FID Summary Section 4.2.2 sub-
options, which allows them to refer to already registered care-off
addresses and flows, while registering new ones in subsequent binding
update messages.
7. 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 mobility option is part of interface. Since the flow identification mobility option is part of
the 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 a mobility agent, or to a correspondent node. whether it is sent to a mobility agent, or to a correspondent node.
7. IANA Considerations 8. IANA Considerations
This specification requires the following IANA assignments on This specification requires the following IANA assignments on
existing namespaces as well as the creation of some new namespaces. existing namespaces as well as the creation of some new namespaces.
1) New Mobility Options [RFC3775]: This registry is available from 1) New Mobility Options [RFC3775]: This registry is available from
http://www.iana.org under "Mobile IPv6 parameters". The following http://www.iana.org under "Mobile IPv6 parameters". The following
type numbers need to be assigned for: type numbers need to be assigned for:
Flow Identification Mobility Option, define in Section 4.2 Flow Identification Mobility Option, define in Section 4.2
skipping to change at page 32, line 28 skipping to change at page 33, 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-250 unassigned and available for allocation based on STD 3-254 unassigned and available for allocation based on
action Standards Action or IESG Approval as per [RFC5226]
251-255 reserved for experimental use 255 reserved for experimental use. A single value should be
sufficient for experimenting with a different flow
identifiction format.
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 Flow binding successful 0 Flow binding successful
1-127 unassigned and available for success codes to be 1-127 unassigned and available for success codes to be
allocated via STD action allocated via STD action
skipping to change at page 32, line 49 skipping to change at page 34, line 4
1-127 unassigned and available for success codes to be 1-127 unassigned and available for success codes to be
allocated via STD action allocated via STD action
128 Administratively prohibited 128 Administratively prohibited
129 Flow binding rejected, reason unspecified 129 Flow binding rejected, reason unspecified
130 Flow identification mobility option malformed 130 Flow identification mobility option malformed
131 BID not found 131 BID not found
132 FID not found 132 FID not found
133 Traffic selector format not supported 133 Traffic selector format not supported
134 Discard function not supported 134 Discard function not supported
135 Forward function not supported 135 Forward function not supported
126-250 unassigned and available for reject codes to be 126-250 unassigned and available for reject codes to be
allocated via STD action allocated via Standards Action or IESG Approval as per
[RFC5226]
251-255 reserved for experimental use 251-255 reserved for experimental use. This small number of
status codes should be sufficient for experiments with
currently unforeseen error conditions.
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-250 unassigned and available for allocation based on STD 4-250 unassigned and available for allocation based on
action Standards Action or IESG Approval as per [RFC5226]
251-255 reserved for experimental use 251-255 reserved for experimental use. This small number of
sub-option types should be sufficient for experiments with
additional parameters associated with a flow.
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-250 unassigned and available for allocation based on STD 1-250 unassigned and available for allocation based on
action Standards Action or IESG Approval as per [RFC5226]
251-255 reserved for experimental use 251-255 reserved for experimental use. This small number of
traffic selector format types should be sufficient for
experiments with different ways of representing a traffic
selector.
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
Review as defined i [RFC5226]. Standards Action or IESG Approval as per [RFC5226]
8. Contributors 9. 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 10. Acknowledgements
We would also like to acknowledge the following people in We would also like to acknowledge the following people in
alphabetical order for their contributions to this specification: C. alphabetical order for their contributions to this specification: C.
Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas- Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas-
Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar. Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar.
Also, Gabor Fekete for the analysis that led to the inclusion of the Also, Gabor Fekete for the analysis that led to the inclusion of the
BIDRef sub-option, and Henrik Levkowetz for suggesting support for BIDRef sub-option, and Henrik Levkowetz for suggesting support for
other ways of describing flows. other ways of describing flows.
10. References 11. References
10.1. Normative References 11.1. Normative References
[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.
skipping to change at page 36, line 30 skipping to change at page 38, line 30
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration", and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009. RFC 5648, October 2009.
10.2. Informative References 11.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.
skipping to change at page 37, line 15 skipping to change at page 39, line 15
Authors' Addresses Authors' Addresses
Hesham Soliman Hesham Soliman
Elevate Technologies Elevate Technologies
Email: hesham@elevatemobile.com Email: hesham@elevatemobile.com
George Tsirtsis George Tsirtsis
Qualcomm Qualcomm
Email: tsirtsis@gmail.com Email: tsirtsis@qualcomm.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//
 End of changes. 26 change blocks. 
36 lines changed or deleted 74 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/