idnits 2.17.1 draft-ietf-fecframe-dvb-al-fec-02.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (August 11, 2009) is 5372 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-fecframe-interleaved-fec-scheme-05 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-raptor-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Informational T. Stockhammer 5 Expires: February 12, 2010 Nomor Research 6 August 11, 2009 8 DVB Application-Layer Hybrid FEC Protection 9 draft-ietf-fecframe-dvb-al-fec-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 12, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes the Application-layer Forward Error 48 Correction (FEC) protocol that was developed by the Digital Video 49 Broadcasting (DVB) consortium for the protection of media streams 50 over IP networks. The DVB AL-FEC protocol uses two layers for FEC 51 protection. The first (base) layer is based on the 1-D interleaved 52 parity code. The second (enhancement) layer is based on the Raptor 53 code. By offering a layered approach, the DVB AL-FEC offers a good 54 protection against both bursty and random packet losses at a cost of 55 decent complexity. The 1-D interleaved parity code and Raptor code 56 have already been specified in separate documents and the current 57 document normatively references these specifications. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 63 3. DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . . 5 64 3.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7 66 3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8 67 4. Session Description Protocol (SDP) Signaling . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 In 2007, the Digital Video Broadcasting (DVB) consortium published a 79 technical specification [ETSI-TS-102-034v1.3.1] through European 80 Telecommunications Standards Institute (ETSI). This specification 81 covers several areas related to the transmission of MPEG2 transport 82 stream-based services over IP networks. 84 The Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol 85 for Application-layer Forward Error Correction (AL-FEC) to protect 86 the streaming media for DVB-IP services carried over RTP [RFC3550] 87 transport. In 2008, DVB updated the specification in a new revision 88 that has been published as a DVB Bluebook [DVB-A086r7] and serves as 89 draft ETSI TS-102-034v1.4.1 until the final ETSI publication 90 (expected in early 2009). Among others, some updates and 91 modifications to the AL-FEC protocol have been made. 93 The DVB AL-FEC protocol uses two layers for protection: a base layer 94 that is produced by the 1-D interleaved parity code, and an 95 enhancement layer that is produced by the Raptor code. Whenever a 96 receiver supports the DVB AL-FEC protocol, the decoding support for 97 the base-layer FEC is mandatory while the decoding support for the 98 enhancement-layer FEC is optional. Both the interleaved parity code 99 and the Raptor code are systematic FEC codes, meaning that source 100 packets are not modified in any way during the FEC encoding process. 102 The normative DVB AL-FEC protocol considers protection of single- 103 sequence source RTP flows only. The source can be any type of media 104 such as audio, video, text or application. However, in the AL-FEC 105 protocol, the source stream can only be an MPEG-2 transport stream. 106 The FEC data at each layer are generated based on some configuration 107 information, which also determines the exact associations and 108 relationships between the source and repair packets. This document 109 shows how this configuration may be communicated out-of-band in the 110 Session Description Protocol (SDP) [RFC4566]. 112 In DVB AL-FEC, the source packets are carried in the source RTP 113 stream and the generated FEC repair packets at each layer are carried 114 in separate streams. At the receiver side, if all of the source 115 packets are successfully received, there is no need for FEC recovery 116 and the repair packets may be discarded. However, if there are 117 missing source packets, the repair packets can be used to recover the 118 missing information. 120 The block diagram of the encoder side for the systematic DVB AL-FEC 121 protection is sketched in Figure 1. Here, the source packets are fed 122 into the parity encoder to produce the parity repair packets. The 123 source packets may also be fed to the Raptor encoder to produce the 124 Raptor repair packets. Source packets as well as the repair packets 125 are then sent to the receiver(s) over an IP network. 127 +--------------+ 128 +--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 129 +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 130 +--------------+ 131 | Parity | -> +==+ +==+ +==+ 132 | Encoder | +==+ +==+ +==+ 133 +--------------+ 134 | Raptor | -> +~~+ +~~+ 135 | Encoder | +~~+ +~~+ 136 +--------------+ 138 Source Packet: +--+ 139 +--+ 141 Base-layer Repair Packet: +==+ 142 +==+ 144 Enhancement-layer Repair Packet: +~~+ 145 +~~+ 147 Figure 1: Block diagram for the DVB AL-FEC encoder 149 The block diagram of the decoder side for the systematic DVB AL-FEC 150 protection is sketched in Figure 2. This is a Minimum Performance 151 Decoder since the receiver only supports decoding the base-layer 152 repair packets. If there is a loss among the source packets, the 153 parity decoder attempts to recover the missing source packets by 154 using the base-layer repair packets. 156 +--------------+ 157 +--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 158 +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 159 +--------------+ 160 +==+ +==+ +==+ --> | Parity | 161 +==+ +==+ +==+ | Decoder | 162 +--------------+ 164 Lost Packet: X 166 Figure 2: Block diagram for the DVB AL-FEC minimum performance 167 decoder 169 On the other hand, if the receiver supports decoding both the base- 170 layer and enhancement-layer repair packets, a combined (hybrid) 171 decoding approach is employed to improve the recovery rate of the 172 lost packets. In this case, the decoder is called an Enhanced 173 Decoder. Section 3.3 outlines the procedures for hybrid decoding. 175 +--------------+ 176 +--+ X X X --> | Systematic | -> +--+ +--+ +--+ +--+ 177 +--+ |FEC Protection| +--+ +--+ +--+ +--+ 178 +--------------+ 179 +==+ +==+ +==+ --> | Parity | 180 +==+ +==+ +==+ | Decoder | 181 +--------------+ 182 +~~+ +~~+ --> | Raptor | 183 +~~+ +~~+ | Decoder | 184 +--------------+ 186 Lost Packet: X 188 Figure 3: Block diagram for the DVB AL-FEC enhanced decoder 190 2. Requirements Notation 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 3. DVB AL-FEC Specification 198 The DVB AL-FEC protocol comprises two layers of FEC protection: 1-D 199 interleaved parity FEC for the base layer and Raptor FEC for the 200 enhancement layer. The performance of these FEC codes has been 201 examined in detail in [DVB-A115]. 203 3.1. Base-Layer FEC 205 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 206 to generate the repair symbols. In a group of D x L source packets, 207 the XOR operation is applied to the group of the source packets whose 208 sequence numbers are L apart from each other to generate L repair 209 packets. Due to interleaving, this FEC is effective against bursty 210 packet losses up to burst sizes of length L. 212 The DVB AL-FEC protocol requires the D x L block of the source 213 packets protected by the 1-D interleaved FEC code to be wholly 214 contained within a single source block of the Raptor code, if both 215 FEC layers are used. 217 Originally, the DVB AL-FEC protocol had adopted the 1-D interleaved 218 FEC payload format from [SMPTE2022-1] in [ETSI-TS-102-034v1.3.1]. 219 However, some incompatibilities with RTP [RFC3550] have been 220 discovered in this specification. These issues have all been 221 addressed in [I-D.ietf-fecframe-interleaved-fec-scheme] (For details, 222 refer to Section 1 of [I-D.ietf-fecframe-interleaved-fec-scheme]). 223 Some of the changes required by 224 [I-D.ietf-fecframe-interleaved-fec-scheme] are, however, not backward 225 compatible with the existing implementations that were based on 226 [SMPTE2022-1]. 228 In a recent liaison from IETF AVT WG to DVB IPI, it has been 229 recommended that DVB IPI defines a new RTP profile for the AL-FEC 230 protocol since in the new profile, several of the issues could easily 231 be addressed without jeopardizing the compliance to RTP [RFC3550]. 233 At the writing of this document, it was not clear whether or not a 234 new RTP profile would be defined for the AL-FEC protocol. DVB 235 attempted to address some of the issues in the updated specification 236 [DVB-A086r7], however, there are still outstanding issues. Note that 237 [DVB-A086r7] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB will 238 exclusively use [DVB-A086r7] for any future revisions of the DVB IPTV 239 Handbook. 241 The following is a list of the exceptions that MUST be considered by 242 an implementation adopting [I-D.ietf-fecframe-interleaved-fec-scheme] 243 to be in compliant with the AL-FEC protocol as specified in 244 [DVB-A086r7]. 246 o SSRC 247 In the DVB AL-FEC protocol, the SSRC fields of the FEC packets 248 MUST be set to 0. 250 This requirement conflicts with RTP [RFC3550]. Unless signaled 251 otherwise, RTP uses random SSRC values with collision detection. 252 An explicit SSRC signaling mechanism is currently defined in 253 [RFC5576]. It is RECOMMENDED that the DVB AL-FEC protocol uses 254 this mechanism for explicit SSRC signaling. 256 o CSRC 257 The DVB AL-FEC protocol does not support the protection of the 258 CSRC entries in the source packets. Thus, the source stream MUST 259 NOT have any CSRC entries in its packets and the CC fields of the 260 source RTP packets MUST be zero. 262 Note that if there are no RTP mixers used in a system running the 263 DVB AL-FEC protocol, the CC field of the source RTP packets will 264 be 0 and this is no longer an issue. Thus, if defined, the new 265 RTP profile for the AL-FEC protocol SHOULD forbid the use of any 266 RTP mixers. 268 o Timestamp 269 In the DVB AL-FEC protocol, the timestamp fields of the FEC 270 packets SHALL be ignored by the receivers. 272 o Payload Type 273 In the DVB AL-FEC protocol, the PT fields of the FEC packets MUST 274 be set to 96. 276 A static payload type assignment for the base-layer FEC packets is 277 outside the scope of [I-D.ietf-fecframe-interleaved-fec-scheme]. 278 If defined, the new RTP profile for the AL-FEC protocol MAY assign 279 96 as the payload type for the base-layer FEC packets. 281 In implementations that are based on 282 [I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in 283 compliant with the AL-FEC protocol as specified in 284 [ETSI-TS-102-034v1.3.1], all these exceptions MUST be considered as 285 well, however, in this case, the sender does not have to select a 286 random initial sequence number for the FEC stream as suggested by 287 [RFC3550]. 289 Note that neither [ETSI-TS-102-034v1.3.1] nor [DVB-A086r7] implements 290 the 1-D interleaved parity code as specified in 291 [I-D.ietf-fecframe-interleaved-fec-scheme]. Thus, the payload format 292 registered in [I-D.ietf-fecframe-interleaved-fec-scheme] MUST NOT be 293 used by the implementations that are compliant with the 294 [ETSI-TS-102-034v1.3.1] or [DVB-A086r7] specification. 296 3.2. Enhancement-Layer FEC 298 The Raptor code is a fountain code where as many encoding symbols as 299 needed can be generated by the encoder on-the-fly from source data. 300 Due to the fountain property of the Raptor code, multiple enhancement 301 layers may also be specified, if needed. 303 The details of the Raptor code are provided in 304 [I-D.ietf-fecframe-raptor]. The RTP payload format for Raptor FEC is 305 specified in [I-D.watson-fecframe-rtp-raptor]. 307 It is important to note that the DVB AL-FEC protocol in the latest 308 specification [DVB-A086r7] allows only RTP-over-UDP encapsulation for 309 the enhancement-layer FEC stream. The initial specification 310 [ETSI-TS-102-034v1.3.1] exclusively permits UDP-only encapsulation 311 for the enhancement-layer FEC stream. 313 When SDP is used for signaling, the transport protocol identifier 314 permits to distinguish whether an RTP-over-UDP or UDP-only 315 encapsulation is used. In case of any other signaling framework, the 316 differentiation of the protocol for the enhancement-layer stream is 317 achieved either explicitly through a protocol identifier or 318 implicitly by the version number of the DVB IPTV Handbook. If none 319 of the above signaling is provided, the receiver shall concur from 320 the packet size of the repair packets if RTP-over-UDP or UDP-only 321 encapsulation is used. 323 3.3. Hybrid Decoding Procedures 325 The receivers that support receiving and decoding both the base and 326 enhancement-layer FEC perform hybrid decoding to improve the repair 327 performance. The following steps may be followed to perform hybrid 328 decoding: 330 1. Base-layer (Parity) Decoding: In this step, the repair packets 331 that are encoded by the parity encoder are processed as usual to 332 repair as many missing source packets as possible. 334 2. Enhancement-layer (Raptor) Decoding: If there are still missing 335 source packets after the first step, the repair packets that are 336 Raptor encoded are processed with the source packets already 337 received and the source packets that are recovered in the first 338 step. 340 3. Hybrid Decoding: If there are still missing source packets after 341 the second step, the unprocessed base-layer (parity) repair 342 packets are converted to a form in which they can be added to the 343 Raptor decoding process. With this additional information, 344 Raptor decoding may potentially recover any remaining missing 345 source packet. 347 The procedure that should be followed to benefit from the base-layer 348 repair packets in the Raptor decoding process is explained in detail 349 in Section E.5.2 of [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 351 4. Session Description Protocol (SDP) Signaling 353 This section provides an SDP [RFC4566] example for [DVB-A086r7]. The 354 example uses the FEC grouping semantics [RFC4756]. 356 In the example, we have one source video stream (mid:S1), one FEC 357 repair stream (mid:R1) that is produced by the 1-D interleaved parity 358 FEC code as well as another FEC repair stream (mid:R2) that is 359 produced by the Raptor FEC code. We form one FEC group with the 360 "a=group:FEC S1 R1 R2" line. The source and repair streams are sent 361 to the same port on different multicast groups. The source, base- 362 layer FEC and enhancement-layer FEC streams are all encapsulated in 363 RTP. 365 Due to the exceptions described in Section 3.1, a [DVB-A086r7]- 366 compliant implementation MUST NOT use the RTP payload format defined 367 in [I-D.ietf-fecframe-interleaved-fec-scheme]. Instead, it may use 368 the payload format that has been registered by DVB IPI for 369 [ETSI-TS-102-034v1.3.1]. 371 v=0 372 o=ali 1122334455 1122334466 IN IP4 fec.example.com 373 s=DVB AL-FEC Example 374 t=0 0 375 a=group:FEC S1 R1 R2 376 m=video 30000 RTP/AVP 100 377 c=IN IP4 233.252.0.1/127 378 a=rtpmap:100 MP2T/90000 379 a=mid:S1 380 m=application 30000 RTP/AVP 96 381 c=IN IP4 233.252.0.2/127 382 a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000 383 a=mid:R1 384 m=application 30000 RTP/AVP 111 385 c=IN IP4 233.252.0.3/127 386 a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000 387 a=mid:R2 389 Note that in the example above, the payload type has been chosen as 390 96 for the base-layer FEC stream and there is no "a=fmtp:" line to 391 specify the format parameters. Due to the lack of the format 392 parameters, it is not possible to learn the FEC parameters from the 393 SDP description. This severely limits the ability of using multiple 394 FEC streams that are generated with different settings. 396 5. Security Considerations 398 There are no security considerations in this document. 400 6. IANA Considerations 402 There are no IANA considerations in this document. 404 7. Acknowledgments 406 This document is based on [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 407 Thus, the authors would like to thank the editors of 408 [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 410 8. References 412 8.1. Normative References 414 [ETSI-TS-102-034v1.3.1] 415 ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB 416 Services over IP Based Networks", October 2007. 418 [DVB-A086r7] 419 DVB Document A086 Rev. 7 (Draft ETSI TS 102 034 V1.4.1), 420 "Transport of MPEG 2 TS Based DVB Services over IP Based 421 Networks", September 2008. 423 [I-D.ietf-fecframe-interleaved-fec-scheme] 424 Begen, A., "RTP Payload Format for 1-D Interleaved Parity 425 FEC", draft-ietf-fecframe-interleaved-fec-scheme-05 (work 426 in progress), May 2009. 428 [I-D.ietf-fecframe-raptor] 429 Watson, M., "Raptor FEC Schemes for FECFRAME", 430 draft-ietf-fecframe-raptor-01 (work in progress), 431 July 2009. 433 [I-D.watson-fecframe-rtp-raptor] 434 Watson, M., "RTP Payload Format for Raptor FEC", 435 draft-watson-fecframe-rtp-raptor-00 (work in progress), 436 October 2008. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 442 Jacobson, "RTP: A Transport Protocol for Real-Time 443 Applications", STD 64, RFC 3550, July 2003. 445 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 446 Media Attributes in the Session Description Protocol 447 (SDP)", RFC 5576, June 2009. 449 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 450 Description Protocol", RFC 4566, July 2006. 452 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 453 Session Description Protocol", RFC 4756, November 2006. 455 8.2. Informative References 457 [DVB-A115] 458 Available at: http://www.dvb.org/technology/standards/ 459 a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer 460 FEC Evaluations (DVB Document A115)", May 2007. 462 [SMPTE2022-1] 463 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 464 Video/Audio Transport over IP Networks", 2007. 466 Authors' Addresses 468 Ali Begen 469 Cisco Systems 470 170 West Tasman Drive 471 San Jose, CA 95134 472 USA 474 Email: abegen@cisco.com 476 Thomas Stockhammer 477 Nomor Research 478 Brecherspitzstrasse 8 479 Munich, 81541 480 Germany 482 Email: stockhammer@nomor.de