1 / 13

IETF#67 – 5-10 November 2006 FECFRAME requirements ( draft-ietf-fecframe-req-01)

IETF#67 – 5-10 November 2006 FECFRAME requirements ( draft-ietf-fecframe-req-01). Mark Watson. Changes since IETF66. Add “motivation” section Why define a new Framework instead of using RMT’s FEC Building Block and RMT FEC Schemes directly ? Reasons:

patriciabrooks
Download Presentation

IETF#67 – 5-10 November 2006 FECFRAME requirements ( draft-ietf-fecframe-req-01)

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#67 – 5-10 November 2006FECFRAME requirements(draft-ietf-fecframe-req-01) Mark Watson

  2. Changes since IETF66 • Add “motivation” section • Why define a new Framework instead of using RMT’s FEC Building Block and RMT FEC Schemes directly ? • Reasons: • Some FEC Object Transmission Information will be the same for every block of the flow - RMT FEC BB doesn’t include concept of multiple related objects • RMT FEC Schemes include recommendations for setting FEC parameters - we need a place for different recommendations for the streaming case • We need a place to define formatting of stream data into blocks for processing by the FEC code • Proposal: • The FEC Framework is a “peer” to the RMT FEC Building Block • FEC Schemes for use with the FEC Framework may be different from those for use with the RMT FEC BB • Minor editorial/cleanup

  3. Next steps • More review or WGLC ? • Is this the right level of detail ? • What other issues need to be addressed ?

  4. IETF#67 – 5-10 November 2006FECFRAME proposal(draft-watson-fecframe-framework-00) Mark Watson

  5. Architecture Content Delivery Protocol Definition of flows to be protected and flow to carry protection data Rules/indications for source data partitioning/timing Application Application protocols (RTP, RTCP, MIKEY etc.) Allocates packets to source blocks Constructs and sends source and repair packets FEC Streaming Framework FEC Scheme Transport (e.g. UDP) Provides encoding and decoding of FEC data. Defines and interprets FEC signaling elements (Object Transmission Information, FEC Payload IDs) IP

  6. Proposal outline • Follows 3GPP streaming framework with generalised of source block concept • Defines: • Division of responsibility between • FEC Framework • FEC Schemes • Content Delivery Protocols • General procedures and packet format for FEC source and FEC repair packets • Includes possibility of unmodified source packets to support fully backwards-compatible FEC Schemes • FEC Framework Configuration Information • Includes SDP elements which MAY be used by Content Delivery Protocols for communicating this information • Congestion control requirements

  7. Generalisation of source block concept • FEC Framework arranges packets into “source blocks” for encoding by the FEC Scheme 3GPP Source block is a sequence of fixed length “symbols” Padding added by FEC Framework to each packet so that packets start on symbol boundaries Symbols are passed to FEC Scheme for encoding/decoding New draft proposal Source block is a sequence of tuples{ flowid, packet length, packet payload } FEC Scheme defines construction of FEC symbols

  8. Advantages of generalisation • Accommodate wider range of FEC Schemes • FEC Schemes compatible with 3GPP still possible • Associates concept of “symbols” with FEC Scheme

  9. Division of responsibilities • FEC Framework • Identifies packet flows which are to be protected • Groups source packets into source blocks • Interacts with FEC Scheme • FEC Scheme • Mapping from source block -> repair packets (encoding) • Mapping from source/repair packets -> source block (decoding) • Encoding and interpretation of FEC Object Transmission Information and FEC Payload IDs • Content Delivery Protocol • Encode and communicate FEC Configuration Information (definition of flows and flow ids)

  10. IP header IP header Transport header Transport header Transport payload FEC Payload ID FEC repair data FEC Payload ID Procedures and packet format • Descriptions taken mainly from 3GPP framework Repair Packets Source Packets

  11. FEC Framework Configuration Information • FEC Framework Configuration information consists of the following things: • Definition of the IP flows that are protected • i.e. standard source/destination address/port tuple • Definition of short flow IDs for each flow • Used to refer to flows on interface between FEC Scheme and FEC Framework • Definition of IP flow for repair data • We define SDP elements which MAY be used by CDPs to communicate this information

  12. Congestion control • Text taken from original proposal to TSVWG • Bandwidth of repair MUST NOT exceed bandwidth of the protected source • Repair bandwidth MUST be adapted when source bandwidth is adapted • Actual congestion control algorithm is a matter for the source flow

  13. Next steps • Comments ? • Other proposals ? • Accept as WG document ?

More Related