idnits 2.17.1 draft-roca-fecframe-rs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 5034 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 399 -- Looks like a reference, but probably isn't: '1' on line 401 -- Looks like a reference, but probably isn't: '2' on line 403 -- Looks like a reference, but probably isn't: '3' on line 405 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FecFrame V. Roca 3 Internet-Draft M. Cunche 4 Intended status: Experimental INRIA 5 Expires: January 13, 2011 J. Lacan 6 A. Bouabdallah 7 ISAE/LAAS-CNRS 8 K. Matsuzono 9 Keio University 10 July 12, 2010 12 Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME 13 draft-roca-fecframe-rs-03 15 Abstract 17 This document describes two fully-specified simple FEC schemes for 18 Reed-Solomon codes that can be used to protect media streams along 19 the lines defined by the FECFRAME framework. Reed-Solomon codes 20 belong to the class of Maximum Distance Separable (MDS) codes which 21 means they offer optimal protection against packet erasures. They 22 are also systematic codes, which means that the source symbols are 23 part of the encoding symbols. The price to pay is a limit on the 24 maximum source block size, on the maximum number of encoding symbols, 25 and a computational complexity higher than that of LDPC codes for 26 instance. 28 The first scheme is for Reed-Solomon codes over GF(2^^m), with 2 <= m 29 <= 16 and arbitrary packet flows. The second scheme is similar to 30 the first scheme, with the exception that it is restricted to a 31 single sequenced flow. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 13, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Definitions Notations and Abbreviations . . . . . . . . . . . 5 70 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 73 4. Common Procedures Related to the ADU Block and Source 74 Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 9 78 5. Simple Reed-Solomon FEC Encoding Scheme over GF(2^^m) for 79 Arbitrary ADU Flows . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 11 81 5.1.1. FEC Framework Configuration Information . . . . . . . 11 82 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 12 83 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 84 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 15 86 6. Reed-Solomon FEC Encoding Scheme over GF(2^^m) for a 87 Single Sequenced ADU Flow . . . . . . . . . . . . . . . . . . 15 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 15 90 7.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 16 91 7.2.1. Access to Confidential Contents . . . . . . . . . . . 16 92 7.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 16 93 7.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 17 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 98 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 The use of Forward Error Correction (FEC) codes is a classic solution 104 to improve the reliability of unicast, multicast and broadcast 105 Content Delivery Protocols (CDP) and applications. The 106 [FECFRAME-FRAMEWORK] document describes a generic framework to use 107 FEC schemes with media delivery applications, and for instance with 108 real-time streaming media applications based on the RTP real-time 109 protocol. Similarly the [RFC5052] document describes a generic 110 framework to use FEC schemes with with objects (e.g., files) delivery 111 applications based on the ALC [RFC5775] and NORM [RFC5740] reliable 112 multicast transport protocols. 114 More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce 115 erasure codes based on sparse parity check matrices for object 116 delivery protocols like ALC and NORM. These codes are efficient in 117 terms of processing but not optimal in terms of erasure recovery 118 capabilities when dealing with "small" objects. 120 The Reed-Solomon FEC codes described in this document belong to the 121 class of Maximum Distance Separable (MDS) codes that are optimal in 122 terms of erasure recovery capability. It means that a receiver can 123 recover the k source symbols from any set of exactly k encoding 124 symbols. These codes are also systematic codes, which means that the 125 k source symbols are part of the encoding symbols. However they are 126 limited in terms of maximum source block size and number of encoding 127 symbols. Since the real-time constraints of media delivery 128 applications usually limit the maximum source block size, this is not 129 considered to be a major issue in the context of the FEC Framework 130 for many (but not necessarily all) use-cases. Additionally, if the 131 encoding/decoding complexity is higher with Reed-Solomon codes than 132 it is with [RFC5053] or [RFC5170] codes, it remains reasonable for 133 most use-cases, even in case of a software codec. 135 Many applications dealing with reliable content transmission or 136 content storage already rely on packet-based Reed-Solomon erasure 137 recovery codes. In particular, many of them use the Reed-Solomon 138 codec of Luigi Rizzo [RS-codec] [Rizzo97]. The goal of the present 139 document is to specify simple Reed-Solomon schemes that are 140 compatible with this codec. 142 More specifically, the [RFC5510] document introduced such Reed- 143 Solomon codes and several associated FEC schemes that are compatible 144 with the [RFC5052] framework. The present document inherits from 145 [RFC5510] the specification of the core Reed-Solomon codes based on 146 Vandermonde matrices, and specifies FEC schemes that are compatible 147 with the FECFRAME framework [FECFRAME-FRAMEWORK]. Therefore this 148 document specifies only the information specific to the FECFRAME 149 context and refers to [RFC5510] for the core specifications of the 150 codes. 152 To that purpose, the present document introduces: 153 o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that 154 specifies a simple way of using of Reed-Solomon codes over 155 GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for 156 arbitrary packet flows; 157 o the Fully-Specified FEC Scheme with FEC Encoding ID XXX is similar 158 to Scheme XXX except that it is for a single sequenced flow; 160 For instance, with the first (resp. second) scheme, a set of 161 Application Data Units (or ADUs) coming from one or several (resp. 162 one) media delivery applications (e.g., a set of RTP packets), are 163 grouped in a ADU block and FEC encoded as a whole. With Reed-Solomon 164 codes over GF(2^^8), there is a strict limit over the number ADUs 165 that can be protected together, since the number of encoded symbols, 166 n, must be inferior or equal to 255. This constraint is relaxed when 167 using a higher finite field size (m > 8), at the price of an 168 increased computational complexity. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 3. Definitions Notations and Abbreviations 178 3.1. Definitions 180 This document uses the following terms and definitions. Some of them 181 are FEC scheme specific and are in line with [RFC5052]: 182 Source symbol: unit of data used during the encoding process. In 183 this specification, there is always one source symbol per ADU. 184 Encoding symbol: unit of data generated by the encoding process. 185 With systematic codes, source symbols are part of the encoding 186 symbols. 187 Repair symbol: encoding symbol that is not a source symbol. 188 Code rate: the k/n ratio, i.e., the ratio between the number of 189 source symbols and the number of encoding symbols. By definition, 190 the code rate is such that: 0 < code rate <= 1. A code rate close 191 to 1 indicates that a small number of repair symbols have been 192 produced during the encoding process. 194 Systematic code: FEC code in which the source symbols are part of 195 the encoding symbols. The Reed-Solomon codes introduced in this 196 document are systematic. 197 Source block: a block of k source symbols that are considered 198 together for the encoding. 199 Packet Erasure Channel: a communication path where packets are 200 either dropped (e.g., by a congested router, or because the number 201 of transmission errors exceeds the correction capabilities of the 202 physical layer codes) or received. When a packet is received, it 203 is assumed that this packet is not corrupted. 205 Some of them are FECFRAME framework specific and are in line with 206 [FECFRAME-FRAMEWORK]: 207 Application Data Unit (ADU): a unit of data coming from (sender) or 208 given to (receiver) the media delivery application. Depending on 209 the use-case, an ADU can use an RTP encapsulation. In this 210 specification, there is always one source symbol per ADU. 211 (Source) ADU Flow: a flow of ADUs from a media delivery application 212 and to which FEC protection is applied. Depending on the use- 213 case, several ADU flows can be protected together by the FECFRAME 214 framework. 215 ADU Block: a set of ADUs that are considered together by the 216 FECFRAME instance for the purpose of the FEC scheme. Along with 217 the F[], L[], and Pad[] fields, they form the set of source 218 symbols over which FEC encoding will be performed. 219 ADU Information (ADUI): a unit of data constituted by the ADU and 220 the associated Flow ID, Length and Padding fields (Section 4.3). 221 This is the unit of data that is used as source symbols. 222 FEC Framework Configuration Information: the FEC scheme specific 223 information that enables the synchronization of the FECFRAME 224 sender and receiver instances. 225 FEC Source Packet: a data packet submitted to (sender) or received 226 from (receiver) the transport protocol. It contains an ADU along 227 with its optional Explicit Source FEC Payload ID. 228 FEC Repair Packet: a repair packet submitted to (sender) or received 229 from (receiver) the transport protocol. It contains a repair 230 symbol along with its Explicit Repair FEC Payload ID. 232 The above terminology is illustrated in Figure 1 (sender's point of 233 view): 235 +----------------------+ 236 | Application | 237 +----------------------+ 238 | 239 ADU flow | (1) Application Data Unit (ADU) 240 v 241 +----------------------+ +----------------+ 242 | FEC Framework | | | 243 | |------------------------- >| FEC Scheme | 244 |(2) Construct an ADU | (4) Source Symbols for | | 245 | block | this Source Block |(5) Perform FEC | 246 |(3) Construct ADU Info| | Encoding | 247 |(7) Construct FEC Src |< -------------------------| | 248 | Packets and FEC |(6) Ex src FEC Payload Ids,| | 249 | Repair Packets | Repair FEC Payload Ids,| | 250 +----------------------+ Repair Symbols +----------------+ 251 | | 252 |(8) FEC Src |(8') FEC Repair 253 | packets | packets 254 v v 255 +----------------------+ 256 | Transport Layer | 257 | (e.g., UDP ) | 258 +----------------------+ 260 Figure 1: Terminology used in this document (sender). 262 3.2. Notations 264 This document uses the following notations: Some of them are FEC 265 scheme specific: 266 k denotes the number of source symbols in a source block. 267 max_k denotes the maximum number of source symbols for any source 268 block. 269 n denotes the number of encoding symbols generated for a source 270 block. 271 E denotes the encoding symbol length in bytes. 272 GF(q) denotes a finite field (also known as Galois Field) with q 273 elements. We assume that q = 2^^m in this document. 274 m defines the length of the elements in the finite field, in 275 bits. In this document, m belongs to {2..16}. 276 q defines the number of elements in the finite field. We have: 277 q = 2^^m in this specification. 278 CR denotes the "code rate", i.e., the k/n ratio. 280 a^^b denotes a raised to the power b. 282 Some of them are FECFRAME framework specific: 283 B denotes the number of ADUs per ADU block. 284 max_B denotes the maximum number of ADUs for any ADU block. 286 3.3. Abbreviations 288 This document uses the following abbreviations: 289 ADU stands for Application Data Unit. 290 ESI stands for Encoding Symbol ID. 291 FEC stands for Forward Error Correction code. 292 FFCI stands for FEC Framework Configuration Information. 293 RS stands for Reed-Solomon. 294 MDS stands for Maximum Distance Separable code. 296 4. Common Procedures Related to the ADU Block and Source Block Creation 298 This section introduces the procedures that are used during the ADU 299 block and the related source block(s) creation, for the various FEC 300 schemes considered. 302 4.1. Restrictions 304 This specification has the following restrictions: 305 o there MUST be exactly one source symbol per ADU; 306 o there MUST be exactly one repair symbol per FEC Repair Packet; 307 o there MUST be exactly one source block per ADU block; 309 4.2. ADU Block Creation 311 Several aspects must be considered, that impact the ADU block 312 creation: 313 o the maximum source block size (k parameter) and number of encoding 314 symbols (n parameter), that are constrained by the finite field 315 size (m parameter); 316 o the potential real-time constraints, that impact the maximum ADU 317 block size, since the larger the block size, the larger the 318 decoding delay; 319 We now detail each of these aspects. 321 The finite field size parameter, m, defines the number of non zero 322 elements in this field which is equal to: q - 1 = 2^^m - 1. This q - 323 1 value is also the theoretical maximum number of encoding symbols 324 that can be produced for a source block. For instance, when m = 8 325 (default) there is a maximum of 2^^8 - 1 = 255 encoding symbols. So: 326 k < n <= 255. Given the target FEC code rate (e.g., provided by the 327 end-user or upper application when starting the FECFRAME framework, 328 and taking into account the (known or estimated) packet loss rate), 329 the sender calculates: 330 max_k = floor((2^^m - 1) * CR) 331 This max_k value leaves enough room for the sender to produce the 332 desired number of repair symbols. Since there is one source symbol 333 per ADU, max_k is also an upper bound to the maximum number of ADUs 334 per ADU block. 336 The source ADU flows usually have real-time constraints. It means 337 that the maximum number of ADUs of an ADU block must not exceed a 338 certain threshold since it directly impacts the decoding delay. It 339 is the role of the developer, who knows the flow real-time features, 340 to define an appropriate upper bound to the ADU block size, max_rt. 342 If we take into account these constraints, we find: max_B = 343 min(max_k, max_rt). Then max_B gives an upper bound to the number of 344 ADUs that can constitute an ADU block. 346 4.3. Source Block Creation 348 In its most general form the FECFRAME framework and the RS FEC 349 schemes are meant to protect a set of independent flows. Since the 350 flows have no relationship to one another, the ADU size of each flow 351 can potentially vary significantly. Even in the special case of a 352 single flow, the ADU sizes can largely vary (e.g., the various frames 353 of a "Group of Pictures (GOP) of an H.264 flow). This diversity must 354 be addressed since the RS FEC scheme requires a constant encoding 355 symbol size (E parameter) per source block. Since this specification 356 requires that there is only one source symbol per ADU, E must be 357 large enough to contain all the ADUs of an ADU block along with their 358 prepended 3 bytes (see below). 360 In situations where E is determined per source block (default, 361 specified by the FCCI/FSSI with S = 0, Section 5.1.1.2), E is equal 362 to the size of the largest ADU of this source block plus three (for 363 the prepended 3 bytes, see below). In this case, upon receiving the 364 first FEC Repair Packet for this source block, since this packet MUST 365 contain a single repair symbol (Section 5.1.3), a receiver determines 366 the E parameter used for this source block. 368 In situations where E is fixed (specified by the FCCI/FSSI with S = 369 1, Section 5.1.1.2), then E must be greater or equal to the size of 370 the largest ADU of this source block plus three (for the prepended 3 371 bytes, see below). If this is not the case, an error is returned. 372 How to handle this error is use-case specific (e.g., a larger E 373 parameter may be communicated to the receivers in an updated FFCI 374 message, using an appropriate mechanism) and is not considered by 375 this specification. 377 The ADU block is always encoded as a single source block. There are 378 a total of B <= max_B ADUs in this ADU block. For the ADU i, with 0 379 <= i <= B-1, 3 bytes are prepended (Figure 2): 380 o The first byte, FID[i] (Flow ID), contains the integer identifier 381 associated to the source ADU flow to which this ADU belongs to. 382 It is assumed that a single byte is sufficient, or said 383 differently, that no more than 256 flows will be protected by a 384 single instance of the FECFRAME framework. 385 o The following two bytes, L[i] (Length), contain the length of this 386 ADU, in network byte order (i.e., big endian). This length is for 387 the ADU itself and does not include the FID[i], L[i], or Pad[i] 388 fields. 390 Then zero padding is added to ADU i (if needed) in field Pad[i], for 391 alignment purposes up to a size of exactly E bytes. The data unit 392 resulting from the ADU i and the F[i], L[i] and Pad[i] fields, is 393 called ADU Information (or ADUI). Each ADUI contributes to exactly 394 one source symbol to the source block. 396 Encoding Symbol Length (E) 397 < -------------------------------------------------------------- > 398 +----+----+-----------------------+------------------------------+ 399 |F[0]|L[0]| ADU[0] | Pad[0] | 400 +----+----+----------+------------+------------------------------+ 401 |F[1]|L[1]| ADU[1] | Pad[1] | 402 +----+----+----------+-------------------------------------------+ 403 |F[2]|L[2]| ADU[2] | 404 +----+----+------+-----------------------------------------------+ 405 |F[3]|L[3]|ADU[3]| Pad[3] | 406 +----+----+------+-----------------------------------------------+ 407 \_______________________________ _______________________________/ 408 \/ 409 simple FEC encoding 411 +----------------------------------------------------------------+ 412 | Repair 4 | 413 +----------------------------------------------------------------+ 414 . . 415 . . 416 +----------------------------------------------------------------+ 417 | Repair 7 | 418 +----------------------------------------------------------------+ 420 Figure 2: Source block creation with the simple encoding scheme, for 421 code rate 1/2 (equal number of source and repair symbols, 4 in this 422 example), S = 0. 424 Note that neither the initial 3 bytes nor the optional padding are 425 sent over the network. However, they are considered during FEC 426 encoding. It means that a receiver who lost a certain FEC source 427 packet (e.g., the UDP datagram containing this FEC source packet) 428 will be able to recover the ADUI if FEC decoding succeeds. Thanks to 429 the initial 3 bytes, this receiver will get rid of the padding (if 430 any) and identify the corresponding ADU flow. 432 5. Simple Reed-Solomon FEC Encoding Scheme over GF(2^^m) for Arbitrary 433 ADU Flows 435 This Fully-Specified FEC Scheme specifies the use of Reed-Solomon 436 codes over GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding 437 for arbitrary packet flows. 439 5.1. Formats and Codes 441 5.1.1. FEC Framework Configuration Information 443 The FEC Framework Configuration Information (or FFCI) includes 444 information that MUST be communicated between the sender and 445 receiver(s). More specifically, it enables the synchronization of 446 the FECFRAME sender and receiver instances. It includes both 447 mandatory elements and scheme-specific elements, as detailed below. 449 5.1.1.1. Mandatory Information 451 o FEC Encoding ID: the value assigned to this fully-specified FEC 452 scheme MUST be XXX, as assigned by IANA (Section 8). 453 When SDP is used to communicate the FFCI, this FEC Encoding ID is 454 carried in the 'encoding-id' parameter. 456 5.1.1.2. FEC Scheme-Specific Information 458 The FEC Scheme Specific Information (FSSI) includes elements that are 459 specific to the present FEC scheme. More precisely: 460 o Encoding symbol length (E): a non-negative integer that indicates 461 either the length of each encoding symbol in bytes (strict mode, 462 i.e., if S = 1), or the maximum length of any encoding symbol 463 (i.e., if S = 0). 464 o Strict (S) flag: when set to 1 this flag indicates that the E 465 parameter is valid for the whole session, unless otherwise 466 notified. When set to 0 this flag indicates that the E parameter 467 is only the maximum length of each encoding symbol, for the whole 468 session, unless otherwise notified. 470 o m parameter (m): an integer that defines the length of the 471 elements in the finite field, in bits. We have: 2 <= m <= 16. 472 These elements are required both by the sender (RS encoder) and the 473 receiver(s) (RS decoder). 475 When SDP is used to communicate the FFCI, this FEC scheme-specific 476 information is carried in the 'fssi' parameter in textual 477 representation as specified in [SDP_ELEMENTS]. For instance: 479 fssi = E:1400,S:0,m:8 481 If another mechanism requires the FSSI to be carried as an opaque 482 octet string (for instance after a Base64 encoding), the encoding 483 format consists of the following 3 octets: 484 o Encoding symbol length (E): 16 bit field. 485 o Strict (S) flag: 1 bit field. 486 o m parameter (m): 7 bit field. 488 0 1 2 489 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Encoding Symbol Length (E) |S| m | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 3: FSSI encoding format. 496 5.1.2. Explicit Source FEC Payload ID 498 A FEC source packet MUST contain an Explicit Source FEC Payload ID 499 that is appended to the end of the packet as illustrated in Figure 4. 501 +--------------------------------+ 502 | IP Header | 503 +--------------------------------+ 504 | Transport Header | 505 +--------------------------------+ 506 | ADU | 507 +--------------------------------+ 508 | Explicit Source FEC Payload ID | 509 +--------------------------------+ 511 Figure 4: Structure of a FEC source packet with the Explicit Source 512 FEC Payload ID. 514 More precisely, the Explicit Source FEC Payload ID is composed of the 515 Source Block Number, the Encoding Symbol ID, and the Source Block 516 Length. The length of the first two fields depends on the m 517 parameter (transmitted separately in the FFCI, Section 5.1.1.2): 519 Source Block Number (SBN) (32-m bit field): this field identifies 520 the source block to which this FEC source packet belongs. 521 Encoding Symbol ID (ESI) (m bit field): this field identifies the 522 first source symbol associated to this FEC source packet in the 523 source block (remember there can be several source symbols per 524 ADUI, Section 4.3). This value is such that 0 <= ESI <= k - 1 for 525 source symbols. 526 Source Block Length (k) (16 bit field): this field provides the 527 number of source symbols for this source block, i.e., the k 528 parameter. If 16 bits are too much when m <= 8, it is needed when 529 8 < m <= 16. Therefore we provide a single common format 530 regardless of m. 532 0 1 2 3 533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Source Block Number (24 bits) | Enc. Symb. ID | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Source Block Length (k) | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Figure 5: Source FEC Payload ID encoding format for m = 8 (default). 542 0 1 2 3 543 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Source Block Length (k) | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 6: Source FEC Payload ID encoding format for m = 16. 552 The format of the Source FEC Payload ID for m = 8 and m = 16 are 553 illustrated in Figure 5 and Figure 6 respectively. 555 5.1.3. Repair FEC Payload ID 557 A FEC repair packet MUST contain a Repair FEC Payload ID that is 558 prepended to the repair symbol(s) as illustrated in Figure 7. There 559 MUST be a single repair symbol per FEC repair packet. 561 +--------------------------------+ 562 | IP Header | 563 +--------------------------------+ 564 | Transport Header | 565 +--------------------------------+ 566 | Repair FEC Payload ID | 567 +--------------------------------+ 568 | Repair Symbol | 569 +--------------------------------+ 571 Figure 7: Structure of a repair packet with the Repair FEC Payload 572 ID. 574 More precisely, the Repair FEC Payload ID is composed of the Source 575 Block Number, the Encoding Symbol ID, and the Source Block Length. 576 The length of the first two fields depends on the m parameter 577 (transmitted separately in the FFCI, Section 5.1.1.2): 578 Source Block Number (SBN) (32-m bit field): this field identifies 579 the source block to which the FEC repair packet belongs. 580 Encoding Symbol ID (ESI) (m bit field) this field identifies the 581 repair symbol contained in this FEC repair packet. This value is 582 such that k <= ESI <= n - 1 for repair symbols. 583 Source Block Length (k) (16 bit field): this field provides the 584 number of source symbols for this source block, i.e., the k 585 parameter. If 16 bits are too much when m <= 8, it is needed when 586 8 < m <= 16. Therefore we provide a single common format 587 regardless of m. 589 0 1 2 3 590 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Source Block Number (24 bits) | Enc. Symb. ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Source Block Length (k) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Figure 8: Repair FEC Payload ID encoding format for m = 8 (default). 599 0 1 2 3 600 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Source Block Length (k) | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 9: Repair FEC Payload ID encoding format for m = 16. 609 The format of the Repair FEC Payload ID for m = 8 and m = 16 are 610 illustrated in Figure 8 and Figure 9 respectively. 612 5.2. Procedures 614 The following procedures apply: 615 o The source block creation procedures are specified in Section 4.3. 616 o The SBN value is incremented for each new source block, starting 617 at 0 for the first block of the ADU flow. Wrapping to zero will 618 happen for long sessions, after value 2^^(32-m) - 1. 619 o The ESI of source symbols is managed sequentially, starting at 0 620 for the first symbol. There are a maximum of 2^^m encoding 621 symbols per block. The first k values (0 <= ESI <= k - 1) 622 identify source symbols, whereas the last n-k values (k <= ESI <= 623 n - 1) identify repair symbols. 624 o The FEC repair packet creation procedures are specified in 625 Section 5.1.3. 627 5.3. FEC Code Specification 629 The present document inherits from [RFC5510] the specification of the 630 core Reed-Solomon codes based on Vandermonde matrices for a packet 631 transmission channel. 633 6. Reed-Solomon FEC Encoding Scheme over GF(2^^m) for a Single 634 Sequenced ADU Flow 636 TBD 638 7. Security Considerations 640 7.1. Problem Statement 642 A content delivery system is potentially subject to many attacks. 643 Some of them target the network (e.g., to compromise the routing 644 infrastructure, by compromising the congestion control component), 645 others target the Content Delivery Protocol (CDP) (e.g., to 646 compromise its normal behavior), and finally some attacks target the 647 content itself. Since this document focuses on various FEC schemes, 648 this section only discusses the additional threats that their use 649 within the FECFRAME framework can create to an arbitrary CDP. 651 More specifically, these attacks may have several goals: 652 o those that are meant to give access to a confidential content 653 (e.g., in case of a non-free content), 655 o those that try to corrupt the ADU Flows being transmitted (e.g., 656 to prevent a receiver from using it), 657 o and those that try to compromise the receiver's behavior (e.g., by 658 making the decoding of an object computationally expensive). 659 These attacks can be launched either against the data flow itself 660 (e.g., by sending forged FEC Source/Repair Packets) or against the 661 FEC parameters that are sent either in-band (e.g., in the Repair FEC 662 Payload ID) or out-of-band (e.g., in a session description). 664 7.2. Attacks Against the Data Flow 666 First of all, let us consider the attacks against the data flow. 668 7.2.1. Access to Confidential Contents 670 Access control to the ADU Flow being transmitted is typically 671 provided by means of encryption. This encryption can be done within 672 the content provider itself, by the application (for instance by 673 using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or 674 at the Network Layer, on a packet per packet basis when IPSec/ESP is 675 used [RFC4303]. If confidentiality is a concern, it is RECOMMENDED 676 that one of these solutions be used. Even if we mention these 677 attacks here, they are not related nor facilitated by the use of FEC. 679 7.2.2. Content Corruption 681 Protection against corruptions (e.g., after sending forged FEC 682 Source/Repair Packets) is achieved by means of a content integrity 683 verification/sender authentication scheme. This service is usually 684 provided at the packet level. In this case, after removing all 685 forged packets, the ADU Flow may be sometimes recovered. Several 686 techniques can provide this source authentication/content integrity 687 service: 688 o at the application level, the Secure Real-time Transport Protocol 689 (SRTP) [RFC3711] provides several solutions to authenticate the 690 source and check the integrity of RTP and RTCP messages, among 691 other services. For instance, associated to the Timed Efficient 692 Stream Loss-Tolerant Authentication (TESLA) [RFC4383], SRTP is an 693 attractive solution that is robust to losses, provides a true 694 authentication/integrity service, and does not create any 695 prohibitive processing load or transmission overhead. Yet, 696 checking a packet requires a small delay (a second or more) after 697 its reception with TESLA. Other building blocks can be used 698 within SRTP to provide authentication/content integrity services. 699 o at the Network Layer, IPSec/ESP offers (among other services) an 700 integrity verification mechanism that can be used to provide 701 authentication/content integrity services. 703 It is up to the developer and deployer, who know the security 704 requirements and features of the target application area, to define 705 which solution is the most appropriate. Nonetheless it is 706 RECOMMENDED that at least one of these techniques be used. 708 7.3. Attacks Against the FEC Parameters 710 Let us now consider attacks against the FEC parameters included in 711 the FFCI that are usually sent out-of-band (e.g., in a session 712 description). Attacks on these FEC parameters can prevent the 713 decoding of the associated object. For instance modifying the m 714 field (when applicable) will lead a receiver to consider a different 715 code. Modifying the E parameter will lead a receiver to consider bad 716 Repair Symbols for a received FEC Repair Packet. 718 It is therefore RECOMMENDED that security measures be taken to 719 guarantee the FFCI integrity. When the FFCI is sent out-of-band in a 720 session description, this latter SHOULD be protected, for instance by 721 digitally signing it. 723 Attacks are also possible against some FEC parameters included in the 724 Explicit Source FEC Payload ID and Repair FEC Payload ID. For 725 instance modifying the Source Block Number of a FEC Source of Repair 726 Packet will lead a receiver to assign this packet to a wrong block. 728 It is therefore RECOMMENDED that security measures be taken to 729 guarantee the Explicit Source FEC Payload ID and Repair FEC Payload 730 ID integrity. To that purpose, one of the packet-level source 731 authentication/content integrity techniques of Section 7.2.2 can be 732 used. 734 8. IANA Considerations 736 Values of FEC Encoding IDs are subject to IANA registration. 738 TBD 740 9. Acknowledgments 742 The authors want to thank Hitoshi Asaeda for his valuable comments. 744 10. References 745 10.1. Normative References 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", RFC 2119. 750 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 751 Correction (FEC) Building Block", RFC 5052, August 2007. 753 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 754 "Reed-Solomon Forward Error Correction (FEC) Schemes", 755 RFC 5510, April 2009. 757 [FECFRAME-FRAMEWORK] 758 Watson, M., "Forward Error Correction (FEC) Framework", 759 Work in Progress, July 2010. 761 [SDP_ELEMENTS] 762 Begen, A., "SDP Elements for FEC Framework", Work 763 in Progress, April 2010. 765 10.2. Informative References 767 [RS-codec] 768 Rizzo, L., "Reed-Solomon FEC codec (revised version of 769 July 2nd, 1998), available at 770 http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz and 771 mirrored at http://planete-bcast.inrialpes.fr/", 772 July 1998. 774 [Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer 775 Communication Protocols", ACM SIGCOMM Computer 776 Communication Review Vol.27, No.2, pp.24-36, April 1997. 778 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity 779 Check (LDPC) Forward Error Correction", RFC 5170, 780 June 2008. 782 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 783 "Raptor Forward Error Correction Scheme", RFC 5053, 784 June 2007. 786 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 787 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 788 April 2010. 790 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 791 "Negative-acknowledgment (NACK)-Oriented Reliable 792 Multicast (NORM) Protocol", RFC 5740, November 2009. 794 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 795 RFC 4303, December 2005. 797 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 798 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 799 RFC 3711, March 2004. 801 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 802 Stream Loss-Tolerant Authentication (TESLA) in the Secure 803 Real-time Transport Protocol (SRTP)", RFC 4383, 804 February 2006. 806 Authors' Addresses 808 Vincent Roca 809 INRIA 810 655, av. de l'Europe 811 Inovallee; Montbonnot 812 ST ISMIER cedex 38334 813 France 815 Email: vincent.roca@inria.fr 816 URI: http://planete.inrialpes.fr/people/roca/ 818 Mathieu Cunche 819 INRIA 820 655, av. de l'Europe 821 Inovallee; Montbonnot 822 ST ISMIER cedex 38334 823 France 825 Email: mathieu.cunche@inria.fr 826 URI: http://planete.inrialpes.fr/people/cunche/ 828 Jerome Lacan 829 ISAE/LAAS-CNRS 830 1, place Emile Blouin 831 Toulouse 31056 832 France 834 Email: jerome.lacan@isae.fr 835 URI: http://dmi.ensica.fr/auteur.php3?id_auteur=5 836 Amine Bouabdallah 837 ISAE/LAAS-CNRS 838 1, place Emile Blouin 839 Toulouse 31056 840 France 842 Email: Amine.Bouabdallah@isae.fr 843 URI: http://dmi.ensica.fr/ 845 Kazuhisa Matsuzono 846 Keio University 847 Graduate School of Media and Governance 848 5322 Endo 849 Fujisawa, Kanagawa 252-8520 850 Japan 852 Email: kazuhisa@sfc.wide.ad.jp