idnits 2.17.1 draft-singh-avtcore-mprtp-02.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2011) is 4674 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. '6') (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '10') (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5117 (ref. '13') (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. '18') (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: January 9, 2012 S. Ahsan 6 Aalto University 7 L. Eggert 8 Nokia 9 July 8, 2011 11 Multipath RTP (MPRTP) 12 draft-singh-avtcore-mprtp-02 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 January 9, 2012. 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. RTP Header Extension for MPRTP . . . . . . . . . . . . . . 16 95 9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 18 96 9.1.2. MPRTP RTP Extension for Connectivity Checks . . . . . 19 97 9.1.3. MPRTP RTP Extension for Keep-alive Packets . . . . . . 19 98 9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 19 99 9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . . 20 100 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 22 101 9.3. MPRTCP Extension for Interface advertisement . . . . . . . 24 102 9.3.1. Interface Advertisement block . . . . . . . . . . . . 25 103 10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 26 104 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 26 105 11.1. Signaling MPRTP capability in SDP . . . . . . . . . . . . 26 106 11.2. Signaling MPRTP Header Extension in SDP . . . . . . . . . 27 107 11.3. MPRTP using preloaded interfaces from ICE (out-band 108 signaling) . . . . . . . . . . . . . . . . . . . . . . . . 27 109 11.3.1. "interface" attribute . . . . . . . . . . . . . . . . 27 110 11.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 28 111 11.4. Increased Throughput . . . . . . . . . . . . . . . . . . . 29 112 11.5. Offer/Answer Examples . . . . . . . . . . . . . . . . . . 29 113 11.5.1. In-band signaling . . . . . . . . . . . . . . . . . . 29 114 11.5.2. Out-band signaling . . . . . . . . . . . . . . . . . . 30 115 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 116 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 117 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 118 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 119 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 120 15.2. Informative References . . . . . . . . . . . . . . . . . . 32 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 123 1. Introduction 125 Multi-homed endpoints are becoming common in today's Internet, e.g., 126 devices that support multiple wireless access technologies such as 3G 127 and Wireless LAN. This means that there is often more than one 128 network path available between two endpoints. Transport protocols, 129 such as RTP, have not been designed to take advantage of the 130 availability of multiple concurrent paths and therefore cannot 131 benefit from the increased capacity and reliability that can be 132 achieved by pooling their respective capacities. 134 Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [1] that allows 135 splitting a single RTP stream into multiple subflows that are 136 transmitted over different paths. In effect, this pools the resource 137 capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension 138 to RTCP, it is used along with MPRTP to report per-path sender and 139 receiver characteristics. 141 Other IETF transport protocols that are capable of using multiple 142 paths include SCTP [10], MPTCP MPTCP [11] and SHIM6 [12]. However, 143 these protocols are not suitable for realtime communications. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [2]. 151 1.2. Terminology 153 o Endpoint: host either initiating or terminating an RTP connection. 155 o Interface: logical or physical component that is capable of 156 acquiring a unique IP address. 158 o Path: sequence of links between a sender and a receiver. 159 Typically, defined by a set of source and destination addresses. 161 o Subflow: flow of RTP packets along a specific path, i.e., a subset 162 of the packets belonging to an RTP stream. The combination of all 163 RTP subflows forms the complete RTP stream. Typically, a subflow 164 would map to a unique path, i.e., each combination of IP addresses 165 and port pairs (5-tuple) is a unique subflow. 167 1.3. Use-cases 169 The primary use-case for MPRTP is transporting high bit-rate 170 streaming multimedia content between endpoints, where at least one is 171 multi-homed. Such endpoints could be residential IPTV devices that 172 connect to the Internet through two different Internet service 173 providers (ISPs), or mobile devices that connect to the Internet 174 through 3G and WLAN interfaces. By allowing RTP to use multiple 175 paths for transmission, the following gains can be achieved: 177 o Higher quality: Pooling the resource capacity of multiple Internet 178 paths allows higher bit-rate and higher quality codecs to be used. 179 From the application perspective, the available bandwidth between 180 the two endpoints increases. 182 o Load balancing: Transmitting one RTP stream over multiple paths 183 can reduce the bandwidth usage, compared to transmitting the same 184 stream along a single path. This reduces the impact on other 185 traffic. 187 o Fault tolerance: When multiple paths are used in conjunction with 188 redundancy mechanisms (FEC, re-transmissions, etc.), outages on 189 one path have less impact on the overall perceived quality of the 190 stream. 192 A secondary use-case for MPRTP is transporting Voice over IP (VoIP) 193 calls to a device with multiple interfaces. Again, such an endpoint 194 could be a mobile device with multiple wireless interfaces. In this 195 case, little is to be gained from resource pooling, i.e., higher 196 capacity or load balancing, because a single path should be easily 197 capable of handling the required load. However, using multiple 198 concurrent subflows can improve fault tolerance, because traffic can 199 shift between the subflows when path outages occur. This results in 200 very fast transport-layer handovers that do not require support from 201 signaling. 203 2. Goals 205 This section outlines the basic goals that multipath RTP aims to 206 meet. These are broadly classified as Functional goals and 207 Compatibility goals. 209 2.1. Functional goals 211 Allow unicast RTP session to be split into multiple subflows in order 212 to be carried over multiple paths. This may prove beneficial in case 213 of video streaming. 215 o Increased Throughput: Cumulative capacity of the two paths may 216 meet the requirements of the multimedia session. Therefore, MPRTP 217 MUST support concurrent use of the multiple paths. 219 o Improved Reliability: MPRTP SHOULD be able to send redundant 220 packets or re-transmit packets along any available path to 221 increase reliability. 223 The protocol SHOULD be able to open new subflows for an existing 224 session when new paths appear and MUST be able to close subflows when 225 paths disappear. 227 2.2. Compatibility goals 229 MPRTP MUST be backwards compatible; an MPRTP stream needs to fall 230 back to be compatible with legacy RTP stacks if MPRTP support is not 231 successfully negotiated. 233 o Application Compatibility: MPRTP service model MUST be backwards 234 compatible with existing RTP applications, i.e., an MPRTP stack 235 MUST be able to work with legacy RTP applications and not require 236 changes to them. Therefore, the basic RTP APIs MUST remain 237 unchanged, but an MPRTP stack MAY provide extended APIs so that 238 the application can configure any additional features provided by 239 the MPRTP stack. 241 o Network Compatibility: individual RTP subflows MUST themselves be 242 well-formed RTP flows, so that they are able to traverse NATs and 243 firewalls. This MUST be the case even when interfaces appear 244 after session initiation. Interactive Connectivity Establishment 245 (ICE) [3] MAY be used for discovering new interfaces or performing 246 connectivity checks. 248 3. RTP Topologies 250 RFC 5117 [13] describes a number of scenarios using mixers and 251 translators in single-party (point-to-point), and multi-party (point- 252 to-multipoint) scenarios. RFC 3550 [1] (Section 2.3 and 7.x) discuss 253 in detail the impact of mixers and translators on RTP and RTCP 254 packets. MPRTP assumes that if a mixer or translator exists in the 255 network, then either all of the multiple paths or none of the 256 multiple paths go via this component. 258 4. MPRTP Architecture 260 In a typical scenario, an RTP session uses a single path. In an 261 MPRTP scenario, an RTP session uses multiple subflows that each use a 262 different path. Figure 1 shows the difference. 264 +--------------+ Signaling +--------------+ 265 | |------------------------------------>| | 266 | Client |<------------------------------------| Server | 267 | | Single RTP flow | | 268 +--------------+ +--------------+ 270 +--------------+ Signaling +--------------+ 271 | |------------------------------------>| | 272 | Client |<------------------------------------| Server | 273 | |<------------------------------------| | 274 +--------------+ MPRTP subflows +--------------+ 276 Figure 1: Comparison between traditional RTP streaming and MPRTP 278 +-----------------------+ +-------------------------------+ 279 | Application | | Application | 280 +-----------------------+ +-------------------------------+ 281 | | | MPRTP | 282 + RTP + +- - - - - - - -+- - - - - - - -+ 283 | | | RTP subflow | RTP subflow | 284 +-----------------------+ +---------------+---------------+ 285 | UDP | | UDP | UDP | 286 +-----------------------+ +---------------+---------------+ 287 | IP | | IP | IP | 288 +-----------------------+ +---------------+---------------+ 290 Figure 2: MPRTP Architecture 292 Figure 2 illustrates the differences between the standard RTP stack 293 and the MPRTP stack. MPRTP receives a normal RTP session from the 294 application and splits it into multiple RTP subflows. Each subflow 295 is then sent along a different path to the receiver. To the network, 296 each subflow appears as an independent, well-formed RTP flow. At the 297 receiver, the subflows are combined to recreate the original RTP 298 session. The MPRTP layer performs the following functions: 300 o Path Management: The layer is aware of alternate paths to the 301 other host, which may, for example, be the peer's multiple 302 interfaces. So that it is able to send differently marked packets 303 along separate paths. MPRTP also selects interfaces to send and 304 receive data. Furthermore, it manages the port and IP address 305 pair bindings for each subflow. 307 o Packet Scheduling: the layer splits a single RTP flow into 308 multiple subflows and sends them across multiple interfaces 309 (paths). The splitting MAY BE done using different path 310 characteristics. 312 o Subflow recombination: the layer creates the original stream by 313 recombining the independent subflows. Therefore, the multipath 314 subflows appear as a single RTP stream to applications. 316 4.1. Relationship of MPRTP with Session Signaling 318 Session signaling (e.g., SIP [14], RTSP [15]) SHOULD be done over a 319 failover-capable or multipath-capable transport for e.g., SCTP [10] 320 or MPTCP [11] instead of TCP or UDP. 322 5. Example Media Flow Diagrams 324 There may be many complex technical scenarios for MPRTP, however, 325 this memo only considers the following two scenarios: 1) a 326 unidirectional media flow that represents the streaming use-case, and 327 2) a bidirectional media flow that represents a conversational use- 328 case. 330 5.1. Streaming use-case 332 In the unidirectional scenario, the receiver (client) initiates a 333 multimedia session with the sender (server). The receiver or the 334 sender may have multiple interfaces and both endpoints are MPRTP- 335 capable. Figure 3 shows this scenario. In this case, host A has 336 multiple interfaces. Host B performs connectivity checks on host A's 337 multiple interfaces. If the interfaces are reachable, then host B 338 streams multimedia data along multiple paths to host A. Moreover, 339 host B also sends RTCP Sender Reports (SR) for each subflow and host 340 A responds with a standard RTCP Receiver Report (RR) for the overall 341 session and receiver statistics for each subflow. Host B distributes 342 the packets across the subflows based on the individually measured 343 path characteristics. 345 Alternatively, to reduce media startup time, host B may start 346 streaming multimedia data to host A's initiating interface and then 347 perform connectivity checks for the other interfaces. This method of 348 updating a single path session to a multipath session is called 349 "multipath session upgrade". 351 Host A Host B 352 ----------------------- ---------- 353 Address A1 Address A2 Address B1 354 ----------------------- ---------- 355 | Session Setup | 356 |------------------------------------->| connections at endpoint 357 |<-------------------------------------| may be "preloaded" 358 | | | (e.g., with ICE) 359 | | | 360 | (RTP data B1->A1, B1->A2) | 361 |<=====================================| 362 | |<========================| 363 | | | 364 Note: there may be more scenarios. 366 Figure 3: Unidirectional media flow 368 5.2. Conversational use-case 370 In the bidirectional scenario, multimedia data flows in both 371 directions. The two hosts exchange their lists of interfaces with 372 each other and perform connectivity checks. Communication begins 373 after each host finds suitable address, port pairs. Interfaces that 374 receive data send back RTCP receiver statistics for that path (based 375 on the 5-tuple). The hosts balance their multimedia stream across 376 multiple paths based on the per path reception statistics and its own 377 volume of traffic. Figure 4 describes an example of a bidirectional 378 flow. 380 Host A Host B 381 ----------------------- ----------------------- 382 Address A1 Address A2 Address B1 Address B2 383 ----------------------- ----------------------- 384 | | | | 385 | Session Setup | | connections at 386 |----------------------------------->| | the endpoint may 387 |<-----------------------------------| | be "preloaded" 388 | | | | (e.g., ICE) 389 | | | | 390 | (RTP data B1<->A1, B2<->A2) | | 391 |<===================================| | 392 | |<===================================| 393 |===================================>| | 394 | |===================================>| 395 | | | | 396 Note: the address pairs may have other permutations, 397 and they may be symmetric or asymmetric combinations. 399 Figure 4: Bidirectional flow 401 5.3. Challenges with Multipath Interface Discovery 403 For some applications, where the user expects immediate playback, 404 e.g., High Definition Media Streaming or IPTV, it may not be possible 405 to perform connectivity checks within the given time bound. In these 406 cases, connectivity checks MAY need to be done ahead of time. 408 [Open Issue: ICE or any other system would have to be aware of the 409 endpoint's interfaces ahead of time]. 411 6. MPRTP Functional Blocks 413 This section describes some of the functional blocks needed for 414 MPRTP. We then investigate each block and consider available 415 mechanisms in the next section. 417 1. Session Setup: Multipath session setup is an upgrade or add-on to 418 a typical RTP session. Interfaces may appear or disappear at 419 anytime during the session. To preserve backward compatibility 420 with legacy applications, a multipath session MUST look like a 421 bundle of individual RTP sessions. 423 2. Expanding RTP: For a multipath session, each subflow MUST look 424 like an independent RTP flow, so that individual RTCP messages 425 can be generated per subflow. Furthermore, MPRTP splits the 426 single multimedia stream into multiple subflows based on path 427 characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- 428 delay product etc.) and dynamically adjusts the load on each 429 link. 431 3. Adding Interfaces: Interfaces on the host need to be regularly 432 discovered and signaled. This can be done at session setup 433 and/or during the session. When discovering and receiving new 434 interfaces, the MPRTP layer needs to select address and port 435 pairs. 437 4. Expanding RTCP: MPRTP MUST recombine RTCP reports from each path 438 to re-create a single RTCP message to maintain backward 439 compatibility with legacy applications. 441 5. Maintenance and Failure Handling: In a multi-homed endpoint 442 interfaces may appear and disappear. If this happens at the 443 sender, it has to re-adjust the load on the available links. On 444 the other hand, if this occurs on the receiver, then the 445 multimedia data transmitted by the sender to those interfaces is 446 lost. This data may be re-transmitted along a different path 447 i.e., to a different interface on the receiver. Furthermore, the 448 receiver has to explicitly signal the disappearance of an 449 interface, or the sender has to detect it. [Open Issue: What 450 happens if the interface that setup the session disappears? does 451 the control channel also failover? re-start the session?] 453 6. Teardown: The MPRTP layer releases the occupied ports on the 454 interfaces. 456 7. Available Mechanisms within the Functional Blocks 458 This section discusses some of the possible alternatives for each 459 functional block mentioned in the previous section. 461 7.1. Session Setup 463 MPRTP session can be set up in many possible ways e.g., during 464 handshake, or upgraded mid-session. The capability exchange may be 465 done using out-of-band signaling (e.g., SDP [16] in SIP [14], RTSP 466 [15]) or in-band signaling (e.g., RTP/RTCP header extension). 467 Furthermore, ICE [3] may be used for discovering and performing 468 connectivity checks during session setup. 470 7.2. Expanding RTP 472 RTCP [1] is generated per media session. However, with MPRTP, the 473 media sender spreads the RTP load across several interfaces. The 474 media sender SHOULD make the path selection, load balancing and fault 475 tolerance decisions based on the characteristics of each path. 476 Therefore, apart from normal RTP sequence numbers defined in [1], the 477 MPRTP sender MUST add subflow-specific sequence numbers to help 478 calculate fractional losses, jitter, RTT, playout time, etc., for 479 each path and a subflow identifier to associate the characteristics 480 with a path. The RTP header extension for MPRTP is shown in 481 Section 9). 483 7.3. Adding New Interfaces 485 When interfaces appear and disappear mid-session, ICE [3] may be used 486 for discovering interfaces and performing connectivity checks. 487 However, MPRTP may require a capability re-negotiation (using SDP) to 488 include all these new interfaces. This method is referred to as out- 489 of-band multipath advertisement. 491 Alternatively, when new interfaces appear, the interface 492 advertisements may be done in-band using RTP/RTCP extensions. The 493 endpoints perform connectivity checks (see Figure 5 for more 494 details). If the connectivity packets are received by the peers, 495 then multimedia data can flow between the new address, port pairs. 497 7.4. Expanding RTCP 499 To provide accurate per path information an MPRTP endpoint MUST send 500 (SR/RR) report for each unique subflow along with the overall session 501 RTCP report. Therefore, the additional subflow reporting affects the 502 RTCP bandwidth and the RTCP reporting interval for each subflow. 503 RTCP report scheduling for each subflow may cause a problem for RTCP 504 recombination and reconstruction in cases when 1) RTCP for a subflow 505 is lost, and 2) RTCP for a subflow arrives later than the other 506 subflows. (There may be other cases as well.) 508 The sender distributes the media across different paths using the per 509 path RTCP reports. However, this document doesn't cover algorithms 510 for congestion control or load balancing. 512 7.5. Checking and Failure Handling 514 [Note: If the original interface that setup the session disappears 515 then does the session signaling failover to another interface? Can 516 we recommend that SIP/RTSP be run over MPTCP, SCTP]. 518 8. MPRTP Protocol 520 To enable a quick start of a multimedia session, a multipath session 521 MUST be upgraded from a single path session. Therefore, no explicit 522 changes are needed in multimedia session setup and the session can be 523 setup as before. 525 Host A Host B 526 ----------------------- ----------------------- 527 Address A1 Address A2 Address B1 Address B2 528 ----------------------- ----------------------- 529 | | | | 530 | | (1) | | 531 |--------------------------------------->| | 532 |<---------------------------------------| | 533 | | (2) | | 534 |<=======================================| | 535 |<=======================================| (3) | 536 | | (4) | | 537 |<=======================================| | 538 |<=======================================| | 539 |<=======================================| | 540 | | (5) | | 541 |- - - - - - - - - - - - - - - - - - - ->| | 542 |<=======================================| (6) | 543 |<=======================================| | 544 | |<========================================| 545 |<=======================================| | 546 | |<========================================| 548 Key: 549 | Interface 550 ---> Signaling Protocol 551 <=== RTP Packets 552 - -> RTCP Packet 554 Figure 5: MPRTP New Interface 556 8.1. Overview 558 The bullet points explain the different steps shown in Figure 5 for 559 upgrading a standard single path multimedia session to multipath 560 session. 562 (1) The first two interactions between the hosts represents the 563 standard session setup. This may be SIP or RTSP. 565 (2) Following the setup, like in a conventional RTP scenario, host 566 B using interface B1 starts to stream data to host A at interface 567 A1. 569 (3) Host B is an MPRTP-capable media sender and becomes aware of 570 another interface B2. 572 (4) Host B advertises the multiple interface addresses using an 573 RTCP header extensions. 575 (5) Host A is an MPRTP-capable media receiver and becomes aware of 576 another interface A2. It advertises the multiple interface 577 addresses using an RTCP extension. 579 Side note, even if an MPRTP-capable host has only one interface, 580 it SHOULD respond to the advertisement with its single interface. 582 (6) Each host receives information about the additional interfaces 583 and performs the connectivity tests (not shown in figure). If the 584 paths are reachable then the host starts to stream the multimedia 585 content using the additional paths. 587 8.1.1. Subflow or Interface advertisement 589 To advertise the multiple interfaces, an MPRTP-capable endpoint MUST 590 add the MPRTP Interface Advertisement defined in Figure 13 with the 591 RTCP Sender Report (SR). Each unique address is encapsulated in an 592 Interface Advertisement block and contains the IP address, RTP and 593 RTCP port addresses. The Interface Advertisement blocks are ordered 594 based on a decreasing priority level. On receiving the MPRTP 595 Interface Advertisement, an MPRTP-capable receiver MUST respond with 596 its own set of interfaces. 598 If the sender and receiver have only one interface, then the 599 endpoints MUST respond with the default IP, RTP port and RTCP port 600 addresses. If an endpoint receives an RTCP report without the MPRTP 601 Interface Advertisement, then the endpoint MUST assume that the other 602 endpoint is not MPRTP capable. 604 8.1.2. Path selection 606 After MPRTP support has been discovered and interface advertisements 607 have been exchanged, the sender MUST initiate connectivity checks to 608 determine which interface pairs offer valid paths between the sender 609 and the receiver. Each combination of IP addresses and port pairs 610 (5-tuple) is a unique subflow. An endpoint MUST associate a Subflow 611 ID to each unique subflow. 613 To initiate a connectivity check, the endpoints send an RTP packet 614 using the appropriate MPRTP extension header (See Figure 7), 615 associated Subflow ID and no RTP payload. The receiving endpoint 616 replies to each connectivity check with an RTCP packet with the 617 appropriate packet type (See Figure 10) and Subflow ID. After the 618 endpoint receives the reply, the path is considered a valid candidate 619 for sending data. An endpoint MAY choose to do any number of 620 connectivity checks for any interface pairs at any point in a 621 session. 623 [Open Issue: How should the endpoint adjust the RTCP Reporting 624 interval/schedule the RTCP packet on receiving a connectivity check 625 containing a new Subflow ID? Editor: One option is send immediately 626 as defined in [4]. Another option is the RTCP timing defined in 627 [17].] 629 8.1.3. Opening subflows 631 The sender MAY open any number of subflows from the set of candidate 632 subflows after performing connectivity checks. To use the subflow, 633 the sender simply starts sending the RTP packets with an MPRTP 634 extension shown in Figure 8. The MPRTP extension carries a mapping 635 of a subflow packet to the aggregate flow. Namely, sequence numbers 636 and timestamps associated with the subflow. 638 An endpoint MAY use all or a subset of candidate subflows for sending 639 media packets. To avoid redoing the connectivity checks the endpoint 640 MAY send keep-alive MPRTP packets (see Section 9.1.3) to the passive 641 subflows to keep the NAT bindings alive. 643 [Open Issue: How to differentiate between Passive and Active 644 connections? Editor: Active paths get "regular flow" of media 645 packets while passive paths are for failover of active paths. ] 647 [Open Issue: How to keep a passive connection alive, if not actively 648 used? Alternatively, what is the maximum timeout? Editor: keep- 649 alive for ICE/NAT bindings should not be less than 15 seconds [3].] 651 8.2. RTP Transmission 653 The MPRTP layer SHOULD associate an RTP packet with a subflow based 654 on a scheduling strategy. The scheduling strategy may either choose 655 to augment the paths to create higher throughput or use the alternate 656 paths for enhancing resilience or error-repair. Due to the changes 657 in path characteristics, an MPRTP sender can change its scheduling 658 strategy during an ongoing session. The MPRTP sender MUST also 659 populate the subflow specific fields described in the MPRTP extension 660 header (see Section 9.1.1). 662 8.3. Playout Considerations at the Receiver 664 A media receiver, irrespective of MPRTP support or not, should be 665 able to playback the media stream because the received RTP packets 666 are compliant to [1], i.e., a non-MPRTP receiver will ignore the 667 MPRTP header and still be able to playback the RTP packets. However, 668 the variation of jitter and loss per path may affect proper playout. 669 The receiver can compensate for the jitter by modifying the playout 670 delay (i.e., by calculating skew across all paths) of the received 671 RTP packets. 673 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation 675 Aggregate RTCP provides the overall media statistics and follows the 676 standard RTCP defined in RFC3550 [1]. However, subflow specific RTCP 677 provides the per path media statistics because the aggregate RTCP 678 report may not provide sufficient per path information to an MPRTP 679 scheduler. Specifically, the scheduler should be aware of each 680 path's RTT and loss-rate, which an aggregate RTCP cannot provide. 681 The sender/receiver MUST use non-compound RTCP reports defined in 682 RFC5506 [5] to transmit the aggregate and subflow-specific RTCP 683 reports. Also, each subflow and the aggregate RTCP report MUST 684 follow the timing rules defined in [4]. 686 The RTCP reporting interval is locally implemented and the scheduling 687 of the RTCP reports may depend on the the behavior of each path. For 688 instance, the RTCP interval may be different for a passive path than 689 an active path to keep port bindings alive. Additionally, an 690 endpoint may decide to share the RTCP reporting bit rate equally 691 across all its paths or schedule based on the receiver rate on each 692 path. 694 8.5. RTCP Transmission 696 The sender sends an RTCP SR on each active path. For each SR the 697 receiver gets, it echoes one back to the same IP address-port pair 698 that sent the SR. The receiver tries to choose the symmetric path 699 and if the routing is symmetric then the per-path RTT calculations 700 will work out correctly. However, even if the paths are not 701 symmetric, the sender would at maximum, under-estimate the RTT of the 702 path by a factor of half of the actual path RTT. 704 9. Packet Formats 706 In this section we define the protocol structures described in the 707 previous sections. 709 9.1. RTP Header Extension for MPRTP 711 The MPRTP header extension is used to 1) distribute a single RTP 712 stream over multiple subflows, 2) perform connectivity checks on the 713 advertised interfaces, and 3) keep-alive passive interfaces (paths). 715 The header conforms to the one-byte RTP header extension defined in 716 [6]. The header extension contains a 16-bit length field that counts 717 the number of 32-bit words in the extension, excluding the four-octet 718 extension header (therefore zero is a valid length, see Section 5.3.1 719 of [1] for details). 721 To signal the use of the above RTP header extensions in SDP, the 722 following URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp. 724 The RTP header for each subflow is defined below: 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 |V=2|P|1| CC |M| PT | sequence number | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | timestamp | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | synchronization source (SSRC) identifier | 734 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 735 | ID | LEN | MPID |LENGTH | MPRTP header data | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 737 | .... | 738 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 739 | RTP payload | 740 | .... | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 Figure 6: Generic MPRTP header extension 745 MPID: 747 The MPID field corresponds to the type of MPRTP packet. 748 Namely: 750 +---------------+--------------------------------------------------+ 751 | MPID ID | Use | 752 | Value | | 753 +---------------+--------------------------------------------------+ 754 | 0x00 | Subflow RTP Header. For this case the Length is | 755 | | set to 6 | 756 | 0x01 | Connectivity Check. For this case the length is | 757 | | set to 0 | 758 | TBD | Keep Alive Packet. | 759 +---------------+--------------------------------------------------+ 761 Figure 7: RTP header extension values for MPRTP (H-Ext ID) 763 length 765 The 4-bit length field is the length of extension data in bytes 766 not including the H-Ext ID and length fields. The value zero 767 indicates there is no data following. 769 MPRTP header data 771 Carries the MPID specific data as described in the following 772 sub-sections. 774 9.1.1. MPRTP RTP Extension for a Subflow 776 The RTP header for each subflow is defined below: 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 |V=2|P|1| CC |M| PT | sequence number | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | timestamp | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | synchronization source (SSRC) identifier | 786 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 787 | ID | LEN=4 | 0x00 | LEN=4 | Subflow ID | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Subflow-specific Seq Number | Pad (0) | Pad (0) | 790 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 791 | RTP payload | 792 | .... | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 Figure 8: MPRTP header for subflow 797 MP ID = 0x00 799 Indicates that the MPRTP header extension carries subflow 800 specific information. 802 length = 4 804 Subflow ID: Identifier of the subflow. Every RTP packet belonging 805 to the same subflow carries the same unique subflow identifier. 807 Flow-Specific Sequence Number (FSSN): Sequence of the packet in 808 the subflow. Each subflow has its own strictly monotonically 809 increasing sequence number space. 811 9.1.2. MPRTP RTP Extension for Connectivity Checks 813 [Open Issue: What sequence number to use for the RTP session? 814 Alternative 1: An MPRTP receiver MUST NOT give the packet with 815 MPID=0x01 to the decoder and ignore these packets from RTCP 816 calculation. Alternative 2: Instead of sending an RTP packet the 817 sender transmits a modified STUN packet.] 819 9.1.3. MPRTP RTP Extension for Keep-alive Packets 821 [Editor: RTCP guidelines for keep alive packet [17] recommends 822 multiplexing RTP and RTCP. If so, we can do the same and remove the 823 keep alive from the list. 825 9.2. RTCP Extension for MPRTP (MPRTCP) 827 The MPRTP RTCP header extension is used to 1) provide RTCP feedback 828 per subflow to determine the characteristics of each path, 2) 829 advertise each interface and perform connectivity check on the other 830 endpoint's interfaces, and 3) to keep alive a passive connection. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 |V=2|P|reserved | PT=MPRTCP=210 | length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | SSRC of packet sender | 838 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 839 | SSRC_1 (SSRC of first source) | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | MPRTCP_Type | block length | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | MPRTCP Reports | 844 | ... | 845 | ... | 846 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 848 Figure 9: Generic RTCP Extension for MPRTP (MPRTCP) [appended to 849 standard SR/RR] 851 MPRTCP: 8 bits 853 Contains the constant 210 to identify this as an Multipath RTCP 854 packet. 856 length: 16 bits 857 As described for the RTCP packet (see Section 6.4.1 of the RTP 858 specification [1]), the length of this is in 32-bit words minus 859 one, including the header and any padding. 861 MPRTCP_Type: 16-bits 863 The MPRTCP_Type field corresponds to the type of MPRTP RTCP 864 packet. Namely: 866 +---------------+--------------------------------------------------+ 867 | MPRTCP_Type | Use | 868 | Value | | 869 +---------------+--------------------------------------------------+ 870 | 0x00 | Subflow Specific Report | 871 | 0x01 | Connectivity Check. For this case the length is | 872 | | set to 0 | 873 | 0x02 | Interface Advertisement | 874 | TBD | Keep Alive Packet. | 875 +---------------+--------------------------------------------------+ 877 Figure 10: RTP header extension values for MPRTP (MPRTCP_Type) 879 block length: 16-bits 881 The 16-bit length field is the length of the encapsulated 882 MPRTCP reports in 32-bit word length not including the 883 MPRTCP_Type and length fields. The value zero indicates there 884 is no data following. 886 MPRTCP Reports: variable size 888 Defined later in 9.2.1 and 9.3.1. 890 9.2.1. MPRTCP Extension for Subflow Reporting 892 When sending a report for a specific subflow the sender or receiver 893 MUST add only the reports associated with that 5-tuple. Each subflow 894 is reported independently using the following MPRTCP Feedback header. 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |V=2|P|reserved | PT=MPRTCP=210 | length | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | SSRC of packet sender | 902 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 903 | SSRC_1 (SSRC of first source) | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | MPRTCP_Type=0x02 | block length | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Subflow ID #1 | reserved | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Subflow-specific reports | 910 | .... | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | MPRTCP_Type=0x02 | block length | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Subflow ID #2 | reserved | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Subflow-specific reports | 917 | .... | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 Figure 11: MPRTCP Subflow Reporting Header 922 MPRTCP_Type: 0x02 924 block length: 16-bits 926 The 16-bit length field is the length of the encapsulated subflow- 927 specific reports in 32-bit word length not including the 928 MPRTCP_Type and length fields. 930 Subflow ID: 16 bits 932 Subflow identifier is the value associated with the subflow the 933 endpoint is reporting about. If it is a sender it MUST use the 934 Subflow ID associated with the 5-tuple. If it is a receiver it 935 MUST use the Subflow ID received in the Subflow-specific Sender 936 Report. 938 Subflow-specific reports: variable 940 Subflow-specific report contains all the reports associated with 941 the Subflow ID. For a sender, it MUST include the Subflow- 942 specific Sender Report (SSR). For a receiver, it MUST include 943 Subflow-specific Receiver Report (SRR). Additionally, if the 944 receiver supports subflow-specific extension reports then it MUST 945 append them to the SRR. 947 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR 949 [Editor: inside the context of subflow specific reports can we reuse 950 the payload type code for Sender Report (PT=200), Receiver Report 951 (PT=201), Extension Report (PT=207). Transport and Payload specific 952 RTCP messages are session specific and SHOULD be used as before.] 954 Example: 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 |V=2|P|reserved | PT=MPRTCP=210 | length | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | SSRC of packet sender | 962 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 963 | SSRC_1 (SSRC of first source) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | MPRTCP_Type=0x02 | block length | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Subflow ID #1 | reserved | 968 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 969 |V=2|P| RC | PT=SR=200 | length | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | SSRC of sender | 972 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 973 | NTP timestamp, most significant word | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | NTP timestamp, least significant word | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | RTP timestamp | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | subflow's packet count | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | subflow's octet count | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | MPRTCP_Type=0x02 | block length | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Subflow ID #2 | reserved | 986 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 987 |V=2|P| RC | PT=RR=201 | length | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | SSRC of packet sender | 990 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 991 | fraction lost | cumulative number of packets lost | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | extended highest sequence number received | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | inter-arrival jitter | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | last SR (LSR) | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | delay since last SR (DLSR) | 1000 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1001 | Subflow specific extension reports | 1002 | .... | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header 1005 (Bi-directional use-case, in case of uni-directional flow the subflow 1006 will only send an SR or RR). 1008 9.3. MPRTCP Extension for Interface advertisement 1010 This sub-section defines the RTCP header extension for in-band 1011 interface advertisement by the receiver, instead of relying on ICE or 1012 in situations when the interface appears after SDP session 1013 establishment. 1015 The interface advertisement SHOULD immediately follow the Receiver 1016 Report. If the Receiver Report is not present, then it MUST be 1017 appended to the Sender Report. 1019 The endpoint MUST advertise all its interfaces when a new interface 1020 appears. Furthermore, an endpoint MUST advertise all its interfaces 1021 when it receives an Interface Advertisement. 1023 0 1 2 3 1024 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 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 |V=2|P|reserved | PT=MPRTCP=210 | length | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | SSRC of packet sender | 1029 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1030 | SSRC_1 (SSRC of first source) | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | MPRTCP_Type=0x02 | block length | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Interface #1 Advertisement block | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Interface #2 Advertisement block | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Interface #... Advertisement block | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Interface #m Advertisement block | 1041 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1043 Figure 13: MPRTP Interface Advertisement. (appended to SR/RR) 1045 MPRTCP_Type: 0x00 1047 block length: 16-bits 1049 The 16-bit length field is the length of the encapsulated 1050 interface advertisement blocks in 32-bit word length not 1051 including the MPRTCP_Type and length fields. 1053 Interface Advertisement block: variable size 1055 Defined later in 9.3.1. 1057 9.3.1. Interface Advertisement block 1059 This block describes a method to represent IPv4, IPv6 and generic 1060 DNS-type addresses in a block format. It is based on the sub- 1061 reporting block in [7]. 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Type={0,1,2} | Length | Subflow ID | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | RTCP Port | RTCP Port | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Address | 1071 + + 1072 : : 1073 | | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Figure 14: Interface Advertisement block during path discovery 1078 Type: 8 bits 1080 The Type corresponds to the type of address. Namely: 1082 0: IPv4 address 1084 1: IPv6 address 1086 2: DNS name 1088 Length: 8 bits 1090 The length of the Interface Advertisement block in bytes. 1092 For an IPv4 address, this should be 9 (i.e., 5 octets for 1093 the header and 4 octets for IPv4 address). 1095 For an IPv6 address, this should be 21. 1097 For a DNS name, the length field indicates the number of 1098 octets making up the string plus the 5 byte header. 1100 RTP Port: 2 octets 1102 The port number to which the sender sends RTP data. A port 1103 number of 0 is invalid and MUST NOT be used. 1105 RTCP Port: 2 octets 1107 The port number to which receivers send feedback reports. A 1108 port number of 0 is invalid and MUST NOT be used. 1110 Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) 1112 The address to which receivers send feedback reports. For IPv4 1113 and IPv6, fixed-length address fields are used. A DNS name is 1114 an arbitrary-length string. The string MAY contain 1115 Internationalizing Domain Names in Applications (IDNA) domain 1116 names and MUST be UTF-8 [8] encoded. 1118 10. RTCP Timing reconsiderations for MPRTCP 1120 MPRTP endpoints MUST conform to the timing rule imposed in [4], i.e., 1121 the total RTCP rate between the participants MUST NOT exceed 5% of 1122 the media rate. For each endpoint, a subflow MUST send the aggregate 1123 and subflow-specific report. The endpoint SHOULD schedule the RTCP 1124 reports for the active subflows based on the share of the transmitted 1125 or received bit rate to the average media bit rate, this method 1126 ensures fair sharing of the RTCP bandwidth. Alternatively, the 1127 endpoint MAY schedule the reports in round-robin. 1129 11. SDP Considerations 1131 The packet formats specified in this document define extensions for 1132 RTP and RTCP. The use of MPRTP is left to the discretion of the 1133 sender and receiver. 1135 11.1. Signaling MPRTP capability in SDP 1137 A participant of a media session MAY use SDP to signal that it 1138 supports MPRTP. Not providing this information may/will make the 1139 sender or receiver ignore the header extensions. However, MPRTP MAY 1140 be used by either sender or receiver without prior signaling. 1142 mprtp-attrib = "a=" "mprtp" [ 1143 SP mprtp-optional-parameter] 1144 CRLF ; flag to enable MPRTP 1146 The literal 'mprtp' MUST be used to indicate support for MPRTP. 1147 Generally, senders and receivers MUST indicate this capability if 1148 they support MPRTP and would like to use it in the specific media 1149 session being signaled. They can then use the in-band signaling to 1150 exchange the additional interfaces and to perform connectivity 1151 checks. 1153 11.2. Signaling MPRTP Header Extension in SDP 1155 To signal the use of MPRTP header extensions in SDP, the following 1156 URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp. Legacy RTP (non- 1157 MPRTP) clients MUST ignore this header extension, but continue to 1158 parse and decode the packet. 1160 11.3. MPRTP using preloaded interfaces from ICE (out-band signaling) 1162 If the endpoints intend to use ICE [3] for discovering new interfaces 1163 and running connectivity checks then these endpoints MUST NOT use in- 1164 band interface advertisement and the associated connectivity checks, 1165 as described in Section 9.1.2 (MPID=0x01) and Section 9.3 1166 (MPRTCP_Type=0x01, 0x02). 1168 Using ICE for MPRTP is a two step process: 1170 1. Advertising ICE candidates: in the initial INVITE the endpoints 1171 exchange candidates, as defined in ICE [3]. Thereafter the 1172 endpoints run connectivity checks 1174 2. Advertising MPRTP interfaces: When a sufficient number of 1175 connectivity checks succeed the endpoint MUST send an updated 1176 offer containing their interfaces. 1178 This process enables the participants to use MPRTP capabilities from 1179 the start of a media session. 1181 11.3.1. "interface" attribute 1183 The interface attribute is only a media-level attribute. It is used 1184 to describe one of the many network addresses of an endpoint. 1186 The syntax of the interface attribute is defined using the following 1187 Augmented BNF, as defined in [9]. It reuses the RFC4566 [18] 1188 definitions of unicast-address, port, token, SP, and CRLF. 1190 mprtp-optional-parameter = mprtp-interface 1191 ; other optional parameters may be added later 1193 mprtp-interface = "interface" ":" counter SP unicast-address 1194 ":" rtp_port "/" rtcp_port 1195 *(SP interface-description-extension) 1197 counter = 1*DIGIT 1198 rtp_port = port ;port from RFC4566 1199 rtcp_port = port ;port from RFC4566 1201 : specifies one of the unicast IP address, the RTP 1202 and RTCP port numbers of the endpoint. The unicast address in the 1203 first interface line MUST match the connection address ('c=' line). 1204 The RTP and RTCP ports in the first interface line MUST match with 1205 the RTP and RTCP ports in the associated 'm=' line. The counter 1206 should start at 1 and increment with each additional interface. 1207 Multiple interface lines MUST be ordered in a decreasing priority 1208 level as is the case with the Interface Advertisement blocks in in- 1209 band signaling (See Figure 13). 1211 : is taken from RFC5245 [3]. It is one of the IP 1212 addresses of the endpoint allows the use of IPv4 addresses, IPv6 1213 addresses and Fully Qualified Domain Names (FQDN). An endpoint MUST 1214 only include the IP address for which the connectivity checks have 1215 succeeded. 1217 : is from RFC4566 [18]. It is the RTP or RTCP port associated 1218 the unicast address for which the connectivity checks have succeeded. 1220 : is a monotonically increasing positive integer starting at 1221 1. The counter SHOULD reset for each media line. 1223 The 'mprtp-interface' can be extended using the 'interface- 1224 description-extension' parameter. An endpoint MUST ignore any 1225 extensions it does not understand. 1227 11.3.2. Example 1229 The ABNF grammar is illustrated by means of an example: 1231 v=0 1232 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1233 s= 1234 c=IN IP4 192.0.2.1 1235 t=0 0 1236 m=video 49170 RTP/AVP 98 1237 a=rtpmap:98 H264/90000 1238 a=fmtp:98 profile-level-id=42A01E; 1239 a=mprtp interface:1 192.0.2.1:49170/49171 ;primary interface 1240 a=mprtp interface:2 192.1.2.1:51372/51373 ;additional interface 1242 11.4. Increased Throughput 1244 The MPRTP layer MAY choose to augment paths to increase throughput. 1245 If the desired media rate exceeds the current media rate, the 1246 endpoints MUST renegotiate the application specific ("b=AS:") [18] 1247 bandwidth. 1249 11.5. Offer/Answer Examples 1251 This section shows examples of SDP offer and answer for in-band and 1252 out-band signaling. 1254 11.5.1. In-band signaling 1256 The following offer/answer shows that both the endpoints are MPRTP 1257 capable and SHOULD use in-band signaling for exchanging interfaces 1258 and for performing connectivity checks. If candidate addresses are 1259 included in the initial INVITE then the connectivity checks are 1260 performed by ICE and the out-band signaling is preferred. 1262 Offer: 1263 v=0 1264 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1265 s= 1266 c=IN IP4 192.0.2.1 1267 t=0 0 1268 m=video 49170 RTP/AVP 98 1269 a=rtpmap:98 H264/90000 1270 a=fmtp:98 profile-level-id=42A01E; 1271 a=mprtp 1273 Answer: 1274 v=0 1275 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1276 s= 1277 c=IN IP4 192.0.2.2 1278 t=0 0 1279 m=video 4000 RTP/AVP 98 1280 a=rtpmap:98 H264/90000 1281 a=fmtp:98 profile-level-id=42A01E; 1282 a=mprtp 1284 11.5.2. Out-band signaling 1286 In this example, the offerer advertises two interfaces and the 1287 answerer responds with a single interface description. The endpoint 1288 MAY use one or both paths depending on the end-to-end characteristics 1289 of each path. 1291 Offer: 1292 v=0 1293 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1294 s= 1295 c=IN IP4 192.0.2.1 1296 t=0 0 1297 m=video 49170 RTP/AVP 98 1298 a=rtpmap:98 H264/90000 1299 a=fmtp:98 profile-level-id=42A01E; 1300 a=mprtp interface:1 192.0.2.1:49170/49171 1301 a=mprtp interface:2 192.1.2.1:51372/51373 1303 Answer: 1304 v=0 1305 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1306 s= 1307 c=IN IP4 192.0.2.2 1308 t=0 0 1309 m=video 4000 RTP/AVP 98 1310 a=rtpmap:98 H264/90000 1311 a=fmtp:98 profile-level-id=42A01E; 1312 a=mprtp interface:1 192.0.2.2:4000/4001 1314 12. IANA Considerations 1316 TBD 1318 13. Security Considerations 1320 TBD 1322 All drafts are required to have a security considerations section. 1323 See RFC 3552 [19] for a guide. 1325 14. Acknowledgements 1327 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 1328 Trilogy (http://www.trilogy-project.org), a research project (ICT- 1329 216372) partially funded by the European Community under its Seventh 1330 Framework Program. The views expressed here are those of the 1331 author(s) only. The European Commission is not liable for any use 1332 that may be made of the information in this document. 1334 The authors would also like acknowledge the contribution of Ralf 1335 Globish and Thomas Schierl for providing the input and text for the 1336 MPRTP interface advertisement in SDP. 1338 15. References 1340 15.1. Normative References 1342 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1343 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1344 RFC 3550, July 2003. 1346 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1347 Levels", BCP 14, RFC 2119, March 1997. 1349 [3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1350 Protocol for Network Address Translator (NAT) Traversal for 1351 Offer/Answer Protocols", RFC 5245, April 2010. 1353 [4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1354 "Extended RTP Profile for Real-time Transport Control Protocol 1355 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 1357 [5] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1358 Real-Time Transport Control Protocol (RTCP): Opportunities and 1359 Consequences", RFC 5506, April 2009. 1361 [6] Singer, D. and H. Desineni, "A General Mechanism for RTP Header 1362 Extensions", RFC 5285, July 2008. 1364 [7] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1365 Protocol (RTCP) Extensions for Single-Source Multicast Sessions 1366 with Unicast Feedback", RFC 5760, February 2010. 1368 [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1369 STD 63, RFC 3629, November 2003. 1371 [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1372 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1374 15.2. Informative References 1376 [10] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 1377 September 2007. 1379 [11] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, 1380 "Architectural Guidelines for Multipath TCP Development", 1381 RFC 6182, March 2011. 1383 [12] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim 1384 Protocol for IPv6", RFC 5533, June 2009. 1386 [13] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1387 January 2008. 1389 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1390 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1391 Session Initiation Protocol", RFC 3261, June 2002. 1393 [15] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. 1394 Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", 1395 draft-ietf-mmusic-rfc2326bis-27 (work in progress), March 2011. 1397 [16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1398 Session Description Protocol (SDP)", RFC 3264, June 2002. 1400 [17] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping 1401 Alive the NAT Mappings Associated with RTP / RTP Control 1402 Protocol (RTCP) Flows", RFC 6263, June 2011. 1404 [18] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1405 Description Protocol", RFC 4566, July 2006. 1407 [19] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1408 Security Considerations", BCP 72, RFC 3552, July 2003. 1410 Authors' Addresses 1412 Varun Singh 1413 Aalto University 1414 School of Science and Technology 1415 Otakaari 5 A 1416 Espoo, FIN 02150 1417 Finland 1419 Email: varun@comnet.tkk.fi 1420 URI: http://www.netlab.tkk.fi/~varun/ 1422 Teemu Karkkainen 1423 Aalto University 1424 School of Science and Technology 1425 Otakaari 5 A 1426 Espoo, FIN 02150 1427 Finland 1429 Email: teemuk@comnet.tkk.fi 1431 Joerg Ott 1432 Aalto University 1433 School of Science and Technology 1434 Otakaari 5 A 1435 Espoo, FIN 02150 1436 Finland 1438 Email: jo@comnet.tkk.fi 1440 Saba Ahsan 1441 Aalto University 1442 School of Science and Technology 1443 Otakaari 5 A 1444 Espoo, FIN 02150 1445 Finland 1447 Email: sahsan@cc.hut.fi 1448 Lars Eggert 1449 Nokia Research Center 1450 P.O. Box 407 1451 Nokia Group 00045 1452 Finland 1454 Phone: +358 50 48 24461 1455 Email: lars.eggert@nokia.com 1456 URI: http://research.nokia.com/people/lars_eggert