idnits 2.17.1 draft-ietf-fecframe-req-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. ** 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 issues found here. 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 (October 20, 2006) is 6398 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-04 Summary: 5 errors (**), 0 flaws (~~), 2 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 Intended status: Informational October 20, 2006 5 Expires: April 23, 2007 7 FECFRAME requirements 8 draft-ietf-fecframe-req-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 23, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines requirements for a "FEC Framework" to be 42 defined by the IETF FECFRAME working group. The object of this group 43 is primarily to develop specifications for using forward error 44 correction (FEC) codes with applications in the Internet to provide 45 protection against packet loss. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Essential requirements . . . . . . . . . . . . . . . . . . . . 8 53 5. Non-essential requirements . . . . . . . . . . . . . . . . . . 10 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 57 Intellectual Property and Copyright Statements . . . . . . . . . . 14 59 1. Introduction 61 This document defines requirements for a "FEC Framework" to be 62 defined by the IETF FECFRAME working group. The purpose of this 63 working group is defined in the working group charter as follows: 65 "The object of this group is to develop specifications for using 66 forward error correction (FEC) codes with applications in the 67 Internet to provide protection against packet loss. The group 68 will develop a protocol framework for application of FEC codes to 69 arbitrary packet flows over unreliable transport protocols over 70 both IP multicast and unicast." 72 This document defines requirements for this protocol framework. Both 73 'essential' ('SHALL') and 'non-essential' ('SHOULD') requirements are 74 considered. 76 A 'protocol framework' is a partial specification of a protocol, 77 along with a formal description of the missing aspects which are 78 required to form a full protocol specification - i.e. a protocol 79 framework is a protocol with 'holes' and a detailed description of 80 the 'shape' of those holes. Protocol frameworks provide for maximum 81 commonality between different complete protocols which provide 82 similar functions and therefore simplify implementation and 83 understanding of a set of alternative protocols which perform similar 84 functions. In this case, support for different complete protocols is 85 valuable for two reasons. Firstly because there exist many different 86 forward error correction codes, with different properties in terms of 87 error correction capability, computational complexity, flexibility 88 and intellectual property rights. Secondly, there are many 89 applications which could benefit from the use of forward error 90 correction. The FEC framework therefore replaces the "full mesh" of 91 application/FEC code combinations with a single general approach 92 which specifies how any FEC code meeting the FEC code requirments 93 defined in the framework can be used with any application meeting the 94 application requirements defined in the framework. 96 The FEC protocol framework must therefore define as much as possible 97 of a protocol for providing forward error correction for arbitrary 98 packet flows over unreliable transport, without defining a particular 99 FEC code or assuming a particular application. Furthermore, the 100 protocol framework specification will define a clear interface 101 between the specified parts and the unspecified, FEC-code-specific 102 and application-specific, parts. For this purpose, the building 103 block techniques applied in the Reliable Multicast (RMT) working 104 group will be re-used, specifically the FEC Building Block 105 [I-D.ietf-rmt-fec-bb-revised] 106 The term "Forward Error Correction" refers here to application/ 107 transport layer techniques for recovering lost packets of data. More 108 accurately, the term "Forward Erasure Correction" should be used. In 109 many contexts the term "Application Layer FEC (AL-FEC)" is also used, 110 although the mechanisms considered here could be considered as either 111 application or transport layer (the important point being that they 112 are end-to-end). 114 Generally, an "FEC Code" is defined in terms of the operations 115 required to construct encoded data from source data (at an encoder) 116 and to reconstruct source data from encoded data (at a decoder). In 117 order to apply an FEC Code to arbitrary packet flows, additional 118 elements are required such as protocol elements to identify encoded 119 data within packets, pre-processing of source data (e.g. segmentation 120 and/or addition of FEC-related indications into the source data). 121 Therefore, in order to adapt an FEC Code for use in the context of 122 the FEC Framework, additional FEC-code specific specification is 123 required. Following the approach of the FEC Building Block, this 124 specification is known as an "FEC Scheme". The FEC Framework will 125 define the requirements that FEC Schemes must meet for use with the 126 framework. 128 Generally, it is required to add forward error correction to existing 129 applications, for example media streaming applications. In this 130 case, the application protocols must be extended to support this. 131 The FEC framework will describe the requirements that application 132 protocols must meet in order to be used with the FEC framework. 134 2. Terminology 136 'FEC' Forward Erasure Correction. 138 'AL-FEC' Application Layer Forward Erasure Correction 140 'FEC Framework' The protocol framework which is to be defined by 141 FECFRAME and for which this document provides requirements. 143 'Source data flow' The packet flow or flows to which FEC protection 144 is to be applied. 146 'Repair data flow' The packet flow or flows carrying forward error 147 correction data 149 'Source protocol' A protocol used for the source data flow being 150 protected - e.g. RTP. 152 'Transport protocol' The protocol used for transport of the source 153 data flow being protected - e.g. UDP, DCCP. 155 'Control protocol' Application layer protocols used to establish and 156 modify the source data flow being protected - e.g. RTSP. 158 'FEC Code' An algorithm for encoding data such that the encoded dats 159 flow is resiliant to data loss or corruption. 161 'FEC Scheme' A specification which defines the additional protocol 162 aspects required to use a particular FEC code with the FEC 163 framework, or (in the context of RMT), with the RMT FEC Building 164 Block. 166 'Source Block' the group of source data packets which are to be FEC 167 protected as a single block 169 'Protection amount' The relative increase in data sent due to the 170 use of FEC. 172 3. Motivation 174 One approach to the problem addressed in this document would be to 175 arrange the source packet flows into a sequence of 'objects' and then 176 apply FEC protection using the mechanisms defined by the RMT working 177 group for object transport. This section describes the motivation 178 for following a separate approach, although one that draws heavily on 179 the RMT work. 181 FEC Schemes defined according to the RMT FEC Building Block 182 [I-D.ietf-rmt-fec-bb-revised] envisage objects with a finite size. 183 Mapping arbitrary flows to this environment one would need to 184 consider the flows as a sequence of such objects (also known as 185 Source Blocks). For each object, the RMT FEC Schemes expect FEC 186 Object Transmission Information to be communicated with the object. 187 In many cases some or all of this information will be the same for 188 every block. Thus there is some advantage in explicitly introducing 189 the concept of a flow (or bundle of flows) for which some or all of 190 the FEC Object Transmission Information can be the same for every 191 source block. As well as reducing overhead, it is advantageous to be 192 able to inform the receiver that these parameters won't change during 193 the lifetime of the flow or flows. 195 A second issue is that FEC Schemes in RMT generally also include 196 recommendations for parameter settings, which are based on single- 197 object delivery. Recommendations for protection of packet flows may 198 be different from these for a variety of reasons. There is a need, 199 therefore, for FEC-Scheme specific specification material which is 200 specific to the case of arbitrary packet flows and different from the 201 recommendations for single-object delivery. One of the key aspects 202 of the FEC Framework contemplated here is that it provides a context 203 for such material, in the form of an explicit description of the 204 requirements that FEC Schemes must meet in order to be used with this 205 framework. 207 A third issue is the question of how source data from a packet flow 208 or flows is formatted into data blocks that an 'object-based' FEC 209 Scheme could process. RMT FEC Schemes expect an object which is just 210 a sequence of bytes. We therefore would need to build such an object 211 out of a sequence of potentially variable-length source packets. 212 There are several ways this could be done and different FEC Schemes 213 may require different approaches. Again, the framework contemplated 214 here provides a context for the definition of these mechanisms 215 through the concept of FEC Schemes which are adapted for use with 216 this framework. The RMT work then envisages that both source packets 217 and repair packets consist of symbols which are extracted from or 218 generated from (respectively) this source block. In the case of FEC 219 protection of arbitrary packet flows it is desirable to support cases 220 where the source packets are transmitted unchanged, thereby providing 221 backwards compatibility. This is not compatible with in the RMT 222 approach. 224 As a result of the considerations above, this document describes 225 requirements for an FEC Framework for arbitrary packet flows which is 226 independent of the RMT FEC Building Block, although we draw heavily 227 on the concepts developed there. FEC Schemes defined for use with 228 this FEC Framework are distinct from FEC Schemes defined for object 229 delivery in the context of the RMT FEC Building Block. However, it 230 is expected that in many cases the task of generalising an RMT FEC 231 Scheme into one which can be used with both the RMT protocols and 232 this FEC Framework will be a simple one. 234 4. Essential requirements 236 Req-10: The FEC Framework shall support a wide range of FEC codes, 237 using the abstractions of the FEC Building Block defined in RMT 238 [I-D.ietf-rmt-fec-bb-revised] (including short and long block FEC 239 codes, systematic and non-systematic codes). Specifically, the 240 FEC Framework shall define the requirements that FEC code 241 specifications shall meet in order to be used with the framework, 242 re-using, as far as possible, the FEC code specification approach 243 and requirements from the FEC Building Block and specifying any 244 further requirements that must be met for the FEC Framework. 246 Req-20: The FEC Framework shall support a wide range of application 247 protocols, using the abstractions of the FEC Building Block 248 [I-D.ietf-rmt-fec-bb-revised]. Specifically, the FEC Framework 249 shall define the requirements that application protocol 250 specifications shall meet in order to be used with the framework, 251 re-using, as far as possible, the Content Delivery Protocol 252 specification approach and requirements from the FEC Building 253 Block and specifying any further requirements that must be met for 254 the FEC Framework. 256 Req-30: The FEC Framework shall support variable source block sizes, 257 including real-time variation of source block size between blocks 258 of a given source data flow. 260 Req-35: The FEC Framework shall support variable protection amounts, 261 including dynamic variation of protection amount between blocks 262 within a given source data flow. 264 Req-40: The FEC Framework shall be independent of the source 265 protocols (provided that source protocol uses one of the supported 266 transport protocols). 268 Req-50: The FEC Framework shall place minimal requirements on the 269 application protocols. 271 Req-60: The FEC Framework shall support variable source data flow 272 rates. 274 Req-70: The FEC Framework shall support variable source data flow 275 packet sizes. 277 Req-80: The FEC Framework shall provide support of combined 278 protection of multiple source data flows. 280 Req-90: The FEC Framework shall provide support of multiple 281 transport protocols for the source data protocols (UDP, DCCP, 282 others ?). 284 Req-100: The FEC Framework shall provide support for definition of 285 backwards-compatible FEC protocols (i.e. where the source packets 286 are not modified in any way). 288 Req-110: The FEC Framework shall provide support for different 289 source data protocols (RTP, MIKEY, others ?). 291 Req-120: The FEC Framework shall shall address the security issues, 292 if any, associated with the use of FEC. 294 5. Non-essential requirements 296 The FEC Framework should be constructed such that the FEC 297 streaming protocol defined by 3GPP in TS26.346 is a valid protocol 298 according to the FEC Framework. 300 6. Security Considerations 302 This document defines requirements for the work of the FECFRAME 303 working group and includes a requirement that the security 304 implications of the use of FEC, if any, should be addressed in that 305 work. 307 7. References 309 [I-D.ietf-rmt-fec-bb-revised] 310 Watson, M., "Forward Error Correction (FEC) Building 311 Block", draft-ietf-rmt-fec-bb-revised-04 (work in 312 progress), September 2006. 314 Author's Address 316 Mark Watson 317 Digital Fountain 318 39141 Civic Center Dr. 319 Suite 300 320 Fremont, CA 94538 321 US 323 Email: mark@digitalfountain.com 325 Full Copyright Statement 327 Copyright (C) The Internet Society (2006). 329 This document is subject to the rights, licenses and restrictions 330 contained in BCP 78, and except as set forth therein, the authors 331 retain all their rights. 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 336 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 337 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 338 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Intellectual Property 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at 363 ietf-ipr@ietf.org. 365 Acknowledgment 367 Funding for the RFC Editor function is provided by the IETF 368 Administrative Support Activity (IASA).