idnits 2.17.1 draft-ietf-mmusic-rfc4756bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 draft header indicates that this document obsoletes RFC4756, but the abstract doesn't seem to directly say this. It does mention RFC4756 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2009) is 5328 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 471, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-rfc3388bis-03 == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-05 -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Cisco Systems 4 Obsoletes: 4756 September 23, 2009 5 (if approved) 6 Intended status: Standards Track 7 Expires: March 27, 2010 9 Forward Error Correction Grouping Semantics in Session Description 10 Protocol 11 draft-ietf-mmusic-rfc4756bis-03 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 27, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The Session Description Protocol (SDP) supports grouping media lines. 50 SDP also has semantics defined for grouping the associated source and 51 Forward Error Correction (FEC)-based repair flows. However, the 52 semantics that was defined in RFC 4756 generally fail to provide the 53 specific grouping relationships between the source and repair flows 54 when there are more than one source and/or repair flows in the same 55 group. Furthermore, the existing semantics does not support 56 describing additive repair flows. This document addresses these 57 issues by introducing new FEC grouping semantics. SSRC-level 58 grouping semantics is also introduced in this document for Real-time 59 Transport Protocol (RTP) streams using SSRC multiplexing. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 65 3. Requirements and Issues with RFC 4756 . . . . . . . . . . . . 5 66 3.1. Source and Repair Flow Association . . . . . . . . . . . . 5 67 3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6 68 4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. New Grouping Semantics . . . . . . . . . . . . . . . . . . 6 70 4.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8 72 4.4. Offer-Answer Model Considerations . . . . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Any application that needs a reliable transmission over an unreliable 84 packet network has to cope with packet losses. Forward Error 85 Correction (FEC) is an effective approach that provides reliable 86 transmission particularly in multicast and broadcast applications 87 where the feedback from the receiver(s) is potentially limited. 89 In a nutshell, FEC groups source packets into blocks and applies 90 protection to generate a desired number of repair packets. These 91 repair packets may be sent on demand or independently of any receiver 92 feedback. The choice depends on the FEC scheme, the packet loss 93 characteristics of the underlying network, the transport scheme 94 (e.g., unicast, multicast and broadcast) and the application. At the 95 receiver side, lost packets can be recovered by erasure decoding 96 provided that a sufficient number of source and repair packets have 97 been received. 99 For example, one of the most basic FEC schemes is the parity codes, 100 where an exclusive OR (XOR) operation is applied to a group of 101 packets (i.e., source block) to generate a single repair packet. At 102 the receiver side, this scheme provides a full recovery if only one 103 packet is lost within the source block and the repair packet is 104 received. There are various other ways of generating repair packets, 105 possibly with different loss-recovery capabilities. 107 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 108 framework for using FEC codes in multimedia applications that stream 109 audio, video or other types of multimedia content. The FEC Framework 110 specification states that source and repair packets MUST be carried 111 in different streams, which are referred to as the source and repair 112 flows, respectively. At the receiver side, the receivers should know 113 which flows are the source flows and which flows are the repair 114 flows. The receivers should also know the exact association of the 115 source and repair flows so that they can use the correct data to 116 repair the original content in case there is a packet loss. 117 Currently, SDP [RFC4566] uses [RFC3388] and [RFC4756] for this 118 purpose. 120 In order to provide applications more flexibility, the FEC Framework 121 [I-D.ietf-fecframe-framework] allows a source flow to be protected by 122 multiple FEC schemes, each of which requires an instance of the FEC 123 Framework. Thus, multiple instances of the FEC Framework MAY exist 124 at the sender and the receiver(s). Furthermore, within a single FEC 125 Framework instance, multiple source flows MAY be grouped and 126 protected by one or more repair flows. 128 It should be noted that the FEC Framework requires the source and 129 repair packets to be carried in different streams. When Real-time 130 Transport Protocol (RTP) [RFC3550] is used to carry the source and 131 repair streams, the FEC Framework recommends that each stream is 132 carried in its own RTP session. This provides flexibility in using 133 FEC in a backward-compatible manner. However, in some scenarios, a 134 single RTP session may be desired to carry multiple RTP streams via 135 SSRC multiplexing in order to reduce the port usage. For such 136 scenarios, an appropriate grouping semantics is also required. 138 A basic example scenario is shown in Figure 1. Here, source flow S1 139 is protected by repair flow R1. Also, source flows S1 and S2 are 140 grouped and protected together by repair flow R2. 142 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 143 | S1: Source Flow |--------| R1: Repair Flow 144 +---| 145 | | S2: Source Flow 146 | 147 +______________________________| FEC FRAMEWORK INSTANCE #2 148 | R2: Repair Flow 150 Figure 1: Example scenario with two FEC Framework instances where R1 151 protects S1, and R2 protects the group of S1 and S2 153 Grouping source flows before applying FEC protection may allow us to 154 achieve a better coding performance. As a typical scenario, suppose 155 that source flows S1 and S2 in Figure 1 correspond to the base and 156 enhancement layers in a layered video content, respectively. Repair 157 flow R2 protects the combination of the base and enhancement layers 158 for the receivers who receive both layers, and repair flow R1 159 protects the base layer only, for the receivers who want the base 160 layer only, or who receive both layers but prefer FEC protection for 161 the base layer only due to a bandwidth and/or any other limitation. 163 It should be noted that the grouping semantics defined in this 164 document offers flexibility about which source streams can be grouped 165 together prior to FEC protection. However, not all FEC schemes 166 support the full range of the possible scenarios (e.g., when the 167 source streams carry different top-level media types such as audio 168 and video). 170 Using multiple FEC Framework instances for a single source flow 171 provides flexibility to the receivers. An example scenario is 172 sketched in Figure 2. Different instances may offer repair flows 173 that are generated by different FEC schemes, and receivers choose 174 receiving the appropriate repair flow(s) that they can support and 175 decode. Alternatively, different instances (whether they use the 176 same FEC scheme or not) may use larger and smaller source block 177 sizes, which accommodate the receivers that have looser and tighter 178 latency requirements, respectively. In addition, different instances 179 may also provide FEC protection at different redundancy levels. This 180 is particularly useful in multicast scenarios where different 181 receivers may experience different packet loss rates and each 182 receiver can choose the repair flow that is tailored to its needs. 184 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 185 S3: Source Flow |---------| R3: Repair Flow 186 | 187 |---------| FEC FRAMEWORK INSTANCE #2 188 | R4: Repair Flow 190 Figure 2: Example scenario with two FEC Framework instances, each 191 with a single repair flow protecting the same source flow S3 193 To summarize, the FEC Framework supports the following: 195 1. A source flow MAY be protected by multiple different FEC schemes. 197 2. An FEC scheme MAY generate multiple repair flows. 199 3. Source flows MAY be grouped prior to FEC protection. That is, 200 one or more repair flows MAY protect a group of source flows. 202 To fully benefit from the flexibility provided by the FEC Framework, 203 the grouping semantics for FEC MUST support these features. 205 2. Requirements Notation 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 211 3. Requirements and Issues with RFC 4756 213 3.1. Source and Repair Flow Association 215 Currently, the 'group' attribute and the FEC grouping semantics 216 defined in [RFC3388] and [RFC4756], respectively, are used to 217 associate source and repair flows together. 219 The 'group' attribute is used to group multiple repair flows with one 220 or more source flows. However, [RFC3388] prohibits an "m" line 221 identified by its 'mid' attribute from appearing in more than one 222 "a=group" line using the same semantics. This limitation prevents us 223 from indicating specific associations between the source and repair 224 flows by using an "a=group:FEC" line per FEC Framework instance. For 225 example, for the scenario sketched in Figure 1, [RFC3388] mandates us 226 to write 228 a=group:FEC S1 S2 R1 R2 230 Clearly, this "a=group:FEC" line does not say anything specific about 231 which repair flows are protecting which source flows. 233 A new work ([I-D.ietf-mmusic-rfc3388bis]) is currently in progress in 234 the MMUSIC WG to remove this limitation in [RFC3388]. However, 235 [RFC4756] also needs to be updated according to the FEC Framework 236 requirements. 238 3.2. Support for Additivity 240 The FEC Framework also supports additive repair flows. Additivity 241 among the repair flows means that multiple repair flows may be 242 decoded jointly to improve the recovery chances of the missing 243 packets in a single or the same set of source flows. Additive repair 244 flows can be generated by the same FEC scheme or different FEC 245 schemes. 247 For example, in Figure 3, repair flows R5 and R6 may be additive 248 within the FEC Framework instance #1. Alternatively, all three 249 repair flows R5, R6 and R7 could be additive, too. 251 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 252 S4: Source Flow |---------| R5: Repair Flow 253 | | R6: Repair Flow 254 | 255 |---------| FEC FRAMEWORK INSTANCE #2 256 | R7: Repair Flow 258 Figure 3: Example scenario with two FEC Framework instances, where 259 two repair flows in the first instance and a single repair flow in 260 the second instance protect the same source flow S4 262 4. FEC Grouping 264 4.1. New Grouping Semantics 266 Each "a=group" line is used to indicate an association relationship 267 between the source and repair flows. The flows included in one 268 "a=group" line are called an FEC Group. If there are more than one 269 repair flows included in an FEC group, they are considered to be 270 additive. Repair flows that are in different FEC groups are non- 271 additive. 273 By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-XR" as the 274 new grouping semantics that can support the features of the FEC 275 Framework. 277 The "a=group:FEC-XR" semantics MUST always be used to associate the 278 source and repair flows except when the source and repair flows are 279 specified in the same media description, i.e., in the same "m" line. 281 4.2. SDP Example 283 For the scenario sketched in Figure 1, we can write the following 284 SDP: 286 v=0 287 o=ali 1122334455 1122334466 IN IP4 fec.example.com 288 s=New FEC Grouping Semantics 289 t=0 0 290 a=group:FEC-XR S1 R1 291 a=group:FEC-XR S1 S2 R2 292 m=video 30000 RTP/AVP 100 293 c=IN IP4 233.252.0.1/127 294 a=rtpmap:100 MP2T/90000 295 a=mid:S1 296 m=video 30000 RTP/AVP 101 297 c=IN IP4 233.252.0.2/127 298 a=rtpmap:101 MP2T/90000 299 a=mid:S2 300 m=application 30000 RTP/AVP 110 301 c=IN IP4 233.252.0.3/127 302 a=rtpmap:110 1d-interleaved-parityfec/90000 303 a=fmtp:110 L=5; D=10; repair-window=200000 304 a=mid:R1 305 m=application 30000 RTP/AVP 111 306 c=IN IP4 233.252.0.4/127 307 a=rtpmap:111 1d-interleaved-parityfec/90000 308 a=fmtp:111 L=10; D=10; repair-window=400000 309 a=mid:R2 311 In this example, the source and repair flows are carried in their own 312 RTP sessions and the grouping is achieved through the "a=group: 313 FEC-XR" lines. 315 For the additivity issues, let us consider the scenario sketched in 316 Figure 3. Suppose that repair flows R5 and R6 are additive but 317 repair flow R7 is not additive with any of the other repair flows. 319 In this case, we MUST write 321 a=group:FEC-XR S4 R5 R6 322 a=group:FEC-XR S4 R7 324 If none of the repair flows are additive, we MUST write 326 a=group:FEC-XR S4 R5 327 a=group:FEC-XR S4 R6 328 a=group:FEC-XR S4 R7 330 Note that additivity is not necessarily a transitive relation. Thus, 331 each set of additive repair flows MUST be stated explicitly. 333 4.3. Grouping for SSRC-Multiplexed RTP Streams 335 [RFC5576] defines a grouping attribute, called 'ssrc-group', for the 336 RTP streams that are SSRC multiplexed and carried in the same RTP 337 session. The grouping is based on the Synchronization Source (SSRC) 338 identifiers. Since SSRC-multiplexed RTP streams are defined in the 339 same "m" line, the 'group' attribute cannot be used. Instead, the 340 'ssrc-group' attribute MUST be used. 342 Per [RFC3550], the SSRC identifiers for the RTP streams that are 343 carried in the same RTP session MUST be unique. However, the SSRC 344 identifiers are not guaranteed to be unique among different RTP 345 sessions. Thus, the 'ssrc-group' attribute MUST only be used at the 346 media level [RFC5576]. The semantics of "FEC-XR" for the 'ssrc- 347 group' attribute is exactly the same as the one defined for the 348 'group' attribute. 350 Let us consider the following scenario where there are two source 351 flows (e.g., one video and one audio) and a single repair flow that 352 protects only one of the source flows (e.g., video). Suppose that 353 all these flows are separate RTP streams that are SSRC multiplexed in 354 the same RTP session. 356 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 357 S5: Source Flow |--------| R8: Repair Flow 358 S6: Source Flow 360 Figure 4: Example scenario with one FEC Framework instance, where a 361 single repair flow protects only one of the source flows 363 The following SDP describes the scenario sketched in Figure 4. 365 v=0 366 o=ali 1122334455 1122334466 IN IP4 fec.example.com 367 s=New FEC Grouping Semantics for SSRC Multiplexing 368 t=0 0 369 m=video 30000 RTP/AVP 100 101 110 370 c=IN IP4 233.252.0.1/127 371 a=rtpmap:100 JPEG/90000 372 a=rtpmap:101 L16/32000/2 373 a=rtpmap:110 1d-interleaved-parityfec/90000 374 a=fmtp:110 L=5; D=10; repair-window=200000 375 a=ssrc:1000 cname:fec@example.com 376 a=ssrc:1010 cname:fec@example.com 377 a=ssrc:2110 cname:fec@example.com 378 a=ssrc-group:FEC-XR 1000 2110 379 a=mid:Group1 381 Note that in actual use, SSRC values, which are random 32-bit 382 numbers, may be much larger than the ones shown in this example. 383 Also note that before receiving an RTP packet for each stream, the 384 receiver cannot know which SSRC identifier is associated with which 385 payload type. 387 The additivity of the repair flows is handled in the same way as 388 described in Section 4.2. In other words, the repair flows that are 389 included in an "a=ssrc-group" line are additive. Repair flows that 390 are in different "a=ssrc-group" lines are non-additive. 392 4.4. Offer-Answer Model Considerations 394 When offering FEC grouping using SDP in an Offer/Answer model 395 [RFC3264], the following considerations apply. 397 A node that is receiving an offer from a sender may or may not 398 understand line grouping. It is also possible that the node 399 understands line grouping but it does not understand the "FEC-XR" 400 semantics. From the viewpoint of the sender of the offer, these 401 cases are indistinguishable. 403 When a node is offered a session with the "FEC-XR" grouping semantics 404 but it does not support line grouping or the FEC grouping semantics, 405 the node SHOULD respond to the offer either: 407 o With an answer that ignores the grouping attribute. 409 In this case, the original sender of the offer MUST first check 410 whether using the FEC grouping semantics of [RFC4756] will create 411 any ambiguity or not, while keeping in mind the limitations 412 explained in Section 3.1. If using the "FEC" semantics rather 413 than the "FEC-XR" semantics still provides an exact association 414 among the source and repair flows, the sender of the offer MUST 415 send a new offer using the "FEC" semantics. However, if an exact 416 association cannot be described, the sender MUST send a new offer 417 without FEC. 419 o With a refusal to the request (e.g., 488 Not Acceptable Here or 420 606 Not Acceptable in SIP). 422 In this case, if the sender of the offer still wishes to establish 423 the session, it MUST first check whether using the FEC grouping 424 semantics of [RFC4756] will create any ambiguity or not, while 425 keeping in mind the limitations explained in Section 3.1. If 426 using the "FEC" semantics rather than the "FEC-XR" semantics still 427 provides an exact association among the source and repair flows, 428 the sender of the offer SHOULD send a new offer using the "FEC" 429 semantics. However, if an exact association cannot be described, 430 the sender SHOULD send a new offer without FEC. 432 Note that in both cases described above, when the sender of the offer 433 sends a new offer with the "FEC" semantics, and the node understands 434 it, the session will be established and the rules pertaining to 435 [RFC4756] will be valid. 437 However, if the node does not understand the "FEC" semantics, it 438 SHOULD respond to the offer either (1) with an answer that ignores 439 the grouping attribute, or (2) with a refusal to the request. In the 440 first case, the sender MUST send a new offer without FEC. In the 441 second case, if the sender of the offer still wishes to establish the 442 session, it SHOULD retry the request with an offer without FEC. 444 5. Security Considerations 446 There is a weak threat for the receiver that the FEC grouping can be 447 modified to indicate FEC relationships that do not exist. Such 448 attacks may result in failure of FEC to protect, and/or mishandling 449 of other media payload streams. It is RECOMMENDED that the receiver 450 SHOULD do integrity check on SDP and follow the security 451 considerations of SDP [RFC4566] to only trust SDP from trusted 452 sources. 454 6. IANA Considerations 456 This document registers the following semantics with IANA in 457 Semantics for the 'group' SDP Attribute under SDP Parameters: 459 Note to the RFC Editor: In the following, please replace "XXXX" with 460 the number of this document prior to publication as an RFC. 462 Semantics Token Reference 463 --------------------------- ------ --------- 464 Forward Error Correction XR FEC-XR [RFCXXXX] 466 This document also registers the following semantics with IANA in 467 Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters: 469 Semantics Token Reference 470 --------------------------- ------ --------- 471 Forward Error Correction XR FEC-XR [RFCXXXX] 473 7. Acknowledgments 475 Some parts of this document are based on [RFC4756]. Thus, the author 476 would like to thank those who contributed to [RFC4756]. Also, thanks 477 to Jonathan Lennox who has contributed to Section 4.3. 479 8. References 481 8.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 487 Description Protocol", RFC 4566, July 2006. 489 [I-D.ietf-mmusic-rfc3388bis] 490 Camarillo, G., "The SDP (Session Description Protocol) 491 Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work 492 in progress), July 2009. 494 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 495 with Session Description Protocol (SDP)", RFC 3264, 496 June 2002. 498 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 499 Jacobson, "RTP: A Transport Protocol for Real-Time 500 Applications", STD 64, RFC 3550, July 2003. 502 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 503 Media Attributes in the Session Description Protocol 504 (SDP)", RFC 5576, June 2009. 506 8.2. Informative References 508 [I-D.ietf-fecframe-framework] 509 Watson, M., "Forward Error Correction (FEC) Framework", 510 draft-ietf-fecframe-framework-05 (work in progress), 511 July 2009. 513 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 514 Session Description Protocol", RFC 4756, November 2006. 516 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 517 Schulzrinne, "Grouping of Media Lines in the Session 518 Description Protocol (SDP)", RFC 3388, December 2002. 520 Author's Address 522 Ali Begen 523 Cisco Systems 524 170 West Tasman Drive 525 San Jose, CA 95134 526 USA 528 Email: abegen@cisco.com