idnits 2.17.1 draft-yokota-mext-ha-init-flow-binding-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (August 1, 2013) is 3892 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-netext-pmip6-qos-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft D. Kim 4 Intended status: Experimental KDDI Lab 5 Expires: February 2, 2014 B. Sarikaya 6 F. Xia 7 Huawei USA 8 August 1, 2013 10 Home Agent Initiated Flow Binding for Mobile IPv6 11 draft-yokota-mext-ha-init-flow-binding-06 13 Abstract 15 There are scenarios in which the home agent needs to trigger flow 16 binding operations towards the mobile node such as moving a flow from 17 one access network to another based on the network resource 18 availability. In order for the home agent to be able to initiate 19 interactions for flow bindings with the mobile node, this document 20 defines new signaling messages and sub-options for Mobile IPv6. Home 21 agent initiated flow bindings are supported for both IPv4 and IPv6 22 enabled mobile nodes. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 2, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. QoS provisioning . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Traffic Offload from congested network . . . . . . . . . . 4 63 3.3. Flow movement or deletion in emergency situation . . . . . 4 64 3.4. Service-specific data cap . . . . . . . . . . . . . . . . 4 65 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Adding flow bindings . . . . . . . . . . . . . . . . . . . 5 67 4.2. Deleting flow bindings . . . . . . . . . . . . . . . . . . 6 68 4.3. Modifying flow bindings . . . . . . . . . . . . . . . . . 6 69 4.4. Refreshing flow bindings . . . . . . . . . . . . . . . . . 6 70 4.5. Moving flow bindings . . . . . . . . . . . . . . . . . . . 7 71 4.6. Revoking flow bindings . . . . . . . . . . . . . . . . . . 7 72 5. Handling of the Flow Bindings List . . . . . . . . . . . . . . 8 73 6. Flow Binding Messages and Options . . . . . . . . . . . . . . 9 74 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 9 75 6.1.1. Flow Binding Indication . . . . . . . . . . . . . . . 9 76 6.1.2. Flow Binding Acknowledgement . . . . . . . . . . . . . 10 77 6.1.3. Flow Binding Revocation Extensions . . . . . . . . . . 11 78 6.2. New Options . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.2.1. Flow binding action sub-option . . . . . . . . . . . . 12 80 6.2.2. Target Care-of-Address sub-option . . . . . . . . . . 12 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. Protocol constants . . . . . . . . . . . . . . . . . . . . . . 13 83 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 86 10.2. Informative references . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 [RFC6089] allows a mobile node to bind a particular flow to a care-of 92 address without affecting other flows using the same home address. 93 Binding Update (BU)/Binding Acknowledgement(BA) messages are extended 94 for the mobile node to add, modify, remove and refresh flow binding 95 in a home agent. The operations are always initiated by the mobile 96 node. 98 While the mobile node manipulates flow bindings by e.g., the user 99 interaction or the change of the attached link condition, these 100 operations are also required for network-related reasons such as 101 dynamic QoS control in the network, load balancing or maintenance in 102 mobility agent nodes. For the latter case, the mobile node is not 103 much aware of the transport network condition away from it or policy 104 and charging status controlled by the operator, thus the network 105 needs to request the mobile node to handle proper flow bindings. 107 This document defines a new Mobility Header and messages in order for 108 the home agent to request the mobile node to initiate flow bindings 109 in a timely manner. Flow mobility for the mobile nodes with IPv4 110 home address and IPv4 address of the home agent as described in 111 [RFC5555] is also supported. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 The terminology in this document is based on the definitions in 120 [RFC6275] and [RFC6089]. 122 3. Use Cases 124 3.1. QoS provisioning 126 When the user launches a video chat application and starts sending 127 voice and video to the other end, the network may need to provide 128 different QoS treatments to these media based on the operator's 129 policy. In such a case, the network needs to request the user or 130 mobile node to establish separate flows for voice and video. 132 3.2. Traffic Offload from congested network 134 The 3G operator may want to move traffic flows from the 3G access to 135 another (e.g., WiFi network) due to instantaneous traffic increase in 136 the 3G access network. Fine-grained traffic offload is desirable. 137 For example, IMS-based VoIP flows must stay in the mobile core 138 network while video streaming flows provided by servers on the 139 Internet could bypass the mobile core network via WiFi access. Since 140 the network knows more about its conditions and has access to the 141 policy server, more timely and well-controlled traffic offloading is 142 possible. The home agent sends an updated flow descriptor to be 143 offloaded to the mobile node. 145 3.3. Flow movement or deletion in emergency situation 147 In an emergency situation caused by a natural disaster, it is 148 necessary to accept as many voice calls as possible for safety 149 inquiry to confirm the safety status of family and friends, while 150 non-critical services such as gaming could be put lower priority. In 151 order to save the 3G/LTE radio resources for emergency services, non- 152 critical services may need to be moved to another access or closed 153 down. The home agent requests the mobile node to use WiFi access for 154 non-critical application flows or to terminate them gracefully e.g., 155 by letting it notify the user of possible QoS degradation or ask him/ 156 her to finish the corresponding applications before taking any 157 action. 159 3.4. Service-specific data cap 161 The mobile operator offers a mobile broadband service with a flat 162 rate subscription limited to 5G Byte per month. Once the allotment 163 is used up, the service is downgraded to 64 K bits per second. This 164 limitation, however, is not applied to IMS-based services (e.g., 165 VoLTE), while video conversations over the Internet will be affected. 166 The operator can indicate this to the user by sending modified flow 167 descriptors as a proposal to adjust the communication data rate or 168 change access for an ongoing session. 170 4. Protocol Operation 172 [RFC6089] makes use of Binding Update (BU) / Binding Acknowledgement 173 (BA) signalling to forward, i.e. register or discard a flow binding 174 in a home agent. Flow binding operations are always initiated from 175 the mobile node. In this document, the basic principle of the 176 specification is that the home agent prompts the mobile node to 177 perform flow binding operations. For this purpose, a new Mobility 178 Header and two new messages, that is, Flow Binding Indication (FBI) 179 and Flow Binding Acknowledgement (FBA) are defined. FBI is used by 180 the home agent to request flow binding operations to the mobile node 181 and FBA is used for acknowledging FBI. In order for the flow binding 182 operation to be complete, BU/BA exchange MUST be initiated by the 183 mobile node after FBI/FBA exchange. 185 It is assumed that the home agent has already created Binding Cache 186 entries for the mobile node before launching flow binding operations. 188 Due to access network change on the mobile node side, some interface 189 that used to be active may not be valid at the time of flow binding 190 operation by the home agent, in which case, even if the HA sends the 191 FBI to the MN, the FBA will not return. After retransmitting the 192 FBIs for MAX_FBI_RETRIES times and not receiving the FBA, the HA 193 determines that the target interface is not available. 195 If the mobile node does not support the FBI message, it responds with 196 a Binding Error message with status set to 2 (unrecognized mobility 197 header (MH) type value) as described in [RFC6275]. When the Binding 198 Error message with status set to 2 is received in response to a FBI 199 message, the home agent MUST NOT use FBI message with that mobile 200 node again. 202 4.1. Adding flow bindings 204 Adding the flow binding implies associating a particular flow with 205 one of the care-of addresses on the mobile node. The care-of address 206 concerned with the flow binding is present in the destination address 207 of the packet or the alternate care-of address option. 208 Alternatively, the care-of address may be indicated by the Target 209 Care-of Address sub-option defined in Section 6.2.2. 211 When adding a new flow binding, the home agent sends a FBI with a 212 Flow Identification Mobility option to the mobile node. In Figure 1, 213 which is shown as an example for this operation, the mobile node 214 exchanges both voice and video over Flow Identifier (FID)#1. Based 215 on the operator's policy, the network determines to provide separate 216 QoS for the video flow and the home agent sends the FBI to the mobile 217 node. The Flow Identification Mobility option defined in [RFC6089] 218 includes the current FID and the Traffic Selector (TS) to specify the 219 video flow. The Flow binding action sub-option MUST indicate Add 220 operation defined in Section 6.2.1. The mobile node returns the FBA 221 to the home agent with the same options. The BU/BA exchange follows 222 afterwards to perform the actual flow binding as defined in RFC6088 223 and the video traffic is exchanged over FID#2. 225 +----+ +----+ 226 | MN | | HA | 227 +----+ +----+ 228 | FID#1(voice+video) | 229 |/==============================\| 230 |\==============================/| 231 | | 232 | FBI(add,FID#1,TS[video]) | 233 |<-------------------------------| 234 | FBA(FID#1,TS[video]) | 235 |------------------------------->| 236 | BU(FID#2,TS[video]) | 237 |------------------------------->| 238 | BA(FID#2,TS[video]) | 239 |<-------------------------------| 240 | | 241 | FID#1(voice) | 242 |<==============================>| 243 | FID#2(video) | 244 |<==============================>| 246 Figure 1: Example call flow for adding a flow binding 248 4.2. Deleting flow bindings 250 When removing a flow binding, the home agent sends a FBI with a Flow 251 Identification Mobility option in which the Flow binding action sub- 252 option indicates Delete operation. The Flow Identification Mobility 253 option includes a unique FID for the mobile node to locate the flow 254 binding and remove it. 256 4.3. Modifying flow bindings 258 When modifying a flow binding (e.g., changing QoS attributes of the 259 flow as defined in [I-D.ietf-netext-pmip6-qos]) is needed, the home 260 agent sends the mobile node a FBI message with Flow Identification 261 Mobility option. The option includes the FID to be modified. A 262 Traffic Selector sub-option MAY come with the Flow Identification 263 Mobility Option and contain new attributes e.g., in Quality of 264 Service Option. 266 4.4. Refreshing flow bindings 268 A flow binding is refreshed by simply including the Flow 269 Identification Mobility option with Refresh Action field in the FBI 270 message. The message should be sent before the expiration of the 271 flow binding. The message updates existing bindings with new 272 information. Hence, all information previously sent in the last 273 refreshing message need to be resent, otherwise such information will 274 be lost. 276 4.5. Moving flow bindings 278 The home agent can request to move a flow associated with one 279 interface of the multi-interfaced mobile node to another by sending a 280 FBI message to the mobile node. The Action field of the flow binding 281 action sub-option is set to Move and the address of the target 282 interface is also included in Target Care-of Address sub-option. 283 After the FBA is returned to the home agent, the flow mobility is 284 performed by the mobile node. Figure 2 shows the movement of a flow 285 label as FID from the interface with sCoA to that with tCoA, which is 286 stored in the Binding Identity Mobility Option. 288 +----+ +----+ 289 | MN | | HA | 290 +----+ +----+ 291 |<=sCoA | 292 | |<=tCoA | 293 | | FBI(FID,tCoA) | 294 |<--------------------------------| 295 | | FBA(FID,tCoA) | 296 |-------------------------------->| 297 | | | 298 | | BU(BID[tCoA],FID) | 299 | |------------------------------>| 300 | | BA(BID[tCoA],FID) | 301 | |<------------------------------| 302 | | | 304 Figure 2: Example call flow for moving a flow binding 306 4.6. Revoking flow bindings 308 When the home agent or the network attached to it is overloaded, the 309 home agent can revoke a flow binding registered by the mobile node. 310 The home agent sends the mobile node a FBI message with a Flow 311 Identification Mobility option in which the Flow binding action sub- 312 option indicates Revoke operation. When the MN receives the FBI 313 message with Revoke operation, it decides whether the flow should be 314 removed (de-registration) or moved to another interface and returns 315 the FBA with an appropriate status code. The mobile node SHOULD take 316 an action by sending a new BU, for example, to deregister the flow. 318 The difference from deleting flow bindings in Section 4.2 is that 319 even if the mobile node does not take any action, the target flow may 320 be revoked by the network with the procedures defined in [RFC5846]. 322 5. Handling of the Flow Bindings List 324 Flow bindings list defined in [RFC6089] needs to be modified after 325 each protocol operation defined above as follows: 327 If FBI contains a flow binding add operation and if the corresponding 328 FBA has a status code equal to zero, home agent MUST add a new entry 329 to the flow bindings list. FID, Flow Descriptor, FID-PRI and Action 330 fields are taken from the Flow Identification Mobility Option. BID 331 is copied from the Binding Reference sub-option. Active/Inactive 332 Flag is set to Active. Note that if BID is not available it may be 333 replaced by Care-of-Address. 335 If FBI contains a flow binding delete operation and if the 336 corresponding FBA has a status code equal to zero, home agent MUST 337 locate the list entry corresponding to this flow and then delete the 338 entry. 340 If the home agent sends a Binding Revocation Indication message with 341 Flow Mobility Option where the action field is set to Revoke and if 342 the corresponding Binding Revocation Acknowledgement message 343 indicates acceptance, home agent MUST locate the list entry 344 corresponding to this flow and then delete the entry. 346 If FBI contains a flow binding modify operation and if the 347 corresponding FBA has a status code equal to zero, home agent MUST 348 delete the list entry corresponding to this flow and then add a new 349 entry setting the values as defined in the Flow Identification 350 Mobility Option. 352 If FBI contains a flow binding refresh operation and if the 353 corresponding FBA has a status code equal to zero, home agent MUST 354 locate the list entry corresponding to this flow and then set Active/ 355 Inactive Flag to Active. 357 If FBI contains a flow binding move operation and if the 358 corresponding FBA has a status code equal to zero, home agent MUST 359 locate the list entry corresponding to this flow and then change the 360 BID value to the Care-of-Address in the Flow Identification Mobility 361 Option. 363 If FBI contains a flow binding switch operation and if the 364 corresponding FBA has a status code equal to zero, home agent MUST 365 locate the list entry corresponding to this flow and then delete the 366 entry. 368 Flow binding operations apply equally to IPv4 packets as well as IPv6 369 packets as per Dual-Stack Mobile IPv6 [RFC5555]. In order to support 370 the situation where there is NAT/firewall between the mobile node and 371 home agent, NAT detection and NAT keepalives mechanisms defined in 372 [RFC5555] MUST be used. When the mobile node and home agent are in 373 IPv6-only and IPv4-only networks, respectively and NAT64 [RFC6146] 374 resides in between, each node would behave as if the other node was 375 in the same network domain. Even though this scenario is not fully 376 described in [RFC5555], the initial mobility binding is always 377 performed by the mobile node and the binding cache is created in the 378 home agent. The destination address of the FBI SHALL be the mobile 379 node's IPv4 care-of address in the binding cache entry. 381 6. Flow Binding Messages and Options 383 6.1. Mobility Header 385 The messages described below follow the Mobility Header format 386 specified in Section 6.1 of [RFC6275]. 388 6.1.1. Flow Binding Indication 390 The Flow Binding Indication messages are used by the home agent to 391 initiate flow binding operations to the mobile node. The Flow 392 Binding Indication messages use the MH Type value (IANA-TBD1) for 393 Flow Binding message and a Flow Binding Type value of 1, and the 394 format of the Message Data field in the Mobility Header is as 395 follows: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Flow Binding Type = 1 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Sequence # | Trigger |A| Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | | 405 . . 406 . Mobility options . 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 3: Flow Binding Indication Mobility Header Format 412 Sequence # 413 A 16-bit unsigned integer used by the home agent to match a 414 returned Flow Binding Acknowledgement with this Flow Binding 415 Indication. It could be a random number. 417 Trigger 418 8-bit unsigned integer indicating the event which triggered the 419 home agent to send the Flow Binding Indication message. The 420 following Trigger values are currently defined: 422 0 Reserved 423 1 Unspecified 424 2 Administrative Reason 425 3 Possible Out-of Sync BCE State 426 250-255 Reserved For Testing Purposes only 427 All the other values are reserved 429 Acknowledge (A) 430 The Acknowledge (A) bit is set by the home agent to request a Flow 431 Binding Acknowledgement be returned upon receipt of the Flow 432 Binding Indication. 434 Reserved 435 These fields are unused. They MUST be initialized to zero by the 436 sender and MUST be ignored by the receiver. 438 Mobility Options 439 Variable-length field of such length that the complete Mobility 440 Header is an integer multiple of 8 octets long. Flow 441 Identification Mobility Options are included in this field. 443 6.1.2. Flow Binding Acknowledgement 445 The Flow Binding Acknowledgement is used to acknowledge receipt of a 446 Flow Binding Indication. The mobile node sends FBA message to 447 acknowledge the reception of FBI to Add, Delete, Modify, Refresh, 448 Move, or Switch a flow binding. On receiving messages with Flow 449 Identification Mobility Option(s), the mobile node should copy each 450 Flow Identification Mobility Option to the Acknowledgement messages. 451 The Flow Binding Acknowledgement has the MH Type value (IANA-TBD1) 452 for Flow Binding message and a Flow Binding Type value of 2. When 453 this value is indicated in the MH Type field, the format of the 454 Message Data field in the Mobility Header is as follows: 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Flow Binding Type = 2 | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Sequence # | Status | Reserved | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 . . 465 . Mobility options . 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 4: Flow Binding Acknowledgement Mobility Header Format 471 Sequence # 472 The sequence number in the Flow Binding Acknowledgement is copied 473 from the Sequence Number field in the Flow Binding Indication. 475 Status 476 8-bit unsigned integer indicating the result of processing the 477 Flow Binding Indication message by the receiving mobile node. 478 Values of the Status field less than 128 indicate that the Flow 479 Binding Indication was processed successfully by the receiving 480 node. Values greater than or equal to 128 indicate that the Flow 481 Binding Indication was rejected by the receiving node. The 482 following status values are currently defined: 484 0 success 485 128 Binding (target CoA) Does NOT Exist 486 129 Action NOT Authorized 487 All the other values are reserved 489 Mobility Options 490 Variable-length field of such length that the complete Mobility 491 Header is an integer multiple of 8 octets long. This field 492 contains zero or more TLV-encoded mobility options. Flow 493 Identification Mobility Options are included in this field. 495 6.1.3. Flow Binding Revocation Extensions 497 This specification enables Binding Revocation Indication and Binding 498 Revocation Acknowledgement messages to carry Flow Identification 499 Mobility Options as defined in [RFC6089] with extensions defined in 500 this document. 502 6.2. New Options 504 This document defines new Flow Indication Sub-Options that are 505 included in Flow Identification Mobility Option specified in 506 [RFC6089]. 508 6.2.1. Flow binding action sub-option 510 This section defines a new sub-option for flow binding actions, which 511 MUST be included in the Flow Identification Mobility Option when it 512 is sent from the home agent to the mobile node via the FBI message. 513 The format of this sub-option is shown in Figure 5. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 |Sub-opt Type |Sub-opt Length | Reserved | Action | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 5: Flow binding action sub-option 523 Sub-opt Type 524 To be assigned by IANA (IANA-TBD2) 526 Sub-opt Length 527 Length of the sub-option in octets, excluding the Sub-opt Type and 528 Sub-opt Length fields. 530 Action 531 This is a 8-bit field that describes the required processing for 532 the option. It can be assigned one of the following new values: 534 11 Add a flow binding 535 12 Delete a flow binding 536 13 Modify a flow binding 537 14 Refresh a flow binding 538 15 Move a flow binding 539 16 Revoke a flow binding 540 All the other values are reserved for future use 542 6.2.2. Target Care-of-Address sub-option 544 This section introduces the Target Care-of-Address sub-option, which 545 may be included in the Flow Identification Mobility Option. This 546 sub-option is used to indicate the mobile node to move a flow binding 547 from one interface to another. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |Sub-opt Type |Sub-opt Length | Reserved | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Target Care-of-Address | 555 . . 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 6: Target Care-of-Address Sub-option 560 Sub-opt Type 561 To be assigned by IANA (IANA-TBD3) 563 Sub-opt Length 564 Length of the sub-option in octets, excluding the Sub-opt Type and 565 Sub-opt Length fields. 567 Reserved 568 This field is unused. It MUST be initialized to zero by the 569 sender and MUST be ignored by the receiver. 571 Target Care-of-Address 572 The address of an interface that the flow is moved to. This 573 address could be IPv4 or IPv6 address. This sub-option MUST be 574 included when the action taken is "15 Move a flow binding". 576 7. Security Considerations 578 Security issues for this document follow those of [RFC6088],[RFC6089] 579 and [RFC5846]. This specification allows the home agent to 580 manipulate only the binding of a flow(s) that is currently registered 581 with it, which is the same principle described in [RFC5846]. No 582 additional security issue specific to this document is identified. 584 8. Protocol constants 586 Maximum FBI retries (MAX_FBI_RETRIES) 587 This variable specifies the maximum number of times the HA MAY 588 retransmit a Flow Binding Indication message when FBA is not 589 returned within the time period specified by MAX_FBA_TIMEOUT. The 590 default value for this parameter is 3. 592 Maximum FBA timeout (MAX_FBA_TIMEOUT) 593 This variable specifies the maximum time in seconds the HA MUST 594 wait before retransmitting another FBI message. The default for 595 this parameter is 3 seconds. 597 9. IANA considerations 599 This document defines one new Mobility Header and two new mobility 600 options to be used in Flow Binding Initiate and Flow Binding 601 Acknowledge messages. A new Mobility Header Type and two new sub-opt 602 type values (IANA-TBD1 through IANA-TBD3) need to be assigned by 603 IANA. 605 10. References 607 10.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 613 Routers", RFC 5555, June 2009. 615 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 616 in IPv6", RFC 6275, July 2011. 618 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 619 NAT64: Network Address and Protocol Translation from IPv6 620 Clients to IPv4 Servers", RFC 6146, April 2011. 622 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 623 and P. Yegani, "Binding Revocation for IPv6 Mobility", 624 RFC 5846, June 2010. 626 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 627 "Traffic Selectors for Flow Bindings", RFC 6088, 628 January 2011. 630 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 631 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 632 Network Mobility (NEMO) Basic Support", RFC 6089, 633 January 2011. 635 10.2. Informative references 637 [I-D.ietf-netext-pmip6-qos] 638 Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. 639 Gundavelli, "Quality of Service Option for Proxy Mobile 640 IPv6", draft-ietf-netext-pmip6-qos-03 (work in progress), 641 July 2013. 643 Authors' Addresses 645 Hidetoshi Yokota 646 KDDI Lab 647 2-1-15 Ohara 648 Fujimino 649 Saitama, Japan 356-8502 651 Phone: 652 Email: yokota@kddilabs.jp 654 Dae-Sun Kim 655 KDDI Lab 656 2-1-15 Ohara 657 Fujimino 658 Saitama, Japan 356-8502 660 Phone: 661 Email: da-kim@kddilabs.jp 663 Behcet Sarikaya 664 Huawei USA 665 5340 Legacy Drive Building 3 666 Plano, TX 75024 668 Phone: +1 469-277-5839 669 Email: sarikaya@ieee.org 671 Frank Xia 672 Huawei USA 673 5430 Legacy Dr. Building 3 674 Plano, TX 75024 676 Phone: 677 Email: xiayangsong@huawei.com