[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

INTERNET-DRAFT                                                 M. Cullen
Intended Status: Informational                         Painless Security
                                                              N. Leymann
                                                            C. Heidemann
                                                     Deutsche Telekom AG
                                                            M. Boucadair
                                                          France Telecom
                                                                 H. Deng
                                                            China Mobile
                                                                M. Zhang
                                                             B. Sarikaya
                                                                  Huawei
Expires: May 4, 2017                                    October 31, 2016

      Problem Statement: Bandwidth Aggregation for Internet Access
              draft-zhang-banana-problem-statement-03.txt

Abstract

   Bandwidth aggregation capabilities for Internet access services can
   significantly improve end user's Quality of Experience. Such
   capabilities are especially attractive in environments where multi-
   interfaced boxes become commonplace and can technically connect to
   various access networks, both wired and wireless.

   This document describes the problems with bandwidth aggregation for
   Internet access. A set of requirements are derived from the said
   problems.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html



BANANA                    Expires May 4, 2017                   [Page 1]


INTERNET-DRAFT             Problem Statement            October 31, 2016


Copyright and License Notice

   Copyright (c) 2016 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.


Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Acronyms and Terminology  . . . . . . . . . . . . . . . . . . .  3
   3. Generic Reference Model . . . . . . . . . . . . . . . . . . . .  4
   4. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1. Addressing  . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2. Traffic Classification  . . . . . . . . . . . . . . . . . .  5
     4.3. Traffic Distribution  . . . . . . . . . . . . . . . . . . .  5
     4.4. Traffic Recombination . . . . . . . . . . . . . . . . . . .  6
       4.4.1. Reordering Buffer . . . . . . . . . . . . . . . . . . .  6
     4.5. Bypass  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.6. Measurement . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.7. Policy Control  . . . . . . . . . . . . . . . . . . . . . .  8
   5. Requirements  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1. GRE Tunnel Bonding  . . . . . . . . . . . . . . . . . . . . 10
     6.2. LISP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.4. Multipath TCP Proxy . . . . . . . . . . . . . . . . . . . . 11
   7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
   8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   9. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A. Additional Requirements  . . . . . . . . . . . . . . . 14
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16







BANANA                    Expires May 4, 2017                   [Page 2]


INTERNET-DRAFT             Problem Statement            October 31, 2016


1. Introduction

   Use cases of BANdwidth Aggregation for interNet Access (BANANA,
   a.k.a., Hybrid Access) are described in the Technical Report [TR-348]
   published by Broadband Forum: by providing Hybrid Access, Service
   Providers can provide customers with increased access bandwidth and
   higher access reliability; Service delivery may also be fostered to
   access the Internet by means of providing a LTE (Long Term Evolution)
   connection while the wired line is being constructed.

   Although host-based Hybrid Access is possible, the scope of this
   document is restricted to be network-based only. Host-based might be
   standardized in other places, such as the MIF Working Group.

   Design techniques that are being investigated, developed and
   sometimes deployed to facilitate bandwidth aggregation and improve
   the resiliency of access conditions raise several problems from
   various standpoints: traffic routing and forwarding, congestion
   control, security, etc. This document aims at presenting these
   problems regardless of the nature of the design technique. It also
   intends to derive requirements accordingly, and which should be
   addressed by any bandwidth aggregation technique. Typically, this is
   one of the inputs that are expected from the IETF community.

   A common framework will be sketched, including required functional
   modules and interactions. The various solution proposals (e.g., GRE,
   LISP, MIP, MPTCP) can be viewed as applicability assessments of the
   framework. To support BANANA, the problems to be addressed includes:
   addressing, traffic classification, distribution and recombination,
   bypassing, measurement and policy control. To address these problems,
   we may work as a group to

   -  specify the encapsulation format;
   -  develop a common control plane;
   -  and define or suggest approaches to address BANANA problems
      developed in this document.

2. Acronyms and Terminology

   Hybrid Access: The coordinated and simultaneous use of two
   heterogeneous access paths (e.g., DSL and LTE) [TR-348].

   CPE: Customer Premises Equipment. An equipment which is the property
   of the network operator and located on the customer premises.

   HG: Home Gateway. A CPE device that is enhanced to support the
   simultaneous use of both fixed broadband and 3GPP access connections.




BANANA                    Expires May 4, 2017                   [Page 3]


INTERNET-DRAFT             Problem Statement            October 31, 2016


   HAAP: Hybrid Access Aggregation Point. A logical function in
   Operator's network, terminating bonded connections while offering
   high speed Internet.

   PDP: Packet Data Protocol. A packet transfer protocol used in
   wireless GPRS (General Packet Radio Service)/HSDPA (High Speed
   Downlink Packet Access) networks.

   PPPoE: Point-to-Point Protocol over Ethernet is a network protocol
   for encapsulating PPP frames inside Ethernet frames.

   DHCP: Dynamic Host Configuration Protocol [RFC2131].

   DNS: Domain Name System [RFC1035].

   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].

3. Generic Reference Model

               +--+                             +----+
               |  +----- bonding connection ----+    |
               |  |                             |    |
               |  |                             |    |
               |HG|i/f --- sub-connection ---i/f|HAAP|
               |  |           . . .             |    |
               |  |i/f --- sub-connection ---i/f|    |
               |  |                             |    |
               +--+                             +----+


            Figure 3.1: Reference model of the Hybrid Access

   Customers access the Internet using the Hybrid Access which comprises
   of several key component functions as shown in Figure 3.1: the Home
   Gateway (HG) as one peer, the Hybrid Access Aggregation Point (HAAP)
   as the other peer, the bonding connection between the two peers and
   the sub-connections that logically make up the bonding connection.

4. Problem Areas

4.1. Addressing

   At the HG side, interface addresses of sub-connections are locally
   acquired upon the bootstrap of the system by means of certain
   existing protocols such as Point-to-Point Protocol over Ethernet
   (PPPoE) [RFC2516] and Packet Data Protocol (PDP). At the HAAP side,



BANANA                    Expires May 4, 2017                   [Page 4]


INTERNET-DRAFT             Problem Statement            October 31, 2016


   interface addresses are usually pre-configured by operators. HG and
   HAAP will rely on the control protocol that is to be developed to
   exchange these addresses. Afterwards, sub-connections are de-
   multiplexed by their interface addresses. Both IPv4 and IPv6 should
   be supported.

   End users behind the HG box will regard the bonding connection as a
   traditional connection to the Internet. With the established sub-
   connections, connectivity between the HG and HAAP has been built up,
   therefore endpoint addresses for this bonding connection can be
   obtained from existing protocols, e.g., DHCP and DNS.

4.2. Traffic Classification

   Traffic classification occurs before the flows or packets are
   distributed among the connections. HG and HAAP should support the
   classification function that marks a flow or packets which are to be
   further processed by the traffic distribution function or bypass the
   Hybrid Access (See Section 4.5). Classification criteria include IP
   addresses, port numbers, etc. Traffic classification policies can be
   defined by end users and service providers and must be enforced by
   the HG and HAAP equipments.

4.3. Traffic Distribution

   For traffic that is to be distributed across multiple sub-
   connections, equal load balancing generally applies, possibly
   inferred by the bandwidth that is available in each link that
   supports sub-connection. Unequal load balancing should be supported
   as well. Traffic may be distributed across sub-connections as a
   function of their available bandwidth. Traffic may also be split in
   such a way that whenever one sub-connection is saturated, then
   traffic is forwarded over a secondary sub-connection.

   There are two kinds of traffic distribution methods for the Hybrid
   Access: per-flow load balancing and per-packet load sharing. The per-
   flow load balancing method is used to be widely adopted in core IP
   networks. It is suitable for the scenario where there are a large
   number of flows to be distributed. For end users, usually there are
   few number of applications to be transmitted over the bonded sub-
   connections. Per-flow load balance techniques might not be able to
   achieve a fine grained load distribution, so that the per-packet load
   sharing is necessary.

   For the per-flow load balancing, the load can be distributed using
   hashing methods. For the per-packet load splitting, the coloring
   mechanism specified in [RFC2698] can be used to classify customer's
   IP packets, both upstream and downstream, and packets will then be



BANANA                    Expires May 4, 2017                   [Page 5]


INTERNET-DRAFT             Problem Statement            October 31, 2016


   forwarded over the appropriate sub-connections. For example, packets
   colored as green are forwarded over one sub-connection and packets
   colored as yellow are forwarded over another sub-connection. For
   scenarios that rely upon more than two sub-connections, multiple
   levels of coloring mechanism could be implemented.

4.4. Traffic Recombination

   For the packet-based traffic distribution, the recombination function
   at the receiver sides must reorder packets to preserve the integrity
   of the communication. The sender needs to mark each packet with a
   sequence number. The sequence number are set per the whole bonding
   connection rather than per sub-connection so that all packets
   forwarded over several sub-connections actually share the same
   reordering buffer.

4.4.1. Reordering Buffer


               Ingress|   flying packets   |Egress
                      | +---+   +---+---+  |
                      | | 99|...|  3|  1|  |
                      | +---+   +---+---+  |
                      |                    |
                      | ------- LTE -----> |
                      |                    |
                      |                    |
                      |                    | +---+   +---+---+
                      |                    | |100|...|  4|  2|
                      | ------- DSL -----> | +---+   +---+---+
                      |                    |50 buffered packets
                      |                    |


              Figure 4.1: Minimizing the reordering buffer

   Deployment experiences show that a secondary sub-connection might
   suffer from large latency, jitter and high packet loss rate. For
   packet-based traffic distribution, packets are distributed onto those
   sub-connections at the ingress and then recombined again in a buffer
   at the egress. If the secondary sub-connection suffers, the entire
   bonding connection will suffer as well due to the recombination
   function. For example, assume packet 1,3,...,99 are distributed onto
   the secondary sub-connection while packet 2,4,...,100 are distributed
   onto the primary sub-connection. If packet 1 is delayed by 100 ms,
   even packet 2 arrives at the recombination buffer at the first
   millisecond, it has to remain in the buffer awaiting for packet 1 as
   long as 99 ms. Packets distributed onto the primary sub-connection,



BANANA                    Expires May 4, 2017                   [Page 6]


INTERNET-DRAFT             Problem Statement            October 31, 2016


   which arrive after packet 2, have to be buffered. This can easily
   lead to the overflow of the reordering buffer and the user's TCP
   throughput of the bonding connection might be greatly reduced.

   Latency of each sub-connection will be monitored. For example, HG and
   HAAP may calculate the Adaptive Acknowledgment Time-Out of each sub-
   connection as specified in [RFC2637]; HG and HAAP may periodically
   exchange control messages to detect the RTT of each sub-connection
   [FLARE]; Packet loss rate of each sub-connection may be monitored as
   well [BondL3]. If the difference of the monitored latency exceeds a
   predefined threshold or the secondary sub-connection exhibits a too
   high packet loss rate, attached HG and HAAP will stop distributing
   traffic onto this sub-connection.

   Even if the latency of the two sub-connections are comparable and the
   packet loss rate of the secondary sub-connection is fine so that the
   reordering buffer does not overflow, it's still worthy to design
   solutions to minimize the usage of the reordering buffer. In order to
   realize this goal, the traffic distribution at the ingress should be
   manipulated. For example, the idea of [FLARE] might be borrowed:
   basically, a traffic flow would be split into "flowlets" by the gaps
   between the arriving packets. Packets of a specific flowlet is solely
   distributed onto one sub-connection. In this way, reordering is
   avoided or minimized. The load-balancing method of MPTCP [RFC6824]
   could be used as well: packets are always distributed to the sub-
   connection with the least congestion level and/or latency
   [MPscheduler].

4.5. Bypass

   Service Providers may require some traffic to bypass the Hybrid
   Access. For example, some delay sensitive applications such as live
   TV broadcasting carried over a lossy sub-connection would impair
   customers' Quality of Experience. Service providers could then make
   sure that such traffic is forwarded over a set of wired sub-
   connections only, thereby disregarding low-rate mobile connections,
   for example.

   There are two types of bypass: the bypassing traffic are transmitted
   on a sub-connection out of all the sub-connections between HG and
   HAAP; the bypassing traffic is still transmitted on a sub-connection
   between HG and HAAP, just that the occupied bandwidth of the
   bypassing traffic on this sub-connection can not used for bandwidth
   aggregation. In either case, the bypassing traffic would not be under
   control of the Hybrid Access scheme.

   HG and HAAP needs to exchange information about bypassing through the
   control protocol, such as the application types that need to bypass



BANANA                    Expires May 4, 2017                   [Page 7]


INTERNET-DRAFT             Problem Statement            October 31, 2016


   the Hybrid Access and the bandwidth occupied by the bypassing traffic
   (See also Section 4.6).

4.6. Measurement

   HG and HAAP need to measure and exchange performance parameters of
   the Hybrid Access, including performance parameters that pertain to
   each sub-connection that belongs to the same connection. Such
   parameters include (but are not necessarily limited to):

   -  Operating state: The operating state has to be measured by control
      messages. When a sub-connection fails, this sub-connection has to
      be removed from the bonding connection.

   -  Round Trip Time (RTT): The measurement of this parameter is used
      by flow and congestion control algorithms for per-flow and per-
      packet distribution purposes. The probing packet could be piggy-
      backed by data packets or could be carried by control messages.

   -  Maximum sub-connection bandwidth: This parameter may be used to
      determine the amount of traffic that can be distributed across all
      or a subset of sub-connections.

   -  Bypassing bandwidth: This parameter has to be periodically
      monitored. Usually, this is measured for the opposite end to
      figure out the available sending bandwidth. For example, the HG
      reports the downloading bypassing bandwidth used in a sub-
      connection so that the HAAP can calculate the remaining
      downloading bandwidth of this sub-connection.

4.7. Policy Control

   Operators and customers may control the Hybrid Access with policies.
   These policies will be instantiated into parameters or actions that
   impact traffic classification, distribution, combination, measurement
   and bypassing. Such policies may consist in:

   -  Defining traffic filter lists used by the traffic classification
      function.

   -  Per-flow or per-packet forwarding policies.

   -  Operators may specify maximum value of the difference between two
      measured one-way transit delays. Operators may also specify the
      maximum allowed packet loss rate of a sub-connection.

   -  Operators may determine the maximum allowed size (See
      MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering.



BANANA                    Expires May 4, 2017                   [Page 8]


INTERNET-DRAFT             Problem Statement            October 31, 2016


      Operators may also define the maximum time (See OUTOFORDER_TIMER
      in [RFC2890]) that a packet can stay in the buffer for reordering.
      These parameters may pact traffic recombination.

   -  Operators and customers may specify the service types to bypass
      the Hybrid Access.

   -  Operators may specify the frequency for detecting a sub-connection
      and the detection retry times before a sub-connection can be
      declared as "failed".

5. Requirements

   Requirements for the Hybrid Access are described in this section.
   Also, some additional requirements are listed for discussion in the
   Appendix.

   The solution MUST apply for both IPv4 and IPv6 traffic.

   The solution MUST NOT require any new capability to support Hybrid
   Access from the host.

   In the Hybrid Access, forwarding traffic flows over various
   interfaces may have a negative impact on customers' experience (e.g.,
   hazardous log outs, broken HTTPS associations, etc.). The solution
   should be carefully designed, so that

      - activating the solution MUST NOT impact the stability,
        availability of the services delivered to the customer compared
        to customers who access the same service whose traffic is
        forwarded along a single path.

   "Roles" (primary or backup) should be assigned to each supported
   network interface type (e.g., fixed or mobile access). This role is
   assigned by the network operator (e.g., fixed access can be set as
   the "primary"). Note that there may be more than two sub-connections
   to support primary and backup roles. A default setting can be
   considered.

      - Setting of the role of the sub-connections SHOULD NOT be changed
        by the user.

   The solution should provide Service Providers with means to enforce
   policy control of the Hybrid Access. For example,

      - the solution MUST allow to rate limit the traffic on a per-
        interface basis.




BANANA                    Expires May 4, 2017                   [Page 9]


INTERNET-DRAFT             Problem Statement            October 31, 2016


      - the solution MUST support means to enable/disable the activation
        of multiple interfaces at the HG.

      - the solution MUST support means to instruct the HG about the
        logic for mounting interfaces.

      - the solution MUST support means to bind a given traffic to a
        subset of interfaces.

   For the sake of policy enforcement or analytics at the network side,

      - the solution MAY ease correlating flows, conveyed over multiple
        access networks, and which belong to the same customer.

   Some services such as VoIP may be available over all active
   interfaces, but distinct logins and credentials may be used.

      - The HG SHOULD be provided with clear instructions about which
        account to use to place outgoing sessions. For the sake of
        simplicity, it is RECOMMENDED to use the login/credentials that
        are independent of the underlying access network used to access
        the service.

6. Related IETF Work

   Hybrid Access designs can rely upon several solutions. The following
   subsections recap the work that has been or is being conducted by the
   IETF in this area. Note that solutions are listed in an alphabetic
   order. No preference order should be assumed by the reader.

6.1. GRE Tunnel Bonding

   GRE Tunnel Bonding [GRE-HA] uses per-packet traffic distribution to
   achieve a fine-grained load sharing among the sub-connections. Out-
   of-sequence packets may be received at the egress so that reordering
   function is provided. IP packets are encapsulated in the GRE header
   which is in turn encapsulated in an outer IP header and forwarded
   over the sub-connections. The Sequence Number field of the GRE header
   is used to number the packets at the sender side, while the receiver
   uses of this sequence number to reorder the packets.

   A new control plane is defined. Control messages are transported in
   the same GRE tunnels that are used to transport data packets. The
   control messages and data packets are distinguished by the GRE
   Protocol Type 0xB7EA.

   GRE tunnel bonding has been deployed by Deutsche Telekom AG and
   Austria Telekom.



BANANA                    Expires May 4, 2017                  [Page 10]


INTERNET-DRAFT             Problem Statement            October 31, 2016


6.2. LISP

   LISP has the basic capability to support the Hybrid Access [LISP-HA]
   [ILNP]. LISP can be used to enforce traffic engineering based upon
   static load balancing that is not agnostic to link characteristics.

   Packet-based traffic distribution has been considered in [LISP-HA] as
   well. The detail specification of the reordering mechanism based on a
   "Reorder" flag is left for future work.

6.3. Mobile IP

   Mobile IP [RFC3775] and Network Mobility (NEMO; [RFC3963]) used to
   handle multiple L3 connectivity to the Internet via multiple ISPs for
   a multi-homed end user [RFC4908]. By treating Hybrid Access as a
   special scenario, some existing capabilities of Mobile IP and NEMO
   could be reused to realize Hybrid Access. Take [MIP-HA] as an
   example, rely on the multiple Care-of Addresses (CoAs) capability
   [RFC5648] [RFC6275], the "addressing" problem of BANANA could be
   settled. Currently, per-flow traffic distribution has already been
   supported by Mobile IP and NEMO ([RFC6088], [RFC6089]) while packet-
   based traffic distribution is left for future work [MIP-HA].

6.4. Multipath TCP Proxy

   MPTCP provides the ability to establish a communication over multiple
   paths, by means of sub-flow establishment and operation [RFC6824].
   However, the traditional MPTCP is a host-based technology therefore
   it's out the scope of this document. What is considered as a
   candidate technology to support the Hybrid Access is the MPTCP proxy
   mechanism. There are some implementations and deployments.

   The MPTCP proxy operates at the transport layer and locates in the
   operator's network. A transparent MPTCP mode is proposed in [MPTCP-
   trans]: a MPTCP proxy terminates a user's TCP flow and reinitiates
   MPTCP sub-flows towards the other MPTCP proxy; The other MPTCP proxy
   will terminate the MPTCP sub-flows and restore the user's TCP flow;
   The MPTCP protocol suite provides features to manage the state of
   sub-flows between the two proxies. [MPTCP-plain] discusses MPTCP
   proxy (i.e., transparent MPTCP mode) deployment concerns and also
   specifies an extension to transport UDP datagrams in MPTCP packets.
   UDP traffic can therefore be forwarded over a MPTCP connection.

7. Security Considerations

   Hybrid Access might introduce new threats to the network. For
   example, traffic sent on unsecured sub-connections would be easily
   intercepted by an attacker who performs man-in-the-middle attack. The



BANANA                    Expires May 4, 2017                  [Page 11]


INTERNET-DRAFT             Problem Statement            October 31, 2016


   multi-path communication may be leveraged to perform Denial of
   Service (DoS) attack or Distributed Denial of Service (DDoS) attack
   (e.g., based upon flooding traffic) that may jeopardize the
   aggregation gateway as well as the access equipment and end station
   operation.

   These kind of new security issues should be carefully considered in
   designing solutions that aim to address the problems of Bandwidth
   Aggregation for Internet Access.

8. IANA Considerations

   No IANA action is required in this document.

9. Acknowledgements

   Authors would like to thank the comments and suggestions from
   Christian Jacquenet and Li Xue.

10. References

10.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, DOI
             10.17487/RFC2119, March 1997, <http://www.rfc-
             editor.org/info/rfc2119>.

   [TR-348]  Broadband Forum, "Technical Report on Hybrid Access
             Broadband Network Architecture", July, 2016,
             <https://www.broadband-forum.org/technical/download/TR-
             348.pdf>.

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             DOI 10.17487/RFC2131, March 1997, <http://www.rfc-
             editor.org/info/rfc2131>.

   [RFC1035] Mockapetris, P., "Domain names - implementation and
             specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
             November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
             and R. Wheeler, "A Method for Transmitting PPP Over
             Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February
             1999, <http://www.rfc-editor.org/info/rfc2516>.

   [RFC2689] Bormann, C., "Providing Integrated Services over Low-
             bitrate Links", RFC 2689, DOI 10.17487/RFC2689, September



BANANA                    Expires May 4, 2017                  [Page 12]


INTERNET-DRAFT             Problem Statement            October 31, 2016


             1999, <http://www.rfc-editor.org/info/rfc2689>.

   [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
             RFC 2890, DOI 10.17487/RFC2890, September 2000,
             <http://www.rfc-editor.org/info/rfc2890>.

10.2. Informative References

   [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
             and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
             RFC 2637, DOI 10.17487/RFC2637, July 1999, <http://www.rfc-
             editor.org/info/rfc2637>.

   [BondL3]  Maciej Bednarek, Guillermo Barrenetxea, Mirja Mirja
             Kuehlewind and Brian Trammell, "Multipath bonding at Layer
             3", Applied Networking Research Workshop, July 16, 2016,
             Berlin, Germany

   [FLARE]   Srikanth Kandula, Dina Katabi, Shantanu Sinha, and Arthur
             Berger, "Dynamic Load Balancing Without Packet Reordering",
             ACM SIGCOMM Computer Communication Review, April 2007.

   [MPscheduler] Hyunwoo Nam, Doru Calin and Henning Schulzrinne,
             "Towards Dynamic MPTCP Path Control Using SDN", IEEE
             NetSoft Conference and Workshops (NetSoft), June 2016.

   [GRE-HA]  N. Leymann, C. Heidemann, M. Zhang, et al, "GRE Tunnel
             Bonding", draft-zhang-gre-tunnel-bonding, work in progress.

   [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
             Extensions for Multipath Operation with Multiple
             Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
             <http://www.rfc-editor.org/info/rfc6824>.

   [MPTCP-tans] B. Peirens, G. Detal, S. Barre and O. Bonaventure, "Link
             bonding with transparent Multipath TCP", draft-peirens-
             mptcp-transparent, work in progress.

   [MPTCP-plain] M. Boucadair and C. Jacquenet, "An MPTCP Option for
             Network-Assisted MPTCP Deployments: Plain Transport Mode",
             draft-boucadair-mptcp-plain-mode, work in progress.

   [MIP-HA]  P. Seite, A. Yegin and S. Gundavelli, "Multihoming support
             for Residential Gateways", draft-seite-dmm-rg-multihoming,
             work in progress.

   [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury,
             K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI



BANANA                    Expires May 4, 2017                  [Page 13]


INTERNET-DRAFT             Problem Statement            October 31, 2016


             10.17487/RFC5213, August 2008, <http://www.rfc-
             editor.org/info/rfc5213>.

   [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
             "Traffic Selectors for Flow Bindings", RFC 6088, DOI
             10.17487/RFC6088, January 2011, <http://www.rfc-
             editor.org/info/rfc6088>.

   [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, DOI
             10.17487/RFC6089, January 2011, <http://www.rfc-
             editor.org/info/rfc6089>.

   [802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area
             Networks - Link Aggregation", 802.1AX-2014, 24 December
             2014.

   [LISP-HA] M. Menth, A. Stockmayer and M. Schmidt, "LISP Hybrid
             Access", draft-menth-lisp-ha, work in progress.

   [ILNP]    "ILNP - Identifier-Locator Network Protocol", online
             available: http://ilnp.cs.st-andrews.ac.uk/

Appendix A. Additional Requirements

   The following requirements are listed as record and may subject to
   change.

      - The solution MUST be valid for any kinds of interfaces that need
        to be aggregated.  No dependency to the underlying media should
        be assumed.

      - The solution MUST comply with servers policy regarding IP
        addresses that are bound to (HTTP session) cookies.

      - The solution MUST NOT break TLS associations.

      - Activating the solution MUST NOT have negative impacts on the
        service usability (including the HG management).

      - Service degradation MUST NOT be observed when enabling the
        solution.

      - Enabling the solution MUST increase the serviceability of the
        HG. In particular, the solution MUST allow for the HG to always
        establish a network attachment when the primary connectivity is
        out of service.



BANANA                    Expires May 4, 2017                  [Page 14]


INTERNET-DRAFT             Problem Statement            October 31, 2016


      - The solution SHOULD NOT alter any mechanism, to aggregate
        available resources or to ensure a service continuity among
        multiple access points, that is supported by end-devices
        connected to the HG.

      - The HG MUST bind the DNS server(s) discovered during the network
        attachment phase to the interface from which the information was
        received.

      - The HG MUST bind the service information (e.g., SIP Proxy
        Server) discovered during the network attachment phase to the
        interface from which the information was received.

      - When sending the traffic via a given interface, the HG MUST use
        as source address an address (or an address from a prefix) that
        was assigned for that interface.

      - For protocols such as RTP/RTCP, the same IP address MUST be used
        for both RTP and RTCP sessions.

      - Dedicated tools SHOULD be provided to the customer to assess the
        aggregated capacity (instead of link-specific). This can be
        included as part of the HG UI, a dedicated portal, etc.




























BANANA                    Expires May 4, 2017                  [Page 15]


INTERNET-DRAFT             Problem Statement            October 31, 2016


Author's Addresses


   Margaret Cullen
   Painless Security
   14 Summer St. Suite 202
   Malden, MA 02148  USA

   EMail: margaret@painless-security.com


   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21-27
   Berlin  10781
   Germany

   Phone: +49-170-2275345
   EMail: n.leymann@telekom.de


   Cornelius Heidemann
   Deutsche Telekom AG
   Heinrich-Hertz-Strasse 3-7
   Darmstadt  64295
   Germany

   Phone: +4961515812721
   EMail: heidemannc@telekom.de


   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   EMail: mohamed.boucadair@orange.com


   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   EMail: denghui@chinamobile.com




BANANA                    Expires May 4, 2017                  [Page 16]


INTERNET-DRAFT             Problem Statement            October 31, 2016


   Mingui Zhang
   Huawei Technologies
   No.156 Beiqing Rd. Haidian District,
   Beijing 100095 P.R. China

   EMail: zhangmingui@huawei.com

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Dr. Building 3
   Plano, TX  75024

   EMail: sarikaya@ieee.org






































BANANA                    Expires May 4, 2017                  [Page 17]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/