--- 1/draft-ietf-rmt-fec-bb-revised-06.txt 2007-04-19 01:12:06.000000000 +0200 +++ 2/draft-ietf-rmt-fec-bb-revised-07.txt 2007-04-19 01:12:06.000000000 +0200 @@ -1,19 +1,19 @@ Reliable Multicast M. Watson Internet-Draft M. Luby Obsoletes: 3452 (if approved) L. Vicisano Intended status: Standards Track Digital Fountain -Expires: September 21, 2007 March 20, 2007 +Expires: October 20, 2007 April 18, 2007 Forward Error Correction (FEC) Building Block - draft-ietf-rmt-fec-bb-revised-06 + draft-ietf-rmt-fec-bb-revised-07 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 21, 2007. + This Internet-Draft will expire on October 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for @@ -66,85 +66,87 @@ 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. FEC Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. FEC Object Transmission Information . . . . . . . . . . . 13 6.2.1. Transport of FEC Object Transmission Information . . . 14 6.2.2. Opacity of FEC Object Transmission Information . . . . 15 6.2.3. Mandatory FEC Object Transmission Information elements . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.4. Common FEC Object Transmission Information elements . 16 6.2.5. Scheme-specific FEC Object Transmission - Information element . . . . . . . . . . . . . . . . . 16 + Information element . . . . . . . . . . . . . . . . . 17 6.3. FEC Payload ID . . . . . . . . . . . . . . . . . . . . . . 17 - 7. FEC scheme specifications . . . . . . . . . . . . . . . . . . 18 - 8. CDP specifications . . . . . . . . . . . . . . . . . . . . . . 21 - 9. Common algorithms . . . . . . . . . . . . . . . . . . . . . . 22 - 9.1. Block partitioning algorithm . . . . . . . . . . . . . . . 22 - 9.1.1. First Step . . . . . . . . . . . . . . . . . . . . . . 22 - 9.1.2. Second step . . . . . . . . . . . . . . . . . . . . . 23 - 10. Requirements from other building blocks . . . . . . . . . . . 24 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 12.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 26 - 13. Changes from RFC3452 . . . . . . . . . . . . . . . . . . . . . 28 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 15.1. Normative References . . . . . . . . . . . . . . . . . . . 30 - 15.2. Informative References . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 - Intellectual Property and Copyright Statements . . . . . . . . . . 32 + 7. FEC scheme specifications . . . . . . . . . . . . . . . . . . 19 + 8. CDP specifications . . . . . . . . . . . . . . . . . . . . . . 22 + 9. Common algorithms . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Block partitioning algorithm . . . . . . . . . . . . . . . 23 + 9.1.1. First Step . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1.2. Second step . . . . . . . . . . . . . . . . . . . . . 24 + 10. Requirements from other building blocks . . . . . . . . . . . 25 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 12.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 27 + 13. Changes from RFC3452 . . . . . . . . . . . . . . . . . . . . . 29 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 + Intellectual Property and Copyright Statements . . . . . . . . . . 33 1. Introduction This document describes how to use Forward Error Correction (FEC) codes to provide support for reliable delivery of content within the context of a Content Delivery Protocol (CDP). This document - describes a building block as defined in [10]. This document is a - product of the IETF RMT WG and follows the general guidelines - provided in [5]. + describes a building block as defined in [10], specifically Section + 4.2 of that document and follows the general guidelines provided in + [5]. The purpose of this building block is to define a framework for forward error correction such that: 1. CDPs can be designed to operate with a range of different FEC codes/schemes, without needing to know details of the specific FEC code/scheme that may be used 2. FEC schemes can be designed to operate with a range of different CDPs, without needing to know details of the specific CDPs Note that a 'CDP' in the context of this document may consist of several distinct protocol mechanisms and may support any kind of application requiring reliable transport - for example object delivery and streaming applications. This document also provides detailed guidelines on how to write an 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 - see + Section 4). RFC3452 [3], which is obsoleted by this document, contained a previous version, which was published in the "Experimental" category. - It was the stated intent of the RMT working group to re-submit this - specification as an IETF Proposed Standard in due course. + RFC3452 was published as an Experimental RFC in part due to the lack + at that time of specified congestion control strategies suitable for + use with Reliable Multicast protocols. This Proposed Standard specification is thus based on RFC3452 [3] updated according to accumulated experience and growing protocol maturity since the publication of RFC3452 [3]. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification. The differences between RFC3452 [3] and this document listed in Section 13 2. Definitions/Abbreviations - Object: An ordered sequence of bytes to be transferred by the + Object: An ordered sequence of octets to be transferred by the transport protocol. For example, a file or stream. Symbol: A unit of data processed by the Forward Error Correction code. A symbol is always considered as a unit i.e. it is either completely received or completely lost. Source symbol: A symbol containing information from the original object. Repair symbol: A symbol containing information generated by the FEC @@ -173,79 +175,82 @@ FEC: Forward Error Correction 3. Requirements notation 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 [1]. 4. Rationale - An FEC code is a valuable basic component of any CDP that is to - provide reliable delivery of an object. Using FEC codes is effective - in the context of IP multicast and reliable delivery because FEC - encoding symbols can be useful to all receivers for reconstructing an - object even when the receivers have received different encoding - symbols. Furthermore, FEC codes can ameliorate or even eliminate the - need for feedback from receivers to senders to request retransmission - of lost packets. + An FEC code, in the general sense, is a valuable basic component of + any CDP that is to provide reliable delivery of an object. Using FEC + codes is effective in the context of IP multicast and reliable + delivery because FEC encoding symbols can be useful to all receivers + for reconstructing an object even when the receivers have received + different encoding symbols. Furthermore, FEC codes can ameliorate or + even eliminate the need for feedback from receivers to senders to + request retransmission of lost packets. - Central to this document is the concept of an 'FEC Scheme'. An FEC - scheme defines ancilliary information and procedures which, combined - with an FEC code specification, fully define how the FEC code can be - used with CDPs. An FEC scheme may be associated with a single - standardised FEC code (A 'Fully-Specified' FEC scheme) or may be - applicable to many FEC codes (An 'Under-Specified' FEC scheme). + Central to this document is the concept of an 'FEC Scheme', which we + distinguish from the concept of an 'FEC code' or 'FEC algorithm'. An + FEC scheme defines the ancillary information and procedures which, + combined with an FEC code or algorithm specification, fully define + how the FEC code can be used with CDPs. An FEC scheme may be + associated with a single standardised FEC code (A 'Fully-Specified' + FEC scheme) or may be applicable to many FEC codes (An 'Under- + Specified' FEC scheme). This document describes a framework for the definition of FEC schemes. Definition of actual FEC schemes is outside the scope of this document. This document also defines requirements for reliable CDPs that make use of FEC schemes. Any such CDP which is compliant to the requirements specified in this document can make use of any FEC scheme which is defined within the framework described here. Note that FEC schemes may place restrictions on the types of CDP they are intended to be used with. For example, some FEC schemes may be specific to particular types of application, such as file delivery or streaming. The goal of the FEC building block is to describe functionality directly related to FEC codes that is common to all reliable CDPs and to all FEC schemes, and to leave out any additional functionality that is specific to particular CDPs or particular FEC schemes. The primary functionality described in this document that is common to all such CDPs that use FEC codes is the definition and transport of three kinds of information from sender to receiver(s): encoding - symbols themselves, anciliary information associated with encoding + symbols themselves, ancillary information associated with encoding symbols (or groups of such symbols, such as the group of symbols in a single packet, or the group of symbols related to a single source - block) and anciliary information associated with the whole object - being transfered. It is important to note that this ancilliary - information is only required by the receiver if one or more of the - encoding symbols to which it relates are received. + block) and ancillary information associated with the whole object + being transferred. It is important to note that this an information + is only required by the receiver if one or more of the encoding + symbols to which it relates are received. This document for example does not describe how receivers may request transmission of particular encoding symbols for an object. This is because although there are CDPs where requests for transmission are of use, there are also CDPs that do not require such requests. The companion document [4] should be consulted for a full explanation of the benefits of using FEC codes for reliable content delivery using IP multicast. FEC codes are also useful in the context of unicast, and thus the scope and applicability of this document is not limited to IP multicast. 5. Applicability Statement The FEC building block does not provide any support for congestion control. Any complete multicast CDP MUST provide congestion control - that conforms to [6], and thus this MUST be provided by another - building block when the FEC building block is used in a CDP. + that conforms to [6], in particular Section 3.2 of that document. + Thus, congestion control MUST be provided by another building block + when the FEC building block is used in a CDP. A more complete description of the applicability of FEC codes can be found in the companion document [4]. 6. Functionality This section describes FEC information that is either to be sent in packets also containing FEC encoding symbols or 'out-of-band'. The FEC information is associated with transmission of encoding symbols related to a particular object. There are three classes of packets @@ -258,27 +263,30 @@ both data and session-control packets generally travel downstream from the sender towards receivers and are sent to a multicast channel or to a specific receiver using unicast. Session-control packets may additionally travel upstream from receivers to senders. As a general rule, feedback packets travel upstream from receivers to the sender. Sometimes, however, they might be sent to a multicast channel or to another receiver or to some intermediate node or neighboring router that provides recovery services. - This document specifies the FEC information that must be carried in - data packets and the other FEC information that must be communicated + This document specifies both the FEC information that must be carried + in data packets and the FEC information that must be communicated from sender to receiver(s) either out-of-band or in data packets. - This document does not specify out-of-band methods nor does it - specify the way out-of-band FEC information is associated with FEC - information carried in data packets. These methods must be specified - in CDP specifications that use this FEC building block. + Specification of protocol mechanisms for transporting this + information, for example field and packet formats, is out of scope of + this document. Instead, this document specifies at a higher level + the information that must be communicate and provides detailed + requirements for FEC Scheme and Content Delivery Protocol + specifications, which are where the detailed field and packet formats + should be defined. FEC information is classified as follows: 1. FEC information associated with an object This is information that is essential for the FEC decoder to decode a specific object. An example of this information is the identity of the FEC scheme that is being used to encode the object, in the form of the FEC Encoding ID. The FEC Encoding ID is described further below. This information may also include @@ -295,21 +302,21 @@ group of symbols included within a single packet. Many FEC schemes also segment the object being encoded into multiple 'source blocks', each of which is processed independently for FEC purposes. Information about each source block is another type of information associated with a group of encoding symbols, this time the group of symbols which are related to a given source block. Two 'containers' are provided for communicating the FEC information described above, but there is not necessarily a one-to-one - correspondance between the class of FEC information and the mechanism + correspondence between the class of FEC information and the mechanism used. The two mechanisms are: a. FEC Object Transmission Information CDPs must provide a reliable mechanism for communicating certain FEC information from sender to receiver(s). This information is known as 'FEC Object Transmission Information' and its contents depend on the particular FEC scheme. It includes all information of the first class above and may include information of the second class. The FEC Object Transmission Information can be @@ -349,21 +356,21 @@ same set of multicast channels and/or using a single upper-layer session. The FEC Instance ID is an integer value that identifies a specific instance of an Under-Specified FEC scheme. This value is not used for Fully-Specified FEC schemes. The FEC Instance ID is scoped by the FEC Encoding ID, and FEC Instance ID values are subject to IANA registration. The FEC Encoding ID for Fully-Specified FEC Schemes and both the FEC - Encoding ID and FEC Instance ID for Under-Specified FEc Schemes are + Encoding ID and FEC Instance ID for Under-Specified FEC Schemes are essential for the decoder to decode an object and thus are part of the FEC Object Transmission Information. The following requirements apply to all FEC schemes, whether Fully- Specified or Under-Specified: o The type, semantics and an encoding format for the FEC Payload ID and the FEC Object Transmission Information MUST be defined. o A value for the FEC Encoding ID MUST be reserved and associated @@ -424,22 +431,22 @@ Common: These elements are defined in this specification and are optional to be used by an FEC scheme. Each FEC scheme specifies which of the Common FEC Object Transmission Information elements it uses and how the values of these elements are determined. Scheme-specific: An FEC scheme may specify a single Scheme-specific FEC Object Transmission Information element. The FEC scheme specifies the type, semantics and encoding format of the Scheme- specific FEC Object Transmission Information element. The - resulting byte-string is known as the "encoded Scheme-specific FEC - Object Transmission Information". Each CDP specifies how the + resulting octet-string is known as the "encoded Scheme-specific + FEC Object Transmission Information". Each CDP specifies how the encoded Scheme-specific FEC Object Transmission is communicated reliably to the receiver(s) i.e. exactly where it shall be carried within packets of the CDP. Note that although from the point of view of this specification and of CDPs there is only a single Scheme-specific FEC Object Transmission Information element, the FEC scheme may specify this element to contain multiple distinct pieces of information. Each FEC scheme specifies an encoding format for the Common and Scheme-specific FEC Object Transmission Information. Each CDP must @@ -471,58 +478,60 @@ Common FEC Object Transmission Information elements can be transported in two different ways: (a) the FEC Scheme defines an encoding format for the Common FEC Object Transmission Information elements that it uses and the CDP transports this encoded data block, or (b) the CDP defines an encoding format for each Common FEC Object Transmission Information element and transports the information in this format. An FEC Scheme MUST define an encoding format for the Common FEC Object Transmission Information elements that it uses. The resulting - byte string is known as the "encoded Common FEC Object Transmission + octet string is known as the "encoded Common FEC Object Transmission Information". A CDP MAY define individual encoding formats for each - of the Common FEC Object Transmission Information elements. The CDP - determines which way the Common FEC Object Transmission Information - elements shall be transported, (a) or (b). Note that a CDP may - provide support for one or both options. + of the Common FEC Object Transmission Information elements. The + choice of which way the Common FEC Object Transmission Information + elements shall be transported, (a) or (b), is made by the Content + Delivery Protocol and a particular method SHOULD be defined in the + Content Delivery Protocol specification. Note that a CDP may provide + support for one or both options. In the case that the CDP uses the encoding format specified by the FEC scheme then it may simply concatenate the encoded Common FEC Object Transmission Information and the encoded Scheme-specific FEC - Object Transmission Information or it may carry each in a seperate + Object Transmission Information or it may carry each in a separate field or wrapper within the CDP. In the former case, the - concatenated byte-string is known as the encoded FEC Object + concatenated octet-string is known as the encoded FEC Object Transmission Information. The FEC scheme must define the encoding format for the Common FEC Object Transmission Information elements that it uses in such a way that the length of each element is either fixed or can be determined from the encoded data itself. The encoding format of the Scheme-specific FEC Object Transmission Information element is defined by the FEC scheme. CDPs specify only - how the resulting byte sequence is communicated. As with the - encoding format for the Common FEC Oject Transmission Information + how the resulting octet sequence is communicated. As with the + encoding format for the Common FEC Object Transmission Information elements the length of the Scheme-specific FEC Object Transmission Information must either be fixed or it must be possible to determine the length from the encoded data itself. 6.2.2. Opacity of FEC Object Transmission Information The Scheme-specific FEC Object Transmission Information element is opaque to the CDP in the sense that inspecting the contents of this element can only be done if FEC scheme-specific logic is included in the CDP. - The encoding formats defined by the FEC scheme for the Common FEC + Any encoding formats defined by the FEC scheme for the Common FEC Object Transmission Information elements are also opaque to the CDP in the same sense. - The encoding formats defined by the CDP for the Common FEC Object + Any encoding formats defined by the CDP for the Common FEC Object Transmission Information elements are not opaque in this sense, although it must be considered that different FEC Schemes may use different combinations of the Common FEC Object Transmission Information elements. 6.2.3. Mandatory FEC Object Transmission Information elements The Mandatory FEC Object Transmission Information element is: FEC Encoding ID: an integer between 0 and 255 inclusive identifying @@ -534,24 +543,24 @@ below. Note that with the exception of the FEC Instance ID, this specification does not provide complete definitions of these fields. Instead only aspects of the abstract type are defined. The precise type and semantics are defined for each FEC scheme in the FEC scheme specification. FEC Instance ID: an integer between 0 and 65535 inclusive identifying an instance of an Under-specifed FEC scheme Transfer-Length: a non-negative integer indicating the length of the - object in bytes + object in octets Encoding-Symbol-Length: a non-negative integer indicating the length - of each encoding symbol in bytes + of each encoding symbol in octets Maximum-Source-Block-Length: a non-negative integer indicating the maximum number of source symbols in a source block Max-Number-of-Encoding-Symbols: a non-negative integer indicating the maximum number of encoding symbols (i.e. source plus repair symbols in the case of a systematic code) The FEC Instance ID MUST be used by all Under-specified FEC schemes and MUST NOT be used by Fully-specified FEC Schemes. @@ -572,61 +581,66 @@ 6.2.5. Scheme-specific FEC Object Transmission Information element The Scheme-specific FEC Object Transmission Information element may be used by an FEC Scheme to communicate information which is essential to the decoder which cannot adequately be represented within the Mandatory or Common FEC Object Transmission Information elements. From the point of view of a CDP, the Scheme-specific FEC Object - Transmission Information element is an opaque, variable length, byte - string. The FEC Scheme defines the structure of this byte string, + Transmission Information element is an opaque, variable length, octet + string. The FEC Scheme defines the structure of this octet string, which may contain multiple distinct elements. 6.3. FEC Payload ID The FEC Payload ID contains information which indicates to the FEC decoder the relationships between the encoding symbols carried by a particular packet and the FEC encoding transformation. For example if the packet carries source symbols then the FEC Payload ID indicates which source symbols of the object are carried by the packet. If the packet carries repair symbols, then the FEC Payload ID indicates how those repair symbols were constructed from the object. The FEC Payload ID may also contain information about larger groups of encoding symbols of which those contained in the packet are part. For example, the FEC Payload ID may contain information about the source block the symbols are related to. The FEC Payload ID for a given packet is essential to the decoder if and only if the packet itself is received. Thus it must be possible - to obtain the FEC Payload ID from the recieved packet. Usually, the + to obtain the FEC Payload ID from the received packet. Usually, the FEC Payload ID is simply carried explicitly as a separate field - within each packet. Some FEC schemes may specify means for deriving - the relationship between the carried encoding symbols and the object - implicitly from other information within the packet, such as protocol - headers already present. Such FEC schemes could obviously only be - used with CDPs which provided the appropriate information from which - the FEC Payload ID could be derived. + within each packet. In this case the size of the FEC Payload ID + field SHOULD be a small fraction of the packet size. Some FEC + schemes may specify means for deriving the relationship between the + carried encoding symbols and the object implicitly from other + information within the packet, such as protocol headers already + present. Such FEC schemes could obviously only be used with CDPs + which provided the appropriate information from which the FEC Payload + ID could be derived. - The encoding format of the FEC Payload ID is defined by the FEC - Scheme. CDPs specify how the FEC Payload ID is carried within data - packets i.e. the position of the FEC Payload ID within the CDP packet - format and the how it is associated with encoding symbols. + The encoding format of the FEC Payload ID, including its size, is + defined by the FEC Scheme. CDPs specify how the FEC Payload ID is + carried within data packets i.e. the position of the FEC Payload ID + within the CDP packet format and the how it is associated with + encoding symbols. - FEC schemes for systematic FEC codes may specify two FEC Payload ID - formats, one for packets carrying only source symbols and another for - packets carrying at least one repair symbol. CDPs must include an - indication of which of the two FEC Payload ID formats is included in - each packet if they wish to support such FEC Schemes. + FEC schemes for systematic FEC codes, that is, those codes in which + the original source data is included within the encoded data, MAY + specify two FEC Payload ID formats, one for packets carrying only + source symbols and another for packets carrying at least one repair + symbol. CDPs must include an indication of which of the two FEC + Payload ID formats is included in each packet if they wish to support + such FEC Schemes. 7. FEC scheme specifications A specification for a new FEC scheme MUST include the following things: 1. The FEC Encoding ID value that uniquely identifies the FEC scheme. This value MUST be registered with IANA as described in Section 12. @@ -647,64 +661,64 @@ Information elements used by the FEC Scheme. Fully-Specified FEC schemes MUST further specify: 1. A full specification of the FEC code. This specification MUST precisely define the valid FEC Object Transmission Information values, the valid FEC Payload ID values and the valid packet payload sizes for any given object (where packet payload refers to the space - not necessarily contiguous - - within a packet dedicated to carrying encoding symbol bytes). + within a packet dedicated to carrying encoding symbol octets). Furthermore, given an object, valid values for each of the FEC Object Transmission Information elements used by the FEC Scheme, a valid FEC Payload ID value and a valid packet payload size, the specification MUST uniquely define the values of the encoding - symbol bytes to be included in the packet payload of a packet + symbol octets to be included in the packet payload of a packet with the given FEC Payload ID value. A common and simple way to specify the FEC code to the required level of detail is to provide a precise specification of an encoding algorithm which, given an object, valid values for each of the FEC Object Transmission Information elements used by the FEC Scheme for the object, a valid FEC Payload ID and packet payload length as input produces the exact value of the encoding - symbol bytes as output. + symbol octets as output. 2. A description of practical encoding and decoding algorithms. This description need not be to the same level of detail as for (1) above, however it must be sufficient to demonstrate that encoding and decoding of the code is both possible and practical. FEC scheme specifications MAY additionally define the following: 1. Type, semantics and encoding format of a Scheme-specific FEC Object Transmission Information element. - Note that if an FEC sheme does not define a Scheme-specific FEC + Note that if an FEC scheme does not define a Scheme-specific FEC Object Transmission Information then such an element MUST NOT be introduced in future versions of the FEC Scheme. This requirement is included to ensure backwards-compatibility of CDPs designed to support only FEC Schemes which do not use the Scheme-specific FEC Object Transmission Information element. Whenever an FEC scheme specification defines an 'encoding format' for - an element, this must be defined in terms of a sequence of bytes + an element, this must be defined in terms of a sequence of octets which can be embedded within a protocol. The length of the encoding format MUST either be fixed or it must be possible to derive the - length from examining the encoded bytes themselves. For example, the - initial bytes may include some kind of length indication. + length from examining the encoded octets themselves. For example, + the initial octets may include some kind of length indication. FEC schemes SHOULD make use of the Common FEC Object Transmission - Information elements in preference to including infomation in a + Information elements in preference to including information in a Scheme-specific FEC Object Transmission Information element. FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the following format: 1. Introduction @@ -811,23 +825,23 @@ floor[x] denotes x rounded down to the nearest integer. 9.1.1. First Step Input: B -- Maximum Source Block Length, i.e., the maximum number of source symbols per source block - L -- Transfer Length in bytes + L -- Transfer Length in octets - E -- Encoding Symbol Length in bytes + E -- Encoding Symbol Length in octets Output: T -- the number of source symbols in the object. N -- The number of source blocks into which the object shall be partitioned. Algorithm: @@ -858,25 +872,25 @@ Algorithm: 1. A_large = ceil[T/N] 2. A_small = floor[T/N] 3. I = T - A_small * N Each of the first I source blocks then consists of A_large source - symbols, each source symbol is E bytes in length. Each of the + symbols, each source symbol is E octets in length. Each of the remaining N-I source blocks consist of A_small source symbols, each - source symbol is E bytes in length except that the last source symbol - of the last source block is L-((L-1)/E) rounded down to the nearest - integer)*E bytes in length. + source symbol is E octets in length except that the last source + symbol of the last source block is L-((L-1)/E) rounded down to the + nearest integer)*E octets in length. 10. Requirements from other building blocks The FEC building block does not provide any support for congestion control. Any complete CDP MUST provide congestion control that conforms to [6], and thus this MUST be provided by another building block when the FEC building block is used in a CDP. There are no other specific requirements from other building blocks for the use of this FEC building block. However, any CDP that uses @@ -884,28 +898,28 @@ provide support for sending higher level session information within data packets containing FEC encoding symbols. 11. Security Considerations Data delivery can be subject to denial-of-service attacks by attackers which send corrupted packets that are accepted as legitimate by receivers. This is particularly a concern for multicast delivery because a corrupted packet may be injected into 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 at many receivers. This is particularly a concern for the FEC building block because the use of even one corrupted packet containing encoding data may result in the decoding of an object that is completely corrupted and unusable. It is thus RECOMMENDED that source authentication and integrity checking are applied to decoded objects before delivering objects to an - application. For example, an MD5 hash [7] of an object may be - appended before transmission, and the MD5 hash is computed and + application. For example, a SHA-1 hash [7] of an object may be + appended before transmission, and the SHA-1 hash is computed and checked after the object is decoded but before it is delivered to an application. Source authentication SHOULD be provided, for example by including a digital signature verifiable by the receiver computed on top of the hash value. It is also RECOMMENDED that a packet authentication protocol such as TESLA [9] be used to detect and discard corrupted packets upon arrival. Furthermore, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent successfully injecting a corrupted packet into the multicast tree data path. @@ -915,41 +929,46 @@ description is forged or corrupted then the receivers will not use the correct protocol for decoding content from received packets. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders. 12. IANA Considerations Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA - registration. FEC Encoding IDs and FEC Instance IDs are - hierarchical: FEC Encoding IDs scope independent ranges of FEC - Instance IDs. Only FEC Encoding IDs that correspond to Under- - Specified FEC schemes scope a corresponding set of FEC Instance IDs. + registration. They are registered in the registry named "Reliable + Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs" + located at time of publication at: + http://www.iana.org/assignments/rmt-fec-parameters + + FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding + IDs scope independent ranges of FEC Instance IDs. Only FEC Encoding + IDs that correspond to Under-Specified FEC schemes scope a + corresponding set of FEC Instance IDs. The FEC Encoding ID and FEC Instance IDs are non-negative integers. In this document, the range of values for FEC Encoding IDs is 0 to 255. Values from 0 to 127 are reserved for Fully-Specified FEC schemes and Values from 128 to 255 are reserved for Under-Specified FEC schemes, as described in more detail in Section 6.1. 12.1. Explicit IANA Assignment Guidelines This document defines a name-space for FEC Encoding IDs named: 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 included. Assignment requests are granted on a "IETF Consensus" basis as defined in [2]. Section 7 defines explicit requirements - that documents defining new FEC Encloding IDs should meet. + that documents defining new FEC Encoding IDs should meet. This document also defines a name-space for FEC Instance IDs named: ietf:rmt:fec:encoding:instance The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space associated with the "ietf:rmt:fec:encoding" name-space. Each value of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a separate "ietf:rmt:fec:encoding:instance" sub-name-space that it scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do not scope a "ietf:rmt:fec:encoding:instance" sub-name-space. @@ -999,21 +1018,21 @@ Scheme-specific) are introduced to permit re-usable definition of explicit fields in Content Delivery Protocols to carry these elements. o FEC Schemes are required to specify a complete encoding for the FEC Object Transmission which can be carried transparently by Content Delivery protocols (instead of defining explicit elements). o The possibility for FEC Schemes to define two FEC Payload ID - formats for use with souce and repair packets respectively in the + formats for use with source and repair packets respectively in the case of systematic FEC codes is introduced. o The file blocking algorithm from FLUTE is included here as a common algorithm which is recommended to be re-used by FEC Schemes when appropriate. 14. Acknowledgments This document is largely based on RFC3452 [3] and thus thanks are due to the additional authors of that document: J. Gemmell, L. Rizzo, M.