Internet DRAFT - draft-zuo-banana-mptcp-integration
draft-zuo-banana-mptcp-integration
BANANA N. Leymann
Internet Draft C. Heidemann
Intended Category: Standard Track Deutsche Telekom AG
G. Liang
China Mobile
J. Zuo
L. Zheng
Huawei
Expires: December 9, 2017 June 8, 2017
Integration of Bonding Tunnels and MPTCP
draft-zuo-banana-mptcp-integration-00.txt
Abstract
BANdwidth Aggregation for interNet Access (BANANA) based on tunnel
bonding protocols and Multipath TCP (MPTCP) are two different
technology suites that offer subscribers with higher bandwidth and
reliability. MPTCP excels at conducting TCP traffic since its
flow/congestion control scheme has been well developed while tunnel
bonding protocols support not only TCP traffic but also UDP traffic.
The integration of the two kinds of technologies can be considered to
make use of advantages of both. Moreover, extensions made to the
tunnel bonding protocols can simplify the MPTCP stack and keep it
intact. This document specifies the extensions for tunnel bonding
protocols to realize integrative deployment of tunnel bonding
solutions and MPTCP.
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
J. Zuo, et al Expires December 9, 2017 [Page 1]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
Copyright and License Notice
Copyright (c) 2017 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. Integration of Tunnel Bonding and MPTCP . . . . . . . . . . . . 4
3.1. Collocated Scenarios . . . . . . . . . . . . . . . . . . . 4
3.1.1 BANANA Endpoints Collocate with MPTCP Endpoints . . . . 4
3.1.2 HG/HAAP Collocate with MPTCP Proxy/Endpoint . . . . . . 4
3.1.3 HG and HAAP Collocate with Two MPTCP Proxies . . . . . . 5
3.2. MPTCP Traffic Recognition . . . . . . . . . . . . . . . . . 6
3.3. Bypassing and Pre-coloring . . . . . . . . . . . . . . . . 6
3.4. The Anycast Mechanism . . . . . . . . . . . . . . . . . . . 7
4. Message Types . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Tunnel Characteristics . . . . . . . . . . . . . . . . . . 7
4.2. Connection Mapping . . . . . . . . . . . . . . . . . . . . 9
5. MPTCP Path Selection using Bonding Tunnels . . . . . . . . . . 9
5.1 Subflow Policy . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Address Knowledge Exchange (Path Management) . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
BANdwidth Aggregation for interNet Access (BANANA) offers subscribers
with higher bandwidth and resilience than they can get from a single
access. MPTCP proxy based solutions and tunnel based solutions have
been developed to realize BANANA.
J. Zuo, et al Expires December 9, 2017 [Page 2]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
Multipath TCP (MPTCP) enables a transport connection to operate
across multiple paths simultaneously [RFC6824]. A flow/congestion
control scheme has been developed by MPTCP to let subscribers with
MPTCP endpoints efficiently utilize the bandwidth of the multiple
paths. Recently, MPTCP WG proposed the network-based MPTCP proxy
solution [PlainProxy] so that TCP endpoints can utilize the
aggregated bandwidth between the two MPTCP proxies while they need
not be upgraded to MPTCP endpoints.
As enabling technologies of BANANA, tunnel bonding solutions have
been deployed by multiple Service Providers. In a tunnel bonding
system, one tunnel is established per-connection between the two
tunnel bonding boxes. These tunnels are bonded together as if there
is a single IP link provided between the two boxes for the subscriber
who buys the tunnel bonding box. Different from MPTCP which is a
transport layer technology, tunnel bonding protocols operate under
the transport layer and support both TCP and UDP.
MPTCP and a tunnel bonding protocol may coexist in one network. There
are two types of such coexistence. For the first type, the tunnel
endpoint and the MPTCP stack can either be collocated in a host, in a
network device or on a site. For the second type, subscribers'
endpoints support MPTCP. These MPTCP endpoints are distributing MPTCP
traffic among the tunnels according to the MPTCP stack. The MPTCP
traffic should be recognized and avoid being re-distributed by the
BANANA box's load balancer. This document specifies how a tunnel
bonding solution and MPTCP can be integrated in a single system in
order to make use of advantages of both technologies.
In this document, message types of the bonding tunnel protocol are
specified to deliver characteristics of tunnels to the MPTCP stack.
MPTCP stack uses these tunnels that are setup in advance as its
network paths. In this way, the time on the discovery of these
network paths and the time on learning those characteristics can be
saved. Hence, this kind of integration will help to accelerate the
deployment of MPTCP.
2. Acronyms and Terminology
BANANA: BANdwidth Aggregation for interNet Access
HG: Home Gateway. A CPE device that is enhanced to support the
simultaneous use of multiple access connections. Also used as BANANA
local box.
HAAP: Hybrid Access Aggregation Point. A logical function in the
network, terminating bonded connections while offering high speed
Internet. Also used as BANANA remote box.
J. Zuo, et al Expires December 9, 2017 [Page 3]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
CIR: Committed Information Rate [RFC2697]
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. Integration of Tunnel Bonding and MPTCP
Tunnel bonding and MPTCP can be integrated as follows. MPTCP stack
and the tunnel bonding protocol endpoints can collocate in one host,
one network device or one site. MPTCP stack uses the bonding tunnels
as its multiple paths so that the time on path discovery can be
saved. Meanwhile, the bonding tunnels do not need consider the
flow/congestion control and reliability issues for the TCP traffic.
In either ways, the tunnel bonding protocol notifies the MPTCP stack
about the characteristics of the tunnels, such as the priority, the
available bandwidth and the Round-Trip Time (RTT). The MPTCP stack
sorts the paths according to their priorities and allocates subflows
according to their bandwidth demands and the available bandwidth of
the tunnels or even RTT.
3.1. Collocated Scenarios
The following three scenarios explains how a tunnel bonding protocol
and MPTCP are collocated in one host or one network device.
3.1.1 BANANA Endpoints Collocate with MPTCP Endpoints
+-----+ +-----+
| | subflow1 | |
| IP1---------IP2 |
| | | |
| | | |
| | subflow2 | |
| IP3---------IP4 |
| | | |
+-----+ +-----+
MPTCP endpoint1 MPTCP endpoint2
/HG /HAAP
Figure 3.1: BANANA endpoints collocate with MPTCP endpoints
As shown in Figure 3.1, BANANA endpoints HG and HAAP collocate with
the two MPTCP endpoints respectively. The two endpoints act as tunnel
endpoints which used to be done by network based devices.
3.1.2 HG/HAAP Collocate with MPTCP Proxy/Endpoint
J. Zuo, et al Expires December 9, 2017 [Page 4]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
+-----+ +-----+ +-----+
| | subflow1 | | | |
| IP1---------IP2 | | |
| | | | TCP | |
| | | IPe-----IPf |
| | subflow2 | | | |
| IP3---------IP4 | | |
| | | | | |
+-----+ +-----+ +-----+
MPTCP endpoint1 MPTCP proxy2 TCP
/HG /HAAP endpoint2
Figure 3.2: HAAP collocates with one-end MPTCP proxy
HG collocates with the MPTCP endpoint
As shown in Figure 3.2, HAAP acts as the proxy of TCP endpoint2 and
speaks MPTCP with MPTCP endpoint1. MPTCP proxy2 SHOULD use IPe as the
source IP address for the TCP session between itself and the TCP
endpoint2. MPTCP proxy2 locally maintains the mapping between the
subflows and the normal TCP session.
3.1.3 HG and HAAP Collocate with Two MPTCP Proxies
+-----+ +-----+ +-----+ +-----+
| | | | subflow1 | | | |
| | | IP1---------IP2 | | |
| | TCP | | | | TCP | |
| IPe------IPf | | IPe-----IPf |
| | | | subflow2 | | | |
| | | IP3---------IP4 | | |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
TCP MPTCP proxy1 MPTCP proxy2 TCP
endpoint1 /HG /HAAP endpoint2
Figure 3.3: HG and HAAP collocate with two MPTCP proxies
As shown in Figure 3.3, HG and HAAP act as MPTCP proxies of TCP
endpoint1 and TCP endpoint2 respectively. HG and HAAP need to learn
the source and destination IP address being used by the normal TCP
session and act as MPTCP proxies of the TCP endpoint1 and TCP
endpoint2 from each end respectively.
The two MPTCP proxies need to exchange the mapping between the TCP
connection and the MPTCP connection to ensure that a specific TCP
connection is mapped to the same MPTCP connection on both proxies.
This mapping is exchanged using the TLV as specified in Section 4.2.
J. Zuo, et al Expires December 9, 2017 [Page 5]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
3.2. MPTCP Traffic Recognition
+-----+ +-----+ +-----+ +-----+
| | | | subflow1 | | | |
| | | |-----------| | | |
| |subflow1| | | |subflow1| |
| IPe========| | | |========IPf |
| |subflow2| | subflow2 | |subflow2| |
| | | |-----------| | | |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
MPTCP MPTCP
endpoint1 HG HAAP endpoint2
Figure 3.4: Bonding tunnels discriminate the MPTCP traffic
Suppose endpoints support the MPTCP stack. The MPTCP traffic (e.g.,
subflows) will be recognized by the HG/HAAP boxes and locally
bypassed by the traffic distribution method of the bonding tunnel
protocol. For this scenario, HG and HAAP need not to deliver the
tunnel characteristics or connection mapping information of the two
tunnels to the two MPTCP endpoints.
3.3. Bypassing and Pre-coloring
The bypass feature of bonding tunnels allows operators to configure
traffic types not to be carried through the bonding tunnels. That is
an "outer" bypass. This memo additionally enables an "inner" (inside
the bonding tunnels) bypass of MPTCP traffic.
Suppose a packet of size B bytes arrives at time t.
o If the packet is of the traffic type that is configured to bypass
the bonding tunnels, it is pre-colored as green; the Single Rate
Three Color Marker (srTCM) of [RFC2697] MUST operate in the
Color-Aware mode with a minor change: pre-colored green packet
will remain in green than be re-colored as yellow; else
o if the packet is an MPTCP packet, this packet will be pre-colored
depends on the load balancer of the MPTCP stack: it is pre-
colored as green if it is to be delivered through the first
tunnel or yellow if it is to be delivered through the second
tunnel; the packet size B is incremented by the size of the
tunnel header; the srTCM MUST operate in the Color-Aware mode
with a minor change: pre-colored green packet will remain in
green than be re-colored as yellow; else
o the packet size B is incremented by the size of the tunnel header
J. Zuo, et al Expires December 9, 2017 [Page 6]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
and the srTCM MUST operate in the Color-Blind mode.
Green packets of the traffic types that are configured to bypass the
bonding tunnels are carried using the first raw connection of the HG.
Within the bonding tunnels, green packets are carried using the first
tunnel while yellow or red packets are carried using the second
tunnel.
3.4. The Anycast Mechanism
When a MPTCP proxy box and a BANANA box are collocated in a site
rather than one host or one network device (Scenario 2 and Scenario
3), a box can be put in front of them to achieve anycast. Service
discovery of BANANA will be handled by the front box while the tunnel
endpoints will be either the BANANA box or the MPTCP proxy. Hence,
two pairs of tunnels will be set up. One pair of them are terminated
by the BANANA box while the other pair of tunnels are terminated by
the MPTCP proxy box. Hence, MPTCP and non-MPTCP traffic is delivered
in different tunnels.
The two pairs of tunnels share the same pair of paths. Different from
the scenarios where BANANA box and MPTCP proxy are in the same
network device, traffic for the MPTCP proxy and the BANANA box is
distributed onto the paths separately. Bonding tunnels will still
conduct MPTCP traffic as bypass traffic. BANANA boxes need to measure
the amount of the bypass traffic periodically in order to subtract
this amount from the Committed Information Rate (CIR) for the
coloring mechanism [RFC2697].
4. Message Types
Two TLVs are defined by the tunnel bonding protocol to facilitate the
MPTCP stack.
4.1. Tunnel Characteristics
The follow TLV carries tunnel characteristics and IP addresses of a
tunnel which will be used as paths by MPTCP stack for its subflows.
J. Zuo, et al Expires December 9, 2017 [Page 7]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Available Downstream Bandwidth (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Available Upstream Bandwidth (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| RTT (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Source IP address (4 or 16 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Destination IP address (4 or 16 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Type
Tunnel Characteristics (TBD), the characteristics of the tunnel.
Length
Set to 17 or 41. Source IP address and destination IP address MUST
be either IPv4 or IPv6.
Priority
An unsigned integer. The bonding tunnels will determine the
priority of paths for MPTCP and deliver this information through
the tunnel priority. The path manager of MPTCP stack will order
the paths with highest numerical priority being highest priority.
Available Downstream Bandwidth
An unsigned integer measured in kbps. The HAAP calculates the
available Bandwidth by subtracting the measured bypass traffic
rate, where the bypass traffic rate can be calculated by
periodically counting the received packets at the HG. The HG
notify the Available Downstream Bandwidth and the measured bypass
traffic rate to the HAAP.
Available Upstream Bandwidth
An unsigned integer measured in kbps. There is no bypass traffic
rate to be substracted from the Committed Upstream Bandwidth. The
HAAP notify the Available Upstream Bandwidth to the HG.
RTT
An unsigned integer measured in ms.
Source IP address
J. Zuo, et al Expires December 9, 2017 [Page 8]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
Set to a pre-configured IPv4/IPv6 address which is used as the
source endpoint IP address of a tunnel between the two MPTCP
proxies.
Destination IP address
Set to a pre-configured IPv4/IPv6 address which is used as the
destination endpoint IP address of a tunnel between the two MPTCP
proxies.
4.2. Connection Mapping
The following Connection Mapping TLV is specified by the tunnel
bonding protocol for the purpose of exchanging between the pair of
MPTCP proxies about the mapping between MPTCP connection and TCP
connection.
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| MPTCP Connection ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Source IP address of TCP (4 or 16 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Destination IP address of TCP (4 or 16 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Type
Connection Mapping (TBD), the mapping between MPTCP connection and
TCP connection.
MPTCP Connection ID
An unique identifier given to a multipath connection by the MPTCP
proxy, which is the Token defined in [RFC6824].
Source IP address of TCP
The source IPv4/IPv6 address of the TCP connection.
Destination IP address of TCP
The destination IPv4/IPv6 address of the TCP connection.
5. MPTCP Path Selection using Bonding Tunnels
Based on the tunnel characteristics like bandwidth, latency, etc., of
the bonding tunnels, MPTCP may select the set of paths for providing
higher throughput or resilience against path failures.
J. Zuo, et al Expires December 9, 2017 [Page 9]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
5.1 Subflow Policy
As mentioned in [RFC6824], the MPTCP endpoint may use any local
policy to decide how to send the traffic over the available paths.
the MPTCP endpoint requires the knowledge of the path 'cost' to make
effective choices, where the path 'cost' may be obtained from the TLV
carried by the Tunnel Characteristics TLV. Moreover, in the event
that the available set of paths changes, the MPTCP endpoint may wish
to signal a change in priority of subflows to the other MPTCP
endpoint, where the subflow has the same meaning of physical path.
Therefore, the priority information may also be obtained from the
TLV. If the multiple subflows are differentiated from port numbers
while with the same IP addresses, the priority of subflows are deemed
to be the same, as obtained from the TLV of the same physical path.
5.2. Address Knowledge Exchange (Path Management)
As mentioned in [RFC6824], the "path management" is responsible for
the exchange of additional addresses between the two MPTCP endpoints,
where the Add Address (ADD_ADDR) MPTCP option is used to inform the
other MPTCP endpoint of the IP addresses. If the previously informed
address becomes invalid, a Remove Address (REMOVE_ADDR) option is
used to announce the peer to remove the subflows related to this
address. The ADD_ADDR and REMOVE_ADDR options are carried in the
duplicate ACK packets and to be sent periodically. However, with the
help of the IP addresses carried in Connection Mapping TLV, the MPTCP
stack does not need extra signal to manage the paths.
6. Security Considerations
TBD.
7. IANA Considerations
Codepoints of the TLV defined in Section 5 need to be registered by a
specific tunnel bonding protocol.
8. References
8.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>.
[RFC2697] Heinanen, J. and Guerin R., "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
J. Zuo, et al Expires December 9, 2017 [Page 10]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
<http://www.rfc-editor.org/info/rfc2697>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and Bonaventure, O.,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[PlainProxy] Boucadair, M., Jacquenet, C., et al, "Extensions for
Network-Assisted MPTCP Deployment Models", draft-boucadair-
mptcp-plain-mode, work in progress.
8.2. Informative References
[802Type] IANA, "IEEE 802 Numbers",
<http://www.iana.org/assignments/ieee-802-numbers>.
J. Zuo, et al Expires December 9, 2017 [Page 11]
INTERNET-DRAFT Bonding Tunnels & MPTCP Integration June 8, 2017
Author's Addresses
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
Geng Liang
China Mobile
32 Xuanwumen West Street,
Xicheng District, Beijing, 100053,
China
EMail: gengliang@chinamobile.com
Jing Zuo
Huawei Technologies
Bantian, Longgang District,
Shenzhen 518129 P.R. China
EMail: jing.zuo@huawei.com
Lianshu Zheng
Huawei Technologies
No.156 Beiqing Rd. Haidian District,
Beijing 100095 P.R. China
EMail: vero.zheng@huawei.com
J. Zuo, et al Expires December 9, 2017 [Page 12]
