idnits 2.17.1 draft-ietf-mip4-multiple-tunnel-support-13.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 (June 21, 2015) is 3232 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility for IPv4 Working Group S. Gundavelli, Ed. 3 Internet-Draft K. Leung 4 Intended status: Experimental Cisco 5 Expires: December 23, 2015 G. Tsirtsis 6 Qualcomm 7 A. Petrescu 8 CEA LIST 9 June 21, 2015 11 Flow Binding Support for Mobile IP 12 draft-ietf-mip4-multiple-tunnel-support-13.txt 14 Abstract 16 This specification defines extensions to Mobile IP protocol for 17 allowing a mobile node with multiple interfaces to register a care-of 18 address for each of its network interfaces and to simultaneously 19 establish multiple IP tunnels with its home agent. This essentially 20 allows the mobile node to utilize all the available network 21 interfaces and build an higher aggregated logical pipe with its home 22 agent for its home address traffic. Furthermore, these extensions 23 also allow the mobile node and the home agent to negotiate IP traffic 24 flow policies for binding individual flows with the registered 25 care-of addresses. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 23, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 63 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6 67 4. Message Extensions . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Multipath Extension . . . . . . . . . . . . . . . . . . . 7 69 4.2. Flow-Binding Extension . . . . . . . . . . . . . . . . . . 9 70 4.3. New Error Codes for Registration Reply . . . . . . . . . . 12 71 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 12 73 5.2. Home Agent Considerations . . . . . . . . . . . . . . . . 14 74 6. Routing Considerations . . . . . . . . . . . . . . . . . . . . 14 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 With the ubiquitous availability of wireless networks based on 86 different access technology types, mobile devices are now equipped 87 with multiple wireless interfaces and have the ability to connect to 88 the network using any of those interfaces. For example, most mobile 89 devices are equipped with Wi-Fi and LTE interfaces. In many 90 deployments, it is desirable for a mobile node to leverage all the 91 available network interfaces and have IP mobility support for its IP 92 flows. 94 The operation defined in the Mobile IP Protocol [RFC5944], allows a 95 mobile node to continue to use its home address as it moves around 96 the internet. Based on the mode of operation, there will be a IP 97 tunnel that will be established between the home agent [RFC5944] and 98 the mobile node [RFC5944], or between the home agent and the foreign 99 agent [RFC5944] where the mobile node is attached. In both of these 100 modes, there will only be one interface on the mobile node that is 101 receiving the IP traffic from the home agent. This approach of using 102 a single access-interface for routing all mobile node's traffic is 103 not efficient and so there is a need to extend Mobile IP to 104 concurrently use multiple access-interfaces for routing the mobile 105 node's IP traffic. The goal is for efficient use of all the 106 available access links to obtain higher aggregated bandwidth for the 107 tunneled traffic between the home agent and the mobile node. 109 This specification defines extensions to Mobile IPv4 protocol for 110 allowing a mobile node with multiple interfaces to register a care-of 111 address for each of its network interfaces and to simultaneously 112 leverage all access links for the mobile node's IP traffic. 113 Furthermore, this specification also defines extensions to allow the 114 mobile node and the home agent to optionally negotiate IP flow 115 policies for binding individual IP flows with the registered care-of 116 addresses. 118 2. Conventions and Terminology 120 2.1. Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2.2. Terminology 128 All the mobility related terms used in this document are to be 129 interpreted as defined in [RFC5944] and [RFC3753]. In addition this 130 document uses the following terms. 132 Binding Identifier (BID) 134 It is an identifier assigned to a mobile node's binding. A 135 binding defines an association between a mobile node's home 136 address and its registered care-of address. When a mobile node 137 registers multiple bindings with its home agent, each using a 138 different care-of address, then each of those bindings are given a 139 unique identifier. Each of the binding identifier will have a 140 unique value which will be different from the identifiers assigned 141 to the mobile node's other bindings. 143 Flow Identifier (FID) 145 It is an identifier for a given IP flow, uniquely identified by 146 source address, destination address, protocol type, source port, 147 destination port, Security Parameter Index and other parameters as 148 identified in [RFC6088]. In the context of this document, the IP 149 flows associated with a mobile node are the IP flows using its 150 home address. For a mobile router, the IP flows also include the 151 IP flows using the mobile network prefix [RFC6626]. 153 3. Overview 155 The illustration below in Figure 1 is an example scenario where a 156 mobile node is connected to WLAN, LTE and CDMA access networks. The 157 mobile node is configured with an home address, HoA_1, and has 158 obtained the care-of addresses [RFC5944] CoA_1 from the WLAN network, 159 CoA_2 from the LTE network and CoA_3 from the CDMA network. 161 The mobile node using the extensions specified in this document 162 registers all the three care-of addresses with its home agent. The 163 mobile node also establishes an IP tunnel with the home agent using 164 each of its IP addresses; Resulting in three IP tunnels (Tunnel_1, 165 Tunnel_2 and Tunnel_3) between the mobile node and the home agent. 166 Each of the tunnel represents a overlay routing path between the 167 mobile node and the home agent and can be used for forwarding the 168 mobile node's IP traffic. 170 Furthermore, the extensions specified in this document allow the 171 mobile node and the home agent to negotiate a IP flow policy. The 172 negotiated flow policy allow the mobile node and the home agent in 173 determining the access network path for each of the mobile node's IP 174 flows. 176 Flow_1 (SIP) 177 | 178 |Flow_2 (SSH) 179 | | 180 | |Flow_3 (HTTP) _----_ 181 | | | CoA_1 _( )_ Tunnel_1 182 | | | .---=======( Wi-Fi )========\ Flow_1 183 | | | | (_ _) \ 184 | | | | '----' \ 185 | | | +=====+ _----_ \ +=====+ _----_ 186 | | '-| | CoA_2 _( )_ Tunnel_2 \ | | _( )_ -- 187 | '---| MN |---====( LTE )=========-----| HA |-( internet )-- 188 '-----| | (_ _) Flow_3 / | | (_ _) -- 189 +=====+ '----' / +=====+ '----' 190 | | _----_ / 191 HoA_1--' | CoA_3 _( )_ Tunnel_3 / 192 .------====( CDMA )========/ Flow_2 193 (_ _) 194 '----' 196 Figure 1: Mobile Node with multiple tunnels to the home agent 198 The above table is an example of how the individual flows are bound 199 to different care-of addresses registered with the home agent. 201 +=========+===================+=====================================+ 202 | Flow Id | Access Network | Description | 203 | (FID) | Preferences | | 204 +=========+===================+=====================================+ 205 | Flow_1 | Tunnel_1 / CoA_1 | All SIP Flows over Wi-Fi (preferred)| 206 | | Tunnel_2 / CoA_2 | If Wi-Fi is not available, use LTE | 207 | | | If Wi-Fi and LTE access network are | 208 | | | not available, drop the flow | 209 +---------+-------------------+-------------------------------------+ 210 | Flow_3 | Tunnel_2 / CoA_2 | All HTTP Flows over LTE (Preferred) | 211 | | | If LTE not available, drop the flow | 212 +---------+-------------------+-------------------------------------+ 213 | Flow_2 | Tunnel_3 / CoA_3 | All SSH Flows over CDMA (Preferred) | 214 | | Tunnel_2 / CoA_2 | If CDMA not available, use LTE | 215 | | Tunnel_1 / CoA_1 | If LTE not available, use Wi-Fi | 216 +---------+-------------------+-------------------------------------+ 218 Figure 2: Example of a IP Traffic Policy 220 3.1. Example Call Flow 222 Figure 3 is the call-flow for the example scenario where a mobile 223 node is connected to WLAN and LTE access networks. 225 +-------+ +-------+ +-------+ +-------+ 226 | MN | | WLAN | | LTE | | HA | 227 | | |Network| |Network| | | 228 +-------+ +-------+ +-------+ +-------+ 229 | | | | 231 * MIP RRQ is sent using the IP Address obtained from the WLAN Network 233 |<--- (1) --------->| | | 234 | | RRQ (Multipath, Flow-Binding) | 235 |---- (2) ----------------------------------------------->| 236 | | RRP | | 237 |<--- (3) ------------------------------------------------| 238 | MIP Tunnel through WLAN Network | 239 |=====(4)===========*=====================================| 241 * MIP RRQ is sent using the IP address obtained from the LTE Network 243 |<--- (5) ---------------------------->| | 244 | | RRQ (Multipath, Flow-Binding) | 245 |---- (6) ----------------------------------------------->| 246 | | RRP | | 247 |<--- (7) ------------------------------------------------| 248 | MIP Tunnel through LTE Access | 249 |=====(8)==============================*==================| 250 | | 251 * * 252 (Policy-based Routing Rule) (Policy-based Routing Rule) 254 Figure 3: Multipath Negotiation - Example Call Flow 256 o (1): The mobile node (MN) attaches to the WLAN network and obtains 257 IP address configuration for its WLAN interface. 259 o (2)-(3): The mobile node sends a Registration Request (RRQ) 260 [RFC5944] to the home agent through the WLAN network. The message 261 includes the Multipath Section 4.1 and Flow-Binding Section 4.2 262 extensions. The home agent upon accepting the request sends a 263 Registration Reply (RRP) [RFC5944] with a value of (0 )in the Code 264 field of the Registration Reply. 266 o (4): The mobile node and the home agent establish a bi-direction 267 IP tunnel over the WLAN network. 269 o (5): The mobile node attaches to LTE network and obtains IP 270 address configuration from that network. 272 o (6)-(7): The mobile node sends a Registration Request to the home 273 agent through the LTE network. The message includes the Multipath 274 and Flow-Binding extensions. The Flow-Binding extension indicates 275 that all HTTP flows need to be routed over WLAN network and if 276 WLAN access is not available, they need be routed over other 277 access networks. The negotiated policy also requires all Voice 278 related traffic flows to be routed over LTE network. The home 279 agent upon accepting the request sends a Registration Reply with a 280 value of (0) in the Code field of the Registration Reply. 282 o (8): The mobile node and the home agent establish a bi-direction 283 IP tunnel over the LTE network. The negotiated traffic flow 284 policy is applied. Both the home agent and the mobile node route 285 all the voice flows over the tunnel established through the LTE 286 access network and HTTP flows over WLAN network. 288 4. Message Extensions 290 This specification defines the following new extensions to Mobile IP. 292 4.1. Multipath Extension 294 This extension is used for requesting multipath support. It 295 indicates that the sender is requesting the home agent to register 296 the current care-of address listed in this Registration Request as 297 one of the many care-addresses through which the mobile node can be 298 reached. It is also for carrying the information specific to the 299 interface to which the care-of addresses that is being registered is 300 bound. 302 This extension is a non-skippable extension and MAY be added by the 303 mobile node to the Registration Request message. There MUST NOT be 304 more than one instance of this extension present in the message. 305 This extension MUST NOT be added by the home agent to the 306 Registration Reply. 308 This extension should be protected using the Mobile-Home 309 Authentication extension [RFC5944]. As specified in Section 3.2 and 310 Section 3.6.1.3 of [RFC5944], the mobile node MUST place this 311 Extension before the Mobile-Home Authentication Extension in the 312 registration messages, so that this extension is integrity protected. 314 The format of this extension is as shown below. It adheres to the 315 long extension format described in [RFC5944]. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Sub-Type | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | If-ATT | If-Label | Binding-Id |B|O| Reserved | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 4: Multipath Extension 327 Type 329 Type: Multipath-Extension-Type () 331 Sub-Type 333 This field MUST be set to a value of 1 (Multipath Extension). 335 Length 337 The length of the extension in octets, excluding Type, Sub-Type 338 and Length fields. This field MUST be set to value of 4. 340 Interface Access-Technology Type (If-ATT) 342 This 8-bit field identifies the Access-Technology type of the 343 interface through which the mobile node is connected. The 344 permitted values for this are from the Access Technology Type 345 registry defined in [RFC5213]. 347 Interface Label (If-Label) 349 This 8-bit field represents the interface label represented as 350 an unsigned integer. The mobile node identifies the label for 351 each of the interfaces through which it registers a CoA with 352 the home agent. When using static traffic flow policies on the 353 mobile node and the home agent, the label can be used for 354 indexing forwarding policies. For example, the operator may 355 have a policy which binds an IP Flow "F1" to any interface with 356 label "Blue". When a registration through an interface 357 matching Label "Blue" gets activated, the home agent and the 358 mobile node establish an IP tunnel and the tunnel is marked 359 with that label. Both the home agent and the mobile node 360 generate traffic rule for forwarding IP flow traffic "F1" 361 through mobile IP tunnel matching Label "Blue". The permitted 362 values for If-Label are 1 through 255. 364 Binding-Identifier (BID) 366 This 8-bit field is used for carrying the binding identifier. 367 It uniquely identifies a specific binding of the mobile node, 368 associated with this registration request. Each binding 369 identifier is represented as an unsigned integer. The 370 permitted values are 1 through 254. The BID value of 0 and 255 371 are reserved. 373 Bulk Re-registration Flag (B) 375 The (B) flag, if set to a value of (1), notifies the home agent 376 to update the binding lifetime of all the mobile node's 377 bindings, upon accepting this request. The (B) flag MUST NOT 378 be set to a value of (1), if the value of the Registration 379 Overwrite Flag (O) flag is set to a value of (1). 381 Registration Overwrite (O) 383 The (O) flag, if set to a value of (1), notifies the home agent 384 that upon accepting this request, it should replace all of the 385 mobile node's existing bindings with the new binding that will 386 be created upon accepting this request. The (O) flag MUST NOT 387 be set to a value of (1), if the value of the Bulk Re- 388 registration Flag (B) is set to a value of (1). This flag MUST 389 be set to a value of (0), in de-registration requests. 391 Reserved (R) 393 This 6-bit field is unused for now. The value MUST be 394 initialized to (0) by the sender and MUST be ignored by the 395 receiver. 397 4.2. Flow-Binding Extension 399 This extension contains information that can be used by the mobile 400 node and the home agent for binding mobile node's IP flows to a 401 specific multipath registration. There can be more than one instance 402 of this extension present in the message. 404 This extension is a non-skippable extension and MAY be added to the 405 Registration Request by the mobile node, or by the home agent to the 406 Registration Reply. 408 This extension should be protected by Mobile-Home Authentication 409 extension [RFC5944]. As specified in Section 3.2 and Section 3.6.1.3 410 of [RFC5944], the mobile node MUST place this Extension before the 411 Mobile-Home Authentication Extension in the registration messages, so 412 that this extension is integrity protected. 414 The format of this extension is as shown below. It adheres to the 415 long extension format described in [RFC5944]. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type | Sub-Type | Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Action | BID Count | ... BID List ... ~ 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | TS Format | Traffic Selector ~ 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 5: Flow-Binding Extension 429 Type 431 Type: Multipath-Extension-Type () 433 Sub-Type 435 This field MUST be set to a value of 2 (Flow-Binding 436 Extension). 438 Length 440 The length of the extension in octets, excluding Type, Sub-Type 441 and Length fields. 443 Action 445 Action field identifies the traffic rule that needs to be 446 enforced. Following are the possible values. 448 +---------+-------+-------------------------------------------------+ 449 | Action | Value | Description | 450 +---------+-------+-------------------------------------------------+ 451 | DROP | 0 | Drop matching packets. A filter rule | 452 | | | indicating a drop action MUST include a single | 453 | | | BID byte, the value of which MAY be set to 255 | 454 | | | by the sender and the value of which SHOULD be | 455 | | | ignored by the receiver. | 456 +---------+-------+-------------------------------------------------+ 457 | FORWARD | 1 | Forward matching packets to the 1st BID in the | 458 | | | list of BIDs the filter rule is pointing to. | 459 | | | If the 1st BID becomes invalid (i.e., the | 460 | | | corresponding CoA is deregistered) use the next | 461 | | | BID in the list. | 462 +---------+-------+-------------------------------------------------+ 464 Figure 6: Action Rules for the Traffic Selector 466 BID Count 468 Total number of binding identifiers that follow this field. 469 Permitted value for this field are 1 through 8; Each binding 470 identifier is represented as an unsigned integer in a single 471 octet field. There is no delimiter between two binding 472 identifier values, they are spaced consecutively. 474 TS Format 476 An 8-bit unsigned integer indicating the Traffic Selector 477 Format. Value (0) is reserved and MUST NOT be used. When the 478 value of TS Format field is set to (1), the format that follows 479 is the IPv4 Binary Traffic Selector specified in section 3.1 of 480 [RFC6088], and when the value of TS Format field is set to (2), 481 the format that follows is the IPv6 Binary Traffic Selector 482 specified in section 3.2 of [RFC6088]. The IPv6 traffic 483 selectors are only relevant when the mobile node registers IPv6 484 prefixes per [RFC5454]. 486 Traffic Selector 488 A variable-length opaque field for including the traffic 489 specification identified by the TS format field. It identifies 490 the traffic selectors for matching the IP traffic and binding 491 them to specific binding identifiers. 493 4.3. New Error Codes for Registration Reply 495 This document defines the following error code values for use by the 496 home agent in the Code field of the Registration Reply. 498 MULTIPATH_NOT_ALLOWED (Multipath Support not allowed for this mobile 499 node): 501 INVALID_FB_IDENTIFIER (Invalid Flow Binding Identifier): 503 5. Protocol Operation 505 5.1. Mobile Node Considerations 507 o The mobile node should register a care-of address for each of the 508 connected interfaces that it wishes to register with the home 509 agent. It can do so by sending a Registration Request to the home 510 agent through each of those interfaces. 512 o Each of the Registration Requests that is sent includes the 513 care-of address of the respective interface. The Registration 514 Request has to be routed through the specific interface for which 515 the registration is sough for. Some of these interfaces may be 516 connected to networks with a configured foreign agent on the link 517 and in such foreign agent based registrations, the care-of address 518 will be the IP address of the foreign agent. 520 o A Multipath extension (Section 4.1) reflecting the interface 521 parameters are present in each of the Registration Requests. This 522 serves as an indication to the home agent that the Registration 523 Request is a Multipath registration and the home agent will have 524 to register this care-of address as one of the many care-of 525 addresses through which the mobile node's home address is 526 reachable. 528 o If the mobile node is configured to exchange IP flow policy to the 529 home agent, then the Flow-Binding extension (Section 4.2) 530 reflecting the flow policy can be included in the message. 531 Otherwise, the Flow-Binding extension will not be included. 533 o The mobile node on receiving a Registration Reply with the code 534 value set to MULTIPATH_NOT_ALLOWED, MAY choose to register without 535 the Multipath extension specified in this document. This implies 536 the home agent has not enabled multipath support for this mobile 537 node and hence multipath support MUST be disabled on the mobile 538 node. 540 o The mobile node on receiving a Registration Reply with the code 541 value set to INVALID_FB_IDENTIFIER, MUST re-register that specific 542 binding with the home agent. 544 o The mobile node at any time can extend the lifetime of a specific 545 care-of address registration by sending a Registration Request to 546 the home agent with a new lifetime value. The message MUST be 547 sent as the initial multipath registration and must be routed 548 through that specific interface. The message MUST include the 549 Multipath extension (Section 4.1) with the value in the Binding-Id 550 field set to the binding identifier assigned to that binding. 551 Alternatively, the home agent can send a single Registration 552 Request with the Bulk Re-registration Flag (B) set to a value of 553 (1). This serves as a request to the home agent to update the 554 registration lifetime of all the mobile node's registrations. 556 o The mobile node at any time can de-register a specific care-of 557 address by sending a Registration Request to the home agent with a 558 lifetime value of (0). The message must include the Multipath 559 extension (Section 4.1) with the value in the Binding-Id field set 560 to the binding identifier assigned to that binding Alternatively, 561 the home agent can send a single Registration Request with the 562 Bulk Re-registration Flag (B) set to a value of (1) and a lifetime 563 value of (0). This serves as a request to the home agent to 564 consider this request as a request to de-register all the mobile 565 node's care-of addresses. 567 o The mobile node at any time can update the parameters of a 568 specific registration by sending a Registration Request to the 569 home agent. This includes change of care-of address associated 570 with a previously registered interface. The message must be sent 571 as the initial multipath registration and must be routed through 572 that specific interface. The message must include the Multipath 573 extension (Section 4.1) with the value in the Binding-Id field set 574 to the binding identifier assigned to that binding and the 575 Overwrite Flag (O) flag MUST set to a value of (1). 577 o The mobile node on receiving a Registration Reply with the code 578 value set to 0 (registration accepted), will establish a mobile IP 579 tunnel to the home agent using that care-of address. When using 580 foreign agent care-of address, the tunnel is between the home 581 agent and the foreign agent. The tunnel encapsulation type and 582 any other parameters are based on the registration for that path. 583 If there is also an exchange of flow policy between the mobile 584 node and the home agent, with the use of Flow-Binding extensions 585 then the mobile node must set up the forwarding plane that matches 586 the flow policy. 588 5.2. Home Agent Considerations 590 The home agent upon receiving a Registration Request from a mobile 591 node with a Multipath extension, should check if the mobile node is 592 authorized for multipath support. If multipath support is not 593 enabled, the home agent MUST reject the request with a registration 594 reply and with the code set to MULTIPATH_NOT_ALLOWED. 596 If the received Registration Request includes a Multipath extension 597 and additionally has the Bulk Re-registration (B) flag set to a value 598 of (1), then the home agent MUST extend the lifetime of all the 599 bindings associated with that mobile node. 601 The home agent upon receipt of a Registration Request with the Flow- 602 Binding Extension must process the extension and upon accepting the 603 flow policy must set up the forwarding plane that matches the flow 604 policy. If the home agent cannot identify any of the binding 605 identifiers then it MUST reject the request with a Registration Reply 606 and with the code set to INVALID_FB_IDENTIFIER. 608 If the received Registration Request includes a Multipath extension 609 and additionally has the Registration Overwrite (O) flag set to a 610 value of (1), then the home agent MUST consider this as a request to 611 replace all other mobile node's bindings with just one binding and 612 that is the binding associated with this request. 614 6. Routing Considerations 616 When multipath registration is enabled for a mobility node, there 617 will be multiple mobile IP tunnels established between a mobile node 618 and its home agent. These mobile IP tunnels appear to the forwarding 619 plane of the mobile node as equal-cost, point-to-point links. 621 If there is also an exchange of traffic flow policy between the 622 mobile node and the home agent, with the use of Flow-Binding 623 extensions (Section 4.2), then the mobile node's IP traffic can be 624 routed by the mobility entities as per the negotiated flow policy. 625 However, if multipath is enabled for a mobility session, without the 626 use of any flow policy exchange, then both the mobile node and the 627 home agent are required to have a pre-configured static flow policy. 628 The specific details on the semantics of this static flow policy is 629 outside the scope of this document. 631 In the absence of any established traffic flow policies, most IP 632 hosts support two alternative traffic load-balancing schemes, Per- 633 flow and Per-packet load balancing [RFC2991]. These load balancing 634 schemes allow the forwarding plane to evenly distribute traffic based 635 on the criteria of either a per-packet or on a per-flow basis, across 636 all the available equal-cost links through which a destination can be 637 reached. The default forwarding behavior of per-flow load balancing 638 will ensure a given flow always takes the same path and will 639 eliminate any packet re-ordering issues and that is critical for 640 delay sensitive traffic. Whereas the per-destination load balancing 641 scheme leverages all the paths much more affectively, but with the 642 potential issue of packet re-ordering on the receiver end. This 643 issue will be specially magnified when the access links have very 644 different forwarding characteristics. A host can choose to enable 645 any of these approaches. Therefore, this specification recommends 646 the use of per-flow load balancing. 648 7. IANA Considerations 650 This document requires the following IANA actions. 652 o Action-1: This specification defines two new Mobile IP extensions, 653 Multipath extension and Flow-Binding extension. The format of the 654 Multipath extension is described in Section 4.1 and the format of 655 the Flow-Binding extension is described in Section 4.2. Both of 656 these extensions are non-skippable extensions to the Mobile IPv4 657 header in accordance to the long extension format of [RFC5944]. 658 Both of these extensions use a common Type value, Multipath- 659 Extension-Type () but are identified using different Sub- 660 Type values. The type value for these extension needs to 661 be allocated from the registry, "Extensions to Mobile IP 662 Registration Messages", at the URL, 663 . The field, 664 "Permitted for Notification Messages" for this extension MUST be 665 set to "N"." RFC Editor: Please replace in Section 4.1 666 and in Section 4.2 with the assigned value and update these 667 sections accordingly. 669 o Action-2: This specification defines a new message sub-type space, 670 Multipath Extension sub-type. This field is described in 671 Section 4.1. The values for this sub-type field needs to be 672 managed by IANA, under the Registry, Multipath Extension Sub-type 673 Registry. This specification reserves the following type values. 674 Approval of new Multipath Extension sub-type values are to be made 675 through IANA Expert Review [RFC5226]. 677 +=========================================================+ 678 | 0 | Reserved | 679 +=========================================================+ 680 | 1 | Multipath Extension | 681 +=========================================================+ 682 | 2 | Flow-Binding Extension | 683 +=========================================================+ 684 | | | 685 ~ 3-254 | -- For future use -- ~ 686 | | | 687 +=========================================================+ 688 | 255 | Reserved | 689 +=========================================================+ 691 o Action-3: This document defines new status code values, 692 MULTIPATH_NOT_ALLOWED () and INVALID_FB_IDENTIFIER 693 () for use by the home agent in the Code field of the 694 Registration Reply, as described in Section 4.3. These values 695 need to be assigned from the "Registration denied by the home 696 agent" registry at 697 . The 698 allocated value has to be greater than 127. RFC Editor: Please 699 replace and in Section 4.3 with the assigned 700 value and update this section accordingly. 702 8. Security Considerations 704 This specification allows a mobile node to establish multiple Mobile 705 IP tunnels with its home agent, by registering a care-of address for 706 each of its active roaming interfaces. This essentially allows the 707 mobile node's IP traffic to be routed through any of the tunnel paths 708 based on a static or a dynamically negotiated flow policy. This new 709 capability has no impact on the protocol security. Furthermore, this 710 specification defines two new Mobile IP extensions, Multipath 711 extension and the Flow-Binding extension. These extensions are 712 specified to be included in Mobile IP control messages, which are 713 authenticated and integrity protected as described in [RFC5944]. 714 Therefore, this specification does not weaken the security of Mobile 715 IP Protocol, and does not introduce any new security vulnerabilities. 717 9. Contributors 719 This document reflects discussions and contributions from the 720 following people: 722 Ahmad Muhanna 724 asmuhanna@yahoo.com 726 Srinivasa Kanduru 728 skanduru@gmail.com 730 Vince Park 732 vpark@qualcomm.com 734 Hesham Soliman 736 hesham@elevatemobile.com 738 10. Acknowledgements 740 We like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan, Yungui 741 Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela Vanderveen, 742 Antti Makela, Charles Perkins, Pierrick Siette, Vijay Gurbani, Barry 743 Leiba, Henrik Levkowetz, Pete McCann and Brian Haberman. for their 744 review and comments on this draft. 746 11. References 748 11.1. Normative References 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 754 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 756 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 757 RFC 5944, November 2010. 759 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 760 "Traffic Selectors for Flow Bindings", RFC 6088, 761 January 2011. 763 11.2. Informative References 765 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 766 Multicast Next-Hop Selection", RFC 2991, November 2000. 768 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 769 RFC 3753, June 2004. 771 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 772 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 773 May 2008. 775 [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile 776 IPv4", RFC 5454, March 2009. 778 [RFC6626] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, 779 "Dynamic Prefix Allocation for Network Mobility for Mobile 780 IPv4 (NEMOv4)", RFC 6626, May 2012. 782 Authors' Addresses 784 Sri Gundavelli (editor) 785 Cisco 786 170 West Tasman Drive 787 San Jose, CA 95134 788 USA 790 EMail: sgundave@cisco.com 792 Kent Leung 793 Cisco 794 170 West Tasman Drive 795 San Jose, CA 95134 796 USA 798 EMail: kleung@cisco.com 800 George Tsirtsis 801 Qualcomm 803 EMail: tsirtsis@qualcomm.com 805 Alexandru Petrescu 806 CEA LIST 807 Communicating Systems Laboratory, Point Courrier 94 808 Gif-sur-Yvette F-91191 809 France 811 Phone: +33 169089223 812 EMail: alexandru.petrescu@cea.fr