One document matched: draft-begen-fecframe-1d2d-parity-scheme-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 07:47:18 |