IETF MEXT Working Group H. Soliman Internet-Draft Elevate Technologies Intended status: Standards Track G. Tsirtsis Expires: October 30, 2009 Qualcomm N. Montavont IT/TB G. Giaretta Qualcomm K. Kuladinithi University of Bremen April 28, 2009 Flow Bindings in Mobile IPv6 and Nemo Basic Support draft-ietf-mext-flow-binding-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 30, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights Soliman, et al. Expires October 30, 2009 [Page 1] Internet-Draft Flow binding April 2009 and restrictions with respect to this document. Soliman, et al. Expires October 30, 2009 [Page 2] Internet-Draft Flow binding April 2009 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 their peers to direct downlink flows to specific addresses. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 4.1. Definition Update for Binding Identifier Mobility Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 4.2.1. Binding Reference Sub-option . . . . . . . . . . . . . 11 4.2.2. Flow Description Sub-option . . . . . . . . . . . . . 12 4.3. Flow Identification Summary Mobility Option . . . . . . . 13 4.4. Flow Bindings entries list and its relationship to Binding Cache . . . . . . . . . . . . . . . . . . . . . . 14 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 17 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 17 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 17 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 18 5.2.2. Sending BU with Flow Identification Options . . . . . 18 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 20 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 21 5.2.5. Receiving Binding Acknowledgements . . . . . . . . . . 21 5.2.6. Return Routability Procedure . . . . . . . . . . . . . 21 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 22 5.3.1. Receiving BU with BID Options . . . . . . . . . . . . 22 5.3.2. Receiving BU with Flow Identification Options . . . . 23 5.3.3. Receiving BU with Flow Summary Option . . . . . . . . 25 5.3.4. Handling flow binding Removals . . . . . . . . . . . . 26 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 26 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 27 6. Security considerations . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Soliman, et al. Expires October 30, 2009 [Page 3] Internet-Draft Flow binding April 2009 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Soliman, et al. Expires October 30, 2009 [Page 4] Internet-Draft Flow binding April 2009 2. Introduction Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and Nemo Basic Support [RFC3963] allow a mobile node / mobile router to manage its mobility using the binding update message, which binds one care-of address to one home address. The binding update message can be sent to the home agent. In Mobile IPv6, the binding update can also be sent to correspondent node or to a mobility anchor point (see [RFC5380]). The semantics of the binding update are limited to care-of address changes. That is, [RFC3775], [I-D.ietf-mext-nemo-v4traversal], and [RFC3963] do not allow a mobile node / mobile router to bind more than one address to the home address. In [I-D.ietf-monami6-multiplecoa] Mobile IPv6 and Nemo Basic Support are extended to allow the binding of more than one care-of address to a home address. This specification further extends Mobile IPv6, DSMIPv6, and Nemo Basic Support to allow it to specify policies associated with each binding. A policy can contain a request for a special treatment of a particular IPv4 or IPv6 flow, which is viewed as a group of packets matching a flow descriptor. Hence, this specification allows a mobile node / mobile router to bind a particular flow to a care-of address without affecting other flows using the same home address. In addition, this specification allows to bind a particular flow to a particular care-of address directly with correspondent node and mobility anchor point. 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 destination IP addresses, transport protocol number, the source and destination port numbers and other fields in IP and higher layer headers. This specification, however, does not define flow descriptors and it is assumed that one or more ways of defining flow descriptors are going to be defined in other specifications. This specification, however, does define the sub-option extension format to be used for any defined flows descriptors. Using the flow identifier option introduced in this specification a mobile node / mobile router can bind one or more flows to a care-of address while maintaining the reception of other flows on another care-of address. Requesting the flow binding can be decided based on local policies within the mobile node / mobile router and based on the link characteristics and the types of applications running at the time. Such policies are outside the scope of this document. It should be noted that the flow identification option can be associated with any binding update, whether it is sent to a home agent, correspondent node (in the case of Mobile IPv6), or mobility anchor point (in the case of Hierarchical Mobile IPv6). Soliman, et al. Expires October 30, 2009 [Page 5] Internet-Draft Flow binding April 2009 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 router as defined in [RFC3963] unless stated otherwise. Soliman, et al. Expires October 30, 2009 [Page 6] Internet-Draft Flow binding April 2009 3. Terminology Terms used in this document are defined in [RFC3753] and [RFC4885]. The following terms are also used in this document: Flow: A flow is identified as a set of data packets that are exchanged between two nodes and match a given flow description Flow Description: A set of instructions that describes a flow. Flow Identifier: Identifier of a flow binding. Flow binding: An entry in the list of flow binding associated with a given mobile node. Soliman, et al. Expires October 30, 2009 [Page 7] Internet-Draft Flow binding April 2009 4. Mobile IPv6 Extensions This section introduces extensions to Mobile IPv6 that are necessary for supporting the flow binding mechanism described in this document. 4.1. Definition Update for Binding Identifier Mobility Option This specification updates the definition of the Binding Identifier Mobility option defined in [I-D.ietf-monami6-multiplecoa], as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding ID (BID) | Status |H| BID-PRI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ + + : IPv4 or IPv6 care-of address (CoA) : + + +---------------------------------------------------------------+ Figure 1: The Binding Identifier Mobility option BID-PRI This is a 7-bit field placing each BID to a relative priority with other registered BIDs. Value "0" is reserved for implementation of [I-D.ietf-monami6-multiplecoa] that do not support this specification. A higher number in this field indicates lower priority, while BIDs with the same BID-PRI value have equal priority. 4.2. Flow Identification Mobility Option The Flow identification mobility option is included in the binding update and acknowledgement messages. This option contains information that allows the receiver of a binding update to install policies on a traffic flow and route it to a given care-of address. Multiple options may exist within the same binding update message. Soliman, et al. Expires October 30, 2009 [Page 8] Internet-Draft Flow binding April 2009 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID-PRI | Action | Rsvd | PRO | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The flow identification mobility option Option Type TBD Option Len Length of option, including any sub-options, in 8-octet units FID The Flow Identifier field is an 8-bit unsigned integer that includes the identifier for the flow binding. This field is used to refer to an existing binding or to create a new binding. The value of this field is set by the mobile node. FID-PRI This is an 8-bit priority field to indicate the priority of a particular option. This field is needed in cases where two different flow descriptions in two different options overlap. The priority field decides which policy should be in those cases. A lower number in this field indicates a higher priority. Action This field specifies the action that needs to be taken by the receiver of the binding update containing the flow identification option. The details of these requests are discussed below. Rsvd This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Soliman, et al. Expires October 30, 2009 [Page 9] Internet-Draft Flow binding April 2009 PRO This is a 4-bit field that describes the required processing for the option. This field may indicate a request for adding, deleting, modifying or refreshing the option. The details of these requests are discussed below. Status This field indicates the success or failure of the flow binding operation for the particular flow in the option. This field is not relevant to the binding update message as a whole or to other flow identification options. Values from 0 to 127 indicate success. Values of 128 and higher indicate failure. This field is only relevant when included in the Binding Acknowledgement message and must be ignored in the binding update message. The following values are reserved for the PRO field in this option: 0 Add a flow binding 1 Modify a flow binding The following values are reserved for the Action field in this option: 1 Forward. This value indicates a request to forward a flow to the address indicated in the Binding Reference sub-option. A single BID MUST be associated with this Action. 2 Discard. This value indicates a request to discard all packets in the flow described by the option. No BIDs are associated with this Action. 3 n-cast. This value indicates a request to replicate the flow to several addresses indicated in the Binding Reference sub-option. One or more BIDs MUST be associated with this Action. The following values are reserved for the status field within the flow identification option: 0 Flow binding successful. 128 Flow binding rejected, reason unspecified. 129 Flow identification option poorly formed. Soliman, et al. Expires October 30, 2009 [Page 10] Internet-Draft Flow binding April 2009 130 Administratively prohibited. 135 FID already in use 136 FID not found 137 FD-Type not supported. 138 Discard function not supported. 139 N-cast function not supported. It should be noted that per-packet load balancing may have negative impacts on TCP congestion avoidance mechanisms as it is desirable to maintain order between packets belonging to the same TCP connection. This behaviour is specified in RFC2702 [RFC2702]. Other negative impacts are also foreseen for other types of real time connections due to the potential variations in RTT between packets. Hence per- packet load balancing is not currently supported in this extension. A number of sub-options can follow the option defined in this section. These are defined below. 4.2.1. Binding Reference Sub-option This section introduces the Binding Reference sub-option, which may be included in the Flow identification option. The Binding Reference sub-option includes one or more BIDs defined in MCoA [I-D.ietf-monami6-multiplecoa]. When this sub-option is included in the Flow identification option it associates the flow described with one or more registered BIDs. The binding identifier option, defined in [I-D.ietf-monami6-multiplecoa], registering a given BID which is then indicated in the Binding Reference sub-option, MUST be either defined in the same or earlier BU from the one including the binding reference sub-option. The Binding Reference sub-option is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-opt Type | Sub-Opt Len | BID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BID ........ +-+-+-+-+-+-+-+-+-+- Figure 3: The Binding Reference sub-option Soliman, et al. Expires October 30, 2009 [Page 11] Internet-Draft Flow binding April 2009 Sub-opt Type Indicates the Sub-option type. For the Binding Reference sub- option, this field MUST be set to 1. Sub-opt Len Indicates the sub-option length in octets. This field includes the entire length of the sub-option including the Sub-opt Type and Sub-opt-Len fields. BID The BID that the mobile node wants to associate with the flow identification option. One or more BID fields can be included in this sub-option. Since each BID is 2 byte long, the value of the Sub-opt Len field indicates the number of BIDs present. Number of BIDs = (Sub-opt Len-2)/2. 4.2.2. Flow Description Sub-option The Flow description sub-option(s) include the parameters used to match packets for a specific flow binding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-opt Type | Sub-Opt Len | Flow Description ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The Flow Description sub-option Sub-opt Type Indicates the Sub-option type. For the flow description sub- option, this field SHOULD be set to one of the FD types defined below. Sub-opt Len Indicates the sub-option length in octets. This field includes the entire length of the sub-option including the Sub-opt Type and Sub-opt-Len fields. Soliman, et al. Expires October 30, 2009 [Page 12] Internet-Draft Flow binding April 2009 Flow Description The flow description corresponding to the type indicated by the Sub-opt Type field. Flow description is out of scope of this document. The following values are reserved for the sub-option Type values are defined for Flow Description: 17-32 reserved for Flow Description formats. 4.3. Flow Identification Summary Mobility Option TBD 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID ........ +-+-+-+-+-+-+-+-+-+- Figure 5: The Flow Identification Summary Option Option Type Indicates the Sub-option type. For the Binding Reference sub- option, this field MUST be set to 1. Option Length Indicates the sub-option length in octets. This field includes the entire length of the sub-option including the Sub-opt Type and Sub-opt-Len fields. FID A registered FID. One or more FID fields can be included in this option. Since each FID is 2 bytes long, the value of the Option Len field indicates the number of FIDs present. Number of FIDs = (Sub-opt Len-2)/2. Soliman, et al. Expires October 30, 2009 [Page 13] Internet-Draft Flow binding April 2009 4.4. Flow Bindings entries list and its relationship to Binding Cache The conceptual mobile IPv6 binding cache was defined in [RFC3775] to identify the mobile IP state maintained by the mobile node, home agent, and corresponding node. The binding cache includes, between others, the mobile node's home address, the registered care-of address, and the lifetime of the binding. The binding cache was then extended by [I-D.ietf-monami6-multiplecoa] to include more than one care-of addresses and to associate each of them with a Binding Identifier (BID). This specification does not change modify the mobile IPv6 binding cache any further. Flow bindings can be thought of as a conceptual list of entries that is separate from the binding cache. The flow bindings list contains an entry for each of the registered flow binding. Flow binding entries can point to an entry in the binding cache by means of the BID. Each flow binding entry include the following parameters : * FID (Flow Identifier): For a given mobile node, identified by its primary home address, the FID MUST uniquely identify an entry, i.e. a unique flow binding. Each mobile node can only have a single entry identified by a given FID at any one time. Different mobile nodes can use the same FID number space. * A Flow Descriptor: Included in a Flow Description sub-option. * BID(s): The list of BIDs associated with the entry as defined by the Binding Reference sub-option included in the FID option that created it. * Action: The action associated with a given entry as defined by the PRO field of the FID option that created it * Active/Inactive flag: This flag indicates whether the entry is active or inactive. The flow bindings list is associated with a given mobile node, and the corresponding binding cache. An entry in the flow bindings list, 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 entry. The BIDs included in a given entry point to a corresponding entry in the binding cache for the purpose of identifying a care-of address. Soliman, et al. Expires October 30, 2009 [Page 14] Internet-Draft Flow binding April 2009 Depending on the Action parameter in a given entry a valid BID is required to make the entry "active". If all of the BIDs pointed to by a given entry are not valid BIDs in the binding cache, the flow binding entry becomes "inactive", in other words it does not affect data traffic. Note that if the action parameter in an entry indicates "n-cast" then the entry becomes inactive only if none of the BIDs is valid. If only some of the BIDs are valid, the invalid BIDs are simply ignored. Also note that the state described in this section is maintained by the mobile node as well as in mobility agents and corresponding 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. Section 5 defines how these flow binding entries are manipulated by the mobile node in detail. As an example the following represents an ordered flow bindings entries table for a mobile node that has registered three care-of addresses and three flow bindings. FID-PRI FID Flow Description BIDs Action A/I ------- --- ---------------- ---- ------- ------ 10 4 TCP 2 Forward Active 20 3 srcAddr=IPx N/A Discard Active 30 2 srcAddr=IPy 4 Forward Inactive 40 5 UDP 1,3 N-Cast Active Ordered Flow Binding Entries 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 be forwarded to BID2, corresponding to a given care-of address (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 associated Action it will be discarded. Note that any TCP traffic with source address IPx will match the first entry and thus it will be forwarded as per that entry. 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 affect traffic, i.e., packets are not matched against them. 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 replicated and forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and IP2 shown below. Soliman, et al. Expires October 30, 2009 [Page 15] Internet-Draft Flow binding April 2009 Finally any remaining packets that do not match any of the entries above will be simply forwarded to the care-of address indicated by the highest order BID in the table below. In the example, such packets will be forwarded to BID 1, corresponding to care-of address IP1. BID-PRI BID CoA --------- --- --- 20 1 IP1 30 3 IP2 30 2 IP3 Ordered BID Entries Soliman, et al. Expires October 30, 2009 [Page 16] Internet-Draft Flow binding April 2009 5. Protocol operations 5.1. General This specification introduces a flow bindings list of entries and an ordered list of binding identifiers, allowing mobile nodes to associate flow binding policies with the registered care-of addresses. The flow identification option defines how the mobile node can control a set of flow binding entries maintained in a home agent, correspondent node, or mobility anchor points, on its behalf. The fields of the flow identification option are necessary for ordering flow identification options, indicating the sort of action that should be undertaken to the recipient's flow binding list of entries or for carrying the results of such a petition. This specification allows mobile nodes to direct flows to a particular care-of address. The granularity of what constitutes a flow depends on the flow descriptor used. As indicated earlier the flow description itself is defined in another document. The remaining of this section discusses how mobile nodes can use the options and sub-options defined in this document when sending binding updates to the correspondent node, home agent or mobility anchor point. In addition, refresh, deletion, and modification of bindings are all discussed below. 5.1.1. Preferred Care-of address Any node that supports this specification MUST maintain an ordered 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 based on the BID-PRI field of the Binding Identifier option (see Section 4.1). 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 binding entries defined in Section 4.4. A packet that does not match 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 BID-PRI value. 5.2. Mobile Node Considerations This specification allows the mobile node to maintain several bindings in its home agent and to direct packets to different care-of addresses according to flow bindings. This section details the Soliman, et al. Expires October 30, 2009 [Page 17] Internet-Draft Flow binding April 2009 mobile node operations necessary to implement this specification. The home agent list of flow bindings is manipulated by the mobile node, via flow identification and flow summary options included in binding update messages. Each flow binding update can add, modify, refresh, or delete a given binding. More than one flow identification options MAY be included in the same binding update but each of them MUST include a different FID. In other words, two flow identification options in the same message can not be about the same flow binding. All flow binding state MUST be refreshed in every binding update the mobile node sends. Any previously registered flow binding that is not included in a given binding update will be deleted. So, any flow bindings that are not added or modified by a flow identification option, but have previously registered and need to be maintained MUST be included in a flow summary option. Only one flow summary option can be included in a given binding update. 5.2.1. Sending BU with BID Options This specification (see Section 4.1) updates the definition of the Binding Identifier option, originally defined in [I-D.ietf-monami6-multiplecoa]. According to this specification the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus placing them in an ordered list as also described in Section 4.4. Mobile nodes supporting this specification MUST use the BID option format defined in Section 4.1. Mobiles nodes MUST also register all care-of addresses using the updated BID option format, either in the same BU as any flow identification options using them, or in earlier BUs. 5.2.2. Sending BU with Flow Identification Options 5.2.2.1. Adding flow bindings When adding a new flow binding, a mobile node sends the flow identification option in the binding update. The care-of address concerned with each flow identification option in the 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 in the FID field. The FID needs only be unique for the receiver of the binding update and for the same sender, i.e. the same FID can be Soliman, et al. Expires October 30, 2009 [Page 18] Internet-Draft Flow binding April 2009 used across different receivers of the binding update, for the same sender. The FID-PRI field is set to the desired priority of the FID, defining the order of the binding to be added in the list of flow binding entries as defined in Section 4.4. The Action field is set to one of the defined action codes (see Section 4.2). The PRO field MUST indicate an Add operation. The Status filed is set to zero in all binding update messages. The mobile node MUST include exactly one Flow Description sub-option (see Section 4.2.2) describing the flow associated with the new binding. The mobile node MAY also include exactly one BID Reference sub-option (see Section 4.2.1) to associate the flow binding with a given set of BIDs and corresponding CoAs. Depending on the Action field of the Flow Binding Identifier option, the following rules MUST be followed with respect to the Binding Reference sub-option: - if the Action indicates 'Forward', a single Binding Reference sub-option with a single BID MUST be included. This BID MUST be associated with a single care-of address. - if the Action indicates 'Discard', the Binding Reference sub- option SHOULD NOT be included. If it is included it will be ignored by the receiver. - if the Action indicates 'n-cast', a single Binding Reference sub-option with one or more BIDs MUST be included. 5.2.2.2. Modifying flow bindings Flow binding modification is essentially a process where an existing flow binding is removed from the list of flow binding entries and a new flow binding (included in the option) is added, and given the same FID as the flow that was removed. With this procedure the mobile node can change the action, the priority, the BID, or the flow description associated with a flow binding. To modify an existing flow binding the mobile node MUST send a 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 entries. Soliman, et al. Expires October 30, 2009 [Page 19] Internet-Draft Flow binding April 2009 The PRO field MUST be set to 1, indicating a request to modify the binding. The FID-PRI and Action fields MUST be set to the desired values to be implemented with this modification. The Status field is set to zero since this option is in a binding update. The mobile node MAY include exactly one Flow Description sub-option (see Section 4.2.2) describing the modified flow to be associated with the binding. The mobile node MAY also include exactly one BID Reference sub-option (see Section 4.2.1) to associate the existing binding with a new set of CoAs. The rules regarding the Binding Reference sub-option in this case are identical to those described from flow binding addition in Section 5.2.2.1 . Note that it is also possible for the mobile node to effectively modify the effect of a flow binding entry without actually changing the entry itself. This can be done by changing the CoA associated with a given BID, which is a process defined in detail in [I-D.ietf-monami6-multiplecoa]. 5.2.3. Sending BU with a Flow Summary Option 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 of their parameters. To refresh an existing flow binding the mobile node MUST send a binding update with a flow summary option. The flow summary option MUST include one or more FID fields as indicated in Section 4.3. Each FID field included MUST be set to one of the FID values already in the list of flow binding entries. Any flow bindings (active or inactive) that are not included in a binding update will be removed from the list of flow binding entries. Note that any inactive flow bindings, i.e., flow bindings without associated BIDs that are marked as Inactive in the list of flow binding entries (see Section 4.4, MUST also be refreshed, or modified, to be maintained. If they are not included in a BU they will be removed. Soliman, et al. Expires October 30, 2009 [Page 20] Internet-Draft Flow binding April 2009 5.2.4. Removing flow bindings Removal of flow binging entries is performed implicitly by omission of a given FID from a binding update. To remove a flow binding the MN simply sends a binding update that includes flow identification and flow summary options for all the FIDs that need to be refreshed, modified, or added, and simply omits any FIDs that need to be removed. Note that a mobile node can also remove the BIDs associated with a given Flow Binding, without removing the flow binding itself. The procedure for removing a BID is defined in detail in [I-D.ietf-monami6-multiplecoa]. 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 entries as shown in Section 4.4. In other words the state associated 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 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 or more valid BIDs. 5.2.5. Receiving Binding Acknowledgements According to [RFC3775] all nodes are required to silently ignore mobility options not understood while processing binding updates. As such a mobile node receiving a Binding Acknowledgement in response to the transmission of a binding update MUST determine if the Binding Acknowledgement contains a copy of every flow identification options included in the binding update. A Binding Acknowledgement without flow identification option(s), in response to a Binding Update with flow identification option, would indicate inability (or unwillingness) on behalf of the source node to support the extensions presented in this document. If a received Binding Acknowledgement contains a copy of of each flow identification option that was sent within the binding update, the status field of each flow identification option indicates the status of the flow binding on the distant node. 5.2.6. Return Routability Procedure A mobile node may perform route optimization with correspondent nodes 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 correspondent node to direct the traffic to the current location of Soliman, et al. Expires October 30, 2009 [Page 21] Internet-Draft Flow binding April 2009 the mobile node. Before sending a Binding Update to correspondent node, the Return Routability Procedure needs to be performed between the mobile node and the correspondent node. 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 n-cast action before having registered each care-of address one by one. 5.3. HA, MAP, and CN Considerations This specification allows the home agents, mobility anchor points, and corresponding nodes to maintain several bindings for a given home address and to direct packets to different care-of addresses according to flow bindings. This section details the home agent operations necessary to implement this specification. These operations are identical for MAPs and CNs unless otherwise stated. Note that route optimization is only defined for mobile nodes (MIPv6 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these sections only apply to correspondent nodes with respect to mobile nodes and not for mobile routers. 5.3.1. Receiving BU with BID Options This specification (see Section 4.1) updates the definition of the Binding Identifier option, originally defined in [I-D.ietf-monami6-multiplecoa]. According to this specification the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus placing them in an ordered list (see Section 4.4). Home agents receiving BUs including BID options and flow identification options MUST logically process BID options first. This is because BID Reference sub-options included in the flow identification options might refer to BIDs defined in BID options included in the same message. The BID option is processed as defined in [I-D.ietf-monami6-multiplecoa] but then the BID to care-of address mapping is placed in an ordered list according to the BID-PRI field of the BID option. Soliman, et al. Expires October 30, 2009 [Page 22] Internet-Draft Flow binding April 2009 5.3.2. Receiving BU with Flow Identification Options When the home agent receives a binding update which includes at least one Flow Identification option, it first performs the operation described in section 10.3.1 of RFC3775. Home agents that do not support this specification will ignore the flow identification options and all their suboption, 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 support flow bindings for this MN, the home agent checks the flow identification options. If more than one flow identification option in the same BU, has the same value in the FID field, all the flow identification options MUST be rejected. If all FID fields have different values the flow identification options can be processed further and in any order, as defined by the following subsections. 5.3.2.1. Handling Flow Binding Add Requests If the PRO field of the flow identification option is set to 'Add', it indicates a flow binding add request. 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 poorly formed). 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 combination with the Binding Reference sub-option if present. - if the Action indicates 'Forward' Soliman, et al. Expires October 30, 2009 [Page 23] Internet-Draft Flow binding April 2009 If the Binding reference sub-option is not included or if it is included but it contains more than a single BID, 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 129 (Flow identification option poorly formed). If the Binding Reference sub-option is present and includes a single BID, but the BID is not present in the binding cache of the 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 TBD (BID not known). If the Binding Reference sub-option is present and includes a single BID, and the BID exists in the mobile node's binding cache, 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', Any Binding Reference sub-options that might be present SHOULD be ignored. 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 'n-cast', If the Binding reference sub-option is not included, 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 129 (Flow identification option poorly formed). If the Binding Reference sub-option is present and includes BIDs that are not present in the binding cache of the 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 TBD (BID not known). 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, the home agent SHOULD add a new entry in the mobile node's list of flow binding entries, as defined below. 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 to the following rules: The entry MUST be placed according to the order indicated by the FID-PRI field of the flow identification option and it MUST include: Soliman, et al. Expires October 30, 2009 [Page 24] Internet-Draft Flow binding April 2009 the FID as a key to the entry The flow description included in the corresponding sub-option the action indicated in the Action field the BIDs indicated in the binding reference sub-option the entry MUST be marked as Active, as shown in Section 4.4 5.3.2.2. Handling flow binding Modification Requests If the PRO field of the flow identification option is set to 'Modify', it indicates a flow binding modification request. Note that flow binding modification is essentially a process where an existing flow binding is removed from the list of flow binding entries and a new flow binding (included in the option) is added, and given the same FID as the flow that was removed. If the value of the FID field of the flow identification option is not present in the binding cache entries for this mobile node, the home agent MUST reject this flow binding modify request by copying the flow identification option in the BA, and setting the Status field to 135 (FID not found). If the value of the FID field is present in the mobile nodes list of flow binding entries, the home agent SHOULD first remove the flow binding entry identified by the FID. The home agent then SHOULD processes this flow identification option as defined in Section 5.3.2.1. 5.3.3. Receiving BU with Flow Summary Option When the home agent receives a binding update which includes a Flow Summary option, it first performs the operation described in section 10.3.1 of RFC3775. Binding update messages including more than one flow summary option MUST be rejected. Home agents that do not support this specification will ignore the flow summary option, having no effect on the operation of the rest of the protocol. 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 mobile node, the home agent MUST reject this flow binding modify request by including a flow identification option in the BA, and setting the FID field in the value of the FID that is not found and Soliman, et al. Expires October 30, 2009 [Page 25] Internet-Draft Flow binding April 2009 the Status field to 135 (FID not found). 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 identified by the FID without changing any of the other parameters associated with it. 5.3.4. Handling flow binding Removals Removal of flow bindings is performed implicitly by omission of a given FID from a binding update. When a valid binding update is received, any registered FIDs that are not explicitly referred to in a flow identification option or in a flow summary option, MUST be removed from the list of flow binding entries for the mobile node. 5.3.5. Sending Binding Acknowledgements Upon the reception of a binding update, the home agent is required to send back a Binding Acknowledgment. The status code in the Binding Acknowledgement must be set as recommended in [RFC3775]. This status code does not give information on the success or failure of flow bindings. In order to inform the mobile node about the status of the flow binding(s) requested by a mobile node, flow identification options MUST be included in the Binding Acknowledgement message. Specifically, the home agent MUST copy each flow identification option received in the binding update and set its status code to an appropriate value. If an operation requested in a flow identification option by a mobile node is performed successfully by the home agent, the status field on the copied flow identification option in the BA, SHOULD be set to 0 (Flow binding successful), otherwise it SHOULD be set to one of the rejection codes defined. Section 5.3.2 identifies a number of cases where specific error codes should be used. Home agents that support this specification MAY refuse to maintain flow bindings by setting the status field of any flow identification options to 130 (Administratively prohibited), or by just ignoring all the flow binding options. Note that BID options and their Status field are handled as defined in [I-D.ietf-monami6-multiplecoa]. Soliman, et al. Expires October 30, 2009 [Page 26] Internet-Draft Flow binding April 2009 5.3.6. Packet Processing This section defines packet processing rules according to this specification. This specification does not change any of the packet interception rules defined in [RFC3775], and [I-D.ietf-mext-nemo-v4traversal]. These rules apply to HAs, MAPs, and CNs, as part of the routing process for any packet with destination address set to a valid home address of the mobile node. For nodes other than CNs this also applies to packets with destination address set to an address under any of the registered prefixes. These rules apply equally to IPv6 packets as well as to IPv4 packets when [I-D.ietf-mext-nemo-v4traversal]. 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 binding entries for this mobile node (see Section 4.4). A match is attempted with the flow description included in the first line (highest order) of the table. If the packet matches the flow description, the action defined by the action parameter of the table SHOULD be performed. - if the Action indicates 'Forward' the packet is forwarded to the care-of address indicated by the BID parameter in the same line of the table. - if the Action indicates 'Discard', the packet is silently discarded - if the Action indicates 'n-cast', a copy of the packet is forwarded to each of the care-of addresses associated with the BIDs indicated in the same line of the table. 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 entry since the packet is not forwarded. If, however, the action indicated in an entry of the list of flow bindings is "forward" or "n-cast", the entry must indicated a BID. For "n-cast" if any of the BIDs indicated does not correspond to a valid care-of address, e.g., the BID was deregistered then that BID has no effect on the traffic. In other words, packets matching the flow binding are n-casted to the other BIDs, pointing to registered care-of addresses. If none of the BIDs pointed to in a flow binding entry is valid then the entry is considered to be inactive (as defined in Section 4.4) and is skipped. In other words packets should not be matched against that entry. Soliman, et al. Expires October 30, 2009 [Page 27] Internet-Draft Flow binding April 2009 6. Security considerations This draft introduces a new option that adds more granularity to the binding update message. The new option allows the mobile node to associate some flows to one interface and other flows to another interface. Since the flow Identification option is part of the mobility header, it uses the same security as the Binding Update, whether it is sent to the home agent, correspondent node, or MAP. Soliman, et al. Expires October 30, 2009 [Page 28] Internet-Draft Flow binding April 2009 7. IANA Considerations A Type number (TBD) for Flow Identification Mobility Option and another Type number (TBD) for Flow Summary Mobility Option has been 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 Mobility Option has been created: "Flow Identification Mobility Option Sub-Options". The suboption values 1, and 2, are defined in 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 Mobility Option has been created: "Flow Identification Mobility Option Status codes". Values 0, 128-130 and 135-139 are defined in this specification. The rest of the values below 128 are reserved for accept codes, and values from 128 and above are reserved for reject codes. Similar to the procedures specified for Mobile IPv6 [RFC3775] number spaces, future allocations from the two number spaces require Expert Review [RFC5226]. Soliman, et al. Expires October 30, 2009 [Page 29] Internet-Draft Flow binding April 2009 8. Contributors We would like to explicitly acknowledge the following person who co- authored one of the documents used as source material for this document. Nikolaus A. Fikouras, niko@comnets.uni-bremen.de Soliman, et al. Expires October 30, 2009 [Page 30] Internet-Draft Flow binding April 2009 9. Acknowledgements We would also like to acknowledge the following people in alphabetical order: C. Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N. Pavlidou, V. Park. Gabor Fekete for the analysis that led to the inclusion of the BIDRef sub-option. Henrik Levkowetz for suggesting support for other ways of describing flows. Soliman, et al. Expires October 30, 2009 [Page 31] Internet-Draft Flow binding April 2009 10. 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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. 10.2. Informative References [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. Soliman, et al. Expires October 30, 2009 [Page 32] Internet-Draft Flow binding April 2009 Authors' Addresses Hesham Soliman Elevate Technologies Email: hesham@elevatemobile.com George Qualcomm Email: tsirtsis@gmail.com Nicolas Montavont Institut Telecom / Telecom Bretagne 2, rue de la chataigneraie Cesson Sevigne 35576 France Phone: (+33) 2 99 12 70 23 Email: nicolas.montavont@telecom-bretagne.eu URI: http://www.rennes.enst-bretagne.fr/~nmontavo// Gerardo Qualcomm Email: gerardog@qualcomm.com Koojana Kuladinithi University of Bremen ComNets-ikom,University of Bremen. Otto-Hahn-Allee NW 1 Bremen, Bremen 28359 Germany Phone: +49-421-218-8264 Fax: +49-421-218-3601 Email: koo@comnets.uni-bremen.de URI: http://www.comnets.uni-bremen.de/~koo/ Soliman, et al. Expires October 30, 2009 [Page 33]