| 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
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.
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 (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 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.
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.
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.
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].
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].
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).
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:
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.
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
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.
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
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.
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.
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
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
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:
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).
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.
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.
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 <http://www.iana.org/assignments/mobility-parameters>.
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.
The author would like to thank Sri Gundavelli and Gaetan Feige for having shared thoughts on concepts exposed in this document.
| [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. |