diff options
Diffstat (limited to 'doc/rfc/rfc7629.txt')
| -rw-r--r-- | doc/rfc/rfc7629.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7629.txt b/doc/rfc/rfc7629.txt new file mode 100644 index 0000000..d34072b --- /dev/null +++ b/doc/rfc/rfc7629.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Gundavelli, Ed. +Request for Comments: 7629 K. Leung +Category: Experimental Cisco +ISSN: 2070-1721 G. Tsirtsis + Qualcomm + A. Petrescu + CEA, LIST + August 2015 + + + Flow-Binding Support for Mobile IP + +Abstract + + This specification defines extensions to the Mobile IP protocol for + allowing a mobile node with multiple interfaces to register a care-of + address for each of its network interfaces and to simultaneously + establish multiple IP tunnels with its home agent. This essentially + allows the mobile node to utilize all the available network + interfaces and build a higher aggregated logical pipe with its home + agent for its home address traffic. Furthermore, these extensions + also allow the mobile node and the home agent to negotiate IP traffic + flow policies for binding individual flows with the registered care- + of addresses. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7629. + + + + + + + + + +Gundavelli, et al. Experimental [Page 1] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 + 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6 + 4. Message Extensions . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Multipath Extension . . . . . . . . . . . . . . . . . . . 7 + 4.2. Flow-Binding Extension . . . . . . . . . . . . . . . . . 9 + 4.3. New Error Codes for Registration Reply . . . . . . . . . 12 + 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . 12 + 5.2. Home Agent Considerations . . . . . . . . . . . . . . . . 14 + 6. Routing Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 9.2. Informative References . . . . . . . . . . . . . . . . . 17 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + + + + + + + + + + + + +Gundavelli, et al. Experimental [Page 2] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +1. Introduction + + With the ubiquitous availability of wireless networks based on + different access technology types, mobile devices are now equipped + with multiple wireless interfaces and have the ability to connect to + the network using any of those interfaces. For example, most mobile + devices are equipped with Wi-Fi and LTE (Long Term Evolution) + interfaces. In many deployments, it is desirable for a mobile node + to leverage all the available network interfaces and have IP mobility + support for its IP flows. + + The operation defined in the Mobile IP protocol [RFC5944] allows a + mobile node to continue to use its home address as it moves around + the Internet. Based on the mode of operation, there will be an IP + tunnel that will be established between the home agent and the mobile + node or between the home agent and the foreign agent where the mobile + node is attached; see [RFC5944]. In both of these modes, there will + only be one interface on the mobile node that is receiving the IP + traffic from the home agent. This approach of using a single access + interface for routing all mobile node's traffic is not efficient and + so there is a need to extend Mobile IP to concurrently use multiple + access interfaces for routing the mobile node's IP traffic. The goal + is for efficient use of all the available access links to obtain + higher aggregated bandwidth for the tunneled traffic between the home + agent and the mobile node. + + This specification defines extensions to Mobile IPv4 protocol for + allowing a mobile node with multiple interfaces to register a care-of + address for each of its network interfaces and to simultaneously + leverage all access links for the mobile node's IP traffic. + Furthermore, this specification also defines extensions to allow the + mobile node and the home agent to optionally negotiate IP flow + policies for binding individual IP flows with the registered care-of + addresses. + +2. Conventions and Terminology + +2.1. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2.2. Terminology + + All the mobility-related terms used in this document are to be + interpreted as defined in [RFC5944] and [RFC3753]. In addition, this + document uses the following terms. + + + +Gundavelli, et al. Experimental [Page 3] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + Binding Identifier (BID) + + It is an identifier assigned to a mobile node's binding. A + binding defines an association between a mobile node's home + address and its registered care-of address. When a mobile node + registers multiple bindings with its home agent, each using a + different care-of address, then each of those bindings are given a + unique identifier. Each of the binding identifiers will have a + unique value that will be different from the identifiers assigned + to the mobile node's other bindings. + + Flow Identifier (FID) + + It is an identifier for a given IP flow, uniquely identified by + source address, destination address, protocol type, source port, + destination port, Security Parameter Index, and other parameters + as identified in [RFC6088]. In the context of this document, the + IP flows associated with a mobile node are the IP flows using its + home address. For a mobile router, the IP flows also include the + IP flows using the mobile network prefix [RFC6626]. + +3. Overview + + The illustration below in Figure 1 is an example scenario where a + mobile node is connected to WLAN, LTE, and CDMA access networks. The + mobile node is configured with a home address, HoA_1, and has + obtained the following care-of addresses [RFC5944]: CoA_1, from the + WLAN network; CoA_2, from the LTE network; and CoA_3, from the CDMA + network. + + The mobile node using the extensions specified in this document + registers all three care-of addresses with its home agent. The + mobile node also establishes an IP tunnel with the home agent using + each of its IP addresses, which results in three IP tunnels + (Tunnel_1, Tunnel_2, and Tunnel_3) between the mobile node and the + home agent. Each of the tunnels represents an overlay routing path + between the mobile node and the home agent and can be used for + forwarding the mobile node's IP traffic. + + Furthermore, using the extensions specified in this document, the + mobile node and the home agent can negotiate an IP flow policy. The + negotiated flow policy allows the mobile node and the home agent to + determine the access network path for each of the mobile node's IP + flows. + + + + + + + +Gundavelli, et al. Experimental [Page 4] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + Flow_1 (SIP) + | + |Flow_2 (SSH) + | | + | |Flow_3 (HTTP) _----_ + | | | CoA_1 _( )_ Tunnel_1 + | | | .---=======( Wi-Fi )========\ Flow_1 + | | | | (_ _) \ + | | | | '----' \ + | | | +=====+ _----_ \ +=====+ _----_ + | | '-| | CoA_2 _( )_ Tunnel_2 \ | | _( )_ -- + | '---| MN |---====( LTE )=========-----| HA |-( Internet )-- + '-----| | (_ _) Flow_3 / | | (_ _) -- + +=====+ '----' / +=====+ '----' + | | _----_ / + HoA_1--' | CoA_3 _( )_ Tunnel_3 / + .------====( CDMA )========/ Flow_2 + (_ _) + '----' + + Figure 1: Mobile Node (MN) with Multiple Tunnels + to the Home Agent (HA) + + The table below is an example of how the individual flows are bound + to different care-of addresses registered with the home agent. + + +=========+===================+=====================================+ + | Flow ID | Access Network | Description | + | (FID) | Preferences | | + +=========+===================+=====================================+ + | Flow_1 | Tunnel_1 / CoA_1 | All SIP flows over Wi-Fi (Preferred)| + | | Tunnel_2 / CoA_2 | If Wi-Fi is not available, use LTE | + | | <DROP> | If Wi-Fi and LTE access networks are| + | | | not available, drop the flow | + +---------+-------------------+-------------------------------------+ + | Flow_3 | Tunnel_2 / CoA_2 | All HTTP flows over LTE (Preferred) | + | | <DROP> | If LTE not available, drop the flow | + +---------+-------------------+-------------------------------------+ + | Flow_2 | Tunnel_3 / CoA_3 | All SSH flows over CDMA (Preferred) | + | | Tunnel_2 / CoA_2 | If CDMA not available, use LTE | + | | Tunnel_1 / CoA_1 | If LTE not available, use Wi-Fi | + +---------+-------------------+-------------------------------------+ + + Figure 2: Example of an IP Traffic Policy + + + + + + + +Gundavelli, et al. Experimental [Page 5] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +3.1. Example Call Flow + + Figure 3 is the call flow for the example scenario where a mobile + node is connected to WLAN and LTE access networks. + + +-------+ +-------+ +-------+ +-------+ + | MN | | WLAN | | LTE | | HA | + | | |Network| |Network| | | + +-------+ +-------+ +-------+ +-------+ + | | | | + + * MIP RRQ is sent using the IP address obtained from the WLAN Network + + |<--- (1) --------->| | | + | | RRQ (Multipath, Flow-Binding) | + |---- (2) ----------------------------------------------->| + | | RRP | | + |<--- (3) ------------------------------------------------| + | MIP Tunnel through WLAN Network | + |=====(4)===========*=====================================| + + + * MIP RRQ is sent using the IP address obtained from the LTE Network + + |<--- (5) ---------------------------->| | + | | RRQ (Multipath, Flow-Binding) | + |---- (6) ----------------------------------------------->| + | | RRP | | + |<--- (7) ------------------------------------------------| + | MIP Tunnel through LTE Access Network | + |=====(8)==============================*==================| + | | + * * + (Policy-based Routing Rule) (Policy-based Routing Rule) + + Figure 3: Multipath Negotiation - Example Call Flow + + o (1): The mobile node attaches to the WLAN network and obtains the + IP address configuration for its WLAN interface. + + o (2)-(3): The mobile node sends a Registration Request (RRQ) + [RFC5944] to the home agent through the WLAN network. The message + includes the Multipath (Section 4.1) and the Flow-Binding + (Section 4.2) Extensions. The home agent, upon accepting the + request, sends a Registration Reply (RRP) [RFC5944] with a value + of (0) in the Code field of the Registration Reply. + + + + + +Gundavelli, et al. Experimental [Page 6] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + o (4): The mobile node and the home agent establish a bidirectional + IP tunnel over the WLAN network. + + o (5): The mobile node attaches to the LTE network and obtains the + IP address configuration from that network. + + o (6)-(7): The mobile node sends a Registration Request to the home + agent through the LTE network. The message includes the Multipath + and the Flow-Binding Extensions. The Flow-Binding Extension + indicates that all HTTP flows need to be routed over the WLAN + network and if the WLAN access network is not available, they need + be routed over other access networks. The negotiated policy also + requires all voice-related traffic flows to be routed over the LTE + network. The home agent, upon accepting the request, sends a + Registration Reply with a value of (0) in the Code field of the + Registration Reply. + + o (8): The mobile node and the home agent establish a bidirectional + IP tunnel over the LTE network. The negotiated traffic flow + policy is applied. Both the home agent and the mobile node route + all the voice flows over the tunnel established through the LTE + access network and the HTTP flows over the WLAN network. + +4. Message Extensions + + This specification defines the following new extensions to Mobile IP. + +4.1. Multipath Extension + + This extension is used for requesting multipath support. It + indicates that the sender is requesting the home agent to register + the current care-of address listed in this Registration Request as + one of the many care-of addresses through which the mobile node can + be reached. It is also for carrying the information specific to the + interface to which the care-of address that is being registered is + bound. + + This extension is a non-skippable extension and MAY be added by the + mobile node to the Registration Request message. There MUST NOT be + more than one instance of this extension present in the message. + This extension MUST NOT be added by the home agent to the + Registration Reply. + + This extension should be protected using the Mobile-Home + Authentication Extension [RFC5944]. As specified in Sections 3.2 and + 3.6.1.3 of [RFC5944], the mobile node MUST place this Extension + before the Mobile-Home Authentication Extension in the registration + messages so that this extension is integrity protected. + + + +Gundavelli, et al. Experimental [Page 7] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + The format of this extension is as shown below. It adheres to the + long extension format described in [RFC5944]. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Subtype | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | If-ATT | If-Label | Binding ID |B|O| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Multipath Extension + + Type + + Type: Multipath-Extension-Type (154) + + Subtype + + This field MUST be set to a value of 1 (Multipath Extension). + + Length + + The length of the extension in octets, excluding Type, Subtype, + and Length fields. This field MUST be set to a value of 4. + + Interface Access-Technology Type (If-ATT) + + This 8-bit field identifies the Access Technology type of the + interface through which the mobile node is connected. The + permitted values for this are from the Access Technology Type + registry defined in [RFC5213]. + + Interface Label (If-Label) + + This 8-bit field represents the interface label represented as an + unsigned integer. The mobile node identifies the label for each + of the interfaces through which it registers a CoA with the home + agent. When using static traffic flow policies on the mobile node + and the home agent, the label can be used for indexing forwarding + policies. For example, the operator may have a policy that binds + an IP flow "F1" to any interface with the label "Blue". When a + registration through an interface matching the label "Blue" gets + activated, the home agent and the mobile node establish an IP + tunnel and the tunnel is marked with that label. Both the home + agent and the mobile node generate traffic rules for forwarding IP + flow traffic "F1" through the mobile IP tunnel matching the label + "Blue". The permitted values for If-Label are 1 through 255. + + + +Gundavelli, et al. Experimental [Page 8] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + Binding Identifier (BID) + + This 8-bit field is used for carrying the binding identifier. It + uniquely identifies a specific binding of the mobile node + associated with this Registration Request. Each binding + identifier is represented as an unsigned integer. The permitted + values are 1 through 254. The BID value of 0 and 255 are + reserved. + + Bulk Re-registration Flag (B) + + The (B) flag, if set to a value of (1), notifies the home agent to + update the binding lifetime of all the mobile node's bindings upon + accepting this request. The (B) flag MUST NOT be set to a value + of (1) if the value of the Registration Overwrite Flag (O) flag is + set to a value of (1). + + Registration Overwrite (O) + + The (O) flag, if set to a value of (1), notifies the home agent + that upon accepting this request it should replace all of the + mobile node's existing bindings with the new binding that will be + created upon accepting this request. The (O) flag MUST NOT be set + to a value of (1) if the value of the Bulk Re-registration Flag + (B) is set to a value of (1). This flag MUST be set to a value of + (0) in De-Registration requests. + + Reserved (R) + + This 6-bit field is unused for now. The value MUST be initialized + to (0) by the sender and MUST be ignored by the receiver. + +4.2. Flow-Binding Extension + + This extension contains information that can be used by the mobile + node and the home agent for binding mobile node's IP flows to a + specific multipath registration. There can be more than one instance + of this extension present in the message. + + This extension is a non-skippable extension and MAY be added to the + Registration Request by the mobile node or by the home agent to the + Registration Reply. + + This extension should be protected by Mobile-Home Authentication + Extension [RFC5944]. As specified in Section 3.2 and 3.6.1.3 of + [RFC5944], the mobile node MUST place this extension before the + Mobile-Home Authentication Extension in the registration messages so + that this extension is integrity protected. + + + +Gundavelli, et al. Experimental [Page 9] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + The format of this extension is as shown below. It adheres to the + long extension format described in [RFC5944]. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Subtype | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action | BID Count | ... BID List ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TS Format | Traffic Selector ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Flow-Binding Extension + + Type + + Type: Multipath-Extension-Type (154) + + Subtype + + This field MUST be set to a value of 2 (Flow-Binding Extension). + + Length + + The length of the extension in octets, excluding Type, Subtype, + and Length fields. + + Action + + The Action field identifies the traffic rule that needs to be + enforced. Following are the possible values. + + + + + + + + + + + + + + + + + + + +Gundavelli, et al. Experimental [Page 10] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + +---------+-------+-------------------------------------------------+ + | 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 first BID in the| + | | | list of BIDs the filter rule is pointing to. | + | | | If the first BID becomes invalid (i.e., the | + | | | corresponding CoA is de-registered), use the | + | | | next BID in the list. | + +---------+-------+-------------------------------------------------+ + + Figure 6: Action Rules for the Traffic Selector + + BID Count + + Total number of binding identifiers that follow this field. The + permitted values 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 (TS) + Format. The value (0) is reserved and MUST NOT be used. When the + value of the 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 the 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. + + + + + + + +Gundavelli, et al. Experimental [Page 11] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +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): 152 + + INVALID_FB_IDENTIFIER (Invalid Flow-Binding Identifier): 153 + +5. Protocol Operation + +5.1. Mobile Node Considerations + + o 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. + + o 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 sought 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. + + o A Multipath Extension (Section 4.1) reflecting the interface + parameters is 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. + + o 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. + + o The mobile node, upon 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. + + + + + +Gundavelli, et al. Experimental [Page 12] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + o The mobile node, upon receiving a Registration Reply with the Code + value set to INVALID_FB_IDENTIFIER, MUST re-register that specific + binding with the home agent. + + o 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. + + o The mobile node can, at any time, 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. + + o The mobile node can, at any time, update the parameters of a + specific registration by sending a Registration Request to the + home agent. This includes a 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 be set to a value of (1). + + o The mobile node, upon 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 a + 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. + + + + +Gundavelli, et al. Experimental [Page 13] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +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 are + 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 on + either a per-packet or per-flow basis, across all the available + + + +Gundavelli, et al. Experimental [Page 14] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + 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 effectively 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 + + Per this document, the following IANA actions have been completed. + + o Action 1: This specification defines two new Mobile IP extensions, + the Multipath Extension and the 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 (154), but are identified + using different Subtype values. The Type value 154 for these + extensions has been allocated from the "Extensions to Mobile IP + Registration Messages" registry at the URL + <http://www.iana.org/assignments/mobileip-numbers>. The field + "Permitted for Notification Messages" for this extension MUST be + set to "N". + + o Action 2: This specification defines a new message subtype space, + Multipath Extension subtype. This field is described in + Section 4.1. The values for this subtype field are managed by + IANA under the "Multipath Extension subtypes (Value 154)" + registry. This specification reserves the following Type values. + Approvals of new Multipath Extension subtype values are to be made + through IANA Expert Review [RFC5226]. + + + + + + + + + + + + + +Gundavelli, et al. Experimental [Page 15] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + + +=========================================================+ + | 0 | Reserved | + +=========================================================+ + | 1 | Multipath Extension | + +=========================================================+ + | 2 | Flow-Binding Extension | + +=========================================================+ + | | | + ~ 3-254 | Unassigned ~ + | | | + +=========================================================+ + | 255 | Reserved | + +=========================================================+ + + o Action 3: This document defines new status code values, + MULTIPATH_NOT_ALLOWED (152) and INVALID_FB_IDENTIFIER (153), for + use by the home agent in the Code field of the Registration Reply, + as described in Section 4.3. These values have been assigned from + the "Registration denied by the home agent" registry at + <http://www.iana.org/assignments/mobileip-numbers>. + +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, the 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 the + Mobile IP protocol and does not introduce any new security + vulnerabilities. + + + + + + + + + + + + + + + +Gundavelli, et al. Experimental [Page 16] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., + Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", + RFC 5213, DOI 10.17487/RFC5213, August 2008, + <http://www.rfc-editor.org/info/rfc5213>. + + [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", + RFC 5944, DOI 10.17487/RFC5944, November 2010, + <http://www.rfc-editor.org/info/rfc5944>. + + [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, + "Traffic Selectors for Flow Bindings", RFC 6088, + DOI 10.17487/RFC6088, January 2011, + <http://www.rfc-editor.org/info/rfc6088>. + +9.2. Informative References + + [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and + Multicast Next-Hop Selection", RFC 2991, + DOI 10.17487/RFC2991, November 2000, + <http://www.rfc-editor.org/info/rfc2991>. + + [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related + Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, + <http://www.rfc-editor.org/info/rfc3753>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile + IPv4", RFC 5454, DOI 10.17487/RFC5454, March 2009, + <http://www.rfc-editor.org/info/rfc5454>. + + [RFC6626] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, + "Dynamic Prefix Allocation for Network Mobility for Mobile + IPv4 (NEMOv4)", RFC 6626, DOI 10.17487/RFC6626, May 2012, + <http://www.rfc-editor.org/info/rfc6626>. + + + + +Gundavelli, et al. Experimental [Page 17] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +Acknowledgements + + We would like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan, + Yungui Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela + Vanderveen, Antti Makela, Charles Perkins, Pierrick Seite, Vijay + Gurbani, Barry Leiba, Henrik Levkowetz, Pete McCann, and Brian + Haberman for their review and comments on this document. + +Contributors + + This document reflects discussions and contributions from the + following people: + + Ahmad Muhanna + Email: asmuhanna@yahoo.com + + Srinivasa Kanduru + Email: skanduru@gmail.com + + Vince Park + Email: vpark@qualcomm.com + + Hesham Soliman + Email: hesham@elevatemobile.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gundavelli, et al. Experimental [Page 18] + +RFC 7629 Flow-Binding Support for Mobile IP August 2015 + + +Authors' Addresses + + Sri Gundavelli (editor) + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + United States + + Email: sgundave@cisco.com + + + Kent Leung + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + United States + + Email: kleung@cisco.com + + + George Tsirtsis + Qualcomm + + Email: tsirtsis@qualcomm.com + + + Alexandre Petrescu + CEA, LIST + CEA Saclay + Gif-sur-Yvette , Ile-de-France 91191 + France + + Phone: +33169089223 + Email: alexandre.petrescu@cea.fr + + + + + + + + + + + + + + + + + +Gundavelli, et al. Experimental [Page 19] + |