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]