idnits 2.17.1 draft-ietf-fecframe-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 285. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2006) is 6507 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-03 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FECFRAME Working Group Watson 3 Internet-Draft Digital Fountain 4 Expires: January 1, 2007 June 30, 2006 6 FECFRAME requirements 7 draft-ietf-fecframe-req-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 1, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines requirements for a "FEC Framework" to be 41 defined by the IETF FECFRAME working group. The object of this group 42 is primarily to develop specifications for using forward error 43 correction (FEC) codes with applications in the Internet to provide 44 protection against packet loss. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Essential requirements . . . . . . . . . . . . . . . . . . . . 6 51 4. Non-essential requirements . . . . . . . . . . . . . . . . . . 8 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 53 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 Intellectual Property and Copyright Statements . . . . . . . . . . 11 57 1. Introduction 59 This document defines requirements for a "FEC Framework" to be 60 defined by the IETF FECFRAME working group. The purpose of this 61 working group is defined in the working group charter as follows: 63 "The object of this group is to develop specifications for using 64 forward error correction (FEC) codes with applications in the 65 Internet to provide protection against packet loss. The group 66 will develop a protocol framework for application of FEC codes to 67 arbitrary packet flows over unreliable transport protocols over 68 both IP multicast and unicast." 70 This document defines requirements for this protocol framework. Both 71 'essential' ('SHALL') and 'non-essential' ('SHOULD') requirements are 72 considered. 74 A 'protocol framework' is a partial specification of a protocol, 75 along with a formal description of the missing aspects which are 76 required to form a full protocol specification - i.e. a protocol 77 framework is a protocol with 'holes' and a detailed description of 78 the 'shape' of those holes. Protocol frameworks provide for maximum 79 commonality between different complete protocols which provide 80 similar functions and therefore simplify implementation and 81 understanding of a set of alternative protocols which perform similar 82 functions. In this case, support for different complete protocols is 83 valuable for two reasons. Firstly because there exist many different 84 forward error correction codes, with different properties in terms of 85 error correction capability, computational complexity, flexibility 86 and intellectual property rights. Secondly, there are many 87 applications which could benefit from the use of forward error 88 correction. The FEC framework therefore replaces the "full mesh" of 89 application/FEC code combinations with a single general approach 90 which specifies how any FEC code meeting the FEC code requirments 91 defined in the framework can be used with any application meeting the 92 application requirements defined in the framework. 94 The FEC protocol framework must therefore define as much as possible 95 of a protocol for providing forward error correction for arbitrary 96 packet flows over unreliable transport, without defining a particular 97 FEC code or assuming a particular application. Furthermore, the 98 protocol framework specification will define a clear interface 99 between the specified parts and the unspecified, FEC-code-specific 100 and application-specific, parts. For this purpose, the building 101 block techniques applied in the Reliable Multicast (RMT) working 102 group will be re-used, specifically the FEC Building Block [I-D.ietf- 103 rmt-fec-bb-revised] 104 The term "Forward Error Correction" refers here to application/ 105 transport layer techniques for recovering lost packets of data. More 106 accurately, the term "Forward Erasure Correction" should be used. In 107 many contexts the term "Application Layer FEC (AL-FEC)" is also used, 108 although the mechanisms considered here could be considered as either 109 application or transport layer (the important point being that they 110 are end-to-end). 112 Generally, an "FEC Code" is defined in terms of the operations 113 required to construct encoded data from source data (at an encoder) 114 and to reconstruct source data from encoded data (at a decoder). In 115 order to apply an FEC Code to arbitrary packet flows, additional 116 elements are required such as protocol elements to identify encoded 117 data within packets, pre-processing of source data (e.g. segmentation 118 and/or addition of FEC-related indications into the source data). 119 Therefore, in order to adapt an FEC Code for use in the context of 120 the FEC Framework, additional FEC-code specific specification is 121 required. Following the approach of the FEC Building Block, this 122 specification is known as an "FEC Scheme". The FEC Framework will 123 define the requirements that FEC Schemes must meet for use with the 124 framework. 126 Generally, it is required to add forward error correction to existing 127 applications, for example media streaming applications. In this 128 case, the application protocols must be extended to support this. 129 The FEC framework will describe the requirements that application 130 protocols must meet in order to be used with the FEC framework. 132 This version of this document is a first draft for discussion in the 133 FECFRAME working group. 135 2. Terminology 137 'FEC' Forward Erasure Correction. 139 'AL-FEC' Application Layer Forward Erasure Correction 141 'FEC Framework' The protocol framework which is to be defined by 142 FECFRAME and for which this document provides requirements. 144 'Source data flow' The packet flow or flows to which FEC protection 145 is to be applied. 147 'Repair data flow' The packet flow or flows carrying forward error 148 correction data 150 'Source protocol' A protocol used for the source data flow being 151 protected - e.g. RTP. 153 'Transport protocol' The protocol used for transport of the source 154 data flow being protected - e.g. UDP, DCCP. 156 'Application protocol' Control protocols used to establish and modify 157 the source data flow being protected - e.g. RTSP. 159 'FEC Code' An algorithm for encoding data such that the encoded dats 160 flow is resiliant to data loss or corruption. 162 'FEC Scheme' A specification which defines the additional protocol 163 aspects required to use a particular FEC code with the FEC 164 framework, or (in the context of RMT), with the RMT FEC Building 165 Block. 167 'Source Block' the group of source data packets which are to be FEC 168 protected as a single block 170 'Protection amount' The relative increase in data sent due to the use 171 of FEC. 173 3. Essential requirements 175 Req-10: The FEC Framework shall support a wide range of FEC codes, 176 using the abstractions of the FEC Building Block defined in RMT 177 [I-D.ietf-rmt-fec-bb-revised] (including short and long block FEC 178 codes, systematic and non-systematic codes). Specifically, the 179 FEC Framework shall define the requirements that FEC code 180 specifications shall meet in order to be used with the framework, 181 re-using, as far as possible, the FEC code specification approach 182 and requirements from the FEC Building Block and specifying any 183 further requirements that must be met for the FEC Framework. 185 Req-20: The FEC Framework shall support a wide range of application 186 protocols, using the abstractions of the FEC Building Block 187 [I-D.ietf-rmt-fec-bb-revised]. Specifically, the FEC Framework 188 shall define the requirements that application protocol 189 specifications shall meet in order to be used with the framework, 190 re-using, as far as possible, the Content Delivery Protocol 191 specification approach and requirements from the FEC Building 192 Block and specifying any further requirements that must be met for 193 the FEC Framework. 195 Req-30: The FEC Framework shall support variable source block sizes, 196 including real-time variation of source block size between blocks 197 of a given source data flow. 199 Req-30: The FEC Framework shall support variable protection amounts, 200 including real-time variation of protection amount between blocks 201 within a given source data flow. 203 Req-40: The FEC Framework shall be independent of the source 204 protocols (provided that source protocol uses one of the supported 205 transport protocols). 207 Req-50: The FEC Framework shall place minimal requirements on the 208 application protocols. 210 Req-60: The FEC Framework shall support variable source data flow 211 rates. 213 Req-70: The FEC Framework shall support variable source data flow 214 packet sizes. 216 Req-80: The FEC Framework shall provide support of combined 217 protection of multiple source data flows. 219 Req-90: The FEC Framework shall provide support of multiple transport 220 protocols for the source data protocols (UDP, DCCP, others ?). 222 Req-100: The FEC Framework shall provide support for definition of 223 backwards-compatible FEC protocols (i.e. where the source packets 224 are not modified in any way). 226 Req-110: The FEC Framework shall provide support for different source 227 data protocols (RTP, MIKEY, others ?). 229 Req-120: The FEC Framework shall shall address the security issues, 230 if any, associated with the use of FEC. 232 4. Non-essential requirements 234 The FEC Framework should be constructed such that the FEC 235 streaming protocol defined by 3GPP in TS26.346 is a valid protocol 236 according to the FEC Framework. 238 5. Security Considerations 240 This document defines requirements for the work of the FECFRAME 241 working group and includes a requirement that the security 242 implications of the use of FEC, if any, should be addressed in that 243 work. 245 6. References 247 [I-D.ietf-rmt-fec-bb-revised] 248 Watson, M., "Forward Error Correction (FEC) Building 249 Block", draft-ietf-rmt-fec-bb-revised-03 (work in 250 progress), January 2006. 252 Author's Address 254 Mark Watson 255 Digital Fountain 256 39141 Civic Center Dr. 257 Suite 300 258 Fremont, CA 94538 259 US 261 Email: mark@digitalfountain.com 263 Intellectual Property Statement 265 The IETF takes no position regarding the validity or scope of any 266 Intellectual Property Rights or other rights that might be claimed to 267 pertain to the implementation or use of the technology described in 268 this document or the extent to which any license under such rights 269 might or might not be available; nor does it represent that it has 270 made any independent effort to identify any such rights. Information 271 on the procedures with respect to rights in RFC documents can be 272 found in BCP 78 and BCP 79. 274 Copies of IPR disclosures made to the IETF Secretariat and any 275 assurances of licenses to be made available, or the result of an 276 attempt made to obtain a general license or permission for the use of 277 such proprietary rights by implementers or users of this 278 specification can be obtained from the IETF on-line IPR repository at 279 http://www.ietf.org/ipr. 281 The IETF invites any interested party to bring to its attention any 282 copyrights, patents or patent applications, or other proprietary 283 rights that may cover technology that may be required to implement 284 this standard. Please address the information to the IETF at 285 ietf-ipr@ietf.org. 287 Disclaimer of Validity 289 This document and the information contained herein are provided on an 290 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 291 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 292 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 293 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 294 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 295 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 297 Copyright Statement 299 Copyright (C) The Internet Society (2006). This document is subject 300 to the rights, licenses and restrictions contained in BCP 78, and 301 except as set forth therein, the authors retain all their rights. 303 Acknowledgment 305 Funding for the RFC Editor function is currently provided by the 306 Internet Society.