INTERNET-DRAFT M. Cullen
Intended Status: Informational Painless Security
N. Leymann M. Boucadair
C. Heidemann C. Jacquenet
Deutsche Telekom AG France Telecom
M. Zhang
B. Sarikaya
Huawei
Expires: April 21, 2016 October 19, 2015
Problem Statement: Bandwidth Aggregation for Internet Access
draft-zhang-banana-problem-statement-00.txt
Abstract
Bandwidth aggregation for Internet access can increase the access
bandwidth and reliability. It has become a desirable network
function, especially for those Service Providers who operates
multiple heterogeneous networks.
This document describes the issues with bandwidth aggregation for
Internet access. The required network functions to be supported are
specified. Several candidate solutions had been considered to support
bandwidth aggregation for Internet access in IETF. These techniques
are investigated.
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 April 21, 2016 [Page 1]
INTERNET-DRAFT Problem Statement October 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Per-packet Traffic Distribution . . . . . . . . . . . . . . 4
3.2. Per-flow Traffic Distribution . . . . . . . . . . . . . . . 4
4. Generic Reference Model . . . . . . . . . . . . . . . . . . . . 4
5. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Traffic Classification . . . . . . . . . . . . . . . . . . 5
5.3. Traffic Distribution . . . . . . . . . . . . . . . . . . . 5
5.4. Traffic Recombination . . . . . . . . . . . . . . . . . . . 6
5.5. Bypassing . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.6. Measurement . . . . . . . . . . . . . . . . . . . . . . . . 7
5.7. Policy Control . . . . . . . . . . . . . . . . . . . . . . 7
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. GRE Tunnel Bonding . . . . . . . . . . . . . . . . . . . . 9
7.2. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.4. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . . 10
7.5. Network Based Layer-2 Tunneling . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Additional Requirements . . . . . . . . . . . . . . . 12
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
BANANA Expires April 21, 2016 [Page 2]
INTERNET-DRAFT Problem Statement October 19, 2015
1. Introduction
Bandwidth aggregation across multiple Internet access links (a.k.a.,
the bonding service) provides several useful features. The working
text [WT-348] being developed by Broadband Forum has documented
several use cases of the bonding service: Service Providers may use
the bonding service to offer customers with increased access
bandwidth and higher access reliability; Service Providers may
accelerate the service turn-up of a primary access (e.g., a link of
Digital Subscriber Line) with a longer lead time by providing an
additional access (e.g., a link of Long Term Evolution) which has a
short lead time.
Although host based bonding service is possible, this document
restricts the scope to be network based only. 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.
This document is meant to capture the common problems that are
addressed by several ongoing initiatives. The goal is to identify
commonalities among them and derive functional requirements. It is
not clear at this stage whether one or multiple solutions may be
required to accommodate various deployment contexts. Typically, this
is one of the inputs that are expected from the IETF community.
Alternatively, a common framework can 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 the problems, the work should be done in IETF
includes:
- to determine and further detail the tunneling technology to be
used;
- to specify the sole encapsulation format;
- to develop a common control plane;
- to define or suggest the algorithms to be used in packet
reordering, flow control and congestion control.
Several groups have developed, and in some cases deployed, bandwidth
aggregation solutions based on existing IETF technologies. These
technologies are investigated in this document. Note that solutions
are listed in an alphabetic order. No preference order should be
assumed by the reader.
BANANA Expires April 21, 2016 [Page 3]
INTERNET-DRAFT Problem Statement October 19, 2015
2. Acronyms and Terminology
Bonding Service: An alias for Bandwidth Aggregation for Internet
Access in this document.
ACC: Shorted for ACCess equipment. ACC connects user's end station or
network to the bonding service.
AGG: Shorted for AGGregation equipment. AGG faces to the Internet
while aggregates and terminates the bonding service from ACCs.
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. Use Cases
Depends on the traffic distribution techniques, there are two kinds
of use cases for the bonding service.
3.1. Per-packet Traffic Distribution
For residential users, 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.
3.2. Per-flow Traffic Distribution
Per-flow load balancing methods are widely used in IP networks. These
techniques may be used to implement the bonding service. The per-flow
traffic distribution is suitable for enterprise users who usually
owns a dense number of applications. The load balancing among the
bonded connections could be fine grained.
4. Generic Reference Model
+-+ +-+
| +----- bonding connection ----+ |
|A| |A|
| | | |
|C|if ---- sub-connection ----if|G|
| | . . . | |
|C|if ---- sub-connection ----if|G|
| | | |
+-+ +-+
Figure 4.1: Reference model of the bonding service
BANANA Expires April 21, 2016 [Page 4]
INTERNET-DRAFT Problem Statement October 19, 2015
Customers access the Internet using the bonding service which
comprises of several key component functions as shown in Figure 4.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. Customers
can only sense the bonding connection while the internal sub-
connection between ACC and AGG are invisible to outside. The bonding
connection works at layer 3. The sub-connections usually works at
layer 3 but could work at layer 2.
5. Problem Areas
The following subsections list the problems that need to be solved in
the bonding service solutions.
5.1. Addressing
ACC and AGG need allocate addresses to the interfaces attached to
each sub-connection and the whole bonding connection. IPv4, IPv6 or
dual-stack operation should be supported. Sub-connections can be
internally demultiplexed by their interface addresses. When the
bonding service is bootstrapped, these connection addresses are
discovered at the other end through the control protocol. The
connection addresses of ACC may be assigned by AGG, also through the
control plane.
5.2. Traffic Classification
Classification happens before the received packets are distributed to
the connections. ACC and AGG MUST support the classification function
that classify a packet into a class that is to be further processed
by the traffic distribution function. The classification can be based
on the IP address, application type, etc. ACC and AGG MUST support
their classification function to be controlled by the policy from
providers or customers.
5.3. Traffic Distribution
For the traffic that is to be distributed into multiple sub-
connections, by default it is distributed equally to the sub-
connections according to their available bandwidth. Unequal load
balancing should be supported as well. Traffic may be distributed to
the connections in proportion to the available bandwidth of the sub-
connections. Traffic may also be split in a way that one sub-
connection is saturated first and then another sub-connection is
used.
For the per-flow use case, the load can be distributed using hashing
BANANA Expires April 21, 2016 [Page 5]
INTERNET-DRAFT Problem Statement October 19, 2015
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, into the sub-connections. For example,
packets colored as green is distributed into one sub-connection and
packets colored as yellow is distributed into the other sub-
connection. For the scenario that requires more than two sub-
connections, multiple levels of token buckets might be realized.
5.4. Traffic Recombination
For the per-packet use case, the recombination function at the
receiver provides the in-order delivery of customers' traffic. The
sender need 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 all packets carried on these sub-connections
actually share the same buffer. The receiver reorder the out-of-
sequence data packets in the buffer by the packets' sequence number.
The maximum allowed size of the buffer and the maximum time that a
packet can stay in the buffer is up to implementations.
For the per-flow use case, an acknowledge number field appear in the
packets in order to integrate the congestion and flow control into
the traffic recombination. In order to support such control, the
sender need also maintain a sending buffer.
5.5. Bypassing
Service Providers may require some traffic to bypass the Traffic
Distribution function. For example, some delay sensitive applications
such as IPTV carried over a lossy sub-connection would impair
customers' Quality of Experience. Service providers would require
such applications transmitted only on the wired sub-connection when
the aggregation is a mix of wired and wireless bonded sub-
connections.
There are two types of bypassing: 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
does not benefit from the Bandwidth Aggregation.
ACC and AGG need timely exchange information about bypassing, such as
the application types that need be handled by the bypassing function,
the bandwidth occupied by the bypassing traffic (See also Section
5.6).
BANANA Expires April 21, 2016 [Page 6]
INTERNET-DRAFT Problem Statement October 19, 2015
5.6. Measurement
ACC and AGG need monitor and exchange the performance parameters of
the sub-connections between them. The following parameters fall into
the problem space.
- Operating state: The operating state has to be measured by out-of-
band control messages. When a sub-connection is detected to be
failed, this sub-connection has to be removed from the bonding
connection.
- End-to-end delay and delay variation: The measured result of this
parameter are used in flow control and congestions control
algorithms for the per-flow distribution. The per-packet
distribution may make use of this measured parameter as well. For
example, when the delay difference of two sub-connection exceeds a
pre-defined threshold, the slower one can be suspended. 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
determine the amount of traffic that can be distributed to each
sub-connection.
- Bypassing bandwidth: This parameter has to be timely monitored.
Usually, this is measured for the opposite end to figure out the
available sending bandwidth. For example, the ACC report the
downward bypassing bandwidth for a sub-connection so that the AGG
can calculate the remained available downward bandwidth of this
sub-connection.
5.7. Policy Control
Operators and customers may control the bonding service with
policies. These policies will be interpreted into parameters or
actions that impact traffic classification, distribution,
combination, measurement and bypassing. The following policy control
examples are in the problem space of this document.
- Operators may provide the parameters or filter list used by the
traffic classification function.
- Operators may control the traffic distribution to be done either
in a per-flow manner or a per-packet manner.
- 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
BANANA Expires April 21, 2016 [Page 7]
INTERNET-DRAFT Problem Statement October 19, 2015
[RFC2890]) that a packet can stay in the buffer for reordering.
These parameters impact the traffic recombination.
- Operators may specify the interval for sending detecting messages
and the retry times for ACC or AGG to send out detecting messages
before it can declare a sub-connection failure. Operators may
specify the allowed threshold of the delay difference for two sub-
connections.
- Operators and customers may specify the service types bypassing
the traffic distribution function.
6. Requirements
Requirements for the bonding service are considered in this section.
Also, some additional requirements are listed for discussion in the
Appendix.
The solution MUST apply for both IPv4 and IPv6.
Host based solutions are out of the scope, therefore
- the solution MUST NOT require any specific function at the
terminal's side.
In the bonding service, flapping the flows among various interfaces
may have a negative impact on the 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 are serviced with traditional non-bonding
service.
"Roles" 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"). A default
setting can be considered.
- Setting of the role of the sub-connections (primary or backup)
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.
BANANA Expires April 21, 2016 [Page 8]
INTERNET-DRAFT Problem Statement October 19, 2015
- the solution MUST support means to enable/disable activating
multiple interfaces at the CPE ACC side.
- the solution MUST support means to instruct the CPEACC 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, that 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 CPE 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.
7. Related IETF Work
The bonding service has been considered to be supported in several
ways. Subsections of this section list the related work that fall
into the scope of IETF. In the future, IETF may adopt one direction
to work on. However, the sub-functions developed in other directions
may be integrated into the adopted direction.
7.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. The
receiver may receive out-of-sequence packets so that reordering
function is provided. Users' IP packets are encapsulated in the GRE
header which in turn encapsulated in an outer IP header and
transported on the sub-connections. The Sequence Number field of the
GRE header is used to number the packets at the sender while the
receiver makes use of this sequence number to reorder the packets.
A clean-slate 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
BANANA Expires April 21, 2016 [Page 9]
INTERNET-DRAFT Problem Statement October 19, 2015
congestion control could be supported within the tunnel through
extending the GRE header, though it is currently out of the scope.
7.2. LISP
LISP has the basic capability to support the bonding service [LISP-
HA] [ILNP]. LISP used to do traffic engineering based on static load
balancing that is not agnostic to link characteristics. If the LISP
architecture takes on the bonding service, performance of the sub-
connections, such as their available bandwidth, end-to-end delay and
packet loss, need to be measured, though they are not supported yet.
To achieve such kind of dynamic flow based load balancing, some
technique issues, such path symmetry and route oscillation, need to
be considered and addressed.
Packet based traffic distribution has been considered in [LISP-HA] as
well. Detail specification of the reordering mechanism based on a
"Reorder" flag is left as future work.
7.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 have already been defined in the IP mobility
protocols could be reused. At the same time, however, the IP mobility
protocols have to be tailored in order to reduce the deployment
complexity.
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 the 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 as future work.
7.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 simultaneously use the
sub-connections between the ACC and AGG peers. MPTCP "subflows" would
be created, one per sub-connection, and are combined with the
existing TCP session, which continues to appear as a single
connection to the applications at both ends [RFC6824].
BANANA Expires April 21, 2016 [Page 10]
INTERNET-DRAFT Problem Statement October 19, 2015
MPTCP operates at the transport layer. The MPTCP protocol is
specified to manage the state of subflows. [MPTCP-HA] addresses the
deployment concerns and specifies the extension to transport UDP
datagrams in MPTCP packets. The UDP traffic can be distributed among
the sub-connections using the MPTCP features, which are traditionally
not supported by MPTCP. Currently, MPTCP only supports per-flow
traffic distribution. Traffic is distributed among these subflows
using the flow based 5-tuple demultiplexing [RFC6824]. In the future,
MPTCP might be extended to support packet based traffic distribution.
7.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. Per-flow load balance can be well supported by various of
implementations. 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 remained to be
addressed by the Network Based Layer-2 Tunneling.
8. Security Considerations
This document describes the problem space and does not introduce any
security risks. However, security issues should be considered by
solutions that address this problem space.
9. IANA Considerations
No IANA action is required in this document. RFC Editor: please
remove this section before publication.
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.
[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
BANANA Expires April 21, 2016 [Page 11]
INTERNET-DRAFT Problem Statement October 19, 2015
[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
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
BANANA Expires April 21, 2016 [Page 12]
INTERNET-DRAFT Problem Statement October 19, 2015
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
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 April 21, 2016 [Page 13]
INTERNET-DRAFT Problem Statement October 19, 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
Christian Jacquenet
France Telecom
Rennes
France
EMail: christian.jacquenet@orange.com
Mingui Zhang
BANANA Expires April 21, 2016 [Page 14]
INTERNET-DRAFT Problem Statement October 19, 2015
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 April 21, 2016 [Page 15]