Forward Error Correction (FEC) Building Block
RFC 3452
Document | Type |
RFC - Experimental
(December 2002; No errata)
Was draft-ietf-rmt-bb-fec (rmt WG)
|
|
---|---|---|---|
Authors | Lorenzo Vicisano , Mark Handley , Jim Gemmell , Jon Crowcroft , Luigi Rizzo , Mike Luby | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3452 (Experimental) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note |
AD comments were addressed by Luby (RMT mailing list 2002-09-16) and revised i-d schedule for IESG again 2002-09-19. [Note from Allison]. Responsible: RFC Editor |
||
Send notices to | <Roger.Kermode@motorola.com> |
Network Working Group M. Luby Request for Comments: 3452 Digital Fountain Category: Experimental L. Vicisano Cisco J. Gemmell Microsoft L. Rizzo Univ. Pisa M. Handley ICIR J. Crowcroft Cambridge Univ. December 2002 Forward Error Correction (FEC) Building Block Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". Luby, et. al. Experimental [Page 1] RFC 3452 FEC Building Block December 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Functionality. . . . . . . . . . . . . . . . . . . . . . . 3 3.1 FEC Encoding ID and FEC Instance ID. . . . . . . . . . . 5 3.2 FEC Payload ID and FEC Object Transmission Information . 6 4. Applicability Statement . . . . . . . . . . . . . . . . . 7 5. Packet Header Fields . . . . . . . . . . . . . . . . . . . 8 5.1 Small Block, Large Block and Expandable FEC Codes. . . . 8 5.2 Small Block Systematic FEC Codes . . . . . . . . . . . . 9 6. Requirements from other building blocks. . . . . . . . . . 11 7. Security Considerations. . . . . . . . . . . . . . . . . . 11 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . 12 8.1 Explicit IANA Assignment Guidelines. . . . . . . . . . . 12 9. Intellectual Property Disclosure . . . . . . . . . . . . . 13 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . 14 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 13. Full Copyright Statement . . . . . . . . . . . . . . . . . 16 1. Introduction This document describes how to use Forward Error Correction (FEC) codes to provide support for reliable delivery of content using IP multicast. This document should be read in conjunction with and uses the terminology of the companion document [4], which describes the use of FEC codes within the context of reliable IP multicast transport and provides an introduction to some commonly used FEC codes. This document describes a building block as defined in RFC 3048 [9]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [3]. 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 [2]. Statement of Intent This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme. Luby, et. al. Experimental [Page 2] RFC 3452 FEC Building Block December 2002 While waiting for such a scheme to be available, or for anShow full document text