1 / 12

1-D and 2-D Parity FEC Scheme draft-begen-fecframe-1d2d-parity-scheme-00 IETF 71 – March 2008

1-D and 2-D Parity FEC Scheme draft-begen-fecframe-1d2d-parity-scheme-00 IETF 71 – March 2008. Ali C. Begen and Rajiv Asati {abegen, rajiva}@cisco.com. Introduction. 1-D and 2-D parity codes are systematic FEC codes of decent complexity that provide protection against Bursty losses

hogan
Download Presentation

1-D and 2-D Parity FEC Scheme draft-begen-fecframe-1d2d-parity-scheme-00 IETF 71 – March 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 1-D and 2-D Parity FEC Scheme draft-begen-fecframe-1d2d-parity-scheme-00IETF 71 – March 2008 Ali C. Begen and Rajiv Asati {abegen, rajiva}@cisco.com

  2. Introduction • 1-D and 2-D parity codes are systematic FEC codes of decent complexity that provide protection against • Bursty losses • Random losses • This document • Describes a Fully-Specified FEC Scheme for the 1-D and 2-D parity codes • Specifies an RTP payload format for the FEC that is generated by the 1-D and 2-D parity codes from an RTP source media • The FEC defined in this document is not backward compatible with RFC 5109 (or SMPTE 2022-1)

  3. 1-D and 2-D Parity FEC • Source block size: D x L • 1-D Column FEC (for Bursty Losses) • Each column produces a single packet • Overhead = 1 / D • L-packet duration should be larger than the (target) burst duration • 1-D Row FEC (for Random Losses) • Each row produces a single packet • Overhead = 1 / L • 2-D Column + Row FEC • Overhead = (D+L)/(DxL) L 1 2 3 R1 4 5 6 R2 XOR D Repair Packets 7 8 9 R3 10 11 12 R4 XOR C1 C2 C3 Repair Packets

  4. 1-D and 2-D Parity FEC Limitations XOR XOR XOR 1-D Column FEC fails! 1-D Row FEC would work Both 1-D and 2-D FEC fails! XOR 1-D Row FEC fails! 1-D Column FEC would work Packet Loss

  5. FEC Framework Architecture – Minor Tweaks Application Layer Content Delivery Protocol (CDP) FEC Config Transport Protocol FEC Framework FEC Scheme Transport Layer (UDP, DCCP, etc) Network Layer (IP) Data Link Layer

  6. Source FEC Payload ID • Each source packet MUST contain the information that identifies • Source block • Packet’s relative position within the source block • We use RTP streams as the source flows • Unique sequence numbers in the RTP headers • No need to use the Explicit Source FEC Payload ID field • Source packets are not modified • Compatibility with non-FEC-capable receivers • Usability of the same multicast group for all receivers

  7. Repair FEC Payload ID • Repair packets MUST contain information that identifies • Source block they pertain to • Relationship between the repair symbols and original source block +--------------------------+ | IP Header | +--------------------------+ | Transport Header | ,--+------------------------+ +--------------------------+-' | RTP Header | | Repair FEC Payload ID | +------------------------+ +--------------------------+-. | FEC Header | | Repair Symbols | `--+------------------------+ +--------------------------+

  8. RTP Header for Repair Packets • Marker: Not used, set to 0 • Payload Type: Introduced in this document (Requires IANA registration) • Unrecognized payload types are discarded per RFC 3550 • Sequence Number (SN): One higher for each subsequent packet • Timestamp (TS): Set to the value of the media RTP clock at the instant the repair packet is transmitted • SSRC: Same as the SSRC value of the protected source RTP stream 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 | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  9. FEC Header • I bit: Set to 0 for the column-FEC, and 1 for the row-FEC packets • SN base: Set to the lowest sequence number of those source packets protected by FEC • Increment field: Set to L for the column-FEC, and 1 for the row-FEC packets • NA field: Set to D for the column-FEC, and L for the row-FEC packets • Open Issue: L and D are already specified in the FSSI. Can we skip the Increment and NA fields?  We won’t be limited to block sizes of 255 x 255 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  10. Configuration Information • FEC Encoding ID: Requires IANA registration  0 or 1? • FEC-Scheme-Specific Information • L: Number of columns of the source block • D: Number of rows of the source block • Open Issue: Shall we define sending arrangements? Can we generalize? • ToP: Type of the protection • 0 for 1-D column-FEC protection • 1 for 1-D row-FEC protection • 2 for 2-D column and row-FEC protection • 3 is reserved • Open Issue: Shall we consider code types other than XOR? • ToF: Type of the FEC data carried in the repair flow • 0 for column FEC • 1 for row FEC • L, D and ToP are carried in SS-FSSI, and ToF is carried in RS-FSSI

  11. FEC Encoding / Decoding • FEC Encoding – Repair Packet Construction • RTP Header: Regular RTP header for the repair packet • FEC Header: Provides protection for the RTP headers of the source packets • Repair Symbols: Provides protection for the “RTP payloads” of the source packets (Variable-length packets are OK) • FEC Decoding – Source Packet Reconstruction • Step 1: Associating the source and repair packets • Step 2: Recover the RTP header and the payload • 2-D parity codes require iterative decoding (of the same algorithm used by the 1-D parity codes)

  12. Next Steps • Shall we make this draft a WG item?

More Related