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