idnits 2.17.1 draft-leiwm-tsvwg-mpmtp-ar-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 461 has weird spacing: '...st from agent...' == Line 972 has weird spacing: '... The part o...' == Line 1663 has weird spacing: '...of data recei...' == Line 2217 has weird spacing: '...packets emit...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. If these conditions are met, then cwnd MUST be increased by, atmost, the lesser of 1) the total size of the previously outstanding DATA packet(s) acknowledged, and 2) the destination's path MTU. This upper bound protects against the ACK-Splitting attack outlined in [SAVAGE99]. -- The document date (Jan 24, 2017) is 2647 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 162 looks like a reference -- Missing reference section? '4' on line 178 looks like a reference -- Missing reference section? '6' on line 181 looks like a reference -- Missing reference section? '3' on line 192 looks like a reference -- Missing reference section? '2' on line 211 looks like a reference -- Missing reference section? '7' on line 226 looks like a reference -- Missing reference section? '5' on line 595 looks like a reference -- Missing reference section? 'ABORT' on line 1702 looks like a reference -- Missing reference section? 'Session' on line 1708 looks like a reference -- Missing reference section? 'SSHUTDOWN' on line 1802 looks like a reference -- Missing reference section? 'RFC2104' on line 1983 looks like a reference -- Missing reference section? 'RFC4086' on line 1955 looks like a reference -- Missing reference section? 'RFC0813' on line 2257 looks like a reference -- Missing reference section? 'RFC1122' on line 2258 looks like a reference -- Missing reference section? 'RFC2581' on line 2720 looks like a reference -- Missing reference section? 'ALLMAN99' on line 2492 looks like a reference -- Missing reference section? 'FALL96' on line 2742 looks like a reference -- Missing reference section? 'SAVAGE99' on line 2829 looks like a reference -- Missing reference section? 'RFC4821' on line 2984 looks like a reference -- Missing reference section? 'RFC1981' on line 2979 looks like a reference -- Missing reference section? 'RFC1191' on line 2979 looks like a reference -- Missing reference section? 'RFC2196' on line 3228 looks like a reference -- Missing reference section? 'RFC4303' on line 3242 looks like a reference -- Missing reference section? 'RFC4306' on line 3257 looks like a reference -- Missing reference section? 'RFC4301' on line 3260 looks like a reference Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Lei 3 Internet-Draft S.Liu 4 Intended Status: Experimental W. Zhang 5 Expires: Jul 24, 2017 Northeastern University 6 Jan 24, 2017 8 Multipath Message Transport Protocol Based on 9 Application-level Relay (MPMTP-AR) 10 draft-leiwm-tsvwg-mpmtp-ar-07 12 Abstract 14 Multipath transmission is regarded as an effective way to improve the 15 quality of service of data delivery. This document defines a 16 multipath message transport protocol based on application level relay 17 (MPMTP-AR), which is a special profile of multipath transport 18 protocol suite defined in Multipath Transport System Based on 19 Application-level Relay (MPTS-AR). MPMTP-AR provides reliable data 20 delivery service over multiple paths. This document discusses related 21 message format and mechanism to support MPMTP-AR. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute working 30 documents as Internet-Drafts. The list of current Internet-Drafts is 31 at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on Jul 24, 2017. 40 Copyright and License Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 10 62 7. MPMTP-AR Agent Behavior . . . . . . . . . . . . . . . . . . . . 11 63 7.1 Consistent Behaviors . . . . . . . . . . . . . . . . . . . . 11 64 7.1.1 Path management . . . . . . . . . . . . . . . . . . . . 11 65 7.2 Modified Behaviors . . . . . . . . . . . . . . . . . . . . . 11 66 7.2.1 Subflow recombination . . . . . . . . . . . . . . . . . 11 67 7.3 Additional Behaviors . . . . . . . . . . . . . . . . . . . . 12 68 7.3.1 Session management . . . . . . . . . . . . . . . . . . . 12 69 7.3.2 Flow partitioning and scheduling . . . . . . . . . . . . 12 70 7.3.3 Subflow packaging . . . . . . . . . . . . . . . . . . . 12 71 7.3.4 Subflow reporting . . . . . . . . . . . . . . . . . . . 13 72 7.4 New Behaviors . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.4.1 Sequenced Delivery . . . . . . . . . . . . . . . . . . . 13 74 7.4.2 Acknowledgement and Congestion Avoidance . . . . . . . . 14 75 8. MPMTP-AR Packet Format . . . . . . . . . . . . . . . . . . . . 14 76 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.2 MPMTP-AR Packet Header . . . . . . . . . . . . . . . . . . . 15 78 8.3 Fixed Header Fields of MPMTP-AR Data Packet . . . . . . . . 15 79 8.4 Fixed Header Fields of MPMTP-AR Control Packet . . . . . . 17 80 8.4.1 Sender Report (SR) . . . . . . . . . . . . . . . . . . . 19 81 8.4.2 Receiver Report (RR) . . . . . . . . . . . . . . . . . . 20 82 8.4.3 Keep Alive (KA) . . . . . . . . . . . . . . . . . . . . 21 83 8.4.4 Session Initiation (SINIT) . . . . . . . . . . . . . . . 21 84 8.4.5 Session Initiation Acknowledgement (SINIT ACK) . . . . . 23 85 8.4.6 State Cookie (COOKIE ECHO) . . . . . . . . . . . . . . . 24 86 8.4.7 Cookie Acknowledgement (COOKIE ACK) . . . . . . . . . . 25 87 8.4.8 Subflow INIT Request (SubINIT) . . . . . . . . . . . . . 25 88 8.4.9 Subflow INIT Acknowledgement (SubINIT ACK) . . . . . . . 25 89 8.4.10 Selective Acknowledgement (SACK) . . . . . . . . . . . 26 90 8.4.11 Subflow Shutdown (SubSHUTDOWN) . . . . . . . . . . . . 29 91 8.4.12 Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK) . . 30 92 8.4.13 Session Shutdown (SSHUTDOWN) . . . . . . . . . . . . . 30 93 8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK) . . . 30 94 8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK) . . . 30 95 8.4.15 Session Shutdown Complete (SSHUTDOWN COMPLETE) . . . . 31 96 8.4.16 Abort (ABORT) . . . . . . . . . . . . . . . . . . . . . 31 97 8.4.17 Operation Error (ERROR) . . . . . . . . . . . . . . . . 31 98 8.4.18 Path Feedback (PATH FEEDBACK) . . . . . . . . . . . . . 37 99 8.4.19 Path Probe (PATH PROBE) . . . . . . . . . . . . . . . . 38 100 9. MPMTP-AR Session State Diagram . . . . . . . . . . . . . . . . 39 101 10. Session Initialization . . . . . . . . . . . . . . . . . . . . 42 102 10.1 Normal Establishment of a Session . . . . . . . . . . . . . 42 103 10.1.1 Handle Path Parameters . . . . . . . . . . . . . . . . 43 104 10.1.2 Generating State Cookie . . . . . . . . . . . . . . . . 44 105 10.1.3 State Cookie Processing . . . . . . . . . . . . . . . . 45 106 10.1.4 State Cookie Authentication . . . . . . . . . . . . . . 45 107 10.1.5 Open Subflow . . . . . . . . . . . . . . . . . . . . . 46 108 10.2 Handle Duplication or Unexpected Issue . . . . . . . . . . 46 109 10.2.1 Unexpected SINIT in States Other than CLOSED, 110 COOKIE-ECHOED, COOKIE-WAIT, and SSHUTDOWN-ACK-SENT . . 46 111 10.2.2 Unexpected SINIT ACK . . . . . . . . . . . . . . . . . 47 112 10.2.3 Handle a COOKIE ECHO when a TCB Exists . . . . . . . . 47 113 10.2.4 Handle Duplicate COOKIE-ACK . . . . . . . . . . . . . . 47 114 10.2.5 Handle Stale COOKIE Error . . . . . . . . . . . . . . . 47 115 11. User Data Transfer . . . . . . . . . . . . . . . . . . . . . . 48 116 11.1 Transmission of DATA Packet . . . . . . . . . . . . . . . . 49 117 11.2 Acknowledge on Reception of DATA Packets . . . . . . . . . 50 118 11.2.1 Processing a Received SACK . . . . . . . . . . . . . . 53 119 11.3 Management of Retransmission Timer . . . . . . . . . . . . 54 120 11.3.1 RTO Calculation . . . . . . . . . . . . . . . . . . . . 54 121 11.3.2 Retransmission Timer Rules . . . . . . . . . . . . . . 56 122 11.3.3 Handle T3-RTX Expiration . . . . . . . . . . . . . . . 56 123 11.4 Path Identifier and Specific-Subflow Sequence Number . . . 57 124 11.5 Ordered and Unordered Delivery . . . . . . . . . . . . . . 57 125 11.6 Report Gaps in Received DATA TSNs . . . . . . . . . . . . . 58 126 11.7 Fragmentation and Reassembly . . . . . . . . . . . . . . . 59 127 12. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 60 128 12.1 Differences Between MPMTP-AR and TCP in Congestion 129 Control . . . . . . . . . . . . . . . . . . . . . . . . . . 60 130 12.2 Slow-Start and Congestion Avoidance . . . . . . . . . . . . 61 131 12.2.1 Slow-Start . . . . . . . . . . . . . . . . . . . . . . 62 132 12.2.2 Congestion Avoidance . . . . . . . . . . . . . . . . . 63 133 12.2.3 Parameter Update . . . . . . . . . . . . . . . . . . . 64 134 12.2.4 Fast Retransmit on Gap Reports . . . . . . . . . . . . 64 135 12.3 Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 66 136 13. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 66 137 13.1 Endpoint Failure Detection . . . . . . . . . . . . . . . . 66 138 13.2 Path Failure Detection . . . . . . . . . . . . . . . . . . 67 139 13.3 Handle "Out of the Blue" Packets . . . . . . . . . . . . . 67 140 14. Termination of Session . . . . . . . . . . . . . . . . . . . . 68 141 14.1 Abort of a Session . . . . . . . . . . . . . . . . . . . . 68 142 14.2 Shutdown of a Session . . . . . . . . . . . . . . . . . . . 69 143 15. Security Consideration . . . . . . . . . . . . . . . . . . . . 70 144 15.1 Security Objectives . . . . . . . . . . . . . . . . . . . 70 145 15.2 MPMTP-AR Responses to Potential Threats . . . . . . . . . 71 146 15.2.1 Countering Insider Attacks . . . . . . . . . . . . . . 71 147 15.2.2 Protecting Confidentiality . . . . . . . . . . . . . . 71 148 15.2.3 Protecting against Blind Denial-of-Service Attacks . . 72 149 15.2.3.1 Flooding . . . . . . . . . . . . . . . . . . . . . 72 150 15.2.3.2 Blind Masquerade . . . . . . . . . . . . . . . . . 73 151 15.2.3.3 Improper Monopolization of Services . . . . . . . 73 152 16. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 74 153 16.1 Normal Reference . . . . . . . . . . . . . . . . . . . . . 74 154 16.2 Information Reference . . . . . . . . . . . . . . . . . . . 74 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 157 1. Introduction 159 This document defines a multipath message transport protocol based on 160 application-level relay (MPMTP-AR). The MPMTP-AR works on framework 161 of multipath transport system based on application-level relay (MPTS- 162 AR)[1], and provides reliable end-to-end multipath transmission 163 services. 165 As Internet evolves, the demands of Internet resources are ever- 166 increasing, but these resources (in particular, bandwidth) cannot be 167 fully utilized due to protocol constraints. If these resources could 168 be used concurrently, network resource utilization and end user 169 experience could be improved significantly. 171 Although current protocols such as TCP, MPTCP and SCTP support 172 reliable or multipath transport, they have some limitations described 173 as following: 175 1) TCP provides reliable and sequential data delivery service. But it 176 cannot support multipath transport. 178 2) MPTCP [4] supports multipath transport. At least one of 179 participates has to be multi-homed. The transmission uses multiple IP 180 pairs (Source IP, Destination IP) simultaneously. Transmission 181 between each IP pair keeps same with regular TCP [6]. Multi-homed 182 host limits the range of usage. 184 3) SCTP is an alternative transport protocol capable of supporting 185 several IP addresses per connection. The first versions of SCTP used 186 multiple addresses in failover scenarios, but recent extensions have 187 enabled it to support the simultaneous use of several paths. 189 All those limitations motivated the development of MPMTP-AR. MPMTP-AR 190 overcome those limitations by application level relay, select 191 acknowledgement and retransmission mechanisms. Part of mechanisms 192 reference to SCTP [3]. 194 Multipath transport has several benefits as following: 196 1) To increase the efficiency of the resource usage, and thus 197 increase the network capacity available to agent. 199 2) Increased Throughput: In some cases, the relay path has better 200 performance than the default path. Total transport capacity of 201 multiple paths may meet the requirements of the high bit-rate. 203 3) To increase the resilience of the connectivity by protecting path 204 from the failure of one. 206 2. Terminology 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in RFC2119 [2]. 212 3. Definition 214 1) Cumulative TSN Ack Point: The TSN of the last DATA packet 215 acknowledged via the Cumulative TSN Ack field of a SACK. 217 2) Session ID: The unique identify of the session. 219 3) Message Authentication Code (MAC): An integrity check mechanism 220 based on cryptographic hash functions using a secret key. Typically, 221 message authentication codes are used between two parties that share 222 a secret key in order to validate information transmitted between 223 these parties. In MPMTP-AR, it is used by an agent to validate the 224 State Cookie information that is returned from the peer in the COOKIE 225 ECHO chunk. The term "MAC" has different meanings in different 226 contexts. MPMTP-AR uses this term with the same meaning as in [7]. 228 4) MPMTP-AR application (MPMTP-AR user): The logical higher-layer 229 application entity which uses the services of MPMTP-AR. 231 5) Ordered Message: A user message that is delivered in order with 232 respect to all previous user messages sent within the session. 234 6) Outstanding TSN (at an MPMTP-AR agent): A TSN (and the associated 235 DATA packet) that has been sent by the agent but for which it has not 236 yet received an acknowledgement. 238 7) Receiver Window (rwnd): An MPMTP-AR variable, a data sender uses 239 to store the most recently calculated receiver window of its peer, in 240 number of bytes. This gives the sender an indication of the space 241 available in the receiver's inbound buffer. 243 8) Slow-Start Threshold (ssthresh): An MPMTP-AR variable. This is the 244 threshold that the agent will use to determine whether to perform 245 slow start or congestion avoidance on a particular path. Ssthresh is 246 in number of bytes. 248 9) Subflow: flow of data packets along a specific path, i.e., a 249 subset of the packets belonging to a data flow. The combination of 250 all subflows forms the complete original data flow. Typically, a 251 subflow should map to a unique path. 253 10)Transmission Control Block (TCB): An internal data structure 254 created by an MPMTP-AR agent for each of its existing MPMTP-AR 255 session to other MPMTP-AR endpoints. TCB contains all the status and 256 operational information for the agent to maintain and manage the 257 corresponding session. 259 11)Transmission Sequence Number (TSN): A 32-bit sequence number used 260 internally by MPMTP-AR. One TSN is attached to each chunk containing 261 user data to permit the receiving MPMTP-AR agent to acknowledge its 262 receipt and detect duplicate deliveries. 264 12)Unacknowledged TSN (at an MPMTP-AR agent): A TSN (and the 265 associated DATA packet) that has been received by the agent but for 266 which an acknowledgement has not yet been sent. Or in the opposite 267 case, for a packet that has been sent but no acknowledgement has been 268 received. 270 13)Unordered Message: Unordered messages are "unordered" with respect 271 to any other message; this includes both other unordered messages as 272 well as other ordered messages. 274 4. Goals 276 Using MPMTP-AR for reliable transmission, original data belonging to 277 a session is divided multiple subflows and carried over multiple 278 paths. This may prove beneficial in case of reliable transmission. 280 1) Improve Throughput: MPMTP-AR MUST support the concurrent use of 281 multiple paths. To meet the minimum performance incentives for 282 deployment, a MPMTP-AR connection over multiple paths SHOULD achieve 283 no worse throughput than regular default path connection over the 284 best constituent paths. 286 2) Improve Resilience: MPMTP-AR MUST support the use of multiple 287 paths interchangeably for resilience purposes, by permitting packets 288 to be sent and re-sent on any available path. It follows that, in the 289 worst case, the protocol MUST be no less resilient than regular 290 default path. 292 In order to guarantee reliable and order transmission, MPMTP-AR has 293 the following goals: 295 1) Load balancing: transmitting a message over multiple paths reduces 296 the bandwidth usage on a single path, which in turn reduces the 297 impact on other traffic on that path and then avoids congestion in 298 network hot-spots. From the perspective of the whole network, the 299 network reliability and network utilization can be significantly 300 improved. 302 2) Acknowledgement and Retransmission: when the receiver receive data 303 packet, it SHOULD indicate the sender about correctly received data 304 packets by acknowledgement; if some data packets with transmission 305 error, the sender MUST retransmit them by retransmission mechanism. 307 5. Overview 309 Figure 1: Illustrates the framework of the proposed multipath 310 transmission system based on application-level relay (MPTS-AR). 312 MPTS-AR defines three kinds of logical entitiy including user agent, 313 relay, and relay controller. It also defines a relay service control 314 protocol named OpenPath protocol in control plane to manage relay 315 paths, and a profile of multipath transport protocol suite in data 316 plane to facilitate multipath data transport. Based on MPTS-AR, we 317 define MPMTP-AR as a profile to support reliable transmission. 319 (1)Out-of-band Signaling +-----------------+ (1) 320 +--------------------->| Out-of-band |<----------------+ 321 | | Signaling Server| | 322 | +-----------------+ | 323 | ^ | 324 | |(1)OpenPath | 325 | V | 326 | or (2) OpenPath +------------------+ | 327 | +----------------->| Relay Controller | | 328 | | +------------------+ | 329 | | ^ | 330 | | | | 331 V V | V 332 +------------+ |OpenPath +------------+ 333 | User Agent | | | User Agent | 334 | (Sender) | | | (Receiver) | 335 +------------+ V +------------+ 336 | ................................. ^ 337 | . +-----------------+ . | 338 | . | Relay | . | 339 | . +-----------------+ | . | 340 | . | Relay |--+ . | 341 | . +-----------------+ | . | 342 +------------>. | Relay |--+ .----------+ 343 MPTP . | | . MPTP 344 . +-----------------+ . 345 ................................. 347 Figure 1 : The framework of the proposed multipath transmission 348 system based on application-level relay. 350 User agent is responsible for sending or receiving data packets. In 351 the sender side, it needs to collect candidate paths, and establish a 352 connective session before transmitting data. The framework defines 353 two ways used for collecting candidate paths by the sender. Before 354 using them, the sender performs connectivity checks on relay paths to 355 ascertain reachability. According to transmission requirements of 356 current session, the sender selects the default path and one or more 357 available relay paths as active paths to transmit data to the 358 receiver. 360 A multiple session may be setup at the beginning, or be upgraded from 361 the default path. 363 The sender distributes the original data across the active paths 364 based on a scheduling strategy up to send buffer, and encapsulates 365 them as special structure defined in MPTP profile before delivery. 367 During the transmission, the sender adjust send buffer in line with 368 the receiver buffer. The receiver combines the received subflows to 369 recreate the original data by transmission sequence number. 371 In order to notify sender of the reception, receiver sends selective 372 acknowledgement to the sender. It contains information about receive 373 buffer, correct reception, out of order packets, and duplicate 374 reception. The sender will sends error data packets immediately and 375 wait for out of order packets for a special timer which can be set by 376 application. The retransmission may choose the best performance path, 377 or may be different from the path for which the timer expired or 378 eroded. 380 The session provides for graceful close on request from the MPMTP-AR 381 agents, and also allows ungraceful close either on request from the 382 MPMTP-AR agents or as a result of an error condition detected. 384 6. Usage Scenarios 386 MPMTP-AR can provide end-to-end message transmission application, 387 such as file transfer. 389 Figure 2 illustrates a end-to-end multipath session. There are three 390 paths between sender and receiver, including a default path, one 391 relay path via one relay, and another relay path via two relays. 392 Applications running at sender side can choose a data partitioning 393 method according to its particular requirements. Then, assigned data 394 to paths. Receiver reassembles the received data packets using 395 reorder buffer to retrieve the reconstructed data which is delivered 396 to the above application. 398 Relay path(A, Relay-1, B) 399 +-----------+ 400 +-------------------->| Relay-1 |---------------------+ 401 | +-----------+ | 402 | V 403 +--------+ Default path(A,B) +--------+ 404 | User A |<--------------------------------------------->| User B | 405 +--------+ +--------+ 406 | ^ 407 | Relay path(A, Relay-2, Relay-3, B) | 408 | +-----------+ +-----------+ | 409 +---->| Relay-2 |------------------>| Relay-3 |-----+ 410 +-----------+ +-----------+ 411 Figure.2. An end-to-end multipath session. 413 As shown in fig.2, relay path is unidirectional and default path is 414 bidirectional. All data from receiver to sender via default path. 416 7. MPMTP-AR Agent Behavior 418 Based on user agent behavior in MPTS-AR, MPMTP-AR agent behavior 419 needs modification, extension and addition to support message 420 reliable transmission. Those functions include session and path 421 management, flow partitioning and scheduling, subflow packaging, 422 sequenced delivery, subflow recombination, subflow reporting, and 423 selection acknowledgement and congestion avoidance. 425 Compare with the agent behavior introduced in MPTS-AR, MPMTP-AR agent 426 behaviors divided into four types: Consistent Behaviors, Modified 427 Behaviors, Additional Behaviors, and New Behaviors. 429 7.1 Consistent Behaviors 431 7.1.1 Path management 433 As illustrated in MPTS-AR, sender need to manage path including 434 obtaining candidate relay path list, periodically path probe, path 435 keep-alive, and monitor quality of relay paths. Details refer to 436 section of path management in MPTS-AR. 438 7.2 Modified Behaviors 440 7.2.1 Subflow recombination 442 Receiver collects receiving statistics for per-subflow using Path-ID 443 and Subflow-Specific sequence number. Then decapsulates packets and 444 puts data packets in receive buffer per subflow using Path-ID and 445 orders them using Subflow-Specific Sequence Number. 447 7.3 Additional Behaviors 449 7.3.1 Session management 451 MPMTP-AR is a connection-oriented application-level protocol, so a 452 connection needs to be established before data transmission. The 453 MPMTP-AR session establishment uses a way of out-of-band signaling 454 (OpenPath) to get path information. Session parameters negotiation 455 and authentication should be done during signaling process. A session 456 with multipath may be setup at the beginning, or may be upgraded from 457 a session with a default path. The connection establishment uses a 458 four-way-handshake. 460 MPMTP-AR provides for graceful close (i.e., shutdown) of an active 461 session on request from agent. MPMTP-AR also allows ungraceful close 462 (i.e., abort), either on request from the agent (ABORT primitive) or 463 as a result of an error condition detected. 465 MPMTP-AR session is a set of multiple paths which are based on 466 connection. The detailed description of session management messages 467 will be specified in section 8.4. 469 7.3.2 Flow partitioning and scheduling 471 MPTS-AR defines a simple flow partitioning scheme, round-robin 472 algorithm, to assign packets to multiple subflows. In MPMTP-AR, we 473 introduce a performance-based algorithm. 475 Due to paths has different transmission characteristic, such as 476 bandwidth, delay, jitter, and error rate, we should assign data 477 packet to subflow according to their capacity to increase 478 transmission quality. Since sender monitor active path quality, 479 collects statistics (e.g. RTT, loss-rate, delay etc.), so sender 480 assigned more data packets to the subflow with a better performance. 481 Data packets distribution adjust dynamically and periodically. 483 Sender should associate a subflow with an active path according to 484 scheduling strategy. MPTS-AR indicates that scheduling policy should 485 take various factors into consideration, including path's 486 performance, and importance of subflow data and so on. Sender orders 487 available path list according to the path quality by descending 488 order. At the same time, the sender maintains active paths. If a path 489 in available path list performs better than an active path for a 490 time, then the path should take over the active path. This behavior 491 is maintained throughout a session. 493 7.3.3 Subflow packaging 494 In a session, sender formats data chunks into MPMTP-AR data packets. 495 Specific packet format will be described in section 8. Then sender 496 dispatches MPMTP-AR data packets along corresponding paths. 498 Apart from two key fields including path identifier and subflow- 499 specific sequence number defined in MPTS-AR, common header also has a 500 unique session ID. It is generated by the sender and receiver 501 respectively at the establishment of the session. 503 Control information and data are encapsulated into different chunks. 504 The control chunk contain a common header and chunk value. All chunks 505 put into payload field in chunk field of MPMTP-AR packet. Details of 506 different chunks are defined in section 8. 508 7.3.4 Subflow reporting 510 As mentioned in MPTS-AR, both sender and receiver need t send subflow 511 report to monitor transmission quality. In this section, we define 512 when to generate reports and what reports contain. 514 Suggested constants are to be used for subflow report interval 515 calculation. Sessions operating under this document may specify a 516 separate parameter for the traffic bandwidth rather than using the 517 default fraction of the session bandwidth. The recommended fraction 518 of the session bandwidth used for reports be fixed at 5%. The 519 recommendation is that 1/4 of the report bandwidth be dedicated to 520 data sender, the recommended default values for these two parameters 521 would be 1.25% and 3.75%, respectively. The reports bandwidth for 522 data senders should be kept non-zero so that sender reports can still 523 be sent for inter-media synchronization. 525 The content of report should be able to reflect sending and receiving 526 status. They collect statistics, such as the number of sent chunks 527 and received chunks for per subflow. Details of report format defined 528 in section 8.4. 530 7.4 New Behaviors 532 7.4.1 Sequenced Delivery 534 MPMTP-AR supports reliable and ordered message transmission using 535 Transmission Sequence Number, Subflow-Specific Sequence Number, and 536 Path-ID. 538 MPMTP-AR uses two levels of sequence spaces to guarantee reliable and 539 ordered transmission: a session-level sequence number (Transmission 540 Sequence Number) and a suflow-level sequence number (Subflow-Specific 541 Sequence Number, SSSN) for each DATA packet. TSN is initialed as a 542 randomly number, and SSSN is a number starting from zero. 544 In order to inform receiver to reassemble the received data, sender 545 uses SSSN to makr location of chunk in a subflow. 547 One-to-one relationship is between path and subflow. MPMTP-AR uses 548 path identity to distinguish multiple paths. This ensures path to be 549 unique in the whole network. Sender is able to tell the relay to 550 choose which path and tell the receiver which subflow the packet come 551 from by Path-ID. 553 7.4.2 Acknowledgement and Congestion Avoidance 555 MPMTP-AR supports selected acknowledgements at session-level to 556 acknowledge the reception. 558 MPMTP-AR assigns a Transmission Sequence Number (TSN) to each data 559 chunk. The TSN is independent of any SSSN assigned at subflow level. 560 SACK acknowledges all TSNs received, even if there are gaps in 561 sequence. In this way, reliable delivery is kept functionally 562 separate from sequenced delivery. 564 MPMTP-AR uses data sequence mapping and session-level SACKs to decide 565 when a session-level segment was received. A session-level SACKs 566 signal when receive window moves forward, sum correct receiving 567 transmission sequence number, out of order blocks and retransmission 568 blocks. It would mean that once a segment is SACKed, it can be 569 discarded in send buffer. Re-transmission send buffer has higher 570 priority. Transmission reports signal sender detail information of 571 active path, such as correctly receiving ratio and RTT. Sender would 572 send segments in re-transmission buffer over the best transmission 573 quality path according to transmission report. MPMTP-AR agent message 574 from application, and put it into send buffer. At the beginning, 575 receiver tells sender the size of receive window via MPMTP-AR session 576 establishment. During message transmission, receiver moves forward 577 receive window and signals sender this change via SACKs. Sender 578 adjusts send window in line to receive window. 580 Acknowledgement and congestion avoidance function is responsible for 581 retransmission when timely acknowledgement has not been received. 582 Packet retransmission is conditioned by congestion avoidance 583 procedures similar to those used for TCP. Large-scale experiments are 584 therefore required in order to determine the most appropriate 585 retransmission strategy, and recommendations will be refined once 586 more information is available. 588 8. MPMTP-AR Packet Format 589 This section defines MPMTP-AR packet format to meet the requirement 590 of behaviour described in section 7. 592 8.1 Overview 594 As stated in MPTS-AR, although MPTP obtain a simple, unreliable 595 datagram service from the underlying UDP [5], MPTP can meet reliable 596 delivery requirements of upper application programs. 598 MPTP is only a profile suit that is not complete, reliable delivery 599 requirement of upper application programs can be relised in specific 600 application profile defined in this document named MPMPT-AR. 602 In order to support agent behavior illustrated in section 7, we 603 define MPMTP-AR packet format containing data and control packet. 605 8.2 MPMTP-AR Packet Header 607 MPMTP-AR header inherits from MPTP packet Header, including eight 608 octet-length common header. The eight octets except for the first 609 four bits correspond to different fields for MPMTP-AR data packets 610 and MPMTP-AR control packets. 612 8.3 Fixed Header Fields of MPMTP-AR Data Packet 614 Fixed header of MPMTP-AR data packet is defined below: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 |V=1|T|P| AMT | TOS | Rsvd | SSSN | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Path Identifier | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Transmission Sequence Number | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |U|B|E| Reserved | Length | 626 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 627 \ \ 628 / Data Chunk / 629 \ \ 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 The fields have the following meaning: 634 version (V): 2 bits 635 This field identifies the version of MPTP. The version defined by 636 this document is one (1). 638 MPMTP-AR packet type (T): 1 bit 639 This field identifies the type of a MPMTP-AR packet. If the MPMTP- 640 AR packet type bit is set, this packet is a MPMTP-AR data packet; 641 otherwise, this packet is a MPMTP-AR control packet. 643 padding (P): 1 bit 644 If the padding bit is set, the packet contains one or more 645 additional padding octets at the end which are not part of the 646 payload. The last octet of the padding contains a count of how 647 many padding octets should be ignored, including itself. Padding 648 may be needed by some encryption algorithms with fixed block 649 sizes. 651 Application-specific MPMTP-AR type (AMT): 4 bits 652 This field identifies the type of application-specific MPTP. In 653 this document, AMT = 2. 655 type of service (TOS): 4 bits 656 This field, similar to TOS field in internet packet header, is 657 specified along the abstract parameters precedence, delay, 658 throughput, and reliability. These abstract parameters embody the 659 delivery requirements of upper application programs. The values of 660 these abstract parameters should be specified in application- 661 specific MPTP documents. 663 Precedence: An independent measure of the importance of the 664 payload data. 666 Delay: Prompt delivery is important for the payload data with this 667 indication. 669 Throughput: High data rate is important for the payload data with 670 this indication. 672 Reliability: A higher level of effort to ensure delivery is 673 important for the payload data with this indication. 675 Rsvd: 4 bits 676 These 4 bits are reserved, which can be used and described in 677 application-specific MPTP documents. 679 Subflow-Specific Sequence Number (SSSN): 680 This field is the sequence of the MPMTP-AR data packet in the 681 subflow. Each subflow has its own strictly monotonically 682 increasing sequence number space. 684 Path Identifier: 685 This field is the identifier of the path that the MPMTP-AR packet 686 is associated with. For a relay path, the path identifier is 687 globally unique; for the default path, the path identifier is 688 fixed to zero. 690 Transmission Sequence Number (TSN): 32 bits 691 This field is the sequence of the MPMTP-AR data packet in the 692 original data. The original flow has the unique strictly 693 monotonically increasing sequence number space. 695 U bit: 1 bit 696 The (U)nordered bit, if set to '1', indicates that this is an 697 unordered DATA chunk, and there is no Stream Sequence Number 698 assigned to this DATA chunk. Therefore, the receiver MUST ignore 699 the Stream Sequence Number field. After reassembly (if necessary), 700 unordered DATA chunks MUST be dispatched to the upper layer by the 701 receiver without any attempt to reorder. If an unordered user 702 message is fragmented, each fragment of the message MUST have its 703 U bit set to '1'. 705 B bit: 1 bit 706 The (B)eginning fragment bit, if set, indicates the first fragment 707 of a user message. 709 E bit: 1 bit 710 The (E)nding fragment bit, if set, indicates the last fragment of 711 a user message. 713 An unfragmented user message shall have both the B and E bits set 714 to '1'. Setting both B and E bits to '0' indicates a middle 715 fragment of a multi-fragment user message, as summarized in the 716 following table: 718 When a user message is fragmented into multiple chunks, the TSNs 719 are used by the receiver to reassemble the message. This means 720 that the TSNs for each fragment of a fragmented user message MUST 721 be strictly sequential. 723 Data Chunk: variable length 724 This is the payload data. The implementation MUST pad the end of 725 the data to a 4-byte boundary with all-zero bytes. Any padding 726 MUST NOT be included in the Length field. A sender MUST never add 727 more than 3 bytes of padding. 729 8.4 Fixed Header Fields of MPMTP-AR Control Packet 731 Fixed header of MPMTP-AR control packet is defined below: 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |V=1|T|P| AMT | CT | Length | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Path Identifier | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Session ID | 741 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 742 \ \ 743 / Control Chunk / 744 \ \ 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 The fields of V, T, P, AMT, Path Identifier, and Session ID have the 748 same meaning as those fields in MPMTP-AR data packet. Other fields 749 have the following meaning: 751 MPMTP-AR control packet type (CT): 8 bits 752 This field identifies the type of MPMTP-AR control packet. 754 Length: 8 bits 755 This field is the length of the encapsulated control data after 756 the MPMTP-AR header in byte length. 758 Chunk: (variable length) 759 This field contains data or control information. 761 Control data is packed into chunks. Following sections from 8.4.1 to 762 8.4.19 describe the format of control chunks. 764 The values of CT are defined as follows: 766 +---------------+---------------------------------------------------+ 767 | ID Value | Chunk Type | 768 +---------------+---------------------------------------------------+ 769 | 1 | Sender Report (SR) | 770 +---------------+---------------------------------------------------+ 771 | 2 | Receiver Report (RR) | 772 +---------------+---------------------------------------------------+ 773 | 3 | Keep Alive (KA) | 774 +---------------+---------------------------------------------------+ 775 | 4 | Session Initiation (SINIT) | 776 +---------------+---------------------------------------------------+ 777 | 5 | Session Initiation Acknowledgement (SINIT ACK) | 778 +---------------+---------------------------------------------------+ 779 | 6 | Cookie Echo (COOKIE ECHO) | 780 +---------------+---------------------------------------------------+ 781 | 7 | Cookie Acknowledgement (COOKIE ACK) | 782 +---------------+---------------------------------------------------+ 783 | 8 | Subflow INIT Request (SubINIT) | 784 +---------------+---------------------------------------------------+ 785 | 9 | Subflow INIT Acknowledgement (SubINIT ACK) | 786 +---------------+---------------------------------------------------+ 787 | 10 | Selective Acknowledgement (SACK) | 788 +---------------+---------------------------------------------------+ 789 | 11 | Subflow Shutdown (SubSHUTDOWN) | 790 +---------------+---------------------------------------------------+ 791 | 12 | Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK)| 792 +---------------+---------------------------------------------------+ 793 | 13 | Session Shutdown (SSHUTDOWN) | 794 +---------------+---------------------------------------------------+ 795 | 14 | Session Shutdown Acknowledgement (SSHUTDOWN ACK) | 796 +---------------+---------------------------------------------------+ 797 | 15 | Session Shutdown Complete (SSHUTDOWN COMPLETE) | 798 +---------------+---------------------------------------------------+ 799 | 16 | Abort (ABORT) | 800 +---------------+---------------------------------------------------+ 801 | 17 | Operation Error (ERROR) | 802 +---------------+---------------------------------------------------+ 803 | 18 | Path Feedback (PATH FEEDBACK) | 804 +---------------+---------------------------------------------------+ 805 | 19 | Path Probe (PATH PROBE) | 806 +---------------+---------------------------------------------------+ 808 8.4.1 Sender Report (SR) 810 The sender report packet consists of three sections. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Timestamp | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Sender's packet count | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Sender's octet count | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 The fields have the following meaning: 824 Timestamp: 32 bits 825 Indicates the time when this report was sent. 827 Sender's packet count: 32 bits 828 The total number of MPMTP-AR data packets transmitted by the 829 sender since starting transmission up until the time this SR 830 packet was generated. 832 Sender's octet count: 32 bits 833 The total number of payload octets (i.e., not including header or 834 padding) transmitted in RTP data packets by the sender since 835 starting transmission up until the time this SR packet was 836 generated. This field can be used to estimate the average payload 837 data rate. 839 8.4.2 Receiver Report (RR) 841 The receiver report packet consists of four sections. 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | cumulative number of packets | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | highest sequence number received | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | last RR (LRR) | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | delay since last RR (DLRR) | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Cumulative number of packets: 32 bits 856 The total number of MPMTP-AR data packets from sender that have 857 been received since the beginning of reception. 859 Highest sequence number received: 32 bits 860 The field contains the highest transmission sequence number 861 received in a MPMTP-AR data packet from the sender. 863 Last SR (LSR): 32 bits 864 This field indicates the time of receiving last sender report. If 865 no SR has been received yet, this field is set to zero. 867 Delay since last SR (DLSR): 32 bits 868 The delay, expressed in units of 1/65536 seconds, between 869 receiving the last SR packet from the sender and sending this 870 reception report packet. If no SR packet has been received yet, 871 the DLSR field is set to zero. 873 8.4.3 Keep Alive (KA) 875 This chunk contains only timestamp. 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Timestamp | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Timestamp: 32 bits 883 This field indicates the time of sending this packet. 885 8.4.4 Session Initiation (SINIT) 887 This chunk is used to initiate an MPMTP-AR session between two 888 endpoints. The format of the SINIT chunk is shown below: 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Number of Outbound Subflow (N)| MSN | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Initial TSN | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 \ \ 898 / Optional/Variable-Length Parameters / 899 \ \ 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 The SINIT chunk contains the following parameters. Unless otherwise 903 noted, each parameter MUST only be included once in the INIT chunk. 905 --------------------------------------------------------------- 906 | Fixed Parameters | Status | 907 --------------------------------------------------------------- 908 | Number of Outbound Subflow | Mandatory | 909 --------------------------------------------------------------- 910 | Maximum Number of Subflow (MSN) | Mandatory | 911 --------------------------------------------------------------- 912 | Initial TSN | Mandatory | 913 --------------------------------------------------------------- 914 | Variable Parameters | Optional | 915 --------------------------------------------------------------- 916 IMPLEMENTATION NOTE: If an SINIT chunk is received with known 917 parameters that are not optional parameters of the SINIT chunk, then 918 the receiver SHOULD process the SINIT chunk and send back an SINIT 919 ACK. 921 Number of Outbound Subflow (NOS): 16 bits (unsigned integer) 922 Defines the maximum number of outbound subflow the sender of this 923 SINIT chunk wants to create in this session. The value of 0 is 924 invalid. 926 Note: A receiver of an SINIT with the NOS value set to 0 SHOULD 927 abort the session. 929 Maximum Number of Subflow (MSN): 16 bits (unsigned integer) 930 Defines the max number of subflows the sender of this SINIT chunk 931 allows to use in this session. 933 Note: A receiver of an SINIT with the MSN value set to 0 SHOULD 934 abort the session. 936 Initial TSN (I-TSN): 32 bits (unsigned integer) 937 This value defines the initial TSN that the sender will use. The 938 valid range is from 0 to 2**32-1. This field MAY be set to the 939 value of the Initiate TSN field. 941 1) Optional/Variable-Length Parameters in INIT The format of optional 942 parameters in the INIT ACK chunk is shown below: 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 \ \ 950 / Parameters Value / 951 \ \ 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Type: 16 bits (unsigned integer) 954 This field identifies the type of parameters in the optional 955 field. 957 Length: 16 bits (unsigned integer) 958 This field indicates the length of the optional parameters in 959 bytes from the beginning of the type field to the end of the 960 parameters field excluding any padding. Optional parameters with 961 one byte parameters will have Length set to 5 (indicating 5 962 bytes). 964 Details of variable-length parameters would be discussed in the 965 future. 967 8.4.5 Session Initiation Acknowledgement (SINIT ACK) 969 The SINIT ACK chunk is used to acknowledge the initiation of an 970 MPMTP-AR session. 972 The part of parameter of SINIT ACK is formatted similarly to the 973 SINIT chunk. It uses two extra variable parameters: advertised 974 receiver window credit and state cookie. The format of the SINIT ACK 975 chunk is shown below: 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Number of Inbound Subflow (N) | MSN | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Advertised Receiver Window Credit | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 \ \ 984 / Optional Parameters (State Cookie) / 985 \ \ 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned 989 integer) 990 This value represents the dedicated buffer space, in number of 991 bytes, the receiver has reserved in session with this window. 992 During the life of the session, this buffer space SHOULD NOT be 993 lessened (i.e., dedicated buffers taken away from this session). 995 Number of Inbound Subflow (NIS): 16 bits (unsigned integer) 996 Defines the maximum number of subflow the receiver allows the 997 sender to create in this session. The value 0 MUST NOT be used. 999 Note: There is no negotiation of the actual number of subflow but 1000 instead the two endpoints will use the min (requested, offered). 1002 Note: The sender receives SINIT ACK with the NIS value set to 0 1003 SHOULD destroy the session discarding its TCB. 1005 MSN (Maximum Number of Subflow): 16 bits (unsigned integer) 1006 This field defines the max number of subflows the receiver allows 1007 to use in this session. Valid value range is 1 to 31. 1009 State Cookie: 1010 Type Value: 1 1011 Length: Variable size, depending on size of Cookie 1012 Parameter Value: 1013 This parameter value MUST contain all the necessary state and 1014 parameter information required to create the session, along 1015 with a Message Authentication Code (MAC). 1017 8.4.6 State Cookie (COOKIE ECHO) 1019 This chunk is used only during the initialization of a session. It is 1020 sent by the initiator of an session to its peer to complete the 1021 initialization process. This chunk MUST precede any DATA chunk sent 1022 within the session. 1024 0 1 2 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | IPN (N) | Length | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Path-ID #1 | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 \ \ 1032 / / 1033 \ \ 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Path-ID #N | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 \ \ 1038 / Cookie / 1039 \ \ 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 IPN (Init Path Number): 16 bit 1043 Chunk Flags in this chunk called IPN indicates the number of 1044 initialize path which the sender wants to use at the beginning of 1045 the session. Valid value range is 1 to 255. It MUST NOT be bigger 1046 than MSN in INIT ACK. 1048 Length: 16 bits (unsigned integer) 1049 Set to the size of the chunk in bytes, including the 4 bytes of 1050 the chunk header and the chunk body. 1052 Path-ID: 32 bits (unsigned integer) 1053 This field indicates the path identification of subflow which the 1054 sender will use in the session. 1056 Cookie: variable size 1057 This field must contain the exact cookie received in the State 1058 Cookie parameter from the previous INIT ACK. 1060 An implementation SHOULD make the cookie as small as possible to 1061 ensure interoperability. 1063 Note: A Cookie Echo does NOT contain a State Cookie parameter; 1064 instead, the data within the State Cookie's Parameter Value 1065 becomes the data within the Cookie Echo's Chunk Value. This allows 1066 an implementation to change only the first 2 bytes of the State 1067 Cookie parameter to become a COOKIE ECHO chunk. 1069 8.4.7 Cookie Acknowledgement (COOKIE ACK) 1071 This chunk is used to end a session establishment and to acknowledge 1072 the receipt of a COOKIE ECHO chunk. This chunk is empty, so the 1073 packet just contains packet header. 1075 8.4.8 Subflow INIT Request (SubINIT) 1077 The sender should send this chunk to its peer agent to notify the use 1078 of a particular relay path negotiated in SINIT and SINIT ACK. 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Path-ID | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Path-ID: 32 bits (unsigned integer) 1087 This field indicates the path identification of subflow which the 1088 sender want to use in the session. 1090 8.4.9 Subflow INIT Acknowledgement (SubINIT ACK) 1092 The receiver should send this chunk to its peer agent to notify the 1093 use of a particular relay path negotiated by SINIT and SINIT ACK. 1095 0 1 2 3 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Path-ID | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 8.4.10 Selective Acknowledgement (SACK) 1103 This chunk is sent to the peer agent via default path to acknowledge 1104 received DATA packet and to inform the peer agent of gaps in the 1105 received subsequences of DATA packets as represented by their TSNs. 1107 The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver 1108 Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of 1109 Duplicate TSNs fields. 1111 By definition, the value of the Cumulative TSN Ack parameter is the 1112 last TSN received before a break in the sequence of received TSNs 1113 occurs; the next TSN value following this one has not yet been 1114 received at the agent sending the SACK. This parameter therefore 1115 acknowledges receipt of all TSNs less than or equal to its value. 1117 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 1118 Block acknowledges a subsequence of TSNs received following a break 1119 in the sequence of received TSNs. By definition, all TSNs 1120 acknowledged by Gap Ack Blocks are greater than the value of the 1121 Cumulative TSN Ack. 1123 0 1 2 3 1124 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 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Cumulative TSN Ack | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Advertised Receiver Window Credit (a_rwnd) | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Gap Ack Block #1 Start | Gap Ack Block #1 End | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 / / 1135 \ ... \ 1136 / / 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Gap Ack Block #N Start | Gap Ack Block #N End | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Duplicate TSN #1 | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 / / 1143 \ ... \ 1144 / / 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Duplicate TSN #X | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Cumulative TSN Ack: 32 bits (unsigned integer) 1150 This parameter contains the TSN of the last DATA packet received 1151 in sequence before a gap. In the case where no DATA packet has 1152 been received, this value is set to the peer's Initial TSN minus 1153 one. 1155 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned 1156 integer) 1157 This field indicates the updated receive buffer space in bytes of 1158 the sender of this SACK. 1160 Number of Gap Ack Blocks: 16 bits (unsigned integer) 1161 This field indicates the number of Gap Ack Blocks included in this 1162 SACK. 1164 Number of Duplicate TSNs: 16 bit 1165 This field contains the number of duplicate TSNs the agent has 1166 received. Each duplicate TSN is listed following the Gap Ack Block 1167 list. 1169 Gap Ack Blocks: 1170 These fields contain the Gap Ack Blocks. They are repeated for 1171 each Gap Ack Block up to the number of Gap Ack Blocks defined in 1172 the Number of Gap Ack Blocks field. All DATA packets with TSNs 1173 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 1174 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 1175 Block End) of each Gap Ack Block are assumed to have been received 1176 correctly. 1178 Gap Ack Block Start: 16 bits (unsigned integer) 1179 Indicates the Start offset TSN for this Gap Ack Block. To 1180 calculate the actual TSN number the Cumulative TSN Ack is added to 1181 this offset number. This calculated TSN identifies the first TSN 1182 in this Gap Ack Block that has been received. 1184 Gap Ack Block End: 16 bits (unsigned integer) 1185 Indicates the End offset TSN for this Gap Ack Block. To calculate 1186 the actual TSN number, the Cumulative TSN Ack is added to this 1187 offset number. This calculated TSN identifies the TSN of the last 1188 DATA packet received in this Gap Ack Block. 1190 For example, assume that the receiver has the following DATA packets 1191 newly arrived at the time when it decides to send a Selective ACK. 1193 ---------- 1194 | TSN=36 | 1195 ---------- 1196 | | <- still missing 1197 ---------- 1198 | TSN=34 | 1199 ---------- 1200 | TSN=33 | 1201 ---------- 1202 | | <- still missing 1203 ---------- 1204 | TSN=31 | 1205 ---------- 1206 | TSN=30 | 1207 ---------- 1208 | TSN=29 | 1209 ---------- 1211 then the parameter part of the SACK MUST be constructed as follows 1212 (assuming the new a_rwnd is set to 1500 by the sender): 1214 +--------------------------------+ 1215 | Cumulative TSN Ack = 31 | 1216 +--------------------------------+ 1217 | a_rwnd = 1500 | 1218 +----------------+---------------+ 1219 | num of block=2 | num of dup=0 | 1220 +----------------+---------------+ 1221 |block #1 strt=2 |block #1 end=3 | 1222 +----------------+---------------+ 1223 |block #2 strt=5 |block #2 end=5 | 1224 +----------------+---------------+ 1226 Duplicate TSN: 32 bits (unsigned integer) 1227 Indicates the number of times a TSN was received in duplicate 1228 since the last SACK was sent. 1230 Every time a receiver gets a duplicate TSN (before sending the SACK); 1231 it adds it to the list of duplicates. The duplicate count is 1232 reinitialized to zero after sending each SACK. 1234 For example, if a receiver were to get the TSN 35 three times it 1235 would list 35 twice in the outbound SACK. After sending the SACK, if 1236 it received yet one more TSN 35 it would list 35 as a duplicate once 1237 in the next outgoing SACK. 1239 8.4.11 Subflow Shutdown (SubSHUTDOWN) 1241 An agent in a session MUST use this chunk to initiate a graceful 1242 close of the session with its peer. Either the sender or the receiver 1243 can initialize this chunk. This chunk has the following format. 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Path Number(N) | Length | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Path ID #1 | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 \ \ 1253 / ... / 1254 \ \ 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Path ID #N | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Path Number (N): 32 bits (unsigned integer) 1260 This field indicates how many subflows will be closed. 1262 Path ID: 32 bits (unsigned integer) 1263 This parameter contains the Path ID of the subflow which will be 1264 closed. 1266 8.4.12 Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK) 1268 This chunk MUST be used to acknowledge the receipt of the SubSHUTDOWN 1269 chunk at the completion of the shutdown process. The format is 1270 similar with SubSHUTODWN chunk. 1272 0 1 2 3 1273 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 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Path Number(N) | Length | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Path ID #1 | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 \ \ 1280 / ... / 1281 \ \ 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Path ID #N | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 8.4.13 Session Shutdown (SSHUTDOWN) 1288 This chunk is used to close a session. The chunk is empty, so the 1289 packet just contains header. 1291 8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK) 1293 This SSHUTDOWN ACK chunk MUST be used to acknowledge the receipt of 1294 the SSHUTDOWN chunk. 1296 8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK) 1298 This SSHUTDOWN ACK chunk MUST be used to acknowledge the receipt of 1299 the SSHUTDOWN chunk. 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Path Number(N) | Length | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Path ID #1 | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 \ \ 1309 / ... / 1310 \ \ 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Path ID #N | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 This chunk inform the sender to close path indicated by Path ID. 1317 8.4.15 Session Shutdown Complete (SSHUTDOWN COMPLETE) 1319 This chunk MUST be used to acknowledge the receipt of the SSHUTDOWN 1320 ACK chunk and complete the shutdown process. The chunk is empty, so 1321 the packet just contains header. 1323 8.4.16 Abort (ABORT) 1325 The ABORT chunk is used to close the session. The ABORT chunk may 1326 contain Cause Parameters to inform the receiver about the reason of 1327 the abort. 1329 If an agent receives an ABORT with a format error or no TCB is found, 1330 it MUST silently discard it. Moreover, under any circumstances, an 1331 agent that receives an ABORT MUST NOT respond to that ABORT by 1332 sending an ABORT of its own. 1334 0 1 2 3 1335 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 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 \ \ 1338 / zero or more Error Causes / 1339 \ \ 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Length: 16 bits (unsigned integer) 1343 Set to the size of the chunk in bytes, including the chunk header 1344 and all the Error Cause fields present. 1346 See section 8.4.17 for Error Cause definitions. 1348 8.4.17 Operation Error (ERROR) 1349 An agent sends this chunk to its peer agent to notify it of certain 1350 error conditions. It contains one or more error causes. An Operation 1351 Error is not considered fatal in and of it, but may be used with an 1352 ABORT chunk to report a fatal condition. It has the following 1353 parameters: 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Number | Reserved | Length | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 \ \ 1361 / one or more Error Causes / 1362 \ \ 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 Number: 8 bits (unsigned integer) 1366 This field indicates the number of errors listed in next Error 1367 Causes field. 1369 Length: 16 bits (unsigned integer) 1370 Set to the size of the parameter in bytes, including the Number, 1371 Reserved, Length, and Error Cause fields. 1373 Error causes are defined as variable-length parameters using the 1374 format described as below: 1376 0 1 2 3 1377 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 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Cause Code | Cause Length | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 \ \ 1382 / Cause-Specific Information / 1383 \ \ 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 Cause Code: 16 bits (unsigned integer) 1387 This value defines the type of error conditions being reported. 1389 Cause Code 1390 Value Cause Code 1391 --------- ---------------- 1392 1 Invalid Path-ID 1393 2 Missing Mandatory Parameter 1394 3 Stale Cookie Error 1395 4 Out of Resource 1396 5 Unrecognized Chunk Type 1397 7 Invalid Mandatory Parameter 1398 7 Unrecognized Parameters 1399 8 No User Data 1400 9 Cookie Received While Shutting Down 1401 10 User Initiated Abort 1402 11 Protocol Violation 1404 Cause Length: 16 bits (unsigned integer) 1405 Set to the size of the parameter in bytes, including the Cause 1406 Code, Cause Length, and Cause-Specific Information fields. 1408 Cause-Specific Information: variable length 1409 This field carries the details of the error condition. 1411 The following section 1) - 11) define error causes for MPMTP-AR. 1413 1) Invalid Path-ID 1415 Cause of error: Invalid Path ID indicates Relay received a DATA chunk 1416 sent to a nonexistent subflow. 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Cause Code=1 | Cause Length=8 | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Path ID | (Reserved) | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 Path ID: 16 bits (unsigned integer) 1427 This field contains the Path Identifier of the error DATA chunk. 1429 Reserved: 16 bits 1430 This field is reserved. It is set to all 0 on transmit and ignored 1431 on receipt. 1433 2) Missing Mandatory Parameter 1435 Cause of error: Missing Mandatory Parameter. Indicating that one or 1436 more mandatory parameters are missing in a received SINIT or SINIT 1437 ACK. 1439 0 1 2 3 1440 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 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Cause Code=2 | Cause Length=8+N*2 | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Number of missing params=N | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Missing Param Type #1 | Missing Param Type #2 | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 \ \ 1449 / Missing Param Type / 1450 \ \ 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | Missing Param Type #N-1 | Missing Param Type #N | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 Number of Missing params: 32 bits (unsigned integer) 1456 This field contains the number of parameters contained in the 1457 Cause-Specific Information field. 1459 Missing Param Type: 16 bits (unsigned integer) 1460 Each field will contain the missing mandatory parameter number. 1462 3) Stale Cookie Error 1464 Cause of error: Stale Cookie Error indicates the receipt of a valid 1465 State Cookie that has expired. 1467 0 1 2 3 1468 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 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Cause Code=3 | Cause Length=8 | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Measure of Staleness (usec.) | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 Measure of Staleness: 32 bits (unsigned integer) 1476 This field contains the difference, in microseconds, between the 1477 current time and the time the State Cookie expired. 1479 The sender of this error cause MAY choose to report how long past 1480 expiration the State Cookie is by including a non-zero value in the 1481 Measure of Staleness field. If the sender does not wish to provide 1482 this information, it should set the Measure of Staleness field to the 1483 value of zero. 1485 4) Out of Resource 1487 Cause of error: Out of Resource. Indicating the sender that session 1488 is out of resource. This is usually sent in combination with or 1489 within an ABORT. 1491 0 1 2 3 1492 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 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Cause Code=4 | Cause Length=4 | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 5) Unrecognized Chunk Type 1499 Cause of error: Unrecognized Chunk Type. This error cause is returned 1500 to the originator of the chunk if the receiver does not understand 1501 the chunk. 1503 0 1 2 3 1504 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 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Cause Code=5 | Cause Length | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 \ \ 1509 / Unrecognized Chunk / 1510 \ \ 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 Unrecognized Chunk: variable length 1514 The Unrecognized Chunk field contains the unrecognized chunk from 1515 the MPMTP-AR packet completing with Chunk Type, Chunk Flags, and 1516 Chunk Length. 1518 6) Invalid Mandatory Parameter 1520 Cause of error: Invalid Mandatory Parameter. This error cause is 1521 returned to the originator of an SINIT or SINIT ACK chunk when one of 1522 the mandatory parameters is set to an invalid value. 1524 ,ne5 1525 0 1 2 3 1526 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 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Cause Code=6 | Cause Length=4 | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 7) Unrecognized Parameters 1532 Cause of error: Unrecognized Parameters. This error cause is returned 1533 to the originator of the SINIT ACK chunk if the receiver does not 1534 recognize one or more Optional parameters in the SINIT ACK chunk. 1536 0 1 2 3 1537 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 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Cause Code=7 | Cause Length | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 \ \ 1542 / Unrecognized Parameters / 1543 \ \ 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 Unrecognized Parameters: variable length 1547 The Unrecognized Parameters field contains the unrecognized 1548 parameters copied from the SINIT ACK chunk. This error cause 1549 packet is normally contained in an ERROR chunk followed with the 1550 COOKIE ECHO packet when responding to the INIT ACK, when the 1551 sender of COOKIE ECHO chunk wishes to report unrecognized 1552 parameters. 1554 8) No User Data 1556 Cause of error: No User Data. This error cause is returned to the 1557 originator of a DATA packet if a received DATA packet has no user 1558 data. 1560 0 1 2 3 1561 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 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Cause Code=8 | Cause Length=8 | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 \ \ 1566 / TSN Value / 1567 \ \ 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 TSN value: 32 bits (unsigned integer) 1571 The TSN value field contains the TSN of the DATA chunk received 1572 with no user data field. 1574 9) Cookie Received While Shutting Down 1576 Cause of error: Cookie Received While Shutting Down. A COOKIE ECHO 1577 was received while the agent was in the session-level SSHUTDOWN-ACK- 1578 SENT state. This error is usually returned in an ERROR chunk followed 1579 with the retransmitted SSHUTDOWN ACK. 1581 0 1 2 3 1582 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 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | Cause Code=9 | Cause Length=4 | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 10) User-Initiated Abort 1589 Cause of error: This error cause MAY be included in ABORT chunks that 1590 are sent because of an MPMTP-AR user request. The MPMTP-AR user can 1591 specify an Abort Reason that is transported by MPMTP-AR transparently 1592 and MAY be delivered to the MPMTP-AR user at the peer. 1594 0 1 2 3 1595 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 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Cause Code=10 | Cause Length=Variable | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 \ \ 1600 / Upper Layer Abort Reason / 1601 \ \ 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 11) Protocol Violation 1606 Cause of error: This error cause MAY be included in ABORT chunks that 1607 are sent because an MPMTP-AR agent detects a protocol violation of 1608 the peer that is not covered by the error causes described in above 1609 section 1) to section 10). An implementation MAY provide additional 1610 information specifying what kind of protocol violation has been 1611 detected. 1613 0 1 2 3 1614 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 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Cause Code=11 | Cause Length=Variable | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 \ \ 1619 / Additional Information / 1620 \ \ 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 8.4.18 Path Feedback (PATH FEEDBACK) 1625 This chunk is used to indicate the sender about path feedback 1626 information. The chunk includes time interval, subflow 1627 identification, max received transmission sequence number and 1628 correctly received byte of data packet. 1630 0 1 2 3 1631 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 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Last Feedback Time | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Current Feedback Time | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Path ID #1 | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Received Max TSN #1 | Received Data Bytes #1 | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 \ \ 1642 / ... / 1643 \ \ 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Path ID #N | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Received Max TSN #N | Received Data Bytes #N | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 Last Feedback Time: 32 bits (unsigned integer) 1651 This field marks the time at which the receiver sends last PATH 1652 FEEDBACK. 1654 Current Feedback Time: 32 bits (unsigned integer) 1655 This field marks the time at which the receiver sends this PATH 1656 FEEDBACK. 1658 Received Max TSN: 16 bits (unsigned integer) 1659 This field indicates the max TSN of data packet received from the 1660 path marked by Path ID field. 1662 Received Data Bytes: 16 bits (unsigned integer) 1663 This field indicates the bytes of data received from the path 1664 marked by Path ID between the Last Feedback Time and the Current 1665 Feedback Time. 1667 8.4.19 Path Probe (PATH PROBE) 1669 An agent should send this chunk to its peer agent to probe the path 1670 reachability and RTT. This chunk contains send time. 1672 0 1 2 3 1673 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 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Timestamp | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 Timestamp: 32 bits 1679 This field records the send time of this chunk form the initiator 1680 of this chunk. 1682 The receiver of this chunk delivers it to the sender via default path 1683 as soon as received and do not change anything. The initiator can 1684 calculate the RTT by send time and receive time. 1686 9. MPMTP-AR Session State Diagram 1688 During the life time of an MPMTP-AR session, the MPMTP-AR agent's 1689 session progresses from one state to another in response to various 1690 events. 1692 The state diagram in the figures below illustrates state changes, 1693 together with the causing events and resulting actions. Note that 1694 some of the error conditions are not shown in the state diagram. Full 1695 descriptions of all special cases are found in the text. 1697 Note: Chunk names are given in all capital letters, while parameter 1698 names have the first letter capitalized, e.g., COOKIE ECHO chunk type 1699 vs. State Cookie parameter. 1701 ----- -------- (from any state) 1702 / \ / rcv ABORT [ABORT] 1703 rcv SINIT | | | ---------- or ---------- 1704 --------------- | v v delete TCB snd ABORT 1705 generate Cookie \ +---------+ delete TCB 1706 snd SINIT ACK ---| CLOSED | 1707 +---------+ 1708 / \ [Session] 1709 / \ --------------- 1710 | | create TCB 1711 | | snd SINIT 1712 | | start sinit timer 1713 rcv valid | | 1714 COOKIE ECHO | v 1715 (1) ---------------- | +------------+ 1716 create TCB | | COOKIE-WAIT| (2) 1717 snd COOKIE ACK | +------------+ 1718 | | 1719 | | rcv SINIT ACK 1720 | | ----------------- 1721 | | send COOKIE ECHO 1722 | | stop sinit timer 1723 | | start cookie timer 1724 | v 1725 | +--------------+ 1726 | | COOKIE-ECHOED| (3) 1727 | +--------------+ 1728 | | 1729 | | rcv COOKIE ACK 1730 | | ----------------- 1731 | | stop cookie timer 1732 v v 1733 +---------------+ 1734 | ESTABLISHED | 1735 +---------------+ 1736 | 1737 | 1738 /--------+--------\ 1739 [SSHUTDOWN] / \ 1740 -----------------| | 1741 ack outstanding | | 1742 DATA packets | | 1743 v | 1744 +---------+ | 1745 |SSHUTDOWN| | rcv SSHUTDOWN 1746 |PENDING | |------------------ 1747 +---------+ | check outstanding 1748 | | DATA packets 1749 No more outstanding| | 1750 -------------------| | 1751 send SSHUTDOWN | | 1752 start sshutdown | | 1753 timer v v 1754 +---------+ +-----------+ 1755 (4) |SSHUTDOWN| | SSHUTDOWN | (5,6) 1756 |SENT | | RECEIVED | 1757 +---------+ +-----------+ 1758 | | 1759 rcv SSHUTDOWN ACK | |No more outstanding 1760 -------------------| |------------------- 1761 stop sshutdown timer| |send SSHUTDOWN ACK 1762 send SSHUTDOWN | |start shutdown timer 1763 COMPLETE delete TCB | | 1764 | | 1765 | | 1766 | | 1767 | +-----------+ 1768 | | SSHUTDOWN | (7) 1769 | | ACK-SENT | 1770 | +-----------+ 1771 | | rcv SSHUTDOWN COMPLETE 1772 | |----------------------- 1773 | | stop shutdown timer 1774 | | delete TCB 1775 | | 1776 | | 1777 \ +---------+ / 1778 \-->| CLOSED |<--/ 1779 +---------+ 1780 Notes: 1782 1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., 1783 failed to pass the integrity check), the receiver MUST silently 1784 discard the packet. Or, if the received State Cookie is expired (see 1785 section 10.1.4), the receiver MUST send back an ERROR chunk. In 1786 either case, the receiver stays in the CLOSED state. 1788 2) If the T1-init timer expires, the agent MUST retransmit SINIT and 1789 restart the T1-init timer without changing state. This MUST be 1790 repeated up to 'Max.Init.Retransmits' times. After that, the agent 1791 MUST abort the initialization process and report the error to the 1792 MPMTP-AR user. 1794 3) If the T1-cookie timer expires, the agent MUST retransmit COOKIE 1795 ECHO and restart the T1-cookie timer without changing state. This 1796 MUST be repeated up to 'MAX Init Retransmits' times. After that, the 1797 agent MUST abort the initialization process and report the error to 1798 the MPMTP-AR user. After that, the agent MUST abort the 1799 initialization process and report the error to the MPMTP-AR user. 1801 4) In the ESTABLISHMENT state, if the agent is the receiver of DATA 1802 packet and receives [SSHUTDOWN] from application or SSHUTDOWN from 1803 the peer agent, it should check outstanding DATA packet before sends 1804 a response. 1806 5) In the SSHUTDOWN-SENT state, the agent MUST response any received 1807 control chunks without delay. 1809 6) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any 1810 new send requests from its SCTP user. 1812 7) In the SSHUTDOWN-RECEIVED state, the agent MUST leave this state 1813 when all data in queue is ordered. 1815 8) In the SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any 1816 new send requests from its SCTP user. 1818 The CLOSED state is used to indicate that a session is not created 1819 (i.e., doesn't exist). 1821 10. Session Initialization 1823 Before the first data transmission can take place from one MPMTP-AR 1824 agent ("A") to another MPMTP-AR agent ("Z"), the two endpoints must 1825 complete a session process in order to set up an MPMTP-AR session 1826 between them. 1828 The MPMTP-AR user at an agent should use the SESSION primitive to 1829 initialize an MPMTP-AR session to another MPMTP-AR agent. 1831 IMPLEMENTATION NOTE: From an MPMTP-AR user's point of view, a session 1832 may be implicitly opened, without a SESSION primitive being invoked, 1833 by the initiating agent's sending of the first user data to the 1834 destination agent. The initiating MPMTP-AR will assume default values 1835 for all mandatory and optional parameters for the SINIT/SINIT ACK. 1837 Once the session is established, unidirectional path is open for data 1838 transfer (see section 10.1.1). Then according to the parameters 1839 negotiated at session, MPMTP-AR agent A can use subflow after 1840 notifying agent Z. 1842 10.1 Normal Establishment of a Session 1844 The initialization process consists of the following steps (assuming 1845 that MPMTP-AR agent "A" tries to set up a session with MPMTP-AR agent 1846 "Z" and "Z" accepts the new session): 1848 A) "A" first sends an SINIT chunk to "Z". In the SINIT, "A" must 1849 After sending the SINIT, "A" starts the T1-init timer and enters the 1850 COOKIE-WAIT state. 1852 B) "Z" shall respond immediately with an SINIT ACK chunk. Moreover, 1853 "Z" MUST generate and send along with the SINIT ACK a State Cookie. 1854 See section 10.1.3 for State Cookie generation. 1856 Note: After sending out SINIT ACK with the State Cookie parameter, 1857 "Z" MUST NOT allocate any resources or keep any states for the new 1858 session. Otherwise, "Z" will be vulnerable to resource attacks. 1860 C) Upon reception of the SINIT ACK from "Z", "A" shall stop the T1- 1861 init timer and leave the COOKIE-WAIT state. "A" shall then send the 1862 State Cookie received in the SINIT ACK chunk in a COOKIE ECHO chunk, 1863 start the T1-cookie timer, and enter the COOKIE-ECHOED state. 1865 D) Upon reception of the COOKIE ECHO chunk, agent "Z" will reply with 1866 a COOKIE ACK chunk after building a TCB and moving to the ESTABLISHED 1867 state. 1869 IMPLEMENTATION NOTE: An implementation may choose to send the 1870 Communication Up notification to the MPMTP-AR user upon reception of 1871 a valid COOKIE ECHO chunk. 1873 E) Upon reception of the COOKIE ACK, agent "A" will move from the 1874 COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-cookie 1875 timer. It may also notify its ULP about the successful establishment 1876 of the association with a Communication Up notification. 1878 An agent MUST send the SINIT ACK to the agent from which it received 1879 the SINIT. 1881 Note: T1-init timer and T1-cookie timer shall follow the same rules 1882 given in section 11.3. 1884 If an agent receives an SINIT, SINIT ACK, or COOKIE ECHO chunk but 1885 decides not to establish the new session due to missing mandatory 1886 parameters in the received SINIT or SINIT ACK, invalid parameter 1887 values, or lack of local resources, it SHOULD respond with an ABORT 1888 chunk. It SHOULD also specify the cause of abort, such as the type of 1889 the missing mandatory parameters, etc., by including the error cause 1890 parameters with the ABORT chunk. 1892 Note that a COOKIE ECHO chunk that does NOT pass the integrity check 1893 is NOT considered an 'invalid parameter' and requires special 1894 handling; see section 10.1.4. 1896 After the reception of the first DATA chunk in a session the agent 1897 MUST immediately respond with a SACK to acknowledge the DATA chunk. 1898 Subsequent acknowledgements should be done as described in section 1899 11.2. 1901 When the TCB is created, each agent MUST set its internal Cumulative 1902 TSN Ack Point to the value of its transmitted Initial TSN minus one. 1904 10.1.1 Handle Path Parameters 1906 In the SINIT and SINIT ACK chunks, the sender of the chunk MUST 1907 indicate the number of outbound/inbound subflow and MSN it wishes to 1908 use in the session. 1910 After receiving the session configuration information from the other 1911 side, MPMTP-AR agent MUST perform the following check: If the peer's 1912 number outbound subflow (NOS) is less than the local maximum number 1913 inbound subflow (MIS), meaning that the peer is incapable of 1914 supporting all the outbound subflow the agent wants to configure, the 1915 agent MUST use MIS and MAY report any shortage to the MPMTP-AR user. 1916 The MPMTP-AR user can then choose to abort the session if the 1917 resource shortage is unacceptable. 1919 After the session is initialized, the valid outbound subflow 1920 identifier range for either agent shall be 0 to min (local MIS, 1921 remote NOS)-1. 1923 10.1.2 Generating State Cookie 1925 When sending an SINIT ACK as a response to an SINIT chunk, the sender 1926 of SINIT ACK creates a State Cookie and sends it in the State Cookie 1927 parameter of the SINIT ACK. Inside this State Cookie, the sender 1928 should include a MAC (see [RFC2104] for an example), a timestamp when 1929 the State Cookie created, and the lifespan of the State Cookie, along 1930 with all the information necessary for it to establish the session. 1932 The following steps SHOULD be taken to generate the State Cookie: 1934 1) Create session TCB using information from both the received SINIT 1935 and the outgoing SINIT ACK chunk. 1937 2) In the TCB, set the creation time to the current time of day, and 1938 the lifespan to the protocol parameter 'Valid.Cookie.Life'. 1940 3) From the TCB, identify and collect the minimal subset of 1941 information needed to re-create the TCB, and generate a MAC using 1942 this subset of information and a secret key (see [RFC2104] for an 1943 example of generating a MAC). 1945 4) Generate the State Cookie by combining this subset of information 1946 and the resultant MAC. 1948 After sending the SINIT ACK with the State Cookie parameter, the 1949 sender SHOULD delete the TCB and any other local resource related to 1950 the new session, so as to prevent resource attacks. 1952 The hashing method used to generate the MAC is strictly a private 1953 matter for the receiver of the INIT chunk. The use of a MAC is 1954 mandatory to prevent denial-of-service attacks. The secret key SHOULD 1955 be random ([RFC4086] provides some information on randomness 1956 guidelines); it SHOULD be changed reasonably frequently, and the 1957 timestamp in the State Cookie MAY be used to determine which key 1958 should be used to verify the MAC. 1960 An implementation SHOULD make the cookie as small as possible to 1961 ensure interoperability. 1963 10.1.3 State Cookie Processing 1965 When an agent (in the COOKIE-WAIT state) receives an SINIT ACK chunk 1966 with a State Cookie parameter, it MUST immediately send a COOKIE ECHO 1967 chunk to its peer with the received State Cookie. 1969 The agent shall also start the T1-cookie timer after sending out the 1970 COOKIE ECHO chunk. If the timer expires, the agent shall retransmit 1971 the COOKIE ECHO chunk and restart the T1-cookie timer. This is 1972 repeated until either a COOKIE ACK is received or 'Max.Init. 1973 Retransmits' is reached causing the peer agent to be marked 1974 unreachable (and thus the session enters the CLOSED state). 1976 10.1.4 State Cookie Authentication 1978 When an agent receives a COOKIE ECHO chunk from another agent with 1979 which it has no session, it shall take the following actions: 1981 1) Compute a MAC using the TCB data carried in the State Cookie and 1982 the secret key (note the timestamp in the State Cookie MAY be used to 1983 determine which secret key to use). [RFC2104] can be used as a 1984 guideline for generating the MAC, 1986 2) Authenticate the State Cookie as one that it previously generated 1987 by comparing the computed MAC against the one carried in the State 1988 Cookie. If this comparison fails, the MPMTP-AR packet, including the 1989 COOKIE ECHO and any DATA packets, should be silently discarded. 1991 3) Compare the creation timestamp in the State Cookie to the current 1992 local time. If the elapsed time is longer than the lifespan carried 1993 in the State Cookie, then the packet, including the COOKIE ECHO and 1994 any attached DATA packets, SHOULD be discarded, and the agent MUST 1995 transmit an ERROR chunk with a "Stale Cookie" error cause to the peer 1996 agent. 1998 4) If the State Cookie is valid, create an session to the sender of 1999 the COOKIE ECHO chunk with the information in the TCB data carried in 2000 the COOKIE ECHO and enter the ESTABLISHED state. 2002 5) Send a COOKIE ACK chunk to the peer acknowledging receipt of the 2003 COOKIE ECHO. 2005 If a COOKIE ECHO is received from an agent with which the receiver of 2006 the COOKIE ECHO has an existing session, the procedures in section 2007 10.2 should be followed. 2009 10.1.5 Open Subflow 2011 When an agent wants to use a new subflow, before data transmission it 2012 needs to notify the peer path information. 2014 When an agent receives a SubINIT from another agent with which it 2015 associates an session, it shall take the following actions: 2017 1) Check subflow parameter and session information; 2019 2) Send response. If it is valid, the receiver sends SubINIT ACK to 2020 the sender; otherwise, the receiver MUST transmit an ERROR chunk with 2021 an error cause to the peer agent. 2023 If the sender receives a SUBFLOW INIT ACK response, it can use this 2024 sublfow to transmit data; otherwise it SHOULD terminal this subflow 2025 request. 2027 10.2 Handle Duplication or Unexpected Issue 2029 During the life time of a session (in one of the possible states), an 2030 agent may receive from its peer agent one of the setup chunks (SINIT, 2031 SINIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat 2032 such a setup chunk as a duplicate and process it as described in this 2033 section. 2035 Note: An agent will not receive the chunk unless the chunk was from 2036 an MPMTP-AR agent associated with this agent. Therefore, the agent 2037 processes such a chunk as part of its current session. 2039 The following scenarios can cause duplicated or unexpected chunks: 2041 A) The peer has crashed without being detected, restarted itself, and 2042 sent out a new SINIT chunk trying to restore the session, 2044 B) The chunk is from stale packet that was used to establish the 2045 present session or a past session that is no longer in existence, 2047 C) The chunk is a false packet generated by an attacker, 2049 D) The peer never received the COOKIE ACK and is retransmitting its 2050 COOKIE ECHO. 2052 The rules in the following sections shall be applied in order to 2053 identify and correctly handle these cases. 2055 10.2.1 Unexpected SINIT in States Other than CLOSED, COOKIE-ECHOED, 2056 COOKIE-WAIT, and SSHUTDOWN-ACK-SENT 2057 Unless otherwise stated, upon receipt of an unexpected SINIT for this 2058 session, the agent shall generate an SINIT ACK with a State Cookie. 2059 Before responding, the agent MUST check to see if the unexpected 2060 SINIT adds new parameters to the session. If new parameters are added 2061 to the session, the agent MUST respond with an ABORT. Parameters for 2062 the agent SHOULD be copied from the existing parameters of the 2063 session and be inserted into the SINIT ACK and cookie. 2065 After sending out the SINIT ACK or ABORT, the agent shall take no 2066 further actions; i.e., the existing session, including its current 2067 state; and the corresponding TCB MUST NOT be changed. 2069 10.2.2 Unexpected SINIT ACK 2071 If an SINIT ACK is received by an agent in any state other than the 2072 COOKIE-WAIT state, the agent should discard the SINIT ACK chunk. An 2073 unexpected SINIT ACK usually indicates the processing of an old or 2074 duplicated SINIT chunk. 2076 10.2.3 Handle a COOKIE ECHO when a TCB Exists 2078 When a COOKIE ECHO chunk is received by an agent in any state for an 2079 existing session (i.e., not in the CLOSED state) the following rules 2080 shall be applied: 2082 1) Compute a MAC as described in step 1 of section 10.1.4, 2084 2) Authenticate the State Cookie as described in step 2 of section 2085 10.1.4, 2087 3) Compare the timestamp in the State Cookie to the current time. If 2088 the State Cookie is older than the lifespan carried in the State 2089 Cookie and the Session ID contained in the State Cookie do not match 2090 the current session's Session ID, the packet should be discarded. The 2091 agent also MUST transmit an ERROR chunk with a "Stale Cookie" error 2092 cause to the peer agent. 2094 4) If the State Cookie proves to be valid, unpack the TCB into a 2095 temporary TCB. 2097 10.2.4 Handle Duplicate COOKIE-ACK 2099 At any state other than COOKIE-ECHOED, an agent should silently 2100 discard a received COOKIE ACK chunk. 2102 10.2.5 Handle Stale COOKIE Error 2104 Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates 2105 one of a number of possible events: 2107 A) The session failed to completely setup before the State Cookie 2108 issued by the sender was processed. 2110 B) An old State Cookie was processed after setup completed. 2112 C) An old State Cookie is received from someone that the receiver is 2113 not interested in having a session with and the ABORT chunk was lost. 2115 When processing an ERROR chunk with a "Stale Cookie" error cause an 2116 agent should first examine if a session is in the process of being 2117 set up, i.e., the session is in the COOKIE-ECHOED state. In all 2118 cases, if the session is not in the COOKIE-ECHOED state, the ERROR 2119 chunk should be silently discarded. 2121 If the session is in the COOKIE-ECHOED state, the agent may elect one 2122 of the following three alternatives. 2124 1) Send a new SINIT chunk to the agent to generate a new State Cookie 2125 and reattempt the setup procedure. 2127 2) Discard the TCB and report to the MPMTP-AR user the inability to 2128 set up the session. 2130 3) Send a new SINIT chunk to the agent, adding a Cookie Preservative 2131 parameter requesting an extension to the life time of the State 2132 Cookie. When calculating the time extension, an implementation SHOULD 2133 use the RTT information measured based on the previous COOKIE 2134 ECHO/ERROR exchange, and should add no more than 1 second beyond the 2135 measured RTT, due to long State Cookie life time making the agent 2136 more subject to a replay attack. 2138 11. User Data Transfer 2140 Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN- 2141 PENDING states. 2143 DATA packet MUST only be received according to the rules below in 2144 ESTABLISHED, SSHUTDOWN-PENDING, and SSHUTDOWN-SENT. A DATA packet 2145 received in any other state SHOULD be discarded. 2147 A SACK MUST be processed in ESTABLISHED, and SSHUTDOWN-PENDING. A 2148 SACK in the CLOSED state is out of the blue and SHOULD be processed 2149 according to the rules in section 13.3. A SACK packet received in any 2150 other state SHOULD be discarded. 2152 An MPMTP-AR receiver MUST be able to receive a minimum of 1500 bytes 2153 in one MPMTP-AR packet. This means that an MPMTP-AR agent MUST NOT 2154 indicate less than 1500 bytes in its initial a_rwnd sent in the SINIT 2155 ACK. 2157 Notes: When converting user messages into DATA chunks, an agent will 2158 fragment user messages larger than the current session path MTU into 2159 multiple DATA chunks. The data receiver will normally reassemble the 2160 fragmented message from DATA chunks before delivery to the user (see 2161 section 11.7 for details). 2163 11.1 Transmission of DATA Packet 2165 This document is specified as if there is a single retransmission 2166 timer per subflow, but implementations MAY have a retransmission 2167 timer for each DATA packet. 2169 The following general rules MUST be applied by the sender for 2170 transmission and/or retransmission of outbound DATA packet: 2172 A) At any given time, the data sender MUST NOT transmit new data if 2173 its peer's rwnd indicates that the peer has no buffer space (i.e., 2174 rwnd is 0). However, regardless of the value of rwnd (including if it 2175 is 0), the data sender can always have one DATA packet in flight to 2176 the receiver if allowed by congestion window (cwnd). This rule allows 2177 the sender to probe for a change in rwnd that the sender missed due 2178 to the SACK's having been lost in transit from the data receiver to 2179 the data sender. 2181 When the receiver's advertised window is zero, this probe is called a 2182 zero window probe. Note that a zero window probe SHOULD only be sent 2183 when all outstanding DATA packet have been cumulatively acknowledged 2184 and no DATA packet are in flight. Zero window probing MUST be 2185 supported. 2187 Refer to section 11.2 on the receiver behavior when it advertises a 2188 zero window. The sender SHOULD send the first zero window to probe 2189 after 1 RTO when it detects that the receiver has closed its window 2190 and SHOULD increase the probe interval exponentially afterwards. Also 2191 note that the cwnd SHOULD be adjusted according to section 12.2.1. 2192 Zero window probing does not affect the calculation of cwnd. 2194 The sender MUST also have an algorithm for sending new DATA packets 2195 to avoid silly window syndrome (SWS) as described in [RFC0813]. The 2196 algorithm can be similar to the one described in section 4.2.3.4 of 2197 [RFC1122]. 2199 B) At any given time, the sender MUST NOT transmit new data to the 2200 receiver if it has cwnd or more bytes of data outstanding to the 2201 receiver. 2203 C) When the time comes for the sender to transmit, before sending new 2204 DATA packet, the sender MUST first transmit any outstanding DATA 2205 packets that are marked for retransmission (limited by the current 2206 cwnd). 2208 D) When the time comes for the sender to transmit new DATA packets, 2209 the protocol parameter Max.Burst SHOULD be used to limit the number 2210 of packets sent. The limit MAY be applied by adjusting cwnd as 2211 follows: 2213 if((flightsize + Max.Burst*MTU) < cwnd) 2214 cwnd = flightsize +Max.Burst*MTU 2216 Or it MAY be applied by strictly limiting the number of 2217 packets emitted by the output routine. 2219 E) Then, the sender can send out as many new DATA packet as rule A 2220 and rule B allow. 2222 IMPLEMENTATION NOTE: When the window is full, the sender MUST 2223 transmit no more DATA packet until some or all of the outstanding 2224 DATA packet are acknowledged and transmission is allowed by rule A 2225 and rule B again. 2227 Whenever a transmission or retransmission is made, the sender MUST 2228 start T3-rtx timer. If the timer is already running, the sender MUST 2229 restart the timer if the earliest (i.e., lowest TSN) outstanding DATA 2230 packet is being retransmitted. Otherwise, the data sender MUST NOT 2231 restart the timer. 2233 When starting or restarting the T3-rtx timer, the timer value must be 2234 adjusted according to the timer rules defined in Sections 11.3.2 and 2235 11.3.3. 2237 Note: The data sender SHOULD NOT use a TSN that is more than 2**31-1 2238 above the beginning TSN of the current send window. 2240 11.2 Acknowledge on Reception of DATA Packets 2242 The MPMTP-AR agent MUST always acknowledge the reception of each 2243 valid DATA packet when the DATA packet received is inside its receive 2244 window. 2246 When the receiver's advertised window is 0, the receiver MUST drop 2247 any new incoming DATA packet with a TSN larger than the largest TSN 2248 received so far. If the new incoming DATA packet holds a TSN value 2249 less than the largest TSN received so far, then the receiver SHOULD 2250 drop the largest TSN held for reordering and accept the new incoming 2251 DATA packet. In either case, if such a DATA packet is dropped, the 2252 receiver MUST immediately send back a SACK with the current receive 2253 window showing only DATA chunks received and accepted so far. The 2254 dropped DATA packet(s) MUST NOT be included in the SACK, as they were 2255 not accepted. The receiver MUST also have an algorithm for 2256 advertising its receive window to avoid receiver silly window 2257 syndrome (SWS), as described in [RFC0813]. The algorithm can be 2258 similar to the one described in section 4.2.3.3 of [RFC1122]. 2260 The guidelines on delayed acknowledgement algorithm specified in 2261 section 4.2 of [RFC2581] SHOULD be followed. Specifically, an 2262 acknowledgement SHOULD be generated for at least every second packet 2263 (not every second DATA packet) received, and SHOULD be generated 2264 within 200 ms of the arrival of any unacknowledged DATA packet. In 2265 some situations, it may be beneficial for an MPMTP-AR transmitter to 2266 be more conservative than the algorithms detailed in this document 2267 allow. However, an MPMTP-AR transmitter MUST NOT be more aggressive 2268 than the following algorithms allow. 2270 An MPMTP-AR receiver MUST NOT generate more than one SACK for every 2271 incoming packet, other than to update the offered window as the 2272 receiving application consumes new data. 2274 IMPLEMENTATION NOTE: The maximum delay for generating an 2275 acknowledgement may be configured by the MPMTP-AR administrator, 2276 either statically or dynamically, in order to meet the specific 2277 timing requirement of the protocol being carried. 2279 An implementation MUST NOT allow the maximum delay to be configured 2280 to be more than 500 ms. In other words, an implementation MAY lower 2281 this value below 500 ms but MUST NOT raise it above 500 ms. 2283 Acknowledgements MUST be sent in SACK chunks unless session-level 2284 shutdown was requested by user, in which case an agent MAY send an 2285 acknowledgement in the session-level SSHUTDOWN chunk. A SACK chunk 2286 can acknowledge the reception of multiple DATA packets.See section 2287 8.4.10 for SACK chunk format. In particular, the MPMTP-AR agent MUST 2288 fill in the Cumulative TSN Ack field to indicate the latest 2289 sequential TSN (of a valid DATA packet) it has received. Any received 2290 DATA packets with TSN greater than the value in the Cumulative TSN 2291 Ack field are reported in the Gap Ack Block fields. The MPMTP-AR 2292 agent MUST report as many Gap Ack Blocks as can fit in a single SACK 2293 chunk limited by the current path MTU. 2295 When a packet arrives with duplicate DATA packet, the agent MUST 2296 immediately send a SACK with no delay. The duplicate TSN number(s) 2297 SHOULD be reported in the SACK as duplicate. 2299 When an agent receives a SACK, it MAY use the duplicate TSN 2300 information to determine if SACK loss is occurring. Further use of 2301 this data is for future study. 2303 The data receiver is responsible for maintaining its receive buffers. 2304 The data receiver SHOULD notify the data sender in a timely manner of 2305 changes in its ability to receive data. How an implementation manages 2306 its receive buffers is dependent on many factors (e.g., operating 2307 system, memory management system, amount of memory, etc.). However, 2308 the data sender strategy defined in section 11.2.1 is based on the 2309 assumption of receiver operation similar to the following: 2311 A) At initialization of the session, the agent notify the peer the 2312 number of receive buffer space allocated to the session by SINIT ACK. 2313 The agent sets a_rwnd to this value. 2315 B) As DATA packets are received and buffered, decrement a_rwnd by the 2316 number of bytes received and buffered. This is, in effect, closing 2317 rwnd at the data sender and restricting the amount of data it can 2318 transmit. 2320 C) As DATA packets are delivered to the MPMTP-AR user and released 2321 from the receive buffers, increment a_rwnd by the number of bytes. 2322 This is, in effect, opening up rwnd on the data sender and allowing 2323 it to send more data. The data receiver SHOULD NOT increment a_rwnd 2324 unless it has released bytes from its receive buffer. For example, if 2325 the receiver is holding fragmented DATA packets in a reassembly 2326 queue,it should not increment a_rwnd. 2328 D) When sending a SACK, the data receiver SHOULD place the current 2329 value of a_rwnd into the a_rwnd field. The data receiver SHOULD take 2330 into account that the data sender will not retransmit DATA packets 2331 that are acked via the Cumulative TSN Ack (i.e., will drop from its 2332 retransmit queue). 2334 Under certain circumstances, the data receiver may need to drop DATA 2335 packets that it has received but hasn't released from its receive 2336 buffers (i.e., delivered to the MPMTP-AR user). These DATA packets 2337 may have been acked in Gap Ack Blocks. For example, the data receiver 2338 may be holding data in its receive buffers while reassembling a 2339 fragmented user message from its peer when it runs out of receive 2340 buffer space. It may drop these DATA packets even though it has 2341 acknowledged them in Gap Ack Blocks. If a data receiver drops DATA 2342 packets, it MUST NOT include them in Gap Ack Blocks in subsequent 2343 SACKs until they are received again via retransmission. In addition, 2344 the agent should take into account the dropped data when calculating 2345 its a_rwnd. 2347 An agent SHOULD NOT revoke a SACK and discard data. Only in extreme 2348 circumstances should an agent use this procedure (such as out of 2349 buffer space). The data receiver should take into account that 2350 dropping data that has been acked in Gap Ack Blocks can result in 2351 suboptimal retransmission strategies in the data sender and thus in 2352 suboptimal performance. 2354 If an agent receives a DATA packet with no user data (i.e., the 2355 Length field is set to 16), it MUST send an ABORT with error cause 2356 set to "No User Data". 2358 An agent SHOULD NOT send a DATA packet with no user data. 2360 11.2.1 Processing a Received SACK 2362 Each SACK the agent receives contains an a_rwnd value. This value 2363 represents the amount of buffer space the data receiver, at the time 2364 of transmitting the SACK, has left of its total receive buffer space 2365 (as specified in the SINIT/SINIT ACK). Using a_rwnd, Cumulative TSN 2366 Ack, and Gap Ack Blocks, the data sender can develop a representation 2367 of the peer's receive buffer space. 2369 One of the problems the data sender must take into account when 2370 processing a SACK is that a SACK can be received out of order. That 2371 is, a SACK sent by the data receiver can pass an earlier SACK and be 2372 received first by the data sender. If a SACK is received out of 2373 order, the data sender can develop an incorrect view of the peer's 2374 receive buffer space. 2376 Since there is no explicit identifier that can be used to detect out- 2377 of-order SACKs, the data sender must use heuristics to determine if a 2378 SACK is new. 2380 An agent SHOULD use the following rules to calculate the rwnd, using 2381 the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in a 2382 received SACK. 2384 A) At the establishment of the session, the agent initializes the 2385 rwnd to the Advertised Receiver Window Credit (a_rwnd) the peer 2386 specified in the SINIT or SINIT ACK. 2388 B) Any time a DATA packet is transmitted (or retransmitted) to a 2389 peer,the agent subtracts the data size of the packet from the rwnd of 2390 that peer. 2392 C) Any time a DATA packet is marked for retransmission, either via 2393 T3-rtx timer expiration (section 11.3.3) or via Fast Retransmit 2394 (section 12.2.4); add the data size of those packets to the rwnd. 2396 Note: If the implementation is maintaining a timer on each DATA 2397 packet, then only DATA packets whose timer expired would be marked 2398 for retransmission. 2400 D) Any time a SACK arrives, the agent performs the following: 2402 i) If Cumulative TSN Ack is less than the Cumulative TSN Ack 2403 Point, then drop the SACK. Since Cumulative TSN Ack is 2404 monotonically increasing, a SACK whose Cumulative TSN Ack is less 2405 than the Cumulative TSN Ack Point indicates an out-of-order SACK. 2407 ii) Set rwnd equal to the newly received a_rwnd minus the number 2408 of bytes still outstanding after processing the Cumulative TSN Ack 2409 and the Gap Ack Blocks. 2411 iii) If the SACK is missing a TSN that was previously acknowledged 2412 via a Gap Ack Block (e.g., the data receiver reneged on the data), 2413 then consider the corresponding DATA that might be possibly 2414 missing. Count one miss indication towards Fast Retransmit as 2415 described in section 12.2.4, and if no retransmit timer is running 2416 for the subflow to which the DATA packet was originally 2417 transmitted, then T3-rtx is started for that subflow. 2419 iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery 2420 exitpoint (section 12.2.4), Fast Recovery is exited. 2422 11.3 Management of Retransmission Timer 2424 An MPMTP-AR agent uses a retransmission timer T3-rtx to ensure data 2425 delivery in the absence of any feedback from its peer. The duration 2426 of this timer is referred to as RTO (retransmission timeout). 2428 When an session is multi-subflows, the agent will calculate a 2429 separate RTO for each subflow. 2431 The computation and management of RTO in MPMTP-AR follow closely how 2432 TCP manages its retransmission timer. To compute the current RTO, an 2433 agent maintains two state variables per subflow: SRTT (smoothed 2434 round-trip time) and RTTVAR (round-trip time variation). 2436 11.3.1 RTO Calculation 2438 The rules governing the computation of SRTT, RTTVAR, and RTO are as 2439 follows: 2441 C1)Until an RTT measurement has been made for a packet sent to the 2442 given subflow, set RTO to the protocol parameter 'RTO.Initial'. 2444 C2)When the first RTT measurement R is made, set SRTT <- R, 2445 RTTVAR <- R/2, and RTO <- SRTT + 4 * RTTVAR. 2447 C3) When a new RTT measurement R' is made, set RTTVAR <- (1 - 2448 RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| and SRTT <- (1 - 2449 RTO.Alpha) * SRTT + RTO.Alpha * R' 2451 Note: The value of SRTT used in the update to RTTVAR is its value 2452 before updating SRTT itself using the second assignment. 2454 After the computation, update RTO <- SRTT + 4 * RTTVAR. 2456 C4)When data is in flight and when allowed by rule C5 below, a new 2457 RTT measurement MUST be made each round trip. Furthermore, new RTT 2458 measurements SHOULD be made no more than once per round trip for a 2459 given subflow. There are two reasons for this recommendation: First, 2460 it appears that measuring more frequently often does not in practice 2461 yield any significant benefit [ALLMAN99]; second, if measurements are 2462 made more often, then the values of RTO.Alpha and RTO.Beta in rule C3 2463 above should be adjusted so that SRTT and RTTVAR still adjust to 2464 changes at roughly the same rate (in terms of how many round trips it 2465 takes them to reflect new values) as they would if making only one 2466 measurement per round-trip and using RTO.Alpha and RTO.Beta as given 2467 in rule C3. However, the exact nature of these adjustments remains a 2468 research issue. 2470 C5)Karn's algorithm: RTT measurements MUST NOT be made using packets 2471 that were retransmitted (and thus for which it is ambiguous whether 2472 the reply was for the first instance of the packet or for a later 2473 instance) 2475 IMPLEMENTATION NOTE: RTT measurements should only be made using a 2476 packet with TSN r if no packet with TSN less than or equal to r is 2477 retransmitted since r is first sent. 2479 C6)Whenever RTO is computed, if it is less than RTO.Min seconds then 2480 it is rounded up to RTO.Min seconds. The reason for this rule is that 2481 RTOs that do not have a high minimum value are susceptible to 2482 unnecessary timeouts [ALLMAN99]. 2484 C7) A maximum value may be placed on RTO provided it is at least 2485 RTO.max seconds. 2487 There is no requirement for the clock granularity G used for 2488 computing RTT measurements and the different state variables, other 2489 than: 2491 G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- 2492 G. Experience [ALLMAN99] has shown that finer clock granularities 2493 (<=100 msec) perform somewhat better than more coarse granularities. 2495 11.3.2 Retransmission Timer Rules 2497 The rules for managing the retransmission timer are as follows: 2499 R1)Every time a DATA packet is sent to subflow (including a 2500 retransmission), if the T3-rtx timer of that subflow is not running, 2501 start it running so that it will expire after the RTO of that 2502 subflow. The RTO used here is that obtained after any doubling due to 2503 revious T3-rtx timer expirations on the corresponding subflow as 2504 discussed in rule E2 below. 2506 R2)Whenever all outstanding data sent to subflow have been 2507 acknowledged, turn off the T3-rtx timer of that subflow. 2509 R3)Whenever a SACK is received that acknowledges the DATA packet with 2510 the earliest outstanding TSN for that subflow, restart the T3-rtx 2511 timer for that subflow with its current RTO (if there is still 2512 outstanding data on that subflows). 2514 R4)Whenever a SACK is received missing a TSN that was previously 2515 acknowledged via a Gap Ack Block, start the T3-rtx for the subflow to 2516 which the DATA packet was originally transmitted if it is not already 2517 running. 2519 11.3.3 Handle T3-RTX Expiration 2521 Whenever the retransmission timer T3-rtx expires for a subflow, do 2522 the following: 2524 E1)For the subflow for which the timer expires, adjust its ssthresh 2525 with rules defined in section 12.2.3 and set the cwnd <- MTU. 2527 E2)For the subflow for which the timer expires, set RTO<- RTO * 2 2528 ("back off the timer"). The maximum value discussed in rule C7 above 2529 (RTO.max) may be used to provide an upper bound to this doubling 2530 operation. 2532 E3)Determine how many of the earliest (i.e., lowest TSN) outstanding 2533 DATA packets for the subflow for which the T3-rtx has expired will 2534 fit into a single packet, subject to the MTU constraint for the path 2535 corresponding to the subflow to which the retransmission is being 2536 sent (this may be different from the subflow for which the timer 2537 expires; see section 11.4). Call this value K. 2539 E4)Start the retransmission timer T3-rtx on the subflow to which the 2540 retransmission is sent, if rule R1 above indicates to do so. The RTO 2541 to be used for starting T3-rtx should be the one for the subflow to 2542 which the retransmission is sent, may be different from the subflow 2543 for which the timer expired (see section 11.4 below). 2545 After retransmitting, once a new RTT measurement is obtained (which 2546 can happen only when new data has been sent and acknowledged, per 2547 rule C5, or for a measurement made from a HEARTBEAT; see section 2548 11.3), the computation in rule C3 is performed, including the 2549 computation of RTO, which may result in "collapsing" RTO back down 2550 after it has been subject to doubling (rule E2). 2552 Note: Any DATA packets that were sent to the subflow for which the 2553 T3-rtx timer expired but did not fit in one MTU (rule E3 above) 2554 should be marked for retransmission and sent as soon as cwnd allows 2555 (normally, when a SACK arrives). 2557 E5)Whenever an agent switches from the current subflow to a different 2558 one, the current retransmission timers are left running. As soon as 2559 the agent transmits a packet containing DATA packet to the new 2560 subflow, start the timer on that subflow, using the RTO value of the 2561 subflow to which the data is being sent, if rule R1 indicates to do 2562 so. 2564 11.4 Path Identifier and Specific-Subflow Sequence Number 2566 Every DATA packet MUST carry a valid path identifier. If an agent 2567 receives a DATA packet with an invalid path identifier, it shall 2568 acknowledge the reception of the DATA packet following the normal 2569 procedure, immediately send an ERROR packet with cause set to 2570 "Invalid Path Identifier", and discard the DATA packet. 2572 The Specific-Subflow Sequence Number of all subflows MUST start from 2573 0 when the session is established. Also, when the Specific-Subflow 2574 Sequence Number reaches the value 65535 the next Specific-Subflow 2575 Sequence Number MUST be set to 0. 2577 11.5 Ordered and Unordered Delivery 2579 Within a session, an agent MUST deliver DATA packets received with 2580 the U flag set to 0 to the user according to the order of their 2581 Transmission Sequence Number. If DATA packets arrive out of order of 2582 their Transmission Sequence Number, the agent MUST hold the received 2583 DATA packets from delivery to the user until they are reordered. 2585 However, an MPMTP-AR agent can indicate that no ordered delivery is 2586 required for a particular DATA packet transmitted within the session 2587 by setting the U flag of the DATA packet to 1. 2589 When an agent receives a DATA packet with the U flag set to 1, it 2590 must bypass the ordering mechanism and immediately deliver the data 2591 to the user (after reassembly if the user data is fragmented by the 2592 data sender). 2594 This provides an effective way of transmitting "out-of-band" data in 2595 a given subflow. Also, a message can be used as an "unordered" by 2596 simply setting the U flag to 1 in all DATA packets sent in the 2597 session. 2599 IMPLEMENTATION NOTE: When sending an unordered DATA packet, an 2600 implementation may choose to place the DATA packet in an outbound 2601 packet that is at the head of the outbound transmission queue if 2602 possible. 2604 The 'Transmission Sequence Number' field in a DATA packet with U flag 2605 set to 1 has no significance. The sender can fill it with arbitrary 2606 value, but the receiver MUST ignore the field. 2608 Note: When transmitting unordered data, an agent does not increment 2609 its Transmission Sequence Number. 2611 11.6 Report Gaps in Received DATA TSNs 2613 Upon the reception of a new DATA packet, an agent shall examine the 2614 continuity of the TSNs received. If the agent detects a gap in the 2615 received DATA packet sequence, it SHOULD send a SACK with Gap Ack 2616 Blocks immediately. The data receiver continues sending a SACK after 2617 receipt of each MPMTP-AR packet that doesn't fill the gap. 2619 Based on the Gap Ack Block from the received SACK, the agent can 2620 calculate the missing DATA packets and make decisions on whether to 2621 retransmit them (see section 11.2.1 for details). 2623 Multiple gaps can be reported in one single SACK. 2625 When this session uses multipath, the MPMTP-AR agent SHOULD always 2626 try to send the SACK to the sender from default path. 2628 Upon the reception of a SACK, the agent MUST remove all DATA packets 2629 that have been acknowledged by the SACK's Cumulative TSN Ack from its 2630 transmit queue. The agent MUST also treat all the DATA packets with 2631 TSNs not included in the Gap Ack Blocks reported by the SACK as 2632 "missing". The number of "missing" reports for each outstanding DATA 2633 packet MUST be recorded by the data sender in order to make 2634 retransmission decisions. See section 12.2.4 for details. 2636 The maximum number of Gap Ack Blocks that can be reported within a 2637 single SACK chunk is limited by the current path MTU. When a single 2638 SACK cannot cover all the Gap Ack Blocks needed to be reported due to 2639 the MTU limitation, the agent MUST send only one SACK, reporting the 2640 Gap Ack Blocks from the lowest to highest TSNs, within the size limit 2641 set by the MTU, and leave the remaining highest TSN numbers 2642 unacknowledged. 2644 11.7 Fragmentation and Reassembly 2646 An agent MAY support fragmentation when sending DATA packet, but it 2647 MUST support reassembly when receiving DATA packet. If an agent 2648 supports fragmentation, it MUST fragment a user message if the size 2649 of the user message to be sent causes the outbound MPMTP-AR packet 2650 size to exceed the current MTU. If an implementation does not support 2651 fragmentation of outbound user messages, the agent MUST return an 2652 error to its user and not attempt to send the user message. 2654 Note: If an implementation that supports fragmentation makes 2655 available to its user a mechanism to turn off fragmentation, it may 2656 do so. However, in so doing, it MUST react just like an 2657 implementation that does NOT support fragmentation, i.e., it MUST 2658 reject sends that exceed the current Path MTU (P-MTU). 2660 If its session uses multipath, the agent shall choose a size no 2661 larger than the session Path MTU. The session Path MTU is the 2662 smallest Path MTU of all subflows. 2664 Note: Once a message is fragmented, it cannot be refragmented. 2665 Instead, if the path maximum transmission unit (PMTU) has been 2666 reduced, then IP fragmentation must be used. Please see section 12.3 2667 for details of PMTU discovery. 2669 When determining when to fragment, the MPMTP-AR implementation MUST 2670 take into account the MPMTP-AR packet header as well as the DATA 2671 packet header(s). 2673 Fragmentation takes the following steps: 2675 1) The data sender MUST break the user message into a series of DATA 2676 chunks such that each chunk plus MPMTP-AR overhead and UDP header 2677 fits into an IP datagram smaller than or equal to the Path MTU. 2679 2) The transmitter MUST then assign, in sequence, a separate TSN to 2680 each of the DATA chunks in the series. If the user indicates that the 2681 user message is to be delivered using unordered delivery, then the U 2682 flag of each DATA chunk of the user message MUST be set to 1. 2684 3) The transmitter MUST also set the B/E bits of the first DATA chunk 2685 in the series to '10', the B/E bits of the last DATA chunk in the 2686 series to '01', and the B/E bits of all other DATA chunks in the 2687 series to '00'. 2689 An agent MUST recognize fragmented DATA chunks by examining the B/E 2690 bits in each of the received DATA chunks, and queue the fragmented 2691 DATA chunks for reassembly. 2693 Note: If the data receiver runs out of buffer space while still 2694 waiting for more fragments to complete the reassembly of the message, 2695 it should dispatch part of its inbound message through a partial 2696 delivery API, freeing some of its receive buffer space so that the 2697 rest of the message may be received. 2699 12. Congestion Control 2701 Congestion control is one of the basic functions in MPMTP-AR. For 2702 some applications, it may be likely that adequate resources will be 2703 allocated to MPMTP-AR traffic to ensure prompt delivery of time- 2704 critical data, thus, it would appear to be unlikely, during normal 2705 operations, that transmission encounter several congestion 2706 conditions. However, MPMTP-AR must operate under adverse operational 2707 conditions, which can develop upon partial network failures or 2708 unexpected traffic surges. In such situations, MPMTP-AR must follow 2709 correct congestion control steps to recover from congestion quickly 2710 in order to get data delivered as soon as possible. In absence of 2711 network congestion, these preventive congestion control algorithms 2712 should show no impact on protocol performance. 2714 IMPLEMENTATION NOTE: As far as its specific performance requirements 2715 are met, an implementation is always allowed to adopt a more 2716 conservative congestion control algorithm than the one defined below. 2718 The congestion control algorithms used by MPMTP-AR are based on 2719 [RFC2581]. This section describes how the algorithms defined in 2720 [RFC2581] are adapted to use in MPMTP-AR. We first list differences 2721 in protocol designs between TCP and MPMTP-AR, and then describe 2722 MPMTP-AR's congestion control scheme. The description will use the 2723 same terminology as in TCP congestion control whenever appropriate. 2724 MPMTP-AR congestion control is always applied to both the entire 2725 session and individual subflow. 2727 12.1 Differences Between MPMTP-AR and TCP in Congestion Control 2728 Gap Ack Blocks in the MPMTP-AR SACK carry the same semantic meaning 2729 as the TCP SACK. TCP considers the information carried in the SACK as 2730 advisory information only. MPMTP-AR considers the information carried 2731 in the Gap Ack Blocks in the SACK chunk as advisory. In MPMTP-AR, any 2732 DATA packet that has been acknowledged by SACK, including DATA that 2733 arrived at the receiving end out of order, is not considered fully 2734 delivered until the Cumulative TSN Ack Point passes the TSN of the 2735 DATA packet (i.e., the DATA packet has been acknowledged by the 2736 Cumulative TSN Ack field in the SACK). Consequently, the value of 2737 cwnd controls the amount of outstanding data, rather than (as in the 2738 case of non-SACK TCP) the upper bound between the highest 2739 acknowledged sequence number and the latest DATA packet that can be 2740 sent within the congestion window. MPMTP-AR SACK leads to different 2741 implementations of Fast Retransmit and Fast Recovery than non-SACK 2742 TCP. As an example, see [FALL96]. 2744 The biggest difference between MPMTP-AR and TCP, however, is multiple 2745 paths. MPMTP-AR is designed to establish robust communication session 2746 between two endpoints more than one path. The treatment here of 2747 congestion control for multipath receivers is new with MPMTP-AR and 2748 may require refinement in the future. The current algorithms make the 2749 following assumptions: 2751 1) The sender keeps a separate congestion control parameter set for 2752 each subflow it use. The parameters should decay if the subflow is 2753 not used for a long enough time period. The sender SHOULD adjust the 2754 entire session congestion control parameter according to all 2755 subflows' congestion control parameter; the specific rules will be 2756 refined in the future. 2758 2) For each subflow, an agent does slow start upon the first 2759 transmission to that subflow. 2761 12.2 Slow-Start and Congestion Avoidance 2763 The slow-start and congestion avoidance algorithms MUST be used by an 2764 agent to control the amount of data being injected into the network. 2765 The congestion control in MPMTP-AR is employed in regard not only to 2766 the session, but also to an individual subflow. In some situations, 2767 it may be beneficial for an MPMTP-AR sender to be more conservative 2768 than the algorithms allow; however, an MPMTP-AR sender MUST NOT be 2769 more aggressive than the following algorithms allow. 2771 Like TCP, an MPMTP-AR agent uses the following three control 2772 variables to regulate its transmission rate. 2774 1) Receiver advertised window size (rwnd, in bytes), which is set by 2775 the receiver based on its available buffer space for incoming 2776 packets. 2778 Note: This variable is kept on the entire session. 2780 2) Congestion control window (cwnd, in bytes), which is adjusted by 2781 the sender based on observed network conditions. 2783 Note: This variable is maintained on a per-subflow basis. 2785 3) Slow-start threshold (ssthresh, in bytes), which is used by the 2786 sender to distinguish slow-start and congestion avoidance phases. 2788 Note: This variable is maintained on a per-subflow basis. 2790 MPMTP-AR also requires one additional control variable, 2791 partial_bytes_acked, which is used during congestion avoidance phase 2792 to facilitate cwnd adjustment. 2794 Unlike TCP, an MPMTP-AR sender MUST keep a set of these control 2795 variables cwnd, ssthresh, and partial_bytes_acked for EACH subflow. 2796 Only one rwnd is kept for the whole session. 2798 12.2.1 Slow-Start 2800 Beginning data transmission into a network with unknown conditions or 2801 after a sufficiently long idle period requires MPMTP-AR to probe the 2802 network to determine the available capacity. The slow-start algorithm 2803 is used for this purpose at the beginning of a transfer, or after 2804 repairing loss detected by the retransmission timer. 2806 1) The initial cwnd before DATA transmission or after a sufficiently 2807 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)). 2809 2) The initial cwnd after a retransmission timeout MUST be no more 2810 than 1*MTU. 2812 3) The initial value of ssthresh MAY be arbitrarily high (for 2813 example, implementations MAY use the size of the receiver advertised 2814 window). 2816 4) Whenever cwnd is greater than zero, the agent is allowed to have 2817 cwnd bytes of data outstanding on that subflow. 2819 5) When cwnd is less than or equal to ssthresh, an MPMTP-AR agent 2820 MUST use the slow-start algorithm to increase cwnd only if the 2821 current congestion window is being fully utilized, an incoming SACK 2822 advances the Cumulative TSN Ack Point, and the data sender is not in 2823 Fast Recovery. Only when these three conditions are met can the cwnd 2824 be increased; otherwise, the cwnd MUST not be increased. If these 2825 conditions are met, then cwnd MUST be increased by, atmost, the 2826 lesser of 1) the total size of the previously outstanding DATA 2827 packet(s) acknowledged, and 2) the destination's path MTU. This upper 2828 bound protects against the ACK-Splitting attack outlined in 2829 [SAVAGE99]. 2831 In instances where its session is multipath, if an agent receives a 2832 SACK that advances its Cumulative TSN Ack Point, then it should 2833 update its cwnd (or cwnds). However, if the received SACK does not 2834 advance the Cumulative TSN Ack Point, the agent MUST NOT adjust the 2835 cwnd of any subflow. 2837 Because an agent's cwnd is not tied to its Cumulative TSN Ack Point, 2838 as duplicate SACKs come in, even though they may not advance the 2839 Cumulative TSN Ack Point an agent can still use them to clock out new 2840 data. That is, the data newly acknowledged by the SACK diminishes the 2841 amount of data now in flight to less than cwnd, and so the current, 2842 unchanged value of cwnd now allows new data to be sent. On the other 2843 hand, the increase of cwnd must be tied to the Cumulative TSN Ack 2844 Point advancement as specified above. Otherwise, the duplicate SACKs 2845 will not only clock out new data, but also will adversely clock out 2846 more new data than what has just left the network, during a time of 2847 possible congestion. 2849 6) When the agent does not transmit data on a given subflow, the cwnd 2850 of the subflow should be adjusted to max(cwnd/2, 4*MTU) per RTO. 2852 12.2.2 Congestion Avoidance 2854 When cwnd is greater than ssthresh, cwnd should be incremented by 2855 1*MTU per RTT if the sender has cwnd or more bytes of data 2856 outstanding for the corresponding subflow. 2858 In practice, an implementation can achieve this goal in the following 2859 way: 2861 1) partial_bytes_acked is initialized to 0. 2863 2) Whenever cwnd is greater than ssthresh, upon each SACK arrival 2864 that advances the Cumulative TSN Ack Point, increase 2865 partial_bytes_acked by the total number of bytes of all new chunks in 2866 this subflow acknowledged in that SACK including chunks acknowledged 2867 by the new Cumulative TSN Ack and by Gap Ack Blocks. 2869 3) When partial_bytes_acked is equal to or greater than cwnd and 2870 before the arrival of the SACK the sender had cwnd or more bytes of 2871 data outstanding (i.e., before arrival of the SACK, flightsize was 2872 greater than or equal to cwnd), increase cwnd by MTU, and reset 2873 partial_bytes_acked to (partial_bytes_acked - cwnd). 2875 4) Same as in the slow start, when the sender does not transmit DATA 2876 on a given transport address, the cwnd of the transport address 2877 should be adjusted to max(cwnd / 2, 4*MTU) per RTO. 2879 5) When all of the data transmitted by the sender has been 2880 acknowledged by the receiver, partial_bytes_acked is initialized to 2881 0. 2883 12.2.3 Parameter Update 2885 Upon detection of packet losses from SACK (see section 12.2.4), an 2886 agent should do the following: 2888 ssthresh = max(cwnd/2, 4*MTU) 2890 cwnd = ssthresh 2892 partial_bytes_acked = 0 2894 Basically, a packet loss causes cwnd to be cut in half. 2896 When the T3-rtx timer expires on a subflow, MPMTP-AR should perform 2897 slow start by: 2899 ssthresh = max(cwnd/2, 4*MTU) 2901 cwnd = 1*MTU 2903 and ensure that no more than one MPMTP-AR packet will be in flight 2904 for that subflow until the agent receives select acknowledgement for 2905 successful delivery of data to that subflow. 2907 12.2.4 Fast Retransmit on Gap Reports 2909 In the absence of data loss, an agent performs delayed 2910 acknowledgement. However, whenever an agent notices a hole in the 2911 arriving TSN sequence, it SHOULD start sending a SACK back every time 2912 a packet arrival carrying data until the hole is filled. 2914 Whenever an agent receives a SACK that indicates that some TSNs are 2915 missing, it SHOULD wait for two further miss indications (via 2916 subsequent SACKs for a total of three missing reports) on the same 2917 TSNs before taking action with regard to Fast Retransmit. 2919 Miss indications SHOULD follow the HTNA (Highest TSN Newly 2920 Acknowledged) algorithm. For each incoming SACK, miss indications are 2921 incremented only for missing TSNs prior to the highest TSN newly 2922 acknowledged in the SACK. A newly acknowledged DATA packet is one not 2923 previously acknowledged in a SACK. If an agent is in Fast Recovery 2924 and a SACK arrives that advances the Cumulative TSN Ack Point, the 2925 miss indications are incremented for all TSNs reported missing in the 2926 SACK. 2928 When the third consecutive miss indication is received for a TSN(s), 2929 the data sender shall do the following: 2931 1) Mark the DATA packet(s) with three miss indications for 2932 retransmission. 2934 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the 2935 according to the formula described in section 12.2.3. 2937 3) Determine how many of the earliest (i.e., lowest TSN) DATA packets 2938 marked for retransmission, subject to constraint of the path MTU of 2939 the subflow to which the packet is being sent. When a Fast Retransmit 2940 is being performed, the sender SHOULD ignore the value of cwnd and 2941 SHOULD NOT delay retransmission for this packet. 2943 4) Restart the T3-rtx timer only if the last SACK acknowledged the 2944 lowest outstanding TSN number sent to that subflow, or the agent is 2945 retransmitting the first outstanding DATA packet sent to that 2946 subflow. 2948 5) Mark the DATA packet(s) as being fast retransmitted and thus 2949 ineligible for a subsequent Fast Retransmit. Those TSNs marked for 2950 retransmission due to the Fast-Retransmit algorithm that did not fit 2951 in the sent datagram carrying K other TSNs are also marked as 2952 ineligible for a subsequent Fast Retransmit. However, as they are 2953 marked for retransmission they will be retransmitted later on as soon 2954 as cwnd allows. 2956 6) If not in Fast Recovery, enter Fast Recovery and mark the highest 2957 outstanding TSN as the Fast Recovery exit point. When a SACK 2958 acknowledges all TSNs up to and including this exit point, Fast 2959 Recovery is exited. While in Fast Recovery, the ssthresh and cwnd 2960 SHOULD NOT change for any path due to a subsequent Fast Recovery 2961 event (i.e., one SHOULD NOT reduce the cwnd further due to a 2962 subsequent Fast Retransmit). 2964 Note: Before the above adjustments, if the received SACK also 2965 acknowledges new DATA packets and advances the Cumulative TSN Ack 2966 Point, the cwnd adjustment rules defined in section 12.2.1 and 2967 section 12.2.2 must be applied first. 2969 A straightforward implementation of the above keeps a counter for 2970 each TSN hole reported by a SACK. The counter increases for each 2971 consecutive SACK reporting the TSN hole. After reaching 3 and 2972 starting the Fast-Retransmit procedure, the counter resets to 0. 2973 Because cwnd in MPMTP-AR indirectly bounds the number of outstanding 2974 TSN's, the effect of TCP Fast Recovery is achieved automatically with 2975 no adjustment to the congestion control window size. 2977 12.3 Path MTU Discovery 2979 [RFC4821], [RFC1981], and [RFC1191] specify "Packetization Layer Path 2980 MTU Discovery", whereby an agent maintains an estimate of the maximum 2981 transmission unit (MTU) along a given Internet path and refrains from 2982 sending packets along that path that exceed the MTU, other than 2983 occasional attempts to probe for a change in the Path MTU (PMTU). 2984 [RFC4821] is thorough in its discussion of the MTU discovery 2985 mechanism and strategies for determining the current end-to-end MTU 2986 setting as well as detecting changes in this value. 2988 An agent SHOULD apply these techniques, and SHOULD do so on a per- 2989 path basis. 2991 There are two important MPMTP-AR-specific points regarding Path MTU 2992 discovery: 2994 1) MPMTP-AR session can span multiple paths. An agent MUST maintain 2995 separate MTU estimates for each path. 2997 2) The sender should track an session PMTU that will be the smallest 2998 PMTU discovered for all paths. When fragmenting messages into 2999 multiple parts this session PMTU should be used to calculate the size 3000 of each fragment. This will allow retransmission to be seamlessly 3001 sent to an alternate path without encountering IP fragmentation. 3003 13. Fault Management 3005 13.1 Endpoint Failure Detection 3007 An agent shall keep a counter on the total number of consecutive 3008 retransmission to its peer (this includes retransmission to all 3009 paths). If the value of this counter exceeds the limit indicated in 3010 the protocol parameter 'Session.Max.Retrans', the agent shall 3011 consider the peer agent unreachable and shall stop transmitting any 3012 more data to it (and thus the session enters the CLOSED state). In 3013 addition, the agent MAY report the failure to the MPMTP-AR user and 3014 optionally report back all outstanding user data remaining in its 3015 outbound queue. The session is automatically closed when the peer 3016 agent becomes unreachable. 3018 The counter shall be reset each time a DATA packet sent to that peer 3019 agent is acknowledged (by the reception of a SACK) from the peer 3020 agent. 3022 13.2 Path Failure Detection 3024 When the session employs multipath, an agent should keep an error 3025 counter for each path. 3027 Each time the T3-rtx timer expires on any path, the error counter of 3028 that path will be incremented. When the value in the error counter 3029 exceeds the protocol parameter 'Path.Max.Retrans' of that path, the 3030 agent should mark the destination transport address as inactive, and 3031 a notification SHOULD be sent to the MPMTP-AR user. 3033 When an outstanding TSN is acknowledged, the agent shall clear the 3034 error counter of the path to which the DATA packet was last sent. 3035 When the session is multipath and the last packet sent to it was a 3036 retransmission to an alternate path, there exists an ambiguity as to 3037 whether or not the acknowledgement should be credited to the address 3038 of the last packet sent. However, this ambiguity does not seem to 3039 bear any significant consequence to MPMTP-AR behavior. If this 3040 ambiguity is undesirable, the transmitter may choose not to clear the 3041 error counter if the last packet sent was a retransmission. 3043 Note: When configuring the MPMTP-AR agent, the user should avoid 3044 having the value of 'Session.Max.Retrans' larger than the summation 3045 of the 'Path.Max.Retrans' of all paths for the remote agent. 3046 Otherwise, all paths may become inactive while the agent still 3047 considers the peer agent reachable. When this condition occurs, how 3048 MPMTP-AR chooses to function is implementation specific. 3050 When the primary path is marked inactive (due to excessive 3051 retransmission, for instance), the sender MAY automatically transmit 3052 new packets to alternate paths if they exist and are active. If more 3053 than one alternate path is active when the primary path is marked 3054 inactive, the sender may switch the load allocated to the inactive 3055 path to one or more active path. 3057 13.3 Handle "Out of the Blue" Packets 3059 An MPMTP-AR packet is called an "out of the blue" (OOTB) packet if it 3060 is correctly formed, but the receiver is not able to identify the 3061 session to which this packet belongs. 3063 The receiver of an OOTB packet MUST do the following: 3065 1) If the OOTB packet is to or from a non-unicast address, a receiver 3066 SHOULD silently discard the packet. Otherwise, 3068 2) If the OOTB packet contains an ABORT chunk, the receiver MUST 3069 silently discard the OOTB packet and take no further action. 3070 Otherwise, 3072 3) If the packet contains a COOKIE ECHO chunk, process it as 3073 described in section 10.1. 3075 4) If the packet contains a SSHUTDOWN ACK chunk, the receiver should 3076 respond to the sender of the OOTB packet with a SSHUTDOWN COMPLETE. 3078 5) If the packet contains a SSHUTDOWN COMPLETE chunk, the receiver 3079 should silently discard the packet and take no further action. 3080 Otherwise, 3082 6) If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK, the 3083 MPMTP-AR packet should be silently discarded. Otherwise, 3085 7) The receiver should respond to the sender of the OOTB packet with 3086 an ABORT. After sending this ABORT, the receiver of the OOTB packet 3087 shall discard the OOTB packet and take no further action. 3089 14. Termination of Session 3091 An agent should terminate its session when it exits from service. A 3092 session can be terminated by either abort or session-level shutdown. 3093 An abort of a session is abortive by definition in that any data 3094 pending of the session is discarded and not delivered to the peer. A 3095 session-level shutdown is considered as a graceful close where all 3096 data in queue is delivered to respective peers. When agent performs a 3097 session-level shutdown, the agent will stop accepting new data from 3098 MPMTP-AR user; if the agent is a sender, it only delivers data in all 3099 subflow queues when sending the SSHUTDOWN chunk. 3101 14.1 Abort of a Session 3103 When agent decides to abort an existing session, it MUST send an 3104 ABORT chunk to its peer agent. 3106 An agent MUST NOT respond to any ABORT chunk (also see section 13.3). 3108 After checking the Session ID, the receiving agent MUST remove the 3109 session from its record and SHOULD report the termination to MPMTP-AR 3110 user. If a User-Initiated Abort error cause is present in the ABORT 3111 chunk, the Abort Reason SHOULD be made available to the MPMTP-AR 3112 user. 3114 14.2 Shutdown of a Session 3116 Using the session-level SSHUTDOWN, the MPMTP-AR user in a session can 3117 gracefully close a session. This will allow all outstanding DATA 3118 packet to be delivered before the session terminate. According to the 3119 initiator, it includes sender-initialized and receiver-initialized. 3121 Upon receipt of the SSHUTDOWN primitive from MPMTP-AR user: 3123 For sender-initialized: The agent enters the SSHUTDOWN-PENDING state 3124 and remains there until all outstanding data has been acknowledged by 3125 its peer. The agent accepts no new data from user, but retransmits 3126 data to the peer agent if necessary to fill gaps. Once all its 3127 outstanding data has been acknowledged, the agent shall send a 3128 SSHUTDOWN chunk. It shall then start the T2-shutdown timer and enter 3129 the SSHUTDOWN-SENT state. If the timer expires, the agent must resend 3130 the SSHUTDOWN. 3132 For receiver-initialized: Upon receipt of the SSHUTDOWN primitive 3133 from MPMTP-AR user, the agent enters the SSHUTDOWN-PENDING state and 3134 remains there until all data has been received correctly. Once all 3135 data has been received correctly, the agent shall send a SSHUTDOWN 3136 chunk. It shall then start the T2-shutdown timer and enter the 3137 SSHUTDOWN-SENT state. If the timer expires, the agent must resend the 3138 SSHUTDOWN. 3140 The rules in section 11.3 MUST be followed to determine the proper 3141 timer value for T2-shutdown. 3143 An agent should limit the number of retransmissions of the SSHUTDOWN 3144 chunk to the protocol parameter 'Session.Max.Retrans'. If this 3145 threshold is exceeded, the agent should destroy the TCB and MUST 3146 report the peer agent unreachable to the MPMTP-AR user (and thus the 3147 session enters the CLOSED state). 3149 Upon reception of the SSHUTDOWN, the agent shall enter the SSHUTDOWN- 3150 RECEIVED state. 3152 Once an agent has reached the SSHUTDOWN-RECEIVED state, it should 3153 discard subsequent SSHUTDOWN chunks. 3155 The sender of the SSHUTDOWN MAY also start an overall guard timer 3156 'T5-shutdown-guard' to bound the overall time for the shutdown 3157 sequence. At the expiration of this timer, the sender SHOULD abort 3158 the session by sending an ABORT chunk. If the 'T5-shutdown-guard' 3159 timer is used, it SHOULD be set to the recommended value of 5 times 3160 'RTO.Max'. 3162 The SSHUTDOWN receiver MUST send a SSHUTDOWN ACK and start a T2- 3163 shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If 3164 the timer expires, the agent must resend the SSHUTDOWN ACK. 3166 The sender of the SSHUTDOWN ACK should limit the number of 3167 retransmissions of the SSHUTDOWN ACK chunk to the protocol parameter 3168 'Session.Max.Retrans'. If this threshold is exceeded, the agent 3169 should destroy the TCB and may report the peer agent unreachable to 3170 the MPMTP-AR user (and thus the session enters the CLOSED state). 3172 Upon the receipt of the SSHUTDOWN ACK, the agent shall stop the T2- 3173 shutdown timer, send a SSHUTDOWN COMPLETE chunk to its peer, and 3174 remove all record of the session. 3176 After receiving the SSHUTDOWN COMPLETE chunk, the agent will verify 3177 that it is in the SSHUTDOWN-ACK-SENT state; if it is not, the chunk 3178 should be discarded; otherwise, the agent should stop the T2-shutdown 3179 timer and remove all acknowledge of the session (and thus the session 3180 enters the CLOSED state). 3182 An agent SHOULD ensure that all its outstanding DATA packets have 3183 been sent or received correctly before sending SSHUTDOWN. 3185 The sender of the SINIT or COOKIE ECHO should respond to the receipt 3186 of a SSHUTDOWN ACK with a stand-alone SSHUTDOWN COMPLETE in an MPMTP- 3187 AR packet. This is considered an Out of the Blue packet as defined in 3188 section 13.3. The sender of the SINIT lets T1-init continue running 3189 and remains in the COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init 3190 timer expiration will cause the SINIT or COOKIE chunk to be 3191 retransmitted and thus start a new session. 3193 If a SSHUTDOWN is received in the COOKIE-WAIT or COOKIE ECHOED state, 3194 the SSHUTDOWN chunk SHOULD be silently discarded. 3196 In sender-initialized scenario: An agent should reject any new data 3197 request from its user if it is in the SSHUTDOWN-PENDING, SSHUTDOWN- 3198 SENT state. If an agent is in the SSHUTDOWN-ACK-SENT state and 3199 receives an SINIT chunk (e.g., if the SSHUTDOWN COMPLETE was lost), 3200 it should discard the SINIT chunk and retransmit the SSHUTDOWN ACK 3201 chunk. 3203 15. Security Consideration 3205 15.1 Security Objectives 3207 As a common transport protocol designed to reliably carry time- 3208 sensitive user messages, such as billing or signaling messages for 3209 telephony services, between two networked endpoints, MPMTP-AR has the 3210 following security objectives. 3212 - availability of reliable and timely data transport services 3214 - integrity of the user-to-user information carried by MPMTP-AR 3216 15.2 MPMTP-AR Responses to Potential Threats 3218 MPMTP-AR may potentially be used in a wide variety of risk 3219 situations. It is important for operators of systems running MPMTP-AR 3220 to analyse their particular situations and decide on the appropriate 3221 counter- measures. 3223 Operators of systems running MPMTP-AR should consult [RFC2196] for 3224 guidance in securing their site. 3226 15.2.1 Countering Insider Attacks 3228 The principles of [RFC2196] should be applied to minimize the risk of 3229 theft of information or sabotage by insiders. Such procedures 3230 include publication of security policies, control of access at the 3231 physical, software, and network levels, and separation of services. 3233 15.2.2 Protecting Confidentiality 3235 In most cases, the risk of breach of confidentiality applies to the 3236 signaling data payload, not to the MPMTP-AR or lower-layer protocol 3237 overheads. If that is true, encryption of the MPMTP-AR user data 3238 only might be considered. As with the supplementary checksum 3239 service, user data encryption MAY be performed by the MPMTP-AR user 3240 application. Alternately, the user application MAY use an 3241 implementation-specific API to request that the IP Encapsulating 3242 Security Payload (ESP) [RFC4303] be used to provide confidentiality 3243 and integrity. 3245 Particularly for mobile users, the requirement for confidentiality 3246 might include the masking of IP addresses and ports. In this case, 3247 ESP SHOULD be used instead of application-level confidentiality. If 3248 ESP is used to protect confidentiality of MPMTP-AR traffic, an ESP 3249 cryptographic transform that includes cryptographic integrity 3250 protection MUST be used, because if there is a confidentiality threat 3251 there will also be a strong integrity threat. 3253 Whenever ESP is in use, application-level encryption is not generally 3254 required. 3256 Regardless of where confidentiality is provided, the Internet Key 3257 Exchange Protocol version 2 (IKEv2) [RFC4306] SHOULD be used for key 3258 management. 3260 Operators should consult [RFC4301] for more information on the 3261 security services available at and immediately above the Internet 3262 Protocol layer. 3264 15.2.3 Protecting against Blind Denial-of-Service Attacks 3266 A blind attack is one where the attacker is unable to intercept or 3267 otherwise see the content of data flows passing to and from the 3268 target MPMTP-AR node. Blind denial-of-service attacks may take the 3269 form of flooding, masquerade, or improper monopolization of services. 3271 15.2.3.1 Flooding 3273 The objective of flooding is to cause loss of service and incorrect 3274 behavior at target systems through resource exhaustion, interference 3275 with legitimate transactions, and exploitation of buffer-related 3276 software bugs. Flooding may be directed either at the MPMTP-AR node 3277 or at resources in the intervening IP Access Links or the Internet. 3278 Where the latter entities are the target, flooding will manifest 3279 itself as loss of network services, including potentially the breach 3280 of any firewalls in place. 3282 In general, protection against flooding begins at the equipment 3283 design level, where it includes measures such as: 3285 - avoiding commitment of limited resources before determining that 3286 the request for service is legitimate. 3288 - giving priority to completion of processing in progress over the 3289 acceptance of new work. 3291 - identification and removal of duplicate or stale queued requests 3292 for service. 3294 - not responding to unexpected packets sent to non-unicast 3295 addresses. 3297 Network equipment should be capable of generating an alarm and log if 3298 a suspicious increase in traffic occurs. The log should provide 3299 information such as the identity of the incoming link and source 3300 address(es) used, which will help the network or MPMTP-AR system 3301 operator to take protective measures. Procedures should be in place 3302 for the operator to act on such alarms if a clear pattern of abuse 3303 emerges. 3305 The design of MPMTP-AR is resistant to flooding attacks, particularly 3306 in its use of a four-way startup handshake, its use of a cookie to 3307 defer commitment of resources at the responding MPMTP-AR node until 3308 the handshake is completed, and its use of a Session ID to prevent 3309 insertion of extraneous packets into the flow of an established 3310 session. 3312 The IP Authentication Header and Encapsulating Security Payload might 3313 be useful in reducing the risk of certain kinds of denial-of-service 3314 attacks. 3316 15.2.3.2 Blind Masquerade 3318 Masquerade can be used to deny service in several ways: 3320 - by tying up resources at the target MPMTP-AR node to which the 3321 impersonated node has limited access. For example, the target node 3322 may by policy permit a maximum of one MPMTP-AR session with the 3323 impersonated MPMTP-AR node. The masquerading attacker may attempt to 3324 establish an session purporting to come from the impersonated node so 3325 that the latter cannot do so when it requires it. 3327 - by deliberately allowing the impersonation to be detected, thereby 3328 provoking counter-measures that cause the impersonated node to be 3329 locked out of the target MPMTP-AR node. 3331 - by interfering with an established session by inserting extraneous 3332 content such as a SSHUTDOWN request. 3334 MPMTP-AR reduces the risk of blind masquerade attacks through IP 3335 spoofing by use of the four-way establishment handshake. Because the 3336 initial exchange is memory-less, no lockout mechanism is triggered by 3337 blind masquerade attacks. In addition, the SINIT ACK containing the 3338 State Cookie is transmitted back to the IP address from which it 3339 received the SINIT. Thus, the attacker would not receive the SINIT 3340 ACK containing the State Cookie. MPMTP-AR protects against insertion 3341 of extraneous packets into the flow of an established session by use 3342 of the Verification Session ID. 3344 Logging of received SINIT requests and abnormalities such as 3345 unexpected SINIT ACKs might be considered as a way to detect patterns 3346 of hostile activity. However, the potential usefulness of such 3347 logging must be weighed against the increased MPMTP-AR startup 3348 processing it implies, rendering the MPMTP-AR node more vulnerable to 3349 flooding attacks. Logging is pointless without the establishment of 3350 operating procedures to review and analyze the logs on a routine 3351 basis. 3353 15.2.3.3 Improper Monopolization of Services 3354 Attacks under this heading are performed openly and legitimately by 3355 the attacker. They are directed against fellow users of the target 3356 MPMTP-AR node or of the shared resources between the attacker and the 3357 target node. Possible attacks include the opening of a large number 3358 of associations between the attacker's node and the target, or 3359 transfer of large volumes of information within a legitimately 3360 established session. 3362 Policy limits should be placed on the number of associations per 3363 adjoining MPMTP-AR node. MPMTP-AR user applications should be 3364 capable of detecting large volumes of illegitimate or "no-op" 3365 messages within a given session and either logging or terminating the 3366 session as a result, based on local policy. 3368 16. Reference 3370 16.1 Normal Reference 3372 [1]W. Lei, W. Zhang, S. Liu, "A Framework of Multipath Transport 3373 System Based on Application-Level Relay ", Internet draft, IETF, 3374 July 2013. 3376 [2]Bradner, S., "Key words for use in RFCs to Indicate Requirement 3377 Levels", BCP 14, RFC 2119, March 1997. 3379 16.2 Information Reference 3381 [3]Randall R. Stewart, "Stream Control Transmission Protocol", 3382 RFC4960, September 2007. 3384 [4]A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar, 3385 "Architectural Guidelines for Multipath TCP Development", RFC6182, 3386 March 2011. 3388 [5]J. Postel, "User Datagram Protocol", Augest 1980. 3390 [6]M. Allman, V. Paxson, W. Stevens,"TCP Congestion Control", April 3391 1999. 3393 [7]Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 3394 for Message Authentication", RFC 2104, February 1997. 3396 [8]E. Rescorla, B. Korver, "Guidelines for Writing RFC Text on 3397 Security Considerations", RFC3552, July 2003. 3399 Authors' Addresses 3401 Weimin Lei 3402 Northeastern University 3403 Institute of Communication and Information System 3404 College of Computer Science and Engineering 3405 Shenyang, China, 110819 3406 P. R. China 3408 Phone: +86-24-8368-3048 3409 Email: leiweimin@mail.neu.edu.cn 3411 Shaowei Liu 3412 Northeastern University 3413 Institute of Communication and Information System 3414 College of Computer Science and Engineering 3415 Shenyang, China, 110819 3416 P. R. China 3418 Email: shaoweiliu@stumail.neu.edu.cn 3420 Wei Zhang 3421 Northeastern University 3422 Institute of Communication and Information System 3423 College of Computer Science and Engineering 3424 Shenyang, China, 110819 3425 P. R. China 3427 Email: zhangwei1@mail.neu.edu.cn