Payload C. Bergeron, R. Fracchia, B. Gadat Internet Draft Thales Communications Intended status: Informational February 21, 2011 Expires: August 2011 RTP Payload Format for Reed-Solomon FEC draft-bergeron-payload-rtpfec-rs-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 21, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Bergeron et al. Expires August 21, 2011 [Page 1] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 Abstract This document defines a new RTP payload type for the insertion of Forward Error Correction (FEC) in RTP. This solution is based on Reed-Solomon codes that protect the transmission both from packet losses and bit errors which may affect the communication over wireless links. These codes are systematic, thus being completely transparent to FEC unaware RTP clients. The new payload defined in this draft and the insertion of RS codes are particularly suited for H.264 video streaming. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Bergeron et al. Expires August 21, 2011 [Page 2] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 Table of Contents 1. Introduction 2. Encoding/decoding at transport layer 3. Reed-Solomon (RS) codes 4. Source packets 5. Repair packets 5.1. Information for FEC decoding 5.2. RTP Extra-Header 5.2.1. Repair packet payload type 6. Security Considerations 7. IANA Considerations 8. Acknowledgments 9. References 9.1. Normative References 9.2. Informative References Author's Addresses Intellectual Property Statement Disclaimer of Validity Bergeron et al. Expires August 21, 2011 [Page 3] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 1. Introduction The introduction of Forward Error Correction (FEC) at high level of the OSI stack can be done in several different ways. In particular, as a direct insertion inside the data stream, i.e., at the application level, or as an insertion after encapsulation in RTP packets or on transport packets (UDP, DCCP, SCTP, ...). The idea of using FEC for RTP packets is not new, and some proposals have already been presented at the IETF. However, the RTP-FEC approach defined in [RFC2733] presents the drawback of tagging as "RTP FEC" redundancy packets. This implies that an unaware receiver, i.e., a receiver not specifically enhanced by the RTP-FEC feature, would discard all packets. Work in [RFC6015] has a similar approach to the one presented in this document: the solution presented here proposes an alternative insertion of FEC in RTP, providing correction not only of packet losses but also of bit errors. This scheme, based on Reed-Solomon codes, reduced moreover the overhead associated to the FEC headers. 2. Encoding/decoding at transport layer This section provides an overview of the encoding and decoding process. The packet-level encoder forwards the packets received from the upper layer immediately to the lower layers to avoid the introduction of significant extra-delay. Such packets are called source packets. The encoding process starts when either a sufficient amount of data is available. Regardless the specific (N,K) packet-level code that is employed, encoding starts by filling with the source packets an encoding table, also called the source block, consisting of N=K+M rows, each of T bytes, indexed from 1 to n. Each such row is called a symbol. The generic source block is filled with progressive RTP packets. At the decoder, source or repair packets may be missing. Moreover, both correct and corrupted packets (either source or repair) are received. Packet losses may be due to erasures along the IPv6 network, errors in the DLL/IP/UDP/RTP headers caused by the transmission across a radio channel or selective drops operated by an intelligent transport network. The possible presence of partially corrupted RTP packets (i.e., packets which are recognized as corrupted, but without errors in the header) is due to the use of transport protocols like UDP-Lite or to a partial CRC at the data link layer like introduced in WiMAX and represents an important Bergeron et al. Expires August 21, 2011 [Page 4] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 issue, since a robust source decoder may be able to exploit them to improve the end-to-end quality. At the decoder, the correctly received (source and repair) packets are filled into a decoding source block, analogous to the source block in the encoder. Decoding consists of recovering the missing T-byte symbols from erasures and, if partially corrupted RTP packets are received, correct the errors affecting the corresponding symbols. 3. Reed-Solomon (RS) codes Reed-Solomon (RS) codes are non-binary systematic cyclic error- correcting codes invented by I. Reed and G. Solomon [1] and detecting and correcting multiple random symbol errors. The Reed-Solomon code is an optimum [N, K, N-K+1] code: in other words, it is a linear block code of length N with dimension K and minimum Hamming distance N-K+1. Moreover, the minimum distance has the maximum possible value for a linear code of size (N,K). The error-correcting ability of a Reed-Solomon code is determined by its minimum distance, or, equivalently, by N - K, the measure of redundancy in the block. If the locations of the error symbols are not known in advance, then a Reed-Solomon code can correct up to (N - K) / 2 erroneous symbols, i.e., it can correct half as many errors as there are redundant symbols added to the block. As an erasure code, it can correct up to N - K known erasures. Moreover, it can detect and correct combinations of errors and erasures: a Reed-Solomon code is able to correct any combination of errors and erasures as long as the relation 2E + L = N - K is satisfied, where E is the number of errors and L is the number of erasures in the block. For practical uses of Reed-Solomon codes, it is common to fix a finite field F with 2m elements. In this case, each symbol can be represented as an m-bit value. The sender transmits the data points as encoded blocks, and the number of symbols in the encoded block is N = 2m - 1. Thus a Reed-Solomon code operating on 8-bit symbols has N = 28 - 1 = 255 symbols per block. The number K (with K < N) of data symbols in the block is a design parameter. The above properties of Reed-Solomon codes make them especially well suited to applications where errors occur in bursts. Moreover, being systematic, they allow sending information bits untouched and adding redundancy bits thus being fully transparent for a user unaware of the Forward Error Correction (FEC) feature. Bergeron et al. Expires August 21, 2011 [Page 5] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 4. Source packets In the introduction of RS codes in RTP, source packets are RTP packets as defined in [RFC3984]. This guarantees that non-FEC capable receives could interpret the received source packets. 5. Repair packets For the generation of repair packets, the RTP encoder builds a matrix of K rows where every row corresponds to an RTP source packet. The K source RTP data packets are transmitted to the receiver followed by M = N- K RS packets generated by interleaving 1 byte of each RTP data packet. The dimension K, i.e., the number of source packets in the matrix, is a parameter of the system. However, it may happen that, in case of a H.264 video packetization, the Kth packet may be in the middle of a Network Abstraction Layer (NAL). In order to avoid the split of a NAL into two different matrix, additional RTP packets COULD be inserted in the matrix, up to the completion of the NAL transmission. It follows that a number K'=K+k of RTP source packets are inserted in the matrix, with k=NALsize-K. The matrix size N is instead dimensioned on the maximum RTP packet size Smax plus 2 additional bytes for packet size indication, as depicted in Figure 1. The rational behind this choice is as follows. RTP packets have a variable size S, which can assume a value between 13 bytes (i.e., an header size of 12 bytes and a payload of one byte) and Smax. At the receiver side, in case of losses, the amount of lost data (i.e., the packet size) is needed for the recovery process: this extra information SHOULD be appended to the RTP source packets while inserting them in the matrix. The packet size S, virtually inserted in the matrix and thus considered in the generation of the RS repair packets, SHELL NOT be really transmitted to the receiver: at the receiver side, the payload length can be recovered from the RS packets in case of losses, since it has been included in the computation of the protection. This solution has a general validity and it can be applied to any kind of data packet. It has however to be noticed that for H.264 video frames the addition of the 2 Bytes for the payload size MAY be skipped. Indeed, in H.264 video frames there are no more than two consecutive bits equal to zero. If follows that, if there are three or more bits equal to zero in the received packets, those bits are of Bergeron et al. Expires August 21, 2011 [Page 6] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 padding: in that case, the end of the packet can be identified by looking, starting from the end of the packet, for the first bit different from zero. matrix size <---------------------------------------------> ++++++++++++++++++++++++++++++++++++++++++++++++ | RTP Header | Payload | S | ++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++ | RTP Header | Payload | S | k' ++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++ | RTP Header | Payload | S | ++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++ | RTP Header | Payload | S | ++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | RTP Header | EH | Reed-Solomon | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | RTP Header | EH | Reed-Solomon | m ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | RTP Header | EH | Reed-Solomon | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Figure 1 Application of RS codes to H.264 RTP packets 5.1. Information for FEC decoding The following information MUST be known at the receiver side for a correct decoding: o The Sequence Number (SBN) of the first RTP Packet to take in consideration, i.e., the first packet of the matrix. o The parameters of the RS codes, i.e., N and K (we assume to work on GF(256)). o The size of the payload. o The size of the matrix. Bergeron Expires August 21, 2011 [Page 7] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 As explained above: o The size of the matrix corresponds to Smax+2, and thus it does not require to be transmitted; o The size of the payload is virtually added in the matrix and thus can be determined by the receiver. Moreover, N MAY be considered equal to 255 at the decoder: indeed, a RS(55,25) is equivalent to a RS(255,25) where the last 200 packets are considered lost as depicted in Figure 2. We SHOULD thus avoid transmitting this information while signaling to the receiver only the parameter K and the Sequence Number. 5.2. RTP Extra-Header The repair packets are characterized by an "Extra-header" of four Bytes following the RTP header and reporting, as depicted in Figure 3: o the SBN (2B) o K' (1B only considering a maximum number of rows N of 255). o An RS code on the extra-header (1B). It has to be noticed that SBN and k' have the same values for all the packets in the same matrix: in case of errors, values can be obtained from the other correct packets of the matrix. One byte of protection is thus enough to offer a good reliability with a minimum overhead. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SBN | K | RS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 RTP-FEC standard extended header for unique/multiple Reed- Solomon codes/codewords. Bergeron et al. Expires August 21, 2011 [Page 8] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 5.2.1. Repair packet payload type The M RS repair packets are characterized by a new payload type. The use of a new payload type (e.g., no. 99) assures the compliance to RTP receivers not supporting FEC. At the receiver side, one depacketisers is used for both data and redundancy packets: if RTP FEC packets are received by a client not supporting the RTP FEC mode, the packets with an unknown payload type (i.e, 99) are simply discarded. An RTP FEC receiver would instead decode the RS packet and correct the eventual errors or losses. The repair packets are identified by an X field with a value equal to the new Payload Type (PT) in the RTP header. 6. Security Considerations RTP packets using the format defined in this specification are subject to the security considerations of the RTP specification [RTP3350]. The repair packets as presented in this document do not cause specific additional security issues. 7. IANA Considerations There are no IANA considerations in this document. 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Bergeron et al. Expires August 21, 2011 [Page 9] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997 [RFC2733] J. Rosenberg, H. Schulzinne, "RTP payload format for generic forward error correction", RFC 2733, December 1999. [RFC6015] A. Begen, "RTP Payload Format for 1-D Interleaved Parity FEC", RFC 6015, October 2010. 9.2. Informative References [1] I. Reed, G. Solomon, "Polynomial Codes over Certain Finite Fields", Journal of the Society for Industrial and Applied Mathematics (SIAM) 8 (2): p. 300-304 Bergeron et al. Expires August 21, 2011 [Page 10] Internet-Draft RTP Payload Format for Reed-Solomon FEC February 2011 Author's Addresses Cyril Bergeron Thales Communications 160 boulevard de Valmy, 92704 Colombes Cedex Email: Cyril.Bergeron@fr.thalesgroup.com Benjamin Gadat Thales Communications 160 boulevard de Valmy, 92704 Colombes Cedex Email: Benjamin.gadat@fr.thalesgroup.com Roberta Fracchia Thales Communications 160 boulevard de Valmy, 92704 Colombes Cedex Email: Roberta.fracchia@fr.thalesgroup.com Bergeron et al. Expires August 21, 2011 [Page 11]