DMM WG P. Seite Internet-Draft Orange Intended status: Standards Track July 3, 2014 Expires: January 4, 2015 Multihoming support for Residential Gateway (RG) using IP mobility protocols draft-seite-dmm-bonding-00.txt Abstract The Quality of Experience of fixed network user can be improved with multiple WAN interfaces Residential Gateway (RG), i.e. RG supporting more than one WAN interface (e.g. LTE and DSL), so that it can take benefit of multihoming advantages. This document discusses the use of IP mobility protocols (NEMO [RFC3753] and Mobile IPv6 [RFC6275]), and their Multiple care-of-address extension [RFC5648], to meet multihomed RG requirements. This document also defines a new mobility option, the bonding option, for IP mobility protocols. This option is used by the mobility entities to configure the interface bonding where packets, of a given IP flow, are distributed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2015. Copyright Notice Copyright (c) 2014 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 Seite Expires January 4, 2015 [Page 1] Internet-Draft multihomed RG Interface Bonding Option July 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Messaging Extensions . . . . . . . . . . . . . . . . 5 4.1. Bonding Option . . . . . . . . . . . . . . . . . . . . . 5 4.2. Bonding attributes . . . . . . . . . . . . . . . . . . . 6 4.2.1. Bindings list . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Traffic Selector . . . . . . . . . . . . . . . . . . 7 5. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Sending Bonding Request . . . . . . . . . . . . . . . . . 8 5.2. Receiving Bonding request . . . . . . . . . . . . . . . . 8 5.3. Tunnelling and packet distribution scheme . . . . . . . . 9 5.4. Network controlled aggregation . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Fix access network (e.g. DSL) usually provides Internet connectivity via a Residential Gateway (RG) acting as the access router. When equipped with different WAN access technologies (e.g. DSL and LTE), the RG could take benefit of multihoming advantages such as redundancy, load sharing, load balancing and so on. Among multihoming benefits is the bandwidth aggregation, so that increased bandwidth is provided to the end-user by allowing the RG to use simultaneously the available WAN interfaces. The RG can either bind some given IP flows to given interfaces or distribute the uplink packets of a same IP flow to more than one WAN interface (i.e. interface bonding). On the network side, an aggregation gateway performs same traffic management operations for downlink traffic. Seite Expires January 4, 2015 [Page 2] Internet-Draft multihomed RG Interface Bonding Option July 2014 Actually, the architecture described above is typically a mobile network architecture; functionally, the aggregation point is nothing else than an IP mobility anchor and the RG can be viewed as a mobile router. Actually, if IP mobility protocols have been specified to bring IP session continuity for mobile hosts or mobile networks, nothing prevent to use them in a fixed network context [RFC4908]. Besides, IP mobility protocols can meet a basic aggregation requirement, which consist in setting-up dynamically forwarding paths, over more than one access network, between the RG and a traffic anchoring in charge of managing bandwidth aggregation. Typically, Mobile IPv6 [RFC6275]), NEMO [RFC3963]) and MCoA [RFC5648]) can be used in bandwidth aggregation context to establish forwarding paths (i.e. bindings) on a Residential Gateway with more than one WAN access (e.g. xDSL and LTE, connection to several xDSL ISPs). This document briefly discusses these architectures on Section 3. IP mobility protocols can be used without any modifications to bring bandwidth aggregation at the IP flow level: a multihomed RG can use simultaneously all its WAN interfaces and binds different IP flows to different interfaces. However, for bandwidth aggregation at the packet level, the way to use the available mobility bindings may differ from legacy IP mobility solutions. Indeed, IP mobility protocols tend to associate a given IP flow to a given binding ([RFC6089]), while interface bonding use-case may require to distribute an IP flow simultaneously over more than one binding, i.e. perform bonding of the WAN interfaces for higher bandwidth. This document specifies IP mobility extensions to allow this behaviour. 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 the Mobile IPv6 specifications [RFC3753], [RFC5648], [RFC5213] and [RFC6275]. 3. Architecture This section proposes to use a NEMO [RFC3963] architecture in a fix network context to allow aggregation of the WAN interfaces of an Residential Gateway (RG). Seite Expires January 4, 2015 [Page 3] Internet-Draft multihomed RG Interface Bonding Option July 2014 The Residential Gateway has more than one WAN interfaces (e.g. DSL and LTE), from which it obtains IP addresses, i.e. care-of-address, via legacy IP allocation mechanisms (e.g. DHCP, SLAAC). Then, the RG registers these care-of-addresses to the mobility anchor using NEMO [RFC3963]) protocol and multiple care-of-addresses [RFC5648] extension. Mobile IP bi-directional tunnels are established, between the RG and the mobility anchor, over each WAN interface. The RG has a unique Home Address through which it is reachable when it is registered with its Home Agent. The Home Address is configured from a prefix advertised by its Home Agent. When the Home Agent receives a data packet meant for a node in the RG Network, it tunnels the packet to the RG to one of the available care-of address. The selection of the care-of-address depends on the aggregation method, operating either at the IP flow or at the packet level: o At the IP flow level: this scenario is just an application of the current IP flow mobility solution [RFC6089]). The home agent forwards the packets according IP flow routing rules, which give association between IP flows and bindings, received from the RG. The latter indicates flow routing rules to the home agent using flow binding extensions for NEMO ([RFC6088] and [RFC6089]). o At the Packet Level: in this scenario, IP flow management slightly differs from the default mobile IP behaviour; the home agent distributes packets, belonging to a same IP flow, over more than one bindings simultaneously. The home agent should select the bindings according to interface aggregation indication provided by the RG with the bonding option described in Section 4.1. Note that specification of packets distribution schemes is out the scope of this document. When receiving a packet, the RG decapsulates the packet and forwards it onto the RG Network. If aggregation operates at the packet level, the RG may buffer and reorder packets before delivery. Buffering and reordering considerations are out of the scope of this document. Seite Expires January 4, 2015 [Page 4] Internet-Draft multihomed RG Interface Bonding Option July 2014 IP Network #1 HA Binding Cache +------------+ _--------_ +------------+ ================== | | BID#1 ( ) | | RG, BID#1[HoA, CoA#1],BID#2[HoA, CoA#2] |Residential +======(==IP-in-IP==)==+ | | Gateway | (_ _) |Aggregation | | (RG) | (_______) | Gateway | | | |(Home Agent |------> | Mobility | | | | Client | IP Network #2 | | | | _--------_ | | | | BID#2 ( ) | | | +======(==IP-in-IP==)==+ | | | (_ _) | | +-----+------+ (_______) +------------+ | ----RG network---- | end-nodes Figure 1: Multihomed RG architecture Figure 2: Multihomed MN architecture 4. Protocol Messaging Extensions 4.1. Bonding Option The Bonding option is a mobility header option used by the mobile client and the home agent to indicate bindings to be aggregated. The option can be used by any IP mobility protocols supporting Multiple care-of-address registration, it is carried within the Binding Update, Binding Acknowledgement, UPN/UPA and Binding Refresh Request. The alignment requirement for this option is 4n. Seite Expires January 4, 2015 [Page 5] Internet-Draft multihomed RG Interface Bonding Option July 2014 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 | Length | BO-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bonding Attributes (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Bonding Option Type To be assigned by IANA Length 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. Bonding Identifier (BO-ID) The mobile client assigns a BO-ID to each bonding, aggregating at least two bindings. The BO-ID MUST be unique for a given home address. The value is an integer between 0 and 65535. When the value is (0), all . If a mobile node has only one bonding, the assignment of a BO-ID is not needed. Reserved This field is unused for now. The value MUST be initialized to a value of (0) by the sender and MUST be ignored by the receiver. Bonding Attributes One or more Type-Length-Value (TLV) encoded bonding indication. Attributes are optional. 4.2. Bonding attributes 4.2.1. Bindings list MUST be included if bonding is expected to apply on a sunset of available bindings. The list of binding IDs indicates at least two bindings that are grouped together within a single BO-ID. Seite Expires January 4, 2015 [Page 6] Internet-Draft multihomed RG Interface Bonding Option July 2014 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 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding#1 | Binding#2 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Bonding Option The BID is as defined in [RFC5648], it is a 16-bit unsigned integer. 4.2.2. Traffic Selector MUST be included if only some given IP flows are expected to take benefit of the interfaces bonding. 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 | Length | Reserved | TS Format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Selector ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Bonding Option Type 2 Length The length of following data value in octets. TS Format An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and MUST NOT be used. The value of (1) is assigned for IPv4 Binary Traffic Selector, as defined in section 3.1 of [RFC6088]. Traffic Selector variable-length opaque field for including the traffic specification identified by the TS format field. Seite Expires January 4, 2015 [Page 7] Internet-Draft multihomed RG Interface Bonding Option July 2014 5. Protocol Considerations 5.1. Sending Bonding Request The mobile client sends a Binging update with bindings registration and bonding indication to the mobility anchor. IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option Mobility header Binding Update Mobility Options Bonding Option Bonding attributes Figure 6: Binding Update with Bonding Request 5.2. Receiving Bonding request The mobility anchor registers multiple care-of-addresses as per [RFC6088]. If the binding update contains a bonding option while the mobility anchor is not able to the meet the request, the later shall returns a binding acknowledgement without bonding option. If the mobility anchor has bonding capabilities, it shall process the bonding option as follows: o The bonding option has no attributes: the mobility anchor configure a forwarding interface bonding all bindings registered for the RG/MN home address/prefix. All the IP traffic sent to the home address will be distributed over this interface. o The bonding option carries only Traffic Selector: the mobility anchor configure a forwarding interface bonding all bindings registered for the RG/MN home address/prefix; only packets corresponding to the traffic selectors shall be distributed over this interface. o The bonding option carries only list of bindings: the mobility anchor configure a forwarding interface bonding indicated bindings; then, all the IP traffic sent to the home address will be distributed over this interface. o The bonding option carries both list of bindings and traffic selector: the mobility anchor configure a forwarding interface bonding indicated bindings; only packets corresponding to the traffic selectors shall be distributed over this interface. Seite Expires January 4, 2015 [Page 8] Internet-Draft multihomed RG Interface Bonding Option July 2014 The way the mobility anchor distribute downlink packets on interfaces is out of scope of this document. Note, that it is not mandatory, for the mobility anchor, to use the same distribution scheme than applied at the mobile client side (i.e. RG or MN). 5.3. Tunnelling and packet distribution scheme By default IP-in-IP tunnelling is used between RG and mobility anchor. However, RG and mobility anchor can negotiate using GRE with GRE Key and sequence number extensions [RFC6088], which, for example, could be used by the recipient to reorder packets before delivery. Methods to buffer and reorder packets is out of the scope of this document. How to distribute packets on interfaces is out of scope of this document. Proprietary distribution scheme may require mobility entity to share information (e.g. RG sends its DSL synchronisation rate); in this case the Vendor specific mobility option [RFC5094] can be used for that purpose. Mobility entities are not requested to use the same packet distribution scheme. 5.4. Network controlled aggregation The mobility anchor n enforce its decision to the RG. UPN/UPA could be used to allow the mobility anchor to enforce aggregation rules to the RG. Rules can be either IP flow routing policies or bonding configuration. 6. IANA Considerations This document requires the following IANA action: This specification defines a new mobility option, the Bonding option. The format of this option is described in Section 4.1. The type value for this mobility option needs to be allocated from the Mobility Options registry at . 7. Security Considerations The Bonding option defined in this specification is for use in Binding Update and Binding Acknowledgement messages. This option is carried in these messages like any other mobility header option. [RFC3963] and [RFC6275] identify the security considerations for these signaling messages. When included in these signaling messages, the Bonding option does not require additional security considerations. Seite Expires January 4, 2015 [Page 9] Internet-Draft multihomed RG Interface Bonding Option July 2014 8. Acknowledgements The author would like to thank Sri Gundavelli and Gaetan Feige for having shared thoughts on concepts exposed in this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. Seite Expires January 4, 2015 [Page 10] Internet-Draft multihomed RG Interface Bonding Option July 2014 9.2. Informative References [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, R., and H. Ohnishi, "Multi-homing for small scale fixed network Using Mobile IP and NEMO", RFC 4908, June 2007. Author's Address Pierrick Seite Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange.com Seite Expires January 4, 2015 [Page 11]