idnits 2.17.1 draft-ietf-mmusic-duplication-grouping-04.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 (November 21, 2013) is 3808 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 298, 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-04 == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-delayed-duplication-02 -- 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: 1 error (**), 0 flaws (~~), 4 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: May 25, 2014 Microsoft 6 H. Ou 7 Cisco 8 November 21, 2013 10 Duplication Grouping Semantics in the Session Description Protocol 11 draft-ietf-mmusic-duplication-grouping-04 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. SSRC-level (Synchronization Source) grouping 25 semantics are also defined in this document for RTP streams using 26 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 May 25, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . 3 67 3.3. SDP Offer/Answer Model Considerations . . . . . . . . . . 4 68 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. Separate Source Addresses . . . . . . . . . . . . . . . . 4 70 4.2. Separate Destination Addresses . . . . . . . . . . . . . 5 71 4.3. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 8.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 SDP Grouping Framework in [RFC5888], this document defines 124 "DUP" as the 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 omits 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 source-specific multicast (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 233.252.0.1/127 194 a=source-filter:incl IN IP4 233.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 MAY explicitly insert 207 an "a=duplication-delay:0" line before the "a=mid:Ch1" line for 208 informational purposes. 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 In general, the security considerations of [RFC4566] apply to this 263 document as well. 265 There is a weak threat for the receiver that the duplication grouping 266 can be modified to indicate relationships that do not exist. Such 267 attacks might result in failure of the duplication mechanisms, and/or 268 mishandling of the media streams by the receivers. 270 In order to avoid attacks of this sort, the SDP description needs to 271 be integrity protected and provided with source authentication. This 272 can, for example, be achieved on an end-to-end basis using S/MIME 273 [RFC5652] [RFC5751] when the SDP is used in a signaling packet using 274 MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the 275 authentication method in the Session Announcement Protocol (SAP) 276 [RFC2974] could be used as well. As for the confidentiality, if it 277 is desired, it can be useful to use a secure, encrypted transport 278 method to carry the SDP description. 280 6. IANA Considerations 282 This document registers the following semantics with IANA in 283 Semantics for the 'group' SDP Attribute under SDP Parameters: 285 Note to the RFC Editor: In the following registrations, please 286 replace "XXXX" with the number of this document prior to publication 287 as an RFC. 289 Semantics Token Reference 290 ------------------------------------- ------ --------- 291 Duplication DUP [RFCXXXX] 293 This document also registers the following semantics with IANA in 294 Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters: 296 Token Semantics Reference 297 ------- ----------------------------- --------- 298 DUP Duplication [RFCXXXX] 300 7. Acknowledgments 302 The authors would like to thank Colin Perkins, Bill Ver Steeg, Dave 303 Oran and Toerless Eckert for their inputs and suggestions. 305 8. References 307 8.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 313 with Session Description Protocol (SDP)", RFC 3264, June 314 2002. 316 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 317 Jacobson, "RTP: A Transport Protocol for Real-Time 318 Applications", STD 64, RFC 3550, July 2003. 320 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 321 Description Protocol", RFC 4566, July 2006. 323 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 324 Media Attributes in the Session Description Protocol 325 (SDP)", RFC 5576, June 2009. 327 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 328 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 330 8.2. Informative References 332 [I-D.ietf-avtext-rtp-duplication] 333 Begen, A. and C. Perkins, "Duplicating RTP Streams", 334 draft-ietf-avtext-rtp-duplication-04 (work in progress), 335 October 2013. 337 [I-D.ietf-mmusic-delayed-duplication] 338 Begen, A., Cai, Y., and H. Ou, "Delayed Duplication 339 Attribute in the Session Description Protocol", draft- 340 ietf-mmusic-delayed-duplication-02 (work in progress), May 341 2013. 343 [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, 344 "Toward Lossless Video Transport, IEEE Internet Computing, 345 vol. 15/6, pp. 48-57", November 2011. 347 [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of 348 Streaming Media", RFC 2354, June 1998. 350 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 352 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 353 Announcement Protocol", RFC 2974, October 2000. 355 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 356 RFC 5652, September 2009. 358 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 359 Mail Extensions (S/MIME) Version 3.2 Message 360 Specification", RFC 5751, January 2010. 362 Authors' Addresses 364 Ali Begen 365 Cisco 366 181 Bay Street 367 Toronto, ON M5J 2T3 368 Canada 370 Email: abegen@cisco.com 372 Yiqun Cai 373 Microsoft 374 1065 La Avenida 375 Mountain View, CA 94043 376 USA 378 Email: yiqunc@microsoft.com 379 Heidi Ou 380 Cisco 381 170 W. Tasman Dr. 382 San Jose, CA 95134 383 USA 385 Email: hou@cisco.com