idnits 2.17.1 draft-bergeron-payload-rtpfec-rs-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 108 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([RTP3350], [RFC2119], [RFC2733], [RFC-2119], [RFC3984], [1], [RFC6015]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 184 has weird spacing: '...s could inter...' == Line 205 has weird spacing: '...instead dimen...' == Line 213 has weird spacing: '...for the recov...' -- The document date (February 21, 2011) is 4806 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC-2119' on line 64 looks like a reference -- Missing reference section? 'RFC2733' on line 358 looks like a reference -- Missing reference section? 'RFC6015' on line 361 looks like a reference -- Missing reference section? '1' on line 366 looks like a reference -- Missing reference section? 'RFC3984' on line 183 looks like a reference -- Missing reference section? 'RTP3350' on line 338 looks like a reference -- Missing reference section? 'RFC2119' on line 355 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Payload C. Bergeron, R. Fracchia, B. Gadat 2 Internet Draft Thales Communications 3 Intended status: Informational February 21, 2011 4 Expires: August 2011 6 RTP Payload Format for Reed-Solomon FEC 7 draft-bergeron-payload-rtpfec-rs-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 21, 2011. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the BSD License. 47 Abstract 49 This document defines a new RTP payload type for the insertion of 50 Forward Error Correction (FEC) in RTP. This solution is based on 51 Reed-Solomon codes that protect the transmission both from packet 52 losses and bit errors which may affect the communication over 53 wireless links. These codes are systematic, thus being completely 54 transparent to FEC unaware RTP clients. The new payload defined in 56 this draft and the insertion of RS codes are particularly suited for 57 H.264 video streaming. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC-2119]. 65 Table of Contents 67 1. Introduction 68 2. Encoding/decoding at transport layer 69 3. Reed-Solomon (RS) codes 70 4. Source packets 71 5. Repair packets 72 5.1. Information for FEC decoding 73 5.2. RTP Extra-Header 74 5.2.1. Repair packet payload type 75 6. Security Considerations 76 7. IANA Considerations 77 8. Acknowledgments 78 9. References 79 9.1. Normative References 81 9.2. Informative References 83 Author's Addresses 84 Intellectual Property Statement 85 Disclaimer of Validity 87 1. Introduction 89 The introduction of Forward Error Correction (FEC) at high level of 90 the OSI stack can be done in several different ways. In particular, 91 as a direct insertion inside the data stream, i.e., at the 92 application level, or as an insertion after encapsulation in RTP 93 packets or on transport packets (UDP, DCCP, SCTP, ...). 95 The idea of using FEC for RTP packets is not new, and some proposals 96 have already been presented at the IETF. However, the RTP-FEC 97 approach defined in [RFC2733] presents the drawback of tagging as 98 "RTP FEC" redundancy packets. This implies that an unaware receiver, 99 i.e., a receiver not specifically enhanced by the RTP-FEC feature, 100 would discard all packets. 102 Work in [RFC6015] has a similar approach to the one presented in 103 this document: the solution presented here proposes an alternative 104 insertion of FEC in RTP, providing correction not only of packet 105 losses but also of bit errors. This scheme, based on Reed-Solomon 106 codes, reduced moreover the overhead associated to the FEC headers. 108 2. Encoding/decoding at transport layer 110 This section provides an overview of the encoding and decoding 111 process. 113 The packet-level encoder forwards the packets received from the upper 114 layer immediately to the lower layers to avoid the introduction of 115 significant extra-delay. Such packets are called source packets. The 116 encoding process starts when either a sufficient amount of data is 117 available. 119 Regardless the specific (N,K) packet-level code that is employed, 120 encoding starts by filling with the source packets an encoding table, 121 also called the source block, consisting of N=K+M rows, each of T 122 bytes, indexed from 1 to n. Each such row is called a symbol. The 123 generic source block is filled with progressive RTP packets. 125 At the decoder, source or repair packets may be missing. Moreover, 126 both correct and corrupted packets (either source or repair) are 127 received. Packet losses may be due to erasures along the IPv6 128 network, errors in the DLL/IP/UDP/RTP headers caused by the 129 transmission across a radio channel or selective drops operated by an 130 intelligent transport network. The possible presence of partially 131 corrupted RTP packets (i.e., packets which are recognized as 132 corrupted, but without errors in the header) is due to the use of 133 transport protocols like UDP-Lite or to a partial CRC at the data 134 link layer like introduced in WiMAX and represents an important 135 issue, since a robust source decoder may be able to exploit them to 136 improve the end-to-end quality. At the decoder, the correctly 137 received (source and repair) packets are filled into a decoding 138 source block, analogous to the source block in the encoder. Decoding 139 consists of recovering the missing T-byte symbols from erasures and, 140 if partially corrupted RTP packets are received, correct the errors 141 affecting the corresponding symbols. 143 3. Reed-Solomon (RS) codes 145 Reed-Solomon (RS) codes are non-binary systematic cyclic error- 146 correcting codes invented by I. Reed and G. Solomon [1] and detecting 147 and correcting multiple random symbol errors. 149 The Reed-Solomon code is an optimum [N, K, N-K+1] code: in other 150 words, it is a linear block code of length N with dimension K and 151 minimum Hamming distance N-K+1. Moreover, the minimum distance has 152 the maximum possible value for a linear code of size (N,K). 154 The error-correcting ability of a Reed-Solomon code is determined by 155 its minimum distance, or, equivalently, by N - K, the measure of 156 redundancy in the block. If the locations of the error symbols are 157 not known in advance, then a Reed-Solomon code can correct up to (N - 158 K) / 2 erroneous symbols, i.e., it can correct half as many errors as 159 there are redundant symbols added to the block. As an erasure code, 160 it can correct up to N - K known erasures. Moreover, it can detect 161 and correct combinations of errors and erasures: a Reed-Solomon code 162 is able to correct any combination of errors and erasures as long as 163 the relation 2E + L = N - K is satisfied, where E is the number of 164 errors and L is the number of erasures in the block. 166 For practical uses of Reed-Solomon codes, it is common to fix a 167 finite field F with 2m elements. In this case, each symbol can be 168 represented as an m-bit value. The sender transmits the data points 169 as encoded blocks, and the number of symbols in the encoded block is 170 N = 2m - 1. Thus a Reed-Solomon code operating on 8-bit symbols has N 171 = 28 - 1 = 255 symbols per block. The number K (with K < N) of data 172 symbols in the block is a design parameter. 174 The above properties of Reed-Solomon codes make them especially well 175 suited to applications where errors occur in bursts. Moreover, being 176 systematic, they allow sending information bits untouched and adding 177 redundancy bits thus being fully transparent for a user unaware of 178 the Forward Error Correction (FEC) feature. 180 4. Source packets 182 In the introduction of RS codes in RTP, source packets are RTP 183 packets as defined in [RFC3984]. This guarantees that non-FEC capable 184 receives could interpret the received source packets. 186 5. Repair packets 188 For the generation of repair packets, the RTP encoder builds a matrix 189 of K rows where every row corresponds to an RTP source packet. The K 190 source RTP data packets are transmitted to the receiver followed by M 191 = N- K RS packets generated by interleaving 1 byte of each RTP data 192 packet. 194 The dimension K, i.e., the number of source packets in the matrix, is 195 a parameter of the system. 197 However, it may happen that, in case of a H.264 video packetization, 198 the Kth packet may be in the middle of a Network Abstraction Layer 199 (NAL). In order to avoid the split of a NAL into two different 200 matrix, additional RTP packets COULD be inserted in the matrix, up to 201 the completion of the NAL transmission. It follows that a number 202 K'=K+k of RTP source packets are inserted in the matrix, with 203 k=NALsize-K. 205 The matrix size N is instead dimensioned on the maximum RTP packet 206 size Smax plus 2 additional bytes for packet size indication, as 207 depicted in Figure 1. 209 The rational behind this choice is as follows. RTP packets have a 210 variable size S, which can assume a value between 13 bytes (i.e., an 211 header size of 12 bytes and a payload of one byte) and Smax. At the 212 receiver side, in case of losses, the amount of lost data (i.e., the 213 packet size) is needed for the recovery process: this extra 214 information SHOULD be appended to the RTP source packets while 215 inserting them in the matrix. The packet size S, virtually inserted 216 in the matrix and thus considered in the generation of the RS repair 217 packets, SHELL NOT be really transmitted to the receiver: at the 218 receiver side, the payload length can be recovered from the RS 219 packets in case of losses, since it has been included in the 220 computation of the protection. 222 This solution has a general validity and it can be applied to any 223 kind of data packet. It has however to be noticed that for H.264 224 video frames the addition of the 2 Bytes for the payload size MAY be 225 skipped. Indeed, in H.264 video frames there are no more than two 226 consecutive bits equal to zero. If follows that, if there are three 227 or more bits equal to zero in the received packets, those bits are of 228 padding: in that case, the end of the packet can be identified by 229 looking, starting from the end of the packet, for the first bit 230 different from zero. 232 matrix size 233 <---------------------------------------------> 234 ++++++++++++++++++++++++++++++++++++++++++++++++ 235 | RTP Header | Payload | S | 236 ++++++++++++++++++++++++++++++++++++++++++++++++ 237 ++++++++++++++++++++++++++++++++++++++++++++++++ 238 | RTP Header | Payload | S | k' 239 ++++++++++++++++++++++++++++++++++++++++++++++++ 240 ++++++++++++++++++++++++++++++++++++++++++++++++ 241 | RTP Header | Payload | S | 242 ++++++++++++++++++++++++++++++++++++++++++++++++ 243 ++++++++++++++++++++++++++++++++++++++++++++++++ 244 | RTP Header | Payload | S | 245 ++++++++++++++++++++++++++++++++++++++++++++++++ 246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 247 | RTP Header | EH | Reed-Solomon | 248 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 249 | RTP Header | EH | Reed-Solomon | m 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 251 | RTP Header | EH | Reed-Solomon | 252 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 254 Figure 1 Application of RS codes to H.264 RTP packets 256 5.1. Information for FEC decoding 258 The following information MUST be known at the receiver side for a 259 correct decoding: 261 o The Sequence Number (SBN) of the first RTP Packet to take in 262 consideration, i.e., the first packet of the matrix. 264 o The parameters of the RS codes, i.e., N and K (we assume to work on 265 GF(256)). 267 o The size of the payload. 269 o The size of the matrix. 271 As explained above: 273 o The size of the matrix corresponds to Smax+2, and thus it does not 274 require to be transmitted; 276 o The size of the payload is virtually added in the matrix and thus 277 can be determined by the receiver. 279 Moreover, N MAY be considered equal to 255 at the decoder: indeed, a 280 RS(55,25) is equivalent to a RS(255,25) where the last 200 packets 281 are considered lost as depicted in Figure 2. 283 We SHOULD thus avoid transmitting this information while signaling to 284 the receiver only the parameter K and the Sequence Number. 286 5.2. RTP Extra-Header 288 The repair packets are characterized by an "Extra-header" of four 289 Bytes following the RTP header and reporting, as depicted in Figure 290 3: 292 o the SBN (2B) 294 o K' (1B only considering a maximum number of rows N of 255). 296 o An RS code on the extra-header (1B). It has to be noticed that SBN 297 and k' have the same values for all the packets in the same 298 matrix: in case of errors, values can be obtained from the other 299 correct packets of the matrix. One byte of protection is thus 300 enough to offer a good reliability with a minimum overhead. 302 0 1 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |V=2|P|X| CC |M| PT | sequence number | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | timestamp | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | synchronization source (SSRC) identifier | 310 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 311 | contributing source (CSRC) identifiers | 312 | .... | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | SBN | K | RS | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 2 RTP-FEC standard extended header for unique/multiple Reed- 318 Solomon codes/codewords. 320 5.2.1. Repair packet payload type 322 The M RS repair packets are characterized by a new payload type. The 323 use of a new payload type (e.g., no. 99) assures the compliance to 324 RTP receivers not supporting FEC. At the receiver side, one 325 depacketisers is used for both data and redundancy packets: if RTP 326 FEC packets are received by a client not supporting the RTP FEC mode, 327 the packets with an unknown payload type (i.e, 99) are simply 328 discarded. An RTP FEC receiver would instead decode the RS packet and 329 correct the eventual errors or losses. 331 The repair packets are identified by an X field with a value equal to 332 the new Payload Type (PT) in the RTP header. 334 6. Security Considerations 336 RTP packets using the format defined in this specification are 337 subject to the security considerations of the RTP specification 338 [RTP3350]. 340 The repair packets as presented in this document do not cause 341 specific additional security issues. 343 7. IANA Considerations 345 There are no IANA considerations in this document. 347 8. Acknowledgments 349 This document was prepared using 2-Word-v2.0.template.dot. 351 9. References 353 9.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", March 1997 358 [RFC2733] J. Rosenberg, H. Schulzinne, "RTP payload format for 359 generic forward error correction", RFC 2733, December 1999. 361 [RFC6015] A. Begen, "RTP Payload Format for 1-D Interleaved Parity 362 FEC", RFC 6015, October 2010. 364 9.2. Informative References 366 [1] I. Reed, G. Solomon, "Polynomial Codes over Certain Finite 367 Fields", Journal of the Society for Industrial and Applied 368 Mathematics (SIAM) 8 (2): p. 300-304 370 Author's Addresses 372 Cyril Bergeron 373 Thales Communications 374 160 boulevard de Valmy, 92704 Colombes Cedex 376 Email: Cyril.Bergeron@fr.thalesgroup.com 378 Benjamin Gadat 379 Thales Communications 380 160 boulevard de Valmy, 92704 Colombes Cedex 382 Email: Benjamin.gadat@fr.thalesgroup.com 384 Roberta Fracchia 385 Thales Communications 386 160 boulevard de Valmy, 92704 Colombes Cedex 388 Email: Roberta.fracchia@fr.thalesgroup.com