idnits 2.17.1 draft-begen-mmusic-redundancy-grouping-03.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 11, 2012) is 4401 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 292, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- 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 (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Y. Cai 4 Intended status: Standards Track H. Ou 5 Expires: September 12, 2012 Cisco 6 March 11, 2012 8 Duplication Grouping Semantics in the Session Description Protocol 9 draft-begen-mmusic-redundancy-grouping-03 11 Abstract 13 Packet loss is undesirable for real-time multimedia sessions, but can 14 occur due to congestion, or other unplanned network outages. This is 15 especially true for IP multicast networks, where packet loss patterns 16 can vary greatly between receivers. One technique that can be used 17 to recover from packet loss without incurring unbounded delay for all 18 the receivers is to duplicate the packets and send them in separate 19 redundant streams. This document defines the semantics for grouping 20 redundant streams in the Session Description Protocol (SDP). The 21 semantics defined in this document are to be used with the SDP 22 Grouping Framework [RFC5888]. SSRC-level (Synchronization Source) 23 grouping semantics are also defined in this document for RTP streams 24 using SSRC multiplexing. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 62 3. Duplication Grouping . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. "DUP" Grouping Semantics . . . . . . . . . . . . . . . . . 3 64 3.2. DUP Grouping for SSRC-Multiplexed RTP Streams . . . . . . . 4 65 3.3. SDP Offer/Answer Model Considerations . . . . . . . . . . . 4 66 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Separate Source Addresses . . . . . . . . . . . . . . . . . 5 68 4.2. Separate Destination Addresses . . . . . . . . . . . . . . 5 69 4.3. Temporal Redundancy . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The Real-time Transport Protocol (RTP) [RFC3550] is widely used today 81 for delivering IPTV traffic, and other real-time multimedia sessions. 82 Many of these applications support very large numbers of receivers, 83 and rely on intra-domain UDP/IP multicast for efficient distribution 84 of traffic within the network. 86 While this combination has proved successful, there does exist a 87 weakness. As [RFC2354] noted, packet loss is not avoidable, even in 88 a carefully managed network. This loss might be due to congestion, 89 it might also be a result of an unplanned outage caused by a flapping 90 link, link or interface failure, a software bug, or a maintenance 91 person accidentally cutting the wrong fiber. Since UDP/IP flows do 92 not provide any means for detecting loss and retransmitting packets, 93 it leaves up to the RTP layer and the applications to detect, and 94 recover from, packet loss. 96 One technique to recover from packet loss without incurring unbounded 97 delay for all the receivers is to duplicate the packets and send them 98 in separate redundant streams. Variations on this idea have been 99 implemented and deployed today [IC2011]. 100 [I-D.begen-avtcore-rtp-duplication] explains how duplication can be 101 achieved for RTP streams without breaking the RTP and RTCP 102 functionality. In this document, we describe the semantics needed in 103 the Session Description Protocol (SDP) [RFC4566] to support this 104 technique. 106 2. Requirements Notation 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 [RFC2119]. 113 3. Duplication Grouping 115 3.1. "DUP" Grouping Semantics 117 Each "a=group" line is used to indicate an association relationship 118 between the redundant streams. The streams included in one "a=group" 119 line are called a Duplication Group. 121 Using the framework in [RFC5888], this document defines "DUP" as the 122 grouping semantics for redundant streams. 124 The "a=group:DUP" semantics MUST be used to group the redundant 125 streams except when the streams are specified in the same media 126 description, i.e., in the same "m" line (See Section 3.2). 128 When the redundant streams are described in separate "m" lines and 129 the 'group' attribute is used to describe the redundancy relation, 130 the SSRCs for each redundant stream MUST be announced in the SDP 131 description using the 'ssrc' attribute [RFC5576]. According to 132 [I-D.begen-avtcore-rtp-duplication], the sender must also use the 133 same RTCP CNAME for both the main and redundant streams, and must 134 include an "a=ssrc:... srcname:..." attribute to correlate the flows. 136 3.2. DUP Grouping for SSRC-Multiplexed RTP Streams 138 [RFC5576] defines an SDP media-level attribute, called 'ssrc-group', 139 for grouping the RTP streams that are SSRC multiplexed and carried in 140 the same RTP session. The grouping is based on the SSRC identifiers. 141 Since SSRC-multiplexed RTP streams are defined in the same "m" line, 142 the 'group' attribute cannot be used. 144 This section specifies how duplication is used with SSRC-multiplexed 145 streams using the 'ssrc-group' attribute [RFC5576]. 147 The semantics of "DUP" for the 'ssrc-group' attribute are the same as 148 the one defined for the 'group' attribute except that the SSRC 149 identifiers are used to designate the duplication grouping 150 associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576]. 152 3.3. SDP Offer/Answer Model Considerations 154 When offering duplication grouping using SDP in an Offer/Answer model 155 [RFC3264], the following considerations apply. 157 A node that is receiving an offer from a sender may or may not 158 understand line grouping. It is also possible that the node 159 understands line grouping but it does not understand the "DUP" 160 semantics. From the viewpoint of the sender of the offer, these 161 cases are indistinguishable. 163 When a node is offered a session with the "DUP" grouping semantics 164 but it does not support line grouping or the duplication grouping 165 semantics, as per [RFC5888], the node responds to the offer either 166 (1) with an answer that ignores the grouping attribute or (2) with a 167 refusal to the request (e.g., 488 Not Acceptable Here or 606 Not 168 Acceptable in SIP). 170 In the first case, the original sender of the offer must send a new 171 offer without any duplication grouping. In the second case, if the 172 sender of the offer still wishes to establish the session, it should 173 retry the request with an offer without the duplication grouping. 174 This behavior is specified in [RFC5888]. 176 4. SDP Examples 178 4.1. Separate Source Addresses 180 In this example, the redundant streams use the same IP destination 181 address (232.252.0.1) but they are sourced from different addresses 182 (198.51.100.1 and 198.51.100.2). Thus, the receiving host needs to 183 join both SSM sessions separately. 185 v=0 186 o=ali 1122334455 1122334466 IN IP4 dup.example.com 187 s=DUP Grouping Semantics 188 t=0 0 189 m=video 30000 RTP/AVP 100 190 c=IN IP4 232.252.0.1/127 191 a=source-filter:incl IN IP4 232.252.0.1 198.51.100.1 198.51.100.2 192 a=rtpmap:100 MP2T/90000 193 a=ssrc:1000 cname:ch1@example.com 194 a=ssrc:1010 cname:ch1@example.com 195 a=ssrc-group:DUP 1000 1010 196 a=mid:Group1 198 Note that in actual use, SSRC values, which are random 32-bit 199 numbers, can be much larger than the ones shown in this example. 201 4.2. Separate Destination Addresses 203 In this example, the redundant streams have different IP destination 204 addresses. The example shows the same UDP port number and IP source 205 addresses, but either or both could have been different for the two 206 streams. 208 v=0 209 o=ali 1122334455 1122334466 IN IP4 dup.example.com 210 s=DUP Grouping Semantics 211 t=0 0 212 a=group:DUP S1a S1b 213 m=video 30000 RTP/AVP 100 214 c=IN IP4 233.252.0.1/127 215 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 216 a=rtpmap:100 MP2T/90000 217 a=ssrc:1000 cname:ch1@example.com 218 a=ssrc:1000 srcname:45:a8:f4:19:b4:c3 219 a=mid:S1a 220 m=video 30000 RTP/AVP 101 221 c=IN IP4 233.252.0.2/127 222 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 223 a=rtpmap:101 MP2T/90000 224 a=ssrc:1010 cname:ch1@example.com 225 a=ssrc:1010 srcname:45:a8:f4:19:b4:c3 226 a=mid:S1b 228 4.3. Temporal Redundancy 230 In this example, the redundant streams have the same IP source and 231 destination addresses but different UDP port numbers. Due to the 232 same source and destination addresses, the packets in both streams 233 will be routed over the same path. To provide resiliency against 234 packet loss, the duplicate of an original packet is transmitted 50 ms 235 later as indicated by the 'duplication-delay' attribute (defined in 236 [I-D.begen-mmusic-temporal-interleaving]). 238 v=0 239 o=ali 1122334455 1122334466 IN IP4 dup.example.com 240 s=DUP Grouping Semantics 241 t=0 0 242 a=group:DUP S1a S1b 243 a=duplication-delay:50 244 m=video 30000 RTP/AVP 100 245 c=IN IP4 233.252.0.1/127 246 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 247 a=rtpmap:100 MP2T/90000 248 a=ssrc:1000 cname:ch1@example.com 249 a=ssrc:1000 srcname:45:a8:f4:19:b4:c3 250 a=mid:S1a 251 m=video 40000 RTP/AVP 101 252 c=IN IP4 233.252.0.1/127 253 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 254 a=rtpmap:101 MP2T/90000 255 a=ssrc:1010 cname:ch1@example.com 256 a=ssrc:1010 srcname:45:a8:f4:19:b4:c3 257 a=mid:S1b 259 5. Security Considerations 261 There is a weak threat for the receiver that the duplication grouping 262 can be modified to indicate relationships that do not exist. Such 263 attacks might result in failure of the duplication mechanisms, and/or 264 mishandling of the media streams by the receivers. 266 In order to avoid attacks of this sort, the SDP description needs to 267 be integrity protected and provided with source authentication. This 268 can, for example, be achieved on an end-to-end basis using S/MIME 269 [RFC5652] [RFC5751] when the SDP is used in a signaling packet using 270 MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the 271 authentication method in the Session Announcement Protocol (SAP) 272 [RFC2974] could be used as well. 274 6. IANA Considerations 276 This document registers the following semantics with IANA in 277 Semantics for the 'group' SDP Attribute under SDP Parameters: 279 Note to the RFC Editor: In the following registrations, please 280 replace "XXXX" with the number of this document prior to publication 281 as an RFC. 283 Semantics Token Reference 284 ------------------------------------- ------ --------- 285 Duplication DUP [RFCXXXX] 287 This document also registers the following semantics with IANA in 288 Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters: 290 Token Semantics Reference 291 ------- ----------------------------- --------- 292 DUP Duplication [RFCXXXX] 294 7. Acknowledgments 296 The authors would like to thank Colin Perkins, Bill Ver Steeg, Dave 297 Oran and Toerless Eckert for their inputs and suggestions. 299 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.begen-avtcore-rtp-duplication] 327 Begen, A. and C. Perkins, "Duplicating RTP Streams", 328 draft-begen-avtcore-rtp-duplication-01 (work in progress), 329 March 2012. 331 [I-D.begen-mmusic-temporal-interleaving] 332 Begen, A., Cai, Y., and H. Ou, "Delayed Duplication 333 Attribute in the Session Description Protocol", 334 draft-begen-mmusic-temporal-interleaving-04 (work in 335 progress), March 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 Cisco 368 170 W. Tasman Dr. 369 San Jose, CA 95134 370 USA 372 Email: ycai@cisco.com 373 Heidi Ou 374 Cisco 375 170 W. Tasman Dr. 376 San Jose, CA 95134 377 USA 379 Email: hou@cisco.com