+---------+-------+-------------------------------------------------+
|  Action | Value | Description                                     |
+---------+-------+-------------------------------------------------+
|  DROP   |   0   | Drop matching packets. A filter rule            |
|         |       | indicating a drop action MUST include a single  |
|         |       | BID byte, the value of which MAY be set to 255  |
|         |       | by the sender and the value of which SHOULD be  |
|         |       | ignored by the receiver.                        |
+---------+-------+-------------------------------------------------+
| FORWARD |   1   | Forward matching packets to the 1st BID in the  |
|         |       | list of BIDs the filter rule is pointing to.    |
|         |       | If the 1st BID becomes invalid (i.e., the       |
|         |       | corresponding CoA is deregistered) use the next |
|         |       | BID in the list.                                |    
+---------+-------+-------------------------------------------------+

 

Figure 6: Action Rules for the Traffic Selector

Type

Type: Multipath-Extension-Type (<IANA-1>)

Sub-Type

This field MUST be set to a value of 2 (Flow-Binding Extension).

Length

The length of the extension in octets, excluding Type, Sub-Type and Length fields.

Action

Action field identifies the traffic rule that needs to be enforced. Following are the possible values.

BID Count

Total number of binding identifiers that follow this field. Permitted value for this field are 1 through 8; Each binding identifier is represented as an unsigned integer in a single octet field. There is no delimiter between two binding identifier values, they are spaced consecutively.

TS Format

An 8-bit unsigned integer indicating the Traffic Selector Format. Value (0) is reserved and MUST NOT be used. When the value of TS Format field is set to (1), the format that follows is the IPv4 Binary Traffic Selector specified in section 3.1 of [RFC6088], and when the value of TS Format field is set to (2), the format that follows is the IPv6 Binary Traffic Selector specified in section 3.2 of [RFC6088]. The IPv6 traffic selectors are only relevant when the mobile node registers IPv6 prefixes per [RFC5454].

Traffic Selector

A variable-length opaque field for including the traffic specification identified by the TS format field. It identifies the traffic selectors for matching the IP traffic and binding them to specific binding identifiers.

4.3. New Error Codes for Registration Reply

This document defines the following error code values for use by the home agent in the Code field of the Registration Reply.

MULTIPATH_NOT_ALLOWED (Multipath Support not allowed for this mobile node): <IANA-3>

INVALID_FB_IDENTIFIER (Invalid Flow Binding Identifier): <IANA-4>

5. Protocol Operation

5.1. Mobile Node Considerations

• The mobile node should register a care-of address for each of the connected interfaces that it wishes to register with the home agent. It can do so by sending a Registration Request to the home agent through each of those interfaces.
• Each of the Registration Requests that is sent includes the care-of address of the respective interface. The Registration Request has to be routed through the specific interface for which the registration is sough for. Some of these interfaces may be connected to networks with a configured foreign agent on the link and in such foreign agent based registrations, the care-of address will be the IP address of the foreign agent.
• A Multipath extension (Section 4.1) reflecting the interface parameters are present in each of the Registration Requests. This serves as an indication to the home agent that the Registration Request is a Multipath registration and the home agent will have to register this care-of address as one of the many care-of addresses through which the mobile node's home address is reachable.
• If the mobile node is configured to exchange IP flow policy to the home agent, then the Flow-Binding extension (Section 4.2) reflecting the flow policy can be included in the message. Otherwise, the Flow-Binding extension will not be included.
• The mobile node on receiving a Registration Reply with the code value set to MULTIPATH_NOT_ALLOWED, MAY choose to register without the Multipath extension specified in this document. This implies the home agent has not enabled multipath support for this mobile node and hence multipath support MUST be disabled on the mobile node.
• The mobile node on receiving a Registration Reply with the code value set to INVALID_FB_IDENTIFIER, MUST re-register that specific binding with the home agent.
• The mobile node at any time can extend the lifetime of a specific care-of address registration by sending a Registration Request to the home agent with a new lifetime value. The message MUST be sent as the initial multipath registration and must be routed through that specific interface. The message MUST include the Multipath extension (Section 4.1) with the value in the Binding-Id field set to the binding identifier assigned to that binding. Alternatively, the home agent can send a single Registration Request with the Bulk Re-registration Flag (B) set to a value of (1). This serves as a request to the home agent to update the registration lifetime of all the mobile node's registrations.
• The mobile node at any time can de-register a specific care-of address by sending a Registration Request to the home agent with a lifetime value of (0). The message must include the Multipath extension (Section 4.1) with the value in the Binding-Id field set to the binding identifier assigned to that binding Alternatively, the home agent can send a single Registration Request with the Bulk Re-registration Flag (B) set to a value of (1) and a lifetime value of (0). This serves as a request to the home agent to consider this request as a request to de-register all the mobile node's care-of addresses.
• The mobile node at any time can update the parameters of a specific registration by sending a Registration Request to the home agent. This includes change of care-of address associated with a previously registered interface. The message must be sent as the initial multipath registration and must be routed through that specific interface. The message must include the Multipath extension (Section 4.1) with the value in the Binding-Id field set to the binding identifier assigned to that binding and the Overwrite Flag (O) flag MUST set to a value of (1).
• The mobile node on receiving a Registration Reply with the code value set to 0 (registration accepted), will establish a mobile IP tunnel to the home agent using that care-of address. When using foreign agent care-of address, the tunnel is between the home agent and the foreign agent. The tunnel encapsulation type and any other parameters are based on the registration for that path. If there is also an exchange of flow policy between the mobile node and the home agent, with the use of Flow-Binding extensions then the mobile node must set up the forwarding plane that matches the flow policy.

5.2. Home Agent Considerations

The home agent upon receiving a Registration Request from a mobile node with a Multipath extension, should check if the mobile node is authorized for multipath support. If multipath support is not enabled, the home agent MUST reject the request with a registration reply and with the code set to MULTIPATH_NOT_ALLOWED.

If the received Registration Request includes a Multipath extension and additionally has the Bulk Re-registration (B) flag set to a value of (1), then the home agent MUST extend the lifetime of all the bindings associated with that mobile node.

The home agent upon receipt of a Registration Request with the Flow-Binding Extension must process the extension and upon accepting the flow policy must set up the forwarding plane that matches the flow policy. If the home agent cannot identify any of the binding identifiers then it MUST reject the request with a Registration Reply and with the code set to INVALID_FB_IDENTIFIER.

If the received Registration Request includes a Multipath extension and additionally has the Registration Overwrite (O) flag set to a value of (1), then the home agent MUST consider this as a request to replace all other mobile node's bindings with just one binding and that is the binding associated with this request.

6. Routing Considerations

When multipath registration is enabled for a mobility node, there will be multiple mobile IP tunnels established between a mobile node and its home agent. These mobile IP tunnels appear to the forwarding plane of the mobile node as equal-cost, point-to-point links.

If there is also an exchange of traffic flow policy between the mobile node and the home agent, with the use of Flow-Binding extensions (Section 4.2), then the mobile node's IP traffic can be routed by the mobility entities as per the negotiated flow policy. However, if multipath is enabled for a mobility session, without the use of any flow policy exchange, then both the mobile node and the home agent are required to have a pre-configured static flow policy. The specific details on the semantics of this static flow policy is outside the scope of this document.

In the absence of any established traffic flow policies, most IP hosts support two alternative traffic load-balancing schemes, Per-flow and Per-packet load balancing [RFC2991]. These load balancing schemes allow the forwarding plane to evenly distribute traffic based on the criteria of either a per-packet or on a per-flow basis, across all the available equal-cost links through which a destination can be reached. The default forwarding behavior of per-flow load balancing will ensure a given flow always takes the same path and will eliminate any packet re-ordering issues and that is critical for delay sensitive traffic. Whereas the per-destination load balancing scheme leverages all the paths much more affectively, but with the potential issue of packet re-ordering on the receiver end. This issue will be specially magnified when the access links have very different forwarding characteristics. A host can choose to enable any of these approaches. Therefore, this specification recommends the use of per-flow load balancing.

7. IANA Considerations

This document requires the following IANA actions.

   +=========================================================+
   |  0    | Reserved                                        |
   +=========================================================+
   |  1    | Multipath Extension                             |
   +=========================================================+
   |  2    | Flow-Binding Extension                          |
   +=========================================================+
   |       |                                                 |
   ~ 3-254 |  -- For future use --                           ~
   |       |                                                 |
   +=========================================================+
   |  255  | Reserved                                        |
   +=========================================================+

• Action-1: This specification defines two new Mobile IP extensions, Multipath extension and Flow-Binding extension. The format of the Multipath extension is described in Section 4.1 and the format of the Flow-Binding extension is described in Section 4.2. Both of these extensions are non-skippable extensions to the Mobile IPv4 header in accordance to the long extension format of [RFC5944]. Both of these extensions use a common Type value, Multipath-Extension-Type (<IANA-1>) but are identified using different Sub-Type values. The type value <IANA-1> for these extension needs to be allocated from the registry, "Extensions to Mobile IP Registration Messages", at the URL, <http://www.iana.org/assignments/mobileip-numbers>. The field, "Permitted for Notification Messages" for this extension MUST be set to "N"." RFC Editor: Please replace <IANA-1> in Section 4.1 and in Section 4.2 with the assigned value and update these sections accordingly.
• Action-2: This specification defines a new message sub-type space, Multipath Extension sub-type. This field is described in Section 4.1. The values for this sub-type field needs to be managed by IANA, under the Registry, Multipath Extension Sub-type Registry. This specification reserves the following type values. Approval of new Multipath Extension sub-type values are to be made through IANA Expert Review [RFC5226].
• Action-3: This document defines new status code values, MULTIPATH_NOT_ALLOWED (<IANA-3>) and INVALID_FB_IDENTIFIER (<IANA-4>) for use by the home agent in the Code field of the Registration Reply, as described in Section 4.3. These values need to be assigned from the "Registration denied by the home agent" registry at <http://www.iana.org/assignments/mobility-parameters>. The allocated value has to be greater than 127. RFC Editor: Please replace <IANA-3> and <IANA-4> in Section 4.3 with the assigned value and update this section accordingly.

8. Security Considerations

This specification allows a mobile node to establish multiple Mobile IP tunnels with its home agent, by registering a care-of address for each of its active roaming interfaces. This essentially allows the mobile node's IP traffic to be routed through any of the tunnel paths based on a static or a dynamically negotiated flow policy. This new capability has no impact on the protocol security. Furthermore, this specification defines two new Mobile IP extensions, Multipath extension and the Flow-Binding extension. These extensions are specified to be included in Mobile IP control messages, which are authenticated and integrity protected as described in [RFC5944]. Therefore, this specification does not weaken the security of Mobile IP Protocol, and does not introduce any new security vulnerabilities.

9. Contributors

This document reflects discussions and contributions from the following people:

Ahmad Muhanna

asmuhanna@yahoo.com

Srinivasa Kanduru

skanduru@gmail.com

Vince Park

vpark@qualcomm.com

Hesham Soliman

hesham@elevatemobile.com

10. Acknowledgements

We like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan, Yungui Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela Vanderveen, Antti Makela, Charles Perkins, Pierrick Siette, Vijay Gurbani, Barry Leiba, Henrik Levkowetz, Pete McCann and Brian Haberman. for their review and comments on this draft.

11. References

11.1. Normative References

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213]	Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5944]	Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC6088]	Tsirtsis, G., Giarreta, G., Soliman, H. and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011.

11.2. Informative References

[RFC2991]	Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC3753]	Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5454]	Tsirtsis, G., Park, V. and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC6626]	Tsirtsis, G., Park, V., Narayanan, V. and K. Leung, "Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4)", RFC 6626, May 2012.

Authors' Addresses