FEC Framework A. Begen Internet-Draft R. Asati Intended status: Standards Track Cisco Systems Expires: August 21, 2008 February 18, 2008 1-D and 2-D Parity FEC Scheme for FEC Framework draft-begen-fecframe-1d2d-parity-scheme-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the one-dimensional (1-D) and two-dimensional (2-D) parity codes and its application to reliable delivery of media streams in the context of FEC Framework. The 1-D and 2-D parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The 1-D and 2-D parity codes offer Begen & Asati Expires August 21, 2008 [Page 1] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 a good protection against random and bursty packet losses at a cost of decent complexity. This document also specifies an RTP payload format for the FEC that is generated by the 1-D and 2-D parity codes from a source media encapsulated in RTP. The FEC defined in this document is not backward compatible with RFC 5109. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Use Cases for 1-D Parity Codes . . . . . . . . . . . . . . 4 1.2. Use Cases for 2-D Parity Codes . . . . . . . . . . . . . . 4 1.3. Overhead Computation . . . . . . . . . . . . . . . . . . . 4 1.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 5 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Source FEC Payload ID . . . . . . . . . . . . . . . . . . 6 4.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 7 4.3. FEC Framework Configuration Information . . . . . . . . . 10 4.3.1. Mandatory Elements . . . . . . . . . . . . . . . . . . 11 4.3.2. Scheme-Specific Elements . . . . . . . . . . . . . . . 11 4.3.3. Encoding Format . . . . . . . . . . . . . . . . . . . 12 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Configuration Information Signaling Procedures . . . . . . 12 5.2. Content Delivery Protocol Requirements . . . . . . . . . . 13 5.3. Determination of Source Block Size and Repair Window . . . 13 6. 1-D and 2-D Parity FEC Code Specification . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 14 6.2.1. Generating the FEC Header . . . . . . . . . . . . . . 14 6.2.2. Generating the Repair Packet Payload . . . . . . . . . 15 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 15 6.3.1. Associating the Source and Repair Packets . . . . . . 16 6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 16 6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . . 17 6.3.4. Iterative Decoding Algorithm for the 2-D Parity Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 7. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Congestion Control Considerations . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10.1. Registration of FEC Encoding ID . . . . . . . . . . . . . 19 10.2. Registration of audio/2dparityfec . . . . . . . . . . . . 19 10.3. Registration of video/2dparityfec . . . . . . . . . . . . 19 Begen & Asati Expires August 21, 2008 [Page 2] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 10.4. Registration of text/2dparityfec . . . . . . . . . . . . . 19 10.5. Registration of application/2dparityfec . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Begen & Asati Expires August 21, 2008 [Page 3] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 1. Introduction This document defines a new RTP payload format for the FEC that is generated by the 1-D and 2-D parity codes from a source media encapsulated in RTP [RFC3550]. The type of the protected source media can be audio, video, text or application. The payload format also allows for a wide range of FEC configurations to be used within the FEC Framework. The configuration information for the FEC Framework is described through out-of-band means. This configuration information plus the information contained in the payload format let the receiver(s) know the exact associations/relationships between the source and repair packets. The FEC supported by this format uses the simple exclusive OR (XOR) operation. In a nutshell, the sender determines a set of source packets to be protected together based on the FEC Framework Configuration Information. The sender then applies the XOR operation to generate the required number of repair packets and sends the repair packet(s) along with the source packets to the receiver(s). Per the FEC Framework requirements, the sender MUST transmit the source and repair packets in different source and repair flows, respectively. At the receiver side, if all of the source packets are successfully received, there is no need for FEC recovery and the repair packets should be discarded. However, if there are missing source packets, the repair packets can be used to recover the missing information. Editor's note: Include brief introduction to the parity codes, show a block diagram, column FEC/row FEC, the notion of L and D. 1.1. Use Cases for 1-D Parity Codes Editor's note: This section should include the use cases for the 1-D parity codes, the scenarios where the 1-D parity codes fail. 1.2. Use Cases for 2-D Parity Codes Editor's note: This section should include the use cases for the 2-D parity codes, the scenarios where they offer an advantage over the 1-D version and the scenarios where the 2-D parity codes fail. 1.3. Overhead Computation Editor's note: This section should include formulations to be used to compute the overhead for the 1-D and 2-D parity codes. Begen & Asati Expires August 21, 2008 [Page 4] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 1.4. Backward Compatibility Editor's note: This section should include the limitations of the existing specs such as [SMPTE2022-1] and [RFC5109]. It should also include the differences between these specs. This FEC scheme specification follows the document structure defined in [I-D.ietf-fecframe-framework]. 2. Requirements Notation 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 [RFC2119]. 3. Definitions, Notations and Abbreviations The definitions, notations and abbreviations commonly used in this document are summarized in this section. 3.1. Definitions This document uses the following definitions. For further definitions that apply to FEC Framework in general, see [I-D.ietf-fecframe-framework]. Source Flow: The packet flow(s) carrying the source data and to which FEC protection is to be applied. Repair Flow: The packet flow(s) carrying the repair data. Symbol: A unit of data. Its size, in bytes, is referred to as the symbol size. Source Symbol: The smallest unit of data used during the encoding process. All source symbols within a source block have the same size. Repair Symbol: Repair symbols are generated from the source symbols and they have the same size as the source symbols of that source block. Source Packet: Data packets that contain only source symbols. Repair Packet: Data packets that contain only repair symbols. Begen & Asati Expires August 21, 2008 [Page 5] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 Source Block: A block of source symbols that are considered together in the encoding process. FEC Framework Configuration Information: Information that controls the operation of the FEC Framework. Each FEC Framework instance has its own configuration information. FEC Payload ID: Information that identifies the contents of a packet with respect to the FEC scheme. Source FEC Payload ID: An FEC Payload ID specifically used with source packets. Repair FEC Payload ID: An FEC Payload ID specifically used with repair packets. 3.2. Notations o L: Number of columns of the source block. o D: Number of rows of the source block. 3.3. Abbreviations o XOR: Bitwise exclusive OR operation. 0 XOR 0 = 0; 0 XOR 1 = 1; 1 XOR 0 = 1; 1 XOR 1 = 0. o FSSI: FEC-Scheme-Specific Information. o SS-FSSI: Sender-Side FEC-Scheme-Specific Information. o RS-FSSI: Receiver-Side FEC-Scheme-Specific Information. o ToP: Type of the protection applied by the sender. o ToF: Type of the FEC data carried in the repair packet. 4. Formats and Codes This section defines the formats of the source and repair packets as well as the configuration information for the FEC scheme. 4.1. Source FEC Payload ID The source packets MUST contain the information that identifies the source block and the position within the source block occupied by the packet. This information is referred to as the Source FEC Payload Begen & Asati Expires August 21, 2008 [Page 6] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 ID. In some cases, Source FEC Payload ID may be inferred from the fields already existing in the packet. In other cases, however, the required information is explicitly encoded into a specific field called Explicit Source FEC Payload ID, which is appended to the end of the source packets [I-D.ietf-fecframe-framework]. Since the source packets that are carried within an RTP stream already contain unique sequence numbers in their RTP headers [RFC3550], the Source FEC Payload ID can be derived in a straightforward manner. Thus, there is no need to use the Explicit Source FEC Payload ID field. The primary advantage of this approach is that the source packets are not modified in anyway. This provides backward compatibility for the receivers that do not support FEC at all. In multicast scenarios, this backward compatibility becomes quite useful as it allows the non-FEC-capable receivers to receive and interpret the source packets. The derivation of the Source FEC Payload ID from the RTP sequence number is discussed in Section 5. Editor's note: This section should specify the additional requirements that are relevant to grouping multiple source flows together before applying FEC protection. 4.2. Repair FEC Payload ID The repair packets MUST contain information that identifies the source block they pertain to and the relationship between the contained repair symbols and the original source block. This information is referred to as the Repair FEC Payload ID. This information MUST be encoded into a specific field between the transport header and the repair symbols within a repair packet, as shown in Figure 1 [I-D.ietf-fecframe-framework]. Begen & Asati Expires August 21, 2008 [Page 7] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 +------------------------------+ | IP Header | +------------------------------+ | Transport Header | +------------------------------+ | Repair FEC Payload ID | +------------------------------+ | Repair Symbols | +------------------------------+ Figure 1: Format of repair packets Since the repair packets are carried within an RTP stream, the Repair FEC Payload ID consists of an RTP header and an FEC header. This is shown in Figure 2. +------------------------------+ | IP Header | +------------------------------+ | Transport Header | ,--+------------------------------+ +------------------------------+-' | RTP Header | | Repair FEC Payload ID | +------------------------------+ +------------------------------+-. | FEC Header | | Repair Symbols | `--+------------------------------+ +------------------------------+ Figure 2: Format of Repair FEC Payload ID The RTP header is formatted according to [RFC3550] with some further clarifications listed below: o Marker: This field is not used for this payload type, and SHALL be set to 0. o Synchronization Source (SSRC): The SSRC value SHALL be the same as the SSRC value of the protected source RTP stream. o Sequence Number (SN): The sequence number has the standard definition. It MUST be one higher than the sequence number in the previously transmitted repair packet. o Timestamp (TS): The timestamp MUST be set to the value of the media RTP clock at the instant the repair packet is transmitted. Thus, the TS value in FEC packets is always monotonically increasing. o Payload Type: The payload type for the repair packets is determined through the payload format specified in the FEC Begen & Asati Expires August 21, 2008 [Page 8] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 Framework Configuration Information. Note that this document introduces a new payload format for the repair packets (See Section 10 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides backward compatibility. The FEC mechanisms can then be used in a multicast group with mixed FEC-capable and non-FEC- capable receivers. If the non-FEC-capable receivers receive any repair packet, they will not recognize the payload type, and hence, discard the repair packets. The FEC header is 12 octets. The format of the FEC header is shown in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|I|P|X| CC |M| PT recovery | SN base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS recovery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length recovery | Increment | NA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of the FEC header The FEC header consists of the following fields: o The E bit is the extension flag reserved to indicate any future extension to this specification. It SHALL be set to 0, and SHOULD be ignored by the receiver. o The I bit MUST be set to 0 for the column-FEC packets, and MUST be set to 1 for the row-FEC packets. This is the indicator bit that shows the type of the FEC carried with this packet. o The P recovery field, the X recovery field, the CC recovery field, the M recovery field, and the PT recovery field are obtained by applying protection to the corresponding P, X, CC, M, and PT values from the RTP headers of the source packets associated with this repair packet. o The SN base field MUST be set to the lowest sequence number, taking wrap around into account, of those source packets protected by FEC. o The TS recovery field is computed by applying protection to the timestamps of the source packets associated with this repair packet. This allows the timestamp to be completely recovered. Begen & Asati Expires August 21, 2008 [Page 9] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 o The Length recovery field is used to determine the length of any recovered packets. It is computed by applying protection to the unsigned network-ordered 16-bit representation of the sums of the lengths (in bytes) of the media payload, CSRC list, extension and padding of each of the source packets associated with this repair packet. In other words, the CSRC list, RTP extension, and padding of the media payload packets, if present, are counted as part of the payload. This allows the FEC procedure to be applied even when the lengths of the protected source packets are not identical. o The Increment field is the period used to select the source packets associated with this repair packet. It MUST be set to the L parameter defined in Section 4.3.2 for the column-FEC packets, and MUST be set to 1 for the row-FEC packets. o The NA field indicates the number of source packets associated with this repair packet. It MUST be set to the D parameter defined in Section 4.3.2 for the column-FEC packets, and MUST be set to the L parameter defined in Section 4.3.2 for the row-FEC packets. Editor's note: Since the L and D are specified in the FSSI, we may easily skip the Increment and NA fields in the header. However, this information may be needed by the Repair FEC Payload ID and is useful for sanity checks. Editor's note: Shall we consider D and L values larger than 255? If we don't put the Increment and NA fields in the repair packets, length of the D and L values will not be an issue any more. It should be noted that a mask-based approach (similar to the one specified in [RFC5109]) may not be very efficient to indicate which source packets in the current source block are associated with a given repair packet. In particular, for the applications that would like to use large source block sizes, the size of the mask that is required to describe the source-repair packet associations may be prohibitively large. Instead, a systematic approach that specifies the same relationships with fewer bits is generally more efficient. 4.3. FEC Framework Configuration Information The FEC Framework defines a minimum set of information that MUST be communicated between the sender and receiver(s) for a proper operation of the FEC scheme. This information is called the FEC Framework Configuration Information. This information specifies how the sender applies protection to the source flow(s) and how the repair flow(s) can be used to recover the lost data. In other words, Begen & Asati Expires August 21, 2008 [Page 10] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 this information specifies the relationship(s) between the source and repair flows. The FEC Framework requires every FEC Framework instance to provide its own configuration information. From the FEC scheme point of view, the FEC Framework Configuration Information consists of mandatory and scheme-specific elements. We describe these elements below. 4.3.1. Mandatory Elements o FEC Encoding ID: The value of the FEC Encoding ID for the fully- specified FEC scheme defined in this document MUST be TBD as assigned by IANA. Refer to Section 10. 4.3.2. Scheme-Specific Elements FEC-Scheme-Specific Information (FSSI) includes the information that is specific to the FEC scheme used by the Content Delivery Protocol. FSSI is used to communicate the information that cannot be adequately represented otherwise and is essential for proper FEC encoding and decoding operations. The FSSI is carried in two opaque containers. The first container contains the FSSI required only by the sender. This information is referred to as the Sender-Side FEC-Scheme-Specific Information (SS- FSSI). Rest of the FSSI is referred to as the Receiver-Side FEC- Scheme-Specific Information (RS-FSSI) and carried in the second container. The following parameters are carried in the FEC Scheme-Specific Information element: o L: Number of columns of the source block. L is a positive integer. L cannot be larger than 255. o D: Number of rows of the source block. D is a positive integer. D cannot be larger than 255. o SA: Sending arrangement. This is TBD. Editor's note: Shall we define the sending arrangements? Can we generalize this? Or, should we fix it to a certain sending arrangement? Or, should we use "repair-window" attribute to figure out the sending arrangement? E.g., send the repair packets (as smoothly as possible) such that repair window requirement is not violated. Editor's note: In a strict sense, sending arrangement does not Begen & Asati Expires August 21, 2008 [Page 11] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 depend on the FEC scheme and probably should not be part of this specification. It is a transmission problem, which is out of the scope of this document. o ToP: Type of the protection applied by the sender. There are three possible values for ToP: 0 for 1-D column-FEC protection, 1 for 1-D row-FEC protection, and 2 for 2-D column and row-FEC protection. The ToP value of 3 is reserved for possible uses in the future. The ToP value MAY be set by the receiver or another 3rd party entity to control the FEC operations at the sender. Editor's note: Shall we consider code types other than XOR? o ToF: Type of the FEC data carried in the repair flow. 0 for column FEC, and 1 for row FEC. While the type of the FEC data within a repair packet is already indicated by the I bit in the FEC header, ToF is used by the receivers to determine which repair flow carries which FEC data before they start receiving the repair packets. For example, the sender might be generating two repair flows corresponding to column FEC and and row FEC, and the receiver might be interested only in the column-FEC protection. The receiver can identify the repair flow carrying the column-FEC data by checking the ToF values for each repair flow described in the FEC Framework Configuration Information. All of the parameters listed above MUST be included in the FSSI. The parameters L, D and ToP are carried within the SS-FSSI container. The parameter ToF is carried within the RS-FSSI container. 4.3.3. Encoding Format The SS-FSSI container contains the string resulting from the Base64 encoding of the following value: TBD The RS-FSSI container contains the string resulting from the Base64 encoding of the following value: TBD 5. Procedures This section describes the procedures that are specific to the 1-D and 2-D parity FEC scheme. 5.1. Configuration Information Signaling Procedures This specification makes use of the signaling protocol to signal the FEC Framework Configuration Information between the sender and receiver(s). This enables the sender and receiver(s) to be in sync Begen & Asati Expires August 21, 2008 [Page 12] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 with respect to the information needed for the operation of FEC Framework. 5.2. Content Delivery Protocol Requirements Content Delivery Protocol (CDP) is a complete application-protocol specification that provides FEC capabilities by making use of the FEC Schemes through the use of FEC Framework defined in [I-D.ietf-fecframe-framework]. The 1-D/2-D parity encoder and decoder require the following from the CDP: o The size of the source block, namely the number of columns (L) and the number of rows (D). o Type of the protection to be applied to the source blocks (ToP). This information is transmitted to the receiver side by the CDP through the FEC Framework Configuration Information. The 1-D/2-D parity encoder additionally requires: o The data to be protected. The 1-D/2-D parity encoder provides the following information to the CDP: o A column-FEC packet that is generated by applying FEC over each column in the current source block, if column-FEC is enabled. o A row-FEC packet that is generated by applying FEC over each row in the current source block, if row-FEC is enabled. The source packets as well as the repair packets are then transmitted to the receiver(s) by the transport protocol chosen by the CDP. 5.3. Determination of Source Block Size and Repair Window TBC. Editor's note: This section should discuss the derivation of the Source FEC Payload ID from the RTP sequence number. 6. 1-D and 2-D Parity FEC Code Specification This section provides a complete specification of the 1-D and 2-D parity FEC scheme. Basically, it specifies the steps involved in Begen & Asati Expires August 21, 2008 [Page 13] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 generating the repair packets and reconstructing the missing source packets from the repair packets. 6.1. Overview TBC. 6.2. Repair Packet Construction The Repair FEC Payload ID consists of an RTP header and an FEC header. The RTP header of an repair packet is formed based on the guidelines given in Section 4.2. 6.2.1. Generating the FEC Header The FEC header includes 12 octets (96 bits). It is constructed by applying the XOR operation on the bit strings that are generated from the individual source packets protected by this particular repair packet. The set of the source packets that are associated with a given repair packet can be computed by the formula given in Section 6.3.1. The bit string is formed for each source packet by concatenating the following fields together in the order specified: o The first 64 bits of the RTP header (64 bits). o Unsigned network-ordered 16-bit representation of the source packet length in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, extension header, RTP payload, and RTP padding (16 bits). By applying parity operation on the bit strings, we generate the FEC bit string. The FEC header is generated from the FEC bit string as follows: o The first (most significant) 2 bits in the FEC bit string are skipped. o The next bit in the FEC bit string is written into the P recovery bit of the FEC header in the FEC packet. o The next bit in the FEC bit string is written into the X recovery bit of the FEC header. o The next 4 bits of the FEC bit string are written into the CC recovery field of the FEC header. Begen & Asati Expires August 21, 2008 [Page 14] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 o The next bit is written into the M recovery bit of the FEC header. o The next 7 bits of the FEC bit string are written into the PT recovery field in the FEC header. o The next 16 bits are skipped. o The next 32 bits of the FEC bit string are written into the TS recovery field in the FEC header. o The next 16 bits are written into the length recovery field in the packet header. As described in Section 4.2, the SN base field of the FEC header MUST be set to the lowest sequence number of the source packets protected by this repair packet. For the column-FEC packets, this corresponds to the lowest sequence number of the source packets that form the column. For the row-FEC packets, the SN base field MUST be set to the lowest sequence number of the source packets that form the row. The Increment field MUST be set to the L parameter defined in Section 4.3.2 for the column-FEC packets, and MUST be set to 1 for the row-FEC packets. Finally, the NA field MUST be set to the D parameter defined in Section 4.3.2 for the column-FEC packets, and MUST be set to the L parameter defined in Section 4.3.2 for the row- FEC packets. 6.2.2. Generating the Repair Packet Payload The repair packet payload consists of the bits that are generated by applying the XOR operation on the payloads of the source RTP packets. If the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. 6.3. Source Packet Reconstruction This section describes the recovery procedures that are required to reconstruct the missing packets. The recovery process has two steps. In the first step, the FEC decoder determines which source and repair packets should be used in order to recover a missing packet. In the second step, the decoder recovers the missing packet, which consists of an RTP header and RTP payload. In the following, we describe the RECOMMENDED algorithms for the first and second step. Based on the implementation, different algorithms MAY be adopted. However, note that the same algorithms are used by the 1-D parity codes, regardless of whether the FEC is Begen & Asati Expires August 21, 2008 [Page 15] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 applied over a column or a row. The 2-D parity codes, on the other hand, usually require multiple iterations of the procedures described here. This iterative decoding algorithm is further explained in Section 6.3.4. 6.3.1. Associating the Source and Repair Packets The first step is associating the source and repair packets. By virtue of the I bit in the FEC header, each repair packet is indicated whether it is a column or row-FEC packet. In addition, the SN base field in the FEC header shows the lowest sequence number of the source packets that form the particular column or row. Finally, the information of how many source packets are included in each column or row is available from the Increment and NA fields in the FEC header and from the FEC Framework Configuration Information. This set of information uniquely identifies all of the source packets associated with a given repair packet. Mathematically, for any received repair packet, p*, we can determine the sequence numbers of the source packets that are protected by this repair packet as follows: p*_snb + i * Increment where p*_snb denotes the value indicated in the SN base field of p*, and 0 <= i < NA We denote the set of the source packets associated with a repair packet by the set T. Note that in a source block whose size is L columns by D rows, set T includes D source packets plus one repair packet for the FEC applied over a column, and L source packets plus one repair packet for the FEC applied over a row. 6.3.2. Recovering the RTP Header For a given set T, the procedure for the recovery of the RTP header of the missing packet, whose sequence number is denoted by X, is as follows: 1. For each of the source packets that are successfully received in T, compute the 80-bit string by concatenating the first 64 bits of their RTP header and the unsigned network-ordered 16-bit representation of their length in bytes minus 12. 2. For the repair packet in T, compute the FEC bit string from the first 80 bits of the FEC header. Begen & Asati Expires August 21, 2008 [Page 16] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 3. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T. 4. Create a new packet with the standard 12-byte RTP header and no payload. 5. Set the version of the new packet to 2. Skip the first 2 bits in the recovered bit string. 6. Set the Padding bit in the new packet to the next bit in the recovered bit string. 7. Set the Extension bit in the new packet to the next bit in the recovered bit string. 8. Set the CC field to the next 4 bits in the recovered bit string. 9. Set the Marker bit in the new packet to the next bit in the recovered bit string. 10. Set the Payload type in the new packet to the next 7 bits in the recovered bit string. 11. Set the SN field in the new packet to X. Skip the next 16 bits in the recovered bit string. 12. Set the TS field in the new packet to the next 32 bits in the recovered bit string. 13. Take the next 16 bits of the recovered bit string and set Y to whatever unsigned integer this represents (assuming network- order). Y represents the length of the new packet in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, extension header, RTP payload, and RTP padding. 14. Set the SSRC of the new packet to the SSRC of the media stream it's protecting, i.e., the SSRC of the media stream to which the FEC stream is associated. This procedure recovers the header of an RTP packet up to (and including) the SSRC field. 6.3.3. Recovering the RTP Payload Following the recovery of the RTP header, the procedure for the recovery of the RTP payload is as follows: Begen & Asati Expires August 21, 2008 [Page 17] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 1. Append Y bytes to the new packet. 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. Note that the information of the first 12 octets are protected by the FEC header. 3. For the repair packet in T, compute the FEC bit string from the repair packet payload, i.e., the Y octets of data following the FEC header. 4. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T. 5. Append the recovered bit string (Y octets) to the new packet generated in Section 6.3.2. 6.3.4. Iterative Decoding Algorithm for the 2-D Parity Codes TBC. 7. SDP Examples Editor's note: This section should provide SDP [RFC4566] examples with different set of configurations. The SDP elements for FEC Framework are introduced in [I-D.ietf-fecframe-sdp-elements]. Current examples use [RFC4756] for grouping source and repair flows together in SDP. However, the examples should be updated, in case new grouping semantics will be introduced [I-D.begen-mmusic-fec-grouping-issues] in MMUSIC WG. 8. Congestion Control Considerations For the general congestion control considerations related to the use of FEC, refer to [I-D.ietf-fecframe-framework]. Editor's note: Additional congestion control considerations regarding the use of 2-D parity codes should be added here. Begen & Asati Expires August 21, 2008 [Page 18] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 9. Security Considerations For the general security considerations related to the use of FEC, refer to [I-D.ietf-fecframe-framework]. 10. IANA Considerations 10.1. Registration of FEC Encoding ID The value of FEC Encoding ID is subject to IANA registration. For general guidelines on IANA considerations as they apply to this document, see [I-D.ietf-fecframe-framework]. This document assigns the Fully-Specified FEC Encoding ID TBD under the ietf:fecframe:fec:encoding name-space to TBD. 10.2. Registration of audio/2dparityfec TBC. 10.3. Registration of video/2dparityfec TBC. 10.4. Registration of text/2dparityfec TBC. 10.5. Registration of application/2dparityfec TBC. 11. Acknowledgments A major part of this document is borrowed from [RFC5109]. Thus, the authors would like to thank the editor of [RFC5109] and those who contributed to [RFC5109]. The authors would also like to thank the FEC Framework Design Team for their inputs, suggestions and contributions. 12. References Begen & Asati Expires August 21, 2008 [Page 19] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 12.1. Normative References [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-01 (work in progress), November 2007. [I-D.ietf-fecframe-sdp-elements] Begen, A., "SDP Elements for FEC Framework", draft-ietf-fecframe-sdp-elements-00 (work in progress), February 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006. [I-D.begen-mmusic-fec-grouping-issues] Begen, A., "FEC Grouping Issues in Session Description Protocol", draft-begen-mmusic-fec-grouping-issues-00 (work in progress), February 2008. [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007. 12.2. Informative References [SMPTE2022-1] SMPTE 2022-1-2007, "Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks", 2007. Begen & Asati Expires August 21, 2008 [Page 20] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 Authors' Addresses Ali Begen Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: abegen@cisco.com Rajiv Asati Cisco Systems 7025-6 Kit Creek Road PO Box 14987 RTP, NC 27709 USA Email: rajiva@cisco.com Begen & Asati Expires August 21, 2008 [Page 21] Internet-Draft 1-D and 2-D Parity FEC Scheme February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Begen & Asati Expires August 21, 2008 [Page 22]