Internet DRAFT - draft-seite-dmm-bonding
draft-seite-dmm-bonding
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 <http://www.iana.org/assignments/
mobility-parameters>.
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]