idnits 2.17.1 draft-ietf-mmusic-rfc4756bis-00.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 4 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 -- The draft header indicates that this document updates 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 (Using the creation date from RFC4756, updated by this document, for RFC5378 checks: 2005-10-25) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 21, 2009) is 5571 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) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-03 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-rfc3388bis-02 -- 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 (==), 6 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 Updates: 4756 (if approved) January 21, 2009 5 Intended status: Standards Track 6 Expires: July 25, 2009 8 Forward Error Correction Grouping Semantics in Session Description 9 Protocol 10 draft-ietf-mmusic-rfc4756bis-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 25, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 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 were 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 also do not support 56 additive repair flows. This document addresses these issues by 57 introducing new FEC grouping semantics. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 63 3. Requirements and Issues with RFC 4756 . . . . . . . . . . . . 5 64 3.1. Source and Repair Flow Association . . . . . . . . . . . . 5 65 3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6 66 4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. New Grouping Semantics . . . . . . . . . . . . . . . . . . 6 68 4.2. Offer / Answer Consideration . . . . . . . . . . . . . . . 7 69 4.3. Example of FEC Grouping . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Any application that needs a reliable transmission over an unreliable 81 packet network has to cope with packet losses. Forward Error 82 Correction (FEC) is an effective approach that provides reliable 83 transmission particularly in multicast and broadcast applications 84 where the feedback from the receiver(s) is potentially limited. 86 In a nutshell, FEC groups source packets into blocks and applies 87 protection to generate a desired number of repair packets. These 88 repair packets may be sent on demand or independently of any receiver 89 feedback. The choice depends on the FEC scheme or the Content 90 Delivery Protocol used by the application, the packet loss 91 characteristics of the underlying network, the transport scheme 92 (e.g., unicast, multicast and broadcast), and the application. At 93 the receiver side, lost packets can be recovered by erasure decoding 94 provided that a sufficient number of source and repair packets have 95 been received. 97 For example, one of the most basic FEC schemes is the parity codes, 98 where an XOR operation is applied to a group of packets (i.e., source 99 block) to generate a single repair packet. At the receiver side, 100 this scheme achieves a full recovery if only one packet is lost 101 within the source block and the repair packet is received. There are 102 various other ways of generating repair packets, possibly with 103 different loss-recovery capabilities. 105 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 106 framework for using FEC codes in multimedia applications that stream 107 audio, video or other types of multimedia content. The FEC Framework 108 specification states that source and repair packets MUST be carried 109 in different streams, which are referred to as the source and repair 110 flows, respectively. At the receiver side, the receivers should know 111 which flows are the source flows and which flows are the repair 112 flows. The receivers should also know the exact association of the 113 source and repair flows so that they can use the correct data to 114 repair the original content in case there is a packet loss. 115 Currently, SDP [RFC4566] uses [RFC3388] and [RFC4756] for this 116 purpose. 118 In order to provide applications more flexibility, the FEC Framework 119 [I-D.ietf-fecframe-framework] allows a source flow to be protected by 120 multiple FEC schemes, each of which requires an instance of the FEC 121 Framework. Thus, multiple instances of the FEC Framework MAY exist 122 at the sender and the receiver(s). Furthermore, within a single FEC 123 Framework instance, multiple source flows MAY be grouped and 124 protected by one or more repair flows. 126 A basic example scenario is shown in Figure 1. Here, source flow S1 127 is protected by repair flow R1. Also, source flows S1 and S2 are 128 grouped and protected together by repair flow R2. 130 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 131 | S1: Source Flow |--------| R1: Repair Flow 132 +---| 133 | | S2: Source Flow 134 | 135 +______________________________| FEC FRAMEWORK INSTANCE #2 136 | R2: Repair Flow 138 Figure 1: Example scenario with two FEC Framework instances where R1 139 protects S1, and R2 protects the group of S1 and S2 141 Grouping source flows before applying FEC protection may allow us to 142 achieve a better coding performance. As a typical scenario, suppose 143 that source flows S1 and S2 in Figure 1 correspond to the base and 144 enhancement layers in a layered video content, respectively. Repair 145 flow R2 protects the combination of the base and enhancement layer 146 for the receivers who receive both layers, and repair flow R1 147 protects the base layer only, for the receivers who want the base 148 layer only, or who receive both layers but prefer FEC protection for 149 the base layer only due to a bandwidth and/or processing-power 150 limitation. 152 Using multiple FEC Framework instances for a single source flow 153 provides flexibility to the receivers. An example scenario is 154 sketched in Figure 2. Different instances may offer repair flows 155 that are generated by different FEC schemes, and receivers choose 156 receiving the appropriate repair flow(s) that they can support and 157 decode. Alternatively, different instances (whether they use the 158 same FEC scheme or not) may use larger and smaller source block 159 sizes, which accommodate the receivers that have looser and tighter 160 latency requirements, respectively. In addition, different instances 161 may also provide FEC protection at different redundancy levels. This 162 is particularly useful in multicast scenarios where different 163 receivers might experience different packet loss rates and each 164 receiver can choose the repair flow that is tailored to its needs. 166 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 167 S3: Source Flow |---------| R3: Repair Flow 168 | 169 |---------| FEC FRAMEWORK INSTANCE #2 170 | R4: Repair Flow 172 Figure 2: Example scenario with two FEC Framework instances, each 173 with a single repair flow protecting the same source flow S3 175 To summarize, the FEC Framework supports the following: 177 1. A source flow MAY be protected by multiple different FEC schemes. 179 2. An FEC scheme MAY generate multiple repair flows. 181 3. Source flows MAY be grouped prior to FEC protection. That is, 182 one or more repair flows MAY protect a group of source flows. 184 To fully benefit from the flexibility provided by the FEC Framework, 185 the grouping semantics for FEC MUST support these features. 187 2. Requirements Notation 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 3. Requirements and Issues with RFC 4756 195 3.1. Source and Repair Flow Association 197 Currently, the 'group' attribute and the FEC grouping semantics 198 defined in [RFC3388] and [RFC4756], respectively, are used to 199 associate source and repair flows together. 201 The 'group' attribute is used to group multiple repair flows with one 202 or more source flows. However, [RFC3388] prohibits an "m" line 203 identified by its 'mid' attribute from appearing in more than one 204 "a=group" line using the same semantics. This limitation prevents us 205 from indicating specific associations between the source and repair 206 flows by using an "a=group:FEC" line per FEC Framework instance. For 207 example, for the scenario sketched in Figure 1, [RFC3388] mandates us 208 to write 209 a=group:FEC S1 S2 R1 R2 211 Clearly, this "a=group:FEC" line does not say anything specific about 212 which repair flows are protecting which source flows. 214 A new work ([I-D.ietf-mmusic-rfc3388bis]) is currently in progress in 215 the MMUSIC WG to remove this limitation in [RFC3388]. However, 216 [RFC4756] also needs to be updated according to the FEC Framework 217 requirements. 219 3.2. Support for Additivity 221 The FEC Framework also supports additive repair flows. Additivity 222 among the repair flows means that multiple repair flows may be 223 decoded jointly to improve the recovery chances of the missing 224 packets in a single or the same set of source flows. Additive repair 225 flows can be generated by the same FEC scheme or different FEC 226 schemes. 228 For example, in Figure 3, repair flows R5 and R6 may be additive 229 within the FEC Framework instance #1. Alternatively, all three 230 repair flows R5, R6 and R7 could be additive, too. 232 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 233 S4: Source Flow |---------| R5: Repair Flow 234 | | R6: Repair Flow 235 | 236 |---------| FEC FRAMEWORK INSTANCE #2 237 | R7: Repair Flow 239 Figure 3: Example scenario with two FEC Framework instances, where 240 two repair flows in the first instance and a single repair flow in 241 the second instance protect the same source flow S4 243 4. FEC Grouping 245 4.1. New Grouping Semantics 247 Each "a=group" line is used to indicate an association relationship 248 between the source and repair flows. The flows included in one 249 "a=group" line are called an "FEC Group." If there are more than one 250 repair flows included in an FEC group, they are considered to be 251 additive. Repair flows that are in different FEC groups are non- 252 additive. 254 By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-XR" as the 255 new grouping semantics that can support the features of the FEC 256 Framework. 258 4.2. Offer / Answer Consideration 260 The backward compatibility in offer / answer is generally handled as 261 specified in [RFC3388]. 263 Depending on the implementation, a node that does not understand FEC 264 grouping (either does not understand line grouping at all, or just 265 does not understand the FEC semantics) SHOULD respond to an offer 266 containing FEC grouping either (1) with an answer that ignores the 267 grouping attribute or (2) with a refusal to the request (e.g., 488 268 Not acceptable here or 606 Not acceptable in SIP). 270 In the first case, the original sender of the offer MUST establish 271 the connection without FEC. In the second case, if the sender of the 272 offer still wishes to establish the session, it SHOULD re-try the 273 request with an offer without FEC. 275 Editor's note: This section may need to be updated according to 276 [I-D.ietf-mmusic-rfc3388bis]. 278 4.3. Example of FEC Grouping 280 For the scenario sketched in Figure 1, we can write the following 281 SDP: 283 v=0 284 o=ali 1122334455 1122334466 IN IP4 fec.example.com 285 s=New FEC Grouping Semantics 286 t=0 0 287 a=group:FEC-XR S1 R1 288 a=group:FEX-XR S1 S2 R2 289 m=video 30000 RTP/AVP 100 290 c=IN IP4 224.1.1.1/127 291 a=rtpmap:100 MP2T/90000 292 a=mid:S1 293 m=video 30000 RTP/AVP 101 294 c=IN IP4 224.1.1.2/127 295 a=rtpmap:101 MP2T/90000 296 a=mid:S2 297 m=application 30000 RTP/AVP 110 298 c=IN IP4 224.1.2.1/127 299 a=rtpmap:110 1d-interleaved-parityfec/90000 300 a=fmtp:110 L:5; D:10; repair-window: 200000 301 a=mid:R1 302 m=application 30000 RTP/AVP 111 303 c=IN IP4 224.1.2.2/127 304 a=rtpmap:111 1d-interleaved-parityfec/90000 305 a=fmtp:111 L:10; D:10; repair-window: 200000 306 a=mid:R2 308 For the additivity issues, let us consider the scenario sketched in 309 Figure 3. Suppose that repair flows R5 and R6 are additive but 310 repair flow R7 is not additive with any of the other repair flows. 311 In this case, we must write 313 a=group:FEC-XR S4 R5 R6 314 a=group:FEC-XR S4 R7 316 If none of the repair flows are additive, we must write 318 a=group:FEC-XR S4 R5 319 a=group:FEC-XR S4 R6 320 a=group:FEC-XR S4 R7 322 5. Security Considerations 324 There is a weak threat for the receiver that the FEC grouping can be 325 modified to indicate FEC relationships that do not exist. Such 326 attacks may result in failure of FEC to protect, and/or mishandling 327 of other media payload streams. It is recommended that the receiver 328 SHOULD do integrity check on SDP and follow the security 329 considerations of SDP [RFC4566] to only trust SDP from trusted 330 sources. 332 6. IANA Considerations 334 This document registers the following semantics with IANA in 335 Semantics for the "group" SDP Attribute under SDP Parameters. 337 Semantics Token Reference 338 --------------------------- ------ ------------- 339 Forward Error Correction XR FEC-XR This document 341 7. Acknowledgments 343 Some parts of this document is based on [RFC4756]. Thus, the author 344 would like to thank those who contributed to [RFC4756]. 346 8. References 348 8.1. Normative References 350 [I-D.ietf-fecframe-framework] 351 Watson, M., "Forward Error Correction (FEC) Framework", 352 draft-ietf-fecframe-framework-03 (work in progress), 353 October 2008. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 359 Description Protocol", RFC 4566, July 2006. 361 [I-D.ietf-mmusic-rfc3388bis] 362 Camarillo, G., "The SDP (Session Description Protocol) 363 Grouping Framework", draft-ietf-mmusic-rfc3388bis-02 (work 364 in progress), January 2009. 366 8.2. Informative References 368 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 369 Session Description Protocol", RFC 4756, November 2006. 371 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 372 Schulzrinne, "Grouping of Media Lines in the Session 373 Description Protocol (SDP)", RFC 3388, December 2002. 375 Author's Address 377 Ali Begen 378 Cisco Systems 379 170 West Tasman Drive 380 San Jose, CA 95134 381 USA 383 Email: abegen@cisco.com