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]