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 an
Show full document text