DCCP Extensions for Multipath Operation with Multiple Addresses

3.2.1. MP_CONFIRM

              1          2          3           4          5
   01234567 89012345 67890123 45678901 23456789 01234567 89012345
  +--------+--------+--------+--------+--------+--------+--------+
  |00101110|  var   |00000000| List of confirmations ...
  +--------+--------+--------+--------+--------+--------+--------+
   Type=46   Length  MP_OPT=0

Some multipath options require confirmation from the remote peer (see Table 4). Such options will be retransmitted by the sender until a MP_CONFIRM is received or confirmation of options is identified outdated. The further processing of the multipath options in the receiving host is not the subject of MP_CONFIRM.¶

As the transmission of multipath suboptions is subject to out-of-order arrival, suboptions defined in Table 4 SHALL be sent in a DCCP datagram with MP_SEQ Section 3.2.5. This allows to identify outdated suboptions which updates the same dataset. In case of MP_ADDADDR, MP_REMOVEADDR the same dataset is identified based on AddressID, whereas the same dataset for MP_PRIO is identified by the subflow in use. An outdated suboption is detected at the receiver if a previous suboption referring to the same dataset contained a higher sequence number carried by MP_SEQ. Generating a MP_CONFIRM for suboptions identified outdated is optional.¶

Similarly MP_CONFIRM is subject to out-of-order arrival. To ensure that the most recent suboption is confirmed the associated MP_SEQ received MUST be echoed. Otherwise inconsistency happens if between updates of a dataset with the same value, another value is sent. If the MP_CONFIRM of the second update and the third update itself gets lost, the value of the second update is applied on receiver side without being detected by the sender.¶

The length and sending path of the MP_CONFIRM are dependent on the confirmed suboptions and the received MP_SEQ, which will be both copied verbatim and appended as list of confirmations. The order within this list is the confirmed suboption first followed by the received MP_SEQ.¶

3.2.2. MP_JOIN

              1          2          3
   01234567 89012345 67890123 45678901
  +--------+--------+--------+--------+
  |00101110|00001100|00000001| Addr ID|
  +--------+--------+--------+--------+
  | Path Token                        |
  +--------+--------+--------+--------+
  | Nonce                             |
  +--------+--------+--------+--------+
   Type=46  Length=12 MP_OPT=1

The MP_JOIN option is used by a host to add a new subflow to an existing MP-DCCP connection. The Path Token is the SHA256 hash of the derived key (d-key), which was previously exchanged with the MP_KEY option. MP_HMAC MUST be set when using MP_JOIN to provide authentication (See MP_HMAC for details). Also MP_KEY MUST be set to provide key material for authentication purposes.¶

The MP_JOIN option includes an "Addr ID" (Address ID) generated by the sender of the option, used to identify the source address of this packet, even if the IP header has been changed in transit by a middlebox. The numeric value of this field is generated by the sender and must map uniquely to a source IP address for the sending host. The Address ID allows address removal (Section 3.2.9) without needing to know what the source address at the receiver is, thus allowing address removal through NATs. The Address ID also allows correlation between new subflow setup attempts and address signaling (Section 3.2.8), to prevent setting up duplicate subflows on the same path, if an MP_JOIN and MP_ADDADDR are sent at the same time.¶

The Address IDs of the subflow used in the initial DCCP Request/Response exchange of the first subflow in the connection are implicit, and have the value zero. A host MUST store the mappings between Address IDs and addresses both for itself and the remote host. An implementation will also need to know which local and remote Address IDs are associated with which established subflows, for when addresses are removed from a local or remote host. An Address ID always has to be unique over the lifetime of a subflow and can only be re-assigned if sender and receiver no longer have them in use.¶

The Nonce is a 32-bit random value locally generated for every MP_JOIN option. Together with the Token, the Nonce value builds the basis to calculate the HMAC used in the handshaking process as described in Section 3.3.¶

3.2.3. MP_FAST_CLOSE

Regular DCCP has the means of sending a Close or Reset signals to abruptly close a connection. With MP-DCCP, a regular Close or Reset only has the scope of the subflow over which the signal was received. As such, it will only close the applicable subflow and will not affect the remaining subflows concurrently in use on other paths. A MP-DCCP connection will stay alive at the data level in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MP-DCCP-level "Reset" to allow the abrupt closure of the whole MP-DCCP connection; this is done via the MP_FAST_CLOSE suboption.¶

              1          2          3
   01234567 89012345 67890123 45678901 23456789
  +--------+--------+--------+--------+--------+
  |00101110|  var   |00000010| Key Data ...
  +--------+--------+--------+--------+--------+
   Type=46   Length  MP_OPT=2

For being effective, the MP_FAST_CLOSE suboption MUST be sent from an initiating host on all subflows as part of a DCCP-Reset packet with Reset Code 13. To protect unauthorized shutdown of a multipath DCCP connection, the selected Key Data of the peer host during the handshaking procedure is carried by the MP_FAST_CLOSE option.¶

With completion of this step, the initiating host can tear down the subflows and the multipath DCCP connection immediately terminates.¶

Upon reception of the MP_FAST_CLOSE and successful validation of the Key Data at the peer host, a DCCP Reset packet is replied on all subflows to the initiating host with Reset Code 13. The peer host can now close the whole MP-DCCP connection (i.e., it transitions the connection state directly to CLOSED).¶

3.2.4. MP_KEY

                       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
  +---------------+---------------+---------------+---------------+
  |0 0 1 0 1 1 1 0|      var      |0 0 0 0 0 0 1 1| Key Type (1)  |
  +---------------+---------------+---------------+---------------+
  |  Key Data (1) |  Key Type (2) |  Key Data (2) | ....
  +---------------+---------------+---------------+---------------+
      Type=46          Length         MP_OPT=3

The MP_KEY suboption is used to exchange key material between hosts for a given connection. The Length varies between 12 and 68 Bytes for a single-key message, and up to 110 Bytes when all specified Key Types 0-2 are provided. The Key Type field is used to specify the type of the following key data. Key types are shown in Table 5.¶

Plain Text

Key Material is exchanged in plain text between hosts, and the key parts (key-a, key-b) are used by each host to generate the derived key (d-key) by concatenating the two parts with the local key in front (e.g. hostA d-key(A)=(key-a+key-b), hostB d-key(B)=(key-b+key-a)).¶

ECDHE-SHA256-C25519

Public Key Material is exchanged via ECDHE key exchange with SHA256 and Curve 25519 to generate the derived key (d-key) from the shared secret.¶

ECDHE-SHA512-C25519

Public Key Material is exchanged via ECDHE key exchange with SHA512 and Curve 25519 to generate the derived key (d-key) from the shared secret.¶

Providing multiple keys is only permitted in the DCCP-Request message of the handshake procedure for the first subflow, and allows the hosts to agree on a single key type to be used as described in Section 3.3¶

3.2.5. MP_SEQ

              1          2          3           4          5
   01234567 89012345 67890123 45678901 23456789 01234567 89012345
  +--------+--------+--------+--------+--------+--------+--------+
  |00101110|00001001|00000100| Multipath Sequence Number
  +--------+--------+--------+--------+--------+--------+--------+
  |                 |
  +--------+--------+
   Type=46  Length=9 MP_OPT=4

The MP_SEQ suboption is used for end-to-end datagram-based sequence numbers of an MP-DCCP connection. The initial data sequence number (IDSN) SHOULD be set randomly [RFC4086].¶

The MP_SEQ number space is different from the path individual sequence number space and MUST be sent with any DCCP-Data and DCCP-DataACK packet.¶

3.2.6. MP_HMAC

              1          2          3           4
   01234567 89012345 67890123 45678901 23456789 01234567
  +--------+--------+--------+--------+--------+--------+
  |00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
  +--------+--------+--------+--------+--------+--------+
   Type=46  Length=23 MP_OPT=5

The MP_HMAC suboption is used to provide authentication for the MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR suboptions. The HMAC code is generated according to [RFC2104] in combination with the SHA256 hash algorithm described in [RFC6234], with the output truncated to the leftmost 160 bits (20 bytes).¶

The "Key" used for the HMAC computation is the derived key (d-key) described in Section 3.2.4, while the HMAC "Message" is a concatenation of¶

• MP_JOIN: The token and nonce of the MP_JOIN for which authentication shall be performed.¶
• MP_ADDADDR: The Address ID with associated IP address and if defined port, otherwise two octets of value 0.¶
• MP_REMOVEADDR: Solely the Address ID.¶

MP_JOIN, MP_ADDADDR and MP_REMOVEADDR can co-exist or be used multiple times within a single DCCP packet. As all this multipath options come along with an individual MP_HASH option, this requires the MP_HASH to be correctly associated. Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR or MP_REMOVEADDR. Therefore, a MP_HASH MUST directly follow its associated multipath option.¶

3.2.7. MP_RTT

              1          2          3           4          5
   01234567 89012345 67890123 45678901 23456789 01234567 89012345
  +--------+--------+--------+--------+--------+--------+--------+
  |00101110|00001100|00000110|RTT Type| RTT
  +--------+--------+--------+--------+--------+--------+--------+
  |        | Age                               |
  +--------+--------+--------+--------+--------+
   Type=46  Length=12 MP_OPT=6

The MP_RTT suboption is used to transmit RTT values in milliseconds and MUST belong to the path over which this information is transmitted. Additionally, the age of the measurement is specified in milliseconds. This information is in particular useful for the receiving host to calculate the RTT difference between the subflows and to estimate whether missing data has been lost.¶

The RTT and Age information is a 32-bit integer, which allows to cover a period of approximately 1193 hours.¶

Raw RTT (=0)

Raw RTT value of the last Datagram Round-Trip preferably provided by the CCID in use.¶

Min RTT (=1)

Min RTT value over a given period preferably provided by the CCID in use.¶

Max RTT (=2)

Max RTT value over a given period preferably provided by the CCID in use.¶

Smooth RTT (=3)

Averaged RTT value over a given period preferably provided by the CCID in use.¶

Age

The Age parameter defines the time difference between now - creation of the MP_RTT option - and the conducted RTT measurement in milliseconds. If no previous measurement exists, e.g., when initialized, the value is 0.¶

In Figure 10 an exemplary flow shows the exchange of path individual RTT information with RTT1 pointing to a first path and RTT2 to a second path. Those RTT values might be extracted from the sender's Congestion Control procedure and carried to the receiving host using MP_RTT suboption. With the reception of RTT1 and RTT2, the receiver is able to calculate the path_delta which corresponds to the absolute difference of both values. In case the path individual RTTs are symmetric in down- and uplink direction, packets with missing sequence number MP_SEQ, e.g., in a reordering process, can be assumed lost after path_delta/2.¶

   MP-DCCP                   MP-DCCP
   Sender                    Receiver
   +--------+  MP_RTT(RTT1)  +-------------+
   |   RTT1 |----------------|             |
   |        |                | path_delta= |
   |        |  MP_RTT(RTT2)  | |RTT1-RTT2| |
   |   RTT2 |----------------|             |
   +--------+                +-------------+

3.2.8. MP_ADDADDR

The MP_ADDADDR suboption announces additional addresses (and, optionally, port numbers) on which a host can be reached. This option can be used at any time during an existing DCCP connection, when the sender wishes to enable multiple paths and/or when additional paths become available. Multiple instances of this suboption within a packet advertise simultaneously new addresses.¶

Length is variable depending on the address family (IPv4 or IPv6) and whether a port number is used. This field is in range between 8 and 22 bytes.¶

The presence of the final 2 octets, specifying the DCCP port number to use, are optional and can be inferred from the length of the option. Although it is expected that the majority of use cases will use the same port pairs as used for the initial subflow (e.g., port 80 remains port 80 on all subflows, as does the ephemeral port at the client), there may be cases (such as port-based load balancing) where the explicit specification of a different port is required. If no port is specified, the receiving peer SHOULD assume that any attempt to connect to the specified address has to be on the same port as is already in use by the subflow on which the MP_ADDADDR signal was sent.¶

Along with the MP_ADDADDR option a MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter present in this MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated as described in Section 3.2.6. In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged and selected in the original MP_KEY handshake. The message for the HMAC is the Address ID, IP address, and port that precede the HMAC in the MP_ADDADDR option. If the port is not present in the MP_ADDADDR option, the HMAC message will nevertheless include 2 octets of value zero. The rationale for the HMAC is to prevent unauthorized entities from injecting MP_ADDADDR signals in an attempt to hijack a connection. Note that, additionally, the presence of this HMAC prevents the address from being changed in flight unless the key is known by an intermediary. If a host receives an MP_ADDADDR option for which it cannot validate the HMAC, it SHOULD silently ignore the option.¶

The presence of a MP_SEQ Section 3.2.5 MUST be ensured in a DCCP datagram in which MP_ADDADDR is sent. Further details are given in Section 3.2.1.¶

                      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
  +---------------+---------------+-------+-------+---------------+
  |0 0 1 0 1 1 1 0|      var      |0 0 0 0 0 1 1 1|  Address ID   |
  +---------------+---------------+-------+-------+---------------+
  |          Address (IPv4 - 4 bytes / IPv6 - 16 bytes)           |
  +-------------------------------+-------------------------------+
  |   Port (2 bytes, optional)    | + MP_HMAC option
  +-------------------------------+
       Type=46         Length         MP_OPT=7

Every address has an Address ID that can be used for uniquely identifying the address within a connection for address removal. The Address ID is also used to identify MP_JOIN options (see Section 3.2.2) relating to the same address, even when address translators are in use. The Address ID MUST uniquely identify the address for the sender of the option (within the scope of the connection); the mechanism for allocating such IDs is implementation specific.¶

All Address IDs learned via either MP_JOIN or MP_ADDADDR SHOULD be stored by the receiver in a data structure that gathers all the Address-ID-to-address mappings for a connection (identified by a token pair). In this way, there is a stored mapping between the Address ID, observed source address, and token pair for future processing of control information for a connection. Note that an implementation MAY discard incoming address advertisements at will, for example, for avoiding the required mapping state, or because advertised addresses are of no use to it (for example, IPv6 addresses when it has IPv4 only). Therefore, a host MUST treat address advertisements as soft state, and it MAY choose to refresh advertisements periodically.¶

Due to the proliferation of NATs, it is reasonably likely that one host may attempt to advertise private addresses. It is not desirable to prohibit this, since there may be cases where both hosts have additional interfaces on the same private network, and a host MAY want to advertise such addresses. The MP_JOIN handshake to create a new subflow (Section 3.2.2) provides mechanisms to minimize security risks. The MP_JOIN message contains a 32-bit token that uniquely identifies the connection to the receiving host. If the token is unknown, the host will return with a DCCP-Reset. In the unlikely event that the token is known, subflow setup will continue, but the HMAC exchange must occur for authentication. This will fail, and will provide sufficient protection against two unconnected hosts accidentally setting up a new subflow upon the signal of a private address. Further security considerations around the issue of MP_ADDADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in Section 4. In case a sending host of a MP_ADDADDR knows about the inability to establish incoming subflows on a particular address, a MP_ADDADDR SHOULD NOT advertise this address unless sending host has new knowledge about the ability. Such ability information can be obtained from local firewall or routing settings, knowledge about availability of external NAT or firewall, or from connectivity checks performed by the host/application.¶

The reception of an MP_ADDADDR message is acknowledged using MP_CONFIRM (Section 3.2.1). Using this mechanism reliable exchange of address information is ensured.¶

A host can send an MP_ADDADDR message with an already assigned Address ID, but the Address MUST be the same as previously assigned to this Address ID, and the Port MUST be different from one already in use for this Address ID. If these conditions are not met, the receiver SHOULD silently ignore the MP_ADDADDR. A host wishing to replace an existing Address ID MUST first remove the existing one (Section 3.2.9).¶

A host that receives an MP_ADDADDR but finds a connection set up to that IP address and port number is unsuccessful SHOULD NOT perform further connection attempts to this address/port combination for this connection. However, a sender that wants to trigger a new incoming connection attempt on a previously advertised address/port combination can therefore refresh MP_ADDADDR information by sending the option again.¶

3.2.9. MP_REMOVEADDR

If, during the lifetime of an MP-DCCP connection, a previously announced address becomes invalid (e.g., if an interface disappears), the affected host SHOULD announce this so that the peer can remove subflows related to this address.¶

This is achieved through the Remove Address (MP_REMOVEADDR) suboption which will remove a previously added address with an Address ID from a connection and terminate any subflows currently using that address.¶

Along with the MP_REMOVEADDR suboption a MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter present in this MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated as described in Section 3.2.6. In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged and selected in the original MP_KEY handshake. The message for the HMAC is the Address ID. The rationale for the HMAC is to prevent unauthorized entities from injecting MP_REMOVEADDR signals in an attempt to hijack a connection. Note that, additionally, the presence of this HMAC prevents the address from being removed in flight unless the key is known by an intermediary. If a host receives an MP_REMOVEADDR option for which it cannot validate the HMAC, it SHOULD silently ignore the option.¶

The presence of a MP_SEQ Section 3.2.5 MUST be ensured in a DCCP datagram in which MP_REMOVEADDR is sent. Further details are given in Section 3.2.1.¶

The reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM (Section 3.2.1). Using this mechanism reliable exchange of address information is ensured. To avoid inconsistent states, it is recommended to release the sender address ID only after MP_REMOVEADDR has been confirmed.¶

The sending and receipt of this message SHOULD trigger the sending of DCCP-Close and DCCP-Reset by client and server, respectively on the affected subflow(s) (if possible), as a courtesy to cleaning up middlebox state, before cleaning up any local state.¶

Address removal is undertaken by ID, so as to permit the use of NATs and other middleboxes that rewrite source addresses. If there is no address at the requested ID, the receiver will silently ignore the request.¶

                     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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 0|   Address ID  |
+---------------+---------------+---------------+---------------+
     Type=46        Length=4         MP_OPT=8

-> followed by MP_HMAC option

A subflow that is still functioning MUST be closed with a DCCP-Close or exchange as in regular DCCP, rather than using this option. For more information, see Section Section 3.4.¶

3.2.10. MP_PRIO

In the event that a single specific path out of the set of available paths shall be treated with higher priority compared to the others when making scheduling decisions for user plane traffic, a host may wish to signal such change in priority to the peer. One reason for such behavior is due to the different costs involved in using different paths (e.g., WiFi is free while cellular has limit on volume, 5G has higher energy consumption). Also, the priority of a path may be subject to dynamic changes, for example when the mobile runs out of battery, the usage of only a single path may be the preferred choice of the user. Therefore, the path priority should be considered as hints for the packet scheduler when making decisions which path to use for user plane traffic.¶

The MP_PRIO suboption, shown below, can be used to set a priority flag for the path over which the suboption is received.¶

                        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
   +---------------+---------------+---------------+--------------+
   |0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 1|  Address ID  |
   +---------------+---------------+---------------+--------------+
       Type=46         Length=4        MP_OPT=9

The following values are available for Prio field:¶

• 0: Do not use. The path is not available.¶
• 1: Standby: do not use this path for traffic scheduling, if another path (secondary or primary) is available. The path will only be used if other secondary or primary paths are not established.¶
• 2: Secondary: do not use this path for traffic scheduling, if the other paths are good enough. The path will be used occasionally for increasing temporarily the available capacity, e.g. when primary paths are congested or are not available. This is the recommended setting for paths that have costs or data caps as these paths will be used less frequently then primary paths.¶
• 3 - 15: Primary: can use the path in any way deemed reasonable by peer. The path will always be used for packet scheduling decisions. The priority number indicates the relative priority of one path over the other for primary paths. Higher numbers indicate higher priority. The peer should consider sending more traffic over higher priority paths. This is the recommended setting for paths that do not have a cost or data caps associated with them as these paths will be frequently used.¶

Example use cases include: 1) Setting Wi-Fi path to Primary and Cellular paths to Secondary. In this case Wi-Fi will be used and Cellular only if the Wi-Fi path is congested or not available. Such setting results in using the Cellular path only temporally, if more capacity is needed than the WiFi path can provide, indicating a clear priority of the Wi-Fi path over the Cellular due to e.g. cost reasons. 2) Setting Wi-Fi path to Primary and Cellular to Standby. In this case Wi-Fi will be used and Cellular only, if the Wi-Fi path is not available. 3) Setting Wi-Fi path to Primary and Cellular path to Primary. In this case, all packets can be scheduled over all paths at all time.¶

If not specified, the default behavior is, that a path can always be used for packet scheduling decisions (MP_PRIO=3), if the path has been established and added to an existing MP-DCCP connection. At least one path should have a MP_PRIO value greater or equal to one for it to be allowed to send on the connection. MP_PRIO is assumed to be exchanged reliably using the MP_CONFIRM mechanisms (see Table 4).¶

The presence of a MP_SEQ Section 3.2.5 MUST be ensured in a DCCP datagram in which MP_PRIO is sent. Further details are given in Section 3.2.1.¶

3.2.11. MP_CLOSE

              1          2          3
   01234567 89012345 67890123 45678901 23456789
  +--------+--------+--------+--------+--------+
  |00101110|  var   |00001010| Key Data ...
  +--------+--------+--------+--------+--------+
   Type=46   Length  MP_OPT=10

For a graceful shutdown of a MP-DCCP connection, MP_CLOSE is used to communicate this to a peer host. On all subflows, the regular termination procedure as described in [RFC4340] MUST be initiated using MP_CLOSE in the initial packet (either a DCCP-CloseReq or a DCCP-Close). In the case where a DCCP-CloseReq is used, the following DCCP-Close MUST carry the MP_CLOSE as well. At the initiator of the DCCP-CloseReq all sockets, including the MP-DCCP connection socket, transition to CLOSEREQ state. To protect unauthorized shutdown of a multi-path connection, the selected Key Data of the peer host during the handshaking procedure MUST be carried by the MP_CLOSE option and validated by the peer host. Note, Key Data is different between MP_CLOSE option carried by DCCP-CloseReq or DCCP-Close.¶

On reception of a first DCCP-CloseReq carrying a MP_CLOSE with valid Key Data, or due to a local decision, all subflows transition to the CLOSING state before transmitting a DCCP-Close carrying MP_CLOSE. In this case, the MP-DCCP connection socket on the host sending the DCCP-Close reflects the state of the initial subflow used during handshake with MP_KEY option. If the initial subflow no longer exists, the state moves immediately to CLOSED.¶

Upon reception of the first DCCP-Close carrying a MP_CLOSE with valid Key Data at the peer host, all subflows, as well as the MP-DCCP connection socket, move to the CLOSED state. After this, a DCCP-Reset with Reset Code 1 MUST be sent on any subflow in response to a received DCCP-Close containing a valid MP_CLOSE option.¶

When the MP-DCCP connection socket is in CLOSEREQ or CLOSE state, new subflow requests using MP_JOIN MUST be ignored.¶

Contrary to a MP_FAST_CLOSE Section 3.2.3, no single-sided abrupt termination is applied.¶

3.2.12. Experimental MP-DCCP Sub-Option MP_EXP for private use

This section reserves a MP-DCCP sub-option to define and specify any experimental additional feature for improving and optimization of MP-DCCP protocol. This option may be applicable to specific environments or scenarios according to potential new requirements and meant for private use only at this stage. MP_OPT feature number 11 is foreseen with an exemplary description as below:¶

                     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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|      var      |0 0 0 0 1 0 1 1|   Data TBD    |
+---------------+---------------+---------------+---------------+
|   ...
+---------------------------------------------------------------+
     Type=46         Length         MP_OPT=11

Details as length and type of data remain to be defined according to the foreseen use by the experimenters.¶