idnits 2.17.1 draft-ietf-fecframe-dvb-al-fec-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 : ---------------------------------------------------------------------------- == 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 (September 16, 2009) is 5336 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) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-rfc4756bis-02 Summary: 2 errors (**), 0 flaws (~~), 5 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: March 20, 2010 Nomor Research 6 September 16, 2009 8 DVB-IPTV Application-Layer Hybrid FEC Protection 9 draft-ietf-fecframe-dvb-al-fec-03 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 March 20, 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 The Annex E of the DVB-IPTV technical specification defines an 48 optional Application-layer Forward Error Correction (AL-FEC) protocol 49 to protect the streaming media carried over RTP transport. The DVB- 50 IPTV AL-FEC protocol uses two layers for FEC protection. The first 51 (base) layer is based on the 1-D interleaved parity code. The second 52 (enhancement) layer is based on the Raptor code. By offering a 53 layered approach, the DVB-IPTV AL-FEC protocol offers a good 54 protection against both bursty and random packet losses at a cost of 55 decent complexity. This document describes how one can implement the 56 DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and 57 Raptor code that have already been specified in separate documents. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. DVB-IPTV AL-FEC Specification . . . . . . . . . . . . . . . . 5 63 2.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7 65 2.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8 66 3. Session Description Protocol (SDP) Signaling . . . . . . . . . 8 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the 78 Digital Video Broadcasting (DVB) consortium published a technical 79 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 2009, DVB updated the specification in a new revision 88 that has been published as a DVB Bluebook [DVB-A086r8] and serves as 89 draft ETSI TS-102-034v1.4.1 until the final ETSI publication 90 (expected late 2009). Among others, some updates and modifications 91 to the AL-FEC protocol have been made. 93 The DVB-IPTV AL-FEC protocol uses two layers for protection: a base 94 layer that is produced by the 1-D interleaved parity code (also 95 simply referred to as parity code in the remainder of this document), 96 and an enhancement layer that is produced by the Raptor code. 97 Whenever a receiver supports the DVB-IPTV AL-FEC protocol, the 98 decoding support for the base-layer FEC is mandatory while the 99 decoding support for the enhancement-layer FEC is optional. Both the 100 interleaved parity code and the Raptor code are systematic FEC codes, 101 meaning that source packets are not modified in any way during the 102 FEC encoding process. 104 The normative DVB-IPTV AL-FEC protocol considers protection of 105 single-sequence source RTP flows only. In the AL-FEC protocol, the 106 source stream can only be an MPEG-2 transport stream. The FEC data 107 at each layer are generated based on some configuration information, 108 which also determines the exact associations and relationships 109 between the source and repair packets. This document shows how this 110 configuration may be communicated out-of-band in the Session 111 Description Protocol (SDP) [RFC4566]. 113 In DVB-IPTV 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-IPTV AL- 122 FEC protection is sketched in Figure 1. Here, the source packets are 123 fed into the parity encoder to produce the parity repair packets. 124 The source packets may also be fed to the Raptor encoder to produce 125 the Raptor repair packets. Source packets as well as the repair 126 packets 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-IPTV AL-FEC encoder 150 The block diagram of the decoder side for the systematic DVB-IPTV AL- 151 FEC protection is sketched in Figure 2. This is a Minimum 152 Performance Decoder since the receiver only supports decoding the 153 base-layer repair packets. If there is a loss among the source 154 packets, the parity decoder attempts to recover the missing source 155 packets by 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-IPTV 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 2.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-IPTV AL-FEC enhanced decoder 191 2. DVB-IPTV AL-FEC Specification 193 The DVB-IPTV AL-FEC protocol comprises two layers of FEC protection: 194 1-D interleaved parity FEC for the base layer and Raptor FEC for the 195 enhancement layer. The performance of these FEC codes has been 196 examined in detail in [DVB-A115]. 198 2.1. Base-Layer FEC 200 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 201 to generate the repair symbols. In a group of D x L source packets, 202 the XOR operation is applied to each group of D source packets whose 203 sequence numbers are L apart from each other to generate a total of L 204 repair packets. Due to interleaving, this FEC is effective against 205 bursty packet losses up to burst sizes of length L. 207 The DVB-IPTV AL-FEC protocol requires the D x L block of the source 208 packets protected by the 1-D interleaved FEC code to be wholly 209 contained within a single source block of the Raptor code, if both 210 FEC layers are used. 212 Originally, the DVB-IPTV AL-FEC protocol had adopted the 1-D 213 interleaved FEC payload format from [SMPTE2022-1] in 214 [ETSI-TS-102-034v1.3.1]. However, some incompatibilities with RTP 215 [RFC3550] have been discovered in this specification. These issues 216 have all been addressed in [I-D.ietf-fecframe-interleaved-fec-scheme] 217 (For details, refer to Section 1 of 218 [I-D.ietf-fecframe-interleaved-fec-scheme]). Some of the changes 219 required by [I-D.ietf-fecframe-interleaved-fec-scheme] are, however, 220 not backward compatible with the existing implementations that were 221 based on [SMPTE2022-1]. 223 In a recent liaison from IETF AVT WG to DVB TM-IPI, it has been 224 recommended that DVB TM-IPI defines a new RTP profile for the AL-FEC 225 protocol since in the new profile, several of the issues could easily 226 be addressed without jeopardizing the compliance to RTP [RFC3550]. 228 At the writing of this document, it was not clear whether or not a 229 new RTP profile would be defined for the AL-FEC protocol. DVB TM-IPI 230 attempted to address some of the issues in the updated specification 231 [DVB-A086r8], however, there are still outstanding issues. Note that 232 [DVB-A086r8] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB TM-IPI 233 will exclusively use [DVB-A086r8] for any future revisions of the DVB 234 IPTV Handbook. 236 The following is a list of the exceptions that need to be considered 237 by an implementation adopting 238 [I-D.ietf-fecframe-interleaved-fec-scheme] to be in compliant with 239 the DVB-IPTV AL-FEC protocol as specified in [DVB-A086r8]. 241 o SSRC 242 The DVB-IPTV AL-FEC protocol requires the SSRC fields of the FEC 243 packets to be set to zero. 245 This requirement conflicts with RTP [RFC3550]. Unless signaled 246 otherwise, RTP uses random SSRC values with collision detection. 247 An explicit SSRC signaling mechanism is currently defined in 248 [RFC5576] and can be used for this purpose. 250 o CSRC 251 The DVB-IPTV AL-FEC protocol does not support the protection of 252 the CSRC entries in the source packets. Thus, in an 253 implementation compliant to DVB-IPTV AL-FEC protocol, the source 254 stream must not have any CSRC entries in its packets and 255 subsequently the CC fields of the source RTP packets will be zero. 257 Note that if there are no RTP mixers used in a system running the 258 DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets 259 will be zero and this is no longer an issue. Thus, if defined, 260 the new RTP profile for the DVB-IPTV AL-FEC protocol should forbid 261 the use of any RTP mixers. 263 o Timestamp 264 In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC 265 packets are ignored by the receivers. 267 o Payload Type 268 The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets 269 to 96. 271 A static payload type assignment for the base-layer FEC packets is 272 outside the scope of [I-D.ietf-fecframe-interleaved-fec-scheme]. 273 If defined, the new RTP profile for the DVB-IPTV AL-FEC protocol 274 may assign 96 as the payload type for the base-layer FEC packets. 276 In implementations that are based on 277 [I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in 278 compliant with the DVB-IPTV AL-FEC protocol as specified in 279 [ETSI-TS-102-034v1.3.1], all these exceptions must be considered as 280 well, however, in this case, the sender does not have to select a 281 random initial sequence number for the FEC stream as suggested by 282 [RFC3550]. 284 Note that neither [ETSI-TS-102-034v1.3.1] nor [DVB-A086r8] implements 285 the 1-D interleaved parity code as specified in 286 [I-D.ietf-fecframe-interleaved-fec-scheme]. Thus, the payload format 287 registered in [I-D.ietf-fecframe-interleaved-fec-scheme] must not be 288 used by the implementations that are compliant with the 289 [ETSI-TS-102-034v1.3.1] or [DVB-A086r8] specification. 291 2.2. Enhancement-Layer FEC 293 The Raptor code is a fountain code where as many encoding symbols as 294 needed can be generated by the encoder on-the-fly from source data. 295 Due to the fountain property of the Raptor code, multiple enhancement 296 layers may also be specified, if needed. 298 The details of the Raptor code are provided in 299 [I-D.ietf-fecframe-raptor]. The RTP payload format for Raptor FEC is 300 specified in [I-D.watson-fecframe-rtp-raptor]. 302 It is important to note that the DVB-IPTV AL-FEC protocol in the 303 latest specification [DVB-A086r8] allows only RTP-over-UDP 304 encapsulation for the enhancement-layer FEC stream. The initial 305 specification [ETSI-TS-102-034v1.3.1] exclusively permits UDP-only 306 encapsulation for the enhancement-layer FEC stream. 308 When SDP is used for signaling, the transport protocol identifier 309 permits to distinguish whether an RTP-over-UDP or UDP-only 310 encapsulation is used. In case of any other signaling framework, the 311 differentiation of the protocol for the enhancement-layer stream is 312 achieved either explicitly through a protocol identifier or 313 implicitly by the version number of the DVB IPTV Handbook. If none 314 of the above signaling is provided, the receiver shall concur from 315 the packet size of the repair packets if RTP-over-UDP or UDP-only 316 encapsulation is used. 318 2.3. Hybrid Decoding Procedures 320 The receivers that support receiving and decoding both the base and 321 enhancement-layer FEC perform hybrid decoding to improve the repair 322 performance. The following steps may be followed to perform hybrid 323 decoding: 325 1. Base-layer (Parity) Decoding: In this step, the repair packets 326 that are encoded by the parity encoder are processed as usual to 327 repair as many missing source packets as possible. 329 2. Enhancement-layer (Raptor) Decoding: If there are still missing 330 source packets after the first step, the repair packets that are 331 Raptor encoded are processed with the source packets already 332 received and the source packets that are recovered in the first 333 step. 335 3. Hybrid Decoding: If there are still missing source packets after 336 the second step, the unprocessed base-layer (parity) repair 337 packets are converted to a form in which they can be added to the 338 Raptor decoding process. With this additional information, 339 Raptor decoding may potentially recover any remaining missing 340 source packet. 342 The procedure that should be followed to benefit from the base-layer 343 repair packets in the Raptor decoding process is explained in detail 344 in Section E.5.2 of [ETSI-TS-102-034v1.3.1] and [DVB-A086r8]. 346 3. Session Description Protocol (SDP) Signaling 348 This section provides an SDP [RFC4566] example for [DVB-A086r8]. The 349 example uses the FEC grouping semantics [I-D.ietf-mmusic-rfc4756bis]. 351 In the example, we have one source video stream (mid:S1), one FEC 352 repair stream (mid:R1) that is produced by the 1-D interleaved parity 353 FEC code as well as another FEC repair stream (mid:R2) that is 354 produced by the Raptor FEC code. We form one FEC group with the 355 "a=group:FEC-XR S1 R1 R2" line. The source and repair streams are 356 sent to the same port on different multicast groups. The source, 357 base-layer FEC and enhancement-layer FEC streams are all encapsulated 358 in RTP. 360 Due to the exceptions described in Section 2.1, a [DVB-A086r8]- 361 compliant implementation must not use the RTP payload format defined 362 in [I-D.ietf-fecframe-interleaved-fec-scheme]. Instead, it may use 363 the payload format that has been registered by DVB TM-IPI for 364 [ETSI-TS-102-034v1.3.1]. 366 v=0 367 o=ali 1122334455 1122334466 IN IP4 fec.example.com 368 s=DVB-IPTV AL-FEC Example 369 t=0 0 370 a=group:FEC-XR S1 R1 R2 371 m=video 30000 RTP/AVP 100 372 c=IN IP4 233.252.0.1/127 373 a=rtpmap:100 MP2T/90000 374 a=mid:S1 375 m=application 30000 RTP/AVP 96 376 c=IN IP4 233.252.0.2/127 377 a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000 378 a=mid:R1 379 m=application 30000 RTP/AVP 111 380 c=IN IP4 233.252.0.3/127 381 a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000 382 a=mid:R2 384 Note that in the example above, the payload type has been chosen as 385 96 for the base-layer FEC stream and there is no "a=fmtp:" line to 386 specify the format parameters. Due to the lack of the format 387 parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn 388 the FEC parameters from the SDP description. 390 4. Security Considerations 392 There are no security considerations in this document. 394 5. IANA Considerations 396 There are no IANA considerations in this document. 398 6. Acknowledgments 400 This document is based on [ETSI-TS-102-034v1.3.1] and [DVB-A086r8]. 401 Thus, the authors would like to thank the editors of 402 [ETSI-TS-102-034v1.3.1] and [DVB-A086r8]. The authors also would 403 like to thank those who reviewed earlier versions of this document. 405 7. References 407 7.1. Normative References 409 [ETSI-TS-102-034v1.3.1] 410 ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB 411 Services over IP Based Networks", October 2007. 413 [DVB-A086r8] 414 DVB Document A086 Rev. 8 (Draft ETSI TS 102 034 V1.4.1), 415 "Transport of MPEG 2 TS Based DVB Services over IP Based 416 Networks", July 2009. 418 [I-D.ietf-fecframe-interleaved-fec-scheme] 419 Begen, A., "RTP Payload Format for 1-D Interleaved Parity 420 FEC", draft-ietf-fecframe-interleaved-fec-scheme-05 (work 421 in progress), May 2009. 423 [I-D.ietf-fecframe-raptor] 424 Watson, M., "Raptor FEC Schemes for FECFRAME", 425 draft-ietf-fecframe-raptor-01 (work in progress), 426 July 2009. 428 [I-D.watson-fecframe-rtp-raptor] 429 Watson, M., "RTP Payload Format for Raptor FEC", 430 draft-watson-fecframe-rtp-raptor-00 (work in progress), 431 October 2008. 433 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 434 Jacobson, "RTP: A Transport Protocol for Real-Time 435 Applications", STD 64, RFC 3550, July 2003. 437 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 438 Media Attributes in the Session Description Protocol 439 (SDP)", RFC 5576, June 2009. 441 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 442 Description Protocol", RFC 4566, July 2006. 444 [I-D.ietf-mmusic-rfc4756bis] 445 Begen, A., "Forward Error Correction Grouping Semantics in 446 Session Description Protocol", 447 draft-ietf-mmusic-rfc4756bis-02 (work in progress), 448 April 2009. 450 7.2. Informative References 452 [DVB-A115] 453 Available at: http://www.dvb.org/technology/standards/ 454 a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer 455 FEC Evaluations (DVB Document A115)", May 2007. 457 [SMPTE2022-1] 458 SMPTE 2022-1-2007, "Forward Error Correction for Real-Time 459 Video/Audio Transport over IP Networks", 2007. 461 Authors' Addresses 463 Ali Begen 464 Cisco Systems 465 170 West Tasman Drive 466 San Jose, CA 95134 467 USA 469 Email: abegen@cisco.com 471 Thomas Stockhammer 472 Nomor Research 473 Brecherspitzstrasse 8 474 Munich, 81541 475 Germany 477 Email: stockhammer@nomor.de