IETF MEXT Working Group H.
Soliman, Ed.Soliman Internet-Draft Elevate Technologies Intended status: Standards Track N. MontavontG. Tsirtsis Expires: August 17,October 30, 2009 GET/ENST-BQualcomm N. FikourasMontavont IT/TB G. Giaretta Qualcomm K. Kuladinithi University of Bremen February 13,April 28, 2009 Flow Bindings in Mobile IPv6 and Nemo Basic Support draft-ietf-mext-flow-binding-01.txtdraft-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 August 17,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 (http://trustee.ietf.org/license-info)in effect on the date of publication of this document.document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document introduces extensions to Mobile IPv6 and Nemo Basic Supportthat allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to take full advantage of the different properties associated with each ofinstruct their interfaces.peers to direct downlink flows to specific addresses. Table of Contents 1. IntroductionRequirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . 4 2. Terminology. . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . 6 3. Mobile IPv6 Extensions. . . . . . . . . . . . . . . . . . . . 7 3.1. Flow Identification option4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . 7 3.2. The Binding Reference Sub-option. . . . 8 4.1. Definition Update for Binding Identifier Mobility Option . . . . . . . . . 10 3.3. Binding Cache and Binding Update list extensions. . . . . 11 4. Protocol operations. . . . . . . . . . . . 8 4.2. Flow Identification Mobility Option . . . . . . . . . 12 4.1. Interaction with the Multiple CoA bindings mechanism. . 8 4.2.1. Binding Reference Sub-option . 12 4.2. Flow binding storage. . . . . . . . . . . . 11 4.2.2. Flow Description Sub-option . . . . . . . 13 4.3. Preferred Care-of address. . . . . . 12 4.3. Flow Identification Summary Mobility Option . . . . . . . 13 4.4. Flow Bindings entries list and its relationship to Binding Cache . . . 13 4.4. Adding flow bindings. . . . . . . . . . . . . . . . . . . 13 4.5. Modifying flow bindings14 5. Protocol operations . . . . . . . . . . . . . . . . . 14 4.6. Removing flow bindings. . . . 17 5.1. General . . . . . . . . . . . . . . 15 4.7. Refreshing Flow Bindings. . . . . . . . . . . 17 5.1.1. Preferred Care-of address . . . . . . 15 4.8. Acknowledging flow identification options. . . . . . . . 15 5. Usage scenario17 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 17 5.2.1. Sending BU with BID Options . . . . . . . . 16 6. Mobile Node operations. . . . . 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 . . 18 6.1. Default Bindings. . . . . . . . . . . . . . 21 5.2.5. Receiving Binding Acknowledgements . . . . . . . 18 6.1.1. Managing Flow Bindings with the Home Agent and MAP. . 18 6.1.2. Managing Flow Bindings in Correspondent nodes. 21 5.2.6. Return Routability Procedure . . . 19 6.1.3. Using Alternate Care-Of Address. . . . . . . . . . 21 5.3. HA, MAP, and CN Considerations . 20 6.1.4. Receiving Binding Acknowledgements. . . . . . . . . . 20 6.2. Movement. . . 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 . . . . . . 20 6.3. Return Routability Procedure. . 25 5.3.4. Handling flow binding Removals . . . . . . . . . . . . 26 5.3.5. Sending Binding Acknowledgements . 20 6.4. Returning Home. . . . . . . . . . 26 5.3.6. Packet Processing . . . . . . . . . . . . 21 7. Applicability to Route Optimization. . . . . . 27 6. Security considerations . . . . . . . 22 7.1. Receiving Binding Udpate. . . . . . . . . . . . 28 7. IANA Considerations . . . . . 22 8. Home Agent operations . . . . . . . . . . . . . . . . . . . . 24 8.1. Receiving Binding Update with the Flow Identification option . . . .. . . . . . . . . . . . . . . . 29 8. Contributors . . . . . . 24 8.2. Sending Binding Ackowledgement . .. . . . . . . . . . . . 25 8.3. Deleting an entry in the binding cache . . .. . . . . . . 25 8.3.1. Removing Flow Bindings30 9. Acknowledgements . . . . . . . . . . . . . . . . 26 9. Applicability to Hierarchical Mobile IPv6. . . . . . . 31 10. References . . . 27 10. Security considerations. . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements. . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 12.32 10.2. Informative References . . . . . . . . . . . . . . . . . . . . 3032 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3133 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]. 2. Introduction Mobile IPv6 (RFC3775) [RFC3775][RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and Nemo Basic Support (RFC3963)[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 Updatebinding update can also be sent to correspondent node or to a mobility anchor point (see RFC4140 [RFC4140]).[RFC5380]). The semantics of the binding update are limited to care-of address changes. That is, RFC3775 [RFC3775][RFC3775], [I-D.ietf-mext-nemo-v4traversal], and RFC3963[RFC3963] do not allow a mobile node / mobile router to bind more than one address to the home address. Furthermore, the binding granularity is limited to the address. Therefore, a mobile host cannot associate one of the connections using the home address with a different care-of address.In draft-ietf-monami6-multiplecoa[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 IPv6IPv6, 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 flow.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, we will see thatthis specification allows to bind a particular flow to a particular care-of address directly with correspondent node and mobility anchor point in the case of a single mobile node.point. In this document, a flow is defined as one or more connections that are identified bya set of IP packets matching a flow identifier.descriptor. A single connection is typically identified byflow descriptor can identify the source and destination IP addresses, transport protocol number andnumber, the source and destination port numbers. Alternatively a flow can be identifiednumbers and other fields in a simpler manner using theIP and higher layer headers. This specification, however, does not define flow label field in the IPv6 header [RFC2460] or the Security Parameter Index (SPI) when IPsecdescriptors and it is used. Flow bindingsassumed that one or more ways of defining flow descriptors are usefulgoing to be defined in cases whereother 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 has more thancan bind one address, probably due to being multihomed, and wants to direct certain flows to certain addresses. This may be done because some flows are better suited to certain link layers or simply to load balance flows between different interfaces. This specification introduces the flow identifier option, which is included in the binding update message and used to distribute policies to the recipient of the binding update. However, this document does not define the flow itself but only the action to take on this flow. The flow description will be defined in another document. This will allow to use the same flow description in several protocols. Using the flow identifier option introduced in this specification a mobile node / mobile router can bind one or moreor 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), home agentor mobility anchor point (in the case of Hierarchical Mobile IPv6). In the rest of the document, the term "mobile node" is used to designate either a mobile node as defined in RFC3775[RFC3775] or a mobile router as defined in RFC3963[RFC3963] unless stated otherwise. 2.3. Terminology Terms used in this document are defined in [RFC3753] and [I-D.ietf-nemo-terminology].[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 distant hostsnodes 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: A mobilityAn entry in the list of flow binding extendedassociated with a flow identifier and flow description. 3.given mobile node. 4. Mobile IPv6 Extensions This section introduces extensions to Mobile IPv6 that are necessary for supporting the flow binding mechanism described in this document. 3.1. Flow Identification option The Flow identification option is included in the binding update and acknowledgement messages.4.1. Definition Update for Binding Identifier Mobility Option This option contains information that allowsspecification updates the receiverdefinition of a binding update to install policies on a traffic flow and route it to a given address. Multiple options may exist within a binding update message. The Flow identification option must come with another option (that will be defined in another document) that will describethe flow. This additionalBinding Identifier Mobility option is called Flow Descriptiondefined in the remaining of this document. 0[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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType = TBD | Option Len | PRI | FIDLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | ActionBinding ID (BID) | Status |H| BID-PRI | PRO | Res. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Description ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ + + : IPv4 or IPv6 care-of address (CoA) : + + +---------------------------------------------------------------+ Figure 1: The flowBinding 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. 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 optionoption, including any sub-options, in 8-octet units PRIFID 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. 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.Action This field specifies the action that needs to be taken by the receiver of the binding update containing the flow identification option. StatusThe details of these requests are discussed below. Rsvd This field indicates the successis unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 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. 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. Res. This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.The following values are reserved for the PRO field in this option: 0 Add a flow binding 1 Replace a flow binding 2 Refresh the current binding 15 RemoveModify 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 included or referred byindicated in the option.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. 2No BIDs are associated with this Action. 3 n-cast. hisThis value indicates a request to replicate the flow to several addresses. If this value is used, one or moreaddresses indicated in the Binding Reference sub-optionssub-option. One or more BIDs MUST exist. The Binding Reference sub- option is described later inbe associated with this specificationAction. 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 bindingidentification option poorly formed. 130 Administratively prohibited. 131 Flow identification by IPv6 prefix is not supported. 132 Flow identification by port numbers is not supported. 133 Flow identification with Flow label is not supported. 134 Flow identification with SPI is not supported.135 FID already in use 136 FID not found 137 Classifier languageFD-Type not supported. 138 Discard function not supported. 139 N-cast function not supported. It should be noted that per-packet load balancing hasmay 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 allowedcurrently supported in this extension. However, the MNA number of sub-options can still request per-flow load balancing provided that the entire flow is moved tofollow the new interface. 3.2. Theoption 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 asdefined in theMCoA document.[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 BIDs that where alreadyregistered with the recipient of the BU. A BID sub-option is not necessarily includedBIDs. The binding identifier option, defined in [I-D.ietf-monami6-multiplecoa], registering a given BID which is then indicated in the same BU, butBinding Reference sub-option, MUST be already known toeither defined in the receiver ofsame or earlier BU from the one including the BU.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 2:3: The Binding Reference sub-option 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 typeSub-opt Type and lengthSub-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. 3.3. Binding Cache and Binding Update list extensions Flow bindings are conceptually stored in Binding CacheSince each BID is 2 byte long, the value of home agent, mobility anchor point and correspondent node, and in Binding Update Listthe Sub-opt Len field indicates the number of mobile node. These logical structures need to be extended toBIDs present. Number of BIDs = (Sub-opt Len-2)/2. 4.2.2. Flow Description Sub-option The Flow description sub-option(s) include the followingparameters (in additionused to those described in RFC3775 [RFC3775]): * FID (Flow Identifier). For a given home address, the FID MUST uniquely identify an entry, i.e.match packets for a uniquespecific flow binding. An FID is only unique for a given home address. Different mobile nodes can use0 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 same FID value. * Each attribute that constitutesSub-option type. For the flow dsecription (and that aredescription sub- option, this field SHOULD be set to one of the FD types defined below. Sub-opt Len Indicates the sub-option length in a separate document). An entry in these structures is identified byoctets. This field includes the couple (home address, FID). 4. Protocol operations The flow identification option defines the controls on flow bindings. The fieldsentire length of the flow identification option are necessary for indexing flow identification options, indicating the sort of action that should be undertaken to the recipient's Binding Cache or for carryingsub-option including the results of such a petition.Sub-opt Type and Sub-opt-Len fields. Flow Description The flow description is transported in another option that will be defined in another document. This separation is made to use the same flow description in various protocols. This specification allows mobile nodes to direct flowscorresponding to a particular care-of address. This can be done by aggregating many flows inthe flow identification option (e.g. all TCP traffic), ortype indicated by uniquely identifying a flow inthe flow identification option. The remainingSub-opt Type field. Flow description is out of this section discusses how mobile nodes can use the flow identification option when sending binding updates to the correspondent node, home agent or mobility anchor point. In addition, deletion and modificationscope of bindingsthis document. The following values are all discussed below. 4.1. Interaction withreserved for the Multiple CoA bindings mechanismsub-option Type values are defined for Flow binding presented inDescription: 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 specificationfield MUST be used withset to 1. Option Length Indicates the solutionsub-option length in draft-ietf-monami6-multiplecoa. The main reason why is to avoidoctets. This field includes the duplicationentire length of the default binding to be used when none ofsub-option including the Sub-opt Type and Sub-opt-Len fields. FID A registered rulesFID. One or more FID fields can apply to a flow. As the multiple CoA bindings document already defines a prority field which indicates which care-of address is preferred, flow binding uses this priority field in order to maintain a primary Care-of address (see below section Section 4.3). Moreover, combining the mechanismbe included in this specification withoption. Since each FID is 2 bytes long, the multiple CoA bindings allows for further aggregationvalue of bindings. For example, if a mobile node has several flow identifiers bound to a single Care-of address identified by a unique BID, the mobile node can change the Care-of address for all these flows bindings just by changingthe Care-of address associated with the given BID. Additionally, the combination ofOption Len field indicates the two mechanisms allows for additional features (e.g., n-casting) to take place with minimal effort. Hence, this specification makes usenumber of the BID option described in draft-ietf-monami6-multiplecoa. 4.2.FIDs present. Number of FIDs = (Sub-opt Len-2)/2. 4.4. Flow binding storage Home agent, correspondent nodeBindings entries list and mobility anchor point maintainits relationship to Binding Cache in order to record associations between home addresses and care-of addresses ofThe conceptual mobile nodes that are away from the home link. Mobile nodes maintain binding update list to recordIPv6 binding between home address and care-of address. RFC 3775cache was defined in [RFC3775] allows mobile nodesto register only one care-of address per home address. Thus a binding cache entry is uniquely identifiedidentify the mobile IP state maintained by the mobile node, home address. This specification extends theagent, and corresponding node. The binding cache andincludes, between others, the binding update list structures, and allowsmobile node to (1) register multiple care-of addresses for a givennode's home address and (2) associate flow binding policies withaddress, the registered care-of addresses. New parameters are added to these conceptual structures in order to list the particular rule associated with a standard binding. On one hand, an entry is now identified by the pair (homeaddress, FID) because several Care-of addresses may be bound to a single home address. On the other hand, the Care-of address is selected according to the best match between the packets that need to be sent, and the existing flow bindings. If no matching is found between the flow bindingsand the data packet, a preferred entry is used (see next subsection). If a flow matches two different flow bindings, the PRI field indicates which action is preferred by the mobile node. 4.3. Preferred Care-of address Any distant node which supportslifetime of the flow identification option MUST maintain a default binding per home address. A defaultbinding. The binding indicates an association between a home address and a Care-of address. In additioncache was then extended by [I-D.ietf-monami6-multiplecoa] to include more than one care-of addresses and to the default binding, several bindings may co-exist within a binding cache for the same home address,associate each of them indicating differentwith a Binding Identifier (BID). This specification does not change modify the mobile IPv6 binding cache any further. Flow bindings between flows and Care-of addresses. Whencan be thought of as a data flowconceptual list of entries that is intercepted by a home agent or initiated by a correspondent node, ifseparate from the said databinding cache. The flow does not matchbindings list contains an existing flow identification option,entry for each of the care-of address indicatedregistered flow binding. Flow binding entries can point to an entry in the defaultbinding is used as destination address forcache by means of the mobile node. The defaultBID. Each flow binding is indicated byentry include the Priority field infollowing parameters : * FID (Flow Identifier): For a given mobile node, identified by its primary home address, the BID option described in draft-ietf-monami6-multiplecoa. AFID MUST uniquely identify an entry, i.e. a unique flow binding. Each mobile node is responsible for havingcan only have a preferred care-of address withsingle entry identified by a given FID at any one time. Different mobile nodes can use the receiversame FID number space. * A Flow Descriptor: Included in a Flow Description sub-option. * BID(s): The list of BIDs associated with the flow identification option. 4.4. Adding flow bindings When adding a new flow binding, a mobile node sendsentry as defined by the flow identification optionBinding Reference sub-option included in the binding update.FID option that created it. * Action: The care-of address concernedaction associated with this binding update must already be registereda given entry as defined by the receiverPRO field of the binding update (i.e., must already beFID 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 BID), or a BID sub-option MUST be present ingiven mobile node, and the corresponding binding update (as definedcache. An entry in draft-ietf-multiplecoa"). Thethe flow identification option MUST include a unique FID. Thebindings list, however, is identified by the FID needs only be unique forand the receiver oflist is ordered according to the binding update, i.e.FID-PRI field as defined in the sameFID can be used across different receivers of the binding update.option that created each entry. The PRO field MUST indicate an Add operation. Adding the flow binding implies associatingBIDs included in a flow withgiven entry point to a particular care-of addresscorresponding entry in the binding cache for the mobile node. Thepurpose of identifying a care-of address concerned withaddress. 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 is presententry becomes "inactive", in other words it does not affect data traffic. Note that if the source addressaction parameter in an entry indicates "n-cast" then the entry becomes inactive only if none of the packet orBIDs is valid. If only some of the alternate care-of address option. Alternatively,BIDs are valid, the care-of address may be indicated byinvalid BIDs are simply ignored. Also note that the BID (whichstate described in this section is pointing to an existing care-of address) whenmaintained by the Binding Reference sub-optionmobile 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 Flow Identification option is present. Themobile node may need to definein detail. As an example the following represents an ordered flow partially or entirely based on the source and destination addresses in packets. For instance,bindings entries table for a mobile node may choosethat 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 forwardthe above list of flow binding entries, all flows from address ATCP traffic will match the first entry, and according to address Bthe Action indicated it will be forwarded to BID2, corresponding to a particulargiven care-of address. Alternatively, more granularity can be added by including port numbersaddress (IP3), as shown below. Any traffic that is not TCP, but has as source address IPx will match the second entry, and protocol. These descriptionsaccording to the associated Action it will be given in another document. An Add operation impliesdiscarded. Note that any TCP traffic with source address IPx will match the FID is newfirst entry and thus it will be forwarded as per that entry. The third entry is marked as Inactive since the BID 4 does not already used byexist in the mobile node forordered 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 other flow binding. Ifof the Flow identification option is sent without any flow descriptionearlier entries will match the third rule and withaccording to the PRO field indicating an Add operation, this MUSTAction indicated it will be seen as a wild card request byreplicated and forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and IP2 shown below. Finally any remaining packets that do not match any of the sender. A wild card request implies that all flows shouldentries above will be directedsimply forwarded to the particularcare-of address indicated by the highest order BID in the packet. 4.5. Modifying flow bindings When modifying a flow binding (eithertable below. In the example, such packets will be forwarded to BID 1, corresponding to care-of address or other attributes of the flow), the mobile node sends the binding update withIP1. BID-PRI BID CoA --------- --- --- 20 1 IP1 30 3 IP2 30 2 IP3 Ordered BID Entries 5. Protocol operations 5.1. General This specification introduces a flow identification option. The option includes the FID for thebindings list of entries and an ordered list of binding being modified, as well as the PRO field set to 1, indicating a requestidentifiers, allowing mobile nodes to modify the binding. Aassociate flow description option may comebinding policies with the registered care-of addresses. The flow identification option and contain the new attributes needed to classifydefines how the flow. Hence, flow modification is essentially a process where an existing flow definition is removed andmobile node can control a newset of flow (includedbinding entries maintained in the option) is added and given the same FID as the flow that was removed. If one of the care-of addresses needs to be updated with a new one (e.g., aftera changehome agent, correspondent node, or mobility anchor points, on its behalf. The fields of the IP point of attachment),flow identification option are necessary for ordering flow identification options, indicating the mobile node may just needsort of action that should be undertaken to register the new care-of address forthe given BID. 4.6. Removing flow bindings When removing arecipient's flow binding, the mobile node sends abinding update message withlist of entries or for carrying the flow identification option. The PRO field MUST be setresults of such a petition. This specification allows mobile nodes to direct flows to a valueparticular care-of address. The granularity of 15, which indicates a request for removingwhat constitutes a flow binding. This will provide enough information for the receiver to locatedepends on the flow binding usingdescriptor used. As indicated earlier the FID and remove it. 4.7. Refreshing Flow Bindings Aflow bindingdescription itself is refreshed by simply includingdefined in another document. The remaining of this section discusses how mobile nodes can use the Flow identification optionoptions and sub-options defined in this document when sending binding updates to the BU message.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 casespecification 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 PROBID-PRI field of the Binding Identifier option (see Section 4.1). The ordered list of BIDs is setused to indicatedetermine how to forward a refresh operation. The refresh operation is included in this specification duepacket to a given mobile node when the naturepacket does not match any of the BU message. The BU message updates existing bindings with new information. Hence, all information previously sentflow binding entries defined in Section 4.4. A packet that does not match any of the last BU message need to be resent in all new messages, otherwise such information will be lost. 4.8. Acknowledgingflow identification options The home agent and mobility anchor point are requiredbinding entries SHOULD be forwarded to ackowledgethe reception of Binding Update by sending Binding Acknowledgment. A correspondent node SHOULD also acknowledge Binding Update. The Binding Acknowledgement is extendedcare-of address identified by thisthe BID with the highest priority i.e., lowest BID-PRI value. 5.2. Mobile Node Considerations This specification allows the mobile node to indicatemaintain several bindings in its home agent and to direct packets to different care-of addresses according to flow bindings. This section details the mobile node the successoperations necessary to implement this specification. The home agent list of flow bindings is manipulated by the mobile node, via flow binding. If a Binding Acknowledgement needs to be sentidentification and flow summary options included in response to a Binding Update that containedbinding update messages. Each flow identification option(s),binding update can add, modify, refresh, or delete a copy of eachgiven binding. More than one flow identification MUST be included. Only the Status field needs tooptions MAY be changed toincluded in the appropriate value. The absencesame binding update but each of them MUST include a different FID. In other words, two flow identification optionoptions in Binding Acknwoledgement indicates thatthe sender doessame message can not supportbe about the extension descibed in this document and thereforesame flow binding. All flow binding state MUST be interpreted as a negative acknowledgement. 5. Usage scenario In this section, we highlight a use case ofrefreshed in every binding update the flow identification option. Assume a mobile node equipped with two interfaces namely If1 and If2, each connected to a different foreign network. The mobile node configures one global IPv6 address on each interface, namely CoA1 and CoA2 respectively. Themobile node runs Mobile IPv6 with a home agent located in its home network. We assumesends. Any previously registered flow binding that an existing IPsec security associationis set up betweeen the mobile node and its home agent. We assumenot included in a given binding update will be deleted. So, any flow bindings that the mobile node wants to exchange secure data flows over CoA1 and insecure data flows over CoA2. To do so, the mobile node may request its home agent to redirect packets intended to the mobile node's home address toare not added or modified by a different care-of address, depending on the type of the communication. For example, port numbers 22 (ssh)flow identification option, but have previously registered and 443 (https) may be tunneledneed to CoA1 while other communications maybe tunneled to CoA2. In order to set up thesemaintained MUST be included in a flow bindings, the following messages are exchanged: * The mobile node sendssummary option. Only one flow summary option can be included in a Binding Update through If2,given binding update. 5.2.1. Sending BU with the source address set to CoA2. The Binding Update includes aBID sub-option as described in draft-ietf-monami6-multiplecoa.Options This sub-option intends to set the highest preference on the given Care-of address. * When the home agent receives the Binding Update, it first validatesspecification (see Section 4.1) updates the Binding Update as recommanded in section 10.3definition of [RFC3775]. Ifthe Binding Update is accepted, the home agent processesIdentifier option, originally defined in [I-D.ietf-monami6-multiplecoa]. According to this specification the BID sub-optionoption 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 6.2 of draft-ietf-monami6-multiplecoa. It then registers the source address of the Binding Update asSection 4.4. Mobile nodes supporting this specification MUST use the preferredBID option format defined in Section 4.1. Mobiles nodes MUST also register all care-of address foraddresses using the given home address and sends back a Binding Acknowledgement. * Later,updated BID option format, either in the mobile node sends additional Binding Updatesame BU as any flow identification options using them, or in earlier BUs. 5.2.2. Sending BU with bothFlow Identification options and BID sub-option. The BID sub-option is used to indicate the priority of theOptions 188.8.131.52. Adding flow bindings When adding a new Care-of address. In this example, the priority must be lower than the priority of CoA2. Theflow identification options are used to indicatebinding, a mobile node sends the Care-of address usage preferences. In order to redirect source port numbers 22 and 443 to CoA1, twoflow identification options need to be transported as welloption in the Binding Update. Thesebinding update. The care-of address concerned with each flow identification options are set as follows: PRI is set to 1, Action is set to 0 (forward), PRO is set to 0 (add), FID is set to 1 (and 2 for the second option), and the following flow descriptionoption should indicate port number 22 and 443. * Whenin the home agent receivesbinding update, must be logically registered by this second Binding Update, it first checksbinding update, or must have already been registered by the validityreceiver of the Binding Updatebinding update in an earlier binding update , as recommandeddefined in section 10.3 of [RFC3775] and section 6.2 of draft-ietf-monami6-multiplecoa. If the Binding Update is accepted, the Flow Identification options are treated. If these options are accepted by the home agent, it will returnSection 5.2.1. The flow identification option MUST include a Binding Acknowledgement withunique Flow Identification options, each of them having the same first 8 bytes, andIdentifier in the Status field set to 0 (success). Thereafter, if a data flow is destinated toFID field. The FID needs only be unique for the home addressreceiver of the mobile node, the home agent will determine if the source port number is equal to 22 or 443. If yes, the home agent will tunnelbinding update and for the data flow to CoA1. If not,same sender, i.e. the data flow willsame FID can be forwarded to CoA2. 6. Mobile Node operations 6.1. Default Bindings A default binding is always maintained between a MN and its peers (home agent, correspondent node if RO isused and mobility anchor point if applicable).across different receivers of the binding update, for the same sender. The default entry indicates which care-of addressFID-PRI field is set to use for a data flow that does not match anythe desired priority of the FID, defining the order of the binding to be added in the list of flow bindings.binding entries as defined in Section 4.4. The preferred care-of addressAction field is determined throughset to one of the BID option. 6.1.1. Managingdefined 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 BindingsDescription sub-option (see Section 4.2.2) describing the flow associated with the Home Agent and MAP Anew binding. The mobile node may establish a Flow Binding by issuing a Binding Update containing a Flow Identifier (possibly associatedMAY also include exactly one BID Reference sub-option (see Section 4.2.1) to associate the flow binding with a Flow Description) in its mobility options. The Flow Identification option MUST indicate valid FID, PRO, PRI (rule priority)given set of BIDs and corresponding CoAs. Depending on the Action fields. The PROfield of the Flow Identification option indicates the processing thatBinding Identifier option, the targeted node has to performfollowing rules MUST be followed with respect to its Bindings Cache List. A mobile node may request for any ofthe following requests: * 0: Add flow binding. CreateBinding Reference sub-option: - if the Action indicates 'Forward', a new Flowsingle Binding Reference sub-option with a single BID MUST be included. This BID MUST be associated with a single care-of address. - if the indicated FID and includeAction indicates 'Discard', the attached Flow. A mobile node MUSTBinding Reference sub- option SHOULD NOT issuebe 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. 184.108.40.206. Modifying flow bindings Flow Identifier with the PRO field set to zero forbinding modification is essentially a process where an existing FID. * 1: Replace aflow binding. This request enablesbinding is removed from the mobile node to replace attributeslist of theflow orbinding entries and a new flow binding (included in the care-of address associated withoption) is added, and given the FID. A mobile node MUST NOT issue a Flow Identifier withsame FID as the PRO field set to one for a non existent FID. * 2: Refresh aflow binding. This request allowsthat was removed. With this procedure the mobile node to informcan change the receiver ofaction, the BU message thatpriority, the flow binding is still valid. This request does not modifyBID, or the flow option. A flow identification option MUST NOT contain this value in the PRO field for a non-existent FID. * 15: Removedescription associated with a flow binding. This action enables a mobile node to remove the Flow Binding indicated by the FID onTo modify an existing flow binding the targeted node. Amobile node MUST not issuesend a Flow Identifierbinding update with a flow identification option, with the PROFID field set to 15 for a non existent FID. When adding a flow binding on the home agent or MAP,one of the mobile node MUST ensureFID values already in the following: *list of flow binding entries. The PRO field MUST be set to indicate an Add operation. * The FID field includes1, indicating a value that does not already exist inrequest to modify the mobile node's binding update list. *binding. The PRI field isFID-PRI and Action fields MUST be set to indicate the priority of the rule in case of an overlap between rules. An overlap can occur when one flow matches multiple flow description options. * Ifthe Actiondesired values to be implemented with this modification. The Status field is set to indicate N-cast, the Binding Referencezero since this option is in a binding update. The mobile node MAY include exactly one Flow Description sub-option must(see Section 4.2.2) describing the modified flow to be present and it must contain one or more BIDs. Ifassociated with the Binding Update sub-option includes onlybinding. The mobile node MAY also include exactly one BID, it must be pointingBID Reference sub-option (see Section 4.2.1) to associate the existing binding with a care-of address other thannew set of CoAs. The rules regarding the one includedBinding Reference sub-option in thethis case are identical to those described from flow binding update. 6.1.2. Managing Flow Bindingsaddition in Correspondent nodes When route optimisationSection 220.127.116.11 . Note that it is used (see RFC3775 [RFC3775]), aalso possible for the mobile node sends the BU messageto effectively modify the correspondent node after the return routability test procedure. When addingeffect of a flow bindings in the BU sent to the correspondent node,binding entry without actually changing the mobile node MUST ensureentry itself. This can be done by changing the following: * The FID field includesCoA associated with a value thatgiven BID, which is not already storeda process defined in the binding update listdetail in [I-D.ietf-monami6-multiplecoa]. 5.2.3. Sending BU with a Flow Summary Option When the correspondent node's address. * The PRO field is set to indicate an Add operation. Amobile node can also modify or deletesends a binding update it MUST refresh all flow bindings in a similar mannerit wants to that described earlier with the home agent and MAP. When Modifying amaintain even if it does not want to change any of their parameters. To refresh an existing flow binding,binding the mobile node MUST ensure thatsend 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 usedvalues already exists. The rest ofin the rules for modifyinglist of flow binding entries. Any flow bindings (active or inactive) that are the same as those listed above for addingnot included in a binding update will be removed from the list of flow binding. Refreshing and deletingbinding entries. Note that any inactive flow bindings, i.e., flow bindings without associated BIDs that are donemarked as Inactive in the same manner aslist 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. 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 describedincludes flow identification and flow summary options for all the home agentFIDs that need to be refreshed, modified, or added, and MAP with one exception: thesimply omits any FIDs that need to be removed. Note that a mobile node MUST NOT refresh or delete bindingscan also remove the BIDs associated with any care-of address other thana given Flow Binding, without removing the one includedflow binding itself. The procedure for removing a BID is defined in detail in [I-D.ietf-monami6-multiplecoa]. When all the BU message. 6.1.3. Using Alternate Care-Of Address IfBIDs associated with a flow binding are removed, the Alternate Care-of Address option is usedflow binding MUST be marked as inactive in the Binding Update, it shall indicatelist of flow binding entries as shown in Section 4.4. In other words the care-of address to bestate associated with the Flow Identification options. The Flow Identification options shall contain the FID toflow binding MUST be allocatedmaintained but it does no longer affect the mobile node's traffic. The MN can return an inactive flow binding to the Flow Binding. 6.1.4.active state by using the flow binding modification process described in Section 18.104.22.168, 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.binding updates. As such a mobile node receiving a Binding Acknowledgement in response to the transmission of a Binding Updatebinding update MUST determine if the Binding Acknowledgement contains a copy of the 8 bytes ofevery Flow Identificationflow identification options included in the Binding Update.binding update. A Binding Acknowledgement without Flow Identification option(s)flow identification option(s), in response to a Binding Update with flow identification option, would indicate inabillityinability (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 the 8 bytesof each flow identification option that was sent within the Binding Update,binding update, the status field of each flow identification option indicates the status of the flow binding on the distant node. 6.2. Movement When a MN changes its point of attachment to the Internet, its Care-of address(es) may become invalid and need to be updated. All the flow bindings that are attached to such an old Care-of address need to be udpated with a new Care-of address. This can be achieved by adding flow identification options in Binding Update. One flow identification is needed per flow binding. The flow description may not be needed if only the Care-of address is changed, and not the filter itself. The FID must be set to the flow binding that needs to be udpated and the PRO field MUST be set to 1 (i.e., MODIFY). Another solution is to take advantage of the multiple care-of addresses bindings to aggregate updates; the mobile node may only need to update the care-of address associated with the given BID. This would avoid to send a flow identification option per flow binding. 22.214.171.124.6. Return Routability Procedure A mobile node may perform route optimization with correpondent nodes.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 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 Updatebinding 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. 6.4. Returning Home Whenever a mobile node acquires a point of attachment to5.3. HA, MAP, and CN Considerations This specification allows the home networkagents, mobility anchor points, and wishescorresponding nodes to abolish all Flow Bindings associated with the respectivemaintain several bindings for a given home address, it is requiredaddress and to act as described in Section 11.5.4 of RFC3775 [RFC3775].direct packets to different care-of addresses according to flow bindings. This will causesection details the home agent operations necessary to remove all bindings thatimplement this specification. These operations are linked to the home address, including the flow bindings. 7. Applicability to Route Optimization Theidentical for MAPs and CNs unless otherwise stated. Note that route optimization is only defined for mobile nodes (RFC3775(MIPv6 [RFC3775]), and not mobile router (RFC3963routers (NEMOv6 [RFC3963]). Thus, this section does notthese sections only apply to mobile routers. This section describes the correspondent node operations. Everycorrespondent node is requirednodes with respect to maintain a Binding Cache containing records of associations betweenmobile node home addressesnodes and care-of addresses (bindings) as they roam away from the home network. RFC3775 [RFC3775] allowsnot for mobile nodes to register only a single binding per home addressrouters. 5.3.1. Receiving BU with each correspondent node.BID Options This specification extends the binding cache structure, and enables correspondent nodes to (i) maintain multiple bindings for a given home address and (ii) to associate multiple Flow Identification / description options with every binding, termed as Flow Binding. A flow matching a Flow Description should be directed to(see Section 4.1) updates the Care-of address indicated bydefinition of the Flow Binding. 7.1. Receiving Binding Udpate When a correspondant node receives aBinding Update, it first performs the same operation asIdentifier option, originally defined in RFC3775 [RFC3775]. If the Binding Update is valid and contains a Flow identification option, the correspondent node needs[I-D.ietf-monami6-multiplecoa]. According to check the content of the PRO field. Ifthis specification the PRO field contains a value indicating a request to addBID option includes a new flow binding, the following checks are done: * The FIDBID-PRI field includesassigning each registered care-of address a value thatpriority, 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 not already storedbecause BID Reference sub-options included in the flow identification options might refer to BIDs defined in BID options included in the binding update list with the correspondent node's address. *same message. The PRO fieldBID option is setprocessed as defined in [I-D.ietf-monami6-multiplecoa] but then the BID to indicatecare-of address mapping is placed in an Add operation. + The FID field needsordered list according to contain a value that does not already exist. If the FID contains a value that already exists,the correspondent node MUST rejectBID-PRI field of the option by sending that option back in its Binding AcknowledgementBID option. 5.3.2. Receiving BU with a Status field that contains an error value. + IfFlow Identification Options When the Action field indicateshome agent receives a request to n-castbinding update which includes at least one Flow Identification option, it first performs the flow,operation described in section 10.3.1 of RFC3775. Home agents that do not support this specification will ignore the correspondent node MUST rejectflow identification options and all their suboption, having no effect on the option by sendingoperation of the option in its binding acknowledgement with an appropriate error code. +rest of the protocol. If boththe FIDbinding update is accepted, and Action fields are valid,the correspondent nodehome agent is willing to support flow bindings for this MN, the home agent checks the flow description that must followidentification options. If more than one flow identification option in the same BU, has the same value in the FID field, all the flow identification option.options MUST be rejected. If all ofFID fields have different values the checks above indicated a valid option,flow identification options can be processed further and in any order, as defined by the correspondent node should addfollowing subsections. 126.96.36.199. Handling Flow Binding Add Requests If the PRO field of the flow binding to its binding cache. + The FID MUST includeidentification option is set to 'Add', it indicates a value that already exists.flow binding add request. If the FID cannot be foundfield of the flow identification option is already present in the correspondent node'slist of flow binding cache,entries for this mobile node, the home agent MUST reject this flow binding add request by copying the flow identification option MUST be rejected with an appropriate error code. + Ifin the ActionBA, and setting the Status field indicates a requestto n-cast135 (FID already in use). If the flow,flow identification option does not include a flow description sub-option, the correspondent nodehome agent MUST again reject the optionthis request by sendingcopying the flow identification option in its binding acknowledgement with an appropriate error code. + If the Binding Reference sub-option is present, the correspondent node MUST ensure thatthe BID points to the care-of address inBA, and setting the packet, orStatus field to an already authrozied care-of address. Otherwise the129 (Flow identification option MUST be rejected with an appropriate error code. +poorly formed). If all ofthe above checks returnedflow identification option does include a valid result,flow description sub-option, but the correspondent node should modifyflow description type is not supported, the binding as requested. Ifhome agent MUST also reject this request by copying the PRO fieldflow identification option in the option indicates a request to modifyBA, and setting the option,Status field to 137 (FD-Type not supported). If the following checks must be done byFID value is new the correspondent node: Ifhome agent MUST check the PROAction field in combination with the optionBinding Reference sub-option if present. - if the Action indicates 'Forward' If the Binding reference sub-option is not included or if it is included but it contains more than a request to refresh a binding,single BID, the correspondent nodehome agent MUST ensure thatreject this flow binding add request by copying the flow identification option in the FID already exists.BA, and setting the Status field to 129 (Flow identification option poorly formed). If the FID doesBinding Reference sub-option is present and includes a single BID, but the BID is not exist,present in the correspondentbinding cache of the mobile node the home agent MUST reject this flow binding add request by copying the flow identification option by sending it back in its binding acknowledgement with an appropriate error codein the status field. Otherwise, ifBA, and setting the FID exists,Status field to TBD (BID not known). If the correspondent node must keep itBinding Reference sub-option is present and includes a single BID, and the BID exists in itsthe mobile node's binding cache. No further checks need to be done incache, the option. The correspondent node should reply withhome 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 Acknowledgement message. This Binding Acknowlegement message must containReference sub-options that might be present SHOULD be ignored. The home agent SHOULD add a copy ofnew entry in the 8 bytesmobile node's list of eachflow 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 that was includedin the Binding Udpate. TheBA, and setting the Status field of each Flow Identification option MUST be setto an appropriate value. 8. Home Agent operations This specification allows129 (Flow identification option poorly formed). If the home agent to maintain several bindings for a given home addressBinding Reference sub-option is present and to direct packets to different care-of addresses according to flow bindings. This section detailsincludes BIDs that are not present in the binding cache of the mobile node the home agent operations necessary to implementMUST reject this specification. 8.1. Receiving Binding Update withflow binding add request by copying the Flow Identificationflow identification option Whenin the BA, and setting the Status field to TBD (BID not known). If the home agent receives aBinding Update whichReference sub-option is present and includes at leastone Flow Identification option, it first performsor more BIDs, and the operation describedBIDs exist in section 10.3.1 of RFC3775. Ifthe Binding Update is accepted,mobile node's binding cache, the home agent then checksSHOULD add a new entry in the mobile node's list of flow identification option. Ifbinding entries, as defined below. When the PRO fieldhome agent decides to add an entry in the option indicates an Add operation,mobile node's list of flow binding entries, as discussed above, it MUST do it according to the following checks must be done: *rules: The FID field needsentry MUST be placed according to contain a value that does not already exist. Ifthe order indicated by the FID-PRI field of the flow identification option and it MUST include: the FID containsas a value that already exists,key to the home agententry 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 rejectbe marked as Active, as shown in Section 4.4 188.8.131.52. Handling flow binding Modification Requests If the PRO field of the flow identification option by sending that option back in its Binding acknowledgement withis set to 'Modify', it indicates a Status fieldflow binding modification request. Note that containsflow binding modification is essentially a process where an appropriate error value. * Ifexisting flow binding is removed from the list of flow binding entries and a new flow binding (included in the FID fieldoption) is valid,added, and given the home agent then checkssame FID as the Action field.flow that was removed. If the Actionvalue of the FID field contains a request for n-cast andof the Binding Reference sub-optionflow identification option is not included in the option, the flow binding MUST be rejectedpresent in the binding acknowledgement containing an error code in the Status field. * If both of the checks above indicate valid FID and Action fields,cache entries for this mobile node, the home agent checks theMUST reject this flow description followingbinding modify request by copying the flow identification option,option in the BA, and identifiessetting the filter that needsStatus field to be set up. *135 (FID not found). If the flow option includes an action field that requests n-casting,value of the home agent MUST check forFID field is present in the presencemobile nodes list of flow binding entries, the BID sub-option(s). Ifhome agent SHOULD first remove the sub-options are not present,flow binding entry identified by the FID. The home agent then SHOULD processes this flow identification option MUST be rejectedas a poorly formatted option. If one or more BIDs are presentdefined in the BID Reference sub-option,Section 184.108.40.206. 5.3.3. Receiving BU with Flow Summary Option When the home agent needs to create multiple logical entries in itsreceives a binding cache. All flows matchingupdate which includes a Flow Summary option, it first performs the oneoperation described in thesection 10.3.1 of RFC3775. Binding update messages including more than one flow summary option wouldMUST be n-cast to the care-of addresses pointed to byrejected. Home agents that do not support this specification will ignore the BIDs orflow summary option, having no effect on the setoperation of the rest of registered care-of addresses. If only one BID were included inthe Binding Reference sub-option and it pointed to a different care-of address fromprotocol. If the onevalue of any of the FID fields included in the packet, then packets matching theflow would be bicast to those two addresses. However, if only one BIDsummary option is not present and points to the same addressin the BU, the n-cast is essentially pointing to one address and therefore cannot be performed. Such option MAY be rejected as a poorly formatted option. * If alllist of the checks above indicated a valid option,flow binding entries for this mobile node, the home agent should add theMUST reject this flow binding to its binding cache. Ifmodify request by including a flow identification option in the PROBA, and setting the FID field in the option contains avalue indicating a request to modify an existing binding,of the following actions must be taken: * TheFID MUST include a valuethat already exists. If the FID cannot beis not found in the home agent's binding cache,and the flow identification option MUST be rejected as a poorly formed option. *Status field to 135 (FID not found). If the value of the FID field is valid,present in the mobile nodes list of slow binding entries the, home agent MUST perform the same steps described above for the Add operation. If the PRO field indicates aSHOULD refresh operation,the home agent MUST ensure thatbinding entry identified by the FID in the option already exists. Ifwithout 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 field didfrom a binding update. When a valid binding update is received, any registered FIDs that are not exist, theexplicitly referred to in a flow identification option MUST be rejected asor in a poorly formed option. If the FID existed, the home agentflow summary option, MUST keepbe removed from the currentlist of flow binding in its binding cache. 8.2.entries for the mobile node. 5.3.5. Sending Binding AckowledgementAcknowledgements Upon the reception of a Binding Update,binding update, the home agent is required to send back a Binding Acknowledgment. The status code in the Binding Acknowledgement must be set as recommanded in [RFC3775] and is not modified by the extension definedrecommended in this specification.[RFC3775]. This status code does not give information on the success or failure of theflow binding.bindings. In order to inform the mobile node about the status of the flow binding that wasbinding(s) requested by a mobile node, aflow identification optionoptions MUST be setincluded in the Binding Acknowledgement message. TheSpecifically, the home agent mustMUST copy the 8 octets ofeach Flow Identificationflow identification option received in the Binding Updatebinding update and set theits status code to an approriateappropriate value. Each option must be included in the Binding Acknowledgement message. 8.3. DeletingIf an entryoperation requested in a flow identification option by a mobile node is performed successfully by the binding cache Ahome agent might delete an entry in its binding cache for two reasons: either an entry expires, oragent, the MN explicitly requestsstatus field on the home agent to remove a specific entry. If an entry is going to expire,copied flow identification option in the home agentBA, SHOULD send a Binding Refresh Advice. 8.3.1. Removing Flow Bindings Ifbe set to 0 (Flow binding successful), otherwise it SHOULD be set to one of the home agent receives a valid Binding Update withrejection codes defined. Section 5.3.2 identifies a flow Identification optionnumber of cases where specific error codes should be used. Home agents that support this specification MAY refuse to maintain flow bindings by setting the PROstatus field is setof any flow identification options to 15 (Remove), the home agent MUST remove130 (Administratively prohibited), or by just ignoring all the corresponding entry. The home agent looks upflow binding options. Note that BID options and their Status field are handled as defined in [I-D.ietf-monami6-multiplecoa]. 5.3.6. Packet Processing This section defines packet processing rules according to this specification. This specification does not change any of the entry correspondingpacket interception rules defined in [RFC3775], and [I-D.ietf-mext-nemo-v4traversal]. These rules apply to HAs, MAPs, and CNs, as part of the FIDrouting process for any packet with destination address set to a valid home address of the Binding Update. Ifmobile node. For nodes other than CNs this also applies to packets with destination address set to an entry is found, the entry is removed fromaddress under any of the Binding cache andregistered prefixes. These rules apply equally to IPv6 packets as well as to IPv4 packets when [I-D.ietf-mext-nemo-v4traversal]. Before a Binding Acknowledgementpacket is sent backforwarded to the mobile node with a success value forit MUST be matched against the statusordered list of theflow Identification option (see section Section 8.2. This operation does not modify any other binding that may appear with the same home address. If the FID is not presentbindings stored in the list of flow binding cache entryentries for the corresponding home address, the home agent MUST send back to thethis mobile node a Binding Acknowledgement(see Section 4.4). A match is attempted with error code 137 (FID not found) inthe flow identification option. 9. Applicability to Hierarchical Mobile IPv6 This section describesdescription included in the Mobility Anchor Point (MAP) operations. The MAP operation isfirst line (highest order) of the same astable. If the home agent operation. Flow bindings sent topacket matches the MAP are associated withflow description, the regional care-of address. When a MAP receives a Binding Update that includesaction defined by the flow Identification option, it checksaction parameter of the table SHOULD be performed. - if such optionthe Action indicates 'Forward' the packet is valid accordingforwarded to the requirementscare-of address indicated by the BID parameter in Section 8.1. Ifthe optionsame line of the table. - if the Action indicates 'Discard', the packet is valid,silently discarded - if the MAP installsAction indicates 'n-cast', a copy of the flow bindingpacket is forwarded to each of the care-of addresses associated with the flow identified byBIDs indicated in the flow description. The lifetimesame line of the binding istable. If the lifetimeaction indicated in one of the Binding Update. Onceentries in the bindinglist of flow bindings is successfully installed,"Discard" then, no BIDs needs to be indicated in the MAP sendssame entry since the binding acknowledgement and includespacket is not forwarded. If, however, the action indicated in an entry of the list of flow Identification option. The MAP setsbindings is "forward" or "n-cast", the status fieldentry must indicated a BID. For "n-cast" if any of the BIDs indicated does not correspond to a value indicating success.valid care-of address, e.g., the BID was deregistered then that BID has no effect on the traffic. In all cases, aother words, packets matching the flow identification option SHOULD be included inbinding are n-casted to the Binding Acknowledgementother BIDs, pointing to indicate success or failureregistered care-of addresses. If none of the BIDs pointed to in a flow binding installation. 10.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. 6. Security considerations This draft introduces a new option that adds more granularity to the Binding Updatebinding update message. The new option allows the mobile node to associate some flows to anone interface and other flows to another interface. Since the flowflow 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. 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 option is partMobility 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 mobility header, it usesvalues below 128 are reserved for accept codes, and values from 128 and above are reserved for reject codes. Similar to the same security asprocedures specified for Mobile IPv6 [RFC3775] number spaces, future allocations from the Binding Update, whether it is senttwo number spaces require Expert Review [RFC5226]. 8. Contributors We would like to explicitly acknowledge the home agent, correspondent node, or MAP. 11.following person who co- authored one of the documents used as source material for this document. Nikolaus A. Fikouras, firstname.lastname@example.org 9. Acknowledgements We would also like to thank all authors of initial I-Ds that were merged together to create this document;acknowledge the following people in alphabetical order: C. Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N. Pavlidou. Thanks to George Tsirtsis and Vince Park for their thorough review and input to the draft.Pavlidou, V. Park. Gabor Fekete for the analysis that led to the inclusion of the BID support.BIDRef sub-option. Henrik Levkowetz for suggesting the equivalent of the CLS field to allowsupport for other ways of describing flows. 12. Informative10. References [I-D.ietf-nemo-terminology] Ernst, T. and H. Lach, "Network Mobility10.1. Normative References [I-D.ietf-mext-nemo-v4traversal] Soliman, H., "Mobile IPv6 Support Terminology", draft-ietf-nemo-terminology-06for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-10 (work in progress), November 2006. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2702] "", 2005. [RFC3753] Manner, J.April 2009. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and M. Kojo, "Mobility Related Terminology",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 3753, June 2004.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. [RFC4140] "RF", 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. Authors' Addresses Hesham Soliman (editor)Elevate Technologies Email: email@example.com George Qualcomm Email: firstname.lastname@example.org Nicolas Montavont Ecole Nationale Superieure des telecommunications deInstitut Telecom / Telecom Bretagne 2, rue de la chataigneraie Cesson Sevigne 35576 France Phone: (+33) 2 99 12 70 23 Email: email@example.com@telecom-bretagne.eu URI: http://www-r2.u-strasbg.fr/~montavont/ Nikolaus A. Fikouras 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-3601http://www.rennes.enst-bretagne.fr/~nmontavo// Gerardo Qualcomm Email: firstname.lastname@example.org URI: http://email@example.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: firstname.lastname@example.org URI: http://www.comnets.uni-bremen.de/~koo/