tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6824

 
 
 

TCP Extensions for Multipath Operation with Multiple Addresses

Part 2 of 4, p. 12 to 35
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
3.  MPTCP Protocol

   This section describes the operation of the MPTCP protocol, and is
   subdivided into sections for each key part of the protocol operation.

   All MPTCP operations are signaled using optional TCP header fields.
   A single TCP option number ("Kind") has been assigned by IANA for
   MPTCP (see Section 8), and then individual messages will be
   determined by a "subtype", the values of which are also stored in an
   IANA registry (and are also listed in Section 8).

Top      Up      ToC       Page 13 
   Throughout this document, when reference is made to an MPTCP option
   by symbolic name, such as "MP_CAPABLE", this refers to a TCP option
   with the single MPTCP option type, and with the subtype value of the
   symbolic name as defined in Section 8.  This subtype is a 4-bit field
   -- the first 4 bits of the option payload, as shown in Figure 3.  The
   MPTCP messages are defined in the following sections.

                           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
      +---------------+---------------+-------+-----------------------+
      |     Kind      |    Length     |Subtype|                       |
      +---------------+---------------+-------+                       |
      |                     Subtype-specific data                     |
      |                       (variable length)                       |
      +---------------------------------------------------------------+

                       Figure 3: MPTCP Option Format

   Those MPTCP options associated with subflow initiation are used on
   packets with the SYN flag set.  Additionally, there is one MPTCP
   option for signaling metadata to ensure segmented data can be
   recombined for delivery to the application.

   The remaining options, however, are signals that do not need to be on
   a specific packet, such as those for signaling additional addresses.
   Whilst an implementation may desire to send MPTCP options as soon as
   possible, it may not be possible to combine all desired options (both
   those for MPTCP and for regular TCP, such as SACK (selective
   acknowledgment) [11]) on a single packet.  Therefore, an
   implementation may choose to send duplicate ACKs containing the
   additional signaling information.  This changes the semantics of a
   duplicate ACK; these are usually only sent as a signal of a lost
   segment [12] in regular TCP.  Therefore, an MPTCP implementation
   receiving a duplicate ACK that contains an MPTCP option MUST NOT
   treat it as a signal of congestion.  Additionally, an MPTCP
   implementation SHOULD NOT send more than two duplicate ACKs in a row
   for the purposes of sending MPTCP options alone, in order to ensure
   no middleboxes misinterpret this as a sign of congestion.

   Furthermore, standard TCP validity checks (such as ensuring the
   sequence number and acknowledgment number are within window) MUST be
   undertaken before processing any MPTCP signals, as described in [13].

Top      Up      ToC       Page 14 
3.1.  Connection Initiation

   Connection initiation begins with a SYN, SYN/ACK, ACK exchange on a
   single path.  Each packet contains the Multipath Capable (MP_CAPABLE)
   TCP option (Figure 4).  This option declares its sender is capable of
   performing Multipath TCP and wishes to do so on this particular
   connection.

   This option is used to declare the 64-bit key that the sender has
   generated for this MPTCP connection.  This key is used to
   authenticate the addition of future subflows to this connection.
   This is the only time the key will be sent in clear on the wire
   (unless "fast close", Section 3.5, is used); all future subflows will
   identify the connection using a 32-bit "token".  This token is a
   cryptographic hash of this key.  The algorithm for this process is
   dependent on the authentication algorithm selected; the method of
   selection is defined later in this section.

   This key is generated by its sender, and its method of generation is
   implementation specific.  The key MUST be hard to guess, and it MUST
   be unique for the sending host at any one time.  Recommendations for
   generating random numbers for use in keys are given in [14].
   Connections will be indexed at each host by the token (a one-way hash
   of the key).  Therefore, an implementation will require a mapping
   from each token to the corresponding connection, and in turn to the
   keys for the connection.

   There is a risk that two different keys will hash to the same token.
   The risk of hash collisions is usually small, unless the host is
   handling many tens of thousands of connections.  Therefore, an
   implementation SHOULD check its list of connection tokens to ensure
   there is not a collision before sending its key in the SYN/ACK.  This
   would, however, be costly for a server with thousands of connections.
   The subflow handshake mechanism (Section 3.2) will ensure that new
   subflows only join the correct connection, however, through the
   cryptographic handshake, as well as checking the connection tokens in
   both directions, and ensuring sequence numbers are in-window.  So in
   the worst case if there was a token collision, the new subflow would
   not succeed, but the MPTCP connection would continue to provide a
   regular TCP service.

   The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets
   that start the first subflow of an MPTCP connection.  The data
   carried by each packet is as follows, where A = initiator and B =
   listener.

Top      Up      ToC       Page 15 
   o  SYN (A->B): A's Key for this connection.

   o  SYN/ACK (B->A): B's Key for this connection.

   o  ACK (A->B): A's Key followed by B's Key.

   The contents of the option is determined by the SYN and ACK flags of
   the packet, verified by the option's length field.  For the diagram
   shown in Figure 4, "sender" and "receiver" refer to the sender or
   receiver of the TCP packet (which can be either host).  If the SYN
   flag is set, a single key is included; if only an ACK flag is set,
   both keys are present.

   B's Key is echoed in the ACK in order to allow the listener (Host B)
   to act statelessly until the TCP connection reaches the ESTABLISHED
   state.  If the listener acts in this way, however, it MUST generate
   its key in a way that would allow it to verify that it generated the
   key when it is echoed in the ACK.

   This exchange allows the safe passage of MPTCP options on SYN packets
   to be determined.  If any of these options are dropped, MPTCP will
   gracefully fall back to regular single-path TCP, as documented in
   Section 3.6.  Note that new subflows MUST NOT be established (using
   the process documented in Section 3.2) until a Digital Signature
   Standard (DSS) option has been successfully received across the path
   (as documented in Section 3.3).

                           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
      +---------------+---------------+-------+-------+---------------+
      |     Kind      |    Length     |Subtype|Version|A|B|C|D|E|F|G|H|
      +---------------+---------------+-------+-------+---------------+
      |                   Option Sender's Key (64 bits)               |
      |                                                               |
      |                                                               |
      +---------------------------------------------------------------+
      |                  Option Receiver's Key (64 bits)              |
      |                     (if option Length == 20)                  |
      |                                                               |
      +---------------------------------------------------------------+


              Figure 4: Multipath Capable (MP_CAPABLE) Option

   The first 4 bits of the first octet in the MP_CAPABLE option
   (Figure 4) define the MPTCP option subtype (see Section 8; for
   MP_CAPABLE, this is 0), and the remaining 4 bits of this octet
   specify the MPTCP version in use (for this specification, this is 0).

Top      Up      ToC       Page 16 
   The second octet is reserved for flags, allocated as follows:

   A: The leftmost bit, labeled "A", SHOULD be set to 1 to indicate
      "Checksum Required", unless the system administrator has decided
      that checksums are not required (for example, if the environment
      is controlled and no middleboxes exist that might adjust the
      payload).

   B: The second bit, labeled "B", is an extensibility flag, and MUST be
      set to 0 for current implementations.  This will be used for an
      extensibility mechanism in a future specification, and the impact
      of this flag will be defined at a later date.  If receiving a
      message with the 'B' flag set to 1, and this is not understood,
      then this SYN MUST be silently ignored; the sender is expected to
      retry with a format compatible with this legacy specification.
      Note that the length of the MP_CAPABLE option, and the meanings of
      bits "C" through "H", may be altered by setting B=1.

   C through H:  The remaining bits, labeled "C" through "H", are used
      for crypto algorithm negotiation.  Currently only the rightmost
      bit, labeled "H", is assigned.  Bit "H" indicates the use of HMAC-
      SHA1 (as defined in Section 3.2).  An implementation that only
      supports this method MUST set bit "H" to 1, and bits "C" through
      "G" to 0.

   A crypto algorithm MUST be specified.  If flag bits C through H are
   all 0, the MP_CAPABLE option MUST be treated as invalid and ignored
   (that is, it must be treated as a regular TCP handshake).

   The selection of the authentication algorithm also impacts the
   algorithm used to generate the token and the initial data sequence
   number (IDSN).  In this specification, with only the SHA-1 algorithm
   (bit "H") specified and selected, the token MUST be a truncated (most
   significant 32 bits) SHA-1 hash ([4], [15]) of the key.  A different,
   64-bit truncation (the least significant 64 bits) of the SHA-1 hash
   of the key MUST be used as the initial data sequence number.  Note
   that the key MUST be hashed in network byte order.  Also note that
   the "least significant" bits MUST be the rightmost bits of the SHA-1
   digest, as per [4].  Future specifications of the use of the crypto
   bits may choose to specify different algorithms for token and IDSN
   generation.

   Both the crypto and checksum bits negotiate capabilities in similar
   ways.  For the Checksum Required bit (labeled "A"), if either host
   requires the use of checksums, checksums MUST be used.  In other
   words, the only way for checksums not to be used is if both hosts in
   their SYNs set A=0.  This decision is confirmed by the setting of the
   "A" bit in the third packet (the ACK) of the handshake.  For example,

Top      Up      ToC       Page 17 
   if the initiator sets A=0 in the SYN, but the responder sets A=1 in
   the SYN/ACK, checksums MUST be used in both directions, and the
   initiator will set A=1 in the ACK.  The decision whether to use
   checksums will be stored by an implementation in a per-connection
   binary state variable.

   For crypto negotiation, the responder has the choice.  The initiator
   creates a proposal setting a bit for each algorithm it supports to 1
   (in this version of the specification, there is only one proposal, so
   bit "H" will be always set to 1).  The responder responds with only 1
   bit set -- this is the chosen algorithm.  The rationale for this
   behavior is that the responder will typically be a server with
   potentially many thousands of connections, so it may wish to choose
   an algorithm with minimal computational complexity, depending on the
   load.  If a responder does not support (or does not want to support)
   any of the initiator's proposals, it can respond without an
   MP_CAPABLE option, thus forcing a fallback to regular TCP.

   The MP_CAPABLE option is only used in the first subflow of a
   connection, in order to identify the connection; all following
   subflows will use the "Join" option (see Section 3.2) to join the
   existing connection.

   If a SYN contains an MP_CAPABLE option but the SYN/ACK does not, it
   is assumed that the passive opener is not multipath capable; thus,
   the MPTCP session MUST operate as a regular, single-path TCP.  If a
   SYN does not contain a MP_CAPABLE option, the SYN/ACK MUST NOT
   contain one in response.  If the third packet (the ACK) does not
   contain the MP_CAPABLE option, then the session MUST fall back to
   operating as a regular, single-path TCP.  This is to maintain
   compatibility with middleboxes on the path that drop some or all TCP
   options.  Note that an implementation MAY choose to attempt sending
   MPTCP options more than one time before making this decision to
   operate as regular TCP (see Section 3.8).

   If the SYN packets are unacknowledged, it is up to local policy to
   decide how to respond.  It is expected that a sender will eventually
   fall back to single-path TCP (i.e., without the MP_CAPABLE option) in
   order to work around middleboxes that may drop packets with unknown
   options; however, the number of multipath-capable attempts that are
   made first will be up to local policy.  It is possible that MPTCP and
   non-MPTCP SYNs could get reordered in the network.  Therefore, the
   final state is inferred from the presence or absence of the
   MP_CAPABLE option in the third packet of the TCP handshake.  If this
   option is not present, the connection SHOULD fall back to regular
   TCP, as documented in Section 3.6.

Top      Up      ToC       Page 18 
   The initial data sequence number on an MPTCP connection is generated
   from the key.  The algorithm for IDSN generation is also determined
   from the negotiated authentication algorithm.  In this specification,
   with only the SHA-1 algorithm specified and selected, the IDSN of a
   host MUST be the least significant 64 bits of the SHA-1 hash of its
   key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B).  This
   deterministic generation of the IDSN allows a receiver to ensure that
   there are no gaps in sequence space at the start of the connection.
   The SYN with MP_CAPABLE occupies the first octet of data sequence
   space, although this does not need to be acknowledged at the
   connection level until the first data is sent (see Section 3.3).

3.2.  Starting a New Subflow

   Once an MPTCP connection has begun with the MP_CAPABLE exchange,
   further subflows can be added to the connection.  Hosts have
   knowledge of their own address(es), and can become aware of the other
   host's addresses through signaling exchanges as described in
   Section 3.4.  Using this knowledge, a host can initiate a new subflow
   over a currently unused pair of addresses.  It is permitted for
   either host in a connection to initiate the creation of a new
   subflow, but it is expected that this will normally be the original
   connection initiator (see Section 3.8 for heuristics).

   A new subflow is started as a normal TCP SYN/ACK exchange.  The Join
   Connection (MP_JOIN) TCP option is used to identify the connection to
   be joined by the new subflow.  It uses keying material that was
   exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that
   handshake also negotiates the crypto algorithm in use for the MP_JOIN
   handshake.

   This section specifies the behavior of MP_JOIN using the HMAC-SHA1
   algorithm.  An MP_JOIN option is present in the SYN, SYN/ACK, and ACK
   of the three-way handshake, although in each case with a different
   format.

   In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the
   initiator sends a token, random number, and address ID.

   The token is used to identify the MPTCP connection and is a
   cryptographic hash of the receiver's key, as exchanged in the initial
   MP_CAPABLE handshake (Section 3.1).  In this specification, the
   tokens presented in this option are generated by the SHA-1 ([4],
   [15]) algorithm, truncated to the most significant 32 bits.  The
   token included in the MP_JOIN option is the token that the receiver
   of the packet uses to identify this connection; i.e., Host A will

Top      Up      ToC       Page 19 
   send Token-B (which is generated from Key-B).  Note that the hash
   generation algorithm can be overridden by the choice of cryptographic
   handshake algorithm, as defined in Section 3.1.

   The MP_JOIN SYN sends not only the token (which is static for a
   connection) but also random numbers (nonces) that are used to prevent
   replay attacks on the authentication method.  Recommendations for the
   generation of random numbers for this purpose are given in [14].

   The MP_JOIN option includes an "Address ID".  This is an identifier
   that only has significance within a single connection, where it
   identifies the source address of this packet, even if the IP header
   has been changed in transit by a middlebox.  The Address ID allows
   address removal (Section 3.4.2) 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.4.1), to
   prevent setting up duplicate subflows on the same path, if an MP_JOIN
   and ADD_ADDR are sent at the same time.

   The Address IDs of the subflow used in the initial SYN 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.

   The MP_JOIN option on packets with the SYN flag set also includes 4
   bits of flags, 3 of which are currently reserved and MUST be set to
   zero by the sender.  The final bit, labeled "B", indicates whether
   the sender of this option wishes this subflow to be used as a backup
   path (B=1) in the event of failure of other paths, or whether it
   wants it to be used as part of the connection immediately.  By
   setting B=1, the sender of the option is requesting the other host to
   only send data on this subflow if there are no available subflows
   where B=0.  Subflow policy is discussed in more detail in
   Section 3.3.8.

Top      Up      ToC       Page 20 
                           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
      +---------------+---------------+-------+-----+-+---------------+
      |     Kind      |  Length = 12  |Subtype|     |B|   Address ID  |
      +---------------+---------------+-------+-----+-+---------------+
      |                   Receiver's Token (32 bits)                  |
      +---------------------------------------------------------------+
      |                Sender's Random Number (32 bits)               |
      +---------------------------------------------------------------+

       Figure 5: Join Connection (MP_JOIN) Option (for Initial SYN)

   When receiving a SYN with an MP_JOIN option that contains a valid
   token for an existing MPTCP connection, the recipient SHOULD respond
   with a SYN/ACK also containing an MP_JOIN option containing a random
   number and a truncated (leftmost 64 bits) Hash-based Message
   Authentication Code (HMAC).  This version of the option is shown in
   Figure 6.  If the token is unknown, or the host wants to refuse
   subflow establishment (for example, due to a limit on the number of
   subflows it will permit), the receiver will send back a reset (RST)
   signal, analogous to an unknown port in TCP.  Although calculating an
   HMAC requires cryptographic operations, it is believed that the 32-
   bit token in the MP_JOIN SYN gives sufficient protection against
   blind state exhaustion attacks; therefore, there is no need to
   provide mechanisms to allow a responder to operate statelessly at the
   MP_JOIN stage.

   An HMAC is sent by both hosts -- by the initiator (Host A) in the
   third packet (the ACK) and by the responder (Host B) in the second
   packet (the SYN/ACK).  Doing the HMAC exchange at this stage allows
   both hosts to have first exchanged random data (in the first two SYN
   packets) that is used as the "message".  This specification defines
   that HMAC as defined in [10] is used, along with the SHA-1 hash
   algorithm [4] (potentially implemented as in [15]), thus generating a
   160-bit / 20-octet HMAC.  Due to option space limitations, the HMAC
   included in the SYN/ACK is truncated to the leftmost 64 bits, but
   this is acceptable since random numbers are used; thus, an attacker
   only has one chance to guess the HMAC correctly (if the HMAC is
   incorrect, the TCP connection is closed, so a new MP_JOIN negotiation
   with a new random number is required).

   The initiator's authentication information is sent in its first ACK
   (the third packet of the handshake), as shown in Figure 7.  This data
   needs to be sent reliably, since it is the only time this HMAC is
   sent; therefore, receipt of this packet MUST trigger a regular TCP
   ACK in response, and the packet MUST be retransmitted if this ACK is
   not received.  In other words, sending the ACK/MP_JOIN packet places
   the subflow in the PRE_ESTABLISHED state, and it moves to the

Top      Up      ToC       Page 21 
   ESTABLISHED state only on receipt of an ACK from the receiver.  It is
   not permitted to send data while in the PRE_ESTABLISHED state.  The
   reserved bits in this option MUST be set to zero by the sender.

   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 in the original MP_CAPABLE handshake.  The "message"
   for the HMAC algorithm in each case is the concatenations of random
   number for each host (denoted by R): for Host A, R-A followed by R-B;
   and for Host B, R-B followed by R-A.

                           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
      +---------------+---------------+-------+-----+-+---------------+
      |     Kind      |  Length = 16  |Subtype|     |B|   Address ID  |
      +---------------+---------------+-------+-----+-+---------------+
      |                                                               |
      |                Sender's Truncated HMAC (64 bits)              |
      |                                                               |
      +---------------------------------------------------------------+
      |                Sender's Random Number (32 bits)               |
      +---------------------------------------------------------------+

    Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)


                           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
      +---------------+---------------+-------+-----------------------+
      |     Kind      |  Length = 24  |Subtype|      (reserved)       |
      +---------------+---------------+-------+-----------------------+
      |                                                               |
      |                                                               |
      |                   Sender's HMAC (160 bits)                    |
      |                                                               |
      |                                                               |
      +---------------------------------------------------------------+

        Figure 7: Join Connection (MP_JOIN) Option (for Third ACK)

   These various TCP options fit together to enable authenticated
   subflow setup as illustrated in Figure 8.

Top      Up      ToC       Page 22 
              Host A                                  Host B
     ------------------------                       ----------
     Address A1    Address A2                       Address B1
     ----------    ----------                       ----------
         |             |                                |
         |            SYN + MP_CAPABLE(Key-A)           |
         |--------------------------------------------->|
         |<---------------------------------------------|
         |          SYN/ACK + MP_CAPABLE(Key-B)         |
         |             |                                |
         |        ACK + MP_CAPABLE(Key-A, Key-B)        |
         |--------------------------------------------->|
         |             |                                |
         |             |   SYN + MP_JOIN(Token-B, R-A)  |
         |             |------------------------------->|
         |             |<-------------------------------|
         |             | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
         |             |                                |
         |             |     ACK + MP_JOIN(HMAC-A)      |
         |             |------------------------------->|
         |             |<-------------------------------|
         |             |             ACK                |

   HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B))
   HMAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))

               Figure 8: Example Use of MPTCP Authentication

   If the token received at Host B is unknown or local policy prohibits
   the acceptance of the new subflow, the recipient MUST respond with a
   TCP RST for the subflow.

   If the token is accepted at Host B, but the HMAC returned to Host A
   does not match the one expected, Host A MUST close the subflow with a
   TCP RST.

   If Host B does not receive the expected HMAC, or the MP_JOIN option
   is missing from the ACK, it MUST close the subflow with a TCP RST.

   If the HMACs are verified as correct, then both hosts have
   authenticated each other as being the same peers as existed at the
   start of the connection, and they have agreed of which connection
   this subflow will become a part.

   If the SYN/ACK as received at Host A does not have an MP_JOIN option,
   Host A MUST close the subflow with a RST.

Top      Up      ToC       Page 23 
   This covers all cases of the loss of an MP_JOIN.  In more detail, if
   MP_JOIN is stripped from the SYN on the path from A to B, and Host B
   does not have a passive opener on the relevant port, it will respond
   with a RST in the normal way.  If in response to a SYN with an
   MP_JOIN option, a SYN/ACK is received without the MP_JOIN option
   (either since it was stripped on the return path, or it was stripped
   on the outgoing path but the passive opener on Host B responded as if
   it were a new regular TCP session), then the subflow is unusable and
   Host A MUST close it with a RST.

   Note that additional subflows can be created between any pair of
   ports (but see Section 3.8 for heuristics); no explicit application-
   level accept calls or bind calls are required to open additional
   subflows.  To associate a new subflow with an existing connection,
   the token supplied in the subflow's SYN exchange is used for
   demultiplexing.  This then binds the 5-tuple of the TCP subflow to
   the local token of the connection.  A consequence is that it is
   possible to allow any port pairs to be used for a connection.

   Demultiplexing subflow SYNs MUST be done using the token; this is
   unlike traditional TCP, where the destination port is used for
   demultiplexing SYN packets.  Once a subflow is set up, demultiplexing
   packets is done using the 5-tuple, as in traditional TCP.  The
   5-tuples will be mapped to the local connection identifier (token).
   Note that Host A will know its local token for the subflow even
   though it is not sent on the wire -- only the responder's token is
   sent.

3.3.  General MPTCP Operation

   This section discusses operation of MPTCP for data transfer.  At a
   high level, an MPTCP implementation will take one input data stream
   from an application, and split it into one or more subflows, with
   sufficient control information to allow it to be reassembled and
   delivered reliably and in order to the recipient application.  The
   following subsections define this behavior in detail.

   The data sequence mapping and the Data ACK are signaled in the Data
   Sequence Signal (DSS) option (Figure 9).  Either or both can be
   signaled in one DSS, dependent on the flags set.  The data sequence
   mapping defines how the sequence space on the subflow maps to the
   connection level, and the Data ACK acknowledges receipt of data at
   the connection level.  These functions are described in more detail
   in the following two subsections.

   Either or both the data sequence mapping and the Data ACK can be
   signaled in the DSS option, dependent on the flags set.

Top      Up      ToC       Page 24 
                          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
     +---------------+---------------+-------+----------------------+
     |     Kind      |    Length     |Subtype| (reserved) |F|m|M|a|A|
     +---------------+---------------+-------+----------------------+
     |           Data ACK (4 or 8 octets, depending on flags)       |
     +--------------------------------------------------------------+
     |   Data sequence number (4 or 8 octets, depending on flags)   |
     +--------------------------------------------------------------+
     |              Subflow Sequence Number (4 octets)              |
     +-------------------------------+------------------------------+
     |  Data-Level Length (2 octets) |      Checksum (2 octets)     |
     +-------------------------------+------------------------------+

                Figure 9: Data Sequence Signal (DSS) Option

   The flags, when set, define the contents of this option, as follows:

   o  A = Data ACK present

   o  a = Data ACK is 8 octets (if not set, Data ACK is 4 octets)

   o  M = Data Sequence Number (DSN), Subflow Sequence Number (SSN),
      Data-Level Length, and Checksum present

   o  m = Data sequence number is 8 octets (if not set, DSN is 4 octets)

   The flags 'a' and 'm' only have meaning if the corresponding 'A' or
   'M' flags are set; otherwise, they will be ignored.  The maximum
   length of this option, with all flags set, is 28 octets.

   The 'F' flag indicates "DATA_FIN".  If present, this means that this
   mapping covers the final data from the sender.  This is the
   connection-level equivalent to the FIN flag in single-path TCP.  A
   connection is not closed unless there has been a DATA_FIN exchange or
   a timeout.  The purpose of the DATA_FIN and the interactions between
   this flag, the subflow-level FIN flag, and the data sequence mapping
   are described in Section 3.3.3.  The remaining reserved bits MUST be
   set to zero by an implementation of this specification.

   Note that the checksum is only present in this option if the use of
   MPTCP checksumming has been negotiated at the MP_CAPABLE handshake
   (see Section 3.1).  The presence of the checksum can be inferred from
   the length of the option.  If a checksum is present, but its use had
   not been negotiated in the MP_CAPABLE handshake, the checksum field
   MUST be ignored.  If a checksum is not present when its use has been
   negotiated, the receiver MUST close the subflow with a RST as it is
   considered broken.

Top      Up      ToC       Page 25 
3.3.1.  Data Sequence Mapping

   The data stream as a whole can be reassembled through the use of the
   data sequence mapping components of the DSS option (Figure 9), which
   define the mapping from the subflow sequence number to the data
   sequence number.  This is used by the receiver to ensure in-order
   delivery to the application layer.  Meanwhile, the subflow-level
   sequence numbers (i.e., the regular sequence numbers in the TCP
   header) have subflow-only relevance.  It is expected (but not
   mandated) that SACK [11] is used at the subflow level to improve
   efficiency.

   The data sequence mapping specifies a mapping from subflow sequence
   space to data sequence space.  This is expressed in terms of starting
   sequence numbers for the subflow and the data level, and a length of
   bytes for which this mapping is valid.  This explicit mapping for a
   range of data was chosen rather than per-packet signaling to assist
   with compatibility with situations where TCP/IP segmentation or
   coalescing is undertaken separately from the stack that is generating
   the data flow (e.g., through the use of TCP segmentation offloading
   on network interface cards, or by middleboxes such as performance
   enhancing proxies).  It also allows a single mapping to cover many
   packets, which may be useful in bulk transfer situations.

   A mapping is fixed, in that the subflow sequence number is bound to
   the data sequence number after the mapping has been processed.  A
   sender MUST NOT change this mapping after it has been declared;
   however, the same data sequence number can be mapped to by different
   subflows for retransmission purposes (see Section 3.3.6).  This would
   also permit the same data to be sent simultaneously on multiple
   subflows for resilience or efficiency purposes, especially in the
   case of lossy links.  Although the detailed specification of such
   operation is outside the scope of this document, an implementation
   SHOULD treat the first data that is received at a subflow for the
   data sequence space as that which should be delivered to the
   application, and any later data for that sequence space ignored.

   The data sequence number is specified as an absolute value, whereas
   the subflow sequence numbering is relative (the SYN at the start of
   the subflow has relative subflow sequence number 0).  This is to
   allow middleboxes to change the initial sequence number of a subflow,
   such as firewalls that undertake ISN randomization.

   The data sequence mapping also contains a checksum of the data that
   this mapping covers, if use of checksums has been negotiated at the
   MP_CAPABLE exchange.  Checksums are used to detect if the payload has
   been adjusted in any way by a non-MPTCP-aware middlebox.  If this
   checksum fails, it will trigger a failure of the subflow, or a

Top      Up      ToC       Page 26 
   fallback to regular TCP, as documented in Section 3.6, since MPTCP
   can no longer reliably know the subflow sequence space at the
   receiver to build data sequence mappings.

   The checksum algorithm used is the standard TCP checksum [1],
   operating over the data covered by this mapping, along with a pseudo-
   header as shown in Figure 10.

                          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
     +--------------------------------------------------------------+
     |                                                              |
     |                Data Sequence Number (8 octets)               |
     |                                                              |
     +--------------------------------------------------------------+
     |              Subflow Sequence Number (4 octets)              |
     +-------------------------------+------------------------------+
     |  Data-Level Length (2 octets) |        Zeros (2 octets)      |
     +-------------------------------+------------------------------+

                 Figure 10: Pseudo-Header for DSS Checksum

   Note that the data sequence number used in the pseudo-header is
   always the 64-bit value, irrespective of what length is used in the
   DSS option itself.  The standard TCP checksum algorithm has been
   chosen since it will be calculated anyway for the TCP subflow, and if
   calculated first over the data before adding the pseudo-headers, it
   only needs to be calculated once.  Furthermore, since the TCP
   checksum is additive, the checksum for a DSN_MAP can be constructed
   by simply adding together the checksums for the data of each
   constituent TCP segment, and adding the checksum for the DSS pseudo-
   header.

   Note that checksumming relies on the TCP subflow containing
   contiguous data; therefore, a TCP subflow MUST NOT use the Urgent
   Pointer to interrupt an existing mapping.  Further note, however,
   that if Urgent data is received on a subflow, it SHOULD be mapped to
   the data sequence space and delivered to the application analogous to
   Urgent data in regular TCP.

   To avoid possible deadlock scenarios, subflow-level processing should
   be undertaken separately from that at connection level.  Therefore,
   even if a mapping does not exist from the subflow space to the data-
   level space, the data SHOULD still be ACKed at the subflow (if it is
   in-window).  This data cannot, however, be acknowledged at the data
   level (Section 3.3.2) because its data sequence numbers are unknown.
   Implementations MAY hold onto such unmapped data for a short while in
   the expectation that a mapping will arrive shortly.  Such unmapped

Top      Up      ToC       Page 27 
   data cannot be counted as being within the connection level receive
   window because this is relative to the data sequence numbers, so if
   the receiver runs out of memory to hold this data, it will have to be
   discarded.  If a mapping for that subflow-level sequence space does
   not arrive within a receive window of data, that subflow SHOULD be
   treated as broken, closed with a RST, and any unmapped data silently
   discarded.

   Data sequence numbers are always 64-bit quantities, and MUST be
   maintained as such in implementations.  If a connection is
   progressing at a slow rate, so protection against wrapped sequence
   numbers is not required, then it is permissible to include just the
   lower 32 bits of the data sequence number in the data sequence
   mapping and/or Data ACK as an optimization, and an implementation can
   make this choice independently for each packet.

   An implementation MUST send the full 64-bit data sequence number if
   it is transmitting at a sufficiently high rate that the 32-bit value
   could wrap within the Maximum Segment Lifetime (MSL) [16].  The
   lengths of the DSNs used in these values (which may be different) are
   declared with flags in the DSS option.  Implementations MUST accept a
   32-bit DSN and implicitly promote it to a 64-bit quantity by
   incrementing the upper 32 bits of sequence number each time the lower
   32 bits wrap.  A sanity check MUST be implemented to ensure that a
   wrap occurs at an expected time (e.g., the sequence number jumps from
   a very high number to a very low number) and is not triggered by out-
   of-order packets.

   As with the standard TCP sequence number, the data sequence number
   should not start at zero, but at a random value to make blind session
   hijacking harder.  This specification requires setting the initial
   data sequence number (IDSN) of each host to the least significant 64
   bits of the SHA-1 hash of the host's key, as described in
   Section 3.1.

   A data sequence mapping does not need to be included in every MPTCP
   packet, as long as the subflow sequence space in that packet is
   covered by a mapping known at the receiver.  This can be used to
   reduce overhead in cases where the mapping is known in advance; one
   such case is when there is a single subflow between the hosts,
   another is when segments of data are scheduled in larger than packet-
   sized chunks.

   An "infinite" mapping can be used to fall back to regular TCP by
   mapping the subflow-level data to the connection-level data for the
   remainder of the connection (see Section 3.6).  This is achieved by
   setting the Data-Level Length field of the DSS option to the reserved
   value of 0.  The checksum, in such a case, will also be set to zero.

Top      Up      ToC       Page 28 
3.3.2.  Data Acknowledgments

   To provide full end-to-end resilience, MPTCP provides a connection-
   level acknowledgment, to act as a cumulative ACK for the connection
   as a whole.  This is the "Data ACK" field of the DSS option
   (Figure 9).  The Data ACK is analogous to the behavior of the
   standard TCP cumulative ACK -- indicating how much data has been
   successfully received (with no holes).  This is in comparison to the
   subflow-level ACK, which acts analogous to TCP SACK, given that there
   may still be holes in the data stream at the connection level.  The
   Data ACK specifies the next data sequence number it expects to
   receive.

   The Data ACK, as for the DSN, can be sent as the full 64-bit value,
   or as the lower 32 bits.  If data is received with a 64-bit DSN, it
   MUST be acknowledged with a 64-bit Data ACK.  If the DSN received is
   32 bits, it is valid for the implementation to choose whether to send
   a 32-bit or 64-bit Data ACK.

   The Data ACK proves that the data, and all required MPTCP signaling,
   has been received and accepted by the remote end.  One key use of the
   Data ACK signal is that it is used to indicate the left edge of the
   advertised receive window.  As explained in Section 3.3.4, the
   receive window is shared by all subflows and is relative to the Data
   ACK.  Because of this, an implementation MUST NOT use the RCV.WND
   field of a TCP segment at the connection level if it does not also
   carry a DSS option with a Data ACK field.  Furthermore, separating
   the connection-level acknowledgments from the subflow level allows
   processing to be done separately, and a receiver has the freedom to
   drop segments after acknowledgment at the subflow level, for example,
   due to memory constraints when many segments arrive out of order.

   An MPTCP sender MUST NOT free data from the send buffer until it has
   been acknowledged by both a Data ACK received on any subflow and at
   the subflow level by all subflows on which the data was sent.  The
   former condition ensures liveness of the connection and the latter
   condition ensures liveness and self-consistence of a subflow when
   data needs to be retransmitted.  Note, however, that if some data
   needs to be retransmitted multiple times over a subflow, there is a
   risk of blocking the sending window.  In this case, the MPTCP sender
   can decide to terminate the subflow that is behaving badly by sending
   a RST.

   The Data ACK MAY be included in all segments; however, optimizations
   SHOULD be considered in more advanced implementations, where the Data
   ACK is present in segments only when the Data ACK value advances, and

Top      Up      ToC       Page 29 
   this behavior MUST be treated as valid.  This behavior ensures the
   sender buffer is freed, while reducing overhead when the data
   transfer is unidirectional.

3.3.3.  Closing a Connection

   In regular TCP, a FIN announces the receiver that the sender has no
   more data to send.  In order to allow subflows to operate
   independently and to keep the appearance of TCP over the wire, a FIN
   in MPTCP only affects the subflow on which it is sent.  This allows
   nodes to exercise considerable freedom over which paths are in use at
   any one time.  The semantics of a FIN remain as for regular TCP;
   i.e., it is not until both sides have ACKed each other's FINs that
   the subflow is fully closed.

   When an application calls close() on a socket, this indicates that it
   has no more data to send; for regular TCP, this would result in a FIN
   on the connection.  For MPTCP, an equivalent mechanism is needed, and
   this is referred to as the DATA_FIN.

   A DATA_FIN is an indication that the sender has no more data to send,
   and as such can be used to verify that all data has been successfully
   received.  A DATA_FIN, as with the FIN on a regular TCP connection,
   is a unidirectional signal.

   The DATA_FIN is signaled by setting the 'F' flag in the Data Sequence
   Signal option (Figure 9) to 1.  A DATA_FIN occupies 1 octet (the
   final octet) of the connection-level sequence space.  Note that the
   DATA_FIN is included in the Data-Level Length, but not at the subflow
   level: for example, a segment with DSN 80, and Data-Level Length 11,
   with DATA_FIN set, would map 10 octets from the subflow into data
   sequence space 80-89, the DATA_FIN is DSN 90; therefore, this segment
   including DATA_FIN would be acknowledged with a DATA_ACK of 91.

   Note that when the DATA_FIN is not attached to a TCP segment
   containing data, the Data Sequence Signal MUST have a subflow
   sequence number of 0, a Data-Level Length of 1, and the data sequence
   number that corresponds with the DATA_FIN itself.  The checksum in
   this case will only cover the pseudo-header.

   A DATA_FIN has the semantics and behavior as a regular TCP FIN, but
   at the connection level.  Notably, it is only DATA_ACKed once all
   data has been successfully received at the connection level.  Note,
   therefore, that a DATA_FIN is decoupled from a subflow FIN.  It is
   only permissible to combine these signals on one subflow if there is
   no data outstanding on other subflows.  Otherwise, it may be
   necessary to retransmit data on different subflows.  Essentially, a
   host MUST NOT close all functioning subflows unless it is safe to do

Top      Up      ToC       Page 30 
   so, i.e., until all outstanding data has been DATA_ACKed, or until
   the segment with the DATA_FIN flag set is the only outstanding
   segment.

   Once a DATA_FIN has been acknowledged, all remaining subflows MUST be
   closed with standard FIN exchanges.  Both hosts SHOULD send FINs on
   all subflows, as a courtesy to allow middleboxes to clean up state
   even if an individual subflow has failed.  It is also encouraged to
   reduce the timeouts (Maximum Segment Life) on subflows at end hosts.
   In particular, any subflows where there is still outstanding data
   queued (which has been retransmitted on other subflows in order to
   get the DATA_FIN acknowledged) MAY be closed with a RST.

   A connection is considered closed once both hosts' DATA_FINs have
   been acknowledged by DATA_ACKs.

   As specified above, a standard TCP FIN on an individual subflow only
   shuts down the subflow on which it was sent.  If all subflows have
   been closed with a FIN exchange, but no DATA_FIN has been received
   and acknowledged, the MPTCP connection is treated as closed only
   after a timeout.  This implies that an implementation will have
   TIME_WAIT states at both the subflow and connection levels (see
   Appendix C).  This permits "break-before-make" scenarios where
   connectivity is lost on all subflows before a new one can be re-
   established.

3.3.4.  Receiver Considerations

   Regular TCP advertises a receive window in each packet, telling the
   sender how much data the receiver is willing to accept past the
   cumulative ack.  The receive window is used to implement flow
   control, throttling down fast senders when receivers cannot keep up.

   MPTCP also uses a unique receive window, shared between the subflows.
   The idea is to allow any subflow to send data as long as the receiver
   is willing to accept it.  The alternative, maintaining per subflow
   receive windows, could end up stalling some subflows while others
   would not use up their window.

   The receive window is relative to the DATA_ACK.  As in TCP, a
   receiver MUST NOT shrink the right edge of the receive window (i.e.,
   DATA_ACK + receive window).  The receiver will use the data sequence
   number to tell if a packet should be accepted at the connection
   level.

   When deciding to accept packets at subflow level, regular TCP checks
   the sequence number in the packet against the allowed receive window.
   With multipath, such a check is done using only the connection-level

Top      Up      ToC       Page 31 
   window.  A sanity check SHOULD be performed at subflow level to
   ensure that the subflow and mapped sequence numbers meet the
   following test: SSN - SUBFLOW_ACK <= DSN - DATA_ACK, where SSN is the
   subflow sequence number of the received packet and SUBFLOW_ACK is the
   RCV.NXT (next expected sequence number) of the subflow (with the
   equivalent connection-level definitions for DSN and DATA_ACK).

   In regular TCP, once a segment is deemed in-window, it is put either
   in the in-order receive queue or in the out-of-order queue.  In
   Multipath TCP, the same happens but at the connection level: a
   segment is placed in the connection level in-order or out-of-order
   queue if it is in-window at both connection and subflow levels.  The
   stack still has to remember, for each subflow, which segments were
   received successfully so that it can ACK them at subflow level
   appropriately.  Typically, this will be implemented by keeping per
   subflow out-of-order queues (containing only message headers, not the
   payloads) and remembering the value of the cumulative ACK.

   It is important for implementers to understand how large a receiver
   buffer is appropriate.  The lower bound for full network utilization
   is the maximum bandwidth-delay product of any one of the paths.
   However, this might be insufficient when a packet is lost on a slower
   subflow and needs to be retransmitted (see Section 3.3.6).  A tight
   upper bound would be the maximum round-trip time (RTT) of any path
   multiplied by the total bandwidth available across all paths.  This
   permits all subflows to continue at full speed while a packet is
   fast-retransmitted on the maximum RTT path.  Even this might be
   insufficient to maintain full performance in the event of a
   retransmit timeout on the maximum RTT path.  It is for future study
   to determine the relationship between retransmission strategies and
   receive buffer sizing.

3.3.5.  Sender Considerations

   The sender remembers receiver window advertisements from the
   receiver.  It should only update its local receive window values when
   the largest sequence number allowed (i.e., DATA_ACK + receive window)
   increases, on the receipt of a DATA_ACK.  This is important to allow
   using paths with different RTTs, and thus different feedback loops.

   MPTCP uses a single receive window across all subflows, and if the
   receive window was guaranteed to be unchanged end-to-end, a host
   could always read the most recent receive window value.  However,
   some classes of middleboxes may alter the TCP-level receive window.
   Typically, these will shrink the offered window, although for short
   periods of time it may be possible for the window to be larger
   (however, note that this would not continue for long periods since
   ultimately the middlebox must keep up with delivering data to the

Top      Up      ToC       Page 32 
   receiver).  Therefore, if receive window sizes differ on multiple
   subflows, when sending data MPTCP SHOULD take the largest of the most
   recent window sizes as the one to use in calculations.  This rule is
   implicit in the requirement not to reduce the right edge of the
   window.

   The sender MUST also remember the receive windows advertised by each
   subflow.  The allowed window for subflow i is (ack_i, ack_i +
   rcv_wnd_i), where ack_i is the subflow-level cumulative ACK of
   subflow i.  This ensures data will not be sent to a middlebox unless
   there is enough buffering for the data.

   Putting the two rules together, we get the following: a sender is
   allowed to send data segments with data-level sequence numbers
   between (DATA_ACK, DATA_ACK + receive_window).  Each of these
   segments will be mapped onto subflows, as long as subflow sequence
   numbers are in the allowed windows for those subflows.  Note that
   subflow sequence numbers do not generally affect flow control if the
   same receive window is advertised across all subflows.  They will
   perform flow control for those subflows with a smaller advertised
   receive window.

   The send buffer MUST, at a minimum, be as big as the receive buffer,
   to enable the sender to reach maximum throughput.

3.3.6.  Reliability and Retransmissions

   The data sequence mapping allows senders to resend data with the same
   data sequence number on a different subflow.  When doing this, a host
   MUST still retransmit the original data on the original subflow, in
   order to preserve the subflow integrity (middleboxes could replay old
   data, and/or could reject holes in subflows), and a receiver will
   ignore these retransmissions.  While this is clearly suboptimal, for
   compatibility reasons this is sensible behavior.  Optimizations could
   be negotiated in future versions of this protocol.

   This protocol specification does not mandate any mechanisms for
   handling retransmissions, and much will be dependent upon local
   policy (as discussed in Section 3.3.8).  One can imagine aggressive
   connection-level retransmissions policies where every packet lost at
   subflow level is retransmitted on a different subflow (hence, wasting
   bandwidth but possibly reducing application-to-application delays),
   or conservative retransmission policies where connection-level
   retransmits are only used after a few subflow-level retransmission
   timeouts occur.

Top      Up      ToC       Page 33 
   It is envisaged that a standard connection-level retransmission
   mechanism would be implemented around a connection-level data queue:
   all segments that haven't been DATA_ACKed are stored.  A timer is set
   when the head of the connection-level is ACKed at subflow level but
   its corresponding data is not ACKed at data level.  This timer will
   guard against failures in retransmission by middleboxes that
   proactively ACK data.

   The sender MUST keep data in its send buffer as long as the data has
   not been acknowledged at both connection level and on all subflows on
   which it has been sent.  In this way, the sender can always
   retransmit the data if needed, on the same subflow or on a different
   one.  A special case is when a subflow fails: the sender will
   typically resend the data on other working subflows after a timeout,
   and will keep trying to retransmit the data on the failed subflow
   too.  The sender will declare the subflow failed after a predefined
   upper bound on retransmissions is reached (which MAY be lower than
   the usual TCP limits of the Maximum Segment Life), or on the receipt
   of an ICMP error, and only then delete the outstanding data segments.

   Multiple retransmissions are triggers that will indicate that a
   subflow performs badly and could lead to a host resetting the subflow
   with a RST.  However, additional research is required to understand
   the heuristics of how and when to reset underperforming subflows.
   For example, a highly asymmetric path may be misdiagnosed as
   underperforming.

3.3.7.  Congestion Control Considerations

   Different subflows in an MPTCP connection have different congestion
   windows.  To achieve fairness at bottlenecks and resource pooling, it
   is necessary to couple the congestion windows in use on each subflow,
   in order to push most traffic to uncongested links.  One algorithm
   for achieving this is presented in [5]; the algorithm does not
   achieve perfect resource pooling but is "safe" in that it is readily
   deployable in the current Internet.  By this, we mean that it does
   not take up more capacity on any one path than if it was a single
   path flow using only that route, so this ensures fair coexistence
   with single-path TCP at shared bottlenecks.

   It is foreseeable that different congestion controllers will be
   implemented for MPTCP, each aiming to achieve different properties in
   the resource pooling/fairness/stability design space, as well as
   those for achieving different properties in quality of service,
   reliability, and resilience.

Top      Up      ToC       Page 34 
   Regardless of the algorithm used, the design of the MPTCP protocol
   aims to provide the congestion control implementations sufficient
   information to take the right decisions; this information includes,
   for each subflow, which packets were lost and when.

3.3.8.  Subflow Policy

   Within a local MPTCP implementation, a host may use any local policy
   it wishes to decide how to share the traffic to be sent over the
   available paths.

   In the typical use case, where the goal is to maximize throughput,
   all available paths will be used simultaneously for data transfer,
   using coupled congestion control as described in [5].  It is
   expected, however, that other use cases will appear.

   For instance, a possibility is an 'all-or-nothing' approach, i.e.,
   have a second path ready for use in the event of failure of the first
   path, but alternatives could include entirely saturating one path
   before using an additional path (the 'overflow' case).  Such choices
   would be most likely based on the monetary cost of links, but may
   also be based on properties such as the delay or jitter of links,
   where stability (of delay or bandwidth) is more important than
   throughput.  Application requirements such as these are discussed in
   detail in [6].

   The ability to make effective choices at the sender requires full
   knowledge of the path "cost", which is unlikely to be the case.  It
   would be desirable for a receiver to be able to signal their own
   preferences for paths, since they will often be the multihomed party,
   and may have to pay for metered incoming bandwidth.

   Whilst fine-grained control may be the most powerful solution, that
   would require some mechanism such as overloading the Explicit
   Congestion Notification (ECN) signal [17], which is undesirable, and
   it is felt that there would not be sufficient benefit to justify an
   entirely new signal.  Therefore, the MP_JOIN option (see Section 3.2)
   contains the 'B' bit, which allows a host to indicate to its peer
   that this path should be treated as a backup path to use only in the
   event of failure of other working subflows (i.e., a subflow where the
   receiver has indicated B=1 SHOULD NOT be used to send data unless
   there are no usable subflows where B=0).

   In the event that the available set of paths changes, a host may wish
   to signal a change in priority of subflows to the peer (e.g., a
   subflow that was previously set as backup should now take priority

Top      Up      ToC       Page 35 
   over all remaining subflows).  Therefore, the MP_PRIO option, shown
   in Figure 11, can be used to change the 'B' flag of the subflow on
   which it is sent.

                           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
      +---------------+---------------+-------+-----+-+--------------+
      |     Kind      |     Length    |Subtype|     |B| AddrID (opt) |
      +---------------+---------------+-------+-----+-+--------------+

            Figure 11: Change Subflow Priority (MP_PRIO) Option

   It should be noted that the backup flag is a request from a data
   receiver to a data sender only, and the data sender SHOULD adhere to
   these requests.  A host cannot assume that the data sender will do
   so, however, since local policies -- or technical difficulties -- may
   override MP_PRIO requests.  Note also that this signal applies to a
   single direction, and so the sender of this option could choose to
   continue using the subflow to send data even if it has signaled B=1
   to the other host.

   This option can also be applied to other subflows than the one on
   which it is sent, by setting the optional Address ID field.  This
   applies the given setting of B to all subflows in this connection
   that use the address identified by the given Address ID.  The
   presence of this field is determined by the option length; if
   Length==4 then it is present.  If Length==3, then it applies to the
   current subflow only.  The use case of this is that a host can signal
   to its peer that an address is temporarily unavailable (for example,
   if it has radio coverage issues) and the peer should therefore drop
   to backup state on all subflows using that Address ID.



(page 35 continued on part 3)

Next RFC Part