One document matched: draft-ayar-transparent-sca-proxy-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC1323 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1323.xml">
<!ENTITY RFC1853 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1853.xml">
<!ENTITY RFC2003 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2003.xml">
<!ENTITY RFC2018 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2018.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2453 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2453.xml">
<!ENTITY RFC2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY RFC2883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2883.xml">
<!ENTITY RFC4022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4022.xml">
<!ENTITY RFC1771 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1771.xml">
<!ENTITY RFC4293 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY RFC4898 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4898.xml">
<!ENTITY RFC6182 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6182.xml">
<!ENTITY RFC6356 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6356.xml">
<!ENTITY MPTCP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-multiaddressed-06">
<!ENTITY MPTCPAPI SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-api-03">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="no"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- keep one blank line between list items -->
<?rfc subcompact="no" ?>
<!-- ********************************* RFC BEGIN ********************************* -->
<rfc category="info" docName="draft-ayar-transparent-sca-proxy-00" ipr="trust200902">
<!-- *************************** FRONT MATTER BEGIN *************************** -->
<front>
<!-- ***************************** TITLE BEGIN ***************************** -->
<title abbrev="Multi Path TCP PEP For Single Homed Hosts">
A Transparent Performance Enhancing Proxy Architecture To
Enable TCP over Multiple Paths for Single-Homed Hosts
</title>
<!-- ****************************** TITLE END ****************************** -->
<!-- ************************** AUTHOR T.A. BEGIN ************************** -->
<author fullname="Tacettin Ayar" initials="T.A." surname="Ayar">
<organization> Technical University Berlin </organization>
<address>
<postal>
<street>
Telecommunication Networks Group,
</street>
<street>
Sekr. FT5, Einsteinufer 25,
</street>
<city>Berlin</city>
<code>10587</code>
<country>Germany</country>
</postal>
<phone>+49 30 314 28225</phone>
<email>ayar@tkn.tu-berlin.de</email>
</address>
</author>
<!-- *************************** AUTHOR T.A. END *************************** -->
<!-- ************************** AUTHOR B.R. BEGIN ************************** -->
<author fullname="Berthold Rathke" initials="B.R." surname="Rathke">
<organization> Technical University Berlin </organization>
<address>
<postal>
<street>
Telecommunication Networks Group,
</street>
<street>
Sekr. FT5, Einsteinufer 25,
</street>
<city>Berlin</city>
<region></region>
<code>10587</code>
<country>Germany</country>
</postal>
<phone>+49 30 314 23832</phone>
<email>rathke@tkn.tu-berlin.de</email>
</address>
</author>
<!-- *************************** AUTHOR B.R. END *************************** -->
<!-- ************************** AUTHOR L.B. BEGIN ************************** -->
<author fullname="Lukasz Budzisz" initials="L.B." surname="Budzisz">
<organization> Technical University Berlin </organization>
<address>
<postal>
<street>
Telecommunication Networks Group,
</street>
<street>
Sekr. FT5, Einsteinufer 25,
</street>
<city>Berlin</city>
<region></region>
<code>10587</code>
<country>Germany</country>
</postal>
<phone>+49 30 314 23836</phone>
<email>budzisz@tkn.tu-berlin.de</email>
</address>
</author>
<!-- *************************** AUTHOR L.B. END *************************** -->
<!-- ************************** AUTHOR A.W. BEGIN ************************** -->
<author fullname="Adam Wolisz" initials="A.W." surname="Wolisz">
<organization> Technical University Berlin </organization>
<address>
<postal>
<street>
Telecommunication Networks Group,
</street>
<street>
Sekr. FT5, Einsteinufer 25,
</street>
<city>Berlin</city>
<region></region>
<code>10587</code>
<country>Germany</country>
</postal>
<phone>+49 30 314 22911</phone>
<email>awo@ieee.org</email>
</address>
</author>
<!-- *************************** AUTHOR A.W. END *************************** -->
<date month="February" year="2012" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Multi-Path TCP Proxy</keyword>
<!-- *************************** ABSTRACT BEGIN **************************** -->
<abstract>
<t>
This draft complements the work of MPTCP by defining a TCP
Splitter/Combiner Architecture (SCA) that enables non-MPTCP-capable
single-homed hosts
to benefit from the multiple paths within Internet by means of
performance enhancing proxies (PEPs) placed in the access networks.
</t>
<t>
SCA Proxies (SCAPs) make use of multiple paths in a way which is completely
transparent to end-hosts. Since the existence of the SCAPs is
shielded from the TCP end-points, they can be deployed in the
Internet as well as on the end-systems.
</t>
</abstract>
<!-- **************************** ABSTRACT END ***************************** -->
</front>
<!-- **************************** FRONT MATTER END **************************** -->
<!-- *************************** MIDDLE MATTER BEGIN *************************** -->
<middle>
<!-- ************************** INTRODUCTION BEGIN ************************** -->
<section title="Introduction" anchor="sec-introduction">
<t>
Despite the fact that, the number of end-systems with multiple interfaces
increases every day, usually only one interface is used to connect to
the Internet, as for the single-interface hosts.
This is motivated, among others, by the energy consumption. That is,
the use of
multiple interfaces drastically increases the power consumption and thus
decreases the battery lifetime.
When only one IP address is assigned
to the end-system, the end-system is single-addressed.
</t>
<t>
Single addressed end-hosts may not benefit from the MPTCP
<xref target="RFC6182"/> <xref target="RFC6356"/>
<xref target="I-D.ietf-mptcp-multiaddressed"/>
even if they are MPTCP-capable. MPTCP uses IP address pairs of the
end-hosts to create the subflows.
When two MPTCP-capable single-addressed end-systems transfer data via
MPTCP, they will use regular TCP <xref target="RFC0793"/>
like the non-MPTCP-capable hosts.
</t>
<t>
Moreover, the fact that an end-system is MPTCP-capable does not
mean that MPTCP MUST be used by TCP connections.
MPTCP MAY be disabled with TCP_MULTIPATH_ENABLE socket option on
MPTCP-capable hosts <xref target="I-D.ietf-mptcp-api"/>.
</t>
<t>
Nevertheless, single-addressed end-hosts
may benefit from multiple paths within the Internet by means of
proxies located within the access networks. Such a proxy is described
in this document and called further SCA Proxy (SCAP). It detects the
TCP
connection and then splits and shapes TCP traffic over multiple paths.
If the
access network is connected to the Internet via multiple gateway (GW)
links, then
TCP traffic may be distributed within the access network so that the packets
will leave the network from different GW links. Thus, the bandwidth
aggregation of the links may be achieved.
If an access network is connected to the Internet
via only one GW link, the SCAP may distribute TCP traffic
to multiple paths within the access network and then another SCAP on the
path may combine the packets before they leave the access network.
</t>
<t>
This document describes a splitter/combiner architecture (SCA) that may
be used to develop transparent proxies for TCP over multiple paths
solutions. SCA is a thin layer on top of IP which captures all the TCP
packets. SCA distributes data/ACK packets of a TCP connection
to the multiple paths and/or combines the distributed data/ACK packets of a
TCP connection from multiple paths.
</t>
<!-- ******************** REQUIREMENTS LANGUAGE BEGIN ******************** -->
<section title="Requirements Language">
<t>
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
<xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<!-- ********************* REQUIREMENTS LANGUAGE END ********************* -->
<!-- ************************* TERMINOLOGY BEGIN ************************* -->
<section title="Terminology">
<t>
Single-addressed end-system: An end-system, either with single or
multiple interfaces, which is assigned only one IP address to connect
to the Internet.
</t>
<t>
Network Device: An access point (AP) or router located in
between a TCP sender and receiver.
</t>
<t>
SCA Proxy (SCAP): A running instance of the SCA.
</t>
<t>
SCAP Device: A network device on which an instance of SCA runs.
</t>
<t>
Pipe: A network path between a network interface of a SCAP device
and a network interface of another SCAP device.
Pipe is uniquely identified by the IP address pair
of two SCAP device interfaces.
</t>
</section>
<!-- ************************** TERMINOLOGY END ************************** -->
<!-- ********************** REFERENCE SCENARIO BEGIN ********************* -->
<section title="Reference Scenario"
anchor="sec-sca-reference-scenario" >
<t>
<xref target="fig-sca-multiple-networks"/> shows a reference scenario
for two SCAP devices in different access networks.
Host A and B are single-addressed non-MPTCP-capable hosts.
They are connected to the Internet via network devices
which have multiple (i.e., N) GW links to the Internet.
The multiple interfaces of the network devices have IP addresses
A-1..N and B-1..N.
</t>
<t>
When there is a TCP connection between an application on Host A
and an application on Host B, TCP packets will follow a single path
(e.g., via A-1<->Pipe-1<->B-1).
If the GW links have low capacities (e.g., T1 links or DSL lines),
then they constitute the bottleneck for the TCP connection.
</t>
<t>
As shown in <xref target="fig-sca-multiple-networks"/>,
when network devices are used as SCAP devices
they may use multiple GW links
to aggregate the capacity of the links for the TCP connection:
<list style="symbols">
<t>
SCAP-1 splits TCP data packets from Host A
to Host B via its interfaces A-1 to A-N. Similarly,
SCAP-2 splits TCP data packets from Host B to Host A via
its interfaces B-1 to B-N.
</t>
<t>
On the other side, SCAP-1 combines the packets split
by SCAP-2. That is, it buffers and reorders the packets
before they reach to the Host A. Similarly, SCAP-2
combines the packets split by SCAP-1.
</t>
</list>
</t>
<figure align="center" anchor="fig-sca-multiple-networks"
title="SCAPs on Multiple Access Networks">
<artwork align="left"><![CDATA[
<--Access Network 1--><-------Internet-----><--Access Network 2-->
______
+--------+ ( ) +--------+
+------+ | |_______(........)_______| | +------+
| | | Access |A-1 ( Pipe-1 ) B-1| Access | | |
| Host | | Point | : ( : ) : | Point | | Host |
| |---| or | : ( : ) : | or |---| |
| A | | Router | : ( : ) : | Router | | B |
| | | |______(..........)______| | | |
+------+ |(SCAP-1)|A-N ( Pipe-N ) B-N|(SCAP-2)| +------+
+--------+ (______) +--------+
]]></artwork>
</figure>
</section>
<!-- *********************** REFERENCE SCENARIO END ********************** -->
</section>
<!-- *************************** INTRODUCTION END *************************** -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- *************************** SCA DESIGN BEGIN *************************** -->
<section title="SCA Design">
<t>
In addition to increasing the TCP throughput, SCA aims at high deployment and
adoption. To achieve that, the existence of the SCA MUST be
shielded locally (i.e., from the applications and TCP on the TCP
end-points) as well as on end-to-end (i.e., end points SHOULD NOT need to
know which network devices are SCAP devices).
Thus, SCA is designed as protocol-stack and end-host transparent.
</t>
<!-- ***************** PROTOCOL STACK TRANSPARENCY BEGIN ***************** -->
<section title="SCA Protocol-Stack Transparency"
anchor="sca-protocl-stack-transparency">
<t>
In order to provide protocol-stack transparency,
SCA MUST be located
underneath the TCP. All the TCP multiple path related issues
MUST be handled in the SCA which MAY be implemented as a thin layer.
</t>
<t>
SCA SHOULD be located on top of the IP on the network devices.
Alternatively, SCA MAY be located between the IP and data link layer.
In both cases, all the TCP packets MUST pass through the SCA.
</t>
<t>
In order to recognize TCP connection establishment/release
requests
and TCP data/ACK packets, SCA MUST access and read the
content of the TCP header. Thus, SCA SHOULD NOT be used on
network devices if TCP headers can not be read. SCA SHOULD NOT
access and read TCP payload.
</t>
<t>
Network devices MAY access TCP headers to
work as middleboxes (i.e., performance-enhancing proxies
(PEPs), firewalls, or NATs)
<xref target="RFC6182"/>. As a kind of middlebox,
SCAP devices function as
PEPs that split
and combine TCP traffic while preserving TCP end-to-end
semantics (<xref target="fig-sca-peer"/>).
<figure align="center"
anchor="fig-sca-peer"
title="SCAPs as PEPs In Between TCP End Hosts">
<artwork align="center"><![CDATA[
+-------------+ +-------------+
| | | |
| Application |<-------------End-to-End-------------->| Application |
| | | |
+-------------+ +-------------+
| |<-------------End-to-End-------------->| |
| TCP | +-------------+ +-------------+ | TCP |
| | | SCAP |<->| SCAP | | |
+-------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| IP |<->| IP |<->| IP |<->| IP |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
TCP SCAP Device SCAP Device TCP
End Host (PEP) (PEP) End Host
]]></artwork>
</figure>
</t>
</section>
<!-- ****************** PROTOCOL STACK TRANSPARENCY END ****************** -->
<!-- ******************** END-POINT TRANSPARENCY BEGIN ******************* -->
<section title="SCA End-Point Transparency">
<t>
SCAPs MUST work without any support from TCP end hosts.
Neither TCP sender nor TCP receiver MUST be aware of the
presence of any SCAPs. Thus, TCP end-hosts SHALL NOT be configured to find
SCAPs. Instead, SCAPs SHOULD find other SCAPs to collaborate with.
</t>
</section>
<!-- ********************* END-POINT TRANSPARENCY END ******************** -->
</section>
<!-- **************************** SCA DESIGN END **************************** -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ****************************** SCA BEGIN ******************************* -->
<section title="SCA Components" anchor="sec-sca">
<t>
SCA includes the following components to solve TCP
problems <xref target="ref-ayar12" />
when multiple pipes are used:
<list style="symbols">
<t>
Packet Classifier that captures TCP packets and
classifies them based on the header information.
</t>
<t>
Connection Handler that reacts to new TCP
connections by creating records of
the new TCP connection and discarding
connection information in case of
a TCP connection release.
</t>
<t>
Multiple Pipes Adapter that provides a common
interface to use pipes in the network layer.
</t>
<t>
Data/ACK Processors that process the data/ACK
packets of the TCP connections.
</t>
<t>
Signaling Unit that processes the SCA
signaling packets.
</t>
<t>
Configuration and Management Unit that is used to
configure parameters used by the components.
</t>
</list>
</t>
<!-- ********************** PACKET CLASSIFIER BEGIN ********************** -->
<section title="Packet Classifier"
anchor="sec-packet-classifier">
<t>
Packet Classifier is responsible for looking
at the TCP header to determine the packet type.
An admission control policy MAY be applied to
packets
(<xref target="sec-configuration-management"/>)
before accepting them into the SCAP.
The packets that are not admitted MUST be passed
to the lower/upper layer without SCAP processing.
</t>
<t>
SCAP-accepted TCP packets MUST be passed to the
related SCA component:
<list style="symbols">
<t>
SCA signaling packets are used for detecting
other SCAPs and exchanging control
information among the SCAPs.
All the signaling packets MUST be handled by
the Signaling Unit.
</t>
<t>
TCP connection establishment packets
(i.e., packets with the SYN flag set) MUST be passed
to the Connection Handler to construct
connection record entries.
</t>
<t>
TCP connection release packets MUST be passed to
Connection Handler to remove entries of the
connection records.
</t>
<t>
Data/ACK packets MUST be passed to the
Data/ACK Processor.
</t>
</list>
</t>
</section>
<!-- *********************** PACKET CLASSIFIER END *********************** -->
<!-- ********************* CONNECTION HANDLER BEGIN ********************** -->
<section title="Connection Handler"
anchor="sec-connection-handler">
<t>
Connection Handler manages the records of
the TCP connections. TCP connection
establishment procedure is followed to
detect the TCP connections.
TCP connection requests are detected by
means of TCP segments with SYN flag.
</t>
<t>
TCP connection records MUST contain a unique connection
identifier (tcp_conn_id) that is
generated based on
the TCP sender and receiver end-points
(i.e., sender and receiver
IP addresses and port numbers).
</t>
<t>
When TCP connection release packets
(i.e., packets with the FIN or RST flag set)
are received, the TCP connection release
procedure is followed. When the connection
tear-down is complete, all the connection
related records MUST be deleted.
</t>
</section>
<!-- ********************** CONNECTION HANDLER END *********************** -->
<!-- ******************* MULTIPLE PIPES ADAPTER BEGIN ******************** -->
<section title="Multiple Pipes Adapter"
anchor="sec-multiple-pipes-adapter">
<t>
MPTCP uses IP addresses of the end-hosts in the subflow
end-points. Similarly, SCAPs SHOULD use IP address pairs of SCAP
devices as pipes. In that case, the peer MUST be
informed about the used addresses, as MPTCP informs
its peer by means of ADD_ADDR option.
</t>
<t>
<!-- GENERATE EXTRA SPACE -->
<vspace blankLines="1"/>
</t>
<t>
TCP packets MAY be sent over these pipes to the SCAP peer
by means of:
<list style="symbols">
<t>
IP source routing <xref target="RFC0791"/>:
<vspace blankLines="1"/>
TCP packets may be requested to follow a specific
path. IP Loose/Strict Source and Record Route option
MAY be used to specify the path they must follow.
</t>
<t>
IP-in-IP encapsulation <xref target="RFC2003"/>:
<vspace blankLines="1"/>
The source and destination SCAP IP addresses may
be specified in the outer
IP header to create tunnels between the SCAP peers.
</t>
<t>
IP-in-IP tunneling <xref target="RFC1853"/>:
<vspace blankLines="1"/>
SCAPs may use special headers to exchange signaling
information. Tunnel Headers in the IP-in-IP
tunneling may be used to carry SCA signaling
information.
</t>
</list>
</t>
<t>
Since different methods may be used to send/receive data
via SCA pipes,
Multiple Pipes Adapter is defined as a component that
interacts via specified APIs with other components of
the SCA and handles interaction with IP.
</t>
<t>
Multiple Pipes Adapter interacts with IP
to access and use the available pipes.
Other SCA components use the Multiple Pipes Adapter APIs
to get information about the pipes that may be used
and to send data via them.
</t>
<t>
Multiple Pipes Adapter provides following APIs to
the SCA components:
<list style="numbers">
<t>
PIPE-ID-LIST find_pipes(tcp_conn_id, destination_address)
<vspace blankLines="1"/>
is used to find pipes that may be used to send
TCP data packets to the destination_address
and returns the list of them, if any.
<vspace blankLines="1"/>
tcp_conn_id is used to identify the connection that
needs the pipes to be assigned.
Multiple Pipes Adapter may access information about
the connection (e.g., source/destination TCP end-point)
by using the tcp_conn_id. The API also associates the
list of pipes found with the connection.
<vspace blankLines="1"/>
The PIPE-ID-LIST contains pipe_ids
which are assigned by the Multiple Pipes Adapter
to the available pipes
(i.e., each pipe has a unique pipe_id).
<vspace blankLines="1"/>
<!-- GENERATE EXTRA SPACE -->
<vspace blankLines="1"/>
Pipe implementation is shielded from the other components
by means of pipe_ids: other components only know pipe_ids
and Multiple Pipe Adapter handles pipes.
</t>
<t>
PIPE-PROPERTIES get_pipe_properties(tcp_conn_id, pipe_id)
<vspace blankLines="1"/>
is used to probe for characteristics of a pipe.
<vspace blankLines="1"/>
PIPE-PROPERTIES includes the required pipe parameters
by the SCA instance (e.g., bandwidth, delay,
utilization, packet loss rate, etc.).
<vspace blankLines="1"/>
In order to get pipe parameters, following methods may
be used <xref target="ref-ayar12"/>:
packet-pair based estimation of the pipe
delays and capacities,
tracking the TCP timestamps <xref target="RFC1323"/>,
SACK <xref target="RFC2018"/> or
D-SACK <xref target="RFC2883"/> to estimate packet arrivals
at the receiver,
or probing pipe capacities with TCP-like cwnd increase
and decrease
<xref target="RFC6356"/>.
<vspace blankLines="1"/>
In addition, the local MIB information
(e.g., <xref target="RFC2863"/>
<xref target="RFC4022"/>
<xref target="RFC4293"/>
<xref target="RFC4898"/>)
may be used to set the initial values just after
the pipes are found by Multiple Pipes Adapter.
<vspace blankLines="1"/>
If tcp_conn_id is NULL, then the total pipe characteristics
are returned. Otherwise, tcp_conn_id is used to get pipe
characteristics relevant to a TCP connection. For example,
the bandwidth used by a TCP connection may be asked as well
as the total bandwidth of the pipe.
</t>
<t>
PIPE-ID-LIST employ_pipes(tcp_conn_id, pipe_id_list)
<vspace blankLines="1"/>
is used by Multiple Pipes Adapter to associate pipes which
become available after the connection establishment.
For example, an interface becomes active or a host associates
with an AP/router after the pipes were assigned to the TCP
connection by use of the find_pipes() API.
<vspace blankLines="1"/>
Pipes in the pipe_id_list are associated with
the connection with tcp_conn_id.
</t>
<t>
PIPE-ID-LIST withdraw_pipes(tcp_conn_id, pipe_id_list)
<vspace blankLines="1"/>
is used when a connection terminates or connection doesn't
need some pre-assigned pipes.
<vspace blankLines="1"/>
Pipes in the pipe_id_list are disassociated from
the connection with tcp_conn_id.
<vspace blankLines="1"/>
<!-- GENERATE EXTRA SPACE -->
<vspace blankLines="1"/>
It MUST be called
after the connection termination and MAY be called
during the connection to cancel the use of
some pipes which are previously assigned
to the connection.
<vspace blankLines="1"/>
In addition, Multiple Pipes Adapter may use this API
to disassociate some pipes which become unavailable
during the connection. For example, an interface becomes
inactive or a host looses its connection to an AP/router.
</t>
<t>
PIPE-ID-LIST select_pipes(tcp_conn_id, pipe_id_list)
<vspace blankLines="1"/>
is used to select a subset
from a set of pipes
based on a pipe selection policy
(<xref target="sec-configuration-management"/>).
<vspace blankLines="1"/>
tcp_conn_id is used to determine the pipe selection
policy for the connection.
The API uses withdraw_pipes() API to disassociate
filtered pipes by the pipe selection policy and
returns back the remaining pipes.
</t>
<t>
send_mp_packet(tcp_packet, tcp_conn_id, pipe_id)
<vspace blankLines="1"/>
is used to send a packet via one of the multiple
pipes.
<vspace blankLines="1"/>
Since other SCA components only know the pipe_ids
and do not know what the real pipes are, they use this API
to send a tcp_packet which belongs to the connection
with tcp_conn_id by using the the pipe with pipe_id.
<vspace blankLines="1"/>
tcp_conn_id is supplied to enable update for pipe
characteristics related with the TCP connections.
For example, if a pipe is assigned to more than one TCP
connection, what proportion of the pipe is used by the
assigned TCP connections.
</t>
<t>
TCP-PACKET check_encapsulation(tcp_packet)
<vspace blankLines="1"/>
is used to check whether tcp_packet is encapsulated
or not.
<vspace blankLines="1"/>
Packets may be sent/received encapsulated.
Since other components are shielded from the
use of encapsulation, only the Multiple Pipes Adapter
knows about the encapsulation.
<vspace blankLines="1"/>
send_mp_packet() API encapsulates
packets before sending them when encapsulation is
necessary.
<vspace blankLines="1"/>
When packets are received by the Packet Classifier,
it uses check_encapsulation() to get decapsulated
packets, if encapsulation is used for the connection.
It returns the packet immediately if encapsulation
is not used.
</t>
</list>
</t>
</section>
<!-- ******************** MULTIPLE PIPES ADAPTER END ********************* -->
<!-- ********************* DATA/ACK PROCESSOR BEGIN ********************** -->
<section title="Data/ACK Processor"
anchor="sec-data-ack-processor">
<t>
Data/ACK Processor is responsible for
handling data/ACK packets. It shapes
TCP traffic and decides
on the scheduling of packets to the
pipes.
</t>
<t>
Data/ACK Processor may apply to a TCP data/ACK packet one
of the following operations (called 4-D)
<xref target="ref-ayar12"/>:
<list style="numbers">
<t>
duplicate: TCP packets may be
(one or more times) duplicated
and scheduled to multiple pipes
to create robustness against
packet losses.
</t>
<t>
delay: TCP packets may be buffered
and delivered later, based on a timer
or a condition. For example, some packets
of a TCP flow may be intentionally delayed
to shape the TCP traffic (e.g., to reduce
number of out-of-order packet arrivals at
the receiver side, or to separate sent packets
by a given interval). Another example is to
buffer and reorder out-of-order packets
before they are passed to the TCP receiver.
</t>
<t>
deliver: TCP packets may be released immediately
after their capture, or after the delay or
duplicate operation. Delivery may be done locally
for the incoming packets or over any available pipe
to outgoing packets. For outgoing packets, one of
the available pipes must be selected to efficiently
utilize the pipes.
</t>
<t>
drop: TCP packets may be dropped by SCAP.
For example, assume that a packet is
buffered for early retransmission purposes.
If the ACK for that packet arrived and
the buffered packet is not needed to be kept
any more, it may be dropped.
</t>
</list>
</t>
</section>
<!-- ********************** DATA/ACK PROCESSOR END *********************** -->
<!-- ********************* Signaling Unit BEGIN *********************** -->
<section title="Signaling Unit"
anchor="sec-control-processor">
<t>
SCAPs on different SCAP devices MAY exchange signaling information by
means of the following methods:
<list style="numbers">
<t>
in-band signaling, by means of TCP options
as in MPTCP.
The SCAP that wants to send a signaling
information will generate an SCA option
and add it to the TCP packet.
The peer SCAP will use the content of
the SCA control option and remove it
from the packet.
<vspace blankLines="1"/>
The main drawback of the in-band signaling
is that its size is limited by the TCP option space
allowed.
16-21 bytes of space is left for the SCA
options when the most common TCP options
are encountered
<xref target="I-D.ietf-mptcp-multiaddressed"/>.
</t>
<t>
out-of-band signaling that may use signaling channels
established between the SCAPs.
<vspace blankLines="1"/>
SCAPs may use a well-known port number to exchange
signaling packets (e.g, RIP routing processes
use UDP port 520 <xref target="RFC2453"/>
or BGP systems use TCP port 179
<xref target="RFC1771"/>).
<vspace blankLines="1"/>
</t>
<t>
hybrid signaling that may use in-band signaling
to carry out-of-band signaling channel end-point
information between SCAPs.
First a connection between the signaling channel end-points
will be established. Then, out-of-band signaling over
the connection
may be used to exchange the signaling data.
</t>
</list>
Details of the signaling mechanism are out-of-scope of this
document.
</t>
</section>
<!-- ********************** Signaling Unit END ************************ -->
<!-- ***************** CONFIGURATION & MANAGEMENT BEGIN ****************** -->
<section title="Configuration and Management Unit"
anchor="sec-configuration-management">
<t>
Configuration and Management Unit is used to set
parameters for the SCA components. The configuration
parameters may be defined for each component:
<list style="symbols">
<!-- ******** PACKET CLASSIFIER ADMISSION CONTROL BEGIN ********* -->
<t>
Packet Classifier may accept packets into the SCAP or reject them
based on an admission control policy.
<vspace blankLines="1"/>
Based on the TCP
end-points, some applications or hosts may not benefit from
the SCA:
<list style="symbols">
<t>
Splitting the traffic may not be necessary for some applications.
For example, short-lived flows like web traffic may be carried
over only one path instead of multiple paths as they will most
likely end within a couple of packets anyway. Thus, they may not be
accepted for the SCA processing.
</t>
<t>
SCA may be provided as a service for some set of users. The users
may be identified from the IP addresses they use to connect to the
Internet. Thus, an admission policy may be applied based on the IP
addresses of the TCP end-points.
</t>
</list>
</t>
<!-- ********* PACKET CLASSIFIER ADMISSION CONTROL END ********** -->
<!-- *********** LIMIT CONNECTION NUMBER POLICY BEGIN *********** -->
<t>
Connection Handler may configure the number of acceptable connections
based on the current number of connections or the total number of pipes
used by the connections.
</t>
<!-- ************ LIMIT CONNECTION NUMBER POLICY END ************ -->
<!-- *************** PIPE SELECTION POLICY BEGIN **************** -->
<t>
Multiple Pipes Adapter may use a pipe selection policy
to select a subset of the pipes from the set of available
pipes. Using different policies in pipe selection gives
additional flexibility to the SCA.
<vspace blankLines="1"/>
Pipe selection policy may be based on the
pipe parameters (e.g., delay, loss rate, throughput, etc.)
to decide which pipes will be selected. For example, only the pipes
that have close RTT values may be selected or some pipes with high BERs
may be excluded.
<vspace blankLines="1"/>
In addition, pipe selection policy may be based on the TCP end-points.
For example, some privileged flows (e.g., flows originated from
some IP addresses) may be assigned more pipes and some other flows
may be penalized and forced to use only a single pipe.
</t>
<!-- **************** PIPE SELECTION POLICY END ***************** -->
</list>
</t>
</section>
<!-- ****************** CONFIGURATION & MANAGEMENT END ******************* -->
</section>
<!-- ******************************* SCA END ******************************** -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************* SCA DEPLOYMENT BEGIN ************************* -->
<section title="SCA Deployment Scenarios" anchor="sec-sca-deployment">
<t>
SCAPs may work in three modes:
<list style="numbers">
<t>
Standalone SCAP: If there is only one
SCAP on the path between the TCP sender
and the receiver, SCAP must work alone
</t>
<t>
SCAP Pair: If there are two SCAPs on
the path, then they may work as a peer
</t>
<t>
SCAP Chain: If there are multiple SCAPs
on the path, then they may be used as
cascaded chains
</t>
</list>
</t>
<!-- ************************ STANDALONE SCAP BEGIN *********************** -->
<section title="Standalone SCAP" anchor="sec-single-scap">
<t>
As shown in <xref target="fig-sca-single"/>,
SCA may still be used when there is only one SCAP on the path
between the TCP end-hosts.
<figure align="center"
anchor="fig-sca-single"
title="Single SCAP Between TCP End Hosts">
<artwork align="center"><![CDATA[
+-----------+ +-----------+
| | | |
|Application|<---------------End-to-End-------------->|Application|
| | | |
+-----------+ +-----------+
| |<---------------End-to-End-------------->| |
| TCP | +--------+ | TCP |
| | | SCAP | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
| | | | | | | | | |
| IP |<->| IP |<->| IP |<->| IP |<->| IP |
| | | | | | | | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
TCP Network SCAP Network TCP
End Host Device Device Device End Host
]]></artwork>
</figure>
</t>
<t>
If there are multiple pipes from the SCAP to the TCP end-hosts,
the SCAP may split and shape TCP traffic over them
(e.g., <xref target="ref-ayar12a"/>).
Since there is only one SCAP, it must work without
any feedback via the signaling messages of the peer SCAP.
Therefore, SCAP MUST NOT use signaling information during
data transfer.
</t>
<t>
TCP end-hosts MUST NOT notice the existence of the SCAP.
The TCP end-hosts will only see the effects of TCP
traffic shaping.
</t>
</section>
<!-- ************************* STANDALONE SCAP END ************************ -->
<!-- *************************** SCAP PEER BEGIN ************************** -->
<section title="SCAP Peer" anchor="sec-scap-peer">
<t>
As shown in <xref target="fig-sca-peer"/>, SCAPs MAY work as a peer.
The SCAP device peer may be located on the same access network as well
as different access networks.
</t>
<t>
<xref target="sec-sca-reference-scenario"/> discusses a scenario of
SCAP devices located on different access networks.
</t>
<t>
<xref target="fig-sca-same-network"/> shows two SCAP
devices within the same access network. A TCP connection is
established between an application on
the single-homed Host A to an application on single-homed Host B.
</t>
<t>
In the data flow from Host A to Host B, SCAP-1 may split TCP packets
via Pipe-1 and Pipe-2. This distribution may be used for load
balancing purposes within the access network. In addition, if
Pipe-1 and Pipe-2 are the bottleneck, then bandwidth aggregation
of the pipes may be achieved. SCAP-2 combines the distributed
packets, re-orders them and sends them in-order to the Internet.
Similarly, for the data flow from Host B to Host A, SCAP-2 may
split packets over Pipe-1 and Pipe-2 while SCAP-1 may combine them.
</t>
<figure align="center" anchor="fig-sca-same-network"
title="SCAPs on The Same Access Network">
<artwork align="left"><![CDATA[
_____________________________ ____
| +---------------+ | ( )
+------+ | | Pipe-2 | | ( ) +------+
| | | +------+ +------+ | ( ) | |
| Host |---|-|SCAP-1|--------|SCAP-2|--|----( )---| Host |
| | | +------+ Pipe-1 +------+ | ( INTERNET ) | |
| A | | | ( ) | B |
| | | | ( ) | |
+------+ | Access Network | ( ) +------+
|___________________________| (____)
]]></artwork>
</figure>
</section>
<!-- **************************** SCAP PEER END *************************** -->
<!-- ************************** SCAP CHAIN BEGIN ************************** -->
<section title="SCAP Chain" anchor="sec-scap-chain">
<t>
As shown in <xref target="fig-scap-chain"/>, more than two SCAPs may
be available on the path between the TCP end-hosts.
In that case, SCAP peers constitute a SCAP chain.
A SCAP distributes TCP packets over multiple pipes, and its peer
combines them. This split/combine process is then repeated between each
SCAP pair.
<figure align="center"
anchor="fig-scap-chain"
title="A SCAP Chain Between TCP End Hosts">
<artwork align="center"><![CDATA[
+-----------+ +-----------+
| | | |
|Application|<---------------End-to-End-------------->|Application|
| | | |
+-----------+ +-----------+
| |<---------------End-to-End-------------->| |
| TCP | +--------+ +--------+ +-------+ | TCP |
| | | SCAP |<->| SCAP |<->| SCAP | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
| | | | | | | | | |
| IP |<->| IP |<->| IP |<->| IP |<->| IP |
| | | | | | | | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
TCP SCAP SCAP SCAP TCP
End Host Device Device Device End Host
]]></artwork>
</figure>
</t>
</section>
<!-- *************************** SCAP CHAIN END ************************** -->
</section>
<!-- ************************** SCA DEPLOYMENT END ************************** -->
<!-- ************************* SCA EXTENSIONS BEGIN ************************* -->
<section title="SCA Extensions"
anchor="sec-sca-extensions">
<t>
Since SCA is a thin layer underneath the TCP, it MAY also be placed on
multi homed TCP end-hosts.
SCA SHOULD be located in between the TCP and IP when it
is used on the TCP end-hosts. Alternatively, SCA MAY be
located between the IP and data link layer.
</t>
<t>
<xref target="fig-scap-end-host"/> shows a SCAP peer on TCP end-hosts.
SCA may be also used in the standalone setting
(i.e., only on one TCP end-host).
</t>
<t>
Neither TCP nor IP SHOULD perceive the
intervention of the SCAP:
<list style="symbols">
<t>
TCP sends outgoing TCP packets to its lower layer entity.
</t>
<t>
IP passes incoming TCP packets to its upper layer entity.
</t>
</list>
In both cases, SCAP captures packets and processes them without
TCP or IP having knowledge about that.
</t>
<figure align="center"
anchor="fig-scap-end-host"
title="SCAPs on TCP End-Hosts">
<artwork align="center"><![CDATA[
+-------------+ +-------------+
| Application |<-------------End-to-End-------------->| Application |
+-------------+ +-------------+
| TCP |<-------------End-to-End-------------->| TCP |
+-------------+ +-------------+
| SCAP |<------------SCAP-to-SCAP------------->| SCAP |
+-------------+ +-------------+ +-------------+ +-------------+
| IP |<->| IP |<->| IP |<->| IP |
+-------------+ +-------------+ +-------------+ +-------------+
TCP End Host Network Network TCP End Host
(SCAP Device) Device Device (SCAP Device)
]]></artwork>
</figure>
<t>
Finally, in the most general case, SCAPs on TCP end-hosts MAY
collaborate with the SCAPs on
network devices as shown in <xref target="fig-scap-general-case"/>.
<figure align="center"
anchor="fig-scap-general-case"
title="SCAPs as End-Hosts and Routers">
<artwork align="center"><![CDATA[
+-------------+ +-------------+
| Application |<-------------End-to-End-------------->| Application |
+-------------+ +-------------+
| TCP |<-------------End-to-End-------------->| TCP |
+-------------+ +-------------+ +-------------+ +-------------+
| SCAP |<->| SCAP |<->| SCAP |<->| SCAP |
+-------------+ +-------------+ +-------------+ +-------------+
| IP |<->| IP |<->| IP |<->| IP |
+-------------+ +-------------+ +-------------+ +-------------+
TCP End Host SCAP SCAP TCP End Host
(SCAP Device) Device Device (SCAP Device)
]]></artwork>
</figure>
</t>
</section>
<!-- ************************** SCA EXTENSIONS END ************************** -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************ ACKNOWLEDGEMENTS BEGIN ************************ -->
<!--
<section title="Acknowledgements" anchor="acknowledgements">
<t>
Authors would like to thank to...
</t>
</section>
-->
<!-- ************************* ACKNOWLEDGEMENTS END ************************* -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ****************************** IANA BEGIN ****************************** -->
<section anchor="iana" title="IANA Considerations">
<t>
This draft includes no IANA considerations.
</t>
</section>
<!-- ******************************* IANA END ******************************* -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- ************************************************************************ -->
<!-- **************************** SECURITY BEGIN **************************** -->
<section anchor="security" title="Security Considerations">
<t>
Will be added in a later version of this document.
</t>
</section>
<!-- ***************************** SECURITY END ***************************** -->
</middle>
<!-- **************************** MIDDLE MATTER END **************************** -->
<!-- **************************** BACK MATTER BEGIN **************************** -->
<back>
<!-- ********************** NORMATIVE REFERENCES BEGIN ********************** -->
<references title="Normative References">
&RFC2119;
</references>
<!-- *********************** NORMATIVE REFERENCES END *********************** -->
<!-- ********************* INFORMATIVE REFERENCES BEGIN ********************* -->
<references title="Informative References">
&RFC0791;
&RFC0793;
&RFC1323;
&RFC1853;
&RFC2018;
&RFC2453;
&RFC2863;
&RFC2883;
&RFC2003;
&RFC4022;
&RFC1771;
&RFC4293;
&RFC4898;
&RFC6182;
&RFC6356;
&MPTCP;
&MPTCPAPI;
<reference anchor="ref-ayar12"
target="http://www.tkn.tu-berlin.de/menue/publications/tkn_technical_report_series/">
<front>
<title>
A Splitter/Combiner Architecture for TCP over Multiple Paths
</title>
<author fullname="Tacettin Ayar" initials="T.A." surname="Ayar" />
<author fullname="Berthold Rathke" initials="B.R." surname="Rathke" />
<author fullname="Lukasz Budzisz" initials="L.B." surname="Budzisz" />
<author fullname="Adam Wolisz" initials="A.W." surname="Wolisz" />
<date year="2012" month="February"/>
</front>
<seriesInfo name="TKN Technical Report Series" value="TKN-12-001"/>
</reference>
<reference anchor="ref-ayar12a">
<front>
<title>
TCP over Multiple Paths Revisited: Towards Transparent Proxy Solutions
</title>
<author fullname="Tacettin Ayar" initials="T.A." surname="Ayar" />
<author fullname="Berthold Rathke" initials="B.R." surname="Rathke" />
<author fullname="Lukasz Budzisz" initials="L.B." surname="Budzisz" />
<author fullname="Adam Wolisz" initials="A.W." surname="Wolisz" />
<date year="2012" month="June"/>
</front>
<seriesInfo name="Accepted by The IEEE International Conference on Communications 2012"
value="(IEEE ICC'12)" />
</reference>
</references>
<!-- ********************** INFORMATIVE REFERENCES END ********************** -->
</back>
<!-- ***************************** BACK MATTER END ***************************** -->
</rfc>
<!-- ********************************** RFC END ********************************** -->| PAFTECH AB 2003-2026 | 2026-04-24 05:06:59 |