idnits 2.17.1 draft-singh-avtcore-mprtp-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4791 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5245 (ref. '3') (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5285 (ref. '8') (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '9') (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5117 (ref. '12') (Obsoleted by RFC 7667) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-27 -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '17') (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Core Working Group V. Singh 3 Internet-Draft T. Karkkainen 4 Intended status: Experimental J. Ott 5 Expires: September 15, 2011 S. Ahsan 6 Aalto University 7 L. Eggert 8 Nokia 9 March 14, 2011 11 Multipath RTP (MPRTP) 12 draft-singh-avtcore-mprtp-01 14 Abstract 16 The Real-time Transport Protocol (RTP) is used to deliver real-time 17 content and, along with the RTP Control Protocol (RTCP), forms the 18 control channel between the sender and receiver. However, RTP and 19 RTCP assume a single delivery path between the sender and receiver 20 and make decisions based on the measured characteristics of this 21 single path. Increasingly, endpoints are becoming multi-homed, which 22 means that they are connected via multiple Internet paths. Network 23 utilization can be improved when endpoints use multiple parallel 24 paths for communication. The resulting increase in reliability and 25 throughput can also enhance the user experience. This document 26 extends the Real-time Transport Protocol (RTP) so that a single 27 session can take advantage of the availability of multiple paths 28 between two endpoints. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 15, 2011. 47 Copyright Notice 48 Copyright (c) 2011 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 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Functional goals . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 6 70 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Relationship of MPRTP with Session Signaling . . . . . . . 8 73 5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 8 74 5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . . 8 75 5.2. Conversational use-case . . . . . . . . . . . . . . . . . 9 76 5.3. Challenges with Multipath Interface Discovery . . . . . . 10 77 6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 10 78 7. Available Mechanisms within the Functional Blocks . . . . . . 11 79 7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 11 80 7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 11 81 7.3. Adding New Interfaces . . . . . . . . . . . . . . . . . . 11 82 7.4. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . . 12 83 7.5. Checking and Failure Handling . . . . . . . . . . . . . . 12 84 8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 8.1.1. Subflow or Interface advertisement . . . . . . . . . . 14 87 8.1.2. Path selection . . . . . . . . . . . . . . . . . . . . 14 88 8.1.3. Opening subflows . . . . . . . . . . . . . . . . . . . 15 89 8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . . 15 90 8.3. Playout Considerations at the Receiver . . . . . . . . . . 15 91 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 16 92 8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 16 93 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 16 94 9.1. RTCP Extension for Interface advertisement . . . . . . . . 16 95 9.1.1. Interface Advertisement block . . . . . . . . . . . . 18 96 9.2. MPRTP RTP Header Extension . . . . . . . . . . . . . . . . 19 97 9.2.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 20 98 9.2.2. MPRTP RTP Extension for Connectivity Checks . . . . . 21 99 9.2.3. MPRTP RTP Extension for Keep-alive Packets . . . . . . 21 100 9.3. MPRTP Extension for Subflow Reporting (MPRTCP) . . . . . . 21 101 9.3.1. MPRTCP Generic Extension . . . . . . . . . . . . . . . 21 102 9.3.2. MPRTCP for Subflow-specific SR, RR and XR . . . . . . 23 103 10. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 25 104 10.1. Increased Throughput . . . . . . . . . . . . . . . . . . . 25 105 10.2. Increased Reliability . . . . . . . . . . . . . . . . . . 25 106 10.3. MPRTP using preloaded interfaces from ICE . . . . . . . . 25 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 108 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 109 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 110 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 14.1. Normative References . . . . . . . . . . . . . . . . . . . 26 112 14.2. Informative References . . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 115 1. Introduction 117 Multi-homed endpoints are becoming common in today's Internet, e.g., 118 devices that support multiple wireless access technologies such as 3G 119 and Wireless LAN. This means that there is often more than one 120 network path available between two endpoints. Transport protocols, 121 such as RTP, have not been designed to take advantage of the 122 availability of multiple concurrent paths and therefore cannot 123 benefit from the increased capacity and reliability that can be 124 achieved by pooling their respective capacities. 126 Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [1] that allows 127 splitting a single RTP stream into multiple subflows that are 128 transmitted over different paths. In effect, this pools the resource 129 capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension 130 to RTCP, it is used along with MPRTP to report per-path sender and 131 receiver characteristics. 133 Other IETF transport protocols that are capable of using multiple 134 paths include SCTP [9], MPTCP MPTCP [10] and SHIM6 [11]. However, 135 these protocols are not suitable for realtime communications. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [2]. 143 1.2. Terminology 145 o Endpoint: host either initiating or terminating an RTP connection. 147 o Interface: logical or physical component that is capable of 148 acquiring a unique IP address. 150 o Path: sequence of links between a sender and a receiver. 151 Typically, defined by a set of source and destination addresses. 153 o Subflow: flow of RTP packets along a specific path, i.e., a subset 154 of the packets belonging to an RTP stream. The combination of all 155 RTP subflows forms the complete RTP stream. Typically, a subflow 156 would map to a unique path, i.e., each combination of IP addresses 157 and port pairs (4-tuple) is a unique subflow. 159 1.3. Use-cases 161 The primary use-case for MPRTP is transporting high bit-rate 162 streaming multimedia content between endpoints, where at least one is 163 multi-homed. Such endpoints could be residential IPTV devices that 164 connect to the Internet through two different Internet service 165 providers (ISPs), or mobile devices that connect to the Internet 166 through 3G and WLAN interfaces. By allowing RTP to use multiple 167 paths for transmission, the following gains can be achieved: 169 o Higher quality: Pooling the resource capacity of multiple Internet 170 paths allows higher bit-rate and higher quality codecs to be used. 171 From the application perspective, the available bandwidth between 172 the two endpoints increases. 174 o Load balancing: Transmitting one RTP stream over multiple paths 175 can reduce the bandwidth usage, compared to transmitting the same 176 stream along a single path. This reduces the impact on other 177 traffic. 179 o Fault tolerance: When multiple paths are used in conjunction with 180 redundancy mechanisms (FEC, re-transmissions, etc.), outages on 181 one path have less impact on the overall perceived quality of the 182 stream. 184 A secondary use-case for MPRTP is transporting Voice over IP (VoIP) 185 calls to a device with multiple interfaces. Again, such an endpoint 186 could be a mobile device with multiple wireless interfaces. In this 187 case, little is to be gained from resource pooling, i.e., higher 188 capacity or load balancing, because a single path should be easily 189 capable of handling the required load. However, using multiple 190 concurrent subflows can improve fault tolerance, because traffic can 191 shift between the subflows when path outages occur. This results in 192 very fast transport-layer handovers that do not require support from 193 signaling. 195 2. Goals 197 This section outlines the basic goals that multipath RTP aims to 198 meet. These are broadly classified as Functional goals and 199 Compatibility goals. 201 2.1. Functional goals 203 Allow unicast RTP session to be split into multiple subflows in order 204 to be carried over multiple paths. This may prove beneficial in case 205 of video streaming. 207 o Increased Throughput: Cumulative capacity of the two paths may 208 meet the requirements of the multimedia session. Therefore, MPRTP 209 MUST support concurrent use of the multiple paths. 211 o Improved Reliability: MPRTP SHOULD be able to send redundant 212 packets or re-transmit packets along any available path to 213 increase reliability. 215 The protocol SHOULD be able to open new subflows for an existing 216 session when new paths appear and MUST be able to close subflows when 217 paths disappear. 219 2.2. Compatibility goals 221 MPRTP MUST be backwards compatible; an MPRTP stream needs to fall 222 back to be compatible with legacy RTP stacks if MPRTP support is not 223 successfully negotiated. 225 o Application Compatibility: MPRTP service model MUST be backwards 226 compatible with existing RTP applications, i.e., an MPRTP stack 227 MUST be able to work with legacy RTP applications and not require 228 changes to them. Therefore, the basic RTP APIs MUST remain 229 unchanged, but an MPRTP stack MAY provide extended APIs so that 230 the application can configure any additional features provided by 231 the MPRTP stack. 233 o Network Compatibility: individual RTP subflows MUST themselves be 234 well-formed RTP flows, so that they are able to traverse NATs and 235 firewalls. This MUST be the case even when interfaces appear 236 after session initiation. Interactive Connectivity Establishment 237 (ICE) [3] MAY be used for discovering new interfaces or performing 238 connectivity checks. 240 3. RTP Topologies 242 RFC 5117 [12] describes a number of scenarios using mixers and 243 translators in single-party (point-to-point), and multi-party (point- 244 to-multipoint) scenarios. RFC 3550 [1] (Section 2.3 and 7.x) discuss 245 in detail the impact of mixers and translators on RTP and RTCP 246 packets. MPRTP assumes that if a mixer or translator exists in the 247 network, then either all of the multiple paths or none of the 248 multiple paths go via this component. 250 4. MPRTP Architecture 252 In a typical scenario, an RTP session uses a single path. In an 253 MPRTP scenario, an RTP session uses multiple subflows that each use a 254 different path. Figure 1 shows the difference. 256 +--------------+ Signaling +--------------+ 257 | |------------------------------------>| | 258 | Client |<------------------------------------| Server | 259 | | Single RTP flow | | 260 +--------------+ +--------------+ 262 +--------------+ Signaling +--------------+ 263 | |------------------------------------>| | 264 | Client |<------------------------------------| Server | 265 | |<------------------------------------| | 266 +--------------+ MPRTP subflows +--------------+ 268 Figure 1: Comparison between traditional RTP streaming and MPRTP 270 +-----------------------+ +-------------------------------+ 271 | Application | | Application | 272 +-----------------------+ +-------------------------------+ 273 | | | MPRTP | 274 + RTP + +- - - - - - - -+- - - - - - - -+ 275 | | | RTP subflow | RTP subflow | 276 +-----------------------+ +---------------+---------------+ 277 | UDP | | UDP | UDP | 278 +-----------------------+ +---------------+---------------+ 279 | IP | | IP | IP | 280 +-----------------------+ +---------------+---------------+ 282 Figure 2: MPRTP Architecture 284 Figure 2 illustrates the differences between the standard RTP stack 285 and the MPRTP stack. MPRTP receives a normal RTP session from the 286 application and splits it into multiple RTP subflows. Each subflow 287 is then sent along a different path to the receiver. To the network, 288 each subflow appears as an independent, well-formed RTP flow. At the 289 receiver, the subflows are combined to recreate the original RTP 290 session. The MPRTP layer performs the following functions: 292 o Path Management: The layer is aware of alternate paths to the 293 other host, which may, for example, be the peer's multiple 294 interfaces. So that it is able to send differently marked packets 295 along separate paths. MPRTP also selects interfaces to send and 296 receive data. Furthermore, it manages the port and IP address 297 pair bindings for each subflow. 299 o Packet Scheduling: the layer splits a single RTP flow into 300 multiple subflows and sends them across multiple interfaces 301 (paths). The splitting MAY BE done using different path 302 characteristics. 304 o Subflow recombination: the layer creates the original stream by 305 recombining the independent subflows. Therefore, the multipath 306 subflows appear as a single RTP stream to applications. 308 4.1. Relationship of MPRTP with Session Signaling 310 Session signaling (e.g., SIP [13], RTSP [14]) SHOULD be done over a 311 failover-capable or multipath-capable transport for e.g., SCTP [9] or 312 MPTCP [10] instead of TCP or UDP. 314 5. Example Media Flow Diagrams 316 There may be many complex technical scenarios for MPRTP, however, 317 this memo only considers the following two scenarios: 1) a 318 unidirectional media flow that represents the streaming use-case, and 319 2) a bidirectional media flow that represents a conversational use- 320 case. 322 5.1. Streaming use-case 324 In the unidirectional scenario, the receiver (client) initiates a 325 multimedia session with the sender (server). The receiver or the 326 sender may have multiple interfaces and both endpoints are MPRTP- 327 capable. Figure 3 shows this scenario. In this case, host A has 328 multiple interfaces. Host B performs connectivity checks on host A's 329 multiple interfaces. If the interfaces are reachable, then host B 330 streams multimedia data along multiple paths to host A. Moreover, 331 host B also sends RTCP Sender Reports (SR) for each subflow and host 332 A responds with a standard RTCP Receiver Report (RR) for the overall 333 session and receiver statistics for each subflow. Host B distributes 334 the packets across the subflows based on the individually measured 335 path characteristics. 337 Alternatively, to reduce media startup time, host B may start 338 streaming multimedia data to host A's initiating interface and then 339 perform connectivity checks for the other interfaces. This method of 340 updating a single path session to a multipath session is called 341 "multipath session upgrade". 343 Host A Host B 344 ----------------------- ---------- 345 Address A1 Address A2 Address B1 346 ----------------------- ---------- 347 | Session Setup | 348 |------------------------------------->| connections at endpoint 349 |<-------------------------------------| may be "preloaded" 350 | | | (e.g., with ICE) 351 | | | 352 | (RTP data B1->A1, B1->A2) | 353 |<=====================================| 354 | |<========================| 355 | | | 356 Note: there may be more scenarios. 358 Figure 3: Unidirectional media flow 360 5.2. Conversational use-case 362 In the bidirectional scenario, multimedia data flows in both 363 directions. The two hosts exchange their lists of interfaces with 364 each other and perform connectivity checks. Communication begins 365 after each host finds suitable address, port pairs. Interfaces that 366 receive data send back RTCP receiver statistics for that path (based 367 on the 4-tuple). The hosts balance their multimedia stream across 368 multiple paths based on the per path reception statistics and its own 369 volume of traffic. Figure 4 describes an example of a bidirectional 370 flow. 372 Host A Host B 373 ----------------------- ----------------------- 374 Address A1 Address A2 Address B1 Address B2 375 ----------------------- ----------------------- 376 | | | | 377 | Session Setup | | connections at 378 |----------------------------------->| | the endpoint may 379 |<-----------------------------------| | be "preloaded" 380 | | | | (e.g., ICE) 381 | | | | 382 | (RTP data B1<->A1, B2<->A2) | | 383 |<===================================| | 384 | |<===================================| 385 |===================================>| | 386 | |===================================>| 387 | | | | 388 Note: the address pairs may have other permutations, 389 and they may be symmetric or asymmetric combinations. 391 Figure 4: Bidirectional flow 393 5.3. Challenges with Multipath Interface Discovery 395 For some applications, where the user expects immediate playback, 396 e.g., High Definition Media Streaming or IPTV, it may not be possible 397 to perform connectivity checks within the given time bound. In these 398 cases, connectivity checks MAY need to be done ahead of time. 400 [Open Issue: ICE or any other system would have to be aware of the 401 endpoint's interfaces ahead of time]. 403 6. MPRTP Functional Blocks 405 This section describes some of the functional blocks needed for 406 MPRTP. We then investigate each block and consider available 407 mechanisms in the next section. 409 1. Session Setup: Multipath session setup is an upgrade or add-on to 410 a typical RTP session. Interfaces may appear or disappear at 411 anytime during the session. To preserve backward compatibility 412 with legacy applications, a multipath session MUST look like a 413 bundle of individual RTP sessions. 415 2. Expanding RTP: For a multipath session, each subflow MUST look 416 like an independent RTP flow, so that individual RTCP messages 417 can be generated per subflow. Furthermore, MPRTP splits the 418 single multimedia stream into multiple subflows based on path 419 characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- 420 delay product etc.) and dynamically adjusts the load on each 421 link. 423 3. Adding Interfaces: Interfaces on the host need to be regularly 424 discovered and signaled. This can be done at session setup 425 and/or during the session. When discovering and receiving new 426 interfaces, the MPRTP layer needs to select address and port 427 pairs. 429 4. Expanding RTCP: MPRTP MUST recombine RTCP reports from each path 430 to re-create a single RTCP message to maintain backward 431 compatibility with legacy applications. 433 5. Maintenance and Failure Handling: In a multi-homed endpoint 434 interfaces may appear and disappear. If this happens at the 435 sender, it has to re-adjust the load on the available links. On 436 the other hand, if this occurs on the receiver, then the 437 multimedia data transmitted by the sender to those interfaces is 438 lost. This data may be re-transmitted along a different path 439 i.e., to a different interface on the receiver. Furthermore, the 440 receiver has to explicitly signal the disappearance of an 441 interface, or the sender has to detect it. [Open Issue: What 442 happens if the interface that setup the session disappears? does 443 the control channel also failover? re-start the session?] 445 6. Teardown: The MPRTP layer releases the occupied ports on the 446 interfaces. 448 7. Available Mechanisms within the Functional Blocks 450 This section discusses some of the possible alternatives for each 451 functional block mentioned in the previous section. 453 7.1. Session Setup 455 MPRTP session can be set up in many possible ways e.g., during 456 handshake, or upgraded mid-session. The capability exchange may be 457 done using out-of-band signaling (e.g., SDP [15] in SIP [13], RTSP 458 [14]) or in-band signaling (e.g., RTP/RTCP header extension). 459 Furthermore, ICE [3] may be used for discovering and performing 460 connectivity checks during session setup. 462 7.2. Expanding RTP 464 RTCP [1] is generated per media session. However, with MPRTP, the 465 media sender spreads the RTP load across several interfaces. The 466 media sender SHOULD make the path selection, load balancing and fault 467 tolerance decisions based on the characteristics of each path. 468 Therefore, apart from normal RTP sequence numbers defined in [1], the 469 MPRTP sender MUST add subflow-specific sequence numbers to help 470 calculate fractional losses, jitter, RTT, playout time, etc., for 471 each path and a subflow identifier to associate the characteristics 472 with a path. The RTP header extension for MPRTP is shown in 473 Section 9). 475 7.3. Adding New Interfaces 477 When interfaces appear and disappear mid-session, ICE [3] may be used 478 for discovering interfaces and performing connectivity checks. 479 However, MPRTP may require a capability re-negotiation (using SDP) to 480 include all these new interfaces. This method is referred to as out- 481 of-band multipath advertisement. 483 Alternatively, when new interfaces appear, the interface 484 advertisements may be done in-band using RTP/RTCP extensions. The 485 endpoints perform connectivity checks (see Figure 5 for more 486 details). If the connectivity packets are received by the peers, 487 then multimedia data can flow between the new address, port pairs. 489 7.4. Expanding RTCP 491 To provide accurate per path information an MPRTP endpoint MUST send 492 (SR/RR) report for each unique subflow along with the overall session 493 RTCP report. Therefore, the additional subflow reporting affects the 494 RTCP bandwidth and the RTCP reporting interval for each subflow. 495 RTCP report scheduling for each subflow may cause a problem for RTCP 496 recombination and reconstruction in cases when 1) RTCP for a subflow 497 is lost, and 2) RTCP for a subflow arrives later than the other 498 subflows. (There may be other cases as well.) 500 The sender distributes the media across different paths using the per 501 path RTCP reports. However, this document doesn't cover algorithms 502 for congestion control or load balancing. 504 7.5. Checking and Failure Handling 506 [Note: If the original interface that setup the session disappears 507 then does the session signaling failover to another interface? Can 508 we recommend that SIP/RTSP be run over MPTCP, SCTP]. 510 8. MPRTP Protocol 512 To enable a quick start of a multimedia session, a multipath session 513 MUST be upgraded from a single path session. Therefore, no explicit 514 changes are needed in multimedia session setup and the session can be 515 setup as before. 517 Host A Host B 518 ----------------------- ----------------------- 519 Address A1 Address A2 Address B1 Address B2 520 ----------------------- ----------------------- 521 | | | | 522 | | (1) | | 523 |--------------------------------------->| | 524 |<---------------------------------------| | 525 | | (2) | | 526 |<=======================================| | 527 |<=======================================| (3) | 528 | | (4) | | 529 |<=======================================| | 530 |<=======================================| | 531 |<=======================================| | 532 | | (5) | | 533 |- - - - - - - - - - - - - - - - - - - ->| | 534 |<=======================================| (6) | 535 |<=======================================| | 536 | |<========================================| 537 |<=======================================| | 538 | |<========================================| 540 Key: 541 | Interface 542 ---> Signaling Protocol 543 <=== RTP Packets 544 - -> RTCP Packet 546 Figure 5: MPRTP New Interface 548 8.1. Overview 550 The bullet points explain the different steps shown in Figure 5 for 551 upgrading a standard single path multimedia session to multipath 552 session. 554 (1) The first two interactions between the hosts represents the 555 standard session setup. This may be SIP or RTSP. 557 (2) Following the setup, like in a conventional RTP scenario, host 558 B using interface B1 starts to stream data to host A at interface 559 A1. 561 (3) Host B is an MPRTP-capable media sender and becomes aware of 562 another interface B2. 564 (4) Host B advertises the multiple interface addresses using an 565 RTCP header extensions. 567 (5) Host A is an MPRTP-capable media receiver and becomes aware of 568 another interface A2. It advertises the multiple interface 569 addresses using an RTCP extension. 571 Side note, even if an MPRTP-capable host has only one interface, 572 it SHOULD respond to the advertisement with its single interface. 574 (6) Each host receives information about the additional interfaces 575 and performs the connectivity tests (not shown in figure). If the 576 paths are reachable then the host starts to stream the multimedia 577 content using the additional paths. 579 8.1.1. Subflow or Interface advertisement 581 To advertise the multiple interfaces, an MPRTP-capable endpoint MUST 582 add the MPRTP Interface Advertisement defined in Figure 6 with the 583 RTCP Sender Report (SR). Each unique address is encapsulated in an 584 Interface Advertisement block and contains the IP address, RTP and 585 RTCP port addresses. The Interface Advertisement blocks are ordered 586 based on a decreasing priority level. On receiving the MPRTP 587 Interface Advertisement, an MPRTP-capable receiver MUST respond with 588 its own set of interfaces. 590 If the sender and receiver have only one interface, then the 591 endpoints MUST respond with the default IP, RTP port and RTCP port 592 addresses. If an endpoint receives an RTCP report without the MPRTP 593 Interface Advertisement, then the endpoint MUST assume that the other 594 endpoint is not MPRTP capable. 596 8.1.2. Path selection 598 After MPRTP support has been discovered and interface advertisements 599 have been exchanged, the sender MUST initiate connectivity checks to 600 determine which interface pairs offer valid paths between the sender 601 and the receiver. Each combination of IP addresses and port pairs 602 (4-tuple) is a unique subflow. An endpoint MUST associate a Subflow 603 ID to each unique subflow. 605 To initiate a connectivity check, the endpoints send an RTP packet 606 using the appropriate MPRTP extension header (See Figure 10), 607 associated Subflow ID and no RTP payload. The receiving endpoint 608 replies to each connectivity check with an RTCP packet with the 609 appropriate packet type (See Figure 7) and Subflow ID. After the 610 endpoint receives the reply, the path is considered a valid candidate 611 for sending data. An endpoint MAY choose to do any number of 612 connectivity checks for any interface pairs at any point in a 613 session. 615 [Open Issue: How should the endpoint adjust the RTCP Reporting 616 interval/schedule the RTCP packet on receiving a connectivity check 617 containing a new Subflow ID? Editor: One option is send immediately 618 as defined in [4]. Another option is the RTCP timing defined in 619 [16].] 621 8.1.3. Opening subflows 623 The sender MAY open any number of subflows from the set of candidate 624 subflows after performing connectivity checks. To use the subflow, 625 the sender simply starts sending the RTP packets with an MPRTP 626 extension shown in Figure 9. The MPRTP extension carries a mapping 627 of a subflow packet to the aggregate flow. Namely, sequence numbers 628 and timestamps associated with the subflow. 630 An endpoint MAY use all or a subset of candidate subflows for sending 631 media packets. To avoid redoing the connectivity checks the endpoint 632 MAY send keep-alive MPRTP packets (see Section 9.2.3) to the passive 633 subflows to keep the NAT bindings alive. 635 [Open Issue: How to differentiate between Passive and Active 636 connections? Editor: Active paths get "regular flow" of media 637 packets while passive paths are for failover of active paths. ] 639 [Open Issue: How to keep a passive connection alive, if not actively 640 used? Alternatively, what is the maximum timeout? Editor: keep- 641 alive for ICE/NAT bindings should not be less than 15 seconds [3].] 643 8.2. RTP Transmission 645 The MPRTP layer SHOULD associate an RTP packet with a subflow based 646 on a scheduling strategy. The scheduling strategy may either choose 647 to augment the paths to create higher throughput or use the alternate 648 paths for enhancing resilience or error-repair. Due to the changes 649 in path characteristics, an MPRTP sender can change its scheduling 650 strategy during an ongoing session. The MPRTP sender MUST also 651 populate the subflow specific fields described in the MPRTP extension 652 header (see Section 9.2.1). 654 8.3. Playout Considerations at the Receiver 656 A media receiver, irrespective of MPRTP support or not, should be 657 able to playback the media stream because the received RTP packets 658 are compliant to [1], i.e., a non-MPRTP receiver will ignore the 659 MPRTP header and still be able to playback the RTP packets. However, 660 the variation of jitter and loss per path may affect proper playout. 661 By calculating optimum skew across all paths, the receiver can 662 compensate for the jitter by modifying the playout delay (adaptive 663 playout) of the received RTP packets. 665 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation 667 Aggregate RTCP provides the overall media statistics and follows the 668 standard RTCP defined in RFC3550 [1]. However, subflow specific RTCP 669 provides the per path media statistics because the aggregate RTCP 670 report may not provide sufficient per path information to an MPRTP 671 scheduler. Specifically, the scheduler should be aware of each 672 path's RTT and loss-rate, which an aggregate RTCP cannot provide. 673 The sender/receiver MUST use non-compound RTCP reports defined in 674 RFC5506 [5] to transmit the aggregate and subflow-specific RTCP 675 reports. Also, each subflow and the aggregate RTCP report MUST 676 follow the timing rules defined in [4]. 678 The RTCP reporting interval is locally implemented and the scheduling 679 of the RTCP reports may depend on the the behavior of each path. For 680 instance, the RTCP interval may be different for a passive path than 681 an active path to keep port bindings alive. Additionally, an 682 endpoint may decide to share the RTCP reporting bit rate equally 683 across all its paths or schedule based on the receiver rate on each 684 path. 686 8.5. RTCP Transmission 688 The sender sends an RTCP SR on each active path. For each SR the 689 receiver gets, it echoes one back to the same IP address-port pair 690 that sent the SR. The receiver tries to choose the symmetric path 691 and if the routing is symmetric then the per-path RTT calculations 692 will work out correctly. However, even if the paths are not 693 symmetric, the sender would at maximum, under-estimate the RTT of the 694 path by a factor of half of the actual path RTT. 696 9. Packet Formats 698 In this section we define the protocol structures described in the 699 previous sections. 701 9.1. RTCP Extension for Interface advertisement 703 This sub-section defines the RTCP header extension for in-band 704 interface advertisement by the receiver, instead of relying on ICE or 705 in situations when the interface appears after SDP session 706 establishment. 708 The interface advertisement SHOULD immediately follow the Receiver 709 Report. If the Receiver Report is not present, then it MUST be 710 appended to the Sender Report. 712 The endpoint MUST advertise all its interfaces when a new interface 713 appears. Furthermore, an endpoint MUST advertise all its interfaces 714 when it receives an Interface Advertisement. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 |V=2|P|reserved | PT=MP_IA=210 | length | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | SSRC of packet sender | 722 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 723 | SSRC_1 (SSRC of first source) | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | MPR_Type=0x00 | block length | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Interface #1 Advertisement block | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Interface #2 Advertisement block | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Interface #... Advertisement block | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Interface #m Advertisement block | 734 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 736 Figure 6: MPRTP Interface Advertisement. (appended to SR/RR) 738 MP_IA: 8 bits 740 Contains the constant 210 to identify this as an interface 741 advertisement. 743 length: 16 bits 745 As described for the RTCP packet (see Section 6.4.1 of the RTP 746 specification [1]), the length of this is in 32-bit words minus 747 one, including the header and any padding. 749 MPR_Type: 16-bits 751 The MPRR_Type field corresponds to the type of MPRTP RTCP 752 packet. Namely: 754 +---------------+--------------------------------------------------+ 755 | MPR_Type | Use | 756 | Value | | 757 +---------------+--------------------------------------------------+ 758 | 0x00 | Interface Advertisement | 759 | 0x01 | Connectivity Check. For this case the length is | 760 | | set to 0 | 761 | TBD | Keep Alive Packet. | 762 +---------------+--------------------------------------------------+ 764 Figure 7: RTP header extension values for MPRTP (MPR_Type) 766 block length: 16-bits 768 The 16-bit length field is the length of the encapsulated 769 advertisement blocks in 32-bit word length not including the 770 MPR_Type and length fields. The value zero indicates there is 771 no data following. 773 Interface Advertisement block: variable size 775 Defined later in 9.1.1. 777 9.1.1. Interface Advertisement block 779 This block describes a method to represent IPv4, IPv6 and generic 780 DNS-type addresses in a block format. It is based on the sub- 781 reporting block in RFC 5760 [6]. 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Type={0,1,2} | Length | Subflow ID | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | RTCP Port | RTCP Port | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Address | 791 + + 792 : : 793 | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Figure 8: Interface Advertisement block during path discovery 798 Type: 8 bits 800 The Type corresponds to the type of address. Namely: 802 0: IPv4 address 804 1: IPv6 address 806 2: DNS name 808 Length: 8 bits 810 The length of the Interface Advertisement block in bytes. 812 For an IPv4 address, this should be 9 (i.e., 5 octets for 813 the header and 4 octets for IPv4 address). 815 For an IPv6 address, this should be 21. 817 For a DNS name, the length field indicates the number of 818 octets making up the string plus the 5 byte header. 820 RTP Port: 2 octets 822 The port number to which the sender sends RTP data. A port 823 number of 0 is invalid and MUST NOT be used. 825 RTCP Port: 2 octets 827 The port number to which receivers send feedback reports. A 828 port number of 0 is invalid and MUST NOT be used. 830 Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) 832 The address to which receivers send feedback reports. For IPv4 833 and IPv6, fixed-length address fields are used. A DNS name is 834 an arbitrary-length string. The string MAY contain 835 Internationalizing Domain Names in Applications (IDNA) domain 836 names and MUST be UTF-8 encoded [7]. 838 9.2. MPRTP RTP Header Extension 840 The MPRTP header extension is used to 1) distribute a single RTP 841 stream over multiple subflows, 2) perform connectivity checks on the 842 advertised interfaces, and 3) keep-alive passive interfaces (paths). 844 The header conforms to the 2-byte RTP header extension defined in 845 [8]. The header extension contains a 16-bit length field that counts 846 the number of 32-bit words in the extension, excluding the four-octet 847 extension header (therefore zero is a valid length, see Section 5.3.1 848 of [1] for details). 850 To signal the use of the above RTP header extensions in SDP, the 851 following URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp. 853 9.2.1. MPRTP RTP Extension for a Subflow 855 The RTP header for each subflow is defined below: 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 |V=2|P|1| CC |M| PT | sequence number | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | timestamp | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | synchronization source (SSRC) identifier | 865 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 866 | 0x10 | 0x00 | len=N-1 words | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | H-Ext ID | length | Subflow ID | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Subflow-specific Seq Number | Pad (0) | Pad (0) | 871 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 872 | RTP payload | 873 | .... | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Figure 9: MPRTP header for subflow 878 H-Ext ID and length: 8-bits each 880 The field corresponds to the type of MPRTP packet. Namely: 882 +---------------+--------------------------------------------------+ 883 | H-Ext ID | Use | 884 | Value | | 885 +---------------+--------------------------------------------------+ 886 | 0x00 | Subflow RTP Header. For this case the Length is | 887 | | set to 6 | 888 | 0x01 | Connectivity Check. For this case the length is | 889 | | set to 0 | 890 | TBD | Keep Alive Packet. | 891 +---------------+--------------------------------------------------+ 893 Figure 10: RTP header extension values for MPRTP (H-Ext ID) 895 length 896 The 8-bit length field is the length of extension data in bytes 897 not including the H-Ext ID and length fields. The value zero 898 indicates there is no data following. 900 Subflow ID: Identifier of the subflow. Every RTP packet belonging 901 to the same subflow carries the same unique subflow identifier. 903 Flow-Specific Sequence Number (FSSN): Sequence of the packet in 904 the subflow. Each subflow has its own strictly monotonically 905 increasing sequence number space. 907 9.2.2. MPRTP RTP Extension for Connectivity Checks 909 [Open Issue: What sequence number to use for the RTP session? 910 Alternative 1: An MPRTP receiver MUST NOT send the packet with H-Ext 911 ID=0x01 to the decoder and ignore these packets from RTCP 912 calculation. Alternative 2: Instead of sending an RTP packet the 913 sender transmits a modified STUN packet.] 915 9.2.3. MPRTP RTP Extension for Keep-alive Packets 917 [Editor: Waiting for the progress on RTCP guidelines for the RTP keep 918 alive packet [16]. 920 9.3. MPRTP Extension for Subflow Reporting (MPRTCP) 922 The MPRTP RTCP header extension is used to 1) provide RTCP feedback 923 per subflow to determine the characteristics of each path, 2) perform 924 connectivity check on the other endpoint's interfaces, and 3) to keep 925 alive a passive connection. 927 9.3.1. MPRTCP Generic Extension 929 When sending a report for a specific subflow the sender or receiver 930 MUST add only the reports associated with that 4-tuple. Each subflow 931 is reported independently using the following MPRTCP Feedback header. 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 |V=2|P|reserved | PT=SFR=211 | length | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 938 | SSRC of sender | D 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 940 | Subflow ID #1 | reserved | 941 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 942 | Subflow-specific reports | 943 | .... | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 |V=2|P|reserved | PT=SFR=211 | length | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 947 | SSRC of sender | D 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 949 | Subflow ID #2 | reserved | 950 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 951 | Subflow-specific reports | 952 | .... | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Figure 11: MPRTCP Generic Feedback Header 957 Subflow ID: 16 bits 959 Subflow identifier is the value associated with the subflow the 960 endpoint is reporting about. If it is a sender it MUST use the 961 Subflow ID associated with the 4-tuple. If it is a receiver it 962 MUST use the Subflow ID received in the Subflow-specific Sender 963 Report. 965 length: 16 bits 967 The length of this RTCP packet in 32-bit words minus one, 968 including the header and any padding. It MUST contain at least 969 one subflow report, for e.g., Sender Subflow Report, Receiver 970 Subflow Report, or Subflow Extension Reports, etc. 972 Subflow-specific reports: variable 974 Subflow-specific report contains all the reports associated with 975 the Subflow ID. For a sender, it MUST include the Subflow- 976 specific Sender Report (SSR). For a receiver, it MUST include 977 Subflow-specific Receiver Report (SRR). Additionally, if the 978 receiver supports subflow-specific extension reports then it MUST 979 append them to the SRR. 981 9.3.2. MPRTCP for Subflow-specific SR, RR and XR 983 [Editor: inside the context of subflow specific reports can we reuse 984 the payload type code for Sender Report (PT=200), Receiver Report 985 (PT=201), Extension Report (PT=207). Transport and Payload specific 986 RTCP messages are session specific and SHOULD be used as before.] 988 Example: 990 0 1 2 3 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 |V=2|P|reserved | PT=SFR=211 | length=9 | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 995 | SSRC of sender | D 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 997 | Subflow ID #1 | reserved | 998 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 999 |V=2|P| RC | PT=SR=200 | length | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | SSRC of sender | 1002 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1003 | NTP timestamp, most significant word | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | NTP timestamp, least significant word | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | RTP timestamp | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | subflow's packet count | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | subflow's octet count | 1012 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1013 |V=2|P|reserved | PT=SFR=211 | length | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 1015 | SSRC of sender | D 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 1017 | Subflow ID #2 | reserved | 1018 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1019 |V=2|P| RC | PT=RR=201 | length | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | SSRC of packet sender | 1022 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1023 | fraction lost | cumulative number of packets lost | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | extended highest sequence number received | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | interarrival jitter | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | last SR (LSR) | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | delay since last SR (DLSR) | 1032 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1033 | Subflow specific extension reports | 1034 | .... | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header 1038 (Bi-directional use-case). 1040 10. SDP Considerations 1042 The packet formats specified in this document define extensions for 1043 RTP and RTCP. The use of MPRTP is left to the discretion of the 1044 sender and receiver. 1046 A participant of a media session MAY use SDP to signal that it 1047 supports MPRTP. Not providing this information may/will make the 1048 sender or receiver ignore the header extensions. However, MPRTP MAY 1049 be used by either sender or receiver without prior signaling. 1051 mprtp-attrib = "a=" "mprtp" [":" 1052 mprtp-optional-parameter] 1053 CRLF ; flag to enable MPRTP 1055 The literal 'mprtp' MUST be used to indicate support for MPRTP. 1056 Generally, senders and receivers SHOULD indicate this capability if 1057 they support MPRTP and would like to use it in the specific media 1058 session being signaled. However, it is possible for an MPRTP sender 1059 to stream data using multiple paths to a non-MPRTP client. 1061 Currently, there are no extensions defined for the literal 'mprtp' 1062 but we provide the opportunity to extend it using the mprtp-optional- 1063 parameter. 1065 10.1. Increased Throughput 1067 The MPRTP layer MAY choose to augment paths to increase throughput. 1068 If the desired media rate exceeds the current media rate, the 1069 endpoints MUST renegotiate the application specific ("b=AS:") [17] 1070 bandwidth. 1072 10.2. Increased Reliability 1074 TBD 1076 10.3. MPRTP using preloaded interfaces from ICE 1078 TBD 1080 11. IANA Considerations 1082 This document defines a new SDP attribute, "mprtp", within the 1083 existing IANA registry of SDP Parameters. 1085 TBD. 1087 12. Security Considerations 1089 All drafts are required to have a security considerations section. 1090 See RFC 3552 [18] for a guide. 1092 13. Acknowledgements 1094 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 1095 Trilogy (http://www.trilogy-project.org), a research project (ICT- 1096 216372) partially funded by the European Community under its Seventh 1097 Framework Program. The views expressed here are those of the 1098 author(s) only. The European Commission is not liable for any use 1099 that may be made of the information in this document. 1101 14. References 1103 14.1. Normative References 1105 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1106 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1107 RFC 3550, July 2003. 1109 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1110 Levels", BCP 14, RFC 2119, March 1997. 1112 [3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1113 Protocol for Network Address Translator (NAT) Traversal for 1114 Offer/Answer Protocols", RFC 5245, April 2010. 1116 [4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1117 "Extended RTP Profile for Real-time Transport Control Protocol 1118 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 1120 [5] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1121 Real-Time Transport Control Protocol (RTCP): Opportunities and 1122 Consequences", RFC 5506, April 2009. 1124 [6] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1125 Protocol (RTCP) Extensions for Single-Source Multicast Sessions 1126 with Unicast Feedback", RFC 5760, February 2010. 1128 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1129 STD 63, RFC 3629, November 2003. 1131 [8] Singer, D. and H. Desineni, "A General Mechanism for RTP Header 1132 Extensions", RFC 5285, July 2008. 1134 14.2. Informative References 1136 [9] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 1137 September 2007. 1139 [10] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, 1140 "Architectural Guidelines for Multipath TCP Development", 1141 draft-ietf-mptcp-architecture-05 (work in progress), 1142 January 2011. 1144 [11] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim 1145 Protocol for IPv6", RFC 5533, June 2009. 1147 [12] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1148 January 2008. 1150 [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1151 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1152 Session Initiation Protocol", RFC 3261, June 2002. 1154 [14] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. 1155 Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", 1156 draft-ietf-mmusic-rfc2326bis-27 (work in progress), March 2011. 1158 [15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1159 Session Description Protocol (SDP)", RFC 3264, June 2002. 1161 [16] Marjou, X. and A. Sollaud, "Application Mechanism for keeping 1162 alive the Network Address Translator (NAT) mappings associated 1163 to RTP/RTCP flows.", draft-ietf-avt-app-rtp-keepalive-10 (work 1164 in progress), March 2011. 1166 [17] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1167 Description Protocol", RFC 4566, July 2006. 1169 [18] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1170 Security Considerations", BCP 72, RFC 3552, July 2003. 1172 Authors' Addresses 1174 Varun Singh 1175 Aalto University 1176 School of Science and Technology 1177 Otakaari 5 A 1178 Espoo, FIN 02150 1179 Finland 1181 Email: varun@comnet.tkk.fi 1182 URI: http://www.netlab.tkk.fi/~varun/ 1184 Teemu Karkkainen 1185 Aalto University 1186 School of Science and Technology 1187 Otakaari 5 A 1188 Espoo, FIN 02150 1189 Finland 1191 Email: teemuk@comnet.tkk.fi 1193 Joerg Ott 1194 Aalto University 1195 School of Science and Technology 1196 Otakaari 5 A 1197 Espoo, FIN 02150 1198 Finland 1200 Email: jo@comnet.tkk.fi 1202 Saba Ahsan 1203 Aalto University 1204 School of Science and Technology 1205 Otakaari 5 A 1206 Espoo, FIN 02150 1207 Finland 1209 Email: sahsan@cc.hut.fi 1210 Lars Eggert 1211 Nokia Research Center 1212 P.O. Box 407 1213 Nokia Group 00045 1214 Finland 1216 Phone: +358 50 48 24461 1217 Email: lars.eggert@nokia.com 1218 URI: http://research.nokia.com/people/lars_eggert