Problem Statement: Bandwidth Aggregation for Internet Access
draft-zhang-banana-problem-statement-02

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: January 5, 2017                                    July 4, 2016

      Problem Statement: Bandwidth Aggregation for Internet Access
              draft-zhang-banana-problem-statement-02.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 issues with bandwidth aggregation for
   Internet access. A set of requirements are derived from the said
   issues.

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 January 5, 2017                 [Page 1]
INTERNET-DRAFT             Problem Statement                July 4, 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  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   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 . . . . . . . . . . . . . . . . . . .  5
     4.5. Bypass  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.6. Measurement . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.7. Policy Control  . . . . . . . . . . . . . . . . . . . . . .  7
   5. Requirements  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1. GRE Tunnel Bonding  . . . . . . . . . . . . . . . . . . . .  9
     6.2. LISP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.4. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . . 10
     6.5. Network Based Layer-2 Tunneling . . . . . . . . . . . . . . 10
   7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
   8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
   9. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A. Additional Requirements  . . . . . . . . . . . . . . . 12
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

1. Introduction

 

BANANA                  Expires January 5, 2017                 [Page 2]
INTERNET-DRAFT             Problem Statement                July 4, 2016

   Bandwidth aggregation across multiple Internet access links (a.k.a.,
   a bonding service) provides several useful features. The working text
   [WT-348] that is being edited by the Broadband Forum describes
   several use cases of a bonding service: Service Providers may use the
   bonding service to provide customers with increased access bandwidth
   and higher access reliability; Service delivery may 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 bonding service is possible, the scope of this
   document is restricted to network-based bonding service. Also, a
   bonding service has to be operated by a single provider. Host-based
   or multi-provider cases will 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 issues from various
   standpoints: traffic forwarding, routing and traffic engineering
   policies, security, etc. This document aims at presenting these
   issues 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 the bonding service, the problems to be
   addressed includes: addresses, traffic classification, distribution
   and recombination, bypassing, measurement, and policy control. To
   address these problems, we may work as a group to 

   -  specify a sole encapsulation format;
   -  develop a common control plane;
   -  and define or suggest the algorithms to be used in packet
      reordering, flow control and congestion control.

2. Acronyms and Terminology

   Bonding Service: A service that relies upon Bandwidth Aggregation
   capabilities that are meant to improve end user's quality of
   experience for Internet access services.

   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
 

BANANA                  Expires January 5, 2017                 [Page 3]
INTERNET-DRAFT             Problem Statement                July 4, 2016

   simultaneous use of both fixed broadband and 3GPP access connections.

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

   DHCP: Dynamic Host Configuration Protocol [RFC2131].

   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 bonding service

   Customers access the Internet using the bonding service 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. The bonding connection is usually established at the IP
   or the transport levels. Sub-connections are usually established at
   the IP or transport levels, but could be established at the link
   level.

4. Problem Areas

   The following subsections list the problems that need to be solved by
   bonding service solutions. 

4.1. Addressing

   HG and HAAP need to allocate addresses to the interfaces attached to
   each sub-connection as well as the whole bonding connection. IPv4,
   IPv6 or dual-stack operation ought to be supported. Sub-connections
   can be de-multiplexed by their interface addresses. Upon bootstrap,
 

BANANA                  Expires January 5, 2017                 [Page 4]
INTERNET-DRAFT             Problem Statement                July 4, 2016

   these connection addresses are acquired by the other end by means of
   a specific protocol, such as DHCP or MPTCP. The connection addresses
   of HG may thus be dynamically assigned by the HAAP.

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 packet which is to be
   further processed by the traffic distribution function.
   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 another sub-connection.

   There are two kinds of traffic distribution methods for the bonding
   service: 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
   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 use case, the load can be distributed using hashing
   methods. For the per-packet use case, the coloring mechanism
   specified in [RFC2698] can be used to classify customer's IP packets,
   both upstream and downstream, and packets will then be 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 per-packet use case, the recombination function at the
 

BANANA                  Expires January 5, 2017                 [Page 5]
INTERNET-DRAFT             Problem Statement                July 4, 2016

   receiver sides reorders packets to preserve the integrity of the
   communication. The sender needs to mark each packet with a sequence
   number. The sequence number MUST be set per the whole bandwidth
   aggregation rather than per sub-connection so that all packets
   forwarded over several sub-connections actually share the same
   reordering buffer.

   For the per-flow use case, an acknowledge number field appears in the
   packets in order to support congestion and flow control. In order to
   support such control, the sender needs also to maintain a sending
   buffer. See Section 3.3.2 of [RFC6824] for an example. 

4.5. Bypass

   Service Providers may require some traffic to bypass the bonding
   service. 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 anymore. In either case, the bypassing traffic would not
   be under control of the bonding service scheme. 

   HG and HAAP needs to exchange information about bypassing, such as
   the application types that need to bypass the bonding service and the
   bandwidth occupied by the bypassing traffic (See also Section 4.6).  

4.6. Measurement

   HG and HAAP need to monitor and exchange performance parameters of
   the bonding service, 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. 

   -  End-to-end delay and packet delay variation: The measurement of
      this parameter is used by flow and congestion control algorithms
      for per-flow and per-packet distribution purposes. The probing
 

BANANA                  Expires January 5, 2017                 [Page 6]
INTERNET-DRAFT             Problem Statement                July 4, 2016

      packet could be piggy-backed by data packets or could be carried
      by out-of-band 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 downward bypassing bandwidth used in a sub-connection
      so that the HAAP can calculate the remaining downward bandwidth of
      this sub-connection. 

4.7. Policy Control

   Operators and customers may control the bonding service 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 determine the maximum allowed size (See
      MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering.
      They 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 may specify the frequency for detecting a sub-connection
      and the detection retry times before a sub-connection can be
      declared as "failed". Operators may specify maximum value of the
      difference between two measured one-way transit delays.

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

5. Requirements

   Requirements for the bonding service 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.

 

BANANA                  Expires January 5, 2017                 [Page 7]
INTERNET-DRAFT             Problem Statement                July 4, 2016

   The solution MUST NOT require any new capability to support bonding
   service from the host.

   In the bonding service, 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 bonding service. For example,

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

      - 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
 

BANANA                  Expires January 5, 2017                 [Page 8]
INTERNET-DRAFT             Problem Statement                July 4, 2016

        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

   Bonding service 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 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 implemented and deployed. Flow and
   congestion control could be supported within the tunnel through
   extending the GRE header, though it is currently out of the scope.

6.2. LISP

   LISP has the basic capability to support the bonding service [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

   [MIP-HA] investigates how to support the bonding service by using IP
   mobility protocols. By treating the bonding service as a special
   scenario of IP mobility, some mechanisms (such as redundancy and load
 

BANANA                  Expires January 5, 2017                 [Page 9]
INTERNET-DRAFT             Problem Statement                July 4, 2016

   balancing) that are supported by IP mobility protocols could be
   reused. However, IP mobility protocols have to be tailored in order
   to mitigate the complexity of their operation, let alone their
   scalability.

   A new multipath binding option is proposed as an extension of PMIPv6
   in [MIP-HA]. This option can be used to exchange the binding
   information, such as the Access Technology Type [RFC5213], the
   Interface Label and Binding ID, between peers. 

   Currently, per-flow traffic management is well supported by IP
   mobility protocols (such as  [RFC6088] and [RFC6089]) while packet-
   based traffic distribution is left for future work.

6.4. Multipath TCP

   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 bonding service 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 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. [MPTCP-HA] discuss MPTCP proxy deployment
   concerns and also specifies an extension to transport UDP datagrams
   in MPTCP packets. UDP traffic can therefore be forwarded over a MPTCP
   connection.

6.5. Network Based Layer-2 Tunneling

   Network Based Layer-2 Tunneling assigns a single IP address at each
   peer for the bonding connection. Layer-2 tunnels are set up per sub-
   connections. Layer 2 load balancing techniques, such as Link
   Aggregation [802.1AX] can be used to achieve the traffic distribution
   function. Packet-based distribution might be supported as well.
   However, per-packet distribution may cause the packets to be received
   as out-of-sequence, which is an issue that is yet-to-be-addressed by
   the Network Based Layer-2 Tunneling.

7. Security Considerations

   The bonding service adds new capabilities. It also introduces new
   threats to the network. For example, traffic sent on unsecured sub-
 

BANANA                  Expires January 5, 2017                [Page 10]
INTERNET-DRAFT             Problem Statement                July 4, 2016

   connections would be easily intercepted by an attacker who performs
   man-in-the-middle attack. The 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. RFC Editor: please
   remove this section before publication.

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, March 1997.

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             March 1997.

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

   [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
             RFC 2890, September 2000.

10.2. Informative References

   [WT-348]  Broadband Forum Work on "Hybrid Access for Broadband
             Networks" (WT-348), October 21, 2014,
             <http://datatracker.ietf.org/liaison/1355/>.

   [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
 

BANANA                  Expires January 5, 2017                [Page 11]
INTERNET-DRAFT             Problem Statement                July 4, 2016

             Addresses", RFC 6824, January 2013.

   [MPTCP-HA] 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, August
             2008.

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

   [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).
 

BANANA                  Expires January 5, 2017                [Page 12]
INTERNET-DRAFT             Problem Statement                July 4, 2016

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

      - 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 January 5, 2017                [Page 13]
INTERNET-DRAFT             Problem Statement                July 4, 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 January 5, 2017                [Page 14]
INTERNET-DRAFT             Problem Statement                July 4, 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 January 5, 2017                [Page 15]