INTERNET-DRAFT M. Cullen
Intended Status: Informational Painless Security
N. Leymann
C. Heidemann
Deutsche Telekom AG
M. Boucadair
France Telecom
H. Deng
China Mobile
M. Zhang
B. Sarikaya
Huawei
Expires: May 4, 2017 October 31, 2016
Problem Statement: Bandwidth Aggregation for Internet Access
draft-zhang-banana-problem-statement-03.txt
Abstract
Bandwidth aggregation capabilities for Internet access services can
significantly improve end user's Quality of Experience. Such
capabilities are especially attractive in environments where multi-
interfaced boxes become commonplace and can technically connect to
various access networks, both wired and wireless.
This document describes the problems with bandwidth aggregation for
Internet access. A set of requirements are derived from the said
problems.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
BANANA Expires May 4, 2017 [Page 1]
INTERNET-DRAFT Problem Statement October 31, 2016
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3
3. Generic Reference Model . . . . . . . . . . . . . . . . . . . . 4
4. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Traffic Classification . . . . . . . . . . . . . . . . . . 5
4.3. Traffic Distribution . . . . . . . . . . . . . . . . . . . 5
4.4. Traffic Recombination . . . . . . . . . . . . . . . . . . . 6
4.4.1. Reordering Buffer . . . . . . . . . . . . . . . . . . . 6
4.5. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Measurement . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Policy Control . . . . . . . . . . . . . . . . . . . . . . 8
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. GRE Tunnel Bonding . . . . . . . . . . . . . . . . . . . . 10
6.2. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Multipath TCP Proxy . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Additional Requirements . . . . . . . . . . . . . . . 14
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
BANANA Expires May 4, 2017 [Page 2]
INTERNET-DRAFT Problem Statement October 31, 2016
1. Introduction
Use cases of BANdwidth Aggregation for interNet Access (BANANA,
a.k.a., Hybrid Access) are described in the Technical Report [TR-348]
published by Broadband Forum: by providing Hybrid Access, Service
Providers can provide customers with increased access bandwidth and
higher access reliability; Service delivery may also be fostered to
access the Internet by means of providing a LTE (Long Term Evolution)
connection while the wired line is being constructed.
Although host-based Hybrid Access is possible, the scope of this
document is restricted to be network-based only. Host-based might be
standardized in other places, such as the MIF Working Group.
Design techniques that are being investigated, developed and
sometimes deployed to facilitate bandwidth aggregation and improve
the resiliency of access conditions raise several problems from
various standpoints: traffic routing and forwarding, congestion
control, security, etc. This document aims at presenting these
problems regardless of the nature of the design technique. It also
intends to derive requirements accordingly, and which should be
addressed by any bandwidth aggregation technique. Typically, this is
one of the inputs that are expected from the IETF community.
A common framework will be sketched, including required functional
modules and interactions. The various solution proposals (e.g., GRE,
LISP, MIP, MPTCP) can be viewed as applicability assessments of the
framework. To support BANANA, the problems to be addressed includes:
addressing, traffic classification, distribution and recombination,
bypassing, measurement and policy control. To address these problems,
we may work as a group to
- specify the encapsulation format;
- develop a common control plane;
- and define or suggest approaches to address BANANA problems
developed in this document.
2. Acronyms and Terminology
Hybrid Access: The coordinated and simultaneous use of two
heterogeneous access paths (e.g., DSL and LTE) [TR-348].
CPE: Customer Premises Equipment. An equipment which is the property
of the network operator and located on the customer premises.
HG: Home Gateway. A CPE device that is enhanced to support the
simultaneous use of both fixed broadband and 3GPP access connections.
BANANA Expires May 4, 2017 [Page 3]
INTERNET-DRAFT Problem Statement October 31, 2016
HAAP: Hybrid Access Aggregation Point. A logical function in
Operator's network, terminating bonded connections while offering
high speed Internet.
PDP: Packet Data Protocol. A packet transfer protocol used in
wireless GPRS (General Packet Radio Service)/HSDPA (High Speed
Downlink Packet Access) networks.
PPPoE: Point-to-Point Protocol over Ethernet is a network protocol
for encapsulating PPP frames inside Ethernet frames.
DHCP: Dynamic Host Configuration Protocol [RFC2131].
DNS: Domain Name System [RFC1035].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Generic Reference Model
+--+ +----+
| +----- bonding connection ----+ |
| | | |
| | | |
|HG|i/f --- sub-connection ---i/f|HAAP|
| | . . . | |
| |i/f --- sub-connection ---i/f| |
| | | |
+--+ +----+
Figure 3.1: Reference model of the Hybrid Access
Customers access the Internet using the Hybrid Access which comprises
of several key component functions as shown in Figure 3.1: the Home
Gateway (HG) as one peer, the Hybrid Access Aggregation Point (HAAP)
as the other peer, the bonding connection between the two peers and
the sub-connections that logically make up the bonding connection.
4. Problem Areas
4.1. Addressing
At the HG side, interface addresses of sub-connections are locally
acquired upon the bootstrap of the system by means of certain
existing protocols such as Point-to-Point Protocol over Ethernet
(PPPoE) [RFC2516] and Packet Data Protocol (PDP). At the HAAP side,
BANANA Expires May 4, 2017 [Page 4]
INTERNET-DRAFT Problem Statement October 31, 2016
interface addresses are usually pre-configured by operators. HG and
HAAP will rely on the control protocol that is to be developed to
exchange these addresses. Afterwards, sub-connections are de-
multiplexed by their interface addresses. Both IPv4 and IPv6 should
be supported.
End users behind the HG box will regard the bonding connection as a
traditional connection to the Internet. With the established sub-
connections, connectivity between the HG and HAAP has been built up,
therefore endpoint addresses for this bonding connection can be
obtained from existing protocols, e.g., DHCP and DNS.
4.2. Traffic Classification
Traffic classification occurs before the flows or packets are
distributed among the connections. HG and HAAP should support the
classification function that marks a flow or packets which are to be
further processed by the traffic distribution function or bypass the
Hybrid Access (See Section 4.5). Classification criteria include IP
addresses, port numbers, etc. Traffic classification policies can be
defined by end users and service providers and must be enforced by
the HG and HAAP equipments.
4.3. Traffic Distribution
For traffic that is to be distributed across multiple sub-
connections, equal load balancing generally applies, possibly
inferred by the bandwidth that is available in each link that
supports sub-connection. Unequal load balancing should be supported
as well. Traffic may be distributed across sub-connections as a
function of their available bandwidth. Traffic may also be split in
such a way that whenever one sub-connection is saturated, then
traffic is forwarded over a secondary sub-connection.
There are two kinds of traffic distribution methods for the Hybrid
Access: per-flow load balancing and per-packet load sharing. The per-
flow load balancing method is used to be widely adopted in core IP
networks. It is suitable for the scenario where there are a large
number of flows to be distributed. For end users, usually there are
few number of applications to be transmitted over the bonded sub-
connections. Per-flow load balance techniques might not be able to
achieve a fine grained load distribution, so that the per-packet load
sharing is necessary.
For the per-flow load balancing, the load can be distributed using
hashing methods. For the per-packet load splitting, the coloring
mechanism specified in [RFC2698] can be used to classify customer's
IP packets, both upstream and downstream, and packets will then be
BANANA Expires May 4, 2017 [Page 5]
INTERNET-DRAFT Problem Statement October 31, 2016
forwarded over the appropriate sub-connections. For example, packets
colored as green are forwarded over one sub-connection and packets
colored as yellow are forwarded over another sub-connection. For
scenarios that rely upon more than two sub-connections, multiple
levels of coloring mechanism could be implemented.
4.4. Traffic Recombination
For the packet-based traffic distribution, the recombination function
at the receiver sides must reorder packets to preserve the integrity
of the communication. The sender needs to mark each packet with a
sequence number. The sequence number are set per the whole bonding
connection rather than per sub-connection so that all packets
forwarded over several sub-connections actually share the same
reordering buffer.
4.4.1. Reordering Buffer
Ingress| flying packets |Egress
| +---+ +---+---+ |
| | 99|...| 3| 1| |
| +---+ +---+---+ |
| |
| ------- LTE -----> |
| |
| |
| | +---+ +---+---+
| | |100|...| 4| 2|
| ------- DSL -----> | +---+ +---+---+
| |50 buffered packets
| |
Figure 4.1: Minimizing the reordering buffer
Deployment experiences show that a secondary sub-connection might
suffer from large latency, jitter and high packet loss rate. For
packet-based traffic distribution, packets are distributed onto those
sub-connections at the ingress and then recombined again in a buffer
at the egress. If the secondary sub-connection suffers, the entire
bonding connection will suffer as well due to the recombination
function. For example, assume packet 1,3,...,99 are distributed onto
the secondary sub-connection while packet 2,4,...,100 are distributed
onto the primary sub-connection. If packet 1 is delayed by 100 ms,
even packet 2 arrives at the recombination buffer at the first
millisecond, it has to remain in the buffer awaiting for packet 1 as
long as 99 ms. Packets distributed onto the primary sub-connection,
BANANA Expires May 4, 2017 [Page 6]
INTERNET-DRAFT Problem Statement October 31, 2016
which arrive after packet 2, have to be buffered. This can easily
lead to the overflow of the reordering buffer and the user's TCP
throughput of the bonding connection might be greatly reduced.
Latency of each sub-connection will be monitored. For example, HG and
HAAP may calculate the Adaptive Acknowledgment Time-Out of each sub-
connection as specified in [RFC2637]; HG and HAAP may periodically
exchange control messages to detect the RTT of each sub-connection
[FLARE]; Packet loss rate of each sub-connection may be monitored as
well [BondL3]. If the difference of the monitored latency exceeds a
predefined threshold or the secondary sub-connection exhibits a too
high packet loss rate, attached HG and HAAP will stop distributing
traffic onto this sub-connection.
Even if the latency of the two sub-connections are comparable and the
packet loss rate of the secondary sub-connection is fine so that the
reordering buffer does not overflow, it's still worthy to design
solutions to minimize the usage of the reordering buffer. In order to
realize this goal, the traffic distribution at the ingress should be
manipulated. For example, the idea of [FLARE] might be borrowed:
basically, a traffic flow would be split into "flowlets" by the gaps
between the arriving packets. Packets of a specific flowlet is solely
distributed onto one sub-connection. In this way, reordering is
avoided or minimized. The load-balancing method of MPTCP [RFC6824]
could be used as well: packets are always distributed to the sub-
connection with the least congestion level and/or latency
[MPscheduler].
4.5. Bypass
Service Providers may require some traffic to bypass the Hybrid
Access. For example, some delay sensitive applications such as live
TV broadcasting carried over a lossy sub-connection would impair
customers' Quality of Experience. Service providers could then make
sure that such traffic is forwarded over a set of wired sub-
connections only, thereby disregarding low-rate mobile connections,
for example.
There are two types of bypass: the bypassing traffic are transmitted
on a sub-connection out of all the sub-connections between HG and
HAAP; the bypassing traffic is still transmitted on a sub-connection
between HG and HAAP, just that the occupied bandwidth of the
bypassing traffic on this sub-connection can not used for bandwidth
aggregation. In either case, the bypassing traffic would not be under
control of the Hybrid Access scheme.
HG and HAAP needs to exchange information about bypassing through the
control protocol, such as the application types that need to bypass
BANANA Expires May 4, 2017 [Page 7]
INTERNET-DRAFT Problem Statement October 31, 2016
the Hybrid Access and the bandwidth occupied by the bypassing traffic
(See also Section 4.6).
4.6. Measurement
HG and HAAP need to measure and exchange performance parameters of
the Hybrid Access, including performance parameters that pertain to
each sub-connection that belongs to the same connection. Such
parameters include (but are not necessarily limited to):
- Operating state: The operating state has to be measured by control
messages. When a sub-connection fails, this sub-connection has to
be removed from the bonding connection.
- Round Trip Time (RTT): The measurement of this parameter is used
by flow and congestion control algorithms for per-flow and per-
packet distribution purposes. The probing packet could be piggy-
backed by data packets or could be carried by control messages.
- Maximum sub-connection bandwidth: This parameter may be used to
determine the amount of traffic that can be distributed across all
or a subset of sub-connections.
- Bypassing bandwidth: This parameter has to be periodically
monitored. Usually, this is measured for the opposite end to
figure out the available sending bandwidth. For example, the HG
reports the downloading bypassing bandwidth used in a sub-
connection so that the HAAP can calculate the remaining
downloading bandwidth of this sub-connection.
4.7. Policy Control
Operators and customers may control the Hybrid Access with policies.
These policies will be instantiated into parameters or actions that
impact traffic classification, distribution, combination, measurement
and bypassing. Such policies may consist in:
- Defining traffic filter lists used by the traffic classification
function.
- Per-flow or per-packet forwarding policies.
- Operators may specify maximum value of the difference between two
measured one-way transit delays. Operators may also specify the
maximum allowed packet loss rate of a sub-connection.
- Operators may determine the maximum allowed size (See
MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering.
BANANA Expires May 4, 2017 [Page 8]
INTERNET-DRAFT Problem Statement October 31, 2016
Operators may also define the maximum time (See OUTOFORDER_TIMER
in [RFC2890]) that a packet can stay in the buffer for reordering.
These parameters may pact traffic recombination.
- Operators and customers may specify the service types to bypass
the Hybrid Access.
- Operators may specify the frequency for detecting a sub-connection
and the detection retry times before a sub-connection can be
declared as "failed".
5. Requirements
Requirements for the Hybrid Access are described in this section.
Also, some additional requirements are listed for discussion in the
Appendix.
The solution MUST apply for both IPv4 and IPv6 traffic.
The solution MUST NOT require any new capability to support Hybrid
Access from the host.
In the Hybrid Access, forwarding traffic flows over various
interfaces may have a negative impact on customers' experience (e.g.,
hazardous log outs, broken HTTPS associations, etc.). The solution
should be carefully designed, so that
- activating the solution MUST NOT impact the stability,
availability of the services delivered to the customer compared
to customers who access the same service whose traffic is
forwarded along a single path.
"Roles" (primary or backup) should be assigned to each supported
network interface type (e.g., fixed or mobile access). This role is
assigned by the network operator (e.g., fixed access can be set as
the "primary"). Note that there may be more than two sub-connections
to support primary and backup roles. A default setting can be
considered.
- Setting of the role of the sub-connections SHOULD NOT be changed
by the user.
The solution should provide Service Providers with means to enforce
policy control of the Hybrid Access. For example,
- the solution MUST allow to rate limit the traffic on a per-
interface basis.
BANANA Expires May 4, 2017 [Page 9]
INTERNET-DRAFT Problem Statement October 31, 2016
- the solution MUST support means to enable/disable the activation
of multiple interfaces at the HG.
- the solution MUST support means to instruct the HG about the
logic for mounting interfaces.
- the solution MUST support means to bind a given traffic to a
subset of interfaces.
For the sake of policy enforcement or analytics at the network side,
- the solution MAY ease correlating flows, conveyed over multiple
access networks, and which belong to the same customer.
Some services such as VoIP may be available over all active
interfaces, but distinct logins and credentials may be used.
- The HG SHOULD be provided with clear instructions about which
account to use to place outgoing sessions. For the sake of
simplicity, it is RECOMMENDED to use the login/credentials that
are independent of the underlying access network used to access
the service.
6. Related IETF Work
Hybrid Access designs can rely upon several solutions. The following
subsections recap the work that has been or is being conducted by the
IETF in this area. Note that solutions are listed in an alphabetic
order. No preference order should be assumed by the reader.
6.1. GRE Tunnel Bonding
GRE Tunnel Bonding [GRE-HA] uses per-packet traffic distribution to
achieve a fine-grained load sharing among the sub-connections. Out-
of-sequence packets may be received at the egress so that reordering
function is provided. IP packets are encapsulated in the GRE header
which is in turn encapsulated in an outer IP header and forwarded
over the sub-connections. The Sequence Number field of the GRE header
is used to number the packets at the sender side, while the receiver
uses of this sequence number to reorder the packets.
A new control plane is defined. Control messages are transported in
the same GRE tunnels that are used to transport data packets. The
control messages and data packets are distinguished by the GRE
Protocol Type 0xB7EA.
GRE tunnel bonding has been deployed by Deutsche Telekom AG and
Austria Telekom.
BANANA Expires May 4, 2017 [Page 10]
INTERNET-DRAFT Problem Statement October 31, 2016
6.2. LISP
LISP has the basic capability to support the Hybrid Access [LISP-HA]
[ILNP]. LISP can be used to enforce traffic engineering based upon
static load balancing that is not agnostic to link characteristics.
Packet-based traffic distribution has been considered in [LISP-HA] as
well. The detail specification of the reordering mechanism based on a
"Reorder" flag is left for future work.
6.3. Mobile IP
Mobile IP [RFC3775] and Network Mobility (NEMO; [RFC3963]) used to
handle multiple L3 connectivity to the Internet via multiple ISPs for
a multi-homed end user [RFC4908]. By treating Hybrid Access as a
special scenario, some existing capabilities of Mobile IP and NEMO
could be reused to realize Hybrid Access. Take [MIP-HA] as an
example, rely on the multiple Care-of Addresses (CoAs) capability
[RFC5648] [RFC6275], the "addressing" problem of BANANA could be
settled. Currently, per-flow traffic distribution has already been
supported by Mobile IP and NEMO ([RFC6088], [RFC6089]) while packet-
based traffic distribution is left for future work [MIP-HA].
6.4. Multipath TCP Proxy
MPTCP provides the ability to establish a communication over multiple
paths, by means of sub-flow establishment and operation [RFC6824].
However, the traditional MPTCP is a host-based technology therefore
it's out the scope of this document. What is considered as a
candidate technology to support the Hybrid Access is the MPTCP proxy
mechanism. There are some implementations and deployments.
The MPTCP proxy operates at the transport layer and locates in the
operator's network. A transparent MPTCP mode is proposed in [MPTCP-
trans]: a MPTCP proxy terminates a user's TCP flow and reinitiates
MPTCP sub-flows towards the other MPTCP proxy; The other MPTCP proxy
will terminate the MPTCP sub-flows and restore the user's TCP flow;
The MPTCP protocol suite provides features to manage the state of
sub-flows between the two proxies. [MPTCP-plain] discusses MPTCP
proxy (i.e., transparent MPTCP mode) deployment concerns and also
specifies an extension to transport UDP datagrams in MPTCP packets.
UDP traffic can therefore be forwarded over a MPTCP connection.
7. Security Considerations
Hybrid Access might introduce new threats to the network. For
example, traffic sent on unsecured sub-connections would be easily
intercepted by an attacker who performs man-in-the-middle attack. The
BANANA Expires May 4, 2017 [Page 11]
INTERNET-DRAFT Problem Statement October 31, 2016
multi-path communication may be leveraged to perform Denial of
Service (DoS) attack or Distributed Denial of Service (DDoS) attack
(e.g., based upon flooding traffic) that may jeopardize the
aggregation gateway as well as the access equipment and end station
operation.
These kind of new security issues should be carefully considered in
designing solutions that aim to address the problems of Bandwidth
Aggregation for Internet Access.
8. IANA Considerations
No IANA action is required in this document.
9. Acknowledgements
Authors would like to thank the comments and suggestions from
Christian Jacquenet and Li Xue.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[TR-348] Broadband Forum, "Technical Report on Hybrid Access
Broadband Network Architecture", July, 2016,
<https://www.broadband-forum.org/technical/download/TR-
348.pdf>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
DOI 10.17487/RFC2131, March 1997, <http://www.rfc-
editor.org/info/rfc2131>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February
1999, <http://www.rfc-editor.org/info/rfc2516>.
[RFC2689] Bormann, C., "Providing Integrated Services over Low-
bitrate Links", RFC 2689, DOI 10.17487/RFC2689, September
BANANA Expires May 4, 2017 [Page 12]
INTERNET-DRAFT Problem Statement October 31, 2016
1999, <http://www.rfc-editor.org/info/rfc2689>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>.
10.2. Informative References
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, DOI 10.17487/RFC2637, July 1999, <http://www.rfc-
editor.org/info/rfc2637>.
[BondL3] Maciej Bednarek, Guillermo Barrenetxea, Mirja Mirja
Kuehlewind and Brian Trammell, "Multipath bonding at Layer
3", Applied Networking Research Workshop, July 16, 2016,
Berlin, Germany
[FLARE] Srikanth Kandula, Dina Katabi, Shantanu Sinha, and Arthur
Berger, "Dynamic Load Balancing Without Packet Reordering",
ACM SIGCOMM Computer Communication Review, April 2007.
[MPscheduler] Hyunwoo Nam, Doru Calin and Henning Schulzrinne,
"Towards Dynamic MPTCP Path Control Using SDN", IEEE
NetSoft Conference and Workshops (NetSoft), June 2016.
[GRE-HA] N. Leymann, C. Heidemann, M. Zhang, et al, "GRE Tunnel
Bonding", draft-zhang-gre-tunnel-bonding, work in progress.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[MPTCP-tans] B. Peirens, G. Detal, S. Barre and O. Bonaventure, "Link
bonding with transparent Multipath TCP", draft-peirens-
mptcp-transparent, work in progress.
[MPTCP-plain] M. Boucadair and C. Jacquenet, "An MPTCP Option for
Network-Assisted MPTCP Deployments: Plain Transport Mode",
draft-boucadair-mptcp-plain-mode, work in progress.
[MIP-HA] P. Seite, A. Yegin and S. Gundavelli, "Multihoming support
for Residential Gateways", draft-seite-dmm-rg-multihoming,
work in progress.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI
BANANA Expires May 4, 2017 [Page 13]
INTERNET-DRAFT Problem Statement October 31, 2016
10.17487/RFC5213, August 2008, <http://www.rfc-
editor.org/info/rfc5213>.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088, DOI
10.17487/RFC6088, January 2011, <http://www.rfc-
editor.org/info/rfc6088>.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and
K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network
Mobility (NEMO) Basic Support", RFC 6089, DOI
10.17487/RFC6089, January 2011, <http://www.rfc-
editor.org/info/rfc6089>.
[802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Link Aggregation", 802.1AX-2014, 24 December
2014.
[LISP-HA] M. Menth, A. Stockmayer and M. Schmidt, "LISP Hybrid
Access", draft-menth-lisp-ha, work in progress.
[ILNP] "ILNP - Identifier-Locator Network Protocol", online
available: http://ilnp.cs.st-andrews.ac.uk/
Appendix A. Additional Requirements
The following requirements are listed as record and may subject to
change.
- The solution MUST be valid for any kinds of interfaces that need
to be aggregated. No dependency to the underlying media should
be assumed.
- The solution MUST comply with servers policy regarding IP
addresses that are bound to (HTTP session) cookies.
- The solution MUST NOT break TLS associations.
- Activating the solution MUST NOT have negative impacts on the
service usability (including the HG management).
- Service degradation MUST NOT be observed when enabling the
solution.
- Enabling the solution MUST increase the serviceability of the
HG. In particular, the solution MUST allow for the HG to always
establish a network attachment when the primary connectivity is
out of service.
BANANA Expires May 4, 2017 [Page 14]
INTERNET-DRAFT Problem Statement October 31, 2016
- The solution SHOULD NOT alter any mechanism, to aggregate
available resources or to ensure a service continuity among
multiple access points, that is supported by end-devices
connected to the HG.
- The HG MUST bind the DNS server(s) discovered during the network
attachment phase to the interface from which the information was
received.
- The HG MUST bind the service information (e.g., SIP Proxy
Server) discovered during the network attachment phase to the
interface from which the information was received.
- When sending the traffic via a given interface, the HG MUST use
as source address an address (or an address from a prefix) that
was assigned for that interface.
- For protocols such as RTP/RTCP, the same IP address MUST be used
for both RTP and RTCP sessions.
- Dedicated tools SHOULD be provided to the customer to assess the
aggregated capacity (instead of link-specific). This can be
included as part of the HG UI, a dedicated portal, etc.
BANANA Expires May 4, 2017 [Page 15]
INTERNET-DRAFT Problem Statement October 31, 2016
Author's Addresses
Margaret Cullen
Painless Security
14 Summer St. Suite 202
Malden, MA 02148 USA
EMail: margaret@painless-security.com
Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21-27
Berlin 10781
Germany
Phone: +49-170-2275345
EMail: n.leymann@telekom.de
Cornelius Heidemann
Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7
Darmstadt 64295
Germany
Phone: +4961515812721
EMail: heidemannc@telekom.de
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
EMail: denghui@chinamobile.com
BANANA Expires May 4, 2017 [Page 16]
INTERNET-DRAFT Problem Statement October 31, 2016
Mingui Zhang
Huawei Technologies
No.156 Beiqing Rd. Haidian District,
Beijing 100095 P.R. China
EMail: zhangmingui@huawei.com
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 3
Plano, TX 75024
EMail: sarikaya@ieee.org
BANANA Expires May 4, 2017 [Page 17]