idnits 2.17.1 draft-ietf-fecframe-dvb-al-fec-01.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 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 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 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 27, 2009) is 5567 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-01 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-raptor-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 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: July 31, 2009 Digital Fountain 6 January 27, 2009 8 DVB Application-Layer Hybrid FEC Protection 9 draft-ietf-fecframe-dvb-al-fec-01 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 July 31, 2009. 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document describes the Application-layer Forward Error 49 Correction (FEC) protocol that was developed by the Digital Video 50 Broadcasting (DVB) consortium for the protection of media streams 51 over IP networks. The DVB AL-FEC protocol uses two layers for FEC 52 protection. The first (base) layer is based on the 1-D interleaved 53 parity code. The second (enhancement) layer is based on the Raptor 54 code. By offering a layered approach, the DVB AL-FEC offers a good 55 protection against both bursty and random packet losses at a cost of 56 decent complexity. The 1-D interleaved parity code and Raptor code 57 have already been specified in separate documents and the current 58 document normatively references these specifications. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 64 3. DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . . 5 65 3.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7 67 3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8 68 4. Session Description Protocol (SDP) Signaling . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 In 2007, the Digital Video Broadcasting (DVB) consortium published a 80 technical specification [ETSI-TS-102-034v1.3.1] through European 81 Telecommunications Standards Institute (ETSI). This specification 82 covers several areas related to the transmission of MPEG2 transport 83 stream-based services over IP networks. 85 The Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol 86 for Application-layer Forward Error Correction (AL-FEC) to protect 87 the streaming media for DVB-IP services carried over RTP [RFC3550] 88 transport. In 2008, DVB updated the specification in a new revision 89 that has been published as a DVB Bluebook [DVB-A086r7] and serves as 90 draft ETSI TS-102-034v1.4.1 until the final ETSI publication 91 (expected in early 2009). Among others, some updates and 92 modifications to the AL-FEC protocol have been made. 94 The DVB AL-FEC protocol uses two layers for protection: a base layer 95 that is produced by the 1-D interleaved parity code, and an 96 enhancement layer that is produced by the Raptor code. Whenever a 97 receiver supports the DVB AL-FEC protocol, the decoding support for 98 the base-layer FEC is mandatory while the decoding support for the 99 enhancement-layer FEC is optional. Both the interleaved parity code 100 and the Raptor code are systematic FEC codes, meaning that source 101 packets are not modified in any way during the FEC encoding process. 103 The normative DVB AL-FEC protocol considers protection of single- 104 sequence source RTP flows only. The source can be any type of media 105 such as audio, video, text or application. However, in the AL-FEC 106 protocol, the source stream can only be an MPEG-2 transport stream. 107 The FEC data at each layer are generated based on some configuration 108 information, which also determines the exact associations and 109 relationships between the source and repair packets. This document 110 shows how this configuration may be communicated out-of-band in the 111 Session Description Protocol (SDP) [RFC4566]. 113 In DVB AL-FEC, the source packets are carried in the source RTP 114 stream and the generated FEC repair packets at each layer are carried 115 in separate streams. At the receiver side, if all of the source 116 packets are successfully received, there is no need for FEC recovery 117 and the repair packets may be discarded. However, if there are 118 missing source packets, the repair packets can be used to recover the 119 missing information. 121 The block diagram of the encoder side for the systematic DVB AL-FEC 122 protection is sketched in Figure 1. Here, the source packets are fed 123 into the parity encoder to produce the parity repair packets. The 124 source packets may also be fed to the Raptor encoder to produce the 125 Raptor repair packets. Source packets as well as the repair packets 126 are then sent to the receiver(s) over an IP network. 128 +--------------+ 129 +--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 130 +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 131 +--------------+ 132 | Parity | -> +==+ +==+ +==+ 133 | Encoder | +==+ +==+ +==+ 134 +--------------+ 135 | Raptor | -> +~~+ +~~+ 136 | Encoder | +~~+ +~~+ 137 +--------------+ 139 Source Packet: +--+ 140 +--+ 142 Base-layer Repair Packet: +==+ 143 +==+ 145 Enhancement-layer Repair Packet: +~~+ 146 +~~+ 148 Figure 1: Block diagram for the DVB AL-FEC encoder 150 The block diagram of the decoder side for the systematic DVB AL-FEC 151 protection is sketched in Figure 2. This is a Minimum Performance 152 Decoder since the receiver only supports decoding the base-layer 153 repair packets. If there is a loss among the source packets, the 154 parity decoder attempts to recover the missing source packets by 155 using the base-layer repair packets. 157 +--------------+ 158 +--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 159 +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 160 +--------------+ 161 +==+ +==+ +==+ --> | Parity | 162 +==+ +==+ +==+ | Decoder | 163 +--------------+ 165 Lost Packet: X 167 Figure 2: Block diagram for the DVB AL-FEC minimum performance 168 decoder 170 On the other hand, if the receiver supports decoding both the base- 171 layer and enhancement-layer repair packets, a combined (hybrid) 172 decoding approach is employed to improve the recovery rate of the 173 lost packets. In this case, the decoder is called an Enhanced 174 Decoder. Section 3.3 outlines the procedures for hybrid decoding. 176 +--------------+ 177 +--+ X X X --> | Systematic | -> +--+ +--+ +--+ +--+ 178 +--+ |FEC Protection| +--+ +--+ +--+ +--+ 179 +--------------+ 180 +==+ +==+ +==+ --> | Parity | 181 +==+ +==+ +==+ | Decoder | 182 +--------------+ 183 +~~+ +~~+ --> | Raptor | 184 +~~+ +~~+ | Decoder | 185 +--------------+ 187 Lost Packet: X 189 Figure 3: Block diagram for the DVB AL-FEC enhanced decoder 191 2. Requirements Notation 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 3. DVB AL-FEC Specification 199 The DVB AL-FEC protocol comprises two layers of FEC protection: 1-D 200 interleaved parity FEC for the base layer and Raptor FEC for the 201 enhancement layer. The performance of these FEC codes has been 202 examined in detail in [DVB-A115]. 204 3.1. Base-Layer FEC 206 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 207 to generate the repair symbols. In a group of D x L source packets, 208 the XOR operation is applied to the group of the source packets whose 209 sequence numbers are L apart from each other to generate L repair 210 packets. Due to interleaving, this FEC is effective against bursty 211 packet losses up to burst sizes of length L. 213 The DVB AL-FEC protocol requires the D x L block of the source 214 packets protected by the 1-D interleaved FEC code to be wholly 215 contained within a single source block of the Raptor code, if both 216 FEC layers are used. 218 Originally, the DVB AL-FEC protocol had adopted the 1-D interleaved 219 FEC payload format from [SMPTE2022-1] in [ETSI-TS-102-034v1.3.1]. 220 However, some incompatibilities with RTP [RFC3550] have been 221 discovered in this specification. These issues have all been 222 addressed in [I-D.ietf-fecframe-interleaved-fec-scheme] (For details, 223 refer to Section 1 of [I-D.ietf-fecframe-interleaved-fec-scheme]). 224 Some of the changes required by 225 [I-D.ietf-fecframe-interleaved-fec-scheme] are, however, not backward 226 compatible with the existing implementations that were based on 227 [SMPTE2022-1]. 229 In a recent liaison from IETF AVT WG to DVB IPI, it has been 230 recommended that DVB IPI defines a new RTP profile for the AL-FEC 231 protocol since in the new profile, several of the issues could easily 232 be addressed without jeopardizing the compliance to RTP [RFC3550]. 234 At the writing of this document, it was not clear whether or not a 235 new RTP profile would be defined for the AL-FEC protocol. DVB 236 attempted to address some of the issues in the updated specification 237 [DVB-A086r7], however, there are still outstanding issues. Note that 238 [DVB-A086r7] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB will 239 exclusively use [DVB-A086r7] for any future revisions of the DVB IPTV 240 Handbook. 242 The following is a list of the exceptions that MUST be considered by 243 an implementation adopting [I-D.ietf-fecframe-interleaved-fec-scheme] 244 to be in compliant with the AL-FEC protocol as specified in 245 [DVB-A086r7]. 247 o SSRC 248 In the DVB AL-FEC protocol, the SSRC fields of the FEC packets 249 MUST be set to 0. 251 This requirement conflicts with RTP [RFC3550]. Unless signaled 252 otherwise, RTP uses random SSRC values with collision detection. 253 An explicit SSRC signaling mechanism is currently defined in 254 [I-D.ietf-mmusic-sdp-source-attributes]. It is RECOMMENDED that 255 the DVB AL-FEC protocol uses this mechanism for explicit SSRC 256 signaling. 258 o CSRC 259 The DVB AL-FEC protocol does not support the protection of the 260 CSRC entries in the source packets. Thus, the source stream MUST 261 NOT have any CSRC entries in its packets and the CC fields of the 262 source RTP packets MUST be zero. 264 Note that if there are no RTP mixers used in a system running the 265 DVB AL-FEC protocol, the CC field of the source RTP packets will 266 be 0 and this is no longer an issue. Thus, if defined, the new 267 RTP profile for the AL-FEC protocol SHOULD forbid the use of any 268 RTP mixers. 270 o Timestamp 271 In the DVB AL-FEC protocol, the timestamp fields of the FEC 272 packets SHALL be ignored by the receivers. 274 o Payload Type 275 In the DVB AL-FEC protocol, the PT fields of the FEC packets MUST 276 be set to 96. 278 A static payload type assignment for the base-layer FEC packets is 279 outside the scope of [I-D.ietf-fecframe-interleaved-fec-scheme]. 280 If defined, the new RTP profile for the AL-FEC protocol MAY assign 281 96 as the payload type for the base-layer FEC packets. 283 In implementations that are based on 284 [I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in 285 compliant with the AL-FEC protocol as specified in 286 [ETSI-TS-102-034v1.3.1], all these exceptions MUST be considered as 287 well, however, in this case, the sender does not have to select a 288 random initial sequence number for the FEC stream as suggested by 289 [RFC3550]. 291 Note that neither [ETSI-TS-102-034v1.3.1] nor [DVB-A086r7] implements 292 the 1-D interleaved parity code as specified in 293 [I-D.ietf-fecframe-interleaved-fec-scheme]. Thus, the payload format 294 registered in [I-D.ietf-fecframe-interleaved-fec-scheme] MUST NOT be 295 used by the implementations that are compliant with the 296 [ETSI-TS-102-034v1.3.1] or [DVB-A086r7] specification. 298 3.2. Enhancement-Layer FEC 300 The Raptor code is a fountain code where as many encoding symbols as 301 needed can be generated by the encoder on-the-fly from source data. 302 Due to the fountain property of the Raptor code, multiple enhancement 303 layers may also be specified, if needed. 305 The details of the Raptor code are provided in 306 [I-D.ietf-fecframe-raptor]. The RTP payload format for Raptor FEC is 307 specified in [I-D.watson-fecframe-rtp-raptor]. 309 It is important to note that the DVB AL-FEC protocol in the latest 310 specification [DVB-A086r7] allows only RTP-over-UDP encapsulation for 311 the enhancement-layer FEC stream. The initial specification 313 [ETSI-TS-102-034v1.3.1] exclusively permits UDP-only encapsulation 314 for the enhancement-layer FEC stream. 316 When SDP is used for signaling, the transport protocol identifier 317 permits to distinguish whether an RTP-over-UDP or UDP-only 318 encapsulation is used. In case of any other signaling framework, the 319 differentiation of the protocol for the enhancement-layer stream is 320 achieved either explicitly through a protocol identifier or 321 implicitly by the version number of the DVB IPTV Handbook. If none 322 of the above signaling is provided, the receiver shall concur from 323 the packet size of the repair packets if RTP-over-UDP or UDP-only 324 encapsulation is used. 326 3.3. Hybrid Decoding Procedures 328 The receivers that support receiving and decoding both the base and 329 enhancement-layer FEC perform hybrid decoding to improve the repair 330 performance. The following steps may be followed to perform hybrid 331 decoding: 333 1. Base-layer (Parity) Decoding: In this step, the repair packets 334 that are encoded by the parity encoder are processed as usual to 335 repair as many missing source packets as possible. 337 2. Enhancement-layer (Raptor) Decoding: If there are still missing 338 source packets after the first step, the repair packets that are 339 Raptor encoded are processed with the source packets already 340 received and the source packets that are recovered in the first 341 step. 343 3. Hybrid Decoding: If there are still missing source packets after 344 the second step, the unprocessed base-layer (parity) repair 345 packets are converted to a form in which they can be added to the 346 Raptor decoding process. With this additional information, 347 Raptor decoding may potentially recover any remaining missing 348 source packet. 350 The procedure that should be followed to benefit from the base-layer 351 repair packets in the Raptor decoding process is explained in detail 352 in Section E.5.2 of [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 354 4. Session Description Protocol (SDP) Signaling 356 This section provides an SDP [RFC4566] example for [DVB-A086r7]. The 357 example uses the FEC grouping semantics [RFC4756]. 359 In the example, we have one source video stream (mid:S1), one FEC 360 repair stream (mid:R1) that is produced by the 1-D interleaved parity 361 FEC code as well as another FEC repair stream (mid:R2) that is 362 produced by the Raptor FEC code. We form one FEC group with the 363 "a=group:FEC S1 R1 R2" line. The source and repair streams are sent 364 to the same port on different multicast groups. The source, base- 365 layer FEC and enhancement-layer FEC streams are all encapsulated in 366 RTP. 368 Due to the exceptions described in Section 3.1, a [DVB-A086r7]- 369 compliant implementation MUST NOT use the RTP payload format defined 370 in [I-D.ietf-fecframe-interleaved-fec-scheme]. Instead, it may use 371 the payload format that has been registered by DVB IPI for 372 [ETSI-TS-102-034v1.3.1]. 374 v=0 375 o=ali 1122334455 1122334466 IN IP4 fec.example.com 376 s=DVB AL-FEC Example 377 t=0 0 378 a=group:FEC S1 R1 R2 379 m=video 30000 RTP/AVP 100 380 c=IN IP4 224.1.1.1/127 381 a=rtpmap:100 MP2T/90000 382 a=mid:S1 383 m=application 30000 RTP/AVP 96 384 c=IN IP4 224.1.2.1/127 385 a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000 386 a=mid:R1 387 m=application 30000 RTP/AVP 111 388 c=IN IP4 224.1.2.2/127 389 a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000 390 a=mid:R2 392 Note that in the example above, the payload type has been chosen as 393 96 for the base-layer FEC stream and there is no "a=fmtp:" line to 394 specify the format parameters. Due to the lack of the format 395 parameters, it is not possible to learn the FEC parameters from the 396 SDP description. This severely limits the ability of using multiple 397 FEC streams that are generated with different settings. 399 5. Security Considerations 401 There are no security considerations in this document. 403 6. IANA Considerations 405 There are no IANA considerations in this document. 407 7. Acknowledgments 409 This document is based on [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 410 Thus, the authors would like to thank the editors of 411 [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 413 8. References 415 8.1. Normative References 417 [ETSI-TS-102-034v1.3.1] 418 ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB 419 Services over IP Based Networks", October 2007. 421 [DVB-A086r7] 422 DVB Document A086 Rev. 7 (Draft ETSI TS 102 034 V1.4.1), 423 "Transport of MPEG 2 TS Based DVB Services over IP Based 424 Networks", September 2008. 426 [I-D.ietf-fecframe-interleaved-fec-scheme] 427 Begen, A., "RTP Payload Format for 1-D Interleaved Parity 428 FEC", draft-ietf-fecframe-interleaved-fec-scheme-01 (work 429 in progress), October 2008. 431 [I-D.ietf-fecframe-raptor] 432 Watson, M., "Raptor FEC Schemes for FECFRAME", 433 draft-ietf-fecframe-raptor-00 (work in progress), 434 October 2008. 436 [I-D.watson-fecframe-rtp-raptor] 437 Watson, M., "RTP Payload Format for Raptor FEC", 438 draft-watson-fecframe-rtp-raptor-00 (work in progress), 439 October 2008. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 445 Jacobson, "RTP: A Transport Protocol for Real-Time 446 Applications", STD 64, RFC 3550, July 2003. 448 [I-D.ietf-mmusic-sdp-source-attributes] 449 Lennox, J., Ott, J., and T. Schierl, "Source-Specific 450 Media Attributes in the Session Description Protocol 451 (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work 452 in progress), October 2008. 454 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 455 Description Protocol", RFC 4566, July 2006. 457 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 458 Session Description Protocol", RFC 4756, November 2006. 460 8.2. Informative References 462 [DVB-A115] 463 Available at: http://www.dvb.org/technology/standards/ 464 a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer 465 FEC Evaluations (DVB Document A115)", May 2007. 467 [SMPTE2022-1] 468 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 469 Video/Audio Transport over IP Networks", 2007. 471 Authors' Addresses 473 Ali Begen 474 Cisco Systems 475 170 West Tasman Drive 476 San Jose, CA 95134 477 USA 479 Email: abegen@cisco.com 481 Thomas Stockhammer 482 Digital Fountain 483 39141 Civic Center Drive 484 Suite 300 485 Fremont, CA 94538 486 USA 488 Email: stockhammer@digitalfountain.com