Multipath Message Transport Protocol Based on Application-level Relay (MPMTP-AR)
draft-leiwm-tsvwg-mpmtp-ar-02
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 | 2014-07-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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) |
draft-leiwm-tsvwg-mpmtp-ar-02
Network Working Group W. Lei
Internet-Draft S.Liu
Intended Status: Experimental W. Zhang
Expires: Jan 26, 2015 Northeastern University
Jul 26, 2014
Multipath Message Transport Protocol Based on
Application-level Relay (MPMTP-AR)
draft-leiwm-tsvwg-mpmtp-ar-02
Abstract
Multipath transmission is an important way to improve the quality of
service for message transport. This document defines a multipath
message transmission protocol, which is a special application profile
of multipath transport protocol suite defined in Multipath Transport
System Based on Application-level Relay (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 July 26, 2014 .
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Leiwm, et al Expires Jan 26, 2015 [Page 1]
Internet-Draft MPMTP-AR Jan 2014
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 Jan 26, 2015 [Page 2]
Internet-Draft MPMTP-AR Jan 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 11
7. MPMTP-AR Agent Behavior . . . . . . . . . . . . . . . . . . . . 12
7.1 Consistent Behaviors . . . . . . . . . . . . . . . . . . . . 12
7.1.1 Path management . . . . . . . . . . . . . . . . . . . . 12
7.2 Modified Behaviors . . . . . . . . . . . . . . . . . . . . . 12
7.2.1 Stream 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 . . . . . . . . . . . . . . . . . . . . 15
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2 MPMTP-AR Packet Header . . . . . . . . . . . . . . . . . . . 16
8.3 Fixed Header Fields of MPMTP-AR Data Packet . . . . . . . . 16
8.4 Fixed Header Fields of MPMTP-AR Control Packet . . . . . . 18
8.4.1 Sender Report (SR) . . . . . . . . . . . . . . . . . . . 19
8.4.2 Receiver Report (RR) . . . . . . . . . . . . . . . . . . 20
8.4.3 Keep Alive (KA) . . . . . . . . . . . . . . . . . . . . 21
8.4.4 Session Initiation (SINIT) . . . . . . . . . . . . . . . 21
8.4.5 Session Initiation Acknowledgement (SINIT ACK) . . . . . 23
8.4.6 State Cookie (COOKIE ECHO) . . . . . . . . . . . . . . . 24
8.4.7 Cookie Acknowledgement (COOKIE ACK) . . . . . . . . . . 25
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.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) . . . . . . . . . . . . . . . . 31
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 Jan 26, 2015 [Page 3]
Internet-Draft MPMTP-AR Jan 2014
10.1 Normal Establishment of a Session . . . . . . . . . . . . . 42
10.1.1 Handle Path Parameters . . . . . . . . . . . . . . . . 43
10.1.2 Generating State Cookie . . . . . . . . . . . . . . . . 44
10.1.3 State Cookie Processing . . . . . . . . . . . . . . . . 45
10.1.4 State Cookie Authentication . . . . . . . . . . . . . . 45
10.1.5 Open Subflow . . . . . . . . . . . . . . . . . . . . . 46
10.2 Handle Duplication or Unexpected Issue . . . . . . . . . . 46
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 . . . . . . . . . . . . . . . . . 47
10.2.3 Handle a COOKIE ECHO when a TCB Exists . . . . . . . . 47
10.2.4 Handle Duplicate COOKIE-ACK . . . . . . . . . . . . . . 47
10.2.5. Handle Stale COOKIE Error . . . . . . . . . . . . . . 48
10.3 Other Initialization Issues . . . . . . . . . . . . . . . . 48
11. User Data Transfer . . . . . . . . . . . . . . . . . . . . . . 48
11.1 Transmission of DATA Chunks . . . . . . . . . . . . . . . . 49
11.2 Acknowledge on Reception of DATA Chunks . . . . . . . . . . 51
11.2.1 Processing a Received SACK . . . . . . . . . . . . . . 54
11.3 Management of Retransmission Timer . . . . . . . . . . . . 55
11.3.1 RTO Calculation . . . . . . . . . . . . . . . . . . . . 55
11.3.2 Retransmission Timer Rules . . . . . . . . . . . . . . 57
11.3.3 Handle T3-RTX Expiration . . . . . . . . . . . . . . . 57
11.4 Stream Identifier and Stream Sequence Number . . . . . . . 58
11.5 Ordered and Unordered Delivery . . . . . . . . . . . . . . 58
11.6 Report Gaps in Received DATA TSNs . . . . . . . . . . . . . 59
11.7 Fragmentation and Reassembly . . . . . . . . . . . . . . . 60
12. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 61
12.1 MPMTP-AR Differences from TCP Congestion Control . . . . . 61
12.2 MPMTP-AR Slow-Start and Congestion Avoidance . . . . . . . 62
12.2.1 Slow-Start . . . . . . . . . . . . . . . . . . . . . . 63
12.2.2 Congestion Avoidance . . . . . . . . . . . . . . . . . 64
12.2.3 Congestion Control . . . . . . . . . . . . . . . . . . 65
12.2.4 Fast Retransmit on Gap Reports . . . . . . . . . . . . 65
12.3 Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 67
13. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 67
13.1 Endpoint Failure Detection . . . . . . . . . . . . . . . . 67
13.2 Path Failure Detection . . . . . . . . . . . . . . . . . . 68
13.3 Handle "Out of the Blue" Packets . . . . . . . . . . . . . 68
14. Termination of Session . . . . . . . . . . . . . . . . . . . . 69
14.1 Abort of a Session . . . . . . . . . . . . . . . . . . . . 69
14.2 Shutdown of a Session . . . . . . . . . . . . . . . . . . . 70
15. Security Consideration . . . . . . . . . . . . . . . . . . . . 71
15.1. Security Objectives . . . . . . . . . . . . . . . . . . . 71
15.2. MPMTP-AR Responses to Potential Threats . . . . . . . . . 72
15.2.1. Countering Insider Attacks . . . . . . . . . . . . . 72
15.2.2. Protecting Confidentiality . . . . . . . . . . . . . 72
15.2.3. Protecting against Blind Denial-of-Service Attacks . 73
15.2.3.1. Flooding . . . . . . . . . . . . . . . . . . . . 73
Leiwm, et al Expires Jan 26, 2015 [Page 4]
Internet-Draft MPMTP-AR Jan 2014
15.2.3.2. Blind Masquerade . . . . . . . . . . . . . . . . 74
15.2.3.3. Improper Monopolization of Services . . . . . . . 75
16. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 75
16.1 Normal Reference . . . . . . . . . . . . . . . . . . . . . 75
16.2 Information Reference . . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
Leiwm, et al Expires Jan 26, 2015 [Page 5]
Internet-Draft MPMTP-AR Jan 2014
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.
Part 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 transmission are
the following:
1) To increase the efficiency of the resource usage, and thus
Leiwm, et al Expires Jan 26, 2015 [Page 6]
Internet-Draft MPMTP-AR Jan 2014
increase the network capacity available to agent.
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) Session ID: The unique identify of the session.
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,
Leiwm, et al Expires Jan 26, 2015 [Page 7]
Internet-Draft MPMTP-AR Jan 2014
in 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.
4. Goals
Using MPMTP-AR for reliable transmission, original data belonging to
a session is divided multiple subflows and carried over multiple
Leiwm, et al Expires Jan 26, 2015 [Page 8]
Internet-Draft MPMTP-AR Jan 2014
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 reliability 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 among user agent, relay and controller.
Application-level relay-based multipath transport framework core
defines three logical entities, and also defines a relay service
control protocol named OpenPath protocol in control plane to manage
relay paths, and a profile of multipath transport protocol suite in
data plane to facilitate multipath data transport. Based on this
framework, we define MPMTP-AR as a profile to support reliable
transmission.
Leiwm, et al Expires Jan 26, 2015 [Page 9]
Internet-Draft MPMTP-AR Jan 2014
(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 message
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 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 at the beginning, or may be upgraded
from the default path. The connective session establishment mechanism
uses a four-way-handshake, the middle two legs of which are allowed
to carry authentication.
The sender distributes the original data across the active paths
based on a scheduling strategy up to send buffer, and encapsulates
Leiwm, et al Expires Jan 26, 2015 [Page 10]
Internet-Draft MPMTP-AR Jan 2014
them as special structure defined in MPTP profile before delivery.
During the transmission, the sender adjust send buffer in line with
the receiver buffer of the receiver. The receiver combines the
received subflows to recreate the original data by transmission
sequence number contrained in header.
In order to notify the sender of the reception, the receiver sends
selective acknowledgement of data packet to the sender. It contains
information about receive buffer, correct reception, out of order
packets, and duplicate reception. The sender will sends error data
packets immediately and wait for out of order packets for a special
timer which can be set by application. The retransmission may choose
the best performance path, or may be different from the path for
which the 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,
assigned data to paths. The receiver reassembles the received data
chunks using a reorder buffer to retrieve the reconstructed data
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
Leiwm, et al Expires Jan 26, 2015 [Page 11]
Internet-Draft MPMTP-AR Jan 2014
As we can see from the fig.2, relay path is unidirection and default
path is bidirection. All packets from receiver to sender via default
path.
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
reliable transmission. Those functions include session and path
management, flow partitioning and scheduling, subflow packaging,
sequenced delivery, stream recombination, subflow reporting, and
selection acknowledgement and congestion avoidance.
Compare with the agent behavior introduced 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 Stream recombination
The receiver collects receiving statistics for per-subflow by Path-ID
and Subflow-Specific sequence number. Then decapsulates packet and
puts data chunks in per stream receive buffer by Stream ID and orders
by Stream Sequence Number.
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.
Leiwm, et al Expires Jan 26, 2015 [Page 12]
Internet-Draft MPMTP-AR Jan 2014
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.
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 characteristic, such as
bandwidth, delay, jitter, and error rate, we should assign data
chunks to subflows according to their capacity to increase
transmission quality. Since the sender monitor active path quality,
such as bandwidth information, the path transmission statistics (e.g.
RTT, loss-rate, delay etc.), so the sender assigned more data chunks
to the subflow which has a better performance. Data chunks
distribution 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 transmission statistic
(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 MPMTP-AR data
packets. Specific packet format will be described in section 8. Then
the sender dispatches MPMTP-AR 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 a unique session ID. It is generated by the sender and receiver
respectively at the establishment of the session.
Leiwm, et al Expires Jan 26, 2015 [Page 13]
Internet-Draft MPMTP-AR Jan 2014
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 MPMTP-AR chunk field. Details of different chunks
are defined in section 8.
7.3.4 Subflow reporting
As mentioned in MPTS-AR, both the sender and the receiver need to
send subflow report to monitor the transmission quality. In this
section, 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.
The sender must inform the receiver how to reassemble the data. In
order to achieve this, the receiver uses stream sequence number to
mark location of chunk in a stream.
One-to-one relationship is between path and subflow. MPMTP-AR uses
path identity to distinguish multiple paths. This ensures the path to
Leiwm, et al Expires Jan 26, 2015 [Page 14]
Internet-Draft MPMTP-AR Jan 2014
be unique in the whole network. The sender 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 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 sender the 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 window in line
to receive window.
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 be
refined once more information is available.
8. MPMTP-AR Packet Format
This section defines MPMTP-AR packet format to meet the requirement
of behaviors described in section 7.
8.1 Overview
Leiwm, et al Expires Jan 26, 2015 [Page 15]
Internet-Draft MPMTP-AR Jan 2014
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 profile suit that is not complete, reliable delivery
requirement of upper application programs can be relised in specific
application profile defined in this document named MPMPT-AR.
In order to support agent behavior illustrated in section 7, we
define MPMTP-AR packet format containing data and control packet.
8.2 MPMTP-AR Packet Header
MPMTP-AR header inherits from MPTP packet Header, including eight
octet-length common header. The eight octets except for the first
four bits correspond to different fields for MPMTP-AR data packets
and MPMTP-AR control packets.
8.3 Fixed Header Fields of MPMTP-AR Data Packet
Fixed header of MPMTP-AR data packet is defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=1|T|P| AMT | TOS | Rsvd | SSSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmission Sequence Number |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
\ \
/ Data Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning:
version (V): 2 bits
This field identifies the version of MPTP. The version defined by
this document is one (1).
MPMTP-AR packet type (T): 1 bit
This field identifies the type of a MPMTP-AR packet. If the MPMTP-
AR packet type bit is set, this packet is a MPMTP-AR data packet;
Leiwm, et al Expires Jan 26, 2015 [Page 16]
Internet-Draft MPMTP-AR Jan 2014
otherwise, this packet is a MPMTP-AR control packet.
padding (P): 1 bit
If the padding bit is set, the packet contains one or more
additional padding octets at the end which are not part of the
payload. The last octet of the padding contains a count of how
many padding octets should be ignored, including itself. Padding
may be needed by some encryption algorithms with fixed block
sizes.
Application-specific MPMTP-AR type (AMT): 4 bits
This field identifies the type of application-specific MPTP that
this packet format conforms to. In this document, AMT = 2.
type of service (TOS): 4 bits
This field, similar to TOS field in internet packet header, is
specified along the abstract parameters precedence, delay,
throughput, and reliability. These abstract parameters embody the
delivery requirements of upper application programs. The values of
these abstract parameters should be specified in application-
specific MPTP documents.
Precedence: An independent measure of the importance of the
payload data.
Delay: Prompt delivery is important for the payload data with this
indication.
Throughput: High data rate is important for the payload data with
this indication.
Reliability: A higher level of effort to ensure delivery is
important for the payload data with this indication.
Rsvd: 4 bits
These 4 bits are reserved, which can be used and described in
application-specific MPTP documents.
Subflow-Specific Sequence Number (SSSN):
This field is the sequence of the MPMTP-AR data packet in the
subflow. Each subflow has its own strictly monotonically
increasing sequence number space.
Path Identifier:
This field is the identifier of the path that the MPMTP-AR packet
is associated with. For a relay path, the path identifier is
globally unique; for the default path, the path identifier is
fixed to zero.
Leiwm, et al Expires Jan 26, 2015 [Page 17]
Internet-Draft MPMTP-AR Jan 2014
Session ID:
This field is the identifier of the session, to which this data
pcaket belongs to.
Transmission Sequence Number (TSN): 32 bits
This field is the sequence of the MPMTP-AR data packet in the
original data. The original flow has the unique strictly
monotonically increasing sequence number space.
Data Chunk: variable length
This is the payload 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 Fixed Header Fields of MPMTP-AR Control Packet
Fixed header of MPMTP-AR control packet is defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=1|T|P| AMT | CT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
\ \
/ Control Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of V, T, P, AMT, Path Identifier, and Session ID have the
same meaning as those fields in MPMTP-AR data packet. Other fields
have the following meaning:
MPMTP-AR control packet type (CT): 8 bits
This field identifies the type of MPMTP-AR control packet.
Length: 8 bits
This field is the length of the encapsulated control data after
the MPMTP-AR header in byte length.
Chunk: (variable length)
This field contains data or control information.
Control data is packed into chunks. Following sections from 8.4.1 to
Leiwm, et al Expires Jan 26, 2015 [Page 18]
Internet-Draft MPMTP-AR Jan 2014
8.4.19 describe the format of control chunks.
The values of CT are defined as follows:
+---------------+---------------------------------------------------+
| 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 Jan 26, 2015 [Page 19]
Internet-Draft MPMTP-AR Jan 2014
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.
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. 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
Leiwm, et al Expires Jan 26, 2015 [Page 20]
Internet-Draft MPMTP-AR Jan 2014
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
no SR has been 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Leiwm, et al Expires Jan 26, 2015 [Page 21]
Internet-Draft MPMTP-AR Jan 2014
---------------------------------------------------------------
| Fixed Parameters | Status |
---------------------------------------------------------------
| Number of Outbound Subflow | Mandatory |
---------------------------------------------------------------
| Maximum Stream Number (MSN) | Mandatory |
---------------------------------------------------------------
| Initial TSN | Mandatory |
---------------------------------------------------------------
| Variable Parameters | Optional |
---------------------------------------------------------------
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
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 is
invalid.
Note: A receiver of an SINIT with the NOS value set to 0 SHOULD
abort the session.
MSN (Maximum Stream Number): 16 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 TSN field.
1) Optional/Variable-Length Parameters in INIT
The format of optional parameters in the INIT ACK chunk is shown
below:
Leiwm, et al Expires Jan 26, 2015 [Page 22]
Internet-Draft MPMTP-AR Jan 2014
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Leiwm, et al Expires Jan 26, 2015 [Page 23]
Internet-Draft MPMTP-AR Jan 2014
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 NIS value set to 0
SHOULD destroy the session discarding its TCB.
MSN (Maximum Stream Number): 16 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
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.
Leiwm, et al Expires Jan 26, 2015 [Page 24]
Internet-Draft MPMTP-AR Jan 2014
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.
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 and to acknowledge
Leiwm, et al Expires Jan 26, 2015 [Page 25]
Internet-Draft MPMTP-AR Jan 2014
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 by 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
Leiwm, et al Expires Jan 26, 2015 [Page 26]
Internet-Draft MPMTP-AR Jan 2014
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
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.
Leiwm, et al Expires Jan 26, 2015 [Page 27]
Internet-Draft MPMTP-AR Jan 2014
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 |
----------
then the parameter part of the SACK MUST be constructed as follows
(assuming the new a_rwnd is set to 1500 by the sender):
Leiwm, et al Expires Jan 26, 2015 [Page 28]
Internet-Draft MPMTP-AR Jan 2014
+--------------------------------+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path Number (N): 32 bits (unsigned integer)
This field indicates how many subflows will be closed.
Leiwm, et al Expires Jan 26, 2015 [Page 29]
Internet-Draft MPMTP-AR Jan 2014
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 Jan 26, 2015 [Page 30]
Internet-Draft MPMTP-AR Jan 2014
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk inform the sender to close path indicated 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 used to close the session. The ABORT chunk may
contain Cause Parameters to inform the receiver about the reason of
the abort.
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.
See section 8.4.17 for Error Cause definitions.
8.4.17 Operation Error (ERROR)
Leiwm, et al Expires Jan 26, 2015 [Page 31]
Internet-Draft MPMTP-AR Jan 2014
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 Jan 26, 2015 [Page 32]
Internet-Draft MPMTP-AR Jan 2014
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
Cause of error: Missing Mandatory Parameter: indicates that one or
Leiwm, et al Expires Jan 26, 2015 [Page 33]
Internet-Draft MPMTP-AR Jan 2014
more mandatory parameters are missing in a received SINIT or 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Jan 26, 2015 [Page 34]
Internet-Draft MPMTP-AR Jan 2014
4) Out of Resource
Cause of error: Out of Resource
Indicating the sender that session 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 completing 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
Leiwm, et al Expires Jan 26, 2015 [Page 35]
Internet-Draft MPMTP-AR Jan 2014
Cause of error: Unrecognized Parameters
This error cause is returned 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 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
Leiwm, et al Expires Jan 26, 2015 [Page 36]
Internet-Draft MPMTP-AR Jan 2014
an ERROR chunk followed with the retransmitted SSHUTDOWN 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=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
Leiwm, et al Expires Jan 26, 2015 [Page 37]
Internet-Draft MPMTP-AR Jan 2014
identification, max received transmission sequence number and
correctly received data chunk number.
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 sends last PATH
FEEDBACK.
Current Feedback Time: 32 bits (unsigned integer)
This field marks the time at which the receiver sends this PATH
FEEDBACK.
Received Max TSN: 16 bits (unsigned integer)
This field indicates the max TSN of data chunk received from the
path marked by Path ID field.
Received Data Chunks Number: 16 bits (unsigned integer)
This field indicates the number of data chunk received from the
path marked by 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 Jan 26, 2015 [Page 38]
Internet-Draft MPMTP-AR Jan 2014
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Timestamp: 32 bits
This field records the send time of this chunk form the initiator
of this chunk.
The receiver of this chunk delivers it to the sender via default path
as soon as received and do not change anything. 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.
----- -------- (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
| | start sinit timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv SINIT ACK
Leiwm, et al Expires Jan 26, 2015 [Page 39]
Internet-Draft MPMTP-AR Jan 2014
| | -----------------
| | send COOKIE ECHO
| | stop sinit timer
| | start cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+
|
|
/--------+--------
[SSHUTDOWN] /
-----------------| |
ack outstanding | |
DATA chunks | |
v |
+---------+ |
|SSHUTDOWN| | rcv SSHUTDOWN
|PENDING | |------------------
+---------+ | check outstanding
| | DATA chunks
No more outstanding| |
-------------------| |
send SSHUTDOWN | |
start sshutdown | |
timer v v
+---------+ +-----------+
(4) |SSHUTDOWN| | SSHUTDOWN | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| |
rcv SSHUTDOWN ACK | |No more outstanding
-------------------| |-------------------
stop sshutdown timer| |send SSHUTDOWN ACK
send SSHUTDOWN | |start shutdown timer
COMPLETE delete TCB | |
| |
| |
| |
| +-----------+
Leiwm, et al Expires Jan 26, 2015 [Page 40]
Internet-Draft MPMTP-AR Jan 2014
| | 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 (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 ESTABLISHMENT state, if the agent is the receiver of DATA
chunk and receives [SSHUTDOWN] from application or SSHUTDOWN from
the peer agent, it should check outstanding DATA chunk before
sends a response.
5) In the SSHUTDOWN-SENT state, the agent MUST response any received
control chunks without delay.
6) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any
new send requests from its SCTP user.
7) In the SSHUTDOWN-RECEIVED state, the agent MUST leave this state
when all data in queue is ordered.
8) In the SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any
Leiwm, et al Expires Jan 26, 2015 [Page 41]
Internet-Draft MPMTP-AR Jan 2014
new send requests from its SCTP user.
The CLOSED state is used to indicate that a session 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
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
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.
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 in a COOKIE ECHO
chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED
Leiwm, et al Expires Jan 26, 2015 [Page 42]
Internet-Draft MPMTP-AR Jan 2014
state.
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.
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. It may also notify its ULP about the successful
establishment of the association with a Communication Up
notification.
An agent MUST send the SINIT ACK to the agent from which it received
the SINIT.
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/inbound subflow and maximum stream
number (MSN) it wishes to use in the session.
Leiwm, et al Expires Jan 26, 2015 [Page 43]
Internet-Draft MPMTP-AR Jan 2014
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 local 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 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 when
the State Cookie created, and the lifespan of the State Cookie, along
with all the information necessary for it to establish the session.
The following steps SHOULD be taken to generate the State Cookie:
1) Create session TCB using information from both the received SINIT
and the outgoing SINIT 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 SINIT 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
Leiwm, et al Expires Jan 26, 2015 [Page 44]
Internet-Draft MPMTP-AR Jan 2014
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 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).
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 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.
4) 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.
5) 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
Leiwm, et al Expires Jan 26, 2015 [Page 45]
Internet-Draft MPMTP-AR Jan 2014
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 notify the peer path information.
When an agent receives a SubINIT from another agent with which it
associates an session, it shall take the following actions:
1) Check subflow parameter and session information;
2) Send response. If it is valid, the receiver sends SubINIT 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 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,
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.
Leiwm, et al Expires Jan 26, 2015 [Page 46]
Internet-Draft MPMTP-AR Jan 2014
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. Parameters for
the agent SHOULD be copied from the existing parameters of the
session (e.g., number of outbound streams) and be inserted 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.
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 Session ID contained in the State Cookie do not
match the current session's Session ID, the packet should be
discarded. The agent also MUST transmit an ERROR chunk with a
"Stale Cookie" error cause to the peer agent.
4) If the State Cookie proves to be valid, unpack the TCB into a
temporary TCB.
10.2.4 Handle Duplicate COOKIE-ACK
At any state other than COOKIE-ECHOED, an agent should silently
discard a received COOKIE ACK chunk.
Leiwm, et al Expires Jan 26, 2015 [Page 47]
Internet-Draft MPMTP-AR Jan 2014
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 SINIT 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 SINIT 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
<TBC>
11. User Data Transfer
Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN-
PENDING states.
DATA chunks MUST only be received according to the rules below in
ESTABLISHED, SSHUTDOWN-PENDING, and SSHUTDOWN-SENT. A DATA chunk
Leiwm, et al Expires Jan 26, 2015 [Page 48]
Internet-Draft MPMTP-AR Jan 2014
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.
+--------------------------+
| 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).
Figure 3: Illustration of User Data Transfer
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.
Leiwm, et al Expires Jan 26, 2015 [Page 49]
Internet-Draft MPMTP-AR Jan 2014
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.
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].
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
Leiwm, et al Expires Jan 26, 2015 [Page 50]
Internet-Draft MPMTP-AR Jan 2014
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 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
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
Leiwm, et al Expires Jan 26, 2015 [Page 51]
Internet-Draft MPMTP-AR Jan 2014
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,
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 notify the peer the
Leiwm, et al Expires Jan 26, 2015 [Page 52]
Internet-Draft MPMTP-AR Jan 2014
number of receive buffer space allocated to the session by 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
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.
Leiwm, et al Expires Jan 26, 2015 [Page 53]
Internet-Draft MPMTP-AR Jan 2014
11.2.1 Processing a Received SACK
Each SACK the 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
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-of-
order SACK.
Leiwm, et al Expires Jan 26, 2015 [Page 54]
Internet-Draft MPMTP-AR Jan 2014
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
subflow.
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-subflows, the agent will calculate a
separate RTO for each subflow.
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 subflow, set RTO to the protocol parameter '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'|
Leiwm, et al Expires Jan 26, 2015 [Page 55]
Internet-Draft MPMTP-AR Jan 2014
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
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
Leiwm, et al Expires Jan 26, 2015 [Page 56]
Internet-Draft MPMTP-AR Jan 2014
(<=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
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.
E4)Start the retransmission timer T3-rtx on the subflow to which the
Leiwm, et al Expires Jan 26, 2015 [Page 57]
Internet-Draft MPMTP-AR Jan 2014
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
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 to
the new subflow, start the timer on that subflow, using the RTO
value of the subflow 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
Leiwm, et al Expires Jan 26, 2015 [Page 58]
Internet-Draft MPMTP-AR Jan 2014
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
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 unordered data, an agent does not increment
its Transmission Sequence Number.
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 uses 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.
Leiwm, et al Expires Jan 26, 2015 [Page 59]
Internet-Draft MPMTP-AR Jan 2014
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
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 subflows.
Note: Once a message is fragmented, it cannot be refragmented.
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
Leiwm, et al Expires Jan 26, 2015 [Page 60]
Internet-Draft MPMTP-AR Jan 2014
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
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 to 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
Leiwm, et al Expires Jan 26, 2015 [Page 61]
Internet-Draft MPMTP-AR Jan 2014
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
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
session 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 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.
2) For each subflow, an agent does slow start upon the first
transmission to that subflow.
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
packets.
Leiwm, et al Expires Jan 26, 2015 [Page 62]
Internet-Draft MPMTP-AR Jan 2014
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, 4380
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
not in Fast Recovery. Only when these three conditions are met can
the cwnd be increased; otherwise, the cwnd MUST not be increased.
Leiwm, et al Expires Jan 26, 2015 [Page 63]
Internet-Draft MPMTP-AR Jan 2014
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
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).
Leiwm, et al Expires Jan 26, 2015 [Page 64]
Internet-Draft MPMTP-AR Jan 2014
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 select 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.
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
Leiwm, et al Expires Jan 26, 2015 [Page 65]
Internet-Draft MPMTP-AR Jan 2014
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
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, subject to constraint of the path MTU
of the subflow to which the packet is being sent. When a Fast
Retransmit is being performed, the sender SHOULD ignore the value
of cwnd and SHOULD NOT delay retransmission for this 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).
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
Leiwm, et al Expires Jan 26, 2015 [Page 66]
Internet-Draft MPMTP-AR Jan 2014
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 retransmission 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
retransmission to its peer (this includes retransmission to all
paths). If the value of this counter exceeds the limit indicated in
the protocol parameter 'Session.Max.Retrans', the agent shall
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.
Leiwm, et al Expires Jan 26, 2015 [Page 67]
Internet-Draft MPMTP-AR Jan 2014
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
retransmission, 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
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
Leiwm, et al Expires Jan 26, 2015 [Page 68]
Internet-Draft MPMTP-AR Jan 2014
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 a COOKIE ECHO chunk, process it as
described in section 10.1.
4) If the packet contains a SSHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SSHUTDOWN
COMPLETE.
5) If the packet contains a SSHUTDOWN COMPLETE chunk, the receiver
should silently discard the packet and take no further action.
Otherwise,
6) If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK, the
MPMTP-AR packet should be silently discarded. Otherwise,
7) The receiver should respond to the sender of the OOTB packet with
an ABORT. After sending this ABORT, the receiver of the OOTB
packet shall discard the OOTB packet and take no further action.
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 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 SSHUTDOWN 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.
An agent MUST NOT respond to any ABORT chunk (also see section 13.3).
After checking the Session ID, 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.
Leiwm, et al Expires Jan 26, 2015 [Page 69]
Internet-Draft MPMTP-AR Jan 2014
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 session 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
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 SSHUTDOWN
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'.
Leiwm, et al Expires Jan 26, 2015 [Page 70]
Internet-Draft MPMTP-AR Jan 2014
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 agent shall stop the T2-
shutdown timer, send a SSHUTDOWN COMPLETE chunk to its peer, and
remove all record of the session.
After receiving the SSHUTDOWN COMPLETE chunk, the agent will verify
that it is in the SSHUTDOWN-ACK-SENT state; if it is not, the chunk
should be discarded; otherwise, 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 sending SSHUTDOWN.
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. 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 SSHUTDOWN COMPLETE was lost),
it should discard the SINIT chunk and retransmit the SSHUTDOWN ACK
chunk.
15. Security Consideration
15.1. Security Objectives
As a common transport protocol designed to reliably carry time-
sensitive user messages, such as billing or signaling messages for
telephony services, between two networked endpoints, MPMTP-AR has the
Leiwm, et al Expires Jan 26, 2015 [Page 71]
Internet-Draft MPMTP-AR Jan 2014
following security objectives.
- availability of reliable and timely data transport services
- integrity of the user-to-user information carried by MPMTP-AR
15.2. MPMTP-AR Responses to Potential Threats
MPMTP-AR may potentially be used in a wide variety of risk
situations. It is important for operators of systems running MPMTP-AR
to analyse their particular situations and decide on the appropriate
counter- measures.
Operators of systems running MPMTP-AR should consult [RFC2196] for
guidance in securing their site.
15.2.1. Countering Insider Attacks
The principles of [RFC2196] should be applied to minimize the risk of
theft of information or sabotage by insiders. Such procedures
include publication of security policies, control of access at the
physical, software, and network levels, and separation of services.
15.2.2. Protecting Confidentiality
In most cases, the risk of breach of confidentiality applies to the
signaling data payload, not to the MPMTP-AR or lower-layer protocol
overheads. If that is true, encryption of the MPMTP-AR user data
only might be considered. As with the supplementary checksum
service, user data encryption MAY be performed by the MPMTP-AR user
application. Alternately, the user application MAY use an
implementation-specific API to request that the IP Encapsulating
Security Payload (ESP) [RFC4303] be used to provide confidentiality
and integrity.
Particularly for mobile users, the requirement for confidentiality
might include the masking of IP addresses and ports. In this case,
ESP SHOULD be used instead of application-level confidentiality. If
ESP is used to protect confidentiality of MPMTP-AR traffic, an ESP
cryptographic transform that includes cryptographic integrity
protection MUST be used, because if there is a confidentiality threat
there will also be a strong integrity threat.
Whenever ESP is in use, application-level encryption is not generally
required.
Regardless of where confidentiality is provided, the Internet Key
Exchange Protocol version 2 (IKEv2) [RFC4306] SHOULD be used for key
Leiwm, et al Expires Jan 26, 2015 [Page 72]
Internet-Draft MPMTP-AR Jan 2014
management.
Operators should consult [RFC4301] for more information on the
security services available at and immediately above the Internet
Protocol layer.
15.2.3. Protecting against Blind Denial-of-Service Attacks
A blind attack is one where the attacker is unable to intercept or
otherwise see the content of data flows passing to and from the
target MPMTP-AR node. Blind denial-of-service attacks may take the
form of flooding, masquerade, or improper monopolization of services.
15.2.3.1. Flooding
The objective of flooding is to cause loss of service and incorrect
behavior at target systems through resource exhaustion, interference
with legitimate transactions, and exploitation of buffer-related
software bugs. Flooding may be directed either at the MPMTP-AR node
or at resources in the intervening IP Access Links or the Internet.
Where the latter entities are the target, flooding will manifest
itself as loss of network services, including potentially the breach
of any firewalls in place.
In general, protection against flooding begins at the equipment
design level, where it includes measures such as:
- avoiding commitment of limited resources before determining that
the request for service is legitimate.
- giving priority to completion of processing in progress over the
acceptance of new work.
- identification and removal of duplicate or stale queued requests
for service.
- not responding to unexpected packets sent to non-unicast
addresses.
Network equipment should be capable of generating an alarm and log if
a suspicious increase in traffic occurs. The log should provide
information such as the identity of the incoming link and source
address(es) used, which will help the network or MPMTP-AR system
operator to take protective measures. Procedures should be in place
for the operator to act on such alarms if a clear pattern of abuse
emerges.
The design of MPMTP-AR is resistant to flooding attacks, particularly
Leiwm, et al Expires Jan 26, 2015 [Page 73]
Internet-Draft MPMTP-AR Jan 2014
in its use of a four-way startup handshake, its use of a cookie to
defer commitment of resources at the responding MPMTP-AR node until
the handshake is completed, and its use of a Session ID to prevent
insertion of extraneous packets into the flow of an established
session.
The IP Authentication Header and Encapsulating Security Payload might
be useful in reducing the risk of certain kinds of denial-of-service
attacks.
15.2.3.2. Blind Masquerade
Masquerade can be used to deny service in several ways:
- by tying up resources at the target MPMTP-AR node to which the
impersonated node has limited access. For example, the target
node may by policy permit a maximum of one MPMTP-AR session with
the impersonated MPMTP-AR node. The masquerading attacker may
attempt to establish an session purporting to come from the
impersonated node so that the latter cannot do so when it requires
it.
- by deliberately allowing the impersonation to be detected, thereby
provoking counter-measures that cause the impersonated node to be
locked out of the target MPMTP-AR node.
- by interfering with an established session by inserting
extraneous content such as a SSHUTDOWN request.
MPMTP-AR reduces the risk of blind masquerade attacks through IP
spoofing by use of the four-way startup handshake. Because the
initial exchange is memory-less, no lockout mechanism is triggered by
blind masquerade attacks. In addition, the SINIT ACK containing the
State Cookie is transmitted back to the IP address from which it
received the SINIT. Thus, the attacker would not receive the SINIT
ACK containing the State Cookie. MPMTP-AR protects against insertion
of extraneous packets into the flow of an established session by use
of the Verification Session ID.
Logging of received SINIT requests and abnormalities such as
unexpected SINIT ACKs might be considered as a way to detect patterns
of hostile activity. However, the potential usefulness of such
logging must be weighed against the increased MPMTP-AR startup
processing it implies, rendering the MPMTP-AR node more vulnerable to
flooding attacks. Logging is pointless without the establishment of
operating procedures to review and analyze the logs on a routine
basis.
Leiwm, et al Expires Jan 26, 2015 [Page 74]
Internet-Draft MPMTP-AR Jan 2014
15.2.3.3. Improper Monopolization of Services
Attacks under this heading are performed openly and legitimately by
the attacker. They are directed against fellow users of the target
MPMTP-AR node or of the shared resources between the attacker and the
target node. Possible attacks include the opening of a large number
of associations between the attacker's node and the target, or
transfer of large volumes of information within a legitimately
established session.
Policy limits should be placed on the number of associations per
adjoining MPMTP-AR node. MPMTP-AR user applications should be
capable of detecting large volumes of illegitimate or "no-op"
messages within a given session and either logging or terminating the
session as a result, based on local policy.
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
[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.
Leiwm, et al Expires Jan 26, 2015 [Page 75]
Internet-Draft MPMTP-AR Jan 2014
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
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 Jan 26, 2015 [Page 76]