idnits 2.17.1 draft-ietf-mmusic-duplication-grouping-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5888]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 20, 2013) is 4048 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 293, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-06) exists of draft-ietf-avtext-rtp-duplication-01 == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-delayed-duplication-00 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Cisco 4 Intended status: Standards Track Y. Cai 5 Expires: September 21, 2013 Microsoft 6 H. Ou 7 Cisco 8 March 20, 2013 10 Duplication Grouping Semantics in the Session Description Protocol 11 draft-ietf-mmusic-duplication-grouping-01 13 Abstract 15 Packet loss is undesirable for real-time multimedia sessions, but can 16 occur due to congestion, or other unplanned network outages. This is 17 especially true for IP multicast networks, where packet loss patterns 18 can vary greatly between receivers. One technique that can be used 19 to recover from packet loss without incurring unbounded delay for all 20 the receivers is to duplicate the packets and send them in separate 21 redundant streams. This document defines the semantics for grouping 22 redundant streams in the Session Description Protocol (SDP). The 23 semantics defined in this document are to be used with the SDP 24 Grouping Framework [RFC5888]. SSRC-level (Synchronization Source) 25 grouping semantics are also defined in this document for RTP streams 26 using SSRC multiplexing. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 21, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 64 3. Duplication Grouping . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. "DUP" Grouping Semantics . . . . . . . . . . . . . . . . . 3 66 3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams . . . 4 67 3.3. SDP Offer/Answer Model Considerations . . . . . . . . . . . 4 68 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Separate Source Addresses . . . . . . . . . . . . . . . . . 5 70 4.2. Separate Destination Addresses . . . . . . . . . . . . . . 5 71 4.3. Temporal Redundancy . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 The Real-time Transport Protocol (RTP) [RFC3550] is widely used today 83 for delivering IPTV traffic, and other real-time multimedia sessions. 84 Many of these applications support very large numbers of receivers, 85 and rely on intra-domain UDP/IP multicast for efficient distribution 86 of traffic within the network. 88 While this combination has proved successful, there does exist a 89 weakness. As [RFC2354] noted, packet loss is not avoidable, even in 90 a carefully managed network. This loss might be due to congestion, 91 it might also be a result of an unplanned outage caused by a flapping 92 link, link or interface failure, a software bug, or a maintenance 93 person accidentally cutting the wrong fiber. Since UDP/IP flows do 94 not provide any means for detecting loss and retransmitting packets, 95 it leaves up to the RTP layer and the applications to detect, and 96 recover from, packet loss. 98 One technique to recover from packet loss without incurring unbounded 99 delay for all the receivers is to duplicate the packets and send them 100 in separate redundant streams. Variations on this idea have been 101 implemented and deployed today [IC2011]. 102 [I-D.ietf-avtext-rtp-duplication] explains how duplication can be 103 achieved for RTP streams without breaking the RTP and RTP Control 104 Protocol (RTCP) functionality. In this document, we describe the 105 semantics needed in the Session Description Protocol (SDP) [RFC4566] 106 to support this technique. 108 2. Requirements Notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 [RFC2119]. 115 3. Duplication Grouping 117 3.1. "DUP" Grouping Semantics 119 Each "a=group" line is used to indicate an association relationship 120 between the redundant streams. The streams included in one "a=group" 121 line are called a Duplication Group. 123 Using the framework in [RFC5888], this document defines "DUP" as the 124 grouping semantics for redundant streams. 126 The "a=group:DUP" semantics MUST be used to group the redundant 127 streams except when the streams are specified in the same media 128 description, i.e., in the same "m" line (See Section 3.2). In an 129 "a=group:DUP" line, the order of the listed redundant streams does 130 not strictly indicate the order of transmission, although it is 131 RECOMMENDED that the stream listed first is sent first, with the 132 other stream(s) being the (time-delayed) duplicate(s). 134 3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams 136 [RFC5576] defines an SDP media-level attribute, called 'ssrc-group', 137 for grouping the RTP streams that are SSRC multiplexed and carried in 138 the same RTP session. The grouping is based on the SSRC identifiers. 139 Since SSRC-multiplexed RTP streams are defined in the same "m" line, 140 the 'group' attribute cannot be used. 142 This section explains how duplication is used with SSRC-multiplexed 143 streams using the 'ssrc-group' attribute [RFC5576]. 145 The semantics of "DUP" for the 'ssrc-group' attribute are the same as 146 the one defined for the 'group' attribute except that the SSRC 147 identifiers are used to designate the duplication grouping 148 associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576]. As above, 149 while in an "a=ssrc-group:DUP" line, the order of the listed 150 redundant streams does not necessarily indicate the order of 151 transmission, it is RECOMMENDED that the stream listed first is sent 152 first, with the other stream(s) being the (time-delayed) 153 duplicate(s). 155 3.3. SDP Offer/Answer Model Considerations 157 When offering duplication grouping using SDP in an Offer/Answer model 158 [RFC3264], the following considerations apply. 160 A node that is receiving an offer from a sender may or may not 161 understand line grouping. It is also possible that the node 162 understands line grouping but it does not understand the "DUP" 163 semantics. From the viewpoint of the sender of the offer, these 164 cases are indistinguishable. 166 When a node is offered a session with the "DUP" grouping semantics 167 but it does not support line grouping or the duplication grouping 168 semantics, as per [RFC5888], the node responds to the offer either 169 (1) with an answer that ignores the grouping attribute or (2) with a 170 refusal to the request (e.g., 488 Not Acceptable Here or 606 Not 171 Acceptable in SIP). 173 In the first case, the original sender of the offer must send a new 174 offer without any duplication grouping. In the second case, if the 175 sender of the offer still wishes to establish the session, it should 176 retry the request with an offer without the duplication grouping. 177 This behavior is specified in [RFC5888]. 179 4. SDP Examples 181 4.1. Separate Source Addresses 183 In this example, the redundant streams use the same IP destination 184 address (232.252.0.1) but they are sourced from different addresses 185 (198.51.100.1 and 198.51.100.2). Thus, the receiving host needs to 186 join both SSM sessions separately. 188 v=0 189 o=ali 1122334455 1122334466 IN IP4 dup.example.com 190 s=DUP Grouping Semantics 191 t=0 0 192 m=video 30000 RTP/AVP 100 193 c=IN IP4 232.252.0.1/127 194 a=source-filter:incl IN IP4 232.252.0.1 198.51.100.1 198.51.100.2 195 a=rtpmap:100 MP2T/90000 196 a=ssrc:1000 cname:ch1@example.com 197 a=ssrc:1010 cname:ch1@example.com 198 a=ssrc-group:DUP 1000 1010 199 a=mid:Ch1 201 Note that in actual use, SSRC values, which are random 32-bit 202 numbers, can be much larger than the ones shown in this example. 203 Also note that this SDP description does not use the 'duplication- 204 delay' attribute (defined in [I-D.ietf-mmusic-delayed-duplication]) 205 since the sender does not apply any delay between the redundant 206 streams upon transmission. Alternatively, one could be more explicit 207 and insert an "a=duplication-delay:0" line before the "a=mid:Ch1" 208 line. 210 4.2. Separate Destination Addresses 212 In this example, the redundant streams have different IP destination 213 addresses. The example shows the same UDP port number and IP source 214 address for each stream, but either or both could have been different 215 for the two streams. 217 v=0 218 o=ali 1122334455 1122334466 IN IP4 dup.example.com 219 s=DUP Grouping Semantics 220 t=0 0 221 a=group:DUP S1a S1b 222 m=video 30000 RTP/AVP 100 223 c=IN IP4 233.252.0.1/127 224 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 225 a=rtpmap:100 MP2T/90000 226 a=mid:S1a 227 m=video 30000 RTP/AVP 101 228 c=IN IP4 233.252.0.2/127 229 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 230 a=rtpmap:101 MP2T/90000 231 a=mid:S1b 233 Optionally, one could be more explicit and insert an "a=duplication- 234 delay:0" line before the first "m" line. 236 4.3. Temporal Redundancy 238 In this example, the redundant streams have the same IP source and 239 destination addresses (i.e., they are transmitted in the same SSM 240 session). Due to the same source and destination addresses, the 241 packets in both streams will be routed over the same path. To 242 provide resiliency against packet loss, the duplicate of an original 243 packet is transmitted 50 ms later as indicated by the 'duplication- 244 delay' attribute (defined in [I-D.ietf-mmusic-delayed-duplication]). 246 v=0 247 o=ali 1122334455 1122334466 IN IP4 dup.example.com 248 s=Delayed Duplication 249 t=0 0 250 m=video 30000 RTP/AVP 100 251 c=IN IP4 233.252.0.1/127 252 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 253 a=rtpmap:100 MP2T/90000 254 a=ssrc:1000 cname:ch1a@example.com 255 a=ssrc:1010 cname:ch1a@example.com 256 a=ssrc-group:DUP 1000 1010 257 a=duplication-delay:50 258 a=mid:Ch1 260 5. Security Considerations 262 There is a weak threat for the receiver that the duplication grouping 263 can be modified to indicate relationships that do not exist. Such 264 attacks might result in failure of the duplication mechanisms, and/or 265 mishandling of the media streams by the receivers. 267 In order to avoid attacks of this sort, the SDP description needs to 268 be integrity protected and provided with source authentication. This 269 can, for example, be achieved on an end-to-end basis using S/MIME 270 [RFC5652] [RFC5751] when the SDP is used in a signaling packet using 271 MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the 272 authentication method in the Session Announcement Protocol (SAP) 273 [RFC2974] could be used as well. 275 6. IANA Considerations 277 This document registers the following semantics with IANA in 278 Semantics for the 'group' SDP Attribute under SDP Parameters: 280 Note to the RFC Editor: In the following registrations, please 281 replace "XXXX" with the number of this document prior to publication 282 as an RFC. 284 Semantics Token Reference 285 ------------------------------------- ------ --------- 286 Duplication DUP [RFCXXXX] 288 This document also registers the following semantics with IANA in 289 Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters: 291 Token Semantics Reference 292 ------- ----------------------------- --------- 293 DUP Duplication [RFCXXXX] 295 7. Acknowledgments 297 The authors would like to thank Colin Perkins, Bill Ver Steeg, Dave 298 Oran and Toerless Eckert for their inputs and suggestions. 300 8. References 301 8.1. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 307 with Session Description Protocol (SDP)", RFC 3264, 308 June 2002. 310 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 311 Jacobson, "RTP: A Transport Protocol for Real-Time 312 Applications", STD 64, RFC 3550, July 2003. 314 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 315 Description Protocol", RFC 4566, July 2006. 317 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 318 Media Attributes in the Session Description Protocol 319 (SDP)", RFC 5576, June 2009. 321 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 322 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 324 8.2. Informative References 326 [I-D.ietf-avtext-rtp-duplication] 327 Begen, A. and C. Perkins, "Duplicating RTP Streams", 328 draft-ietf-avtext-rtp-duplication-01 (work in progress), 329 December 2012. 331 [I-D.ietf-mmusic-delayed-duplication] 332 Begen, A., Cai, Y., and H. Ou, "Delayed Duplication 333 Attribute in the Session Description Protocol", 334 draft-ietf-mmusic-delayed-duplication-00 (work in 335 progress), October 2012. 337 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 338 "Toward Lossless Video Transport (to appear in IEEE 339 Internet Computing)", November 2011. 341 [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of 342 Streaming Media", RFC 2354, June 1998. 344 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 346 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 347 Announcement Protocol", RFC 2974, October 2000. 349 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 350 RFC 5652, September 2009. 352 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 353 Mail Extensions (S/MIME) Version 3.2 Message 354 Specification", RFC 5751, January 2010. 356 Authors' Addresses 358 Ali Begen 359 Cisco 360 181 Bay Street 361 Toronto, ON M5J 2T3 362 Canada 364 Email: abegen@cisco.com 366 Yiqun Cai 367 Microsoft 368 1065 La Avenida 369 Mountain View, CA 94043 370 USA 372 Email: yiqunc@microsoft.com 374 Heidi Ou 375 Cisco 376 170 W. Tasman Dr. 377 San Jose, CA 95134 378 USA 380 Email: hou@cisco.com