The low-level, formal and boring specs are here... :)
MPTCP is completely specified in the Procotol Draft, that you can download
from here. In this page we give only a
quick overview of the MPTCP headers internals.
The size and number of fields in the header of the MPTCP protocol is not constant but can
vary to adapt the protocol to each situation while keeping the overhead low. The fields
allowed in the MPTCP header are classified in "options groups" that we
will call "subheaders".
Please note the following constraints:
- All the subheaders are optional except head_general and one between
head_thirdaddress_v4 or head_thirdaddress_v6, that must
always be present.
- The size of each subheader is fixed and specified in this document
- The order of the subheaders is not relevant, except head_general
that must always appear as first.
- All the subheaders except head_general can be present only in the
first packet of a session.
- Each of the subheader types can appear only once in the list
except head_thirdaddress_v4 and head_thirdaddress_v6, that can
appear an arbitrary number of times to indicate that this session
will make simultaneous use of more than one server or meeting
place by sending a copy of the payload to each of them.
- The NextHeader value of the last subheader must be zero to
indicate that the payload is following.
- The subheader head_answer can be used by a MP to communicate
warning or errors to the C.
The subheaders present in a packet take the form of a "linked list",
where each one is identified by the value in the "next header" field of the previous subheader.
Note that this technique is similar to the IPv6 protocol, described in RFC2460.
In the current protocol description, seven groups are present:
NextHeader Value | Name
--------------------+--------------------------
n/a | head_general
0x1 | head_thirdaddress_v6
0x2 | head_thirdaddress_v4
0x3 | head_ttl
0x4 | head_crypt
0x5 | head_multiple
0x6 | head_answer
We will describe them in the following paragraphs.
The MPTCP head_general Subheader
This header is mandatory and must appear in each packet of the session,
always in the first position of the subheader list. The first bit of the
"TYPE" field must be the first bit of the underlying network layer.
The head_general subheader contains information about the content-id,
the source and destination ports for layer-3 multiplexing, flow control
information, session establishment and reset information and congestion
control data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | Content-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |U|A|P|R|S|F| |
| NxtH |GZ |Padding|R|C|S|S|Y|I| Window |
| | | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPTCP head_thirdaddress_v6 Subheader
For direct requests, this header specifies the Server address to store the data on.
For reverse requests, it specifies the Meeting Place address. It is called "third address"
because it completes the set containing the Source and Destination addresses.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NxtH | Destination Port | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Third Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Third Address (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Third Address (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Third Address (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPTCP head_thirdaddress_v4 Subheader
For direct requests, this header specifies the Server address to store the data on.
For reverse requests, it specifies the Meeting Place address. It is called "third address"
because it completes the set containing the Source and Destination addresses.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NxtH | Destination Port | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Third Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPTCP head_ttl Subheader
This subheader can be included by the client to specify how long the data
should be stored on the Meeting Place. This Time-To-Live value is expressed
as the number of integer seconds since the Unix Epoch (01/01/1970 at 0:00GMT).
Using this standard and allocating 60 bits for the timestamp field, we are able
to describe time without compatibility problems in the future. Also, by using
this approach, the 64bit implementations could just copy the system timestamp
and removing the 4 most significant bits.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NxtH | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPTCP head_crypt Subheader
This header specifies the details for the data encryption, such as the
encryption algorithm and the X.509 certificate, that contains the node's public key.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NxtH | SeLvL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pre-secret |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X.509 Cert. (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// (...) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding, if needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPTCP head_multiple Subheader
This subheader can be used in Multiple requests to specify the
number of requests to be done and the time distance between them.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NxtH | num_times | time_diff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPTCP head_answer Subheader
This subheader is used by the MP to communicate Errors, Warnings and informative
messages to the C. Eight "error levels" are defined to specify the seriousness
of a problem. Higher levels are simply informative and do not affect the operation of the protocol.
A Warning is considered a non-blocking error given to the C to signal a unusual
condition (i.e. space quota almost full). An Error requires the closing of the
connection, with the use of the FIN and RST fields.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NxtH | Lvl | Message Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol Operations
The MPTCP state machine identical to TCP, and both protocols share the same "three-way handshaking" procedures
and congestion and flow control.
For more detailed information please refer to the Protocol Draft, available for download from
here.
|
