Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Multipath Message Transport Protocol Based on Application-level Relay (MPMTP-AR)
draft-leiwm-tsvwg-mpmtp-ar-00

Versions:

The information below is for an old version of the document.

Document	Type	This is an older version of an Internet-Draft whose latest revision state is "Expired".
	Authors	Lei Weimin , Shaowei Liu , Wei Zhang
	Last updated	2013-07-29
	RFC stream	(None)
	Formats	txt htmlized pdf bibtex bibxml
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Search email archive

draft-leiwm-tsvwg-mpmtp-ar-00

Network Working Group W. Lei
Internet-Draft S. Liu
Intended status: Experimental W. Zhang
Expires: January 28, 2014 Northeastern University
July 29, 2013

Multipath Message Transport Protocol Based on
Application-level Relay (MPMTP-AR)
draft-leiwm-tsvwg-mpmtp-ar-00.txt

Abstract

Multipath transmission is an important way to improve the quality of
service for message transport. This document defines a multipath
message transmission protocol under the framework of Multipath
Transport System Based on Application-level Relay (MPTS-AR). This
protocol follows OpenPath and MPTP Profile defined in MPTS-AR. Apart
from behaviors of user agent defined in MPTS-AR, user agent should be
also responsible for message reliable transmission,including
connective session establishment, sequenced deliver,select
acknowledgement, retransmission, recombination and congestion
avoidance, etc. This document describes those new or changed
behaviors, and expands the MPTP format to meet them.Moreover this
document illustrates the details of multipath transmission mechanism
reference to the reliable transmission characteristics.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 28, 2014 .

Leiwm, et al. Expires January 28, 2014 [Page 1]
Internet-Draft MPMTP-AR July 2013

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document. Code
Components extracted from this document must include Simplified
BSD License text as described in section 4.e of the Trust Legal
Provisions and are provided without warranty as described in the
Simplified BSD License.

Leiwm, et al. Expires January 28, 2014 [Page 2]
Internet-Draft MPMTP-AR July 2013

Table of Contents

1. Introduction ................................................ 6
2. Terminology ................................................. 7
3. Definition .................................................. 7
4. Goals ....................................................... 9
5. Overview .................................................... 9
6. Usage Scenarios ............................................. 11
7. MPMTP-AR Agent Behavior ..................................... 11
7.1 Consistent Behaviors ................................... 12
7.1.1 Path management ................................. 12
7.2 Modified Behaviors ..................................... 12
7.2.1 Subflow recombination ........................... 12
7.3 Additional Behaviors ................................... 12
7.3.1 Session management .............................. 12
7.3.2 Flow partitioning and scheduling ................ 13
7.3.3 Subflow packaging ............................... 13
7.3.4 Subflow reporting ............................... 14
7.4 New Behaviors .......................................... 14
7.4.1 Sequenced Delivery .............................. 14
7.4.2 Acknowledgement and Congestion Avoidance ........ 15
8. MPMTP-AR Packet Format: MPTP Format Extension ............... 16
8.1 Overview ............................................... 16
8.2 MPMTP-AR Header ........................................ 16
8.3 MPMTP-AR Data Chunk Definition ......................... 17
8.4 MPMTP-AR Control Chunk Definition ...................... 19
8.4.1 Sender Report (SR) .............................. 20
8.4.2 Receiver Report (RR) ............................ 21
8.4.3 Keep Alive (KA) ................................. 22
8.4.4 Session Initiation (SINIT) ...................... 22
8.4.5 Session Initiation Acknowledgement (SINIT ACK) .. 24
8.4.6 State Cookie (COOKIE ECHO) ...................... 25
8.4.7 Cookie Acknowledgement (COOKIE ACK) ............. 26
8.4.8 Subflow INIT Request (SubINIT) .................. 26
8.4.9 Subflow INIT Acknowledgement (SubINIT ACK) ...... 26
8.4.10 Selective Acknowledgement (SACK) ................ 26
8.4.11 Subflow Shutdown (SubSHUTDOWN) .................. 29
8.4.12 Subflow Shutdown Acknowledgement
(SubSHUTDOWN ACK) ............................... 30
8.4.13 Session Shutdown (SSHUTDOWN) .................... 30
8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK). 30
8.4.15 Session Shutdown Complete (SSHUTDOWN COMPLETE) .. 31
8.4.16 Abort (ABORT) ................................... 31
8.4.17 Operation Error (ERROR) ......................... 32
8.4.18 Path Feedback (PATH FEEDBACK) ................... 37
8.4.19 Path Probe (PATH PROBE) ......................... 38
9. MPMTP-AR Session State Diagram .............................. 39
10. Session Initialization ...................................... 42

Leiwm, et al. Expires January 28, 2014 [Page 3]
Internet-Draft MPMTP-AR July 2013

10.1 Normal Establishment of a Session ...................... 43
10.1.1 Handle Path Parameters .......................... 44
10.1.2 Generating State Cookie ......................... 44
10.1.3 State Cookie Processing ......................... 45
10.1.4 State Cookie Authentication ..................... 46
10.1.5 Open Subflow .................................... 46
10.2 Handle Duplication or Unexpected Issue ................. 47
10.2.1 Unexpected SINIT in States Other than CLOSED,
COOKIE-ECHOED, COOKIE-WAIT, and
SSHUTDOWN-ACK-SENT .............................. 47
10.2.2 Unexpected SINIT ACK ............................ 48
10.2.3 Handle a COOKIE ECHO when a TCB Exists .......... 48
10.2.4 Handle Duplicate COOKIE-ACK ..................... 49
10.2.5 Handle Stale COOKIE Error ....................... 49
10.3 Other Initialization Issues ............................ 49
10.3.1 Selection of Tag Value .......................... 49
11. User Data Transfer .......................................... 50
11.1 Transmission of DATA Chunks ............................ 51
11.2 Acknowledge on Reception of DATA Chunks ................ 53
11.2.1 Processing a Received SACK ...................... 55
11.3 Management of Retransmission Timer ..................... 57
11.3.1 RTO Calculation ................................. 57
11.3.2 Retransmission Timer Rules ...................... 58
11.3.3 Handle T3-RTX Expiration ........................ 59
11.4 Stream Identifier and Stream Sequence Number ........... 60
11.5 Ordered and Unordered Delivery ......................... 60
11.6 Report Gaps in Received DATA TSNs ...................... 61
11.7 Fragmentation and Reassembly ........................... 62
12. Congestion Control .......................................... 63
12.1 MPMTP-AR Differences from TCP Congestion Control ....... 63
12.2 MPMTP-AR Slow-Start and Congestion Avoidance ........... 64
12.2.1 Slow-Start ...................................... 65
12.2.2 Congestion Avoidance ............................ 66
12.2.3 Congestion Control .............................. 67
12.2.4 Fast Retransmit on Gap Reports .................. 67
12.3 Path MTU Discovery ..................................... 69
13. Fault Management ............................................ 69
13.1 Endpoint Failure Detection ............................. 69
13.2 Path Failure Detection ................................. 70
13.3 Handle "Out of the Blue" Packets ....................... 70
13.4 Verification Tag ....................................... 71
13.4.1 Exceptions in Verification Tag Rules ............ 72
14. Termination of Session ...................................... 73
14.1 Abort of a Session ..................................... 73
14.2 Shutdown of a Session .................................. 73
15. Security Consideration ...................................... 75
16. Reference ................................................... 75
16.1 Normal Reference ....................................... 75

Leiwm, et al. Expires January 28, 2014 [Page 4]
Internet-Draft MPMTP-AR July 2013

16.2 Information Reference .................................. 75

Leiwm, et al. Expires January 28, 2014 [Page 5]
Internet-Draft MPMTP-AR July 2013

1. Introduction

This document defines the Multipath Message Transport Protocol Based
on Application-Level Relay (MPMTP-AR) under the Framework of
Multipath Transport System Based on Application-Level Relay [1],
which provides end-to-end multipath transmission services with
reliable transmission characteristics.

As the Internet evolves, demands on Internet resources are
ever-increasing, but often these resources (in particular,
bandwidth) cannot be fully utilized due to protocol constraints both
on the end-systems and network resources. If these resources could
be used concurrently, network resource utilization and end user
experience could be greatly improved.

Although current protocols such as TCP, MPTCP and SCTP support
multipath or reliable transmission, a lot of applications show that
there are some limitations to them. The limitations that users have
wished to bypass include the following:

1) TCP supports both reliable data transfer and strict
order-of-transmission delivery of data. But it cannot provide
multipath transmission. It also refuses relay transport; otherwise
the transmission efficiency is very low.

2) MPTCP [4] provides multipath transmission service. At least one of
participates needs to be multi-homed. The transmission uses
multiple IP pairs (Source IP, Destination IP) simultaneously to
support multipath transmission. Transmission between each IP pair
is the same with TCP [6].This multi-homed requirement limits the
range of application.

3) SCTP has reliable transmission characteristic. Although SCTP
endpoints have several IP pairs, they just use one of them to
deliver message, the others are backup. It cannot support
multipath transmission.

All those limitations motivated the development of MPMTP-AR. MPMTP-AR
overcome those limitations by multipath delivery based on
application level relay, select acknowledgement and retransmission
mechanisms. Parts of mechanisms reference to SCTP [3].

MPMTP-AR aims to realize some of the goals of resource pooling by
simultaneously making use of multiple paths and reliable
transmission. The three key benefits of multipath transport are the
following:

1) To increase the efficiency of the resource usage, and thus
increase the network capacity available to agent.

Leiwm, et al. Expires January 28, 2014 [Page 6]
Internet-Draft MPMTP-AR July 2013

2) Increased Throughput: In some cases, the relay path, which is
assigned to a MPMTP-AR association according to the location of
participants and the current network status, has better transport
capacity than the default path between the endpoints. And
cumulative transport capacity of multiple paths may meet the
requirements of the high bit-rate message transmission better.

3) To increase the resilience of the connectivity by providing
multiple paths, protecting path from the failure of one.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC2119 [2].

3. Definition

1) Cumulative TSN Ack Point: The TSN of the last DATA chunk
acknowledged via the Cumulative TSN Ack field of a SACK.

2) Tie Tags: Two 32-bit random numbers that together make a 64-bit
nonce, including from tag and to tag. These tags are used to
identify a valid session which is unique in the whole network.

3) Message Authentication Code (MAC): An integrity check mechanism
based on cryptographic hash functions using a secret key.
Typically, message authentication codes are used between two
parties that share a secret key in order to validate information
transmitted between these parties. In MPMTP-AR, it is used by an
agent to validate the State Cookie information that is returned
from the peer in the COOKIE ECHO chunk. The term "MAC" has
different meanings in different contexts. MPMTP-AR uses this term
with the same meaning as in [7].

4) MPMTP-AR application (MPMTP-AR user): The logical higher-layer
application entity which uses the services of MPMTP-AR.

5) Ordered Message: A user message that is delivered in order with
respect to all previous user messages sent within the stream on
which the message was sent.

6) Outstanding TSN (at an MPMTP-AR agent): A TSN (and the associated
DATA chunk) that has been sent by the agent but for which it has
not yet received an acknowledgement.

7) Receiver Window (rwnd): An MPMTP-AR variable a data sender uses to
store the most recently calculated receiver window of its peer, in

Leiwm, et al. Expires January 28, 2014 [Page 7]
Internet-Draft MPMTP-AR July 2013

number of bytes. This gives the sender an indication of the space
available in the receiver's inbound buffer.

8) Slow-Start Threshold (ssthresh): An MPMTP-AR variable. This is the
threshold that the agent will use to determine whether to perform
slow start or congestion avoidance on a particular path. Ssthresh
is in number of bytes.

9) Stream: A logical channel between one MPMTP-AR agent to another
associated MPMTP-AR agent, within which user message is delivered
in sequence except for those submitted to the unordered delivery
service.

10)Stream Identification: A sequence number used internally by
MPMTP-AR to identify the stream to which the user data belongs.

11)Stream Sequence Number: A sequence number used internally by
MPMTP-AR to ensure sequenced delivery of the user messages within
a given stream. One Stream Sequence Number is attached to each
user message.

12)Transmission Control Block (TCB): An internal data structure
created by an MPMTP-AR agent for each of its existing MPMTP-AR
session to other MPMTP-AR endpoints. TCB contains all the status
and operational information for the agent to maintain and manage
the corresponding session.

13)Transmission Sequence Number (TSN): A 32-bit sequence number used
internally by MPMTP-AR. One TSN is attached to each chunk
containing user data to permit the receiving MPMTP-AR agent to
acknowledge its receipt and detect duplicate deliveries.

14)Unacknowledged TSN (at an MPMTP-AR agent): A TSN (and the
associated DATA chunk) that has been received by the agent but
for which an acknowledgement has not yet been sent. Or in the
opposite case, for a packet that has been sent but no
acknowledgement has been received.

15)Unordered Message: Unordered messages are "unordered" with
respect to any other message; this includes both other unordered
messages as well as other ordered messages. An unordered message
might be delivered prior to or later than ordered messages sent on
the same stream.

16)Session Tag: A 32-bit unsigned integer that is randomly generated.
The Verification Tag provides a key that allows a receiver to
verify that the MPMTP-AR packet belongs to the current session and
is not an old or stale packet from a previous session.

Leiwm, et al. Expires January 28, 2014 [Page 8]
Internet-Draft MPMTP-AR July 2013

4. Goals

Using MPTP extension for reliable transmission, original data
belonging to a session is divided multiple subflows and carried over
multiple paths. This may prove beneficial in case of reliable
transmission.

1) Improve Throughput: MPMTP-AR MUST support the concurrent use of
multiple paths. To meet the minimum performance incentives for
deployment, a MPMTP-AR connection over multiple paths SHOULD
achieve no worse throughput than regular default path connection
over the best constituent paths.

2) Improve Resilience: MPMTP-AR MUST support the use of multiple
paths interchangeably for resilience purposes, by permitting
packets to be sent and re-sent on any available path. It follows
that, in the worst case, the protocol MUST be no less resilient
than regular default path.

In order to guarantee reliable and order transmission, MPMTP-AR has
the following goals:

1) Load balancing: transmitting a message over multiple paths reduces
the bandwidth usage on a single path, which in turn reduces the
impact of the message stream on other traffic on that path and
then avoids congestion in network hot-spots. From the perspective
of the whole network, the network reliable and network utilization
can be significantly improved.

2) Acknowledgement and Retransmission: when the receiver receive data
chunks, it SHOULD indicate the sender about correctly received
data chunks by acknowledgement; if some data chunks with
transmission error, the sender MUST retransmit them by
retransmission mechanism.

5. Overview

Figure 1: Illustrates the structure of the proposed multipath
transmission framework based on application-level relay and the
relationship between user agent, relay and controller.

Application-level relay-based multipath transport framework core
defines three logical entities and two protocols which provide
interfaces between logical entities. Based on this framework, we
define additional MPTP format extension and user agent behaviors to
support reliable transmission.

Leiwm, et al. Expires January 28, 2014 [Page 9]
Internet-Draft MPMTP-AR July 2013

(1)Out-of-band Signaling +-----------------+ (1)
+--------------------->| Out-of-band |<------------------+
| | Signaling Server| |
| +-----------------+ |
| ^ |
| |(1)OpenPath |
| V |
| or (2) OpenPath +------------------+ |
| +----------------->| Relay Controller | |
| | +------------------+ |
| | ^ |
| | | |
V V | V
+------------+ |OpenPath +------------+
| User Agent | | | User Agent |
| (Sender) | | | (Receiver) |
+------------+ V +------------+
| ................................. ^
| . +-----------------+ . |
| . | Relay server | . |
| . +-----------------+ | . |
| . | Relay server |--+ . |
| . +-----------------+ | . |
+------------>. | Relay server |--+ .------------+
MPTP . | | . MPTP
. +-----------------+ .
.................................

Figure 1 : The structure of the proposed multipath transmission
framework based on application-level relay.

User agent, who is responsible for sending out data chunks, called
the sender, needs to collect candidate paths, and establish a
connective session before transmitting data. The framework defines
two ways to be used for collecting candidate paths by the sender.
Before using them, the sender performs connectivity checks on relay
paths to ascertain reachability. According to transmission
requirements of current session, the sender selects the default path
and one or more available relay paths as active paths to transmit
data to the receiver.

A multiple session may be setup from the beginning, or may be
upgraded from a default path. The connective session establishment
mechanism uses a four-way-handshake, the middle two legs of which
are allowed to carry authentication.

Then the sender distributes the original data across the active
paths based on a scheduling strategy and encapsulates them as

Leiwm, et al. Expires January 28, 2014 [Page 10]
Internet-Draft MPMTP-AR July 2013

special structure of MPTP packets before delivery. The receiver
combines the received subflows to recreate the original data flow.

The receiver sends selective acknowledgement of data chunk to the
sender.Then the sender will sends error data chunks immediately and
wait for out of stand chunks for a special timer. The retransmission
may choose a best performance subflow, or may be different from the
sublfow for which the chunk timer expired or eroded.

The session provides for graceful close on request from the MPMTP-AR
agents, and also allows ungraceful close either on request from the
MPMTP-AR agents or as a result of an error condition detected.

6. Usage Scenarios

MPMTP-AR can provide end-to-end message transmission application,
such as file transfer.

Figure 2 illustrates a end-to-end multipath session. There are three
paths between the sender and the receiver, including the default
path, one relay path via one relay and another relay path via two
relays. Applications running at the sender side can choose a data
partitioning method according to its particular requirements. Then,
each flow is assigned to a path. The receiver reassembles the
received data chunks using a re-order buffer to retrieve the
reconstructed flow which is delivered to the above application.

Relay path(A, Relay-1, B)
+-----------+
+-------------------->| Relay-1 |-----------------------+
| +-----------+ |
| V
+--------+ Default path(A,B) +--------+
| User A |<----------------------------------------------->| User B |
+--------+ +--------+
| ^
| Relay path(A, Relay-2, Relay-3, B) |
| +-----------+ +-----------+ |
+---->| Relay-2 |-------------------->| Relay-3 |-----+
+-----------+ +-----------+

Figure.2. An end-to-end multipath session

7. MPMTP-AR Agent Behavior

Based on user agent behavior in MPTS-AR, MPMTP-AR agent behavior
needs modification, extension and addition to support message
transmission. Those functions include session and path management,

Leiwm, et al. Expires January 28, 2014 [Page 11]
Internet-Draft MPMTP-AR July 2013

flow partitioning and scheduling, subflow packageing, sequenced
delivery within subflow, subflow recombination, subflow reporting,
and acknowledgement and congestion avoidance.

Compare with the agent behavior in MPTS-AR, MPMTP-AR agent behaviors
divided into four types: Consistent Behaviors, Modified Behaviors,
Additional Behaviors, and New Behaviors.

7.1 Consistent Behaviors

7.1.1 Path management

As illustrated in MPTS-AR, the sender need to manage the path
including obtain default path and candidate relay path, periodically
path probe, path keep-alive, and monitor quality of active paths.
Details refer to section of path management in MPTS-AR.

7.2 Modified Behaviors

7.2.1 Subflow recombination

The receiver recombines the original message according to MPTP
packers received from multiple subflows. The receiver first collects
receiving statistics for per-subflow by using Path-ID and
Subflow-Specific sequence number. Then the receiver puts data chunks
together and orders them by Transmission Sequence Number. At last,
the receiver distinguishes different message by Stream ID and orders
by Stream Sequence Number. The receiver delivers original message to
application.

7.3 Additional Behaviors

7.3.1 Session management

MPMTP-AR is a connection-oriented application-level protocol, so a
connective session needs to be established before transporting
message on multiple paths. The MPMTP-AR session setup uses a way of
out-of-band signaling (OpenPath) to get path information. The
session parameters negotiated and authentication should be done
during the signaling process. A session with multipath may be setup
at the beginning, or may be upgraded from a session with a default
path. The connective session establishment uses a four-way-handshake.

MPMTP-AR provides for graceful close (i.e., shutdown) of an active
session on request from the agent. MPMTP-AR also allows ungraceful
close (i.e., abort), either on request from the agent
(ABORT primitive) or as a result of an error condition detected.

Leiwm, et al. Expires January 28, 2014 [Page 12]
Internet-Draft MPMTP-AR July 2013

MPMTP-AR session is a set of multiple paths which are based on
connection. The detailed description of session management messages
will be specified in section 8.4.

7.3.2 Flow partitioning and scheduling

MPTS-AR defines a simple flow partitioning scheme to assign packets
to multiple subflows using the round-robin algorithm. In MPMTP-AR,
we introduce a path-based algorithm.

Due to paths has different transmission quality, we should assign
data chunks to subflows according to their capacity to increase
transmission quality. Since the sender can monitor active path
quality, such as bandwidth information, the path reception
statistics (e.g. RTT, loss-rate, delay etc.), so the sender assigned
more data chunks to the path which has a better performance. Data
chunks distributions adjust dynamically and periodically.

The sender should associate a subflow with an active path according
to scheduling strategy. MPTS-AR indicates that the scheduling policy
should take various factors into consideration, including the
estimated path bandwidth information, the path reception statistics
(e.g. RTT, loss-rate, delay etc.), and the relative importance of
subflow data and so on. The sender orders the available path list
according to the path quality descending order. At the same time,
the sender maintains active paths. If the path in available path
list performs better than an active path for a time, then the path
should take over the active path. This behavior is maintained
throughout the session.

7.3.3 Subflow packaging

In a session, the sender formats data chunks into MPMRP data packets
following MPRP core protocol defined in MPTS-AR and the MPTP
extension defined in section 8. Then the sender dispatches MPTP data
packets along corresponding paths.

Apart from two key fields including path identifier and
subflow-specific sequence number defined in MPTS-AR, the common
header also has two another fields: from-tag, and to-tag. Both
from-tag and to-tag are unique. They are generated by the sender and
receiver respectively at the establishment of the session. If they
have not been generated, they are set to zero. The from-tag and the
to-tag represent a globally unique session.

Control information and user data are encapsulated into chunks. The
chunks contain a common header and chunk value. All chunks put into
payload field in MPTP data format. Details of different chunks are

Leiwm, et al. Expires January 28, 2014 [Page 13]
Internet-Draft MPMTP-AR July 2013

defined in section 8.

7.3.4 Subflow reporting

As mentioned in MPTP-AR, both the sender and the receiver need to
send subflow report to monitor the transmission quality. MPTP-AR
only defines deliver route of Sender Reports (SR) and Receiver Reports
(RR). In this document, we define when to generate reports and what
reports contain.

The suggested constants are to be used for the subflow report
interval calculation. Sessions operating under this document may
specify a separate parameter for the traffic bandwidth rather than
using the default fraction of the session bandwidth. The recommended
fraction of the session bandwidth added for reports be fixed at 5%.
The recommendation is that 1/4 of the report bandwidth be dedicated
to data sender, the recommended default values for these two
parameters would be 1.25%and 3.75%, respectively. The reports
bandwidth for data senders should be kept non-zero so that sender
reports can still be sent for inter-media synchronization.

The content of report should be able to reflect the sending and
receiving status. They collect statistics, such as sent chunks, and
received chunks for per subflow. Details of the report format
defined in section 8.4.

7.4 New Behaviors

7.4.1 Sequenced Delivery

MPMTP-AR supports reliable and ordered message transmission by
sequence, such as Transmission Sequence Number, Subflow-Specific
Sequence Number, Stream Identification, Stream Sequence Number,
and Path-ID.

MPMTP-AR uses two levels of sequence spaces to guarantee reliable and
ordered transmission: a session-level sequence number (Transmission
Sequence Number) and another suflow-level sequence number
(Subflow-Specific Sequence Number) for each DATA chunk. TSN is
initialed as a randomly number, and SSSN is a number starting from
zero. This permits session-level segmentation reassembly and
retransmission of the same part of session-level sequence space on
different subflow-level sequence space.

The sender must be able to tell the receiver how to reassemble the
data. In order to achieve this, the receiver must determine how
subflow-level data (carrying stream sequence numbers) maps at the
session-level. This is referred to as the "transmission sequence

Leiwm, et al. Expires January 28, 2014 [Page 14]
Internet-Draft MPMTP-AR July 2013

mapping". This mapping can be represented as a tuple of (transmission
sequence number, Subflow-Specific sequence number, length), i.e., for
a given number of bytes (the length), the subflow sequence space
beginning at the given sequence number maps to the session-level
sequence space (beginning at the given data sequence number).

MPMTP-AR uses path identity to distinguish multiple paths. One-to-one
relationship is between path and subflow. This ensures the path to be
unique in the whole network. The sender must be able to tell the
relay to choose which path and tell the receiver which subflow the
Packet come from by Path-ID.

7.4.2 Acknowledgement and Congestion Avoidance

MPMTP-AR supports select acknowledgements at session-level in order
to provide an acknowledgement and retransmission service to the
application.

MPMTP-AR assigns a Transmission Sequence Number (TSN) to each data
chunk. The TSN is independent of any Stream Sequence Number (SSN)
assigned at the stream level. The receiving SACK acknowledges all
TSNs received, even if there are gaps in the sequence. In this way,
reliable delivery is kept functionally separate from sequenced stream
delivery.

MPMTP-AR could use the data sequence mapping and session-level SACKs
to decide when a session-level segment was received. A session-level
SACKs signal when the receive window moves forward, sum correct
receiving transmission sequence number, out of order blocks and
retransmission blocks. It would mean that once a segment is SACKed,
it can be discarded in the send buffer. Re-transmission send buffer
has higher priority. Transmission reports signal the sender detail
information of active path, such as correctly receiving ratio and
RTT. Sender would send segments in re-transmission buffer over the
best transmission quality path according to transmission report.
MPMTP-AR agent message from application, and put it into send buffer.
At the beginning, the receiver tells the sender size of receive
window via MPMTP-AR session establishment. During message
transmission, receiver moves forward receive window and signals the
sender this change via SACKs. The sender adjusts send buffer
according to receive window size.

The acknowledgement and congestion avoidance function is responsible
for packet retransmission when timely acknowledgement has not been
received. Packet retransmission is conditioned by congestion
avoidance procedures similar to those used for TCP.
Large-scale experiments are therefore required in order to determine
the most appropriate retransmission strategy, and recommendations will

Leiwm, et al. Expires January 28, 2014 [Page 15]
Internet-Draft MPMTP-AR July 2013

be refined once more information is available.

8. MPMTP-AR Packet Format: MPTP Format Extension

This section defines MPTP format extension to meet the requirement of
behaviors described in section 7.

8.1 Overview

As stated in MPTS-AR, although MPTP obtain a simple, unreliable
datagram service from the underlying UDP [5], MPTP can meet reliable
delivery requirements of upper application programs.

MPTP is only a protocol framework that is not complete, reliable
delivery requirement of upper application programs can be met in MPTP
extension.

In order to support agent behavior illustrated in section 7, we
define MPMTP-AR packet format, by expanding MPTP header to define
several types of chunk which are put into MPTP payload data or
control data field.

8.2 MPMTP-AR Header

MPMTP-AR header inherits from MPTP header, including eight
octet-length header, and add another eight octet-length extension
after it. The eight octet-length addition is same for MPMTP-AR data
packets and MPMTP-AR control packets.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=1|T|P| AMT | TOS/CT | SSSN/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| From Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| To Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields have the following meaning:

In this document, AMT=2, indicates that this MPMTP-AR packet conforms

Leiwm, et al. Expires January 28, 2014 [Page 16]
Internet-Draft MPMTP-AR July 2013

to reliable MPTP extension.

From Tag/To Tag: 32 bits (unsigned integer)
This field is set by the sender/receiver of this chunk. Each agent
generates a tag randomly at the session establishment, and keeps
the tag during the whole session. When the agent sends packet, it
puts its own tag in From Tag, and put the peer's tag in To Tag. If
the sender doesn't have the peer's tag, this field is set zero.

The combination of the From tag, and To tag completely defines a
peer-to-peer session relationship.

Chunk: (variable length)
This field contains data or control information which is defined in the next sections.

8.3 MPMTP-AR Data Chunk Definition

Each MPMTP-AR data packet contains one data chunk. The following
format MUST be used for the DATA chunk:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=1|1|P| AMT | TOS | SSSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| From Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| To Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI |Reserved |U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmission Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier | Stream Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SI (Stream Identification):8 bits
A sequence number identify the stream to which the user data
belongs.

U bit: 1 bit
The (U)nordered bit, if set to '1', indicates that this is an

Leiwm, et al. Expires January 28, 2014 [Page 17]
Internet-Draft MPMTP-AR July 2013

unordered DATA chunk, and there is no Stream Sequence Number
assigned to this DATA chunk. Therefore, the receiver MUST ignore
the Stream Sequence Number field. After reassembly (if necessary),
unordered DATA chunks MUST be dispatched to the upper layer by the
receiver without any attempt to reorder. If an unordered user
message is fragmented, each fragment of the message MUST have its
U bit set to '1'.

B bit: 1 bit
The (B)eginning fragment bit, if set, indicates the first fragment
of a user message.

E bit: 1 bit
The (E)nding fragment bit, if set, indicates the last fragment of
a user message.

An unfragmented user message shall have both the B and E bits set
to '1'. Setting both B and E bits to '0' indicates a middle
fragment of a multi-fragment user message, as summarized in the
following table:

When a user message is fragmented into multiple chunks, the TSNs
are used by the receiver to reassemble the message. This means that
the TSNs for each fragment of a fragmented user message MUST be
strictly sequential.

Length: 16 bits (unsigned integer)
This field indicates the length of the DATA chunk in bytes from
the beginning of the type field to the end of the User Data field
excluding any padding. A DATA chunk with one byte of user data
will have Length set to 17 (indicating 17 bytes).

A DATA chunk with a User Data field of length L will have the
Length field set to (12 + L) (indicating 12+L bytes) where L MUST
be greater than 0.

TSN: 32 bits (unsigned integer)
This value represents the TSN for this DATA chunk. The valid range
of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0
after reaching 4294967295.

Payload Protocol Identifier: 16 bits (unsigned integer)
This value represents an application specified protocol
identifier. This value is passed to MPMTP-AR by its MPMTP-AR user
and sent to its peer. This identifier is not used by MPMTP-AR but
can be used by certain network entities, as well as by the peer
application, to identify the type of information being carried in
this DATA chunk. This field must be sent even in fragmented DATA

Leiwm, et al. Expires January 28, 2014 [Page 18]
Internet-Draft MPMTP-AR July 2013

chunks. Note that this field is NOT touched by an MPMTP-AR
implementation; therefore, its byte order is NOT necessarily big
endian. The MPMTP-AR user is responsible for any byte order
conversions to this field.

The value 0 indicates that no application identifier is specified
by the upper layer for this payload data.

Stream Sequence Number: 16 bits (unsigned integer)
This value represents the Stream Sequence Number of the following
user data within the stream. Valid value range is 0 to 65535.

User Data: variable length
This is the payload user data. The implementation MUST pad the end
of the data to a 4-byte boundary with all-zero bytes. Any padding
MUST NOT be included in the Length field. A sender MUST never add
more than 3 bytes of padding.

8.4 MPMTP-AR Control Chunk Definition

The figure below illustrates the field format for the control packets
to be transmitted in the MPMTP-AR packet. Each packet is formatted
according to CT field.

Control data is packed into chunks. Next sections from 8.4.1 to
8.4.19 describe the format of control chunks.

The values of CT are defined as follows:

Leiwm, et al. Expires January 28, 2014 [Page 19]
Internet-Draft MPMTP-AR July 2013

+---------------+-----------------------------------------------------+
| ID Value | Chunk Type |
+---------------+-----------------------------------------------------+
| 1 | Sender Report (SR) |
+---------------+-----------------------------------------------------+
| 2 | Receiver Report (RR) |
+---------------+-----------------------------------------------------+
| 3 | Keep Alive (KA) |
+---------------+-----------------------------------------------------+
| 4 | Session Initiation (SINIT) |
+---------------+-----------------------------------------------------+
| 5 | Session Initiation Acknowledgement (SINIT ACK) |
+---------------+-----------------------------------------------------+
| 6 | Cookie Echo (COOKIE ECHO) |
+---------------+-----------------------------------------------------+
| 7 | Cookie Acknowledgement (COOKIE ACK) |
+---------------+-----------------------------------------------------+
| 8 | Subflow INIT Request (SubINIT) |
+---------------+-----------------------------------------------------+
| 9 | Subflow INIT Acknowledgement (SubINIT ACK) |
+---------------+-----------------------------------------------------+
| 10 | Selective Acknowledgement (SACK) |
+---------------+-----------------------------------------------------+
| 11 | Subflow Shutdown (SubSHUTDOWN) |
+---------------+-----------------------------------------------------+
| 12 | Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK) |
+---------------+-----------------------------------------------------+
| 13 | Session Shutdown (SSHUTDOWN) |
+---------------+-----------------------------------------------------+
| 14 | Session Shutdown Acknowledgement (SSHUTDOWN ACK) |
+---------------+-----------------------------------------------------+
| 15 | Session Shutdown Complete (SSHUTDOWN COMPLETE) |
+---------------+-----------------------------------------------------+
| 16 | Abort (ABORT) |
+---------------+-----------------------------------------------------+
| 17 | Operation Error (ERROR) |
+---------------+-----------------------------------------------------+
| 18 | Path Feedback (PATH FEEDBACK) |
+---------------+-----------------------------------------------------+
| 19 | Path Probe (PATH PROBE) |
+---------------+-----------------------------------------------------+

8.4.1 Sender Report (SR)

The sender report packet consists of three sections.

Leiwm, et al. Expires January 28, 2014 [Page 20]
Internet-Draft MPMTP-AR July 2013

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's octet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields have the following meaning:

Timestamp: 32 bits
Indicates the time when this report was sent.

Sender's packet count: 32 bits
The total number of MPMTP-AR data packets transmitted by the sender
since starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
tag.

Sender's octet count: 32 bits
The total number of payload octets (i.e., not including header or
padding) transmitted in RTP data packets by the sender since
starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
tag. This field can be used to estimate the average payload data
rate.

8.4.2 Receiver Report (RR)

The receiver report packet consists of four sections.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cumulative number of packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last RR (LRR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cumulative number of packets: 32 bits
The total number of MPMTP-AR data packets from sender that have
been received since the beginning of reception.

Highest sequence number received: 32 bits
The field contains the highest transmission sequence number
received in a MPMTP-AR data packet from the sender.

Last SR (LSR): 32 bits
This field indicates the time of receiving last sender report. If

Leiwm, et al. Expires January 28, 2014 [Page 21]
Internet-Draft MPMTP-AR July 2013

no SR has received yet, this field is set to zero.

Delay since last SR (DLSR): 32 bits
The delay, expressed in units of 1/65536 seconds, between
receiving the last SR packet from the sender and sending this
reception report packet. If no SR packet has been received yet,
the DLSR field is set to zero.
8.4.3 Keep Alive (KA)

This chunk contains only timestamp.

Timestamp: 32 bits
This field indicates the time of sending this Keep Alive packet.

8.4.4 Session Initiation (SINIT)

This chunk is used to initiate an MPMTP-AR session between two
endpoints. The format of the SINIT chunk is shown below:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Subflow (N)| MSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SINIT chunk contains the following parameters. Unless otherwise
noted, each parameter MUST only be included once in the INIT chunk.

IMPLEMENTATION NOTE: If an SINIT chunk is received with known
parameters that are not optional parameters of the SINIT chunk, then
the receiver SHOULD process the SINIT chunk and send back an SINIT

Leiwm, et al. Expires January 28, 2014 [Page 22]
Internet-Draft MPMTP-AR July 2013

ACK.

Number of Outbound Subflow (NOS): 16 bits (unsigned integer)
Defines the maximum number of outbound subflow the sender of this
SINIT chunk wishes to create in this session. The value of 0 MUST NOT
be used.

Note: A receiver of an SINIT with the NOS value set to 0 SHOULD abort
the session.

MSN (Maximum Stream Number): 8 bits (unsigned integer)
Defines the max number of streams the sender of this SINIT chunk
allows to use in this session.
Note: A receiver of an SINIT with the MSN value set to 0 SHOULD abort
the session.

Initial TSN (I-TSN): 32 bits (unsigned integer)
This value defines the initial TSN that the sender will use. The
valid range is from 0 to 2**32-1. This field MAY be set to the value
of the Initiate Tag field.

1) Optional/Variable-Length Parameters in INIT

The format of optional parameters in the INIT ACK chunk is shown
below:

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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameters Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 16 bits (unsigned integer)
This field identifies the type of parameters contained in the
optional field.

Length: 16 bits (unsigned integer)
This field indicates the length of the optional parameters in
bytes from the beginning of the type field to the end of the
parameters field excluding any padding. Optional parameters with
one byte parameters will have Length set to 5 (indicating 5
bytes).
Details of variable-length parameters would be discussed in the
future.

Leiwm, et al. Expires January 28, 2014 [Page 23]
Internet-Draft MPMTP-AR July 2013

8.4.5 Session Initiation Acknowledgement (SINIT ACK)

The SINIT ACK chunk is used to acknowledge the initiation of an
MPMTP-AR session.

The parameter part of SINIT ACK is formatted similarly to the SINIT
chunk. It uses two extra variable parameters: advertised receiver
window credit and state cookie. The format of the SINIT ACK chunk is
shown below:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Inbound Subflow (N) | MSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional Parameters (State Cookie) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
This value represents the dedicated buffer space, in number of
bytes, the receiver has reserved in session with this window.
During the life of the session, this buffer space SHOULD NOT be
lessened (i.e., dedicated buffers taken away from this session).

Number of Inbound Subflow (NIS): 16 bits (unsigned integer)
Defines the maximum number of subflow the receiver allows the
sender to create in this session. The value 0 MUST NOT be used.

Note: There is no negotiation of the actual number of subflow but
instead the two endpoints will use the min (requested, offered).

Note: The sender receives SINIT ACK with the MIS value set to 0
SHOULD destroy the session discarding its TCB.

MSN (Maximum Stream Number): 8 bits (unsigned integer)
This field defines the max number of streams the receiver allows
to use in this session. Valid value range is 1 to 31.

State Cookie:
Type Value: 1
Length: Variable size, depending on size of Cookie.
Parameter Value:
This parameter value MUST contain all the necessary state and
parameter information required to create the session, along

Leiwm, et al. Expires January 28, 2014 [Page 24]
Internet-Draft MPMTP-AR July 2013

with a Message Authentication Code (MAC).

8.4.6 State Cookie (COOKIE ECHO)

This chunk is used only during the initialization of a session. It is
sent by the initiator of an session to its peer to complete the
initialization process. This chunk MUST precede any DATA chunk sent
within the session.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPN (N) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path-ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path-ID #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Cookie /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPN (Init Path Number): 16 bit
Chunk Flags in this chunk called IPN indicates the number of
initialize path which the sender wants to use at the beginning of
the session. Valid value range is 1 to 255. It MUST NOT be bigger
than MIS INIT ACK.

Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the 4 bytes of
the chunk header and the chunk body.

Path-ID: 32 bits (unsigned integer)
This field indicates the path identification of subflow which the
sender will use in the session.

Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.

An implementation SHOULD make the cookie as small as possible to
ensure interoperability.

Leiwm, et al. Expires January 28, 2014 [Page 25]
Internet-Draft MPMTP-AR July 2013

Note: A Cookie Echo does NOT contain a State Cookie parameter;
instead, the data within the State Cookie's Parameter Value
becomes the data within the Cookie Echo's Chunk Value. This allows
an implementation to change only the first 2 bytes of the State
Cookie parameter to become a COOKIE ECHO chunk.

8.4.7 Cookie Acknowledgement (COOKIE ACK)

This chunk is used to end a session establishment. It acknowledges
the receipt of a COOKIE ECHO chunk. This chunk is empty, so the
packet just contains packet header.

8.4.8 Subflow INIT Request (SubINIT)

The sender should send this chunk to its peer agent to notify the use
of a particular relay path negotiated in SINIT and SINIT ACK.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Path-ID: 32 bits (unsigned integer)
This field indicates the path identification of subflow which the
sender want to use in the session.

8.4.9 Subflow INIT Acknowledgement (SubINIT ACK)

The receiver should send this chunk to its peer agent to notify the
use of a particular relay path negotiated in SINIT and SINIT ACK.

8.4.10 Selective Acknowledgement (SACK)

This chunk is sent to the peer agent via default path to acknowledge
received DATA chunks and to inform the peer agent of gaps in the
received subsequences of DATA chunks as represented by their TSNs.

The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver
Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of
Duplicate TSNs fields.

By definition, the value of the Cumulative TSN Ack parameter is the

Leiwm, et al. Expires January 28, 2014 [Page 26]
Internet-Draft MPMTP-AR July 2013

last TSN received before a break in the sequence of received TSNs
occurs; the next TSN value following this one has not yet been
received at the agent sending the SACK. This parameter therefore
acknowledges receipt of all TSNs less than or equal to its value.

The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack
Block acknowledges a subsequence of TSNs received following a break
in the sequence of received TSNs. By definition, all TSNs
acknowledged by Gap Ack Blocks are greater than the value of the
Cumulative TSN Ack.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #1 Start | Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #N Start | Gap Ack Block #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cumulative TSN Ack: 32 bits (unsigned integer)
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. In the case where no DATA chunk has been
received, this value is set to the peer's Initial TSN minus one.

Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
This field indicates the updated receive buffer space in bytes of
the sender of this SACK.

Number of Gap Ack Blocks: 16 bits (unsigned integer)
This field indicates the number of Gap Ack Blocks included in this

Leiwm, et al. Expires January 28, 2014 [Page 27]
Internet-Draft MPMTP-AR July 2013

SACK.

Number of Duplicate TSNs: 16 bit
This field contains the number of duplicate TSNs the agent has
received. Each duplicate TSN is listed following the Gap Ack Block
list.

Gap Ack Blocks:
These fields contain the Gap Ack Blocks. They are repeated for
each Gap Ack Block up to the number of Gap Ack Blocks defined in
the Number of Gap Ack Blocks field. All DATA chunks with TSNs
greater than or equal to (Cumulative TSN Ack + Gap Ack Block
Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
Block End) of each Gap Ack Block are assumed to have been received
correctly.

Gap Ack Block Start: 16 bits (unsigned integer)
Indicates the Start offset TSN for this Gap Ack Block. To
calculate the actual TSN number the Cumulative TSN Ack is added to
this offset number. This calculated TSN identifies the first TSN
in this Gap Ack Block that has been received.

Gap Ack Block End: 16 bits (unsigned integer)
Indicates the End offset TSN for this Gap Ack Block. To calculate
the actual TSN number, the Cumulative TSN Ack is added to this
offset number. This calculated TSN identifies the TSN of the last
DATA chunk received in this Gap Ack Block.

For example, assume that the receiver has the following DATA chunks
newly arrived at the time when it decides to send a Selective ACK.

----------
| TSN=36 |
----------
| | <- still missing
----------
| TSN=34 |
----------
| TSN=33 |
----------
| | <- still missing
----------
| TSN=31 |
----------
| TSN=30 |
----------
| TSN=29 |
----------

Leiwm, et al. Expires January 28, 2014 [Page 28]
Internet-Draft MPMTP-AR July 2013

then the parameter part of the SACK MUST be constructed as follows
(assuming the new a_rwnd is set to 1500 by the sender):

+--------------------------------+
| Cumulative TSN Ack = 31 |
+--------------------------------+
| a_rwnd = 1500 |
+----------------+---------------+
| num of block=2 | num of dup=0 |
+----------------+---------------+
|block #1 strt=2 |block #1 end=3 |
+----------------+---------------+
|block #2 strt=5 |block #2 end=5 |
+----------------+---------------+

Duplicate TSN: 32 bits (unsigned integer)
Indicates the number of times a TSN was received in duplicate
since the last SACK was sent.

Every time a receiver gets a duplicate TSN (before sending the SACK);
it adds it to the list of duplicates. The duplicate count is
reinitialized to zero after sending each SACK.

For example, if a receiver were to get the TSN 35 three times it
would list 35 twice in the outbound SACK. After sending the SACK, if
it received yet one more TSN 35 it would list 35 as a duplicate once
in the next outgoing SACK.

8.4.11 Subflow Shutdown (SubSHUTDOWN)

An agent in a session MUST use this chunk to initiate a graceful
close of the session with its peer. Either the sender or the receiver
can initialize this chunk. This chunk has the following format.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Number(N) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Leiwm, et al. Expires January 28, 2014 [Page 29]
Internet-Draft MPMTP-AR July 2013

Path Number (N): 32 bits (unsigned integer)
This field indicates how many subflows will be closed.

Path ID: 32 bits (unsigned integer)
This parameter contains the Path ID of the subflow which will be
closed.

8.4.12 Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK)

This chunk MUST be used to acknowledge the receipt of the SubSHUTDOWN
chunk at the completion of the shutdown process. The format is
similar with SubSHUTODWN chunk.

8.4.13 Session Shutdown (SSHUTDOWN)

This chunk is used to close a session. The chunk is empty, so the
packet just contains header.

8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK)

This SSHUTDOWN ACK chunk MUST be used to acknowledge the receipt of
the SSHUTDOWN chunk.

Leiwm, et al. Expires January 28, 2014 [Page 30]
Internet-Draft MPMTP-AR July 2013

This chunk indicates the sender which subflow will be closed by Path
ID.

8.4.15 Session Shutdown Complete (SSHUTDOWN COMPLETE)

This chunk MUST be used to acknowledge the receipt of the SSHUTDOWN
ACK chunk and complete the shutdown process. The chunk is empty, so
the packet just contains header.

8.4.16 Abort (ABORT)

The ABORT chunk is sent to the peer of a session to close the
session. The ABORT chunk may contain Cause Parameters to inform the
receiver about the reason of the abort. Control chunks (except for
SINIT, SINIT ACK, and SSHUTDOWN COMPLETE) MAY be followed with an
ABORT, but they MUST be sent before the ABORT packet or they will be
ignored by the receiver.

If an agent receives an ABORT with a format error or no TCB is found,
it MUST silently discard it. Moreover, under any circumstances, an
agent that receives an ABORT MUST NOT respond to that ABORT by
sending an ABORT of its own.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ zero or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header
and all the Error Cause fields present.

Leiwm, et al. Expires January 28, 2014 [Page 31]
Internet-Draft MPMTP-AR July 2013

See section 8.4.17 for Error Cause definitions.

8.4.17 Operation Error (ERROR)

An agent sends this chunk to its peer agent to notify it of certain
error conditions. It contains one or more error causes. An Operation
Error is not considered fatal in and of it, but may be used with an
ABORT chunk to report a fatal condition. It has the following
parameters:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ one or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Number: 8 bits (unsigned integer)
This field indicates the number of errors listed in next Error
Causes field.

Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Number,
Reserved, Length, and Error Cause fields.

Error causes are defined as variable-length parameters using the
format described as below:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Cause-Specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cause Code: 16 bits (unsigned integer)
This value defines the type of error conditions being reported.

Leiwm, et al. Expires January 28, 2014 [Page 32]
Internet-Draft MPMTP-AR July 2013

Cause Code
Value Cause Code
--------- ----------------
1 Invalid Path-ID
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
7 Unrecognized Parameters
8 No User Data
9 Cookie Received While Shutting Down
10 User Initiated Abort
11 Protocol Violation

Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields.

Cause-Specific Information: variable length
This field carries the details of the error condition.

The following section 1) - 11) define error causes for MPMTP-AR.

1) Invalid Path-ID

Cause of error: Invalid Path ID indicates Relay received a DATA chunk
sent to a nonexistent subflow.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Path ID: 16 bits (unsigned integer)
This field contains the Stream Identifier of the DATA chunk
received in error.

Reserved: 16 bits
This field is reserved. It is set to all 0 on transmit and ignored
on receipt.

2) Missing Mandatory Parameter

Leiwm, et al. Expires January 28, 2014 [Page 33]
Internet-Draft MPMTP-AR July 2013

Cause of error: Missing Mandatory Parameter: indicates that one or
more mandatory parameters are missing in a received INIT or INIT ACK.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Missing Param Type /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Number of Missing params: 32 bits (unsigned integer)
This field contains the number of parameters contained in the
Cause-Specific Information field.

Missing Param Type: 16 bits (unsigned integer)
Each field will contain the missing mandatory parameter number.

3) Stale Cookie Error

Cause of error: Stale Cookie Error indicates the receipt of a valid
State Cookie that has expired.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Measure of Staleness: 32 bits (unsigned integer)
This field contains the difference, in microseconds, between the
current time and the time the State Cookie expired.

The sender of this error cause MAY choose to report how long past
expiration the State Cookie is by including a non-zero value in the
Measure of Staleness field. If the sender does not wish to provide
this information, it should set the Measure of Staleness field to the
value of zero.

Leiwm, et al. Expires January 28, 2014 [Page 34]
Internet-Draft MPMTP-AR July 2013

4) Out of Resource

Cause of error: Out of Resource: Indicates that the sender is out of
resource. This is usually sent in combination with or within an
ABORT.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5) Unrecognized Chunk Type

Cause of error: Unrecognized Chunk Type: This error cause is returned
to the originator of the chunk if the receiver does not understand
the chunk.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=5 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Unrecognized Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Chunk: variable length
The Unrecognized Chunk field contains the unrecognized chunk from
the MPMTP-AR packet complete with Chunk Type, Chunk Flags, and
Chunk Length.

6) Invalid Mandatory Parameter

Cause of error: Invalid Mandatory Parameter: This error cause is
returned to the originator of an SINIT or SINIT ACK chunk when one of
the mandatory parameters is set to an invalid value.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7) Unrecognized Parameters

Cause of error: Unrecognized Parameters: This error cause is returned

Leiwm, et al. Expires January 28, 2014 [Page 35]
Internet-Draft MPMTP-AR July 2013

to the originator of the SINIT ACK chunk if the receiver does not
recognize one or more Optional parameters in the SINIT ACK chunk.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Parameters: variable length
The Unrecognized Parameters field contains the unrecognized
parameters copied from the SINIT ACK chunk. This error cause
packet is normally contained in an ERROR chunk followed with the
COOKIE ECHO packet when responding to the INIT ACK, when the
sender of the COOKIE ECHO chunk wishes to report unrecognized
parameters.

8) No User Data

Cause of error: No User Data: This error cause is returned to the
originator of a DATA chunk if a received DATA chunk has no user 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ TSN Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TSN value: 32 bits (unsigned integer)
The TSN value field contains the TSN of the DATA chunk received
with no user data field.

9) Cookie Received While Shutting Down

Cause of error: Cookie Received While Shutting Down: A COOKIE ECHO
was received while the agent was in the session-level SSHUTDOWN-ACK-
SENT state. This error is usually returned in an ERROR chunk followed
with the retransmitted SSHUTDOWN ACK.

Leiwm, et al. Expires January 28, 2014 [Page 36]
Internet-Draft MPMTP-AR July 2013

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=9 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10) User-Initiated Abort

Cause of error: This error cause MAY be included in ABORT chunks that
are sent because of an MPMTP-AR user request. The MPMTP-AR user can
specify an Abort Reason that is transported by MPMTP-AR transparently
and MAY be delivered to the MPMTP-AR user at the peer.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11) Protocol Violation

Cause of error: This error cause MAY be included in ABORT chunks that
are sent because an MPMTP-AR agent detects a protocol violation of
the peer that is not covered by the error causes described in above
section 1) to section 10). An implementation MAY provide additional
information specifying what kind of protocol violation has been
detected.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.4.18 Path Feedback (PATH FEEDBACK)

This chunk is used to indicate the sender about path feedback
information. The chunk includes time interval, subflow
identification, max received transmission sequence number and
correctly received data chunk number.

Leiwm, et al. Expires January 28, 2014 [Page 37]
Internet-Draft MPMTP-AR July 2013

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Feedback Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Feedback Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Max TSN #1 | Received Data Chunks Number #1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Max TSN #N | Received Data Chunks Number #N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Last Feedback Time: 32 bits (unsigned integer)
This field marks the time at which the receiver seed last PATH
FEEDBACK.

Current Feedback Time: 32 bits (unsigned integer)
This field marks the time at which the receiver seeds this PATH
FEEDBACK.

Received Max TSN: 16 bits (unsigned integer)
This field indicates the max TSN of data chunk received from the
path mark at Path ID field.

Received Data Chunks Number: 16 bits (unsigned integer)
This field indicates the number of data chunk received from the
path mark at Path ID between the Last Feedback Time and the
Current Feedback Time.

8.4.19 Path Probe (PATH PROBE)

An agent should send this chunk to its peer agent to probe the path
reachability and RTT. This chunk contains send time.

Leiwm, et al. Expires January 28, 2014 [Page 38]
Internet-Draft MPMTP-AR July 2013

Timestamp: 32 bits
This field record the send time of this chunk form the initiator
of this chunk.

The receiver delivers this chunk to the sender via default path as
soon as received and do not do any change to it. The initiator can
calculate the RTT by send time and receive time.

9. MPMTP-AR Session State Diagram

During the life time of an MPMTP-AR session, the MPMTP-AR agent's
session progresses from one state to another in response to various
events.

The state diagram in the figures below illustrates state changes,
together with the causing events and resulting actions. Note that
some of the error conditions are not shown in the state diagram. Full
descriptions of all special cases are found in the text.

Note: Chunk names are given in all capital letters, while parameter
names have the first letter capitalized, e.g., COOKIE ECHO chunk type
vs. State Cookie parameter. If more than one event/message can occur
that causes a state transition, it is labeled (A), (B), etc.

Leiwm, et al. Expires January 28, 2014 [Page 39]
Internet-Draft MPMTP-AR July 2013

----- -------- (from any state)
/ \ / rcv ABORT [ABORT]
rcv SINIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd SINIT ACK ---| CLOSED |
+---------+
/ \ [Session]
/ \ ---------------
| | create TCB
| | snd SINIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv SINIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop sinit timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+

Leiwm, et al. Expires January 28, 2014 [Page 40]
Internet-Draft MPMTP-AR July 2013

(from the ESTABLISHED state only)
|
|
/--------+--------\
[SSHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SSHUTDOWN| | rcv SSHUTDOWN
|PENDING | |------------------
+---------+ | check outstanding
| | DATA chunks
No more outstanding | |
---------------------| |
snd SSHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SSHUTDOWN| | SSHUTDOWN | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| |
rcv SSHUTDOWN ACK | |No more outstanding
-----------------------| |-------------------
stop shutdown timer | |send SSHUTDOWN ACK
send SSHUTDOWN COMPLETE| |strt shutdown timer
delete TCB | |
| |
| |
| |
| +-----------+
| | SSHUTDOWN | (7)
| | ACK-SENT |
| +-----------+
| | rcv SSHUTDOWN COMPLETE
| |-----------------------
| | stop shutdown timer
| | delete TCB
| |
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+

Notes:
1) If the State Cookie in the received COOKIE ECHO is invalid

Leiwm, et al. Expires January 28, 2014 [Page 41]
Internet-Draft MPMTP-AR July 2013

(i.e., failed to pass the integrity check), the receiver MUST
silently discard the packet. Or, if the received State Cookie
is expired (see section 10.1.4), the receiver MUST send back an
ERROR chunk. In either case, the receiver stays in the CLOSED
state.

2) If the T1-init timer expires, the agent MUST retransmit SINIT
and restart the T1-init timer without changing state. This MUST
be repeated up to 'Max.Init.Retransmits' times. After that, the
agent MUST abort the initialization process and report the
error to the MPMTP-AR user.

3) If the T1-cookie timer expires, the agent MUST retransmit
COOKIE ECHO and restart the T1-cookie timer without changing
state. This MUST be repeated up to MAX Init Retransmits times.
After that, the agent MUST abort the initialization process
and report the error to the MPMTP-AR user. After that, the
agent MUST abort the initialization process and report the
error to the MPMTP-AR user.

4) In the SSHUTDOWN-SENT state, the agent MUST response any
received control chunks without delay.

5) In the SSHUTDOWN-RECEIVED state, the agent MUST leave this
state when all data in queue is ordered.

The CLOSED state is used to indicate that a subflow is not created
(i.e., doesn't exist).

10. Session Initialization

Before the first data transmission can take place from one MPMTP-AR
agent ("A") to another MPMTP-AR agent ("Z"), the two endpoints must
complete a session process in order to set up an MPMTP-AR session
between them.

The MPMTP-AR user at an agent should use the SESSION primitive to
initialize an MPMTP-AR session to another MPMTP-AR agent.

IMPLEMENTATION NOTE: From an MPMTP-AR user's point of view, a session
may be implicitly opened, without a SESSION primitive being invoked,
by the initiating agent's sending of the first user data to the
destination agent. The initiating MPMTP-AR will assume default
values for all mandatory and optional parameters for the SINIT/SINIT
ACK.

Once the session is established, unidirectional path is open for data
transfer (see section 10.1.1). Then according to the parameters

Leiwm, et al. Expires January 28, 2014 [Page 42]
Internet-Draft MPMTP-AR July 2013

negotiated at session, MPMTP-AR agent A can use subflow after
notifying agent Z.

10.1 Normal Establishment of a Session

The initialization process consists of the following steps (assuming
that MPMTP-AR agent "A" tries to set up a session with MPMTP-AR agent
"Z" and "Z" accepts the new session):

A) "A" first sends an SINIT chunk to "Z". In the SINIT, "A" must
provide its Tag (Tag-A) in the from-tag field. From-tag SHOULD be
a random number in the range of 1 to 4294967295 (see section
10.3.1 for Tag value selection). After sending the SINIT, "A"
starts the T1-init timer and enters the COOKIE-WAIT state.

B) "Z" shall respond immediately with an SINIT ACK chunk. In the
response, besides filling in other parameters, "Z" must set the
to-tag field to Tag_A, and also provide its own Tag (Tag_Z) in the
from-tag field.

Moreover, "Z" MUST generate and send along with the SINIT ACK a State
Cookie. See section 10.1.3 for State Cookie generation.

Note: After sending out SINIT ACK with the State Cookie parameter,
"Z" MUST NOT allocate any resources or keep any states for the new
session. Otherwise, "Z" will be vulnerable to resource attacks.

C) Upon reception of the SINIT ACK from "Z", "A" shall stop the T1-
init timer and leave the COOKIE-WAIT state. "A" shall then send
the State Cookie received in the SINIT ACK chunk.

D) Upon reception of the COOKIE ECHO chunk, agent "Z" will reply with
a COOKIE ACK chunk after building a TCB and moving to the
ESTABLISHED state.

IMPLEMENTATION NOTE: An implementation may choose to send the
Communication Up notification to the MPMTP-AR user upon reception of
a valid COOKIE ECHO chunk.

Leiwm, et al. Expires January 28, 2014 [Page 43]
Internet-Draft MPMTP-AR July 2013

E) Upon reception of the COOKIE ACK, agent "A" will move from the
COOKIE-ECHOED state to the ESTABLISHED state, stopping the
T1-cookie timer.

An agent MUST send the INIT ACK to the agent from which it received
the INIT.

Note: T1-init timer and T1-cookie timer shall follow the same rules
given in section 11.3.

If an agent receives an SINIT, SINIT ACK, or COOKIE ECHO chunk but
decides not to establish the new session due to missing mandatory
parameters in the received SINIT or SINIT ACK, invalid parameter
values, or lack of local resources, it SHOULD respond with an ABORT
chunk. It SHOULD also specify the cause of abort, such as the type of
the missing mandatory parameters, etc., by including the error cause
parameters with the ABORT chunk.

Note that a COOKIE ECHO chunk that does NOT pass the integrity check
is NOT considered an 'invalid parameter' and requires special
handling; see section 10.1.4.

After the reception of the first DATA chunk in a session the agent
MUST immediately respond with a SACK to acknowledge the DATA chunk.
Subsequent acknowledgements should be done as described in section
11.2.

When the TCB is created, each agent MUST set its internal Cumulative
TSN Ack Point to the value of its transmitted Initial TSN minus one.

10.1.1 Handle Path Parameters

In the SINIT and SINIT ACK chunks, the sender of the chunk MUST
indicate the number of outbound subflow (NOS) it wishes to have in
the session, as well as the maximum stream number (MSN) it will use
in the seesion.

After receiving the session configuration information from the other
side, MPMTP-AR agent MUST perform the following check: If the peer's
number outbound subflow (NOS) is less than the agent's maximum number
inbound subflow (MIS), meaning that the peer is incapable of
supporting all the outbound subflow the agent wants to configure, the
agent MUST use MIS outbound subflows and MAY report any shortage to
the MPMTP-AR user. The MPMTP-AR user can then choose to abort the
session if the resource shortage is unacceptable.

After the session is initialized, the valid outbound subflow
identifier range for either agent shall be 0 to min (local MIS,
remote NOS)-1.

10.1.2 Generating State Cookie

When sending an SINIT ACK as a response to an SINIT chunk, the sender
of SINIT ACK creates a State Cookie and sends it in the State Cookie
parameter of the SINIT ACK. Inside this State Cookie, the sender
should include a MAC (see [RFC2104] for an example), a timestamp on
when the State Cookie is created, and the lifespan of the State
Cookie, along with all the information necessary for it to establish

Leiwm, et al. Expires January 28, 2014 [Page 44]
Internet-Draft MPMTP-AR July 2013

the session.

The following steps SHOULD be taken to generate the State Cookie:

1) Create session TCB using information from both the received INIT
and the outgoing INIT ACK chunk.

2) In the TCB, set the creation time to the current time of day, and
the lifespan to the protocol parameter 'Valid.Cookie.Life'.

3) From the TCB, identify and collect the minimal subset of
information needed to re-create the TCB, and generate a MAC using
this subset of information and a secret key (see [RFC2104] for an
example of generating a MAC).

4) Generate the State Cookie by combining this subset of information
and the resultant MAC.

After sending the INIT ACK with the State Cookie parameter, the
sender SHOULD delete the TCB and any other local resource related to
the new session, so as to prevent resource attacks.

The hashing method used to generate the MAC is strictly a private
matter for the receiver of the INIT chunk. The use of a MAC is
mandatory to prevent denial-of-service attacks. The secret key SHOULD
be random ([RFC4086] provides some information on randomness
guidelines); it SHOULD be changed reasonably frequently, and the
timestamp in the State Cookie MAY be used to determine which key
should be used to verify the MAC.

An implementation SHOULD make the cookie as small as possible to
ensure interoperability.

10.1.3 State Cookie Processing

When an agent (in the COOKIE-WAIT state) receives an SINIT ACK chunk
with a State Cookie parameter, it MUST immediately send a COOKIE ECHO
chunk to its peer with the received State Cookie.The sender MAY also
add any pending DATA chunks to the packet after the COOKIE ECHO
chunk.

The agent shall also start the T1-cookie timer after sending out the
COOKIE ECHO chunk. If the timer expires, the agent shall retransmit
the COOKIE ECHO chunk and restart the T1-cookie timer. This is
repeated until either a COOKIE ACK is received or 'Max.Init.
Retransmits' is reached causing the peer agent to be marked
unreachable (and thus the session enters the CLOSED state).

Leiwm, et al. Expires January 28, 2014 [Page 45]
Internet-Draft MPMTP-AR July 2013

10.1.4 State Cookie Authentication

When an agent receives a COOKIE ECHO chunk from another agent with
which it has no session, it shall take the following actions:

1) Compute a MAC using the TCB data carried in the State Cookie and
the secret key (note the timestamp in the State Cookie MAY be used
to determine which secret key to use). [RFC2104] can be used as a
guideline for generating the MAC,

2) Authenticate the State Cookie as one that it previously generated
by comparing the computed MAC against the one carried in the State
Cookie. If this comparison fails, the MPMTP-AR packet, including
the COOKIE ECHO and any DATA chunks, should be silently discarded.

3) Compare the Verification Tag contained within the COOKIE ECHO
chunk to the Verification Tag within the MPMTP-AR common header of
the received packet. If these values do not match, the packet MUST
be silently discarded.

4) Compare the creation timestamp in the State Cookie to the current
local time. If the elapsed time is longer than the lifespan
carried in the State Cookie, then the packet, including the COOKIE
ECHO and any attached DATA chunks, SHOULD be discarded, and the agent
MUST transmit an ERROR chunk with a "Stale Cookie" error cause to
the peer agent.

5) If the State Cookie is valid, create an session to the sender of
the COOKIE ECHO chunk with the information in the TCB data carried
in the COOKIE ECHO and enter the ESTABLISHED state.

6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the
COOKIE ECHO.

If a COOKIE ECHO is received from an agent with which the receiver of
the COOKIE ECHO has an existing session, the procedures in section
10.2 should be followed.

10.1.5 Open Subflow

When an agent wants to use a new subflow, before data transmission it
needs to tell relay path information to the peer.

When an agent receives a SUBFLOW INIT from another agent with which
it has an session, it shall take the following actions:

1) Check subflow parameter and session information;

Leiwm, et al. Expires January 28, 2014 [Page 46]
Internet-Draft MPMTP-AR July 2013

2) Send response. If it is valid, the receiver sends SUBFLOW INIT ACK
to the sender; otherwise, the receiver MUST transmit an ERROR
chunk with an error cause to the peer agent.

If the sender receives a SUBFLOW INIT ACK response, it can use this
sublfow to transmit data; otherwise it SHOULD terminal this subflow
request.

10.2 Handle Duplication or Unexpected Issue

During the life time of a session (in one of the possible states), an
agent may receive from its peer agent one of the setup chunks (SINIT,
SINIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat
such a setup chunk as a duplicate and process it as described in this
section

Note: An agent will not receive the chunk unless the chunk was from
an MPMTP-AR agent associated with this agent. Therefore, the agent
processes such a chunk as part of its current session.

The following scenarios can cause duplicated or unexpected chunks:

A) The peer has crashed without being detected, restarted itself, and
sent out a new SINIT chunk trying to restore the session,

B) The chunk is from a stale packet that was used to establish the
present session or a past session that is no longer in existence,

C) The chunk is a false packet generated by an attacker, or

D) The peer never received the COOKIE ACK and is retransmitting its
COOKIE ECHO.

The rules in the following sections shall be applied in order to
identify and correctly handle these cases.

10.2.1 Unexpected SINIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT, and SSHUTDOWN-ACK-SENT

Unless otherwise stated, upon receipt of an unexpected SINIT for this
session, the agent shall generate an SINIT ACK with a State Cookie.
Before responding, the agent MUST check to see if the unexpected
SINIT adds new parameters to the session. If new parameters are added
to the session, the agent MUST respond with an ABORT, copying the
'From Tag' of the unexpected INIT into the 'To Tag' of the outbound
packet carrying the ABORT. If no new parameters are added, when
responding to the SINIT in the outbound SINIT ACK. The outbound
MPMTP-AR packet containing this SINIT ACK MUST carry a Tag value

Leiwm, et al. Expires January 28, 2014 [Page 47]
Internet-Draft MPMTP-AR July 2013

equal to the Initiate Tag found in the unexpected SINIT. And the
SINIT ACK MUST contain a new Tag (randomly generated; see section
10.3.1). Other parameters for the agent SHOULD be copied from the
existing parameters of the session (e.g., number of outbound streams)
into the SINIT ACK and cookie.

After sending out the SINIT ACK or ABORT, the agent shall take no
further actions; i.e., the existing session, including its current
state; and the corresponding TCB MUST NOT be changed.

Note: Only when a TCB exists and the session is not in a COOKIE WAIT
or SSHUTDOWN ACK SENT state are from or to Tags populated with a
value other than 0. For a normal session INIT (i.e., the agent is in
the CLOSED state), the To Tags MUST be set to 0 (indicating that no
previous TCB existed).

10.2.2 Unexpected SINIT ACK

If an SINIT ACK is received by an agent in any state other than the
COOKIE-WAIT state, the agent should discard the SINIT ACK chunk. An
unexpected SINIT ACK usually indicates the processing of an old or
duplicated SINIT chunk.

10.2.3 Handle a COOKIE ECHO when a TCB Exists

When a COOKIE ECHO chunk is received by an agent in any state for an
existing session (i.e., not in the CLOSED state) the following rules
shall be applied:

1) Compute a MAC as described in step 1 of section 10.1.4,

2) Authenticate the State Cookie as described in step 2 of section
10.1.4,

3) Compare the timestamp in the State Cookie to the current time. If
the State Cookie is older than the lifespan carried in the State
Cookie and the Tags contained in the State Cookie do not match the
current session's Tags, the packet, including the COOKIE ECHO and
any DATA chunks, should be discarded. The agent also MUST transmit an
ERROR chunk with a "Stale Cookie" error cause to the peer agent.

If both Tags in the State Cookie match the Tags of the current
session, consider the State Cookie valid even if the lifespan is
exceeded.

4) If the State Cookie proves to be valid, unpack the TCB into a
temporary TCB.

Leiwm, et al. Expires January 28, 2014 [Page 48]
Internet-Draft MPMTP-AR July 2013

10.2.4 Handle Duplicate COOKIE-ACK

At any state other than COOKIE-ECHOED, an agent should silently
discard a received COOKIE ACK chunk.

10.2.5. Handle Stale COOKIE Error

Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates
one of a number of possible events:

A) The session failed to completely setup before the State Cookie
issued by the sender was processed.

B) An old State Cookie was processed after setup completed.

C) An old State Cookie is received from someone that the receiver is
not interested in having a session with and the ABORT chunk was
lost.

When processing an ERROR chunk with a "Stale Cookie" error cause an
agent should first examine if a session is in the process of being
set up, i.e., the session is in the COOKIE-ECHOED state. In all
cases, if the session is not in the COOKIE-ECHOED state, the ERROR
chunk should be silently discarded.

If the session is in the COOKIE-ECHOED state, the agent may elect one
of the following three alternatives.

1) Send a new INIT chunk to the agent to generate a new State Cookie
and reattempt the setup procedure.

2) Discard the TCB and report to the MPMTP-AR user the inability to
set up the session.

3) Send a new INIT chunk to the agent, adding a Cookie Preservative
parameter requesting an extension to the life time of the State
Cookie. When calculating the time extension, an implementation
SHOULD use the RTT information measured based on the previous
COOKIE ECHO/ERROR exchange, and should add no more than 1 second
beyond the measured RTT, due to long State Cookie life time making
the agent more subject to a replay attack.

10.3 Other Initialization Issues

10.3.1 Selection of Tag Value

Tag values should be selected from the range of 1 to 2**32 -1. It is
very important that the initiate tag value be randomized to help

Leiwm, et al. Expires January 28, 2014 [Page 49]
Internet-Draft MPMTP-AR July 2013

protect against "man in the middle" and "sequence number" attacks.
The methods described in [RFC4086] can be used for the Initiate Tag
randomization. Careful selection of Initiate Tags is also necessary
to prevent old duplicate packets from previous sessions being
mistakenly processed as belonging to the current session.

Moreover, the Tag value used by either agent in a given session MUST
NOT change during the life time of a session. A new Verification Tag
value MUST be used each time the agent tears down and then
reestablishes a session to the same peer.

11. User Data Transfer

Data transmission MUST only happen in the ESTABLISHED,
SHUTDOWNPENDING states.

DATA chunks MUST only be received according to the rules below in
ESTABLISHED, SSHUTDOWN-PENDING, and SSHUTDOWN-SENT. A DATA chunk
received in any other state SHOULD be discarded.

A SACK MUST be processed in ESTABLISHED, and SSHUTDOWN-PENDING. A
SACK in the CLOSED state is out of the blue and SHOULD be processed
according to the rules in section 13.3. A SACK chunk received in any
other state SHOULD be discarded.

An MPMTP-AR receiver MUST be able to receive a minimum of 1500 bytes
in one MPMTP-AR packet. This means that an MPMTP-AR agent MUST NOT
indicate less than 1500 bytes in its initial a_rwnd sent in the SINIT
ACK.

For transmission efficiency, MPMTP-AR defines mechanisms for bundling
of small user messages and fragmentation of large user messages. The
following diagram depicts the flow of user messages through MPMTP-AR.

Leiwm, et al. Expires January 28, 2014 [Page 50]
Internet-Draft MPMTP-AR July 2013

+--------------------------+
| User Messages |
+--------------------------+
MPMTP-AR user ^ |
==================|==|====================================
| v (1)
+---------------------+ +-----------------------+
| MPMTP-AR DATA Chunks| |MPMTP-AR Control Chunks|
+---------------------+ +-----------------------+
^ | ^ |
| v (2) | v (2)
+--------------------------+
| MPMTP-AR packets |
+--------------------------+
MPMTP-AR ^ |
===========================|==|===========================
| v
Packet Transfer Service (e.g., UDP)

Notes: When converting user messages into DATA chunks, an agent will
fragment user messages larger than the current session path MTU into
multiple DATA chunks. The data receiver will normally reassemble the
fragmented message from DATA chunks before delivery to the user (see
section 11.7 for details).

11.1 Transmission of DATA Chunks

This document is specified as if there is a single retransmission
timer per subflow, but implementations MAY have a retransmission
timer for each DATA packet.

The following general rules MUST be applied by the sender for
transmission and/or retransmission of outbound DATA chunks:

A) At any given time, the data sender MUST NOT transmit new data if
its peer's rwnd indicates that the peer has no buffer space (i.e.,
rwnd is 0; see section 11.2.1). However, regardless of the value
of rwnd (including if it is 0), the data sender can always have
one DATA chunk in flight to the receiver if allowed by congestion
window (cwnd). This rule allows the sender to probe for a change
in rwnd that the sender missed due to the SACK's having been lost
in transit from the data receiver to the data sender.

When the receiver's advertised window is zero, this probe is
called a zero window probe. Note that a zero window probe SHOULD
only be sent when all outstanding DATA chunks have been
cumulatively acknowledged and no DATA chunks are in flight. Zero
window probing MUST be supported.

Leiwm, et al. Expires January 28, 2014 [Page 51]
Internet-Draft MPMTP-AR July 2013

Refer to section 11.2 on the receiver behavior when it advertises
a zero window. The sender SHOULD send the first zero window to
probe after 1 RTO when it detects that the receiver has closed its
window and SHOULD increase the probe interval exponentially
afterwards. Also note that the cwnd SHOULD be adjusted according
to section 12.2.1. Zero window probing does not affect the
calculation of cwnd.

The sender MUST also have an algorithm for sending new DATA chunks
to avoid silly window syndrome (SWS) as described in [RFC0813].
The algorithm can be similar to the one described in section
4.2.3.4 of [RFC1122].

However, regardless of the value of rwnd (including if it is 0),
the data sender can always have one DATA chunk in flight to the
receiver if allowed by cwnd. This rule allows the sender to probe
for a change in rwnd that the sender missed due to the SACK having
been lost in transit from the data receiver to the data sender.

B) At any given time, the sender MUST NOT transmit new data to the
receiver if it has cwnd or more bytes of data outstanding to the
receiver.

C) When the time comes for the sender to transmit, before sending new
DATA chunks, the sender MUST first transmit any outstanding DATA
chunks that are marked for retransmission (limited by the current
cwnd).

D) When the time comes for the sender to transmit new DATA chunks,
the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting cwnd
as follows:

if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize +Max.Burst*MTU

Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine.

E) Then, the sender can send out as many new DATA chunks as rule A
and rule B allow.

IMPLEMENTATION NOTE: When the window is full, the sender MAY still
accept send requests from its user, but MUST transmit no more DATA
chunks until some or all of the outstanding DATA chunks are
acknowledged and transmission is allowed by rule A and rule B again.

Whenever a transmission or retransmission is made, the sender MUST

Leiwm, et al. Expires January 28, 2014 [Page 52]
Internet-Draft MPMTP-AR July 2013

start T3-rtx timer. If the timer is already running, the sender MUST
restart the timer if the earliest (i.e., lowest TSN) outstanding DATA
chunk is being retransmitted. Otherwise, the data sender MUST NOT
restart the timer.

When starting or restarting the T3-rtx timer, the timer value must be
adjusted according to the timer rules defined in Sections 11.3.2 and
11.3.3.

Note: The data sender SHOULD NOT use a TSN that is more than 2**31-1
above the beginning TSN of the current send window.

11.2 Acknowledge on Reception of DATA Chunks

The MPMTP-AR agent MUST always acknowledge the reception of each
valid DATA chunk when the DATA chunk received is inside its receive
window.

When the receiver's advertised window is 0, the receiver MUST drop
any new incoming DATA chunk with a TSN larger than the largest TSN
received so far. If the new incoming DATA chunk holds a TSN value
less than the largest TSN received so far, then the receiver SHOULD
drop the largest TSN held for reordering and accept the new incoming
DATA chunk. In either case, if such a DATA chunk is dropped, the
receiver MUST immediately send back a SACK with the current receive
window showing only DATA chunks received and accepted so far. The
dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
not accepted. The receiver MUST also have an algorithm for
advertising its receive window to avoid receiver silly window
syndrome (SWS), as described in [RFC0813]. The algorithm can be
similar to the one described in section 4.2.3.3 of [RFC1122].

The guidelines on delayed acknowledgement algorithm specified in
section 4.2 of [RFC2581] SHOULD be followed. Specifically, an
acknowledgement SHOULD be generated for at least every second packet
(not every second DATA chunk) received, and SHOULD be generated
within 200 ms of the arrival of any unacknowledged DATA chunk. In
some situations, it may be beneficial for an MPMTP-AR transmitter to
be more conservative than the algorithms detailed in this document
allow. However, an MPMTP-AR transmitter MUST NOT be more aggressive
than the following algorithms allow.

An MPMTP-AR receiver MUST NOT generate more than one SACK for every
incoming packet, other than to update the offered window as the
receiving application consumes new data.

IMPLEMENTATION NOTE: The maximum delay for generating an
acknowledgement may be configured by the MPMTP-AR administrator,

Leiwm, et al. Expires January 28, 2014 [Page 53]
Internet-Draft MPMTP-AR July 2013

either statically or dynamically, in order to meet the specific
timing requirement of the protocol being carried.

An implementation MUST NOT allow the maximum delay to be configured
to be more than 500 ms. In other words, an implementation MAY lower
this value below 500 ms but MUST NOT raise it above 500 ms.

Acknowledgements MUST be sent in SACK chunks unless session-level
shutdown was requested by user, in which case an agent MAY send an
acknowledgement in the session-level SSHUTDOWN chunk. A SACK chunk
can acknowledge the reception of multiple DATA chunks.See section
8.3.10 for SACK chunk format. In particular, the MPMTP-AR agent MUST
fill in the Cumulative TSN Ack field to indicate the latest
sequential TSN (of a valid DATA chunk) it has received. Any received
DATA chunks with TSN greater than the value in the Cumulative TSN Ack
field are reported in the Gap Ack Block fields. The MPMTP-AR agent
MUST report as many Gap Ack Blocks as can fit in a single SACK chunk
limited by the current path MTU.

When a packet arrives with duplicate DATA chunk, the agent MUST
immediately send a SACK with no delay. The duplicate TSN number(s)
SHOULD be reported in the SACK as duplicate.

When an agent receives a SACK, it MAY use the duplicate TSN
information to determine if SACK loss is occurring. Further use of
this data is for future study.

The data receiver is responsible for maintaining its receive buffers.
The data receiver SHOULD notify the data sender in a timely manner of
changes in its ability to receive data. How an implementation manages
its receive buffers is dependent on many factors (e.g., operating
system, memory management system, amount of memory, etc.). However,
the data sender strategy defined in section 11.2.1 is based on the
assumption of receiver operation similar to the following:

A) At initialization of the session, the agent tell the peer how much
receive buffer space it has allocated to the session in the SINIT
ACK. The agent sets a_rwnd to this value.

B) As DATA chunks are received and buffered, decrement a_rwnd by the
number of bytes received and buffered. This is, in effect, closing
rwnd at the data sender and restricting the amount of data it can
transmit.

C) As DATA chunks are delivered to the MPMTP-AR user and released
from the receive buffers, increment a_rwnd by the number of bytes.
This is, in effect, opening up rwnd on the data sender and
allowing it to send more data. The data receiver SHOULD NOT

Leiwm, et al. Expires January 28, 2014 [Page 54]
Internet-Draft MPMTP-AR July 2013

increment a_rwnd unless it has released bytes from its receive
buffer. For example, if the receiver is holding fragmented DATA
chunks in a reassembly queue,it should not increment a_rwnd.

D) When sending a SACK, the data receiver SHOULD place the current
value of a_rwnd into the a_rwnd field. The data receiver SHOULD
take into account that the data sender will not retransmit DATA
chunks that are acked via the Cumulative TSN Ack (i.e., will drop
from its retransmit queue).

Under certain circumstances, the data receiver may need to drop DATA
chunks that it has received but hasn't released from its receive
buffers (i.e., delivered to the MPMTP-AR user). These DATA chunks may
have been acked in Gap Ack Blocks. For example, the data receiver may
be holding data in its receive buffers while reassembling a
fragmented user message from its peer when it runs out of receive
buffer space. It may drop these DATA chunks even though it has
acknowledged them in Gap Ack Blocks. If a data receiver drops DATA
chunks, it MUST NOT include them in Gap Ack Blocks in subsequent
SACKs until they are received again via retransmission. In addition,
the agent should take into account the dropped data when calculating
its a_rwnd.

An agent SHOULD NOT revoke a SACK and discard data. Only in extreme
circumstances should an agent use this procedure (such as out of
buffer space). The data receiver should take into account that
dropping data that has been acked in Gap Ack Blocks can result in
suboptimal retransmission strategies in the data sender and thus in
suboptimal performance.

If an agent receives a DATA chunk with no user data (i.e., the Length
field is set to 16), it MUST send an ABORT with error cause set to
"No User Data".

An agent SHOULD NOT send a DATA packet with no user data.

11.2.1 Processing a Received SACK

Each SACK an agent receives contains an a_rwnd value. This value
represents the amount of buffer space the data receiver, at the time
of transmitting the SACK, has left of its total receive buffer space
(as specified in the SINIT/SINIT ACK). Using a_rwnd, Cumulative TSN
Ack, and Gap Ack Blocks, the data sender can develop a representation
of the peer's receive buffer space.

One of the problems the data sender must take into account when
processing a SACK is that a SACK can be received out of order. That
is, a SACK sent by the data receiver can pass an earlier SACK and be

Leiwm, et al. Expires January 28, 2014 [Page 55]
Internet-Draft MPMTP-AR July 2013

received first by the data sender. If a SACK is received out of
order, the data sender can develop an incorrect view of the peer's
receive buffer space.

Since there is no explicit identifier that can be used to detect
out-of-order SACKs, the data sender must use heuristics to determine
if a SACK is new.

An agent SHOULD use the following rules to calculate the rwnd, using
the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in a
received SACK.

A) At the establishment of the session, the agent initializes the
rwnd to the Advertised Receiver Window Credit (a_rwnd) the peer
specified in the SINIT or SINIT ACK.

B) Any time a DATA chunk is transmitted (or retransmitted) to a peer,
the agent subtracts the data size of the chunk from the rwnd of
that peer.

C) Any time a DATA chunk is marked for retransmission, either via
T3-rtx timer expiration (section 11.3.3) or via Fast Retransmit
(section 12.2.4); add the data size of those chunks to the rwnd.

Note: If the implementation is maintaining a timer on each DATA chunk
, then only DATA chunks whose timer expired would be marked for
retransmission.

D) Any time a SACK arrives, the agent performs the following:

i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-oforder
SACK.

ii) Set rwnd equal to the newly received a_rwnd minus the number
of bytes still outstanding after processing the Cumulative TSN
Ack and the Gap Ack Blocks.

iii) If the SACK is missing a TSN that was previously acknowledged
via a Gap Ack Block (e.g., the data receiver reneged on the
data), then consider the corresponding DATA that might be
possibly missing.Count one miss indication towards Fast
Retransmit as described in section 12.2.4, and if no
retransmit timer is running for the subflow to which the DATA
chunk was originally transmitted, then T3-rtx is started for
that destination address.

Leiwm, et al. Expires January 28, 2014 [Page 56]
Internet-Draft MPMTP-AR July 2013

iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery
exitpoint (section 12.2.4), Fast Recovery is exited.

11.3 Management of Retransmission Timer

An MPMTP-AR agent uses a retransmission timer T3-rtx to ensure data
delivery in the absence of any feedback from its peer. The duration
of this timer is referred to as RTO (retransmission timeout).

When an session is multi-path, the agent will calculate a separate
RTO for each different path.

The computation and management of RTO in MPMTP-AR follow closely how
TCP manages its retransmission timer. To compute the current RTO, an
agent maintains two state variables per subflow: SRTT (smoothed
round-trip time) and RTTVAR (round-trip time variation).

11.3.1 RTO Calculation

The rules governing the computation of SRTT, RTTVAR, and RTO are as
follows:

C1)Until an RTT measurement has been made for a packet sent to the
given destination transport address, set RTO to the protocol
arameter 'RTO.Initial'.

C2)When the first RTT measurement R is made, set

SRTT <- R,

RTTVAR <- R/2, and

RTO <- SRTT + 4 * RTTVAR.

C3) When a new RTT measurement R' is made, set

RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|

and

SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'

Note: The value of SRTT used in the update to RTTVAR is its value
before updating SRTT itself using the second assignment.

After the computation, update RTO <- SRTT + 4 * RTTVAR.

C4)When data is in flight and when allowed by rule C5 below, a new

Leiwm, et al. Expires January 28, 2014 [Page 57]
Internet-Draft MPMTP-AR July 2013

RTT measurement MUST be made each round trip. Furthermore, new RTT
measurements SHOULD be made no more than once per round trip for a
given subflow. There are two reasons for this recommendation:
First, it appears that measuring more frequently often does not in
practice yield any significant benefit [ALLMAN99]; second, if
measurements are made more often, then the values of RTO.Alpha and
RTO.Beta in rule C3 above should be adjusted so that SRTT and
RTTVAR still adjust to changes at roughly the same rate (in terms
of how many round trips it takes them to reflect new values) as
they would if making only one measurement per round-trip and using
RTO.Alpha and RTO.Beta as given in rule C3. However, the exact
nature of these adjustments remains a research issue.

C5)Karn's algorithm: RTT measurements MUST NOT be made using packets
that were retransmitted (and thus for which it is ambiguous
whether the reply was for the first instance of the chunk or for a
later instance)

IMPLEMENTATION NOTE: RTT measurements should only be made using a
chunk with TSN r if no chunk with TSN less than or equal to r is
retransmitted since r is first sent.

C6)Whenever RTO is computed, if it is less than RTO.Min seconds then
it is rounded up to RTO.Min seconds. The reason for this rule is
that RTOs that do not have a high minimum value are susceptible to
unnecessary timeouts [ALLMAN99].

C7) A maximum value may be placed on RTO provided it is at least
RTO.max seconds.

There is no requirement for the clock granularity G used for
computing RTT measurements and the different state variables,
other than:

G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR
<-G.

Experience [ALLMAN99] has shown that finer clock granularities (<=100
msec) perform somewhat better than more coarse granularities.

11.3.2 Retransmission Timer Rules

The rules for managing the retransmission timer are as follows:

R1)Every time a DATA chunk is sent to subflow (including a
retransmission), if the T3-rtx timer of that subflow is not
running, start it running so that it will expire after the RTO
of that subflow. The RTO used here is that obtained after any

Leiwm, et al. Expires January 28, 2014 [Page 58]
Internet-Draft MPMTP-AR July 2013

doubling due to revious T3-rtx timer expirations on the
corresponding subflow as discussed in rule E2 below.

R2)Whenever all outstanding data sent to subflow have been
acknowledged, turn off the T3-rtx timer of that subflow.

R3)Whenever a SACK is received that acknowledges the DATA chunk with
the earliest outstanding TSN for that subflow, restart the T3-rtx
timer for that subflow with its current RTO (if there is still
outstanding data on that subflows).

R4)Whenever a SACK is received missing a TSN that was previously
acknowledged via a Gap Ack Block, start the T3-rtx for the subflow
to which the DATA chunk was originally transmitted if it is not
already running.

11.3.3 Handle T3-RTX Expiration

Whenever the retransmission timer T3-rtx expires for a subflow, do
the following:

E1)For the subflow for which the timer expires, adjust its ssthresh
with rules defined in section 12.2.3 and set the cwnd <- MTU.

E2)For the subflow for which the timer expires, set RTO<- RTO * 2
("back off the timer"). The maximum value discussed in rule C7
above (RTO.max) may be used to provide an upper bound to this
doubling operation.

E3)Determine how many of the earliest (i.e., lowest TSN) outstanding
DATA chunks for the subflow for which the T3-rtx has expired will
fit into a single packet, subject to the MTU constraint for the
path corresponding to the subflow to which the retransmission is
being sent (this may be different from the subflow for which the
timer expires; see section 11.4). Call this value K. Bundle and
retransmit those K DATA chunks in a single packet to the
destination agent.

E4)Start the retransmission timer T3-rtx on the subflow to which the
retransmission is sent, if rule R1 above indicates to do so. The\
RTO to be used for starting T3-rtx should be the one for the
subflow to which the retransmission is sent, may be different from
the subflow for which the timer expired (see section 11.4 below).

After retransmitting, once a new RTT measurement is obtained
(which can happen only when new data has been sent and
acknowledged, per rule C5, or for a measurement made from a
HEARTBEAT; see section 11.3), the computation in rule C3 is

Leiwm, et al. Expires January 28, 2014 [Page 59]
Internet-Draft MPMTP-AR July 2013

performed, including the computation of RTO, which may result in
"collapsing" RTO back down after it has been subject to doubling
(rule E2).

Note: Any DATA chunks that were sent to the subflow for which the
T3-rtx timer expired but did not fit in one MTU (rule E3 above)
should be marked for retransmission and sent as soon as cwnd
allows (normally, when a SACK arrives).

F1)Whenever an agent switches from the current subflow to a
different one, the current retransmission timers are left running.
As soon as the agent transmits a packet containing DATA chunk(s)
to the new subflow, start the timer on that subflow, using the RTO
value of the destination address to which the data is being sent,
if rule R1 indicates to do so.

11.4 Stream Identifier and Stream Sequence Number

Every DATA chunk MUST carry a valid stream identifier. If an agent
receives a DATA chunk with an invalid stream identifier, it shall
acknowledge the reception of the DATA chunk following the normal
procedure, immediately send an ERROR chunk with cause set to "Invalid
Stream Identifier", and discard the DATA chunk.

The Stream Sequence Number in all the streams MUST start from 0 when
the session is established. Also, when the Stream Sequence Number
reaches the value 65535 the next Stream Sequence Number MUST be set
to 0.

11.5 Ordered and Unordered Delivery

Within a stream, an agent MUST deliver DATA chunks received with the
U flag set to 0 to the user according to the order of their
Transmission Sequence Number. If DATA chunks arrive out of order of
their Transmission Sequence Number, the agent MUST hold the received
DATA chunks from delivery to the user until they are reordered.

However, an MPMTP-AR agent can indicate that no ordered delivery is
required for a particular DATA chunk transmitted within the stream by
setting the U flag of the DATA chunk to 1.

When an agent receives a DATA chunk with the U flag set to 1, it must
bypass the ordering mechanism and immediately deliver the data to the
user (after reassembly if the user data is fragmented by the data
sender).

This provides an effective way of transmitting "out-of-band" data in
a given subflow. Also, a message can be used as an "unordered" stream

Leiwm, et al. Expires January 28, 2014 [Page 60]
Internet-Draft MPMTP-AR July 2013

by simply setting the U flag to 1 in all DATA chunks sent through
that stream.

IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an
implementation may choose to place the DATA chunk in an outbound
packet that is at the head of the outbound transmission queue if
possible.

The 'Transmission Sequence Number' field in a DATA chunk with U flag
set to 1 has no significance. The sender can fill it with arbitrary
value, but the receiver MUST ignore the field.

Note: When transmitting ordered and unordered data, an agent does not
increment its Transmission Sequence Number when transmitting a DATA
chunk with U flag set to 1.

11.6 Report Gaps in Received DATA TSNs

Upon the reception of a new DATA chunk, an agent shall examine the
continuity of the TSNs received. If the agent detects a gap in the
received DATA chunk sequence, it SHOULD send a SACK with Gap Ack
Blocks immediately. The data receiver continues sending a SACK after
receipt of each MPMTP-AR packet that doesn't fill the gap.

Based on the Gap Ack Block from the received SACK, the agent can
calculate the missing DATA chunks and make decisions on whether to
retransmit them (see section 11.2.1 for details).

Multiple gaps can be reported in one single SACK.

When this session is multipath, the MPMTP-AR agent SHOULD always try
to send the SACK to the sender from default path.

Upon the reception of a SACK, the agent MUST remove all DATA chunks
that have been acknowledged by the SACK's Cumulative TSN Ack from its
transmit queue. The agent MUST also treat all the DATA chunks with
TSNs not included in the Gap Ack Blocks reported by the SACK as
"missing". The number of "missing" reports for each outstanding DATA
chunk MUST be recorded by the data sender in order to make
retransmission decisions. See section 12.2.4 for details.

The maximum number of Gap Ack Blocks that can be reported within a
single SACK chunk is limited by the current path MTU. When a single
SACK cannot cover all the Gap Ack Blocks needed to be reported due to
the MTU limitation, the agent MUST send only one SACK, reporting the
Gap Ack Blocks from the lowest to highest TSNs, within the size limit

Leiwm, et al. Expires January 28, 2014 [Page 61]
Internet-Draft MPMTP-AR July 2013

set by the MTU, and leave the remaining highest TSN numbers
unacknowledged.

11.7 Fragmentation and Reassembly

An agent MAY support fragmentation when sending DATA chunks, but it
MUST support reassembly when receiving DATA chunks. If an agent
supports fragmentation, it MUST fragment a user message if the size
of the user message to be sent causes the outbound MPMTP-AR packet
size to exceed the current MTU. If an implementation does not support
fragmentation of outbound user messages, the agent MUST return an
error to its user and not attempt to send the user message.

Note: If an implementation that supports fragmentation makes
available to its user a mechanism to turn off fragmentation, it may
do so. However, in so doing, it MUST react just like an
implementation that does NOT support fragmentation, i.e., it MUST
reject sends that exceed the current Path MTU (P-MTU).

If its session uses multipath, the agent shall choose a size no
larger than the session Path MTU. The session Path MTU is the
smallest Path MTU of all subflow.

Note: Once a message is fragmented, it cannot be re-fragmented.
Instead, if the PMTU has been reduced, then IP fragmentation must be
used. Please see section 12.3 for details of PMTU discovery.

When determining when to fragment, the MPMTP-AR implementation MUST
take into account the MPMTP-AR packet header as well as the DATA
chunk header(s). The implementation MUST also take into account the
space required for a SACK chunk if bundling a SACK chunk with the
DATA chunk.

Fragmentation takes the following steps:

1) The data sender MUST break the user message into a series of DATA
chunks such that each chunk plus MPMTP-AR overhead and UDP header
fits into an IP datagram smaller than or equal to the session Path
MTU.

2) The transmitter MUST then assign, in sequence, a separate TSN to
each of the DATA chunks in the series. If the user indicates that
the user message is to be delivered using unordered delivery, then
the U flag of each DATA chunk of the user message MUST be set to
1.

3) The transmitter MUST also set the B/E bits of the first DATA chunk
in the series to '10', the B/E bits of the last DATA chunk in the

Leiwm, et al. Expires January 28, 2014 [Page 62]
Internet-Draft MPMTP-AR July 2013

series to '01', and the B/E bits of all other DATA chunks in the
series to '00'.

An agent MUST recognize fragmented DATA chunks by examining the B/E
bits in each of the received DATA chunks, and queue the fragmented
DATA chunks for reassembly.

Note: If the data receiver runs out of buffer space while still
waiting for more fragments to complete the reassembly of the message,
it should dispatch part of its inbound message through a partial
delivery API, freeing some of its receive buffer space so that the
rest of the message may be received.

12. Congestion Control

Congestion control is one of the basic functions in MPMTP-AR. For
some applications, it may be likely that adequate resources will be
allocated to MPMTP-AR traffic to ensure prompt delivery of
time-critical data -- thus, it would appear to be unlikely, during
normal operations, that transmissions encounter severe congestion
conditions. However, MPMTP-AR must operate under adverse operational
conditions, which can develop upon partial network failures or
unexpected traffic surges. In such situations, MPMTP-AR must follow
correct congestion control steps to recover from congestion quickly
in order to get data delivered as soon as possible. In the absence of
network congestion, these preventive congestion control algorithms
should show no impact on the protocol performance.

IMPLEMENTATION NOTE: As far as its specific performance requirements
are met, an implementation is always allowed to adopt a more
conservative congestion control algorithm than the one defined below.

The congestion control algorithms used by MPMTP-AR are based on
[RFC2581]. This section describes how the algorithms defined in
[RFC2581] are adapted for use in MPMTP-AR. We first list differences
in protocol designs between TCP and MPMTP-AR, and then describe
MPMTP-AR's congestion control scheme. The description will use the
same terminology as in TCP congestion control whenever appropriate.
MPMTP-AR congestion control is always applied to both the entire
session and individual subflow.

12.1 MPMTP-AR Differences from TCP Congestion Control

Gap Ack Blocks in the MPMTP-AR SACK carry the same semantic meaning
as the TCP SACK. TCP considers the information carried in the SACK as
advisory information only. MPMTP-AR considers the information carried
in the Gap Ack Blocks in the SACK chunk as advisory. In MPMTP-AR, any
DATA chunk that has been acknowledged by SACK, including DATA that

Leiwm, et al. Expires January 28, 2014 [Page 63]
Internet-Draft MPMTP-AR July 2013

arrived at the receiving end out of order, is not considered fully
delivered until the Cumulative TSN Ack Point passes the TSN of the
DATA chunk (i.e., the DATA chunk has been acknowledged by the
Cumulative TSN Ack field in the SACK). Consequently, the value of
cwnd controls the amount of outstanding data, rather than (as in the
case of non-SACK TCP) the upper bound between the highest
acknowledged sequence number and the latest DATA chunk that can be
sent within the congestion window. MPMTP-AR SACK leads to different
implementations of Fast Retransmit and Fast Recovery than non-SACK
TCP. As an example, see [FALL96].

The biggest difference between MPMTP-AR and TCP, however, is
multipath. MPMTP-AR is designed to establish robust communication
sessuib between two endpoints more than one path. The treatment here
of congestion control for multihpath receivers is new with MPMTP-AR
and may require refinement in the future. The current algorithms make
the following assumptions:

1) The sender usually uses the same subflows until being instructed
by the user to switch to other subflows; however, MPMTP-AR may
switch load to other subflows in the event a path is marked
inactive (see section 13.2).

2) The sender keeps a separate congestion control parameter set for
each subflow it use. The parameters should decay if the subflow is
not used for a long enough time period. The sender SHOULD adjust
the entire session congestion control parameter according to all
subflows' congestion control parameter; the specific rules will be
refined in the future.

3) For each subflow, an agent does slow start upon the first
transmission to that address.

12.2 MPMTP-AR Slow-Start and Congestion Avoidance

The slow-start and congestion avoidance algorithms MUST be used by an
agent to control the amount of data being injected into the network.
The congestion control in MPMTP-AR is employed in regard not only to
the session, but also to an individual subflow. In some situations,
it may be beneficial for an MPMTP-AR sender to be more conservative
than the algorithms allow; however, an MPMTP-AR sender MUST NOT be
more aggressive than the following algorithms allow.

Like TCP, an MPMTP-AR agent uses the following three control
variables to regulate its transmission rate.

1) Receiver advertised window size (rwnd, in bytes), which is set by
the receiver based on its available buffer space for incoming

Leiwm, et al. Expires January 28, 2014 [Page 64]
Internet-Draft MPMTP-AR July 2013

packets.

Note: This variable is kept on the entire session.

2) Congestion control window (cwnd, in bytes), which is adjusted by
the sender based on observed network conditions.

Note: This variable is maintained on a per-subflow basis.

3) Slow-start threshold (ssthresh, in bytes), which is used by the
sender to distinguish slow-start and congestion avoidance phases.

Note: This variable is maintained on a per-subflow basis.

MPMTP-AR also requires one additional control variable,
partial_bytes_acked, which is used during congestion avoidance phase
to facilitate cwnd adjustment.

Unlike TCP, an MPMTP-AR sender MUST keep a set of these control
variables cwnd, ssthresh, and partial_bytes_acked for EACH subflow.
Only one rwnd is kept for the whole session.

12.2.1 Slow-Start

Beginning data transmission into a network with unknown conditions or
after a sufficiently long idle period requires MPMTP-AR to probe the
network to determine the available capacity. The slow-start algorithm
is used for this purpose at the beginning of a transfer, or after
repairing loss detected by the retransmission timer.

1) The initial cwnd before DATA transmission or after a sufficiently
long idle period MUST be set to min(4*MTU, max (2*MTU, 4488
bytes)).

2) The initial cwnd after a retransmission timeout MUST be no more
than 1*MTU.

3) The initial value of ssthresh MAY be arbitrarily high (for
example, implementations MAY use the size of the receiver
advertised window).

4) Whenever cwnd is greater than zero, the agent is allowed to have
cwnd bytes of data outstanding on that subflow.

5) When cwnd is less than or equal to ssthresh, an MPMTP-AR agent
MUST use the slow-start algorithm to increase cwnd only if the
current congestion window is being fully utilized, an incoming
SACK advances the Cumulative TSN Ack Point, and the data sender is

Leiwm, et al. Expires January 28, 2014 [Page 65]
Internet-Draft MPMTP-AR July 2013

not in Fast Recovery. Only when these three conditions are met can
the cwnd be increased; otherwise, the cwnd MUST not be increased.
If these conditions are met, then cwnd MUST be increased by,
atmost, the lesser of 1) the total size of the previously
outstanding DATA chunk(s) acknowledged, and 2) the destination's
path MTU. This upper bound protects against the ACK-Splitting
attack outlined in [SAVAGE99].

In instances where its session is multipath, if an agent receives
a SACK that advances its Cumulative TSN Ack Point, then it should
update its cwnd (or cwnds). However, if the received SACK does
not advance the Cumulative TSN Ack Point, the agent MUST NOT
adjust the cwnd of any subflow.

Because an agent's cwnd is not tied to its Cumulative TSN Ack
Point, as duplicate SACKs come in, even though they may not
advance the Cumulative TSN Ack Point an agent can still use them
to clock out new data. That is, the data newly acknowledged by the
SACK diminishes the amount of data now in flight to less than
cwnd, and so the current, unchanged value of cwnd now allows new
data to be sent. On the other hand, the increase of cwnd must be
tied to the Cumulative TSN Ack Point advancement as specified
above. Otherwise, the duplicate SACKs will not only clock out new
data, but also will adversely clock out more new data than what
has just left the network, during a time of possible congestion.

6) When the agent does not transmit data on a given subflow, the cwnd
of the subflow should be adjusted to max(cwnd/2, 4*MTU) per RTO.

12.2.2 Congestion Avoidance

When cwnd is greater than ssthresh, cwnd should be incremented by
1*MTU per RTT if the sender has cwnd or more bytes of data
outstanding for the corresponding subflow.

In practice, an implementation can achieve this goal in the following
way:

1) partial_bytes_acked is initialized to 0.

2) Whenever cwnd is greater than ssthresh, upon each SACK arrival
that advances the Cumulative TSN Ack Point, increase
partial_bytes_acked by the total number of bytes of all new chunks
in this subflow acknowledged in that SACK including chunks
acknowledged by the new Cumulative TSN Ack and by Gap Ack Blocks.

3) When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes

Leiwm, et al. Expires January 28, 2014 [Page 66]
Internet-Draft MPMTP-AR July 2013

of data outstanding (i.e., before arrival of the SACK, flightsize
was greater than or equal to cwnd), increase cwnd by MTU, and
reset partial_bytes_acked to (partial_bytes_acked - cwnd).

4) Same as in the slow start, when the sender does not transmit DATA
on a given transport address, the cwnd of the transport address
should be adjusted to max(cwnd / 2, 4*MTU) per RTO.

5) When all of the data transmitted by the sender has been
acknowledged by the receiver, partial_bytes_acked is initialized
to 0.

12.2.3 Congestion Control

Upon detection of packet losses from SACK (see section 12.2.4), an
agent should do the following:

ssthresh = max(cwnd/2, 4*MTU)

cwnd = ssthresh

partial_bytes_acked = 0

Basically, a packet loss causes cwnd to be cut in half.

When the T3-rtx timer expires on a subflow, MPMTP-AR should perform
slow start by:

ssthresh = max(cwnd/2, 4*MTU)

cwnd = 1*MTU

and ensure that no more than one MPMTP-AR packet will be in flight
for that subflow until the agent receives acknowledgement for
successful delivery of data to that subflow.

12.2.4 Fast Retransmit on Gap Reports

In the absence of data loss, an agent performs delayed
acknowledgement. However, whenever an agent notices a hole in the
arriving TSN sequence, it SHOULD start sending a SACK back every time
a packet arrival carrying data until the hole is filled.

Whenever an agent receives a SACK that indicates that some TSNs are
missing, it SHOULD wait for two further miss indications (via
subsequent SACKs for a total of three missing reports) on the same
TSNs before taking action with regard to Fast Retransmit.

Leiwm, et al. Expires January 28, 2014 [Page 67]
Internet-Draft MPMTP-AR July 2013

Miss indications SHOULD follow the HTNA (Highest TSN Newly
Acknowledged) algorithm. For each incoming SACK, miss indications are
incremented only for missing TSNs prior to the highest TSN newly
acknowledged in the SACK. A newly acknowledged DATA chunk is one not
previously acknowledged in a SACK. If an agent is in Fast Recovery
and a SACK arrives that advances the Cumulative TSN Ack Point, the
miss indications are incremented for all TSNs reported missing in the
SACK.

When the third consecutive miss indication is received for a TSN(s),
the data sender shall do the following:

1) Mark the DATA chunk(s) with three miss indications for
retransmission.

2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
subflow(es) to which the missing DATA chunks were last sent,
according to the formula described in section 12.2.3.

3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the subflow to which the packet
is being sent. Call this value K. Retransmit those K DATA chunks
in a single packet. When a Fast Retransmit is being performed, the
sender SHOULD ignore the value of cwnd and SHOULD NOT delay
retransmission for this single packet.

4) Restart the T3-rtx timer only if the last SACK acknowledged the
lowest outstanding TSN number sent to that subflow, or the agent
is retransmitting the first outstanding DATA chunk sent to that
subflow.

5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent Fast Retransmit. Those TSNs marked for
retransmission due to the Fast-Retransmit algorithm that did not
fit in the sent datagram carrying K other TSNs are also marked as
ineligible for a subsequent Fast Retransmit. However, as they are
marked for retransmission they will be retransmitted later on as
soon as cwnd allows.

6) If not in Fast Recovery, enter Fast Recovery and mark the highest
outstanding TSN as the Fast Recovery exit point. When a SACK
acknowledges all TSNs up to and including this exit point, Fast
Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
SHOULD NOT change for any path due to a subsequent Fast Recovery
event (i.e., one SHOULD NOT reduce the cwnd further due to a
subsequent Fast Retransmit).

Leiwm, et al. Expires January 28, 2014 [Page 68]
Internet-Draft MPMTP-AR July 2013

Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in section 12.2.1 and
section 12.2.2 must be applied first.

A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increases for each
consecutive SACK reporting the TSN hole. After reaching 3 and
starting the Fast-Retransmit procedure, the counter resets to 0.
Because cwnd in MPMTP-AR indirectly bounds the number of outstanding
TSN's, the effect of TCP Fast Recovery is achieved automatically with
no adjustment to the congestion control window size.

12.3 Path MTU Discovery

[RFC4821], [RFC1981], and [RFC1191] specify "Packetization Layer Path
MTU Discovery", whereby an agent maintains an estimate of the maximum
transmission unit (MTU) along a given Internet path and refrains from
sending packets along that path that exceed the MTU, other than
occasional attempts to probe for a change in the Path MTU (PMTU).
[RFC4821] is thorough in its discussion of the MTU discovery
mechanism and strategies for determining the current end-to-end MTU
setting as well as detecting changes in this value.

An agent SHOULD apply these techniques, and SHOULD do so on a
per-path basis.

There are two important MPMTP-AR-specific points regarding Path MTU
discovery:

1) MPMTP-AR session can span multiple paths. An agent MUST maintain
separate MTU estimates for each path.

2) The sender should track an session PMTU that will be the smallest
PMTU discovered for all paths. When fragmenting messages into
multiple parts this session PMTU should be used to calculate the
size of each fragment. This will allow retransmissions to be
seamlessly sent to an alternate path without encountering IP
fragmentation.

13. Fault Management

13.1 Endpoint Failure Detection

An agent shall keep a counter on the total number of consecutive
retransmissions to its peer (this includes retransmissions to all
paths). If the value of this counter exceeds the limit indicated in
the protocol parameter 'Session.Max.Retrans', the agent shall

Leiwm, et al. Expires January 28, 2014 [Page 69]
Internet-Draft MPMTP-AR July 2013

consider the peer agent unreachable and shall stop transmitting any
more data to it (and thus the session enters the CLOSED state). In
addition, the agent MAY report the failure to the MPMTP-AR user and
optionally report back all outstanding user data remaining in its
outbound queue. The session is automatically closed when the peer
agent becomes unreachable.

The counter shall be reset each time a DATA chunk sent to that peer
agent is acknowledged (by the reception of a SACK) from the peer
agent.

13.2 Path Failure Detection

When the session is multipath, an agent should keep an error counter
for each path.

Each time the T3-rtx timer expires on any path, the error counter of
that path will be incremented. When the value in the error counter
exceeds the protocol parameter 'Path.Max.Retrans' of that path, the
agent should mark the destination transport address as inactive, and
a notification SHOULD be sent to the MPMTP-AR user.

When an outstanding TSN is acknowledged, the agent shall clear the
error counter of the path to which the DATA chunk was last sent. When
the session is multipath and the last chunk sent to it was a
retransmission to an alternate path, there exists an ambiguity as to
whether or not the acknowledgement should be credited to the address
of the last chunk sent. However, this ambiguity does not seem to
bear any significant consequence to MPMTP-AR behavior. If this
ambiguity is undesirable, the transmitter may choose not to clear the
error counter if the last chunk sent was a retransmission.

Note: When configuring the MPMTP-AR agent, the user should avoid
having the value of 'Session.Max.Retrans' larger than the summation
of the 'Path.Max.Retrans' of all paths for the remote agent.
Otherwise, all paths may become inactive while the agent still
considers the peer agent reachable. When this condition occurs, how
MPMTP-AR chooses to function is implementation specific.

When the primary path is marked inactive (due to excessive
retransmissions, for instance), the sender MAY automatically transmit
new packets to alternate paths if they exist and are active. If more
than one alternate path is active when the primary path is marked
inactive, the sender may switch the load allocated to the inactive
path to one or more active path.

13.3 Handle "Out of the Blue" Packets

Leiwm, et al. Expires January 28, 2014 [Page 70]
Internet-Draft MPMTP-AR July 2013

An MPMTP-AR packet is called an "out of the blue" (OOTB) packet if it
is correctly formed, but the receiver is not able to identify the
session to which this packet belongs.

The receiver of an OOTB packet MUST do the following:

1) If the OOTB packet is to or from a non-unicast address, a receiver
SHOULD silently discard the packet. Otherwise,

2) If the OOTB packet contains an ABORT chunk, the receiver MUST
silently discard the OOTB packet and take no further action.
Otherwise,

3) If the packet contains an SINIT chunk with a To Tag set to '0',
process it as described in section 10.1.

4) If the packet contains a COOKIE ECHO chunk, process it as
described in section 10.1.

5) If the packet contains a SSHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SSHUTDOWN
COMPLETE.

6) If the packet contains a SSHUTDOWN COMPLETE chunk, the receiver
should silently discard the packet and take no further action.
Otherwise,

7) If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK, the
MPMTP-AR packet should be silently discarded. Otherwise,

8) The receiver should respond to the sender of the OOTB packet with
an ABORT. When sending the ABORT, the receiver of the OOTB packet
MUST fill in the To Tag field of the outbound packet with the
value found in the From Tag field of the OOTB packet. After
sending this ABORT, the receiver of the OOTB packet shall discard
the OOTB packet and take no further action.

13.4 Verification Tag

The Tag rules defined in this section apply when sending or receiving
MPMTP-AR packets The rules for sending and receiving MPMTP-AR packets
containing one of these chunk types are discussed separately in
section 13.4.1.

When sending an MPMTP-AR packet, the agent MUST fill in the Tag
fields of the outbound packet with the tag value in the Initiate Tag
parameter of the SINIT or SINIT ACK received from its peer.

Leiwm, et al. Expires January 28, 2014 [Page 71]
Internet-Draft MPMTP-AR July 2013

When receiving an MPMTP-AR packet, the agent MUST ensure that the
value in the To Tag field of the received MPMTP-AR packet matches its
own tag. If the received Verification Tag value does not match the
receiver's own tag value, the receiver shall silently discard the
packet and shall not process it any further except for those cases
listed in section 13.4.1 below.

13.4.1 Exceptions in Verification Tag Rules

A) Rules for packet carrying SINIT:
The sender MUST set the To Tag of the packet to 0.
When an agent receives an MPMTP-AR packet with the To Tag set to
0, it should verify that the packet contains an INIT chunk.
Otherwise, the receiver MUST silently discard the packet.

B) Rules for packet carrying ABORT:
The agent MUST always fill in the To Tag field of the outbound
packet with the destination agent's tag value, if it is known.

If the ABORT is sent in response to an OOTB packet, the agent
MUST follow the procedure described in section 13.3.

The receiver of an ABORT MUST accept the packet if the To Tag
field of the packet matches its own tag. Otherwise, the receiver
MUST silently discard the packet and take no further action.

C) Rules for packet carrying SSHUTDOWN COMPLETE:
When sending a SSHUTDOWN COMPLETE, if the receiver of the
SSHUTDOWN ACK has a TCB, then the To tag MUST be used. Only where
no TCB exists should the sender use the From Tag from the
SSHUTDOWN ACK.

The receiver of a SSHUTDOWN COMPLETE shall accept the packet if
the To Tag field of the packet matches its own tag. Otherwise, the
receiver MUST silently discard the packet and take no further
action. An agent MUST ignore the SSHUTDOWN COMPLETE if it is not
in the SSHUTDOWN ACK SENT state.

D) Rules for packet carrying a COOKIE ECHO
When sending a COOKIE ECHO, the agent MUST use the value of the
From Tag received in theSINIT ACK.

The receiver of a COOKIE ECHO follows the procedures in section
10.

E) Rules for packet carrying a SSHUTDOWN ACK
If the receiver is in COOKIE ECHOED or COOKIE WAIT state the
procedures in section 13.3 SHOULD be followed; in other words, it

Leiwm, et al. Expires January 28, 2014 [Page 72]
Internet-Draft MPMTP-AR July 2013

should be treated as an Out Of The Blue packet.

14. Termination of Session

An agent should terminate its session when it exits from service. A
session can be terminated by either abort or session-level shutdown.
An abort of a session is abortive by definition in that any data
pending of the session is discarded and not delivered to the peer. A
session-level shutdown is considered a graceful close where all data
in queue by all subflow is delivered to the respective peers. When
agent performs a session-level shutdown, the agent will stop
accepting new data from its MPMTP-AR user; if the agent is a sender,
it only delivers data in all subflow queues at the time of sending
the SHUTDOWN chunk.

14.1 Abort of a Session

When one agent decides to abort an existing session, it MUST send an
ABORT chunk to its peer agent. The sender MUST fill in the peer's Tag
in the outbound packet.

An agent MUST NOT respond to any ABORT chunk (also see section 13.3).

An agent receiving an ABORT MUST apply the special Tag check rules
described in section 13.4.1.

After checking the Tag, the receiving agent MUST remove the session
from its record and SHOULD report the termination to MPMTP-AR user.
If a User-Initiated Abort error cause is present in the ABORT chunk,
the Abort Reason SHOULD be made available to the MPMTP-AR user.

14.2 Shutdown of a Session

Using the session-level SSHUTDOWN, the MPMTP-AR user in a session can
gracefully close a session. This will allow all outstanding DATA
chunks to be delivered before the subflows terminate. According to
the initiator, it includes sender-initialized and
receiver-initialized.

Upon receipt of the SSHUTDOWN primitive from MPMTP-AR user:

For sender-initialized: The agent enters the SSHUTDOWN-PENDING state
and remains there until all outstanding data has been acknowledged by
its peer. The agent accepts no new data from user, but retransmits
data to the peer agent if necessary to fill gaps. Once all its
outstanding data has been acknowledged, the agent shall send a
SSHUTDOWN chunk. It shall then start the T2-shutdown timer and enter
the SSHUTDOWN-SENT state. If the timer expires, the agent must resend

Leiwm, et al. Expires January 28, 2014 [Page 73]
Internet-Draft MPMTP-AR July 2013

the SSHUTDOWN.

For receiver-initialized: Upon receipt of the SSHUTDOWN primitive
from MPMTP-AR user, the agent enters the SSHUTDOWN-PENDING state and
remains there until all data has been received correctly. Once all
data has been received correctly, the agent shall send a SSHUTDOWN
chunk. It shall then start the T2-shutdown timer and enter the
SSHUTDOWN-SENT state. If the timer expires, the agent must resend the
SSHUTDOWN.

The rules in section 11.3 MUST be followed to determine the proper
timer value for T2-shutdown.

An agent should limit the number of retransmissions of the SHUTDOWN
chunk to the protocol parameter 'Session.Max.Retrans'. If this
threshold is exceeded, the agent should destroy the TCB and MUST
report the peer agent unreachable to the MPMTP-AR user (and thus the
session enters the CLOSED state).

Upon reception of the SSHUTDOWN, the agent shall enter the
SSHUTDOWN-RECEIVED state.

Once an agent has reached the SSHUTDOWN-RECEIVED state, it should
discard subsequent SSHUTDOWN chunks.

The sender of the SSHUTDOWN MAY also start an overall guard timer
'T5-shutdown-guard' to bound the overall time for the shutdown
sequence. At the expiration of this timer, the sender SHOULD abort
the session by sending an ABORT chunk. If the 'T5-shutdown-guard'
timer is used, it SHOULD be set to the recommended value of 5 times
'RTO.Max'.

The SSHUTDOWN receiver MUST send a SSHUTDOWN ACK and start a T2-
shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If
the timer expires, the agent must resend the SSHUTDOWN ACK.

The sender of the SSHUTDOWN ACK should limit the number of
retransmissions of the SSHUTDOWN ACK chunk to the protocol parameter
'Session.Max.Retrans'. If this threshold is exceeded, the agent
should destroy the TCB and may report the peer agent unreachable to
the MPMTP-AR user (and thus the session enters the CLOSED state).

Upon the receipt of the SSHUTDOWN ACK, the SSHUTDOWN sender shall
stop the T2-shutdown timer, send a SSHUTDOWN COMPLETE chunk to its
peer, and remove all record of the session.

Upon reception of the SSHUTDOWN COMPLETE chunk, the agent will verify
that it is in the SSHUTDOWN-ACK-SENT state; if it is not, the chunk

Leiwm, et al. Expires January 28, 2014 [Page 74]
Internet-Draft MPMTP-AR July 2013

should be discarded. If the agent is in the SSHUTDOWN-ACK-SENT state,
the agent should stop the T2-shutdown timer and remove all
acknowledge of the session (and thus the session enters the CLOSED
state).

An agent SHOULD ensure that all its outstanding DATA chunks have been
sent or received correctly before initiating the shutdown procedure.

Note: Receipt of an SINIT with the same source assigned to an agent
but with a different Tag indicates the initialization of a separate
session.

The sender of the SINIT or COOKIE ECHO should respond to the receipt
of a SSHUTDOWN ACK with a stand-alone SSHUTDOWN COMPLETE in an
MPMTP-AR packet with the Tag field of its common header set to the
same tag that was received in the SSHUTDOWN ACK packet. This is
considered an Out of the Blue packet as defined in section 13.3. The
sender of the SINIT lets T1-init continue running and remains in the
COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init timer expiration
will cause the SINIT or COOKIE chunk to be retransmitted and thus
start a new session.

If a SSHUTDOWN is received in the COOKIE-WAIT or COOKIE ECHOED state,
the SSHUTDOWN chunk SHOULD be silently discarded.

In sender-initialized scenario: An agent should reject any new data
request from its user if it is in the SSHUTDOWN-PENDING,
SSHUTDOWN-SENT state. If an agent is in the SSHUTDOWN-ACK-SENT state
and receives an SINIT chunk (e.g., if the SHUTDOWN COMPLETE was lost)
with Validation Tag that belong to this session, it should discard
the SINIT chunk and retransmit the SSHUTDOWN ACK chunk.

15. Security Consideration
<TBD>
All drafts are required to have a security considerations section.
See RFC 3552 [8] for a guide.

16. Reference

16.1 Normal Reference
[1] W. Lei, W. Zhang, S. Liu, "A Framework of Multipath Transport
System Based on Application-Level Relay ", Internet draft,
IETF, July 2013.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

16.2 Information Reference

Leiwm, et al. Expires January 28, 2014 [Page 75]
Internet-Draft MPMTP-AR July 2013

[3] Randall R. Stewart, "Stream Control Transmission Protocol",
RFC4960, September 2007.

[4] A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar,
"Architectural Guidelines for Multipath TCP Development",
RFC6182, March 2011.

[5] J. Postel, "User Datagram Protocol", Augest 1980.

[6] M. Allman, V. Paxson, W. Stevens,"TCP Congestion Control", April
1999.

[7] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.

[8] E. Rescorla, B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", RFC3552, July 2003.

Authors' Addresses

Weimin Lei
Northeastern University
Institute of Communication and Information System
College of Information Science and Engineering
Shenyang, China, 110819
P. R. China

Phone: +86-24-8368-3048
Email: leiweimin@ise.neu.edu.cn

Shaowei Liu
Northeastern University
Institute of Communication and Information System
College of Information Science and Engineering
Shenyang, China, 110819
P. R. China

Email: liushaowei.ise.neu@gmail.com
liu_nongfu@163.com

Wei Zhang
Northeastern University
Institute of Communication and Information System
College of Information Science and Engineering
Shenyang, China, 110819
P. R. China

Email: zhangwei1@ise.neu.edu.cn

Leiwm, et al. Expires January 28, 2014 [Page 76]

Multipath Message Transport Protocol Based on Application-level Relay (MPMTP-AR) draft-leiwm-tsvwg-mpmtp-ar-00

Multipath Message Transport Protocol Based on Application-level Relay (MPMTP-AR)
draft-leiwm-tsvwg-mpmtp-ar-00