idnits 2.17.1 draft-ietf-fecframe-dvb-al-fec-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (December 15, 2009) is 5244 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-05 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 4 Intended status: Informational T. Stockhammer 5 Expires: June 18, 2010 Nomor Research 6 December 15, 2009 8 Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC 9 Protection 10 draft-ietf-fecframe-dvb-al-fec-04 12 Abstract 14 The Annex E of the Digital Video Broadcasting (DVB)-IPTV technical 15 specification defines an optional Application-layer Forward Error 16 Correction (AL-FEC) protocol to protect the streaming media carried 17 over RTP transport. The DVB-IPTV AL-FEC protocol uses two layers for 18 FEC protection. The first (base) layer is based on the 1-D 19 interleaved parity code. The second (enhancement) layer is based on 20 the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC 21 protocol offers a good protection against both bursty and random 22 packet losses at a cost of decent complexity. This document 23 describes how one can implement the DVB-IPTV AL-FEC protocol by using 24 the 1-D interleaved parity code and Raptor code that have already 25 been specified in separate documents. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on June 18, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. DVB-IPTV AL-FEC Specification . . . . . . . . . . . . . . . . 5 69 2.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7 71 2.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8 72 3. Session Description Protocol (SDP) Signaling . . . . . . . . . 8 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the 84 Digital Video Broadcasting (DVB) consortium published a technical 85 specification [ETSI-TS-102-034v1.3.1] through European 86 Telecommunications Standards Institute (ETSI). 87 [ETSI-TS-102-034v1.3.1] covers several areas related to the 88 transmission of MPEG2 transport stream-based services over IP 89 networks. 91 The Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol 92 for Application-layer Forward Error Correction (AL-FEC) to protect 93 the streaming media for DVB-IP services carried over RTP [RFC3550] 94 transport. In 2009, DVB updated the specification in a new revision 95 that is available as [ETSI-TS-102-034v1.4.1]. Among others, some 96 updates and modifications to the AL-FEC protocol have been made. 97 This document describes how one can implement the DVB-IPTV AL-FEC 98 protocol by using the 1-D interleaved parity code 99 [I-D.ietf-fecframe-interleaved-fec-scheme] and Raptor code 100 specifications [I-D.ietf-fecframe-raptor], 101 [I-D.watson-fecframe-rtp-raptor]. 103 The DVB-IPTV AL-FEC protocol uses two layers for protection: a base 104 layer that is produced by the 1-D interleaved parity code (also 105 simply referred to as parity code in the remainder of this document), 106 and an enhancement layer that is produced by the Raptor code. 107 Whenever a receiver supports the DVB-IPTV AL-FEC protocol, the 108 decoding support for the base-layer FEC is mandatory while the 109 decoding support for the enhancement-layer FEC is optional. Both the 110 interleaved parity code and the Raptor code are systematic FEC codes, 111 meaning that source packets are not modified in any way during the 112 FEC encoding process. 114 The DVB-IPTV AL-FEC protocol considers protection of single-sequence 115 source RTP flows only. In the AL-FEC protocol, the source stream can 116 only be an MPEG-2 transport stream. The FEC data at each layer are 117 generated based on some configuration information, which also 118 determines the exact associations and relationships between the 119 source and repair packets. This document shows how this 120 configuration may be communicated out-of-band in the Session 121 Description Protocol (SDP) [RFC4566]. 123 In DVB-IPTV AL-FEC, the source packets are carried in the source RTP 124 stream and the generated FEC repair packets at each layer are carried 125 in separate streams. At the receiver side, if all of the source 126 packets are successfully received, there is no need for FEC recovery 127 and the repair packets may be discarded. However, if there are 128 missing source packets, the repair packets can be used to recover the 129 missing information. 131 The block diagram of the encoder side for the systematic DVB-IPTV AL- 132 FEC protection is sketched in Figure 1. Here, the source packets are 133 fed into the parity encoder to produce the parity repair packets. 134 The source packets may also be fed to the Raptor encoder to produce 135 the Raptor repair packets. Source packets as well as the repair 136 packets are then sent to the receiver(s) over an IP network. 138 +--------------+ 139 +--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 140 +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 141 +--------------+ 142 | Parity | -> +==+ +==+ +==+ 143 | Encoder | +==+ +==+ +==+ 144 +--------------+ 145 | Raptor | -> +~~+ +~~+ 146 | Encoder | +~~+ +~~+ 147 +--------------+ 149 Source Packet: +--+ 150 +--+ 152 Base-layer Repair Packet: +==+ 153 +==+ 155 Enhancement-layer Repair Packet: +~~+ 156 +~~+ 158 Figure 1: Block diagram for the DVB-IPTV AL-FEC encoder 160 The block diagram of the decoder side for the systematic DVB-IPTV AL- 161 FEC protection is sketched in Figure 2. This is a Minimum 162 Performance Decoder since the receiver only supports decoding the 163 base-layer repair packets. If there is a loss among the source 164 packets, the parity decoder attempts to recover the missing source 165 packets by using the base-layer repair packets. 167 +--------------+ 168 +--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 169 +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 170 +--------------+ 171 +==+ +==+ +==+ --> | Parity | 172 +==+ +==+ +==+ | Decoder | 173 +--------------+ 175 Lost Packet: X 177 Figure 2: Block diagram for the DVB-IPTV AL-FEC minimum performance 178 decoder 180 On the other hand, if the receiver supports decoding both the base- 181 layer and enhancement-layer repair packets, a combined (hybrid) 182 decoding approach is employed to improve the recovery rate of the 183 lost packets. In this case, the decoder is called an Enhanced 184 Decoder. Section 2.3 outlines the procedures for hybrid decoding. 186 +--------------+ 187 +--+ X X X --> | Systematic | -> +--+ +--+ +--+ +--+ 188 +--+ |FEC Protection| +--+ +--+ +--+ +--+ 189 +--------------+ 190 +==+ +==+ +==+ --> | Parity | 191 +==+ +==+ +==+ | Decoder | 192 +--------------+ 193 +~~+ +~~+ --> | Raptor | 194 +~~+ +~~+ | Decoder | 195 +--------------+ 197 Lost Packet: X 199 Figure 3: Block diagram for the DVB-IPTV AL-FEC enhanced decoder 201 2. DVB-IPTV AL-FEC Specification 203 The DVB-IPTV AL-FEC protocol comprises two layers of FEC protection: 204 1-D interleaved parity FEC for the base layer and Raptor FEC for the 205 enhancement layer. The performance of these FEC codes has been 206 examined in detail in [DVB-A115]. 208 2.1. Base-Layer FEC 210 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 211 to generate the repair symbols. In a group of D x L source packets, 212 the XOR operation is applied to each group of D source packets whose 213 sequence numbers are L apart from each other to generate a total of L 214 repair packets. Due to interleaving, this FEC is effective against 215 bursty packet losses up to burst sizes of length L. 217 The DVB-IPTV AL-FEC protocol requires the D x L block of the source 218 packets protected by the 1-D interleaved FEC code to be wholly 219 contained within a single source block of the Raptor code, if both 220 FEC layers are used. 222 Originally, the DVB-IPTV AL-FEC protocol had adopted the 1-D 223 interleaved FEC payload format from [SMPTE2022-1] in 224 [ETSI-TS-102-034v1.3.1]. However, some incompatibilities with RTP 225 [RFC3550] have been discovered in this specification. These issues 226 have all been addressed in [I-D.ietf-fecframe-interleaved-fec-scheme] 227 (For details, refer to Section 1 of 228 [I-D.ietf-fecframe-interleaved-fec-scheme]). Some of the changes 229 required by [I-D.ietf-fecframe-interleaved-fec-scheme] are, however, 230 not backward compatible with the existing implementations that were 231 based on [SMPTE2022-1]. 233 In a recent liaison from IETF AVT WG to DVB TM-IPI, it has been 234 recommended that DVB TM-IPI defines a new RTP profile for the AL-FEC 235 protocol since in the new profile, several of the issues could easily 236 be addressed without jeopardizing the compliance to RTP [RFC3550]. 238 At the writing of this document, it was not clear whether or not a 239 new RTP profile would be defined for the AL-FEC protocol. DVB TM-IPI 240 attempted to address some of the issues in the updated specification 241 [ETSI-TS-102-034v1.4.1], however, there are still outstanding issues. 243 The following is a list of the exceptions that need to be considered 244 by an implementation adopting 245 [I-D.ietf-fecframe-interleaved-fec-scheme] to be in compliant with 246 the DVB-IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.4.1]. 248 o SSRC 249 The DVB-IPTV AL-FEC protocol requires the SSRC fields of the FEC 250 packets to be set to zero. 252 This requirement conflicts with RTP [RFC3550]. Unless signaled 253 otherwise, RTP uses random SSRC values with collision detection. 254 An explicit SSRC signaling mechanism is currently defined in 255 [RFC5576] and can be used for this purpose. 257 o CSRC 258 The DVB-IPTV AL-FEC protocol does not support the protection of 259 the CSRC entries in the source packets. Thus, in an 260 implementation compliant to DVB-IPTV AL-FEC protocol, the source 261 stream must not have any CSRC entries in its packets and 262 subsequently the CC fields of the source RTP packets will be zero. 264 Note that if there are no RTP mixers used in a system running the 265 DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets 266 will be zero and this is no longer an issue. Thus, if defined, 267 the new RTP profile for the DVB-IPTV AL-FEC protocol should forbid 268 the use of any RTP mixers. 270 o Timestamp 271 In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC 272 packets are ignored by the receivers. 274 o Payload Type 275 The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets 276 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 DVB-IPTV AL-FEC protocol 281 may assign 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 DVB-IPTV 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 [ETSI-TS-102-034v1.4.1] 292 implements 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 [ETSI-TS-102-034v1.4.1] specification. 298 2.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-IPTV AL-FEC protocol in the 310 latest specification [ETSI-TS-102-034v1.4.1] allows both UDP-only and 311 RTP-over-UDP encapsulations for the enhancement-layer FEC stream. 312 The initial specification [ETSI-TS-102-034v1.3.1] exclusively permits 313 UDP-only encapsulation for the enhancement-layer FEC stream. 315 When SDP is used for signaling, the transport protocol identifier 316 permits to distinguish whether an RTP-over-UDP or UDP-only 317 encapsulation is used. In case of any other signaling framework, the 318 differentiation of the protocol for the enhancement-layer stream is 319 achieved either explicitly through a protocol identifier or 320 implicitly by the version number of the DVB IPTV Handbook. If none 321 of the above signaling is provided, the receiver shall concur from 322 the packet size of the repair packets if RTP-over-UDP or UDP-only 323 encapsulation is used. 325 2.3. Hybrid Decoding Procedures 327 The receivers that support receiving and decoding both the base and 328 enhancement-layer FEC perform hybrid decoding to improve the repair 329 performance. The following steps may be followed to perform hybrid 330 decoding: 332 1. Base-layer (Parity) Decoding: In this step, the repair packets 333 that are encoded by the parity encoder are processed as usual to 334 repair as many missing source packets as possible. 336 2. Enhancement-layer (Raptor) Decoding: If there are still missing 337 source packets after the first step, the repair packets that are 338 Raptor encoded are processed with the source packets already 339 received and the source packets that are recovered in the first 340 step. 342 3. Hybrid Decoding: If there are still missing source packets after 343 the second step, the unprocessed base-layer (parity) repair 344 packets are converted to a form in which they can be added to the 345 Raptor decoding process. With this additional information, 346 Raptor decoding may potentially recover any remaining missing 347 source packet. 349 The procedure that should be followed to benefit from the base-layer 350 repair packets in the Raptor decoding process is explained in detail 351 in Section E.5.2 of [ETSI-TS-102-034v1.4.1]. 353 3. Session Description Protocol (SDP) Signaling 355 This section provides an SDP [RFC4566] example for 357 [ETSI-TS-102-034v1.4.1]. The example uses the FEC grouping semantics 358 [I-D.ietf-mmusic-rfc4756bis]. 360 In the example, we have one source video stream (mid:S1), one FEC 361 repair stream (mid:R1) that is produced by the 1-D interleaved parity 362 FEC code as well as another FEC repair stream (mid:R2) that is 363 produced by the Raptor FEC code. We form one FEC group with the 364 "a=group:FEC-XR S1 R1 R2" line. The source and repair streams are 365 sent to the same port on different multicast groups. The source, 366 base-layer FEC and enhancement-layer FEC streams are all encapsulated 367 in RTP. 369 Due to the exceptions described in Section 2.1, a 370 [ETSI-TS-102-034v1.4.1]-compliant implementation must not use the RTP 371 payload format defined in [I-D.ietf-fecframe-interleaved-fec-scheme]. 372 Instead, it may use the payload format that has been registered by 373 DVB TM-IPI for [ETSI-TS-102-034v1.3.1]. 375 v=0 376 o=ali 1122334455 1122334466 IN IP4 fec.example.com 377 s=DVB-IPTV AL-FEC Example 378 t=0 0 379 a=group:FEC-XR S1 R1 R2 380 m=video 30000 RTP/AVP 100 381 c=IN IP4 233.252.0.1/127 382 a=rtpmap:100 MP2T/90000 383 a=mid:S1 384 m=application 30000 RTP/AVP 96 385 c=IN IP4 233.252.0.2/127 386 a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000 387 a=mid:R1 388 m=application 30000 RTP/AVP 111 389 c=IN IP4 233.252.0.3/127 390 a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000 391 a=mid:R2 393 Note that in the example above, the payload type has been chosen as 394 96 for the base-layer FEC stream and there is no "a=fmtp:" line to 395 specify the format parameters. Due to the lack of the format 396 parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn 397 the FEC parameters from the SDP description. 399 4. Security Considerations 401 This specification adds no new security considerations to the DVB- 402 IPTV AL-FEC protocol. 404 5. IANA Considerations 406 There are no IANA considerations in this document. 408 6. Acknowledgments 410 This document is based on [ETSI-TS-102-034v1.3.1] and 411 [ETSI-TS-102-034v1.4.1]. Thus, the authors would like to thank the 412 editors of [ETSI-TS-102-034v1.3.1] and [ETSI-TS-102-034v1.4.1]. The 413 authors also would like to thank those who reviewed earlier versions 414 of this document. 416 7. References 418 7.1. Normative References 420 [ETSI-TS-102-034v1.3.1] 421 ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB 422 Services over IP Based Networks", October 2007. 424 [ETSI-TS-102-034v1.4.1] 425 ETSI TS 102 034 V1.4.1, "Transport of MPEG 2 TS Based DVB 426 Services over IP Based Networks", August 2009. 428 [I-D.ietf-fecframe-interleaved-fec-scheme] 429 Begen, A., "RTP Payload Format for 1-D Interleaved Parity 430 FEC", draft-ietf-fecframe-interleaved-fec-scheme-05 (work 431 in progress), May 2009. 433 [I-D.ietf-fecframe-raptor] 434 Watson, M., "Raptor FEC Schemes for FECFRAME", 435 draft-ietf-fecframe-raptor-01 (work in progress), 436 July 2009. 438 [I-D.watson-fecframe-rtp-raptor] 439 Watson, M., "RTP Payload Format for Raptor FEC", 440 draft-watson-fecframe-rtp-raptor-00 (work in progress), 441 October 2008. 443 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 444 Jacobson, "RTP: A Transport Protocol for Real-Time 445 Applications", STD 64, RFC 3550, July 2003. 447 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 448 Media Attributes in the Session Description Protocol 449 (SDP)", RFC 5576, June 2009. 451 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 452 Description Protocol", RFC 4566, July 2006. 454 [I-D.ietf-mmusic-rfc4756bis] 455 Begen, A., "Forward Error Correction Grouping Semantics in 456 Session Description Protocol", 457 draft-ietf-mmusic-rfc4756bis-05 (work in progress), 458 October 2009. 460 7.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 475 170 West Tasman Drive 476 San Jose, CA 95134 477 USA 479 Email: abegen@cisco.com 481 Thomas Stockhammer 482 Nomor Research 483 Brecherspitzstrasse 8 484 Munich, 81541 485 Germany 487 Email: stockhammer@nomor.de