[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 5, 2016                                    November 2, 2015

      Problem Statement: Bandwidth Aggregation for Internet Access
              draft-zhang-banana-problem-statement-01.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 May 5, 2016                   [Page 1]


INTERNET-DRAFT             Problem Statement            November 2, 2015


Copyright and License Notice

   Copyright (c) 2015 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 May 5, 2016                   [Page 2]


INTERNET-DRAFT             Problem Statement            November 2, 2015


   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 can be discussed here but 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.

   ACC: Short for ACCess equipment. ACC connects user's end station or
   Customer-Premises Equipment (CPE) to the network that supports a
   bonding service.




BANANA                    Expires May 5, 2016                   [Page 3]


INTERNET-DRAFT             Problem Statement            November 2, 2015


   AGG: Short for AGGregation equipment. AGG faces to the Internet while
   acts as an aggregation gateway that is responsible for handling
   communications established over multiple paths from ACCs.

   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 ----+ |
               |A|                             |A|
               | |                             | |
               |C|i/f --- sub-connection ---i/f|G|
               | |           . . .             | |
               |C|i/f --- sub-connection ---i/f|G|
               | |                             | |
               +-+                             +-+

           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 access peer (shorted as ACC), the aggregation peer (shorted as
   AGG), 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

   ACC and AGG 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,
   these connection addresses are acquired by the other end by means of
   a specific protocol, such as DHCP or MPTCP. The connection addresses
   of ACC may thus be dynamically assigned by the AGG.




BANANA                    Expires May 5, 2016                   [Page 4]


INTERNET-DRAFT             Problem Statement            November 2, 2015


4.2. Traffic Classification

   Traffic classification occurs before the flows or packets are
   distributed among the connections. ACC and AGG 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 ACC and AGG 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
   receiver sides reorders packets to preserve the integrity of the
   communication. The sender needs to mark each packet with a sequence
   number. The sender need to mark each packet with a sequence number.
   The sequence number MUST be set per the whole bandwidth aggregation



BANANA                    Expires May 5, 2016                   [Page 5]


INTERNET-DRAFT             Problem Statement            November 2, 2015


   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 ACC and
   AGG; the bypassing traffic is still transmitted on a sub-connection
   between ACC and AGG, 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.

   ACC and AGG 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

   ACC and AGG 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
      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



BANANA                    Expires May 5, 2016                   [Page 6]


INTERNET-DRAFT             Problem Statement            November 2, 2015


      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 ACC
      reports the downward bypassing bandwidth used in a sub-connection
      so that the AGG 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.

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

   In the bonding service, forwarding traffic flows over various



BANANA                    Expires May 5, 2016                   [Page 7]


INTERNET-DRAFT             Problem Statement            November 2, 2015


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

      - the solution MUST support means to instruct the ACC device 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 ACC 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.




BANANA                    Expires May 5, 2016                   [Page 8]


INTERNET-DRAFT             Problem Statement            November 2, 2015


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.

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



BANANA                    Expires May 5, 2016                   [Page 9]


INTERNET-DRAFT             Problem Statement            November 2, 2015


   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

   Multipath TCP (MPTCP) had been considered as a candidate technology
   to support the bonding service. There are some implementations and
   deployments. MPTCP provides the ability to establish a communication
   over multiple paths, by means of sub-flow establishment and operation
   [RFC6824].

   MPTCP operates at the transport layer. The MPTCP protocol provides
   features to manage the state of sub-flows. [MPTCP-HA] discuss MPTCP
   deployment concerns and also specifies an extension to transport UDP
   datagrams in MPTCP packets. UDP traffic can therefore be forwarded
   over a MPTCP connection. Currently, MPTCP only supports per-flow
   traffic distribution. Traffic is distributed among these sub-flows
   using flow-based (5-tuple) de-multiplexing technique [RFC6824]. In
   the future, MPTCP might be extended to support packet-based traffic
   distribution.

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



BANANA                    Expires May 5, 2016                  [Page 10]


INTERNET-DRAFT             Problem Statement            November 2, 2015


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



BANANA                    Expires May 5, 2016                  [Page 11]


INTERNET-DRAFT             Problem Statement            November 2, 2015


             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 ACC management).

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

      - Enabling the solution MUST increase the serviceability of the
        ACC. In particular, the solution MUST allow for the ACC to
        always establish a network attachment when the primary



BANANA                    Expires May 5, 2016                  [Page 12]


INTERNET-DRAFT             Problem Statement            November 2, 2015


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

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

      - The ACC 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 ACC 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 ACC UI, a dedicated portal, etc.


























BANANA                    Expires May 5, 2016                  [Page 13]


INTERNET-DRAFT             Problem Statement            November 2, 2015


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 5, 2016                  [Page 14]


INTERNET-DRAFT             Problem Statement            November 2, 2015


   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 5, 2016                  [Page 15]


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