idnits 2.17.1 draft-ietf-mext-flow-binding-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5400 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-13 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MEXT Working Group H. Soliman 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track G. Tsirtsis 5 Expires: January 14, 2010 Qualcomm 6 N. Montavont 7 IT/TB 8 G. Giaretta 9 Qualcomm 10 K. Kuladinithi 11 University of Bremen 12 July 13, 2009 14 Flow Bindings in Mobile IPv6 and NEMO Basic Support 15 draft-ietf-mext-flow-binding-03.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 14, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document introduces extensions to Mobile IPv6 that allow nodes 54 to bind one or more flows to a care-of address. These extensions 55 allow multihomed nodes to instruct home agents and other Mobile IPv6 56 entities to direct inbound flows to specific addresses. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Definition Update for Binding Identifier Mobility 65 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 67 4.2.1. Binding Reference Sub-option . . . . . . . . . . . . . 11 68 4.2.2. Flow Description Sub-option . . . . . . . . . . . . . 12 69 4.3. Flow Identification Summary Mobility Option . . . . . . . 12 70 4.4. Flow Bindings entries list and its relationship to 71 Binding Cache . . . . . . . . . . . . . . . . . . . . . . 13 72 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 16 73 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 16 75 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 16 76 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 17 77 5.2.2. Sending BU with Flow Identification Options . . . . . 17 78 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 19 79 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 19 80 5.2.5. Receiving Binding Acknowledgements . . . . . . . . . . 20 81 5.2.6. Return Routability Procedure . . . . . . . . . . . . . 20 82 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 21 83 5.3.1. Receiving BU with BID Options . . . . . . . . . . . . 21 84 5.3.2. Receiving BU with Flow Identification Options . . . . 21 85 5.3.3. Receiving BU with Flow Summary Option . . . . . . . . 24 86 5.3.4. Handling flow binding Removals . . . . . . . . . . . . 24 87 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 25 88 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 25 89 6. Security considerations . . . . . . . . . . . . . . . . . . . 27 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 91 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 98 1. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Introduction 106 Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and 107 NEMO Basic Support [RFC3963] allow a mobile node / mobile router to 108 manage its mobility using the binding update message, which binds one 109 care-of address to one home address. The binding update message can 110 be sent to the home agent. In Mobile IPv6, the binding update can 111 also be sent to correspondent node or to a mobility anchor point (see 112 [RFC5380]). The semantics of the binding update are limited to 113 care-of address changes. That is, [RFC3775], 114 [I-D.ietf-mext-nemo-v4traversal], and [RFC3963] do not allow a mobile 115 node / mobile router to bind more than one address to the home 116 address. In [I-D.ietf-monami6-multiplecoa] Mobile IPv6 and NEMO 117 Basic Support are extended to allow the binding of more than one 118 care-of address to a home address. This specification further 119 extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow it to 120 specify policies associated with each binding. A policy can contain 121 a request for a special treatment of a particular IPv4 or IPv6 flow, 122 which is viewed as a group of packets matching a flow descriptor. 123 Hence, this specification allows a mobile node / mobile router to 124 bind a particular flow to a care-of address without affecting other 125 flows using the same home address. In addition, this specification 126 allows to bind a particular flow to a particular care-of address 127 directly with correspondent node and mobility anchor point. 129 In this document, a flow is defined as a set of IP packets matching a 130 flow descriptor. A flow descriptor can identify the source and 131 destination IP addresses, transport protocol number, the source and 132 destination port numbers and other fields in IP and higher layer 133 headers. This specification, however, does not define flow 134 descriptors and it is assumed that one or more ways of defining flow 135 descriptors are going to be defined in other specifications. This 136 specification, however, does define the sub-option extension format 137 to be used for any defined flows descriptors. 139 Using the flow identifier option introduced in this specification a 140 mobile node / mobile router can bind one or more flows to a care-of 141 address while maintaining the reception of other flows on another 142 care-of address. Requesting the flow binding can be decided based on 143 local policies within the mobile node / mobile router and based on 144 the link characteristics and the types of applications running at the 145 time. Such policies are outside the scope of this document. 147 It should be noted that the flow identification option can be 148 associated with any binding update, whether it is sent to a home 149 agent, correspondent node (in the case of Mobile IPv6), or mobility 150 anchor point (in the case of Hierarchical Mobile IPv6). 152 Note that per-packet load balancing may have negative impacts on TCP 153 congestion avoidance mechanisms as it is desirable to maintain order 154 between packets belonging to the same TCP connection. This behaviour 155 is specified in [RFC2702]. Other negative impacts are also 156 foreseen for other types of real time connections due to the 157 potential variations in RTT between packets. Moreover, per-packet 158 load-balancing will negatively affect traffic with ant-replay 159 protection mechanisms. Hence, per-packet load balancing is not 160 currently supported in this extension. 162 In the rest of the document, the term "mobile node" is used to 163 designate either a mobile node as defined in [RFC3775] or a mobile 164 router as defined in [RFC3963] unless stated otherwise. 166 3. Terminology 168 Terms used in this document are defined in [RFC3753] and [RFC4885]. 169 The following terms are also used in this document: 171 Flow: A flow is identified as a set of data packets that are 172 exchanged between two nodes and match a given flow description 174 Flow Description: Information that identifies one or more IP 175 packets. The identification can use the source address, 176 destination port, protocol number, DSCP value, or other 177 information from the packet with predefined values. 179 Flow Identifier: An unsigned integer. 181 Flow binding: A triplet consisting of a flow identifier, a flow 182 descriptor, and an action. An IP packet that matches the triplet 183 will be processed according to the action. 185 4. Mobile IPv6 Extensions 187 This section introduces extensions to Mobile IPv6 that are necessary 188 for supporting the flow binding mechanism described in this document. 190 4.1. Definition Update for Binding Identifier Mobility Option 192 This specification updates the definition of the Binding Identifier 193 Mobility option defined in [I-D.ietf-monami6-multiplecoa], as 194 follows: 196 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type = TBD | Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Binding ID (BID) | Status |H| BID-PRI | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 203 + + 204 : IPv4 or IPv6 care-of address (CoA) : 205 + + 206 +---------------------------------------------------------------+ 208 Figure 1: The Binding Identifier Mobility option 210 BID-PRI 212 This is a 7-bit unsigned integer placing each BID to a relative 213 priority with other registered BIDs. Value "0" is reserved. A 214 lower number in this field indicates higher priority, while 215 BIDs with the same BID-PRI value have equal priority. This is 216 consistent with current practice in packet classifiers. 218 4.2. Flow Identification Mobility Option 220 The Flow identification mobility option is included in the binding 221 update and acknowledgement messages. This option contains 222 information that allows the receiver of a binding update to install 223 policies on a traffic flow and route it to a given care-of address. 224 Multiple options may exist within the same binding update message. 225 The alignment requirement for this option is 4n. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Option Type | Option Len | FID | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | FID-PRI | Action | Rsvd | Status | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: The flow identification mobility option 237 Option Type 239 TBD 241 Option Len 243 Length of option, including any sub-options, in 8-octet units 245 FID 247 The Flow Identifier field is an 16-bit unsigned integer that 248 includes the identifier for the flow binding. This field is 249 used to refer to an existing binding or to create a new 250 binding. The value of this field is set by the mobile node. 251 FID = 0 is reserved and MUST NOT be used. 253 FID-PRI 255 This is an unsigned 8-bit priority field to indicate the 256 priority of a particular option. This field is needed in cases 257 where two different flow descriptions in two different options 258 overlap. The priority field decides which policy should be in 259 those cases. A lower number in this field indicates a higher 260 priority. 262 Action 264 This field specifies the action that needs to be taken by the 265 receiver of the binding update containing the flow 266 identification option. The details of these requests are 267 discussed below. 269 Rsvd 271 This field is unused. It MUST be set to zero by the sender and 272 MUST be ignored by the receiver. 274 Status 276 This field indicates the success or failure of the flow binding 277 operation for the particular flow in the option. This field is 278 not relevant to the binding update message as a whole or to 279 other flow identification options. Values from 0 to 127 280 indicate success. Values of 128 and higher indicate failure. 281 This field is only relevant when included in the Binding 282 Acknowledgement message and must be ignored in the binding 283 update message. 285 The following values are reserved for the Action field in this 286 option: 288 1 Discard. This value indicates a request to discard all packets 289 in the flow described by the option. No BIDs are associated with 290 this Action. 292 2 n-cast. This value indicates a request to send the flow to one 293 or more addresses indicated in the Binding Reference sub-option. 294 One or more BIDs MUST be associated with this Action. If only one 295 BID is associated with this action then it is essentially a 296 request to forward packets to that CoA. Care should be taken when 297 the n-cast action is used as some transport layers may not be able 298 to handle packet duplication and this can affect their 299 performance. 301 The following values are reserved for the status field within the 302 flow identification option: 304 0 Flow binding successful. 306 128 Flow binding rejected, reason unspecified. 308 129 Flow identification option malformed. 310 130 Administratively prohibited. 312 135 FID already in use 314 136 FID not found 316 137 FD-Type not supported. 318 138 Discard function not supported. 320 139 N-cast function not supported. 322 A number of sub-options can follow the option defined in this 323 section. These are defined below. 325 4.2.1. Binding Reference Sub-option 327 This section introduces the Binding Reference sub-option, which may 328 be included in the Flow identification option. The Binding Reference 329 sub-option includes one or more BIDs defined in MCoA 330 [I-D.ietf-monami6-multiplecoa]. When this sub-option is included in 331 the Flow identification option it associates the flow described with 332 one or more registered BIDs. 334 When binding a flow using this sub-option, the binding identifier 335 option, defined in [I-D.ietf-monami6-multiplecoa], MUST be defined in 336 either the same or an earlier BU. The Binding Reference sub-option 337 is shown below. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |Sub-opt Type | Sub-Opt Len | BID | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | BID ........ 345 +-+-+-+-+-+-+-+-+-+- 347 Figure 3: The Binding Reference sub-option 349 Sub-opt Type 351 Indicates the Sub-option type. For the Binding Reference sub- 352 option, this field MUST be set to 1. 354 Sub-opt Len 356 Indicates the sub-option length in octets. This field includes 357 the entire length of the sub-option including the Sub-opt Type 358 and Sub-opt-Len fields. 360 BID 362 The BID that the mobile node wants to associate with the flow 363 identification option. One or more BID fields can be included 364 in this sub-option. Since each BID is 2 byte long, the value 365 of the Sub-opt Len field indicates the number of BIDs present. 366 Number of BIDs = (Sub-opt Len-2)/2. 368 4.2.2. Flow Description Sub-option 370 The Flow description sub-option(s) include the parameters used to 371 match packets for a specific flow binding. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 |Sub-opt Type | Sub-Opt Len | Flow Description ... 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 4: The Flow Description sub-option 381 Sub-opt Type 383 Indicates the Sub-option type. For the flow description sub- 384 option, this field SHOULD be set to one of the FD types defined 385 below. 387 Sub-opt Len 389 Indicates the sub-option length in octets. This field includes 390 the entire length of the sub-option including the Sub-opt Type 391 and Sub-opt-Len fields. 393 Flow Description 395 The flow description corresponding to the type indicated by the 396 Sub-opt Type field. Flow description is out of scope of this 397 document. 399 The following values are reserved for the sub-option Type values are 400 defined for Flow Description: 402 17-32 reserved for Flow Description formats. 404 4.3. Flow Identification Summary Mobility Option 406 The Flow Identification Summary Mobility option includes one or more 407 flow identifiers (FIDs) for the purpose of refresing their state 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Option Type | Option Len | FID | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | FID ........ 414 +-+-+-+-+-+-+-+-+-+- 416 Figure 5: The Flow Identification Summary Option 418 Option Type 420 TBD 422 Option Length 424 Length of option, including any sub-options, in 8-octet units 426 FID 428 A registered FID. One or more FID fields can be included in 429 this option. Since each FID is 2 bytes long, the value of the 430 Option Len field indicates the number of FIDs present. 432 4.4. Flow Bindings entries list and its relationship to Binding Cache 434 The conceptual mobile IPv6 binding cache was defined in [RFC3775] to 435 identify the mobile IP state maintained by the mobile node, home 436 agent, and corresponding node. The binding cache includes, between 437 others, the mobile node's home address, the registered care-of 438 address, and the lifetime of the binding. The binding cache was then 439 extended by [I-D.ietf-monami6-multiplecoa] to include more than one 440 care-of addresses and to associate each of them with a Binding 441 Identifier (BID). 443 This specification does not modify the mobile IPv6 binding cache any 444 further. 446 Flow bindings can be thought of as a conceptual list of entries that 447 is separate from the binding cache. The flow bindings list contains 448 an entry for each of the registered flow binding. Flow binding 449 entries can point to an entry in the binding cache by means of the 450 BID. Each flow binding entry include the following parameters : 452 * FID (Flow Identifier): For a given mobile node, identified by 453 its primary home address, the FID MUST uniquely identify an 454 entry, i.e. a unique flow binding. Each mobile node can only 455 have a single entry identified by a given FID at any one time. 456 Different mobile nodes can use the same FID number space. 458 * A Flow Descriptor: Included in a Flow Description sub-option. 460 * BID(s): The list of BIDs associated with the entry as defined 461 by the Binding Reference sub-option included in the FID option 462 that created it. 464 * Action: The action associated with a given entry as defined by 465 the Action field of the FID option that created it 467 * Active/Inactive flag: This flag indicates whether the entry is 468 active or inactive. 470 * FID-PRI: This field indicates the priority of the flow and is 471 used to break the tie between overlapping flows. 473 The flow bindings list is associated with a given mobile node, and 474 the corresponding binding cache. An entry in the flow bindings list, 475 however, is identified by the FID and the list is ordered according 476 to the FID-PRI field as defined in the FID option that created each 477 entry. 479 A valid BID is required to make the entry "active". If all of the 480 BIDs pointed to by a given entry are not valid BIDs in the binding 481 cache, the flow binding entry becomes "inactive", in other words it 482 does not affect data traffic. Note that if the action parameter in 483 an entry indicates "n-cast" then the entry becomes inactive only if 484 none of the BIDs is valid. If only some of the BIDs are valid, the 485 invalid BIDs are simply ignored. 487 Also note that the state described in this section is maintained by 488 the mobile node as well as in mobility agents and corresponding 489 nodes. As such the mobile node is fully aware of which are the valid 490 BIDs at any time and which flow binding entries are active/inactive. 491 Section 5 defines how these flow binding entries are manipulated by 492 the mobile node in detail. 494 As an example the following represents an ordered flow bindings 495 entries table for a mobile node that has registered multiple care-of 496 addresses and flow bindings. 498 FID-PRI FID Flow Description BIDs Action A/I 499 ------- --- ---------------- ---- ------- ------ 500 10 4 TCP 2 Forward Active 501 20 3 srcAddr=IPx N/A Discard Active 502 30 2 srcAddr=IPy 4 Forward Inactive 503 40 5 UDP 1,3 N-Cast Active 505 Ordered Flow Binding Entries 507 According to the above list of flow binding entries, all TCP traffic 508 will match the first entry, and according to the Action indicated it 509 will be forwarded to BID2, corresponding to a given care-of address 510 (IP3), as shown below. Any traffic that is not TCP, but has as 511 source address IPx will match the second entry, and according to the 512 associated Action it will be discarded. Note that any TCP traffic 513 with source address IPx will match the first entry and thus it will 514 be forwarded as per that entry. 516 The third entry is marked as Inactive since the BID 4 does not exist 517 in the ordered list of BID entries below. Inactive entries do not 518 affect traffic, i.e., packets are not matched against them. 520 Any UDP traffic that does not match any of the earlier entries will 521 match the third rule and according to the Action indicated it will be 522 replicated and forwarded to BIDs 1 and 3, corresponding to care-of 523 addresses IP1 and IP2 shown below. 525 Finally any remaining packets that do not match any of the entries 526 above will be simply forwarded to the care-of address indicated by 527 the highest order BID in the table below. In the example, such 528 packets will be forwarded to BID 1, corresponding to care-of address 529 IP1. 531 BID-PRI BID CoA 532 --------- --- --- 533 20 1 IP1 534 30 3 IP2 535 30 2 IP3 537 Ordered BID Entries 539 5. Protocol operations 541 5.1. General 543 This specification introduces a flow bindings list of entries and an 544 ordered list of binding identifiers, allowing mobile nodes to 545 associate flow binding policies with the registered care-of 546 addresses. 548 The flow identification option defines how the mobile node can 549 control a set of flow binding entries maintained in a home agent, 550 correspondent node, or mobility anchor points, on its behalf. The 551 fields of the flow identification option are necessary for ordering 552 flow identification options, indicating the sort of action that 553 should be undertaken to the recipient's flow binding list of entries 554 or for carrying the results of such a petition. 556 This specification allows mobile nodes to direct flows to a 557 particular care-of address. The granularity of what constitutes a 558 flow depends on the flow descriptor used. As indicated earlier the 559 flow description itself is defined in another document. 561 The remaining of this section discusses how mobile nodes can use the 562 options and sub-options defined in this document when sending binding 563 updates to the correspondent node, home agent or mobility anchor 564 point. In addition, refresh, deletion, and modification of bindings 565 are all discussed below. 567 5.1.1. Preferred Care-of address 569 Any node that supports this specification MUST maintain an ordered 570 list of care-of addresses for each mobile node it maintains a list of 571 flow bindings for. The ordered list of care-of addresses is built 572 based on the BID-PRI field of the Binding Identifier option (see 573 Section 4.1). 575 The ordered list of BIDs is used to determine how to forward a packet 576 to a given mobile node when the packet does not match any of the flow 577 binding entries defined in Section 4.4. A packet that does not match 578 any of the flow binding entries SHOULD be forwarded to the care-of 579 address identified by the BID with the highest priority i.e., lowest 580 BID-PRI value. 582 5.2. Mobile Node Considerations 584 This specification allows the mobile node to maintain several 585 bindings with its home agent, MAP and correspondent nodes and to 586 direct packets to different care-of addresses according to flow 587 bindings. This section details the mobile node operations necessary 588 to implement this specification. 590 The home agent list of flow bindings is manipulated by the mobile 591 node, via flow identification and flow summary options included in 592 binding update messages. Each flow binding update can add, modify, 593 refresh, or delete a given binding. More than one flow 594 identification options MAY be included in the same binding update but 595 each of them MUST include a different FID. In other words, two flow 596 identification options in the same message can not be about the same 597 flow binding. 599 All flow binding state MUST be refreshed in every binding update the 600 mobile node sends. Any previously registered flow binding that is 601 not included in a given binding update will be deleted. So, any flow 602 bindings that are not added or modified by a flow identification 603 option, but have previously registered and need to be maintained MUST 604 be included in a flow summary option. Only one flow summary option 605 can be included in a given binding update. 607 5.2.1. Sending BU with BID Options 609 This specification (see Section 4.1) updates the definition of the 610 Binding Identifier option, originally defined in 611 [I-D.ietf-monami6-multiplecoa]. According to this specification the 612 BID option includes a BID-PRI field assigning each registered care-of 613 address a priority, and thus placing them in an ordered list as also 614 described in Section 4.4. 616 Mobile nodes supporting this specification MUST use the BID option 617 format defined in Section 4.1. Mobiles nodes MUST also register all 618 care-of addresses using the updated BID option format, either in the 619 same BU as any flow identification options using them, or in earlier 620 BUs. 622 5.2.2. Sending BU with Flow Identification Options 624 5.2.2.1. Adding flow bindings 626 When adding a new flow binding, a mobile node sends the flow 627 identification option in the binding update. The care-of address 628 concerned with each flow identification option in the binding update, 629 must be logically registered by this binding update, or must have 630 already been registered by the receiver of the binding update in an 631 earlier binding update , as defined in Section 5.2.1. 633 The flow identification option MUST include a unique Flow Identifier 634 in the FID field. The FID needs only be unique for the receiver of 635 the binding update and for the same sender, i.e. the same FID can be 636 used across different receivers of the binding update, for the same 637 sender. 639 The FID-PRI field is set to the desired unique priority of the 640 FID, defining the order of the binding to be added in the list of 641 flow binding entries as defined in Section 4.4. 643 The Action field is set to one of the defined action codes (see 644 Section 4.2). 646 The Status filed is set to zero in all binding update messages. 648 The mobile node MUST include exactly one Flow Description sub-option 649 (see Section 4.2.2) describing the flow associated with the new 650 binding. 652 The mobile node MAY also include exactly one BID Reference sub-option 653 (see Section 4.2.1) to associate the flow binding with a given set of 654 BIDs and corresponding CoAs. Depending on the Action field of the 655 Flow Binding Identifier option, the following rules MUST be followed 656 with respect to the Binding Reference sub-option: 658 - if the Action indicates 'Discard', the Binding Reference sub- 659 option SHOULD NOT be included. If it is included it will be 660 ignored by the receiver. 662 - if the Action indicates 'n-cast', a single Binding Reference 663 sub-option with one or more BIDs MUST be included. 665 5.2.2.2. Modifying flow bindings 667 Flow binding modification is essentially a process where an existing 668 flow binding is removed from the list of flow binding entries and a 669 new flow binding (included in the option) is added, and given the 670 same FID as the flow that was removed. With this procedure the 671 mobile node can change the action, the priority, the BID, or the flow 672 description associated with a flow binding. 674 To modify an existing flow binding the mobile node MUST send a 675 binding update with a flow identification option, with the FID field 676 set to one of the FID values already in the list of flow binding 677 entries. 679 The FID-PRI and Action fields MUST be set to the unique desired 680 value to be implemented with this modification. 682 The Status field is set to zero since this option is in a binding 683 update. 685 The mobile node MAY include exactly one Flow Description sub-option 686 (see Section 4.2.2) describing the modified flow to be associated 687 with the binding. 689 The mobile node MAY also include exactly one BID Reference sub-option 690 (see Section 4.2.1) to associate the existing binding with a new set 691 of CoAs. The rules regarding the Binding Reference sub-option in 692 this case are identical to those described from flow binding addition 693 in Section 5.2.2.1 . 695 Note that it is also possible for the mobile node to effectively 696 modify the effect of a flow binding entry without actually changing 697 the entry itself. This can be done by changing the CoA associated 698 with a given BID, which is a process defined in detail in 699 [I-D.ietf-monami6-multiplecoa]. 701 5.2.3. Sending BU with a Flow Summary Option 703 When the mobile node sends a binding update it MUST refresh all flow 704 bindings it wants to maintain even if it does not want to change any 705 of their parameters. 707 To refresh an existing flow binding the mobile node MUST send a 708 binding update with a flow summary option. The flow summary option 709 MUST include one or more FID fields as indicated in Section 4.3. 710 Each FID field included MUST be set to one of the FID values already 711 in the list of flow binding entries. 713 Any flow bindings (active or inactive) that are not included in a 714 binding update will be removed from the list of flow binding entries. 716 Note that any inactive flow bindings, i.e., flow bindings without 717 associated BIDs that are marked as Inactive in the list of flow 718 binding entries (see Section 4.4), MUST also be refreshed, or 719 modified, to be maintained. If they are not included in a BU they 720 will be removed. 722 5.2.4. Removing flow bindings 724 Removal of flow binging entries is performed implicitly by omission 725 of a given FID from a binding update. 727 To remove a flow binding the MN simply sends a binding update that 728 includes flow identification and flow summary options for all the 729 FIDs that need to be refreshed, modified, or added, and simply omits 730 any FIDs that need to be removed. 732 Note that a mobile node can also remove the BIDs associated with a 733 given Flow Binding, without removing the flow binding itself. The 734 procedure for removing a BID is defined in detail in 735 [I-D.ietf-monami6-multiplecoa]. 737 When all the BIDs associated with a flow binding are removed, the 738 flow binding MUST be marked as inactive in the list of flow binding 739 entries as shown in Section 4.4. In other words the state associated 740 with the flow binding MUST be maintained but it does no longer affect 741 the mobile node's traffic. The MN can return an inactive flow 742 binding to the active state by using the flow binding modification 743 process described in Section 5.2.2.2, to associate it again with one 744 or more valid BIDs. 746 5.2.5. Receiving Binding Acknowledgements 748 According to [RFC3775] all nodes are required to silently ignore 749 mobility options not understood while processing binding updates. As 750 such a mobile node receiving a Binding Acknowledgement in response to 751 the transmission of a binding update MUST determine if the Binding 752 Acknowledgement contains a copy of every flow identification options 753 included in the binding update. A Binding Acknowledgement without 754 flow identification option(s), in response to a Binding Update with 755 flow identification option, would indicate inability (or 756 unwillingness) on behalf of the source node to support the extensions 757 presented in this document. 759 If a received Binding Acknowledgement contains a copy of each flow 760 identification option that was sent within the binding update, the 761 status field of each flow identification option indicates the status 762 of the flow binding on the distant node. 764 5.2.6. Return Routability Procedure 766 A mobile node may perform route optimization with correspondent nodes 767 as defined in [RFC3775]. Route optimization allows a mobile node to 768 bind a care-of address to a home address in order to allow the 769 correspondent node to direct the traffic to the current location of 770 the mobile node. Before sending a Binding Update to correspondent 771 node, the Return Routability Procedure needs to be performed between 772 the mobile node and the correspondent node. 774 This procedure is not affected by the extensions defined in this 775 document. However, since a binding update message is secured with 776 the key generated based on the home address and care-of address test, 777 a mobile node MUST NOT bind a flow to a care-of address whose keygen 778 token (see RFC3775 [RFC3775]) was not used to generate the key for 779 securing the Binding Update. This limitation prohibits the sender 780 from requesting the n-cast action for multiple addresses before 781 having registered each care-of address one by one. 783 5.3. HA, MAP, and CN Considerations 785 This specification allows the home agents, mobility anchor points, 786 and corresponding nodes to maintain several bindings for a given home 787 address and to direct packets to different care-of addresses 788 according to flow bindings. This section details the home agent 789 operations necessary to implement this specification. These 790 operations are identical for MAPs and CNs unless otherwise stated. 792 Note that route optimization is only defined for mobile nodes (MIPv6 793 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these 794 sections only apply to correspondent nodes with respect to mobile 795 nodes and not for mobile routers. 797 5.3.1. Receiving BU with BID Options 799 This specification (see Section 4.1) updates the definition of the 800 Binding Identifier option, originally defined in 801 [I-D.ietf-monami6-multiplecoa]. According to this specification the 802 BID option includes a BID-PRI field assigning each registered care-of 803 address a priority, and thus placing them in an ordered list (see 804 Section 4.4). 806 Home agents receiving BUs including BID options and flow 807 identification options MUST logically process BID options first. 808 This is because BID Reference sub-options included in the flow 809 identification options might refer to BIDs defined in BID options 810 included in the same message. 812 The BID option is processed as defined in 813 [I-D.ietf-monami6-multiplecoa] but then the BID to care-of address 814 mapping is placed in an ordered list according to the BID-PRI field 815 of the BID option. 817 5.3.2. Receiving BU with Flow Identification Options 819 When the home agent receives a binding update which includes at least 820 one Flow Identification option, it first performs the operation 821 described in section 10.3.1 of RFC3775. 823 Home agents that do not support this specification will ignore the 824 flow identification options and all their suboption, having no effect 825 on the operation of the rest of the protocol. 827 If the binding update is accepted, and the home agent is willing to 828 support flow bindings for this MN, the home agent checks the flow 829 identification options. 831 If more than one flow identification option in the same BU, has the 832 same value in the FID field, all the flow identification options MUST 833 be rejected. 835 If all FID fields have different values the flow identification 836 options can be processed further and in any order, as defined by the 837 following subsections. 839 5.3.2.1. Handling Flow Binding Add Requests 841 If the FID field of the flow identification option is already present 842 in the list of flow binding entries for this mobile node, the home 843 agent MUST reject this flow binding add request by copying the flow 844 identification option in the BA, and setting the Status field to 135 845 (FID already in use). 847 If the flow identification option does not include a flow description 848 sub-option, the home agent MUST again reject this request by copying 849 the flow identification option in the BA, and setting the Status 850 field to 129 (Flow identification option malformed). 852 If the flow identification option does include a flow description 853 sub-option, but the flow description type is not supported, the home 854 agent MUST also reject this request by copying the flow 855 identification option in the BA, and setting the Status field to 137 856 (FD-Type not supported). 858 If the FID value is new the home agent MUST check the Action field in 859 combination with the Binding Reference sub-option if present. 861 - if the Action indicates 'Forward' 863 If the Binding reference sub-option is not included or if it is 864 included but it contains more than a single BID, the home agent 865 MUST reject this flow binding add request by copying the flow 866 identification option in the BA, and setting the Status field to 867 129 (Flow identification option malformed). 869 If the Binding Reference sub-option is present and includes a 870 single BID, but the BID is not present in the binding cache of the 871 mobile node the home agent MUST reject this flow binding add 872 request by copying the flow identification option in the BA, and 873 setting the Status field to TBD (BID not known). 875 If the Binding Reference sub-option is present and includes a 876 single BID, and the BID exists in the mobile node's binding cache, 877 the home agent SHOULD add a new entry in the mobile node's list of 878 flow binding entries, as defined below. 880 - if the Action indicates 'Discard', 882 Any Binding Reference sub-options that might be present SHOULD be 883 ignored. 885 The home agent SHOULD add a new entry in the mobile node's list of 886 flow binding entries, as defined below. 888 - if the Action indicates 'n-cast', 890 If the Binding reference sub-option is not included, the home 891 agent MUST reject this flow binding add request by copying the 892 flow identification option in the BA, and setting the Status field 893 to 129 (Flow identification option malformed). 895 If the Binding Reference sub-option is present and includes one or 896 more BIDs that are not present in the binding cache of the mobile 897 node the home agent MUST reject this flow binding add request by 898 copying the flow identification option in the BA, and setting the 899 Status field to TBD (BID not known). 901 If the Binding Reference sub-option is present and includes one or 902 more BIDs, and the BIDs exist in the mobile node's binding cache, 903 the home agent SHOULD add a new entry in the mobile node's list of 904 flow binding entries, as defined below. 906 When the home agent decides to add an entry in the mobile node's list 907 of flow binding entries, as discussed above, it MUST do it according 908 to the following rules: The entry MUST be placed according to the 909 order indicated by the FID-PRI field of the flow identification 910 option and it MUST include: 912 the FID as a key to the entry 914 The flow description included in the corresponding sub-option 916 the action indicated in the Action field 918 the BIDs indicated in the binding reference sub-option 920 the entry MUST be marked as Active, as shown in Section 4.4 922 5.3.2.2. Handling flow binding Modification Requests 924 The flow binding modification is essentially a process where an 925 existing flow binding is removed from the list of flow binding 926 entries and a new flow binding (included in the option) is added, and 927 given the same FID as the flow that was removed. 929 If the value of the FID field of the flow identification option is 930 not present in the binding cache entries for this mobile node, the 931 home agent MUST reject this flow binding modify request by copying 932 the flow identification option in the BA, and setting the Status 933 field to 135 (FID not found). 935 If the value of the FID field is present in the mobile nodes list of 936 flow binding entries, the home agent SHOULD first remove the flow 937 binding entry identified by the FID. The home agent SHOULD then 938 processes this flow identification option as defined in 939 Section 5.3.2.1. 941 5.3.3. Receiving BU with Flow Summary Option 943 When the home agent receives a binding update which includes a Flow 944 Summary option, it first performs the operation described in section 945 10.3.1 of RFC3775. Binding update messages including more than one 946 flow summary option MUST be rejected. A de-registration binding 947 update (with a zero lifetime) would result in deleting all bindings 948 regardless of the presence of the Flow summary option. 950 If the value of any of the FID fields included in the flow summary 951 option is not present in the list of flow binding entries for this 952 mobile node, the home agent MUST reject this flow binding refresh by 953 including a flow identification option in the BA, and setting the FID 954 field in the value of the FID that is not found and the Status field 955 to 135 (FID not found). 957 If the value of the FID field is present in the mobile nodes list of 958 slow binding entries the, home agent SHOULD refresh the binding entry 959 identified by the FID without changing any of the other parameters 960 associated with it. 962 5.3.4. Handling flow binding Removals 964 Removal of flow bindings is performed implicitly by omission of a 965 given FID from a binding update. 967 When a valid binding update is received, any registered FIDs that are 968 not explicitly referred to in a flow identification option or in a 969 flow summary option, MUST be removed from the list of flow binding 970 entries for the mobile node. 972 5.3.5. Sending Binding Acknowledgements 974 Upon the reception of a binding update, the home agent is required to 975 send back a Binding Acknowledgment. The status code in the Binding 976 Acknowledgement must be set as recommended in [RFC3775]. This status 977 code does not give information on the success or failure of flow 978 bindings. 980 In order to inform the mobile node about the status of the flow 981 binding(s) requested by a mobile node, flow identification options 982 MUST be included in the Binding Acknowledgement message. 983 Specifically, the home agent MUST copy each flow identification 984 option received in the binding update and set its status code to an 985 appropriate value. If an operation requested in a flow 986 identification option by a mobile node is performed successfully by 987 the home agent, the status field on the copied flow identification 988 option in the BA, SHOULD be set to 0 (Flow binding successful), 989 otherwise it SHOULD be set to one of the rejection codes defined. 990 Section 5.3.2 identifies a number of cases where specific error codes 991 should be used. 993 Home agents that support this specification MAY refuse to maintain 994 flow bindings by setting the status field of any flow identification 995 options to 130 (Administratively prohibited), or by just ignoring all 996 the flow binding options. 998 Note that BID options and their Status field are handled as defined 999 in [I-D.ietf-monami6-multiplecoa]. 1001 5.3.6. Packet Processing 1003 This section defines packet processing rules according to this 1004 specification. This specification does not change any of the packet 1005 interception rules defined in [RFC3775], and 1006 [I-D.ietf-mext-nemo-v4traversal]. These rules apply to HAs, MAPs, 1007 and CNs, as part of the routing process for any packet with 1008 destination address set to a valid home address of the mobile node. 1009 For nodes other than CNs this also applies to packets with 1010 destination address set to an address under any of the registered 1011 prefixes. These rules apply equally to IPv6 packets as well as to 1012 IPv4 packets when [I-D.ietf-mext-nemo-v4traversal]. 1014 Before a packet is forwarded to the mobile node it MUST be matched 1015 against the ordered list of flow bindings stored in the list of flow 1016 binding entries for this mobile node (see Section 4.4). A match is 1017 attempted with the flow description included in the first line 1018 (highest order) of the table. If the packet matches the flow 1019 description, the action defined by the action parameter of the table 1020 SHOULD be performed. 1022 - if the Action indicates 'Discard', the packet is silently 1023 discarded 1025 - if the Action indicates 'n-cast', a copy of the packet is 1026 forwarded to each of the care-of addresses associated with the 1027 BIDs indicated in the same line of the table. 1029 If the action indicated in one of the entries in the list of flow 1030 bindings is "Discard" then, no BIDs needs to be indicated in the same 1031 entry since the packet is not forwarded. If, however, the action 1032 indicated in an entry of the list of flow bindings is "n-cast", the 1033 entry must indicated a BID. For "n-cast" if any of the BIDs 1034 indicated does not correspond to a valid care-of address, e.g., the 1035 BID was deregistered then that BID has no effect on the traffic. In 1036 other words, packets matching the flow binding are n-casted to the 1037 other BIDs, pointing to registered care-of addresses. If none of the 1038 BIDs pointed to in a flow binding entry is valid then the entry is 1039 considered to be inactive (as defined in Section 4.4) and is skipped. 1040 In other words packets should not be matched against that entry. 1042 6. Security considerations 1044 This draft introduces a new option that adds more granularity to the 1045 binding update message. The new option allows the mobile node to 1046 associate some flows to one interface and other flows to another 1047 interface. Since the flow Identification option is part of the 1048 mobility header, it uses the same security as the Binding Update, 1049 whether it is sent to the home agent, correspondent node, or MAP. 1051 7. IANA Considerations 1053 A Type number (TBD) for Flow Identification Mobility Option and 1054 another Type number (TBD) for Flow Summary Mobility Option has been 1055 registered from the space of numbers for mobility options, defined 1056 for Mobile IPv6 [RFC3775]. This registry is available from 1057 http://www.iana.org under "Mobile IPv6 parameters". 1059 A new sub-type space for the type number of the Flow Identification 1060 Mobility Option has been created: "Flow Identification Mobility 1061 Option Sub-Options". The suboption values 1, and 2, are defined in 1062 this specification, and the values 16-32 are reserved for flow 1063 description sub-options to defined in separate documents. The rest 1064 of the sub-options are reserved and available for allocation based on 1065 Expert Review. 1067 Finally, a new space for the status field of the Flow Identification 1068 Mobility Option has been created: "Flow Identification Mobility 1069 Option Status codes". Values 0, 128-130 and 135-139 are defined in 1070 this specification. The rest of the values below 128 are reserved 1071 for accept codes, and values from 128 and above are reserved for 1072 reject codes. 1074 Similar to the procedures specified for Mobile IPv6 [RFC3775] number 1075 spaces, future allocations from the two number spaces require Expert 1076 Review [RFC5226]. 1078 8. Contributors 1080 We would like to explicitly acknowledge the following person who co- 1081 authored one of the documents used as source material for this 1082 document. 1084 Nikolaus A. Fikouras, niko@comnets.uni-bremen.de 1086 9. Acknowledgements 1088 We would also like to acknowledge the following people in 1089 alphabetical order: C. Castelluccia, K. ElMalki, K. Georgios, , C. 1090 Goerg, C. Kaas-Petersen, T. Noel, F.-N. Pavlidou, V. Park. Gabor 1091 Fekete for the analysis that led to the inclusion of the BIDRef sub- 1092 option. Henrik Levkowetz for suggesting support for other ways of 1093 describing flows. 1095 10. References 1097 10.1. Normative References 1099 [I-D.ietf-mext-nemo-v4traversal] 1100 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1101 Routers", draft-ietf-mext-nemo-v4traversal-10 (work in 1102 progress), April 2009. 1104 [I-D.ietf-monami6-multiplecoa] 1105 Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1106 and K. Nagami, "Multiple Care-of Addresses Registration", 1107 draft-ietf-monami6-multiplecoa-13 (work in progress), 1108 April 2009. 1110 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1111 Requirement Levels", BCP 14, RFC 2119, March 1997. 1113 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1114 in IPv6", RFC 3775, June 2004. 1116 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1117 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1118 RFC 3963, January 2005. 1120 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1121 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1122 May 2008. 1124 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1125 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1126 Management", RFC 5380, October 2008. 1128 10.2. Informative References 1130 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1131 McManus, "Requirements for Traffic Engineering Over MPLS", 1132 RFC 2702, September 1999. 1134 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1135 RFC 3753, June 2004. 1137 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1138 Terminology", RFC 4885, July 2007. 1140 Authors' Addresses 1142 Hesham Soliman 1143 Elevate Technologies 1145 Email: hesham@elevatemobile.com 1147 George 1148 Qualcomm 1150 Email: tsirtsis@gmail.com 1152 Nicolas Montavont 1153 Institut Telecom / Telecom Bretagne 1154 2, rue de la chataigneraie 1155 Cesson Sevigne 35576 1156 France 1158 Phone: (+33) 2 99 12 70 23 1159 Email: nicolas.montavont@telecom-bretagne.eu 1160 URI: http://www.rennes.enst-bretagne.fr/~nmontavo// 1162 Gerardo 1163 Qualcomm 1165 Email: gerardog@qualcomm.com 1167 Koojana Kuladinithi 1168 University of Bremen 1169 ComNets-ikom,University of Bremen. 1170 Otto-Hahn-Allee NW 1 1171 Bremen, Bremen 28359 1172 Germany 1174 Phone: +49-421-218-8264 1175 Fax: +49-421-218-3601 1176 Email: koo@comnets.uni-bremen.de 1177 URI: http://www.comnets.uni-bremen.de/~koo/