idnits 2.17.1 draft-leiwm-avtcore-mprtp-ar-09.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 -- The document date (February 2, 2018) is 2268 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 111 == Unused Reference: '2' is defined on line 784, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 796, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (ref. '5') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '8') (Obsoleted by RFC 8866) == Outdated reference: A later version (-09) exists of draft-leiwm-tsvwg-mpts-ar-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Lei 3 Internet-Draft W. Zhang 4 Intended Status: Experimental S. Liu 5 Expires: August 3, 2018 Northeastern University 6 February 2, 2018 8 Multipath Real-Time Transport Protocol 9 Based on Application-Level Relay (MPRTP-AR) 10 draft-leiwm-avtcore-mprtp-ar-09 12 Abstract 14 Currently, most multimedia applications utilize a combination of 15 real-time transport protocol (RTP) and user datagram protocol (UDP). 16 Application programs at the source end format payload data into RTP 17 packets using RTP specifications and dispatch them using unreliable 18 UDP along a single path. Multipath transport is an important way to 19 improve the efficiency of data delivery. In order to apply the 20 framework of multipath transport system based on application-level 21 relay (MPTS-AR) to RTP-based multimedia applications, this document 22 defines a multipath real-time transport protocol based on 23 application-level relay (MPRTP-AR), which is a concrete 24 application-specific multipath transport protocol (MPTP). Packet 25 formats and packet types of MPRTP-AR follow the common rules 26 specified in MPTP profile. Based on MPRTP-AR, RTP-based multimedia 27 applications can make full use of the advantages brought by MPTS-AR. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current 37 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 3, 2018. 46 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. MPRTP-AR User Agent Behavior . . . . . . . . . . . . . . . . . 5 65 4.1 Flow Partitioning . . . . . . . . . . . . . . . . . . . . . 5 66 4.2 Subflow Packaging . . . . . . . . . . . . . . . . . . . . . 6 67 4.3 Subflow and Flow Recombination . . . . . . . . . . . . . . . 6 68 4.4 Subflow Reporting . . . . . . . . . . . . . . . . . . . . . 6 69 4.5 Flow Reporting . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. MPRTP-AR Packet Format . . . . . . . . . . . . . . . . . . . . 8 71 5.1 MPRTP-AR Data Packet . . . . . . . . . . . . . . . . . . . . 8 72 5.1.1 MPRTP-AR Data Packet for RTP packet . . . . . . . . . . 8 73 5.1.2 MPRTP-AR Data Packet for RTCP packet . . . . . . . . . . 9 74 5.2 MPRTP-AR Control Packet . . . . . . . . . . . . . . . . . . 10 75 5.2.1 MPRTP-AR Subflow Sender Report . . . . . . . . . . . . . 10 76 5.2.2 MPRTP-AR Subflow Receiver Report . . . . . . . . . . . . 12 77 5.2.3 MPRTP-AR keep-alive packet . . . . . . . . . . . . . . . 14 78 5.2.4 MPRTP-AR Flow Recombination Report . . . . . . . . . . . 14 79 6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 15 80 6.1 Signaling MPTP Capability in SDP . . . . . . . . . . . . . . 16 81 6.2 An Offer/Answer Example . . . . . . . . . . . . . . . . . . 16 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 85 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 Currently, most multimedia applications utilize a combination of 91 real-time transport protocol (RTP) [1] and user datagram protocol 92 (UDP). Application programs at the source end format payload data 93 into RTP packets using RTP specifications and dispatch them using 94 unreliable UDP along a single path. Multipath transport is an 95 important way to improve the efficiency of data delivery. In order to 96 apply the framework of multipath transport system based on 97 application-level relay (MPTS-AR) [12] to RTP-based multimedia 98 applications, this document defines a multipath real-time transport 99 protocol based on application-level relay (MPRTP-AR), which is a 100 concrete application-specific multipath transport protocol (MPTP). 101 Packet formats and packet types of MPRTP-AR follow the common rules 102 specified in MPTP profile [12]. Based on MPRTP-AR, RTP-based 103 multimedia applications can make full use of the advantages brought 104 by MPTS-AR. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 3. Overview 114 The protocol stack architecture of the MPRTP-AR is shown in figure 1. 115 MPRTP-AR is divided into two sub-layers: RTP sub-layer and multipath 116 transport control (MPTC) sub-layer. RTP sub-layer is fully compatible 117 with the existing RTP specifications and provides upper applications 118 with the same application programming interfaces (APIs) as those 119 provided by normal RTP. MPTC sub-layer provides essential support for 120 multipath transport, including path management, flow partitioning, 121 subflow packaging, subflow recombination, subflow reporting and so 122 on. At the user agent sender, RTP sub-layer first formats the data 123 received from upper application into RTP packets and then passes them 124 to lower MPTC sub-layer. MPTC sub-layer further formats the RTP 125 packets into MPRTP-AR data packets. At the user agent receiver, MPTC 126 sub-layer extracts the RTP/RTCP packet by removing the fixed header 127 fields of MPRTP-AR data packet from the received packet and passes it 128 directly to upper RTP sub-layer. RTP sub-layer follows the normal 129 process defined in RTP specification to restore original data flow. 130 This design decision is to maximize backwards compatibility with 131 existing RTP applications. Moreover, MPRTP-AR can make full use of 132 real-time transport functions provided by normal RTP including 133 payload type identification, sequence numbering, timestamping and so 134 on. 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | RTP-based multimedia Applications | 138 | (VoIP, video conference, streaming, ...) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 ^ 141 | Application Programming 142 | Interfaces (APIs) 143 V 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 MPRTP-AR | RTP sub-layer | 146 layer +- - - - - - - - - - - - - - - - - - - - - - - - -+ 147 | MPTC sub-layer | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | UDP | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | IP | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1. The protocol stack architecture of MPRTP-AR 156 As defined in MPTP profile, MPRTP-AR packets are divided into two 157 types: MPRTP-AR data packets and MPRTP-AR control packets. MPRTP-AR 158 control packets include MPRTP-AR keep-alive packets and MPRTP-AR 159 report packets. 161 Besides RTP packets, RTP sub-layer generates real-time transport 162 control (RTCP) packets following the normal RTCP defined in [1] to 163 provide the overall media transport statistics. So, payload content 164 of MPTC sub-layer includes both RTP packets and RTCP packets. In MPTC 165 sub-layer, each RTP/RTCP packet is treated as an independent piece of 166 payload data and packaged into an individual MPRTP-AR data packet. 167 RTCP packets may be treated the exact same as RTP packets which are 168 distributed across multiple paths. In addition, as described in RTP 169 specification, RTCP traffic is limited to a small fraction of the 170 session bandwidth, which is recommended no more than five percent. 171 So, RTCP packets may also be treated differently from RTP packets and 172 delivered along any one of active paths, such as the default path or 173 the best path among all active paths based on quality of delivery. 175 When RTP and RTCP packets are multiplexed, the RTCP packet type field 176 occupies the same position in the packet as the combination of the 177 RTP marker (M) bit and the RTP payload type (PT). This field is used 178 to distinguish RTP and RTCP packets. It is RECOMMENDED that RTP 179 sub-layer follows the guidelines in the RTP/AVP profile [3] for the 180 choice of RTP payload type values, with the additional restriction in 181 [4]. 183 MPRTP-AR keep-alive packets are used to keep relay paths alive 184 actively by user agent. The user agent sender generates MPRTP-AR 185 keep-alive packets periodically for both active paths and non-active 186 paths and sends them along the associated path. The user agent 187 receiver does nothing when receiving MPRTP-AR keep-alive packets. 189 MPRTP-AR report packets are used to monitor the transport quality of 190 each active path and multiple concurrent paths. MPRTP-AR-aware user 191 agent MUST generate individual MPRTP-AR report packets for per 192 subflow. The user agent sender generates MPRTP-AR Subflow Sender 193 Report (SSR) packets for each subflow and sends them along the 194 associated active path. The user agent receiver generates a MPRTP-AR 195 Subflow Receiver Report (SRR) packet when receiving a MPRTP-AR SSR 196 packet and sends it along the default path. In addition, the user 197 agent receiver optionally generates MPRTP-AR Flow Recombination 198 Report (FRR) packets for the whole flow and send them to the user 199 agent sender along the default path. The user agent sender may modify 200 its strategies of flow partitioning and scheduling based on the 201 transport quality feedback in MPRTP-AR SRR and FRR packets. 203 4. MPRTP-AR User Agent Behavior 205 In addition to user agent behaviors defined in [12], MPRTP-AR user 206 agent needs to follow the following behaviors to support multipath 207 transport for RTP-based multimedia applications. 209 4.1 Flow Partitioning 211 If multiple paths are used concurrently, the original multimedia 212 stream should be divided into several substreams. Considering the 213 characteristics of multimedia data, flow partitioning may be done 214 based on a number of factors, such as media type, encoding scheme and 215 path characteristics. Flow partitioning methods can be divided into 216 coding-aware partitioning methods and coding-unaware partitioning 217 methods. Coding-unaware partitioning methods can be performed in MPTC 218 sub-layer. MPTC sub-layer does not care what media type (such as 219 audio and video) the payload data is and what coding method the 220 payload data uses. MPTC sub-layer dispatches the formatted RTP/RTCP 221 packets passed from upper RTP sub-layer to multiple subflows 222 evenly based on the local information maintained, such as the 223 delivery quality of the associated active paths. 225 For multimedia applications, a multistream coder using layered 226 coding, multiple description coding or object-oriented coding can 227 produce multiple compressed media flows. In this case, coding-aware 228 partitioning methods could be performed in RTP sub-layer. In layered 229 coding, a flow is either the base layer or one of the enhancement 230 layers; in multiple description coding, a flow typically consists of 231 packets from a description; in object-oriented coding, various 232 objects are coded individually and placed in so-called elementary 233 steams. Each coding flow corresponds to a separate subflow, or 234 several coding flows are multiplexed into one subflow. Data 235 participant in this way can effectively reduce the correlations among 236 subflows and adverse impact of different transport qualities among 237 multiple paths on the final quality of media data received in the 238 receiving end. 240 4.2 Subflow Packaging 242 For each subflow, the assigned RTP packets are treated as payload 243 data and formatted into MPRTP-AR data packets. The initial SSSN is 244 randomly generated when the subflow is first established and the SSSN 245 in subsequent subflow MPRTP-AR data packets for RTP packets is 246 monotonically increasing. The flow sequence number increments by one 247 for each assigned RTP packet from upper application. The initial 248 value of flow the sequence number SHOULD be random. 250 The assigned RTCP packets are also formatted into MPRTP-AR data 251 packets except for the difference that the SSSN and FSN are fixed to 252 zero. 254 4.3 Subflow and Flow Recombination 256 The user agent receiver recombines the original data flow according 257 to MPRTP-AR data packets received from multiple paths. After 258 receiving a MPRTP-AR data packet, MPTC sub-layer first extracts the 259 RTP/RTCP packet by removing the fixed header fields of MPTP data 260 packet from the received packet and passes it directly to upper RTP 261 sub-layer. MPTC sub-layer has no need to restore firstly the order of 262 each subflow using path identifier and SSSN in MPTP data packet 263 headers before passing the encapsulated RTP/RTCP packets up to RTP 264 sub-layer. The RTP sub-layer follows the normal process defined in 265 RTP specification to recombine the original data flow. 267 4.4 Subflow Reporting 269 User agent generates MPRTP-AR report packets for per subflow to 270 monitor the quality of path delivery. The user agent sender generates 271 MPRTP-AR Subflow Sender Report (SSR) packets for each subflow and 272 sends them along the associated active path. The user agent receiver 273 generates a MPRTP-AR Subflow Receiver Report (SRR) packets when 274 receiving a MPRTP-AR SSR and sends it along the default path. 276 The user agent sender calculates the transmission interval of 277 MPRTP-AR SSR packets according to some strategy. The user agent 278 sender may generate MPRTP-AR SSR packets at a constant rate. In this 279 case, it is recommended that the default interval of MPRTP-AR SSR 280 packets be one second. The user agent sender may also generate 281 MPRTP-AR SSR packets at a variable rate. For example, the report 282 traffic is limited to a small fraction of the associated subflow data 283 traffic. In this case, it is recommended that the fraction of the 284 subflow data traffic added for subflow report be fixed at 5%, which 285 makes reference to the recommended value in RTP specification. 287 Reception quality feedback is useful for the user agent sender who 288 may modify its strategies of flow partitioning and scheduling based 289 on the estimated transport qualities of multiple paths. 291 Cumulative counts are used in both the MPRTP-AR SSR and SRR packets 292 so that differences may be calculated between any two reports to make 293 measurements over both short and long time periods, and to provide 294 resilience against the loss of a report. The difference between the 295 last two reports received can be used to estimate the recent 296 transport quality of the associated path. The difference between the 297 two reports with a longer time interval can be used to estimate the 298 long-term transport quality of the associated path. The NTP timestamp 299 is also included so that rates may be calculated from these 300 differences over the interval between two reports. 302 An example calculation is the packet loss rate over the interval 303 between two MPRTP-AR SRR packets. The difference in the cumulative 304 number of packets lost gives the number lost during that interval. 305 The difference in the highest SSSNs received gives the number of 306 packets expected during the interval. The ratio of these two is the 307 packet loss fraction over the interval. This ratio provides a 308 short-term packet loss measurement if the two reports are 309 consecutive. The loss rate per second can be obtained by dividing the 310 loss fraction by the difference in NTP timestamps, expressed in 311 seconds. The number of packets received is the number of packets 312 expected minus the number lost. 314 In addition to the cumulative counts which allow both long-term and 315 short-term measurements using differences between reports, MPRTP-AR 316 SRR packets include an interarrival jitter field which provides 317 short-term measurement of network congestion from a single report. 318 Packet loss tracks persistent congestion while the jitter measure 319 tracks transient congestion. The jitter measure may indicate 320 congestion before it leads to packet loss. The interarrival jitter 321 field is only a snapshot of the jitter at the time of a report and is 322 not intended to be taken quantitatively. Rather, it is intended for 323 comparison across a number of reports. 325 4.5 Flow Reporting 327 The user agent receiver optionally generates MPRTP-AR Flow 328 Recombination Report (FRR) packets for the whole recombined flow and 329 sends them to the user agent sender along the default path. Real-time 330 applications are generally latency- and loss rate-sensitive. 331 Therefore, the flow recombination reports include the cumulative 332 packet loss rate and interarrival jitter caused by out-of-order 333 packets which arrive at the receiver along different paths. The user 334 agent receiver calculates the transmission interval of MPRTP-AR FRR 335 packets according to some strategy. In this document, it is 336 recommended that the default interval of MPRTP-AR FRR packets be one 337 second. 339 5. MPRTP-AR Packet Format 341 Packet types and packet formats of MPRTP-AR follow the common rules 342 specified in MPTP profile. As defined in MPTP profile, MPRTP-AR 343 packets are divided into two types: MPRTP-AR data packets and 344 MPRTP-AR control packets. MPRTP-AR control packets include MPRTP-AR 345 keep-alive packets and MPRTP-AR report packets. For all the MPRTP-AR 346 packets, the application-specific MPTP type (AMT) field in the fixed 347 MPTP header is set to 1. 349 5.1 MPRTP-AR Data Packet 351 As stated in section 3, the RTP packets and RTCP packets are packaged 352 into MPRTP-AR data packets intact. Each RTP packet and RTCP packet 353 corresponds to a MPRTP-AR data packet. 355 5.1.1 MPRTP-AR Data Packet for RTP packet 357 A MPRTP-AR data packet carrying a RTP packet consists of a fixed 358 eight-octet MPTP header and an intact RTP packet. An example is shown 359 below: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 MPTP |V=1|1|P| AMT=1 |0|1|0|0| rsvd | SSSN | 365 header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Path Identifier | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Flow Sequence Number | 369 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 370 RTP |V=2|P|X| CC |M| PT | sequence number | 371 packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | RTP timestamp | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | synchronization source (SSRC) identifier | 375 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 376 | contributing source (CSRC) identifiers | 377 | .... | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 The MPTP packet type (T) field is set to 1 to indicate that this 381 packet is a MPRTP-AR data packet. 383 The application-specific MPTP type (AMT) field is set to 1 to 384 indicate that this packet is a MPRTP-AR packet. 386 For RTP-based multimedia applications, latency and jitter are the 387 primary concerns, and occasional packet lost is acceptable. So the 388 delay bit in the type of service (TOS) field is set to indicate that 389 prompt delivery is important for this packet. 391 The initial SSSN is randomly generated when the subflow is first 392 established. The SSSN is increased by one for each subsequent 393 MPRTP-AR data packets carrying RTP packets of the same subflow. 395 The initial FSN is randomly generated when the multipath session is 396 first established. The FSN is increased by one for each RTP packet. 398 5.1.2 MPRTP-AR Data Packet for RTCP packet 400 A MPRTP-AR data packet carrying a RTCP packet consists of a fixed 401 eight-octet MPTP header and an intact RTCP packet. An example is 402 shown below: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 MPTP |V=1|1|P| AMT=1 |1|0|0|1| rsvd | SSSN=0 | 408 header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Path Identifier | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Flow Sequence Number=0 | 412 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 413 RTCP |V=2|P| RC | PT | length | 414 packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | SSRC of packet sender | 416 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 417 | .... | 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 The MPTP packet type (T) field is set to indicate that this packet 422 is a MPRTP-AR data packet. 424 The application-specific MPTP type (AMT) field is set to 1 to 425 indicate that this packet is a MPRTP-AR packet. 427 In a RTP session, RTCP packets have higher transmission requirements 428 of precedence and reliability than RTP packets. So the precedence and 429 reliability bits of the type of service (TOS) field are set to 430 indicate that the payload data in this MPTP data packet is more 431 important and requires a higher level of effort to ensure delivery. 433 The SSSN field and FSN field in MPRTP-AR data packets carrying RTCP 434 packets are fixed to zero. 436 5.2 MPRTP-AR Control Packet 438 MPRTP-AR control packets include MPRTP-AR keep-alive packets and 439 MPRTP-AR report packets. MPRTP-AR report packets include MPRTP-AR 440 Subflow Sender Report (SSR) packets, MPRTP-AR Subflow Receiver Report 441 (SRR) packets, and MPRTP-AR Flow Recombination Report (FRR) packets. 443 5.2.1 MPRTP-AR Subflow Sender Report 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |V=1|0|P| AMT=1 | CT=1 | Length | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Path Identifier | 450 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 451 | NTP timestamp, most significant word | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | NTP timestamp, least significant word | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | subflow's packet count | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | subflow's octet count | 458 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 460 MPRTP-AR SSR summarizes the data transmissions of the associated 461 subflow. The fields have the following meaning: 463 The MPTP packet type (T) field is set to zero to indicate that this 464 packet is a MPRTP-AR control packet. 466 The application-specific MPTP type (AMT) field is set to 1 to 467 indicate that this packet is a MPRTP-AR packet whose packet formats 468 follow the rules specified in this document. 470 The MPTP control packet type field is set to 1 to indicate that this 471 packet is a MPRTP-AR SSR. 473 NTP timestamp: 64 bits 474 Indicates the wallclock time when this report was sent so that it 475 may be used in combination with timestamps returned in receiver 476 reports to measure round-trip propagation to the user agent 477 receiver. 479 Wallclock time (absolute date and time) is represented using the 480 timestamp format of the Network Time Protocol (NTP), which is in 481 seconds relative to 0h UTC on 1 January 1900 [5]. The full 482 resolution NTP timestamp is a 64-bit unsigned fixed-point number 483 with the integer part in the first 32 bits and the fractional part 484 in the last 32 bits. An implementation is not required to run the 485 Network Time Protocol in order to use this MPTP extension. On a 486 system that has no notion of wallclock time but does have some 487 system-specific clock such as "system uptime", a user agent sender 488 MAY use that clock as a reference to calculate relative NTP 489 timestamps. 491 subflow's packet count: 32 bits 492 The total number of MPRTP-AR data packets with non-zero SSSN value 493 transmitted within a subflow by the user agent sender since 494 starting transmission up until the time this MPRTP-AR SSR packet 495 was generated. 497 subflow's octet count: 32 bits 498 The total number of payload octets (i.e., not including header or 499 padding) transmitted in MPRTP-AR data packets by the user agent 500 sender since starting transmission up until the time this MPRTP-AR 501 SSR packet was generated. This field can be used to estimate the 502 average payload data rate. 504 5.2.2 MPRTP-AR Subflow Receiver Report 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |V=1|0|P| AMT=1 | CT=2 | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Path Identifier | 512 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 513 | highest SSSN received | cumulative num of packets lost| 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | interarrival jitter | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | last SSR (LSR) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | delay since last SSR (DLSR) | 520 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 522 MPRTP-AR SRR conveys statistics on the reception of MPTP data packets 523 from a single subflow. The fields have the following meaning: 525 The MPTP packet type (T) field is set to zero to indicate that this 526 packet is a MPRTP-AR control packet. 528 The application-specific MPTP type (AMT) field is set to 1 to 529 indicate that this packet is a MPRTP-AR packet. 531 The MPTP control packet type field is set to 2 to indicate that this 532 packet is a MPRTP-AR SRR. 534 The highest subflow-specific sequence number (SSSN) received: 16 bits 535 The highest subflow-specific sequence number received in an 536 MPRTP-AR data packet from a subflow. 538 Cumulative number of packets lost: 16 bits 539 The total number of MPRTP-AR data packets from a subflow that have 540 been lost since the beginning of reception. Note that a user agent 541 receiver cannot tell whether any packets were lost after the last 542 one received. This number is defined to be the number of packets 543 expected less the number of packets actually received. The number 544 of packets expected is defined to be the highest SSSN of MPTP data 545 packets received less the initial SSSN received. The number of 546 packets received includes any which are late. Thus, packets that 547 arrive late are not counted as lost. 549 Interarrival jitter: 32 bits 550 An estimate of the statistical variance of the interarrival time 551 of the MPRTP-AR data packets with non-zero SSSN value in a 552 subflow, measured in timestamp units and expressed as an unsigned 553 integer. The interarrival jitter J is defined to be the mean 554 deviation (smoothed absolute value) of the difference D in packet 555 spacing at the user agent receiver compared to the user agent 556 sender for a pair of successive packets in a subflow. As shown in 557 the equation below, the difference D is also equivalent to the 558 difference in the "relative transit time" for the two successive 559 packets; the relative transit time is the difference between a 560 packet's RTP timestamp and the user agent receiver's clock at the 561 time of arrival, measured in the same units. 563 If Si is the RTP timestamp from packet i, and Ri is the time of 564 arrival in RTP timestamp units for packet i, then for two packets 565 i and j, D may be expressed as 567 D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) 569 The interarrival jitter SHOULD be calculated continuously as each 570 MPTP data packet with non-zero SSSN value i is received from a 571 subflow, using this difference D for that packet and the previous 572 packet i-1 in order of arrival (not necessarily in sequence), 573 according to the formula 575 J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16 577 This algorithm is the optimal first-order estimator and the gain 578 parameter 1/16 gives a good noise reduction ratio while 579 maintaining a reasonable rate of convergence [11]. 581 Whenever a MPRTP-AR SRR is issued, the current value of J is 582 sampled. 584 Last SSR timestamp (LSR): 32 bits 585 The middle 32 bits out of 64 in the NTP timestamp received as part 586 of the most recent MPRTP-AR SSR from a subflow. If no MPRTP-AR SSR 587 has been received yet, the field is set to zero. 589 Delay since last SSR (DLSR): 32 bits 590 The delay, expressed in units of 1/65536 seconds, between 591 receiving the last MPRTP-AR SSR from a subflow and sending this 592 MPRTP-AR SRR. If no MPRTP-AR SSR has been received yet from this 593 subflow, the DLSR field is set to zero. 595 The user agent sender can compute the round-trip propagation delay to 596 the user agent receiver along a specific active path by doing the 597 following. The user agent sender records the time A when this 598 MPRTP-AR SRR is received, calculates the total round-trip time A-LSR 599 using the last SSR timestamp (LSR) field, and then subtracting this 600 field to leave the round-trip propagation delay as (A - LSR - DLSR). 602 5.2.3 MPRTP-AR keep-alive packet 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 |V=1|0|P| AMT=1 | CT=3 | Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Path Identifier | 610 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 612 MPRTP-AR keep-alive packet is used to keep the active path alive. It 613 only contains a fixed eight-octet MPTP header. 615 The MPTP packet type (T) field is set to zero to indicate that this 616 packet is a MPRTP-AR control packet. 618 The application-specific MPTP type (AMT) field is set to 1 to 619 indicate that this packet is a MPRTP-AR packet. 621 The MPTP control packet type field is set to 3 to indicate that this 622 packet is a MPRTP-AR keep-alive packet. 624 5.2.4 MPRTP-AR Flow Recombination Report 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 |V=1|0|P| AMT=1 | CT=4 | Length | 629 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 630 | highest FSN received | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | cumulative num of packets lost | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | interarrival jitter | 635 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 637 MPRTP-AR FRR conveys statistics on the reception of MPTP data packets 638 of the whole recombined flow. The fields have the following meaning: 640 The MPTP packet type (T) field is set to zero to indicate that this 641 packet is a MPRTP-AR control packet. 643 The application-specific MPTP type (AMT) field is set to 1 to 644 indicate that this packet is a MPRTP-AR packet. 646 The MPTP control packet type field is set to 4 to indicate that this 647 packet is a MPRTP-AR FRR. 649 The highest Flow Sequence Number (FSN) received: 32 bits 650 The highest flow sequence number received in an MPRTP-AR data 651 packet of the whole flow. 653 Cumulative number of packets lost: 32 bits 654 The total number of MPRTP-AR data packets of a whole flow that 655 have been lost since the beginning of reception. Note that a user 656 agent receiver cannot tell whether any packets were lost after the 657 last one received. This number is defined to be the number of 658 packets expected less the number of packets actually received. The 659 number of packets expected is defined to be the highest FSN of 660 MPTP data packets received less the initial FSN received. The 661 number of packets received includes any which are late. Thus, 662 packets that arrive late are not counted as lost. 664 Interarrival jitter: 32 bits 665 An estimate of the statistical variance of the interarrival time 666 of the MPRTP-AR data packets with non-zero SSSN value in a flow, 667 measured in timestamp units and expressed as an unsigned integer. 668 Its calculation method is identical as the field with the same 669 name. 671 6. SDP Considerations 672 6.1 Signaling MPTP Capability in SDP 674 This document defines a new mptp-name value for the mptp-relay 675 attribute: "mprtp-ar" for RTP-based multimedia application-specific 676 MPTP, i.e. MPRTP-AR. 678 RTP and RTCP packets are multiplexed to transport. So the rtcp-mux 679 attribute MUST be used in Session Description Protocol (SDP) [8] to 680 indicate support for multiplexing of RTP and RTCP packets [4]. When 681 an endpoint receives an SDP containing "a=mptp-relay" but without 682 "a=rtcp-mux", the endpoint MUST infer that the peer, if as a user 683 agent sender, supports multiplexing of RTP and RTCP packets. 685 A user agent sender MAY use multiple paths concurrently to increase 686 throughput. If the desired media rate exceeds the current media rate, 687 the user agent sender MUST renegotiate the application specific 688 ("b=AS:xxx") [8] bandwidth. 690 6.2 An Offer/Answer Example 692 We take the usage scenario shown in Section 5.1 in [12] as an 693 example. Session Initiation Protocol (SIP) [7] and SDP is used to 694 negotiate a multipath session following the offer/answer model [9]. 696 As recommended in [13] and [14], this example uses IPV6 addresses. 698 User A includes an initial SDP offer in the session invitation 699 message. The initial SDP offer is shown as following. 701 Initial Offer: 702 v=0 703 o=alice 2890866901 2890866902 IN IP6 2001:db8:a0b:102::1 704 s= 705 c=IN IP6 2001:db8:a0b:102::1 706 t=0 0 707 m=video 39160 RTP/AVP 98 708 a=rtpmap:98 H264/90000 709 a=fmtp:98 profile-level-id=42A01E; 710 a=mptp-relay:mprtp-ar 711 a=rtcp-mux 713 When the invitation message is processed by the server system, two 714 candidate relay paths are assigned for the media flow from user B to 715 user A. The initial SDP offer in the session invitation message is 716 modified as shown below. The IP addresses of RTP relay-1/relay-2/ 717 relay-3 are 2001:db8:a0b:103::1, 2001:db8:a0b:104::1 and 718 2001:db8:a0b:105::1 respectively. 720 Modified Offer: 721 v=0 722 o=alice 2890866901 2890866902 IN IP6 2001:db8:a0b:102::1 723 s= 724 c=IN IP6 2001:db8:a0b:102::1 725 t=0 0 726 m=video 39160 RTP/AVP 98 727 a=rtpmap:98 H264/90000 728 a=fmtp:98 profile-level-id=42A01E; 729 a=mptp-relay:mprtp-ar 730 a=rtcp-mux 731 a=relay-path:1 0x1a3b6c9d IP6/2001:db8:a0b:103::1/10000 732 a=relay-path:2 0x9i8u7y6t IP6/2001:db8:a0b:105::1/10000 734 If user B accepts the invitation, it includes an initial SDP answer 735 in the session reply message. The initial SDP answer is shown as 736 following. 738 Initial Answer: 739 v=0 740 o=bob 2890866903 2890866904 IN IP6 2001:db8:a0b:106::1 741 s= 742 c=IN IP6 2001:db8:a0b:106::1 743 t=0 0 744 m=video 36120 RTP/AVP 98 745 a=rtpmap:98 H264/90000 746 a=fmtp:98 profile-level-id=42A01E; 747 a=mptp-relay:mprtp-ar 748 a=rtcp-mux 750 When the relay message is processed by the server system, two 751 candidate relay paths are assigned for the media flow from user A to 752 user B. The initial SDP answer in the session invitation message is 753 modified as shown below. 755 Modified Answer: 756 v=0 757 o=bob 2890866903 2890866904 IN IP6 2001:db8:a0b:106::1 758 s= 759 c=IN IP6 2001:db8:a0b:106::1 760 t=0 0 761 m=video 36120 RTP/AVP 98 762 a=rtpmap:98 H264/90000 763 a=fmtp:98 profile-level-id=42A01E; 764 a=mptp-relay:mprtp-ar 765 a=rtcp-mux 766 a=relay-path:1 0x2w3e4r5t IP6/2001:db8:a0b:103::1/10000 767 a=relay-path:2 0x4r5t6y7u IP6/2001:db8:a0b:104::1/10000 769 7. Security Considerations 771 TBD 773 All drafts are required to have a security considerations section. 774 See RFC 3552 [10] for a guide. 776 8. References 778 8.1 Normative References 780 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 781 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 782 RFC 3550, July 2003. 784 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 785 Levels", BCP 14, RFC 2119, March 1997. 787 [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 788 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 790 [4] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 791 Control Packets on a Single Port", RFC 5761, April 2010. 793 [5] Mills, D., "Network Time Protocol (Version 3) Specification, 794 Implementation and Analysis", RFC 1305, March 1992. 796 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 797 Specifications: ABNF", STD 68, RFC 5234, January 2008. 799 8.2 Informative References 801 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 802 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 803 Session Initiation Protocol", RFC 3261, June 2002. 805 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 806 Description Protocol", RFC 4566, July 2006. 808 [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 809 Session Description Protocol (SDP)", RFC 3264, June 2002. 811 [10] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 812 Security Considerations", BCP 72, RFC 3552, July 2003. 814 [11] Cadzow, J., Foundations of Digital Signal Processing and Data 815 Analysis New York, New York: Macmillan, 1987. 817 [12] Lei, W., Zhang, W., and S. Liu, "A Framework of Multipath 818 Transport System Based on Application-Level Relay", 819 draft-leiwm-tsvwg-mpts-ar-05 (work in progress), January 2016. 821 [13] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 822 Reserved for Documentation", RFC3849, July 2004. 824 [14] Robachevsky, A., "Mandating use of IPv6 in examples", 825 draft-robachevsky-mandating-use-of-ipv6-examples-01 (work in 826 progress), April 2016. 828 Authors' Addresses 830 Weimin Lei 831 Northeastern University 832 Department of Communication and Electronic Engineering 833 College of Computer Science and Engineering 834 Shenyang, China, 110819 835 P. R. China 837 Phone: +86-24-8368-3048 838 Email: leiweimin@mail.neu.edu.cn 840 Wei Zhang 841 Northeastern University 842 Department of Communication and Electronic Engineering 843 College of Computer Science and Engineering 844 Shenyang, China, 110819 845 P. R. China 847 Email: zhangwei1@mail.neu.edu.cn 849 Shaowei Liu 850 Northeastern University 851 IDepartment of Communication and Electronic Engineering 852 College of Computer Science and Engineering 853 Shenyang, China, 110819 854 P. R. China 856 Email: liu_nongfu@163.com