idnits 2.17.1 draft-irtf-nwcrg-network-coding-taxonomy-07.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 == Line 254 has weird spacing: '...symbols repa...' == Line 259 has weird spacing: '... packet rep...' -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NWCRG B. Adamson 3 Internet-Draft NRL 4 Intended status: Informational C. Adjih 5 Expires: August 23, 2018 INRIA 6 J. Bilbao 7 Ikerlan 8 V. Firoiu 9 BAE Systems 10 F. Fitzek 11 TU Dresden 12 S. Ghanem 13 Independant 14 E. Lochin 15 ISAE - Supaero 16 A. Masucci 17 Orange 18 M-J. Montpetit 19 Independant 20 M. Pedersen 21 Aalborg University 22 G. Peralta 23 Ikerlan 24 V. Roca, Ed. 25 INRIA 26 P. Saxena 27 AnsuR Technologies 28 S. Sivakumar 29 Cisco 30 2 19, 2018 32 Taxonomy of Coding Techniques for Efficient Network Communications 33 draft-irtf-nwcrg-network-coding-taxonomy-07 35 Abstract 37 This document is the product of the Network Coding Research Group 38 (NWCRG). It summarizes a recommended terminology for Network Coding 39 concepts and constructs. It provides a comprehensive set of terms in 40 order to avoid ambiguities in future IRTF and IETF documents on 41 Network Coding. This document is in-line with the terminology used 42 by the RFCs produced by the Reliable Multicast Transport (RMT) and 43 FEC Framework (FECFRAME) IETF working groups. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on August 23, 2018. 62 Copyright Notice 64 Copyright (c) 2018 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 81 2. General definitions and concepts . . . . . . . . . . . . . . 4 82 3. Taxonomy of Code Uses . . . . . . . . . . . . . . . . . . . . 7 83 4. Coding Details . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.1. Coding Types . . . . . . . . . . . . . . . . . . . . . . 9 85 4.2. Coding Basics . . . . . . . . . . . . . . . . . . . . . . 10 86 4.3. Coding In Practice . . . . . . . . . . . . . . . . . . . 12 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 7.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Appendix A. Additional references . . . . . . . . . . . . . . . 14 93 Appendix B. Authors and Contributors . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 This document is not an IETF product and is not a standard. This 99 document is the product and represents the consensus of the Network 100 Coding Research Group (NWCRG). In 2017, it has been discussed during 101 three audio conferences, each of them gathering 6 to 8 key experts, 102 it has been co-edited, and finally subject to a RG Last Call. The 103 general feeling was that the document was ready for the next step. 105 The literature on Network Coding research and system design, IETF 106 included, led to a rich set of concepts and constructs. This 107 document collects terminology used in the domain, both outside and 108 inside IETF, provides concise definitions, and introduces a high- 109 level taxonomy. Its primary goal is to be useful to IETF and IRTF 110 activities. It is also in-line with the terminology already used by 111 the RFCs produced by the Reliable Multicast Transport (RMT) and FEC 112 Framework (FECFRAME) IETF working groups, in particular [RFC5052] 113 [RFC5740] [RFC5775] [RFC6363] [RFC6726]. Note that in the 114 definitions, the "(IETF)" tag indicates that the associated term is 115 already used in IETF documents. 117 This document focuses on packet transmissions and packet losses. 118 These losses will typically be triggered by various types of 119 networking issues and/or impairments (e.g., congested routers or 120 intermittent wireless connectivity). The notion of "packet" itself 121 is multiform, depending on the target use-case and the notion of 122 network (e.g., in which layer of the protocol stack does the coding 123 middleware operate?). For instance, a "packet" may be a data unit to 124 be carried as a UDP payload because the coding middleware is located 125 between the application and UDP. In another configuration, coding 126 may be applied within an overlay network and the notion of "packet" 127 will be totally different. In any case the goals of Network Coding 128 can be to improve the network throughput, efficiency, latency, and 129 scalability, as well as providing resilience to partition, attacks, 130 and eavesdropping (NWCRG charter). Both End-to-End Coding and 131 systems that also perform re-coding within intermediate forwarding 132 nodes are considered in this document. 134 This document does not consider physical layer transmission issues, 135 nor physical layer codes, nor error detection: if low layer error 136 codes detect but fail to correct bit errors, or if an upper layer 137 checksum (e.g., within IP or UDP) identifies a corrupted packet, then 138 this packet is supposed to be dropped. 140 1.1. Requirements Language 142 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 2. General definitions and concepts 148 This section gathers general definitions and concepts that are used 149 throughout this document. 151 Packet Erasure Channel: A communication path where packets are 152 either dropped or received without any error. This type of 153 packet drop is referred to as an "erasure" or "loss". The 154 term "channel" must be understood as a generic term for any 155 type of communication technology (e.g., an Ethernet link, a 156 WiFi network, or a full path between two nodes over the 157 Internet). The "Erasure" channels are opposed to "Error" 158 channels where one or multiple bit errors may happen during a 159 packet transmission. These "Error" channels are out of 160 scope. 162 Erasure Correcting Code (ECC), or (IETF) Forward Erasure Code (FEC): 164 A code for the Packet Erasure Channel (only). These 165 codes are also called "Application-Level FEC" to 166 highlight that they have been designed to be used within 167 the higher layers of the protocol stack, to protect 168 against packet losses. These codes are opposed to 169 "Error" correction codes that are capable of identifying 170 the presence and/or correcting bit errors. The "Error" 171 correction codes are out of scope. 173 End-to-End Coding: A system where coding is performed at the 174 source or (coding) middlebox, and decoding at the 175 destination(s) or (decoding) middlebox. There is no re- 176 coding operation at intermediate nodes. This is the 177 approach followed in the FLUTE/ALC [RFC6726][RFC5775], 178 NORM [RFC5740] and FECFRAME [RFC6363] protocols. 180 Network Coding: A system where coding can be performed at the 181 source as well as at intermediate forwarding nodes (all 182 or a subset of them). End-to-End Coding is regarded as 183 a special case of Network Coding. Depending on the use 184 case, additional assumptions can be made: for instance 185 the knowledge by the destination of the coding nodes 186 topology and coding operations can help during decoding 187 operations. 189 Packet versus Symbol: Generally speaking, a Packet is the unit 190 of data that is sent in the Packet Erasure Channel, 191 while a Symbol is the unit of data that is manipulated 192 during the encoding and decoding operations. 194 Original Payload, or Uncoded Payload, or Systematic Symbol, or 195 (IETF) Source Symbol: 196 A unit of data originating from the source that is used 197 as input to encoding operations. When there is a single 198 Source Symbol per Source Packet, an Original Payload 199 corresponds to a Source Packet. 201 Coded Payload, Coded Symbol, or (IETF) Repair Symbol: A unit of 202 data that is the result of a coding operation, applied 203 either to Source Symbols or (in case of recoding) Source 204 and/or Repair Symbols. When there is a single Repair 205 Symbol per Repair Packet, a Coded Payload corresponds to 206 a Repair Packet. 208 Input Symbol and Output Symbol: A unit of data that is used as 209 input to an encoding operation or that is generated as 210 output of an encoding operation. At a re-coding node, 211 Repair Symbols are also part of the Input Symbols. With 212 Systematic Coding, Source Symbols are also part of the 213 Output Symbols. 215 (IETF) Encoding Symbol: A Source or a Repair Symbol. 217 (En)coding versus Recoding versus Decoding: (En)coding is an 218 operation that takes Source Symbols as input and 219 produces Encoding Symbols as output. Recoding is an 220 operation that takes Encoding Symbols as input and 221 produces Encoding Symbols as output. Decoding is an 222 operation takes Encoding Symbols as input and produces 223 Source Symbols as output. 225 (IETF) Source Packet: A packet originating from the source 226 which contributes to one or more Source Symbols. For 227 instance, an RTP packet as a whole can constitute a 228 Source Symbol. In other situations (e.g, to address 229 variable size packets) a single RTP packet may 230 contribute to various Source Symbols. 232 (IETF) Repair Packet: A packet containing one or more Repair 233 Symbols. 235 Figure 1 illustrates the relationships between packets (what is sent 236 in the Packet Erasure Channel) and symbols (what is manipulated 237 during encoding and decoding operations) in case of FEC encoding, at 238 a Coding Node that performs Encoding (rather than Recoding). FEC 239 decoding procedures are similarly performed in the reverse order. 241 source packet 242 | 243 | source packet to source symbols transform 244 | (one or more symbols per packet) 245 v 246 source symbols 247 | 248 v input symbols 249 +----------------------+ 250 | FEC encoding | 251 +----------------------+ 252 | output symbols | 253 v v 254 source symbols repair symbols 255 | | 256 | | symbol to packet transform 257 | | (one or more symbols per packet) 258 v v 259 source packet repair packet 261 Figure 1: Packet and symbol relationships at a Coding Node that 262 performs Encoding (rather than Recoding). 264 Source Node: A node that generates one or more Source Flows. 266 Coding Node: A node that performs FEC Encoding or Recoding 267 operations. It may be an end-host or a middlebox (Encoding 268 case), or a forwarding node (Recoding case). 270 (IETF) Flow: A stream of packets logically grouped. 272 (IETF) Source Flow: A flow of Source Packets coming from an 273 application on a given host, and to which FEC encoding is to 274 be applied, potentially along with other Source Flows. 275 Depending on the use case, Source Flows may come from the 276 same application, from different applications on the same 277 host, or from different applications on different hosts. 279 (IETF) Repair flow: A flow containing Repair Packets, after FEC 280 encoding. 282 3. Taxonomy of Code Uses 284 This section discusses the various ways of using coding, without 285 going into coding details. 287 Source Coding versus Channel Coding: (see Figure 2) When both terms 288 are opposed, "Source Coding" usually refers to compression 289 techniques (e.g., audio and video compression) within the 290 upper application that generates the source flow. On the 291 opposite, "Channel Coding" refers to FEC encoding in order to 292 improve transmission robustness, for instance within the 293 lower physical layer (out of scope of this document) or as 294 part of Network Coding. These terms should not be confused 295 with respectively "FEC coding within the Source Node" and 296 "FEC re-coding within an intermediate Coding Node". 298 raw data flow from camera ^ video flow display 299 | | ^ 300 v | upper | 301 +-----------------------+ | +-----------------------+ 302 | source coding | | applica- | source (de)coding | 303 |(e.g. mpeg compression)| | tion |(eg. mpg decompression)| 304 +-----------------------+ v +-----------------------+ 305 | ^ 306 v | 307 +-----------------------+ ^ +-----------------------+ 308 | network/AL-FEC coding | | middle- | network/AL-FEC coding | 309 | (e.g. RLC encoding) | | ware | (e.g. RLC decoding) | 310 +-----------------------+ v +-----------------------+ 311 | ^ 312 v | 313 +-----------------------+ ^ +-----------------------+ 314 | packetization | | | depacketization | 315 | (e.g. UDP/IP) | | communi- | (e.g. UDP/IP) | 316 +-----------------------+ | cation +-----------------------+ 317 | | ^ 318 v | layers | 319 +-----------------------+ | +-----------------------+ 320 | PHY layer | | | PHY layer | 321 | (channel coding) | | | (channel decoding) | 322 +-----------------------+ v +-----------------------+ 323 | ^ 324 | source + repair traffic | 325 +-------------------------------------------+ 327 Figure 2: Example of end-to-end flow manipulation with Network Coding 328 between the application and UDP layers (as with RMT or FECFRAME 329 architectures). Other architectures are possible, for instance with 330 network coding below the transport layer in order to allow re-coding 331 within the network. 333 Intra-Flow Coding, or Single Source Network Coding: Process where 334 incoming packets to the Coding Node belong to the same flow. 336 Inter-Flow Coding, or Multi-Source Network Coding: Process where 337 incoming packets to the Coding Node belong to different 338 flows. 340 Single-Path Coding: Network Coding over a route that has a single 341 path from the source to each destination(s). In case of 342 multicast or broadcast traffic, this route is a tree. Coding 343 may be done end-to-end and/or at intermediate forwarding 344 nodes. 346 Multi-Path Coding: Network Coding over a route that has multiple (at 347 least partially) disjoint paths from the source to each given 348 destination. Coding may be done end-to-end and/or at 349 intermediate forwarding nodes. 351 4. Coding Details 353 4.1. Coding Types 355 This section provides a high-level taxonomy of coding techniques. 356 Technical details are left for the following sections. 358 Linear Coding: Linear combination of a set of input symbols (i.e., 359 Source and/or Repair Symbols) using a given set of 360 coefficients and resulting in a Repair Symbol. Many linear 361 codes exist that differ from the way coding coefficients are 362 drawn from a Finite Field of a given size. 364 Random Linear Coding (RLC): Particular case of Linear Coding using a 365 set of random coding coefficients. 367 Adaptive Linear Coding: Linear Coding that utilizes cross layer 368 adaptation. For instance, an adaptive coding scheme may 369 adapt the generation and transmission of Repair Packets 370 according to the channel variations over time, accounting for 371 the predictive loss of degrees of freedom due to erasures. 373 Block Coding: Coding technique where the input Flow(s) must be first 374 segmented into a sequence of blocks, FEC encoding and 375 decoding being performed independently on a per-block basis. 376 The term "Chunk Coding" is sometimes used, where a "Chunk" 377 denotes a block. 379 Sliding Window Coding, or Convolutional Coding: General class of 380 coding techniques that rely on a sliding encoding window. 381 This is an alternative solution to Block Coding. 383 Fixed or Elastic Sliding Window Coding: Coding technique that 384 generates Repair Symbol(s) on-the-fly, from the set of Source 385 Symbols present in the sliding encoding window at that time, 386 usually by using Linear Coding. The sliding window may be 387 either of fixed size or of variable size over the time (also 388 known as "elastic sliding window"). For instance, this size 389 may depend on acknowledgments sent by the receiver(s) for a 390 particular Source Symbol or Source Packet (received, decoded, 391 or decodable). 393 Systematic Coding: A coding technique where Source Symbols are part 394 of the output Flow generated by a Coding Node. 396 Rateless and Non-Rateless Coding: Rateless Coding can generate an 397 unlimited number of Repair Symbols (in practice this number 398 can be limited by practical considerations or because of use- 399 case requirements) from a given set of Source Symbols, 400 meaning that the code rate is null. RLC codes are an example 401 of Rateless Codes. On the opposite, Non-Rateless Coding 402 usually has a predefined maximum number of Repair Symbols 403 that can be generated from a given set of Source Symbols. 405 4.2. Coding Basics 407 This section discusses and defines low level coding aspects. 409 Code Rate: In case of a Block Code, the Code Rate is the k/n ratio 410 between the number of Source Symbols, k, and the number of 411 Source plus Repair Symbols, n. With a Sliding Window Code, 412 the Code Rate is defined similarly over a certain time 413 interval, since the Code Rate may change dynamically. By 414 definition, the Code Rate is such that: 0 < Code Rate <= 1. 415 A Code Rate close to 1 indicates that a small number of 416 Repair Symbols have been produced during the encoding process 417 and vice-versa. 419 (En)coding Window: A set of Source (and Repair in the case of re- 420 coding) Symbols used as input to the coding operations. The 421 set of symbols will typically change over the time, as the 422 Coding Window slides over the input Flow(s). 424 (En)coding Window Size: The number of Source (and Repair in case of 425 re-coding) Symbols in the current Encoding Window. This size 426 may change over the time. 428 Payload Set: The set of Source and Repair Symbols available (i.e., 429 received or previously decoded) at the receiver and used 430 during FEC decoding operations. 432 Decoding window: The set of Source Symbols (only) that are 433 considered in the current linear system of a receiver, 434 independently of the fact these Source Symbols have been 435 received, decoded, or lost. The Decoding Window will 436 typically change over the time, as transmissions and decoding 437 progress, and may be different for different receivers of a 438 session where content is multicast or broadcast. 440 Decoding Window Size: The number of Source Symbols (only) in the 441 current Decoding Window. This size may change over the time. 443 Rank of a Payload Set, or (IETF) Rank of the Linear System: At a rec 444 eiver, number of linearly independent members of a Payload 445 Set, or equivalently the number of linearly independent 446 equations of the linear system. It is also known as "Degrees 447 of Freedom". The system may be of "full rank" and decoding 448 is possible, or "partial rank", and only partial decoding is 449 possible. 451 Seen Payload, or Seen Symbol: A Source Symbol is Seen when the 452 receiver can compute a linear combination with this symbol 453 and Source Symbols that are strictly more recent (i.e., with 454 logically higher Encoding Symbol Identifiers). Otherwise the 455 Source Symbol is considered as "unseen". 457 Generation, or (IETF) Block: With Block Codes, the set of Source 458 Symbols of the input Flow(s) that are logically grouped into 459 a Block, before doing encoding. 461 Generation Size, or Code Dimension, or (IETF) Block Size: With Block 462 Codes, the number k of Source Symbols belonging to a Block. 464 Coding Matrix, or Generator Matrix: A matrix G that transforms the 465 set of Input Symbols X into a set of Repair Symbols: Y = X * 466 G. Defining a Generator Matrix is usual with Block Codes. 467 The set of Input Symbols X can consist only of Source Symbols 468 (e.g., with End-to-End Coding) or can consist of Source and 469 Repair Symbols (e.g., with re-coding in an intermediate 470 node). 472 Coding Coefficient: With Linear Coding, this is a coefficient in a 473 certain Finite Field. This coefficient may be chosen in 474 different ways: randomly, or in a pre-defined table, or using 475 a pre-defined algorithm plus a seed. 477 Coding Vector: A set of Coding Coefficients used to generate a 478 certain Repair Symbol through Linear Coding. The number of 479 nonzero coefficients in the Coding Vector defines its 480 density. 482 Finite Field, or Galois Field, or Coding Field: Finite fields, used 483 in Linear Codes, have the desired property of having all 484 elements (except zero) invertible for + and * and all 485 operations over any elements do not result in an overflow or 486 underflow. Examples of Finite Fields are prime fields 487 {0..p^m-1}, where p is prime. Most used fields use p=2 and 488 are called binary extension fields {0..2^m-1}, where m often 489 equals 1, 4 or 8 for practical reasons. 491 Finite Field size, or Coding Field size: The number of elements in a 492 finite field. For example the binary extension field 493 {0..2^m-1} has size q=2^m. 495 Feedback: Feedback information sent by a decoding node to a Coding 496 Node (or from a receiver to a source in case of End-to-End 497 Coding). The nature of information contained in a feedback 498 packet varies, depending on the use-case. It can provide 499 reception and/or FEC decoding statistics, or the list of 500 available Source Packets received or decoded 501 (acknowledgement), or the list of lost Source Packets that 502 should be retransmitted (negative acknowledgement), or a 503 number of additional Repair Symbols needed to have a Full 504 Rank Linear System. 506 4.3. Coding In Practice 508 This section discusses practical aspects. Indeed, a practical 509 solution must specify the exact manner encoding and decoding is 510 performed but also all the peripheral aspects, for instance how an 511 encoder informs a decoder about the parameters used to generate a 512 certain Repair Packet (signaling). 514 (IETF) FEC Scheme: A specification that defines the additional 515 protocol aspects required to use a particular FEC code. In 516 particular the FEC Scheme defines in band (e.g., information 517 contained in Source and Repair Packet header or trailers) and 518 out of band (e.g., information contained in an SDP 519 description) signaling needed to synchronize encoders and 520 decoders. 522 Payload Indices, or (IETF) Encoding Symbol Identifiers (ESI): An ide 523 ntifier of a Source or Repair Symbol. If conceptually, each 524 symbol is identified by a unique ESI value, in practice, with 525 a continuous flow and a limited field size to hold the ESI, 526 wrapping to zero in unavoidable and the same integer value 527 will be re-used several times. 529 (IETF) FEC Payload ID: Information that identifies the contents of a 530 packet with respect to the FEC Scheme. The FEC Payload ID of 531 a packet containing Source Symbol(s) is usually different 532 from that of a packet containing Repair Symbol(s). The FEC 533 Payload ID typically contains at least an ESI. 535 Coding Vector and Encoding Window Signaling: With Sliding Window 536 Codes, the FEC Payload ID of a Repair Packet contains 537 information needed and sufficient to identify the Coding 538 Vector and Coding Window. Concerning the Coding Vector, this 539 may consist of a full list of Coding Coefficients (that may 540 be compressed or not), or a piece of information (e.g., a 541 seed) that can be used to generate the list of Coding 542 Coefficients thanks to a predefined algorithm known by 543 encoders and decoders (e.g., a Pseudo Random Number 544 Generator, or PRNG), or an ESI that points to a given entry 545 in a Generator Matrix in case of a Block Code. Concerning 546 the Coding Window, this may consist of the full list of ESI 547 of symbols in the Coding Window (that may be compressed or 548 not), or the ESI of the first Source Symbol along with their 549 number (assuming there is no gap). 551 5. IANA Considerations 553 This document is not subject to IANA registration. 555 6. Security Considerations 557 This document introduces a recommended terminology for network coding 558 and therefore does not contain any security consideration. This does 559 not mean that network coding systems do not have any security 560 implication. 562 7. References 564 7.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 7.2. Informative References 573 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 574 Correction (FEC) Building Block", RFC 5052, 575 DOI 10.17487/RFC5052, August 2007, 576 . 578 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 579 "NACK-Oriented Reliable Multicast (NORM) Transport 580 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 581 . 583 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 584 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 585 DOI 10.17487/RFC5775, April 2010, 586 . 588 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 589 Correction (FEC) Framework", RFC 6363, 590 DOI 10.17487/RFC6363, October 2011, 591 . 593 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 594 "FLUTE - File Delivery over Unidirectional Transport", 595 RFC 6726, DOI 10.17487/RFC6726, November 2012, 596 . 598 Appendix A. Additional references 600 Additional references on network coding are available in the NWCRG 601 research web site: https://irtf.org/nwcrg 603 Appendix B. Authors and Contributors 605 This document is the result of a collaborative work that involved 606 many authors and contributors from the IRTF NWCRG. They are listed 607 in alphabetical order in this document. 609 Authors' Addresses 611 Brian Adamson 612 NRL 613 USA 615 Email: brian.adamson@nrl.navy.mil 617 Cedric Adjih 618 INRIA 619 France 621 Email: cedric.adjih@inria.fr 623 Josu Bilbao 624 Ikerlan 625 Spain 627 Email: jbilbao@ikerlan.es 628 Victor Firoiu 629 BAE Systems 630 USA 632 Email: victor.firoiu@baesystems.com 634 Frank Fitzek 635 TU Dresden 636 Germany 638 Email: frank.fitzek@tu-dresden.de 640 Samah A. M. Ghanem 641 Independant 643 Email: samah.ghanem@gmail.com 645 Emmanuel Lochin 646 ISAE - Supaero 647 France 649 Email: emmanuel.lochin@isae-supaero.fr 651 Antonia Masucci 652 Orange 653 France 655 Marie-Jose Montpetit 656 Independant 657 USA 659 Email: marie@mjmontpetit.com 661 Morten V. Pedersen 662 Aalborg University 663 Denmark 665 Email: mvp@es.aau.dk 666 Goiuri Peralta 667 Ikerlan 668 Spain 670 Email: gperalta@ikerlan.es 672 Vincent Roca (editor) 673 INRIA 674 France 676 Email: vincent.roca@inria.fr 678 Paresh Saxena 679 AnsuR Technologies 680 Norway 682 Email: paresh.saxena@ansur.es 684 Senthil Sivakumar 685 Cisco 686 USA 688 Email: ssenthil@cisco.com