idnits 2.17.1 draft-ietf-fecframe-simple-rs-00.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 (February 28, 2011) is 4807 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) -- Looks like a reference, but probably isn't: '0' on line 396 -- Looks like a reference, but probably isn't: '1' on line 398 -- Looks like a reference, but probably isn't: '2' on line 400 -- Looks like a reference, but probably isn't: '3' on line 402 == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FecFrame V. Roca 3 Internet-Draft INRIA 4 Intended status: Standards Track M. Cunche 5 Expires: September 1, 2011 NICTA 6 J. Lacan 7 A. Bouabdallah 8 ISAE/LAAS-CNRS 9 K. Matsuzono 10 Keio University 11 February 28, 2011 13 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME 14 draft-ietf-fecframe-simple-rs-00 16 Abstract 18 This document describes a fully-specified simple FEC scheme for Reed- 19 Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to 20 protect arbitrary media streams along the lines defined by the 21 FECFRAME framework. Reed-Solomon codes belong to the class of 22 Maximum Distance Separable (MDS) codes which means they offer optimal 23 protection against packet erasures. They are also systematic codes, 24 which means that the source symbols are part of the encoding symbols. 25 The price to pay is a limit on the maximum source block size, on the 26 maximum number of encoding symbols, and a computational complexity 27 higher than that of LDPC codes for instance. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 1, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Definitions Notations and Abbreviations . . . . . . . . . . . 5 66 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Common Procedures Related to the ADU Block and Source 70 Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 8 73 4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 9 74 5. Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary 75 ADU Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 11 77 5.1.1. FEC Framework Configuration Information . . . . . . . 11 78 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 12 79 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 80 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 15 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 15 84 6.1.1. Access to Confidential Content . . . . . . . . . . . . 15 85 6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 16 86 6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 16 87 6.3. When Several Source Flows are to be Protected Together . . 17 88 6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 17 89 7. Operations and Management Considerations . . . . . . . . . . . 17 90 7.1. Finite Field Size (m) Recommendations . . . . . . . . . . 17 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 The use of Forward Error Correction (FEC) codes is a classic solution 102 to improve the reliability of unicast, multicast and broadcast 103 Content Delivery Protocols (CDP) and applications. The 104 [FECFRAME-FRAMEWORK] document describes a generic framework to use 105 FEC schemes with media delivery applications, and for instance with 106 real-time streaming media applications based on the RTP real-time 107 protocol. Similarly the [RFC5052] document describes a generic 108 framework to use FEC schemes with with objects (e.g., files) delivery 109 applications based on the ALC [RFC5775] and NORM [RFC5740] reliable 110 multicast transport protocols. 112 More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce 113 erasure codes based on sparse parity check matrices for object 114 delivery protocols like ALC and NORM. These codes are efficient in 115 terms of processing but not optimal in terms of erasure recovery 116 capabilities when dealing with "small" objects. 118 The Reed-Solomon FEC codes described in this document belong to the 119 class of Maximum Distance Separable (MDS) codes that are optimal in 120 terms of erasure recovery capability. It means that a receiver can 121 recover the k source symbols from any set of exactly k encoding 122 symbols. These codes are also systematic codes, which means that the 123 k source symbols are part of the encoding symbols. However they are 124 limited in terms of maximum source block size and number of encoding 125 symbols. Since the real-time constraints of media delivery 126 applications usually limit the maximum source block size, this is not 127 considered to be a major issue in the context of the FEC Framework 128 for many (but not necessarily all) use-cases. Additionally, if the 129 encoding/decoding complexity is higher with Reed-Solomon codes than 130 it is with [RFC5053] or [RFC5170] codes, it remains reasonable for 131 most use-cases, even in case of a software codec. 133 Many applications dealing with reliable content transmission or 134 content storage already rely on packet-based Reed-Solomon erasure 135 recovery codes. In particular, many of them use the Reed-Solomon 136 codec of Luigi Rizzo [RS-codec] [Rizzo97]. The goal of the present 137 document is to specify a simple Reed-Solomon scheme that is 138 compatible with this codec. 140 More specifically, the [RFC5510] document introduced such Reed- 141 Solomon codes and several associated FEC schemes that are compatible 142 with the [RFC5052] framework. The present document inherits from 143 [RFC5510] the specification of the core Reed-Solomon codes based on 144 Vandermonde matrices, and specifies a simple FEC scheme that is 145 compatible with the FECFRAME framework [FECFRAME-FRAMEWORK]. 146 Therefore this document specifies only the information specific to 147 the FECFRAME context and refers to [RFC5510] for the core 148 specifications of the codes. To that purpose, the present document 149 introduces: 150 o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that 151 specifies a simple way of using of Reed-Solomon codes over 152 GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for 153 arbitrary packet flows; 155 For instance, with this scheme, a set of Application Data Units (or 156 ADUs) coming from one or several (resp. one) media delivery 157 applications (e.g., a set of RTP packets), are grouped in an ADU 158 block and FEC encoded as a whole. With Reed-Solomon codes over 159 GF(2^^8), there is a strict limit over the number of ADUs that can be 160 protected together, since the number of encoded symbols, n, must be 161 inferior or equal to 255. This constraint is relaxed when using a 162 higher finite field size (m > 8), at the price of an increased 163 computational complexity. 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 3. Definitions Notations and Abbreviations 173 3.1. Definitions 175 This document uses the following terms and definitions. Some of them 176 are FEC scheme specific and are in line with [RFC5052]: 177 Source symbol: unit of data used during the encoding process. In 178 this specification, there is always one source symbol per ADU. 179 Encoding symbol: unit of data generated by the encoding process. 180 With systematic codes, source symbols are part of the encoding 181 symbols. 182 Repair symbol: encoding symbol that is not a source symbol. 183 Code rate: the k/n ratio, i.e., the ratio between the number of 184 source symbols and the number of encoding symbols. By definition, 185 the code rate is such that: 0 < code rate <= 1. A code rate close 186 to 1 indicates that a small number of repair symbols have been 187 produced during the encoding process. 188 Systematic code: FEC code in which the source symbols are part of 189 the encoding symbols. The Reed-Solomon codes introduced in this 190 document are systematic. 192 Source block: a block of k source symbols that are considered 193 together for the encoding. 194 Packet Erasure Channel: a communication path where packets are 195 either dropped (e.g., by a congested router, or because the number 196 of transmission errors exceeds the correction capabilities of the 197 physical layer codes) or received. When a packet is received, it 198 is assumed that this packet is not corrupted. 200 Some of them are FECFRAME framework specific and are in line with 201 [FECFRAME-FRAMEWORK]: 202 Application Data Unit (ADU): a unit of data coming from (sender) or 203 given to (receiver) the media delivery application. Depending on 204 the use-case, an ADU can use an RTP encapsulation. In this 205 specification, there is always one source symbol per ADU. 206 (Source) ADU Flow: a flow of ADUs from a media delivery application 207 and to which FEC protection is applied. Depending on the use- 208 case, several ADU flows can be protected together by the FECFRAME 209 framework. 210 ADU Block: a set of ADUs that are considered together by the 211 FECFRAME instance for the purpose of the FEC scheme. Along with 212 the F[], L[], and Pad[] fields, they form the set of source 213 symbols over which FEC encoding will be performed. 214 ADU Information (ADUI): a unit of data constituted by the ADU and 215 the associated Flow ID, Length and Padding fields (Section 4.3). 216 This is the unit of data that is used as source symbol. 217 FEC Framework Configuration Information: the FEC scheme specific 218 information that enables the synchronization of the FECFRAME 219 sender and receiver instances. 220 FEC Source Packet: a data packet submitted to (sender) or received 221 from (receiver) the transport protocol. It contains an ADU along 222 with its optional Explicit Source FEC Payload ID. 223 FEC Repair Packet: a repair packet submitted to (sender) or received 224 from (receiver) the transport protocol. It contains a repair 225 symbol along with its Repair FEC Payload ID. 227 The above terminology is illustrated in Figure 1 (sender's point of 228 view): 230 +----------------------+ 231 | Application | 232 +----------------------+ 233 | 234 ADU flow | (1) Application Data Unit (ADU) 235 v 236 +----------------------+ +----------------+ 237 | FEC Framework | | | 238 | |------------------------- >| FEC Scheme | 239 |(2) Construct an ADU | (4) Source Symbols for | | 240 | block | this Source Block |(5) Perform FEC | 241 |(3) Construct ADU Info| | Encoding | 242 |(7) Construct FEC Src |< -------------------------| | 243 | Packets and FEC |(6) Ex src FEC Payload Ids,| | 244 | Repair Packets | Repair FEC Payload Ids,| | 245 +----------------------+ Repair Symbols +----------------+ 246 | | 247 |(8) FEC Src |(8') FEC Repair 248 | packets | packets 249 v v 250 +----------------------+ 251 | Transport Layer | 252 | (e.g., UDP ) | 253 +----------------------+ 255 Figure 1: Terminology used in this document (sender). 257 3.2. Notations 259 This document uses the following notations: Some of them are FEC 260 scheme specific: 261 k denotes the number of source symbols in a source block. 262 max_k denotes the maximum number of source symbols for any source 263 block. 264 n denotes the number of encoding symbols generated for a source 265 block. 266 E denotes the encoding symbol length in bytes. 267 GF(q) denotes a finite field (also known as Galois Field) with q 268 elements. We assume that q = 2^^m in this document. 269 m defines the length of the elements in the finite field, in 270 bits. In this document, m is such that 2 <= m <= 16. 271 q defines the number of elements in the finite field. We have: 272 q = 2^^m in this specification. 273 CR denotes the "code rate", i.e., the k/n ratio. 275 a^^b denotes a raised to the power b. 277 Some of them are FECFRAME framework specific: 278 B denotes the number of ADUs per ADU block. 279 max_B denotes the maximum number of ADUs for any ADU block. 281 3.3. Abbreviations 283 This document uses the following abbreviations: 284 ADU stands for Application Data Unit. 285 ESI stands for Encoding Symbol ID. 286 FEC stands for Forward Error (or Erasure) Correction code. 287 FFCI stands for FEC Framework Configuration Information. 288 FSSI stands for FEC Scheme Specific Information. 289 RS stands for Reed-Solomon. 290 MDS stands for Maximum Distance Separable code. 292 4. Common Procedures Related to the ADU Block and Source Block Creation 294 This section introduces the procedures that are used during the ADU 295 block and the related source block creation, for the FEC scheme 296 considered. 298 4.1. Restrictions 300 This specification has the following restrictions: 301 o there MUST be exactly one source symbol per ADUI, and therefore 302 per ADU; 303 o there MUST be exactly one repair symbol per FEC Repair Packet; 304 o there MUST be exactly one source block per ADU block; 306 4.2. ADU Block Creation 308 Several aspects must be considered, that impact the ADU block 309 creation: 310 o the maximum source block size (k parameter) and number of encoding 311 symbols (n parameter), that are constrained by the finite field 312 size (m parameter); 313 o the potential real-time constraints, that impact the maximum ADU 314 block size, since the larger the block size, the larger the 315 decoding delay; 316 We now detail each of these aspects. 318 The finite field size parameter, m, defines the number of non zero 319 elements in this field which is equal to: q - 1 = 2^^m - 1. This q - 320 1 value is also the theoretical maximum number of encoding symbols 321 that can be produced for a source block. For instance, when m = 8 322 (default) there is a maximum of 2^^8 - 1 = 255 encoding symbols. So: 323 k < n <= 255. Given the target FEC code rate (e.g., provided by the 324 end-user or upper application when starting the FECFRAME framework, 325 and taking into account the (known or estimated) packet loss rate), 326 the sender calculates: 327 max_k = floor((2^^m - 1) * CR) 328 This max_k value leaves enough room for the sender to produce the 329 desired number of repair symbols. Since there is one source symbol 330 per ADU, max_k is also an upper bound to the maximum number of ADUs 331 per ADU block. 333 The source ADU flows usually have real-time constraints. It means 334 that the maximum number of ADUs of an ADU block must not exceed a 335 certain threshold since it directly impacts the decoding delay. It 336 is the role of the developer, who knows the flow real-time features, 337 to define an appropriate upper bound to the ADU block size, max_rt. 339 If we take into account these constraints, we find: max_B = 340 min(max_k, max_rt). Then max_B gives an upper bound to the number of 341 ADUs that can constitute an ADU block. 343 4.3. Source Block Creation 345 In its most general form the FECFRAME framework and the RS FEC scheme 346 are meant to protect a set of independent flows. Since the flows 347 have no relationship to one another, the ADU size of each flow can 348 potentially vary significantly. Even in the special case of a single 349 flow, the ADU sizes can largely vary (e.g., the various frames of a 350 "Group of Pictures (GOP) of an H.264 flow). This diversity must be 351 addressed since the RS FEC scheme requires a constant encoding symbol 352 size (E parameter) per source block. Since this specification 353 requires that there is only one source symbol per ADU, E must be 354 large enough to contain all the ADUs of an ADU block along with their 355 prepended 3 bytes (see below). 357 In situations where E is determined per source block (default, 358 specified by the FFCI/FSSI with S = 0, Section 5.1.1.2), E is equal 359 to the size of the largest ADU of this source block plus three (for 360 the prepended 3 bytes, see below). In this case, upon receiving the 361 first FEC Repair Packet for this source block, since this packet MUST 362 contain a single repair symbol (Section 5.1.3), a receiver determines 363 the E parameter used for this source block. 365 In situations where E is fixed (specified by the FFCI/FSSI with S = 366 1, Section 5.1.1.2), then E must be greater or equal to the size of 367 the largest ADU of this source block plus three (for the prepended 3 368 bytes, see below). If this is not the case, an error is returned. 369 How to handle this error is use-case specific (e.g., a larger E 370 parameter may be communicated to the receivers in an updated FFCI 371 message, using an appropriate mechanism) and is not considered by 372 this specification. 374 The ADU block is always encoded as a single source block. There are 375 a total of B <= max_B ADUs in this ADU block. For the ADU i, with 0 376 <= i <= B-1, 3 bytes are prepended (Figure 2): 377 o The first byte, FID[i] (Flow ID), contains the integer identifier 378 associated to the source ADU flow to which this ADU belongs to. 379 It is assumed that a single byte is sufficient, or said 380 differently, that no more than 256 flows will be protected by a 381 single instance of the FECFRAME framework. 382 o The following two bytes, L[i] (Length), contain the length of this 383 ADU, in network byte order (i.e., big endian). This length is for 384 the ADU itself and does not include the FID[i], L[i], or Pad[i] 385 fields. 387 Then zero padding is added to ADU i (if needed) in field Pad[i], for 388 alignment purposes up to a size of exactly E bytes. The data unit 389 resulting from the ADU i and the F[i], L[i] and Pad[i] fields, is 390 called ADU Information (or ADUI). Each ADUI contributes to exactly 391 one source symbol to the source block. 393 Encoding Symbol Length (E) 394 < -------------------------------------------------------------- > 395 +----+----+-----------------------+------------------------------+ 396 |F[0]|L[0]| ADU[0] | Pad[0] | 397 +----+----+----------+------------+------------------------------+ 398 |F[1]|L[1]| ADU[1] | Pad[1] | 399 +----+----+----------+-------------------------------------------+ 400 |F[2]|L[2]| ADU[2] | 401 +----+----+------+-----------------------------------------------+ 402 |F[3]|L[3]|ADU[3]| Pad[3] | 403 +----+----+------+-----------------------------------------------+ 404 \_______________________________ _______________________________/ 405 \/ 406 simple FEC encoding 408 +----------------------------------------------------------------+ 409 | Repair 4 | 410 +----------------------------------------------------------------+ 411 . . 412 . . 413 +----------------------------------------------------------------+ 414 | Repair 7 | 415 +----------------------------------------------------------------+ 417 Figure 2: Source block creation, for code rate 1/2 (equal number of 418 source and repair symbols, 4 in this example), and S = 0. 420 Note that neither the initial 3 bytes nor the optional padding are 421 sent over the network. However, they are considered during FEC 422 encoding. It means that a receiver who lost a certain FEC source 423 packet (e.g., the UDP datagram containing this FEC source packet) 424 will be able to recover the ADUI if FEC decoding succeeds. Thanks to 425 the initial 3 bytes, this receiver will get rid of the padding (if 426 any) and identify the corresponding ADU flow. 428 5. Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary ADU Flows 430 This Fully-Specified FEC Scheme specifies the use of Reed-Solomon 431 codes over GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding 432 for arbitrary packet flows. 434 5.1. Formats and Codes 436 5.1.1. FEC Framework Configuration Information 438 The FEC Framework Configuration Information (or FFCI) includes 439 information that MUST be communicated between the sender and 440 receiver(s). More specifically, it enables the synchronization of 441 the FECFRAME sender and receiver instances. It includes both 442 mandatory elements and scheme-specific elements, as detailed below. 444 5.1.1.1. Mandatory Information 446 FEC Encoding ID: the value assigned to this fully-specified FEC 447 scheme MUST be XXX, as assigned by IANA (Section 8). 448 When SDP is used to communicate the FFCI, this FEC Encoding ID is 449 carried in the 'encoding-id' parameter. 451 5.1.1.2. FEC Scheme-Specific Information 453 The FEC Scheme Specific Information (FSSI) includes elements that are 454 specific to the present FEC scheme. More precisely: 455 Encoding symbol length (E): a non-negative integer that indicates 456 either the length of each encoding symbol in bytes (strict mode, 457 i.e., if S = 1), or the maximum length of any encoding symbol 458 (i.e., if S = 0). 459 Strict (S) flag: when set to 1 this flag indicates that the E 460 parameter is the actual encoding symbol length value for each 461 block of the session (unless otherwise notified by an updated FFCI 462 if this possibility is considered by the use-case or CDP). When 463 set to 0 this flag indicates that the E parameter is the maximum 464 encoding symbol length value for each block of the session (unless 465 otherwise notified by an updated FFCI if this possibility is 466 considered by the use-case or CDP). 467 m parameter (m): an integer that defines the length of the elements 468 in the finite field, in bits. We have: 2 <= m <= 16. 469 These elements are required both by the sender (RS encoder) and the 470 receiver(s) (RS decoder). 472 When SDP is used to communicate the FFCI, this FEC scheme-specific 473 information is carried in the 'fssi' parameter in textual 474 representation as specified in [SDP_ELEMENTS]. For instance: 476 fssi = E:1400,S:0,m:8 478 If another mechanism requires the FSSI to be carried as an opaque 479 octet string (for instance after a Base64 encoding), the encoding 480 format consists of the following 3 octets: 481 o Encoding symbol length (E): 16 bit field. 482 o Strict (S) flag: 1 bit field. 483 o m parameter (m): 7 bit field. 485 0 1 2 486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Encoding Symbol Length (E) |S| m | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 3: FSSI encoding format. 493 5.1.2. Explicit Source FEC Payload ID 495 A FEC source packet MUST contain an Explicit Source FEC Payload ID 496 that is appended to the end of the packet as illustrated in Figure 4. 498 +--------------------------------+ 499 | IP Header | 500 +--------------------------------+ 501 | Transport Header | 502 +--------------------------------+ 503 | ADU | 504 +--------------------------------+ 505 | Explicit Source FEC Payload ID | 506 +--------------------------------+ 508 Figure 4: Structure of a FEC Source Packet with the Explicit Source 509 FEC Payload ID. 511 More precisely, the Explicit Source FEC Payload ID is composed of the 512 Source Block Number, the Encoding Symbol ID, and the Source Block 513 Length. The length of the first two fields depends on the m 514 parameter (transmitted separately in the FFCI, Section 5.1.1.2): 515 Source Block Number (SBN) (32-m bit field): this field identifies 516 the source block to which this FEC source packet belongs. 517 Encoding Symbol ID (ESI) (m bit field): this field identifies the 518 source symbol contained in this FEC source packet. This value is 519 such that 0 <= ESI <= k - 1 for source symbols. 520 Source Block Length (k) (16 bit field): this field provides the 521 number of source symbols for this source block, i.e., the k 522 parameter. If 16 bits are too much when m <= 8, it is needed when 523 8 < m <= 16. Therefore we provide a single common format 524 regardless of m. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Source Block Number (24 bits) | Enc. Symb. ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Source Block Length (k) | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Figure 5: Source FEC Payload ID encoding format for m = 8 (default). 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Source Block Length (k) | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 6: Source FEC Payload ID encoding format for m = 16. 546 The format of the Source FEC Payload ID for m = 8 and m = 16 are 547 illustrated in Figure 5 and Figure 6 respectively. 549 5.1.3. Repair FEC Payload ID 551 A FEC repair packet MUST contain a Repair FEC Payload ID that is 552 prepended to the repair symbol(s) as illustrated in Figure 7. There 553 MUST be a single repair symbol per FEC repair packet. 555 +--------------------------------+ 556 | IP Header | 557 +--------------------------------+ 558 | Transport Header | 559 +--------------------------------+ 560 | Repair FEC Payload ID | 561 +--------------------------------+ 562 | Repair Symbol | 563 +--------------------------------+ 565 Figure 7: Structure of a FEC Repair Packet with the Repair FEC 566 Payload ID. 568 More precisely, the Repair FEC Payload ID is composed of the Source 569 Block Number, the Encoding Symbol ID, and the Source Block Length. 570 The length of the first two fields depends on the m parameter 571 (transmitted separately in the FFCI, Section 5.1.1.2): 572 Source Block Number (SBN) (32-m bit field): this field identifies 573 the source block to which the FEC repair packet belongs. 574 Encoding Symbol ID (ESI) (m bit field) this field identifies the 575 repair symbol contained in this FEC repair packet. This value is 576 such that k <= ESI <= n - 1 for repair symbols. 577 Source Block Length (k) (16 bit field): this field provides the 578 number of source symbols for this source block, i.e., the k 579 parameter. If 16 bits are too much when m <= 8, it is needed when 580 8 < m <= 16. Therefore we provide a single common format 581 regardless of m. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Source Block Number (24 bits) | Enc. Symb. ID | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Source Block Length (k) | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 8: Repair FEC Payload ID encoding format for m = 8 (default). 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Source Block Length (k) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 9: Repair FEC Payload ID encoding format for m = 16. 603 The format of the Repair FEC Payload ID for m = 8 and m = 16 are 604 illustrated in Figure 8 and Figure 9 respectively. 606 5.2. Procedures 608 The following procedures apply: 609 o The source block creation procedures are specified in Section 4.3. 610 o The SBN value is incremented for each new source block, starting 611 at 0 for the first block of the ADU flow. Wrapping to zero will 612 happen for long sessions, after value 2^^(32-m) - 1. 613 o The ESI of encoding symbols is managed sequentially, starting at 0 614 for the first symbol. The first k values (0 <= ESI <= k - 1) 615 identify source symbols, whereas the last n-k values (k <= ESI <= 616 n - 1) identify repair symbols. 617 o The FEC repair packet creation procedures are specified in 618 Section 5.1.3. 620 5.3. FEC Code Specification 622 The present document inherits from [RFC5510] the specification of the 623 core Reed-Solomon codes based on Vandermonde matrices for a packet 624 transmission channel. 626 6. Security Considerations 628 The FEC Framework document [FECFRAME-FRAMEWORK] provides a 629 comprehensive analysis of security considerations applicable to FEC 630 schemes. Therefore the present section follows the security 631 considerations section of [FECFRAME-FRAMEWORK] and only discusses 632 topics that are specific to the use of Reed-Solomon codes. 634 6.1. Attacks Against the Data Flow 636 6.1.1. Access to Confidential Content 638 The Reed-Solomon FEC Scheme specified in this document does not 639 change the recommendations of [FECFRAME-FRAMEWORK]. To summarize, if 640 confidentiality is a concern, it is RECOMMENDED that one of the 641 solutions mentioned in [FECFRAME-FRAMEWORK] is used, with special 642 considerations to the way this solution is applied (e.g., before 643 versus after FEC protection, and within the end-system versus in a 644 middlebox), to the operational constraints (e.g., performing FEC 645 decoding in a protected environment may be complicated or even 646 impossible) and to the threat model. 648 6.1.2. Content Corruption 650 The Reed-Solomon FEC Scheme specified in this document does not 651 change the recommendations of [FECFRAME-FRAMEWORK]. To summarize, it 652 is RECOMMENDED that one of the solutions mentioned in 653 [FECFRAME-FRAMEWORK] is used on both the FEC Source and Repair 654 Packets. 656 6.2. Attacks Against the FEC Parameters 658 The FEC Scheme specified in this document defines parameters that can 659 be the basis of several attacks. More specifically, the following 660 parameters of the FFCI may be modified by an attacker 661 (Section 5.1.1.2): 662 o FEC Encoding ID: changing this parameter leads the receiver to 663 consider a different FEC Scheme, which enables an attacker to 664 create a Denial of Service (DoS). 665 o Encoding symbol length (E): setting this E parameter to a value 666 smaller than the valid one enables an attacker to create a DoS 667 since the repair symbols and certain source symbols will be larger 668 than E, which is an incoherency for the receiver. Setting this E 669 parameter to a value larger than the valid one has similar impacts 670 when S=1 since the received repair symbol size will be smaller 671 than expected. On the opposite it will not lead to any 672 incoherency when S=0 since the actual symbol length value for the 673 block is determined by the size of any received repair symbol, as 674 long as this value is smaller than E. However setting this E 675 parameter to a larger value may have impacts on receivers that 676 pre-allocate memory space in advance to store incoming symbols. 677 o Strict (S) flag: flipping this S flag from 0 to 1 (i.e., E is now 678 considered as a strict value) enables an attacker to mislead the 679 receiver if the actual symbol size varies over different source 680 blocks. Flipping this S flag from 1 to 0 has no major 681 consequences unless the receiver requires to have a fixed E value 682 (e.g., because the receiver pre-allocates memory space). 683 o m parameter: changing this parameter triggers a DoS since the 684 receiver and sender will consider different codes, and the 685 receiver will interpret the Explicit Source FEC Payload ID and 686 Repair FEC Payload ID differently. Additionally, by increasing 687 this m parameter to a larger value (typically m=16 rather than 8, 688 when both values are possible in the target use-case) will create 689 additional processing load at a receiver if decoding is attempted. 691 It is therefore RECOMMENDED that security measures are taken to 692 guarantee the FFCI integrity, as specified in [FECFRAME-FRAMEWORK]. 693 How to achieve this depends on the way the FFCI is communicated from 694 the sender to the receiver, which is not specified in this document. 696 Similarly, attacks are possible against the Explicit Source FEC 697 Payload ID and Repair FEC Payload ID: by modifying the Source Block 698 Number (SBN), or the Encoding Symbol ID (ESI), or the Source Block 699 Length (k), an attacker can easily corrupt the block identified by 700 the SBN. Other consequences, that are use-case and/or CDP dependant, 701 may also happen. It is therefore RECOMMENDED that security measures 702 are taken to guarantee the FEC Source and Repair Packets as stated in 703 [FECFRAME-FRAMEWORK]. 705 6.3. When Several Source Flows are to be Protected Together 707 The Reed-Solomon FEC Scheme specified in this document does not 708 change the recommendations of [FECFRAME-FRAMEWORK]. 710 6.4. Baseline Secure FEC Framework Operation 712 The Reed-Solomon FEC Scheme specified in this document does not 713 change the recommendations of [FECFRAME-FRAMEWORK] concerning the use 714 of the IPsec/ESP security protocol as a mandatory to implement (but 715 not mandatory to use) security scheme. This is well suited to 716 situations where the only insecure domain is the one over which the 717 FEC Framework operates. 719 7. Operations and Management Considerations 721 The FEC Framework document [FECFRAME-FRAMEWORK] provides a 722 comprehensive analysis of operations and management considerations 723 applicable to FEC schemes. Therefore the present section only 724 discusses topics that are specific to the use of Reed-Solomon codes 725 as specified in this document. 727 7.1. Finite Field Size (m) Recommendations 729 The present document requires that m, the length of the elements in 730 the finite field, in bits, is such that 2 <= m <= 16. However all 731 possibilities are not equally interesting from a practical point of 732 view. It is expected that m=8, the default value, will be mostly 733 used since it offers the possibility to have small to medium sized 734 source blocks and/or a significant number of repair symbols (i.e., k 735 < n <= 255). Additionally, elements in the finite field are 8 bits 736 long which makes read/write memory operations aligned on bytes during 737 encoding and decoding. 739 An alternative when it is known that only very small source blocks 740 will be used is m=4 (i.e., k < n <= 15). Elements in the finite 741 field are 4 bits long, so if two elements are accessed at a time, 742 read/write memory operations are aligned on bytes during encoding and 743 decoding. 745 An alternative when very large source blocks are needed is m=16 746 (i.e., k < n <= 65535). However this choice has significant impacts 747 on the processing load. For instance using pre-calculated tables to 748 speedup operations over the finite field (as done with smaller finite 749 fields) may require a prohibitive amount of memory to be used on 750 embedded platforms. Alternative lightweigth solutions (e.g., 751 [RFC5170]) MAY be prefered in situations where the processing load is 752 an issue [Matsuzono10]. 754 Since several values for the m parameter are possible, the use-case 755 SHOULD define which value(s) need(s) to be supported. In situations 756 where this is not specified, the default m=8 value SHOULD be 757 supported and used. 759 8. IANA Considerations 761 Values of FEC Encoding IDs are subject to IANA registration. 762 [FECFRAME-FRAMEWORK] defines general guidelines on IANA 763 considerations. In particular it defines a registry called FEC 764 Framework (FECFRAME) FEC Encoding IDs whose values are granted on an 765 IETF Consensus basis. 767 This document registers one value in the FEC Framework (FECFRAME) FEC 768 Encoding IDs registry as follows: 769 o XXX refers to the Simple Reed-Solomon FEC Scheme over GF(2^^m) for 770 Arbitrary Packet Flows as specified in this document and in 771 [RFC5510]. 773 9. Acknowledgments 775 The authors want to thank Hitoshi Asaeda for his valuable comments. 777 10. References 779 10.1. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", RFC 2119. 784 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 785 Correction (FEC) Building Block", RFC 5052, August 2007. 787 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 788 "Reed-Solomon Forward Error Correction (FEC) Schemes", 789 RFC 5510, April 2009. 791 [FECFRAME-FRAMEWORK] 792 Watson, M., Begen, A., and V. Roca, "Forward Error 793 Correction (FEC) Framework", 794 draft-ietf-fecframe-framework-13 (Work in Progress), 795 February 2011. 797 [SDP_ELEMENTS] 798 Begen, A., "SDP Elements for FEC Framework", 799 draft-ietf-fecframe-sdp-elements-11 (Work in Progress), 800 October 2010. 802 10.2. Informative References 804 [RS-codec] 805 Rizzo, L., "Reed-Solomon FEC codec (revised version of 806 July 2nd, 1998), available at 807 http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz and 808 mirrored at http://planete-bcast.inrialpes.fr/", 809 July 1998. 811 [Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer 812 Communication Protocols", ACM SIGCOMM Computer 813 Communication Review Vol.27, No.2, pp.24-36, April 1997. 815 [Matsuzono10] 816 Matsuzono, K., Detchart, J., Cunche, M., Roca, V., and H. 817 Asaeda, "Performance Analysis of a High-Performance Real- 818 Time Application with Several AL-FEC Schemes", 35th Annual 819 IEEE Conference on Local Computer Networks (LCN 2010), 820 October 2010. 822 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity 823 Check (LDPC) Forward Error Correction", RFC 5170, 824 June 2008. 826 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 827 "Raptor Forward Error Correction Scheme", RFC 5053, 828 June 2007. 830 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 831 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 832 April 2010. 834 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 835 "Negative-acknowledgment (NACK)-Oriented Reliable 836 Multicast (NORM) Protocol", RFC 5740, November 2009. 838 Authors' Addresses 840 Vincent Roca 841 INRIA 842 655, av. de l'Europe 843 Inovallee; Montbonnot 844 ST ISMIER cedex 38334 845 France 847 Email: vincent.roca@inria.fr 848 URI: http://planete.inrialpes.fr/people/roca/ 850 Mathieu Cunche 851 NICTA 852 Australia 854 Email: mathieu.cunche@nicta.com.au 855 URI: http://mathieu.cunche.free.fr/ 857 Jerome Lacan 858 ISAE/LAAS-CNRS 859 1, place Emile Blouin 860 Toulouse 31056 861 France 863 Email: jerome.lacan@isae.fr 864 URI: http://dmi.ensica.fr/auteur.php3?id_auteur=5 866 Amine Bouabdallah 867 ISAE/LAAS-CNRS 868 1, place Emile Blouin 869 Toulouse 31056 870 France 872 Email: Amine.Bouabdallah@isae.fr 873 URI: http://dmi.ensica.fr/ 874 Kazuhisa Matsuzono 875 Keio University 876 Graduate School of Media and Governance 877 5322 Endo 878 Fujisawa, Kanagawa 252-8520 879 Japan 881 Email: kazuhisa@sfc.wide.ad.jp