draft-ietf-rmt-fec-bb-revised-04.txt   draft-ietf-rmt-fec-bb-revised-05.txt 
Reliable Multicast M. Watson Reliable Multicast M. Watson
Internet-Draft M. Luby Internet-Draft M. Luby
Intended status: Informational Digital Fountain Obsoletes: 3452 (if approved) L. Vicisano
Expires: March 8, 2007 L. Vicisano Intended status: Standards Track Digital Fountain
Cisco Systems, Inc. Expires: August 26, 2007 February 22, 2007
September 4, 2006
Forward Error Correction (FEC) Building Block Forward Error Correction (FEC) Building Block
draft-ietf-rmt-fec-bb-revised-04 draft-ietf-rmt-fec-bb-revised-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 8, 2007. This Internet-Draft will expire on August 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes how to use Forward Error Correction (FEC) This document describes how to use Forward Error Correction (FEC)
codes to efficiently provide and/or augment reliability for data codes to efficiently provide and/or augment reliability for bulk data
transport. This document defines a framework for the definition of transfer over IP multicast. This document defines a framework for
the information that needs to be communicated in order to use an FEC the definition of the information that needs to be communicated in
code for delivering content, in addition to the encoded data itself, order to use an FEC code for bulk data transfer, in addition to the
and for definition of formats and codes for communcation of that encoded data itself, and for definition of formats and codes for
information. Both information communicated with the encoded data communcation of that information. Both information communicated with
itself and information that needs to be communicated 'out-of-band' the encoded data itself and information that needs to be communicated
are considered. The procedures for specifying new FEC codes, 'out-of-band' are considered. The procedures for specifying new FEC
defining the information communication requirements associated with codes, defining the information communication requirements associated
those codes and registering them with the Internet Assigned Numbers with those codes and registering them with the Internet Assigned
Authority (IANA) are also described. The requirements on Content Numbers Authority (IANA) are also described. The requirements on
Delivery Protocols which wish to use FEC codes defined within this Content Delivery Protocols which wish to use FEC codes defined within
framework are also defined. The companion document titled, "The Use this framework are also defined. The companion document titled, "The
of Forward Error Correction (FEC) in Reliable Multicast" describes Use of Forward Error Correction (FEC) in Reliable Multicast"
some applications of FEC codes for delivering content. describes some applications of FEC codes for delivering content.
This document obsoletes RFC3452.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 5
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 4, line 33 skipping to change at page 4, line 33
Note that a 'CDP' in the context of this document may consist of Note that a 'CDP' in the context of this document may consist of
several distinct protocol mechanisms and may support any kind of several distinct protocol mechanisms and may support any kind of
application requiring reliable transport - for example object application requiring reliable transport - for example object
delivery and streaming applications. delivery and streaming applications.
This document also provides detailed guidelines on how to write an This document also provides detailed guidelines on how to write an
RFC for an FEC scheme corresponding to a new FEC Encoding ID (for RFC for an FEC scheme corresponding to a new FEC Encoding ID (for
both Fully-Specified and Under-Specified FEC Schemes). both Fully-Specified and Under-Specified FEC Schemes).
RFC3452 [3] contained a previous version of this specification, which RFC3452 [3], which is obsoleted by this document, contained a
was published in the "Experimental" category. It was the stated previous version, which was published in the "Experimental" category.
intent of the RMT working group to re-submit this specification as an It was the stated intent of the RMT working group to re-submit this
IETF Proposed Standard in due course. specification as an IETF Proposed Standard in due course.
This Proposed Standard specification is thus based on RFC3452 [3] This Proposed Standard specification is thus based on RFC3452 [3]
updated according to accumulated experience and growing protocol updated according to accumulated experience and growing protocol
maturity since the publication of RFC3452 [3]. Said experience maturity since the publication of RFC3452 [3]. Said experience
applies both to this specification itself and to congestion control applies both to this specification itself and to congestion control
strategies related to the use of this specification. strategies related to the use of this specification.
The differences between RFC3452 [3] and this document listed in The differences between RFC3452 [3] and this document listed in
Section 13 Section 13
skipping to change at page 25, line 16 skipping to change at page 25, line 16
Data delivery can be subject to denial-of-service attacks by Data delivery can be subject to denial-of-service attacks by
attackers which send corrupted packets that are accepted as attackers which send corrupted packets that are accepted as
legitimate by receivers. This is particularly a concern for legitimate by receivers. This is particularly a concern for
multicast delivery because a corrupted packet may be injected into multicast delivery because a corrupted packet may be injected into
the session close to the root of the multicast tree, in which case the session close to the root of the multicast tree, in which case
the corrupted packet will arrive to many receivers. This is the corrupted packet will arrive to many receivers. This is
particularly a concern for the FEC building block because the use of particularly a concern for the FEC building block because the use of
even one corrupted packet containing encoding data may result in the even one corrupted packet containing encoding data may result in the
decoding of an object that is completely corrupted and unusable. It decoding of an object that is completely corrupted and unusable. It
is thus RECOMMENDED that the decoded objects be checked for integrity is thus RECOMMENDED that source authentication and integrity checking
before delivering objects to an application. For example, an MD5 are applied to decoded objects before delivering objects to an
hash [7] of an object may be appended before transmission, and the application. For example, an MD5 hash [7] of an object may be
MD5 hash is computed and checked after the object is decoded but appended before transmission, and the MD5 hash is computed and
before it is delivered to an application. Moreover, in order to checked after the object is decoded but before it is delivered to an
obtain strong cryptographic integrity protection a digital signature application. Source authentication SHOULD be provided, for example
verifiable by the receiver SHOULD be computed on top of such a hash by including a digital signature verifiable by the receiver computed
value. It is also RECOMMENDED that a packet authentication protocol on top of the hash value. It is also RECOMMENDED that a packet
such as TESLA [9] be used to detect and discard corrupted packets authentication protocol such as TESLA [9] be used to detect and
upon arrival. Furthermore, it is RECOMMENDED that Reverse Path discard corrupted packets upon arrival. Furthermore, it is
Forwarding checks be enabled in all network routers and switches RECOMMENDED that Reverse Path Forwarding checks be enabled in all
along the path from the sender to receivers to limit the possibility network routers and switches along the path from the sender to
of a bad agent successfully injecting a corrupted packet into the receivers to limit the possibility of a bad agent successfully
multicast tree data path. injecting a corrupted packet into the multicast tree data path.
Another security concern is that some FEC information may be obtained Another security concern is that some FEC information may be obtained
by receivers out-of-band in a session description, and if the session by receivers out-of-band in a session description, and if the session
description is forged or corrupted then the receivers will not use description is forged or corrupted then the receivers will not use
the correct protocol for decoding content from received packets. To the correct protocol for decoding content from received packets. To
avoid these problems, it is RECOMMENDED that measures be taken to avoid these problems, it is RECOMMENDED that measures be taken to
prevent receivers from accepting incorrect session descriptions, prevent receivers from accepting incorrect session descriptions,
e.g., by using source authentication to ensure that receivers only e.g., by using source authentication to ensure that receivers only
accept legitimate session descriptions from authorized senders. accept legitimate session descriptions from authorized senders.
skipping to change at page 26, line 27 skipping to change at page 26, line 27
FEC schemes, as described in more detail in Section 6.1. FEC schemes, as described in more detail in Section 6.1.
12.1. Explicit IANA Assignment Guidelines 12.1. Explicit IANA Assignment Guidelines
This document defines a name-space for FEC Encoding IDs named: This document defines a name-space for FEC Encoding IDs named:
ietf:rmt:fec:encoding ietf:rmt:fec:encoding
The values that can be assigned within the "ietf:rmt:fec:encoding" The values that can be assigned within the "ietf:rmt:fec:encoding"
name-space are numeric indexes in the range [0, 255], boundaries name-space are numeric indexes in the range [0, 255], boundaries
included. Assignment requests are granted on a "IETF Consensus" included. Assignment requests are granted on a "IETF Consensus"
basis as defined in [2]. basis as defined in [2]. Section 7 defines explicit requirements
that documents defining new FEC Encloding IDs should meet.
This document also defines a name-space for FEC Instance IDs named: This document also defines a name-space for FEC Instance IDs named:
ietf:rmt:fec:encoding:instance ietf:rmt:fec:encoding:instance
The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space
associated with the "ietf:rmt:fec:encoding" name-space. Each value associated with the "ietf:rmt:fec:encoding" name-space. Each value
of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a
separate "ietf:rmt:fec:encoding:instance" sub-name-space that it separate "ietf:rmt:fec:encoding:instance" sub-name-space that it
scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do
not scope a "ietf:rmt:fec:encoding:instance" sub-name-space. not scope a "ietf:rmt:fec:encoding:instance" sub-name-space.
skipping to change at page 30, line 13 skipping to change at page 30, line 13
Handley, J. Crowcroft. Handley, J. Crowcroft.
15. References 15. References
15.1. Normative References 15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
15.2. Informative References 15.2. Informative References
[3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., [3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "Forward Error Correction (FEC) Building and J. Crowcroft, "Forward Error Correction (FEC) Building
Block", RFC 3452, December 2002. Block", RFC 3452, December 2002.
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "The Use of Forward Error Correction (FEC) in and J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC 3453, December 2002. Reliable Multicast", RFC 3453, December 2002.
skipping to change at page 31, line 26 skipping to change at page 31, line 26
Michael Luby Michael Luby
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
U.S.A. U.S.A.
Email: luby@digitalfountain.com Email: luby@digitalfountain.com
Lorenzo Vicisano Lorenzo Vicisano
Cisco Systems, Inc. Digital Fountain
170 West Tasman Dr. 39141 Civic Center Drive
San Jose, CA 95134 Suite 300
Fremont, CA 94538
U.S.A. U.S.A.
Email: lorenzo@cisco.com Email: lorenzo@digitalfountain.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 13 change blocks. 
51 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/