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