on-the-fly at the sender as the data arrives, and all packets
generated for one source block are sent before any packets are sent
for the subsequent source block. In this example, all source blocks
could be of the same length and this length could be communicated
out-of-band to a receiver before the receiver joins the session. For
this delivery model it is not required that the Source Block Numbers
for all source blocks are unique. However, a suggested usage is to
use all 2^16 Source Block Numbers for consecutive source blocks of
the object, and thus the time between reuse of a Source Block Number
is the time it takes to send the packets for 2^16 source blocks.
This delivery model can be used to reliably deliver an object to one
or multiple receivers, using either an ACK or NACK based
acknowledgement based scheme for each source block. As another
example the sender could send a fixed number of packets for each
source block without any acknowledgements from receivers, for example
in a live streaming without feedback application.
5. Security Considerations
The security considerations for this document are the same as they
are for RFC 3452 [4].
6. IANA Considerations
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA
registration. For general guidelines on IANA considerations as they
apply to this document, see RFC 3452 [4]. This document assigns the
Fully-Specified FEC Encoding ID 0 under the ietf:rmt:fec:encoding
name-space to "Compact No-Code". The FEC Payload ID format and
corresponding FEC Object Transmission Information associated with FEC
Encoding ID 0 is described in Subsections 2.1 and 2.2, and the
corresponding FEC scheme is described in Section 3.
This document assigns the Under-Specified FEC Encoding ID 130 under
the ietf:rmt:fec:encoding name-space to "Compact FEC". The FEC
Payload ID format and corresponding FEC Object Transmission
Information associated with FEC Encoding ID 130 are described in
Subsections 2.1 and 2.3.
As FEC Encoding ID 130 is Under-Specified, a new "FEC Instance ID"
sub-name-space must be established, in accordance to RFC 3452. Hence
this document also establishes a new "FEC Instance ID" registry named
ietf:rmt:fec:encoding:instance:130
and scoped by
ietf:rmt:fec:encoding = 130 (Compact FEC)
As per RFC 3452, the values that can be assigned within
ietf:rmt:fec:encoding:instance:130 are non-negative numeric indices.
Assignment requests are granted on a "First Come First Served" basis.
RFC 3452 specifies additional criteria that MUST be met for the
assignment within the generic ietf:rmt:fec:encoding:instance name-
space. These criteria also apply to
ietf:rmt:fec:encoding:instance:130.
7. References
7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation Documents", RFC 3269, April 2002.
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC 3452, December 2002.
[5] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[6] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.
and M. Luby, "Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
7.2. Informative References
[7] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC 3453, December 2002.
8. Authors’ Addresses
Michael Luby
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
EMail: luby@digitalfountain.com
Lorenzo Vicisano
cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134
EMail: lorenzo@cisco.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.