One document matched: draft-seite-dmm-bonding-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2474 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY rfc2475 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY rfc2784 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY rfc2983 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2983.xml">
<!ENTITY rfc3753 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3753.xml">
<!ENTITY rfc3963 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml">
<!ENTITY rfc4908 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4908.xml">
<!ENTITY rfc5094 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5094.xml">
<!ENTITY rfc5213 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY rfc5648 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5648.xml">
<!ENTITY rfc6088 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6088.xml">
<!ENTITY rfc6089 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6089.xml">
<!ENTITY rfc6275 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
]>
<rfc category="std" docName="draft-seite-dmm-bonding-00.txt"
ipr="trust200902">
<front>
<title abbrev="multihomed RG Interface Bonding Option">Multihoming support for Residential Gateway (RG) using IP mobility protocols</title>
<author initials="P." surname="Seite" fullname="Pierrick Seite">
<organization>Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>pierrick.seite@orange.com</email>
</address>
</author>
<date month="July" year="2014" />
<area>Internet</area>
<workgroup>DMM WG</workgroup>
<!-- Abstract -->
<abstract>
<t>
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 <xref target="RFC3753"></xref> and Mobile IPv6 <xref target="RFC6275"></xref>), and their Multiple care-of-address extension <xref target="RFC5648"></xref>, 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.
</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section title="Introduction">
<t>
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.
</t>
<t>
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 <xref target="RFC4908"></xref>. 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 <xref target="RFC6275"></xref>), NEMO <xref target="RFC3963"></xref>) and MCoA <xref target="RFC5648"></xref>) 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 <xref target="sec:archi"></xref>.
</t>
<t>
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 (<xref target="RFC6089"></xref>), 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.
</t>
</section>
<!-- SECTION 2: CONVENTIONS & TERMINOLOGY -->
<section anchor="sec:conventions_terminology" title="Conventions and Terminology">
<!--vspace blankLines="1" /-->
<!-- SECTION 2.1: CONVENTIONS -->
<section anchor="sec:conventions" title="Conventions">
<t>
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 <xref target="RFC2119"/>.
</t>
</section> <!-- conventions -->
<!-- SECTION 2.2: TERMINOLOGY -->
<section anchor="sec:terminology" title="Terminology">
<t>
All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specifications <xref target="RFC3753"></xref>, <xref target="RFC5648"></xref>, <xref target="RFC5213"></xref> and <xref target="RFC6275"></xref>.
</t>
</section> <!-- Terminology -->
</section> <!-- Conventions & Terminology -->
<!-- SECTION Bonding Option - Usage Examples -->
<section anchor="sec:archi" title="Architecture">
<t>
This section proposes to use a NEMO <xref target="RFC3963"></xref> architecture in a fix network context to allow aggregation of the WAN interfaces of an Residential Gateway (RG).
</t>
<t>
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 <xref target="RFC3963"></xref>) protocol and multiple care-of-addresses <xref target="RFC5648"></xref> 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:
<list style="symbols">
<t>At the IP flow level: this scenario is just an application of the current IP flow mobility solution <xref target="RFC6089"></xref>). 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 (<xref target="RFC6088"></xref> and <xref target="RFC6089"></xref>).</t>
<t>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 <xref target="bonding-option-sect"></xref>. Note that specification of packets distribution schemes is out the scope of this document.</t>
</list>
</t>
<t>
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.
</t>
<figure anchor="RG-Bonding-fig" title="Multihomed RG architecture">
<artwork><![CDATA[
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
]]></artwork>
</figure>
<figure anchor="Handset-Bonding-fig" title="Multihomed MN architecture">
<artwork><![CDATA[
]]></artwork>
</figure>
</section>
<!-- SECTION 4: Protocol Messaging Extensions -->
<section anchor="Messaging-sect" title="Protocol Messaging Extensions">
<!-- SECTION : Bonding Mobility Option -->
<section anchor="bonding-option-sect" title="Bonding Option">
<t>
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.
</t>
<t>The alignment requirement for this option is 4n.</t>
<figure anchor="Bonding-option-fig" title="Bonding Option">
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t> <list style="hanging">
<t hangText="Type"></t>
<t>
To be assigned by IANA
</t>
<t hangText="Length"></t>
<t>
8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields.
</t>
<t hangText="Bonding Identifier (BO-ID)"></t>
<t>
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.
</t>
<t hangText="Reserved"></t>
<t>
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.
</t>
<t hangText="Bonding Attributes"></t>
<t> One or more Type-Length-Value (TLV) encoded bonding indication. Attributes are optional.</t>
</list> </t>
</section>
<section anchor="attributes" title="Bonding attributes">
<section anchor="bl-sect" title="Bindings list">
<t>
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.
</t>
<figure anchor="bo-fig" title="Bonding Option">
<artwork>
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t hangText="Binding IDs (BIDs)"></t>
<t> The BID is as defined in <xref target="RFC5648"></xref>, it is a 16-bit unsigned integer.
</t>
</section>
<section anchor="ts-sect" title="Traffic Selector">
<t> MUST be included if only some given IP flows are expected to take benefit of the interfaces bonding.
</t>
<figure anchor="ts-fig" title="Bonding Option">
<artwork>
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 ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t> <list style="hanging">
<t hangText="Type"></t> <t>2</t>
<t hangText="Length"></t> <t>The length of following data value in octets.</t>
<t hangText="TS Format"></t> <t>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 <xref target="RFC6088"></xref>.</t>
<t hangText="Traffic Selector"></t> <t>variable-length opaque field for including the
traffic specification identified by the TS format field.</t>
</list> </t>
</section>
</section>
</section>
<!-- SECTION 5.0: Protocol Configuration -->
<section anchor="sec:pc" title="Protocol Considerations">
<!-- SECTION .1: Bonding Request -->
<section anchor="sec:pc-BR" title="Sending Bonding Request">
<t>
The mobile client sends a Binging update with bindings registration and bonding indication to the mobility anchor.
</t>
<figure anchor="Bonding-BU" title="Binding Update with Bonding Request">
<artwork>
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
Mobility header
Binding Update
Mobility Options
Bonding Option
Bonding attributes
</artwork>
</figure>
</section>
<!-- SECTION .2: receiving Bonding request -->
<section anchor="sec:rec-bd-req" title="Receiving Bonding request ">
<t>
The mobility anchor registers multiple care-of-addresses as per <xref target="RFC6088"></xref>. 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:
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>
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).
</t>
</section>
<section anchor="sec:tun" title="Tunnelling and packet distribution scheme">
<t>
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 <xref target="RFC6088"></xref>, 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.
</t>
<t>
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 <xref target="RFC5094"></xref> can be used for that purpose. Mobility entities are not requested to use the same packet distribution scheme.
</t>
</section>
<section anchor="sec:netw-ctrl" title="Network controlled aggregation">
<t>
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.
</t>
</section>
</section>
<!-- SECTION : IANA Considerations -->
<section anchor="sec:iana" title="IANA Considerations">
<t>
This document requires the following IANA action:
</t>
<t>
This specification defines a new mobility option, the Bonding option. The format of this option is described in <xref target="bonding-option-sect"></xref>. The type value for this mobility option needs to be allocated from the Mobility Options registry at <http://www.iana.org/assignments/mobility-parameters>.
</t>
</section>
<!-- SECTION : Security Considerations -->
<section anchor="Security" title="Security Considerations">
<t>
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. <xref target="RFC3963"></xref> and <xref target="RFC6275"></xref> identify the security considerations for these signaling messages. When included in these signaling messages, the Bonding option does not require additional security considerations.
</t>
</section>
<!-- SECTION: Acknowledgements -->
<section anchor="sec_ack" title="Acknowledgements">
<t>
The author would like to thank Sri Gundavelli and Gaetan Feige for having shared thoughts on concepts exposed in this document.</t>
</section>
</middle>
<back>
<!-- SECTION : References -->
<!-- SECTION .1: Normative References -->
<references title="Normative References">
&rfc2119;
&rfc2784; <!-- GRE -->
&rfc3753;
&rfc3963; <!-- NEMO -->
&rfc5094; <!-- Vendor Option -->
&rfc5213; <!-- pmipv6 -->
&rfc5648; <!-- MCoA -->
&rfc6275; <!-- MIP6 -->
&rfc6088; <!-- TS for IFOM -->
&rfc6089; <!-- IFOM -->
</references>
<!-- SECTION: Informative References -->
<references title="Informative References">
&rfc4908;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:23:47 |