1 / 10

IETF#66 – 10-14 July 2006 FECFRAME requirements ( draft-ietf-fecframe-req-00)

This document outlines the essential requirements for a FEC framework, including support for various FEC codes, application protocols, and source data flow rates. It also details the role of FEC framework and FEC scheme in protecting data flows.

brownmark
Download Presentation

IETF#66 – 10-14 July 2006 FECFRAME requirements ( draft-ietf-fecframe-req-00)

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. IETF#66 – 10-14 July 2006FECFRAME requirements(draft-ietf-fecframe-req-00) Mark Watson

  2. Terminology • Source data flow: The packet flow or flows to which FEC protection is to be applied. • Repair data flow: The packet flow or flows carrying forward error correction data • Source protocol: A protocol used for the source data flow being protected - e.g. RTP. • Transport protocol: The protocol used for transport of the source data flow being protected - e.g. UDP, DCCP. • Application protocol: Control protocols used to establish and modify the source data flow being protected - e.g. RTSP. • FEC Code: An algorithm for encoding data such that the encoded dats flow is resilient to data loss or corruption. • FEC Scheme: A specification which defines the additional protocol aspects required to use a particular FEC code with the FEC framework, or (in the context of RMT), with the RMT FEC Building Block. • Source Block: the group of source data packets which are to be FEC protected as a single block • Protection amount: The relative increase in data sent due to the use of FEC.

  3. “SHALL” requirements(draft-fecframe-req-00) • Req-10: support a wide range of FEC codes, based on the RMT FEC Building Block. • Req-20: support a wide range of application protocols, based on the RMT FEC Building Block. • Req-30 (1st one): support variable source block sizes, including real-time variation of source block size between blocks • Req-30 (2nd one – it’s a typo!): shall support variable protection amounts, including real-time variation of protection amount • Req-40: independence from the source protocols (provided that source protocol uses one of the supported transport protocols, e.g. UDP). • Req-50: place minimal requirements on the application protocols. • Req-60: support variable source data flow rates.

  4. “SHALL” requirements ctd. • Req-70: support variable source data flow packet sizes. • Req-80: support combined protection of multiple source data flows. • Req-90: support of multiple transport protocols for the source data protocols (UDP, DCCP, others ?). • Req-100: support definition of backwards-compatible FEC protocols (i.e. where the source packets are not modified in any way). • Req-110: support for different source data protocols (RTP, MIKEY, others ?) – same as Req 40 ?? • Req-120: address the security issues, if any, associated with the use of FEC.

  5. “SHOULD” requirements ctd. • Include 3GPP protocol from TS26.346 as a sub-case

  6. Architecture question: What should be the split of responsibility between FEC Framework and FEC Scheme ? • FEC Framework • Common to all FEC codes • Preferably “IPR free” • FEC Scheme • Specific to one FEC code • May include IPR

  7. Construction of source block • In 3GPP specification, the FEC framework is responsible for constructing a source block • Source block is a sequence of fixed length “symbols” • Padding added to each packet so that packets start on symbol boundaries • Symbols are passed to FEC Scheme for encoding/decoding

  8. Source block example(3GPP framework) Source Packet Information – Packet 1 Source Packet Information – Packet 2 Source Packet Information – Packet 3 Source Packet Information – Packet 4 Source Packet Information – Packet 5 Padding Symbol FEC Framework knows about “symbols” and adds padding to form source block: Source block is the concatenation of the 17 symbols above

  9. Alternative proposal • Responsibility for “padding” and knowledge of “symbols” transferred to FEC Schemes • Information passed from FEC Framework to FEC Scheme is just the “Source Packet Information” for each packet • Symbol size, padding strategy etc. left to FEC Scheme

  10. Next steps • Update requirements draft • Start work on architecture • Add to requirements draft ? • New draft ?

More Related