idnits 2.17.1 draft-ietf-fecframe-simple-rs-06.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 (January 8, 2013) is 4123 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 470 -- Looks like a reference, but probably isn't: '1' on line 472 -- Looks like a reference, but probably isn't: '2' on line 474 -- Looks like a reference, but probably isn't: '3' on line 476 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 INRIA 4 Intended status: Standards Track M. Cunche 5 Expires: July 12, 2013 INSA-Lyon/INRIA 6 J. Lacan 7 ISAE, Univ. of Toulouse 8 A. Bouabdallah 9 CDTA 10 K. Matsuzono 11 Keio University 12 January 8, 2013 14 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME 15 draft-ietf-fecframe-simple-rs-06 17 Abstract 19 This document describes a fully-specified simple FEC scheme for Reed- 20 Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to 21 protect arbitrary media streams along the lines defined by the 22 FECFRAME framework. The Reed-Solomon codes considered have 23 attractive properties, since they offer optimal protection against 24 packet erasures and the source symbols are part of the encoding 25 symbols which can greatly simplify decoding. However, the price to 26 pay is a limit on the maximum source block size, on the maximum 27 number of encoding symbols, and a computational complexity higher 28 than that of LDPC codes for instance. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 12, 2013. 47 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Definitions Notations and Abbreviations . . . . . . . . . . . 4 66 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 13 79 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 14 80 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 16 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 16 84 6.1.1. Access to Confidential Content . . . . . . . . . . . . 16 85 6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 16 86 6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 17 87 6.3. When Several Source Flows are to be Protected Together . . 18 88 6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 18 89 7. Operations and Management Considerations . . . . . . . . . . . 18 90 7.1. Operational Recommendations: Finite Field Size (m) . . . . 18 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 The use of Forward Error Correction (FEC) codes is a classic solution 100 to improve the reliability of unicast, multicast and broadcast 101 Content Delivery Protocols (CDP) and applications. The [RFC6363] 102 document describes a generic framework to use FEC schemes with media 103 delivery applications, and for instance with real-time streaming 104 media applications based on the RTP real-time protocol. Similarly 105 the [RFC5052] document describes a generic framework to use FEC 106 schemes with objects (e.g., files) delivery applications based on the 107 Asynchronous Layered Coding (ALC) [RFC5775] and NACK-Oriented 108 Reliable Multicast (NORM) [RFC5740] reliable multicast transport 109 protocols. 111 More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce 112 erasure codes based on sparse parity check matrices for object 113 delivery protocols like ALC and NORM. These codes are efficient in 114 terms of processing but not optimal in terms of erasure recovery 115 capabilities when dealing with "small" objects. 117 The Reed-Solomon FEC codes described in this document belong to the 118 class of Maximum Distance Separable (MDS) codes that are optimal in 119 terms of erasure recovery capability. It means that a receiver can 120 recover the k source symbols from any set of exactly k encoding 121 symbols. These codes are also systematic codes, which means that the 122 k source symbols are part of the encoding symbols. However they are 123 limited in terms of maximum source block size and number of encoding 124 symbols. Since the real-time constraints of media delivery 125 applications usually limit the maximum source block size, this is not 126 considered to be a major issue in the context of the FEC Framework 127 for many (but not necessarily all) use-cases. Additionally, if the 128 encoding/decoding complexity is higher with Reed-Solomon codes than 129 it is with [RFC5053] or [RFC5170] codes, it remains reasonable for 130 most use-cases, even in case of a software codec. 132 Many applications dealing with reliable content transmission or 133 content storage already rely on packet-based Reed-Solomon erasure 134 recovery codes. In particular, many of them use the Reed-Solomon 135 codec of Luigi Rizzo [RS-codec] [Rizzo97]. The goal of the present 136 document is to specify a simple Reed-Solomon scheme that is 137 compatible with this codec. 139 More specifically, the [RFC5510] document introduced such Reed- 140 Solomon codes and several associated FEC schemes that are compatible 141 with the [RFC5052] framework. The present document inherits from 142 [RFC5510], Section 8 "Reed-Solomon Codes Specification for the 143 Erasure Channel", the specifications of the core Reed-Solomon codes 144 based on Vandermonde matrices, and specifies a simple FEC scheme that 145 is compatible with the FECFRAME framework [RFC6363]: 147 o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that 148 specifies a simple way of using of Reed-Solomon codes over 149 GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for 150 arbitrary packet flows; 152 Therefore sections 4, 5, 6 and 7 of [RFC5510], that define [RFC5052] 153 specific Formats and Procedures, are not considered and are replaced 154 by FECFRAME specific Formats and Procedures. 156 For instance, with this scheme, a set of Application Data Units (or 157 ADUs) coming from one or several media delivery applications (e.g., a 158 set of RTP packets), are grouped in an ADU block and FEC encoded as a 159 whole. With Reed-Solomon codes over GF(2^^8), there is a strict 160 limit over the number of ADUs that can be protected together, since 161 the number of encoded symbols, n, must be inferior or equal to 255. 162 This constraint is relaxed when using a higher finite field size (m > 163 8), at the price of an increased 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 176 these terms and definitions are FEC scheme specific and are in line 177 with [RFC5052]: 179 Source symbol: unit of data used during the encoding process. In 180 this specification, there is always one source symbol per ADU. 182 Encoding symbol: unit of data generated by the encoding process. 183 With systematic codes, source symbols are part of the encoding 184 symbols. 186 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. 198 Source block: a block of k source symbols that are considered 199 together for the encoding. 201 Packet Erasure Channel: a communication path where packets are 202 either dropped (e.g., by a congested router, or because the number 203 of transmission errors exceeds the correction capabilities of the 204 physical layer codes) or received. When a packet is received, it 205 is assumed that this packet is not corrupted. 207 Some of these terms and definitions are FECFRAME framework specific 208 and are in line with [RFC6363]: 210 Application Data Unit (ADU): The unit of source data provided as 211 payload to the transport layer. Depending on the use-case, an ADU 212 may use an RTP encapsulation. 214 (Source) ADU Flow: A sequence of ADUs associated with a transport- 215 layer flow identifier (such as the standard 5-tuple {Source IP 216 address, source port, destination IP address, destination port, 217 transport protocol}). Depending on the use-case, several ADU 218 flows may be protected together by the FECFRAME framework. 220 ADU Block: a set of ADUs that are considered together by the 221 FECFRAME instance for the purpose of the FEC scheme. Along with 222 the flow ID (F[]), length (L[]), and padding (Pad[]) fields, they 223 form the set of source symbols over which FEC encoding will be 224 performed. 226 ADU Information (ADUI): a unit of data constituted by the ADU and 227 the associated Flow ID, Length and Padding fields (Section 4.3). 228 This is the unit of data that is used as source symbol. 230 FEC Framework Configuration Information (FFCI): Information which 231 controls the operation of the FEC Framework. The FFCI enables the 232 synchronization of the FECFRAME sender and receiver instances. 234 FEC Source Packet: At a sender (respectively, at a receiver) a 235 payload submitted to (respectively, received from) the transport 236 protocol containing an ADU along with an Explicit Source FEC 237 Payload ID (that must be present in the FEC scheme defined by the 238 present document, see Section 5.1.2). 240 FEC Repair Packet: At a sender (respectively, at a receiver) a 241 payload submitted to (respectively, received from) the transport 242 protocol containing one repair symbol along with a Repair FEC 243 Payload ID and possibly an RTP header. 245 The above terminology is illustrated in Figure 1 (sender's point of 246 view): 248 +----------------------+ 249 | Application | 250 +----------------------+ 251 | 252 | (1) Application Data Units (ADUs) 253 | 254 v 255 +----------------------+ +----------------+ 256 | FEC Framework | | | 257 | |-------------------------->| FEC Scheme | 258 |(2) Construct source |(3) Source Block | | 259 | blocks | |(4) FEC Encoding| 260 |(6) Construct FEC |<--------------------------| | 261 | source and repair | | | 262 | packets |(5) Explicit Source FEC | | 263 +----------------------+ Payload IDs +----------------+ 264 | Repair FEC Payload IDs 265 | Repair symbols 266 | 267 |(7) FEC source and repair packets 268 v 269 +----------------------+ 270 | Transport Layer | 271 | (e.g., UDP) | 272 +----------------------+ 274 Figure 1: Terminology used in this document (sender). 276 3.2. Notations 278 This document uses the following notations: Some of them are FEC 279 scheme specific: 281 k denotes the number of source symbols in a source block. 283 max_k denotes the maximum number of source symbols for any source 284 block. 286 n denotes the number of encoding symbols generated for a source 287 block. 289 E denotes the encoding symbol length in bytes. 291 GF(q) denotes a finite field (also known as Galois Field) with q 292 elements. We assume that q = 2^^m in this document. 294 m defines the length of the elements in the finite field, in 295 bits. In this document, m is such that 2 <= m <= 16. 297 q defines the number of elements in the finite field. We have: 298 q = 2^^m in this specification. 300 CR denotes the "code rate", i.e., the k/n ratio. 302 a^^b denotes a raised to the power b. 304 Some of them are FECFRAME framework specific: 306 B denotes the number of ADUs per ADU block. 308 max_B denotes the maximum number of ADUs for any ADU block. 310 3.3. Abbreviations 312 This document uses the following abbreviations: 314 ADU stands for Application Data Unit. 316 ADUI stands for Application Data Unit Information. 318 ESI stands for Encoding Symbol ID. 320 FEC stands for Forward Error (or Erasure) Correction code. 322 FFCI stands for FEC Framework Configuration Information. 324 FSSI stands for FEC Scheme Specific Information. 326 MDS stands for Maximum Distance Separable code. 328 SBN stands for Source Block Number. 330 SDP stands for Session Description Protocol. 332 4. Common Procedures Related to the ADU Block and Source Block Creation 334 This section introduces the procedures that are used during the ADU 335 block and the related source block creation, for the FEC scheme 336 considered. 338 4.1. Restrictions 340 This specification has the following restrictions: 342 o there MUST be exactly one source symbol per ADUI, and therefore 343 per ADU; 345 o there MUST be exactly one repair symbol per FEC Repair Packet; 347 o there MUST be exactly one source block per ADU block; 349 4.2. ADU Block Creation 351 Two kinds of limitations exist that impact the ADU block creation: 353 o at the FEC Scheme level: the finite field size (m parameter) 354 directly impacts the maximum source block size and the maximum 355 number of encoding symbols; 357 o at the FECFRAME instance level: the target use-case can have real- 358 time constraints that can/will define a maximum ADU block size; 360 Note that terminology "maximum source block size" and "maximum ADU 361 block size" depends on the point of view that is adopted (FEC Scheme 362 versus FECFRAME instance). However, in this document, both refer to 363 the same value since Section 4.1 requires there is exactly one source 364 symbol per ADU. We now detail each of these aspects. 366 The finite field size parameter, m, defines the number of non zero 367 elements in this field which is equal to: q - 1 = 2^^m - 1. This q - 368 1 value is also the theoretical maximum number of encoding symbols 369 that can be produced for a source block. For instance, when m = 8 370 (default) there is a maximum of 2^^8 - 1 = 255 encoding symbols. So: 371 k < n <= 255. Given the target FEC code rate (e.g., provided by the 372 end-user or upper application when starting the FECFRAME framework, 373 and taking into account the known or estimated packet loss rate), the 374 sender calculates: 376 max_k = floor((2^^m - 1) * CR) 378 This max_k value leaves enough room for the sender to produce the 379 desired number of repair symbols. Since there is one source symbol 380 per ADU, max_k is also an upper bound to the maximum number of ADUs 381 per ADU block. 383 The source ADU flows can have real-time constraints. When there are 384 multiple flows, with different real-time constraints, let us consider 385 the most stringent constraints (see [RFC6363], section 10.2, item 6 386 for recommendations when several flows are globally protected). In 387 that case the maximum number of ADUs of an ADU block must not exceed 388 a certain threshold since it directly impacts the decoding delay. 389 The larger the ADU block size, the longer a decoder may have to wait 390 until it has received a sufficient number of encoding symbols for 391 decoding to succeed, and therefore the larger the decoding delay. 392 When the target use-case is known, these real-time constraints result 393 in an upper bound to the ADU block size, max_rt. 395 For instance, if the use-case specifies a maximum decoding latency, 396 l, and if each source ADU covers a duration d of a continuous media 397 (we assume here the simple case of a constant bit rate ADU flow), 398 then the ADU block size must not exceed: 400 max_rt = floor(l / d) 402 After encoding, this block will produce a set of at most n = max_rt / 403 CR encoding symbols. These n encoding symbols will have to be sent 404 at a rate of n / l packets per second. For instance, with d = 10 ms, 405 l = 1 s, max_rt = 100 ADUs. 407 If we take into account all these constraints, we find: 409 max_B = min(max_k, max_rt) 411 This max_B parameter is an upper bound to the number of ADUs that can 412 constitute an ADU block. 414 4.3. Source Block Creation 416 In its most general form the FECFRAME framework and the Reed-Solomon 417 FEC scheme are meant to protect a set of independent flows. Since 418 the flows have no relationship to one another, the ADU size of each 419 flow can potentially vary significantly. Even in the special case of 420 a single flow, the ADU sizes can largely vary (e.g., the various 421 frames of a "Group of Pictures (GOP) of an H.264 flow will have 422 different sizes). This diversity must be addressed since the Reed- 423 Solomon FEC scheme requires a constant encoding symbol size (E 424 parameter) per source block. Since this specification requires that 425 there is only one source symbol per ADU, E must be large enough to 426 contain all the ADUs of an ADU block along with their prepended 3 427 bytes (see below). 429 In situations where E is determined per source block (default, 430 specified by the FFCI/FSSI with S = 0, Section 5.1.1.2), E is equal 431 to the size of the largest ADU of this source block plus three (for 432 the prepended 3 bytes, see below). In this case, upon receiving the 433 first FEC Repair Packet for this source block, since this packet MUST 434 contain a single repair symbol (Section 5.1.3), a receiver determines 435 the E parameter used for this source block. 437 In situations where E is fixed (specified by the FFCI/FSSI with S = 438 1, Section 5.1.1.2), then E must be greater or equal to the size of 439 the largest ADU of this source block plus three (for the prepended 3 440 bytes, see below). If this is not the case, an error is returned. 441 How to handle this error is use-case specific (e.g., a larger E 442 parameter may be communicated to the receivers in an updated FFCI 443 message, using an appropriate mechanism) and is not considered by 444 this specification. 446 The ADU block is always encoded as a single source block. There are 447 a total of B <= max_B ADUs in this ADU block. For the ADU i, with 0 448 <= i <= B-1, 3 bytes are prepended (Figure 2): 450 o The first byte, F[i] (Flow ID), contains the integer identifier 451 associated to the source ADU flow to which this ADU belongs to. 452 It is assumed that a single byte is sufficient, or said 453 differently, that no more than 256 flows will be protected by a 454 single instance of the FECFRAME framework. 456 o The following two bytes, L[i] (Length), contain the length of this 457 ADU, in network byte order (i.e., big endian). This length is for 458 the ADU itself and does not include the F[i], L[i], or Pad[i] 459 fields. 461 Then zero padding is added to ADU i (if needed) in field Pad[i], for 462 alignment purposes up to a size of exactly E bytes. The data unit 463 resulting from the ADU i and the F[i], L[i] and Pad[i] fields, is 464 called ADU Information (or ADUI). Each ADUI contributes to exactly 465 one source symbol of the source block. 467 Encoding Symbol Length (E) 468 < ----------------------------------------------------------------- > 469 +----+--------+-----------------------+-----------------------------+ 470 |F[0]| L[0] | ADU[0] | Pad[0] | 471 +----+--------+----------+------------+-----------------------------+ 472 |F[1]| L[1] | ADU[1] | Pad[1] | 473 +----+--------+----------+------------------------------------------+ 474 |F[2]| L[2] | ADU[2] | 475 +----+--------+------+----------------------------------------------+ 476 |F[3]| L[3] |ADU[3]| Pad[3] | 477 +----+--------+------+----------------------------------------------+ 478 \_________________________________ ________________________________/ 479 \/ 480 simple FEC encoding 482 +-------------------------------------------------------------------+ 483 | Repair 4 | 484 +-------------------------------------------------------------------+ 485 . . 486 . . 487 +-------------------------------------------------------------------+ 488 | Repair 7 | 489 +-------------------------------------------------------------------+ 491 Figure 2: Source block creation, for code rate 1/2 (equal number of 492 source and repair symbols, 4 in this example), and S = 0. 494 Note that neither the initial 3 bytes nor the optional padding are 495 sent over the network. However, they are considered during FEC 496 encoding. It means that a receiver who lost a certain FEC source 497 packet (e.g., the UDP datagram containing this FEC source packet) 498 will be able to recover the ADUI if FEC decoding succeeds. Thanks to 499 the initial 3 bytes, this receiver will get rid of the padding (if 500 any) and identify the corresponding ADU flow. 502 5. Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary ADU Flows 504 This Fully-Specified FEC Scheme specifies the use of Reed-Solomon 505 codes over GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding 506 for arbitrary packet flows. 508 5.1. Formats and Codes 510 5.1.1. FEC Framework Configuration Information 512 The FEC Framework Configuration Information (or FFCI) includes 513 information that must be communicated between the sender and 514 receiver(s) [RFC6363]. More specifically, it enables the 515 synchronization of the FECFRAME sender and receiver instances. It 516 includes both mandatory elements and scheme-specific elements, as 517 detailed below. 519 5.1.1.1. Mandatory Information 521 o FEC Encoding ID: the value assigned to this fully-specified FEC 522 scheme MUST be XXX, as assigned by IANA (Section 8). 524 When SDP is used to communicate the FFCI, this FEC Encoding ID MUST 525 be carried in the 'encoding-id' parameter of the 'fec-repair-flow' 526 attribute specified in RFC 6364 [RFC6364]. 528 5.1.1.2. FEC Scheme-Specific Information 530 The FEC Scheme Specific Information (FSSI) includes elements that are 531 specific to the present FEC scheme. More precisely: 533 o Encoding Symbol Length (E): a non-negative integer, inferior to 534 2^16, that indicates either the length of each encoding symbol in 535 bytes ("strict" mode, i.e., if S = 1), or the maximum length of 536 any encoding symbol (i.e., if S = 0). 538 o Strict (S) flag: when set to 1 this flag indicates that the E 539 parameter is the actual encoding symbol length value for each 540 block of the session (unless otherwise notified by an updated FFCI 541 if this possibility is considered by the use-case or CDP). When 542 set to 0 this flag indicates that the E parameter is the maximum 543 encoding symbol length value for each block of the session (unless 544 otherwise notified by an updated FFCI if this possibility is 545 considered by the use-case or CDP). 547 o m parameter (m): an integer that defines the length of the 548 elements in the finite field, in bits. We have: 2 <= m <= 16. 550 These elements are required both by the sender (Reed-Solomon encoder) 551 and the receiver(s) (Reed-Solomon decoder). 553 When SDP is used to communicate the FFCI, this FEC scheme-specific 554 information MUST be carried in the 'fssi' parameter of the 'fec- 555 repair-flow' attribute, in textual representation as specified in RFC 556 6364 [RFC6364]. For instance: 558 a=fec-repair-flow: encoding-id=XXX; fssi=E:1400,S:0,m:8 560 If another mechanism requires the FSSI to be carried as an opaque 561 octet string (for instance after a Base64 encoding), the encoding 562 format consists of the following 3 octets of Figure 3: 564 o Encoding symbol length (E): 16 bit field. 566 o Strict (S) flag: 1 bit field. 568 o m parameter (m): 7 bit field. 570 0 1 2 571 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Encoding Symbol Length (E) |S| m | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 3: FSSI encoding format. 578 5.1.2. Explicit Source FEC Payload ID 580 A FEC source packet MUST contain an Explicit Source FEC Payload ID 581 that is appended to the end of the packet as illustrated in Figure 4. 583 +--------------------------------+ 584 | IP Header | 585 +--------------------------------+ 586 | Transport Header | 587 +--------------------------------+ 588 | ADU | 589 +--------------------------------+ 590 | Explicit Source FEC Payload ID | 591 +--------------------------------+ 593 Figure 4: Structure of a FEC Source Packet with the Explicit Source 594 FEC Payload ID. 596 More precisely, the Explicit Source FEC Payload ID is composed of the 597 Source Block Number, the Encoding Symbol ID, and the Source Block 598 Length. The length of the first two fields depends on the m 599 parameter (transmitted separately in the FFCI, Section 5.1.1.2): 601 o Source Block Number (SBN) (32-m bit field): this field identifies 602 the source block to which this FEC source packet belongs. 604 o Encoding Symbol ID (ESI) (m bit field): this field identifies the 605 source symbol contained in this FEC source packet. This value is 606 such that 0 <= ESI <= k - 1 for source symbols. 608 o Source Block Length (k) (16 bit field): this field provides the 609 number of source symbols for this source block, i.e., the k 610 parameter. If 16 bits are too much when m <= 8, it is needed when 611 8 < m <= 16. Therefore we provide a single common format 612 regardless of m. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Source Block Number (24 bits) | Enc. Symb. ID | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Source Block Length (k) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Figure 5: Source FEC Payload ID encoding format for m = 8 (default). 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Source Block Length (k) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 6: Source FEC Payload ID encoding format for m = 16. 634 The format of the Source FEC Payload ID for m = 8 and m = 16 are 635 illustrated in Figure 5 and Figure 6 respectively. 637 5.1.3. Repair FEC Payload ID 639 A FEC repair packet MUST contain a Repair FEC Payload ID that is 640 prepended to the repair symbol(s) as illustrated in Figure 7. There 641 MUST be a single repair symbol per FEC repair packet. 643 +--------------------------------+ 644 | IP Header | 645 +--------------------------------+ 646 | Transport Header | 647 +--------------------------------+ 648 | Repair FEC Payload ID | 649 +--------------------------------+ 650 | Repair Symbol | 651 +--------------------------------+ 653 Figure 7: Structure of a FEC Repair Packet with the Repair FEC 654 Payload ID. 656 More precisely, the Repair FEC Payload ID is composed of the Source 657 Block Number, the Encoding Symbol ID, and the Source Block Length. 658 The length of the first two fields depends on the m parameter 659 (transmitted separately in the FFCI, Section 5.1.1.2): 661 o Source Block Number (SBN) (32-m bit field): this field identifies 662 the source block to which the FEC repair packet belongs. 664 o Encoding Symbol ID (ESI) (m bit field): this field identifies the 665 repair symbol contained in this FEC repair packet. This value is 666 such that k <= ESI <= n - 1 for repair symbols. 668 o Source Block Length (k) (16 bit field): this field provides the 669 number of source symbols for this source block, i.e., the k 670 parameter. If 16 bits are too much when m <= 8, it is needed when 671 8 < m <= 16. Therefore we provide a single common format 672 regardless of m. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Source Block Number (24 bits) | Enc. Symb. ID | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Source Block Length (k) | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Figure 8: Repair FEC Payload ID encoding format for m = 8 (default). 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Source Block Length (k) | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 Figure 9: Repair FEC Payload ID encoding format for m = 16. 694 The format of the Repair FEC Payload ID for m = 8 and m = 16 are 695 illustrated in Figure 8 and Figure 9 respectively. 697 5.2. Procedures 699 The following procedures apply: 701 o The source block creation MUST follow the procedures specified in 702 Section 4.3. 704 o The SBN value MUST start with value 0 for the first block of the 705 ADU flow and MUST be incremented by 1 for each new source block. 706 Wrapping to zero will happen for long sessions, after value 707 2^^(32-m) - 1. 709 o The ESI of encoding symbols MUST start with value 0 for the first 710 symbol and MUST be managed sequentially. The first k values (0 <= 711 ESI <= k - 1) identify source symbols whereas the last n-k values 712 (k <= ESI <= n - 1) identify repair symbols. 714 o The FEC repair packet creation MUST follow the procedures 715 specified in Section 5.1.3. 717 5.3. FEC Code Specification 719 The present document inherits from [RFC5510], Section 8 "Reed-Solomon 720 Codes Specification for the Erasure Channel", the specifications of 721 the core Reed-Solomon codes based on Vandermonde matrices. 723 6. Security Considerations 725 The FEC Framework document [RFC6363] provides a comprehensive 726 analysis of security considerations applicable to FEC schemes. 727 Therefore the present section follows the security considerations 728 section of [RFC6363] and only discusses topics that are specific to 729 the use of Reed-Solomon codes. 731 6.1. Attacks Against the Data Flow 733 6.1.1. Access to Confidential Content 735 The Reed-Solomon FEC Scheme specified in this document does not 736 change the recommendations of [RFC6363]. To summarize, if 737 confidentiality is a concern, it is RECOMMENDED that one of the 738 solutions mentioned in [RFC6363] is used, with special considerations 739 to the way this solution is applied (e.g., is encryption applied 740 before or after FEC protection, within the end-system or in a 741 middlebox), to the operational constraints (e.g., performing FEC 742 decoding in a protected environment may be complicated or even 743 impossible) and to the threat model. 745 6.1.2. Content Corruption 747 The Reed-Solomon FEC Scheme specified in this document does not 748 change the recommendations of [RFC6363]. To summarize, it is 749 RECOMMENDED that one of the solutions mentioned in [RFC6363] is used 750 on both the FEC Source and Repair Packets. 752 6.2. Attacks Against the FEC Parameters 754 The FEC Scheme specified in this document defines parameters that can 755 be the basis of several attacks. More specifically, the following 756 parameters of the FFCI may be modified by an attacker 757 (Section 5.1.1.2): 759 o FEC Encoding ID: changing this parameter leads the receiver to 760 consider a different FEC Scheme, which enables an attacker to 761 create a Denial of Service (DoS). 763 o Encoding symbol length (E): setting this E parameter to a value 764 smaller than the valid one enables an attacker to create a DoS 765 since the repair symbols and certain source symbols will be larger 766 than E, which is an incoherency for the receiver. Setting this E 767 parameter to a value larger than the valid one has similar impacts 768 when S=1 since the received repair symbol size will be smaller 769 than expected. On the opposite it will not lead to any 770 incoherency when S=0 since the actual symbol length value for the 771 block is determined by the size of any received repair symbol, as 772 long as this value is smaller than E. However setting this E 773 parameter to a larger value may have impacts on receivers that 774 pre-allocate memory space in advance to store incoming symbols. 776 o Strict (S) flag: flipping this S flag from 0 to 1 (i.e., E is now 777 considered as a strict value) enables an attacker to mislead the 778 receiver if the actual symbol size varies over different source 779 blocks. Flipping this S flag from 1 to 0 has no major 780 consequences unless the receiver requires to have a fixed E value 781 (e.g., because the receiver pre-allocates memory space). 783 o m parameter: changing this parameter triggers a DoS since the 784 receiver and sender will consider different codes, and the 785 receiver will interpret the Explicit Source FEC Payload ID and 786 Repair FEC Payload ID differently. Additionally, by increasing 787 this m parameter to a larger value (typically m=16 rather than 8, 788 when both values are possible in the target use-case) will create 789 additional processing load at a receiver if decoding is attempted. 791 It is therefore RECOMMENDED that security measures are taken to 792 guarantee the FFCI integrity, as specified in [RFC6363]. How to 793 achieve this depends on the way the FFCI is communicated from the 794 sender to the receiver, which is not specified in this document. 796 Similarly, attacks are possible against the Explicit Source FEC 797 Payload ID and Repair FEC Payload ID: by modifying the Source Block 798 Number (SBN), or the Encoding Symbol ID (ESI), or the Source Block 799 Length (k), an attacker can easily corrupt the block identified by 800 the SBN. Other consequences, that are use-case and/or CDP dependant, 801 may also happen. It is therefore RECOMMENDED that security measures 802 are taken to guarantee the FEC Source and Repair Packets as stated in 803 [RFC6363]. 805 6.3. When Several Source Flows are to be Protected Together 807 The Reed-Solomon FEC Scheme specified in this document does not 808 change the recommendations of [RFC6363]. 810 6.4. Baseline Secure FEC Framework Operation 812 The Reed-Solomon FEC Scheme specified in this document does not 813 change the recommendations of [RFC6363] concerning the use of the 814 IPsec/ESP security protocol as a mandatory to implement (but not 815 mandatory to use) security scheme. This is well suited to situations 816 where the only insecure domain is the one over which the FEC 817 Framework operates. 819 7. Operations and Management Considerations 821 The FEC Framework document [RFC6363] provides a comprehensive 822 analysis of operations and management considerations applicable to 823 FEC schemes. Therefore the present section only discusses topics 824 that are specific to the use of Reed-Solomon codes as specified in 825 this document. 827 7.1. Operational Recommendations: Finite Field Size (m) 829 The present document requires that m, the length of the elements in 830 the finite field, in bits, is such that 2 <= m <= 16. However all 831 possibilities are not equally interesting from a practical point of 832 view. It is expected that m=8, the default value, will be mostly 833 used since it offers the possibility to have small to medium sized 834 source blocks and/or a significant number of repair symbols (i.e., k 835 < n <= 255). Additionally, elements in the finite field are 8 bits 836 long which makes read/write memory operations aligned on bytes during 837 encoding and decoding. 839 An alternative when it is known that only very small source blocks 840 will be used is m=4 (i.e., k < n <= 15). Elements in the finite 841 field are 4 bits long, so if two elements are accessed at a time, 842 read/write memory operations are aligned on bytes during encoding and 843 decoding. 845 An alternative when very large source blocks are needed is m=16 846 (i.e., k < n <= 65535). However this choice has significant impacts 847 on the processing load. For instance using pre-calculated tables to 848 speedup operations over the finite field (as done with smaller finite 849 fields) may require a prohibitive amount of memory to be used on 850 embedded platforms. Alternative lightweight solutions (e.g., 851 [RFC5170]) may be preferred in situations where the processing load 852 is an issue and the source block length is large enough 853 [Matsuzono10]. 855 Since several values for the m parameter are possible, the use-case 856 SHOULD define which value(s) need(s) to be supported. In situations 857 where this is not specified, the default m=8 value MUST be used. 859 In any case, any compliant implementation MUST support at least the 860 default m=8 value. 862 8. IANA Considerations 864 Values of FEC Encoding IDs are subject to IANA registration. 865 [RFC6363] defines general guidelines on IANA considerations. In 866 particular it defines the "FEC Framework (FECFRAME) FEC Encoding IDs" 867 subregistry of the "Reliable Multicast Transport (RMT) FEC Encoding 868 IDs and FEC Instance IDs" registry, whose values are granted on an 869 IETF Consensus basis. 871 This document registers one value in the FEC Framework (FECFRAME) FEC 872 Encoding IDs subregistry as follows: 874 o XXX refers to the Simple Reed-Solomon [RFC5510] FEC Scheme over 875 GF(2^^m) for Arbitrary Packet Flows. 877 9. Acknowledgments 879 The authors want to thank Hitoshi Asaeda and Ali Begen for their 880 valuable comments. 882 10. References 884 10.1. Normative References 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", RFC 2119. 889 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 890 Correction (FEC) Building Block", RFC 5052, 891 August 2007. 893 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 894 "Reed-Solomon Forward Error Correction (FEC) Schemes", 895 RFC 5510, April 2009. 897 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 898 Correction (FEC) Framework", RFC 6363, September 2011. 900 [RFC6364] Begen, A., "Session Description Protocol Elements for 901 the Forward Error Correction (FEC) Framework", 902 RFC 6364, October 2011. 904 10.2. Informative References 906 [RS-codec] Rizzo, L., "Reed-Solomon FEC codec (C language)", 907 original codec: http://info.iet.unipi.it/~luigi/vdm98/ 908 vdm980702.tgz, improved codec: http://openfec.org/, 909 July 1998. 911 [Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable 912 Computer Communication Protocols", ACM SIGCOMM 913 Computer Communication Review Vol.27, No.2, pp.24-36, 914 April 1997. 916 [Matsuzono10] Matsuzono, K., Detchart, J., Cunche, M., Roca, V., and 917 H. Asaeda, "Performance Analysis of a High-Performance 918 Real-Time Application with Several AL-FEC Schemes", 919 35th Annual IEEE Conference on Local Computer 920 Networks (LCN 2010), October 2010. 922 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density 923 Parity Check (LDPC) Forward Error Correction", 924 RFC 5170, June 2008. 926 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. 927 Stockhammer, "Raptor Forward Error Correction Scheme 928 for Object Delivery", RFC 5053, June 2007. 930 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 931 Layered Coding (ALC) Protocol Instantiation", 932 RFC 5775, April 2010. 934 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 935 "Negative-acknowledgment (NACK)-Oriented Reliable 936 Multicast (NORM) Protocol", RFC 5740, November 2009. 938 Authors' Addresses 940 Vincent Roca 941 INRIA 942 655, av. de l'Europe 943 Inovallee; Montbonnot 944 ST ISMIER cedex 38334 945 France 947 EMail: vincent.roca@inria.fr 948 URI: http://planete.inrialpes.fr/people/roca/ 950 Mathieu Cunche 951 INSA-Lyon/INRIA 952 Laboratoire CITI 953 6 av. des Arts 954 Villeurbanne cedex 69621 955 France 957 EMail: mathieu.cunche@inria.fr 958 URI: http://mathieu.cunche.free.fr/ 960 Jerome Lacan 961 ISAE, Univ. of Toulouse 962 10 av. Edouard Belin; BP 54032 963 Toulouse cedex 4 31055 964 France 966 EMail: jerome.lacan@isae.fr 967 URI: http://personnel.isae.fr/jerome-lacan/ 969 Amine Bouabdallah 970 CDTA 971 Center for Development of Advanced Technologies 972 Cite 20 aout 1956, Baba Hassen 973 Algiers 974 Algeria 976 EMail: abouabdallah@cdta.dz 977 Kazuhisa Matsuzono 978 Keio University 979 Graduate School of Media and Governance 980 5322 Endo 981 Fujisawa, Kanagawa 252-8520 982 Japan 984 EMail: kazuhisa@sfc.wide.ad.jp