RFC 3452

Forward Error Correction (FEC) Building Block

📅 published December 2002, from ietf

Forward Error Correction (FEC) Building Block ✨

Okay bestie, let's get the deets on this one 🎀. It's RFC 3452, written by the RMT working group in the IETF's Network Working Group, and it's Experimental, not a standard. The authors are M. Luby (Digital Fountain), L. Vicisano (Cisco), J. Gemmell (Microsoft), L. Rizzo (Univ. Pisa), M. Handley (ICIR), and J. Crowcroft (Cambridge Univ.). It's dated December 2002, and the title block doesn't list anything it obsoletes or updates 🌸.

Network Working Group                                            M. Luby
Request for Comments: 3452                              Digital Fountain

Yes, that's the author list in full, and yes, I know the layout is cute, but we're keeping the prose version 💅.

Status of this Memo 🌈

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract ✨

Okay so this doc is all about using Forward Error Correction (FEC) codes to deliver data more efficiently and/or boost reliability for data transport 🦋. The main focus is applying FEC codes to one-to-many reliable data transport over IP multicast, which is giving main character energy 👑. It explains what info you need to identify a specific FEC code, what info has to be communicated out-of-band so you can actually use that code, and what info goes in data packets to say which encoding symbols they're carrying 🧚. It also covers how FEC codes get specified and registered with the Internet Assigned Numbers Authority (IANA). And you should read it together with the companion doc, "The Use of Forward Error Correction (FEC) in Reliable Multicast", because this one uses that doc's terminology too 💖.

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Rationale. . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Functionality. . . . . . . . . . . . . . . . . . . . . . .   3
  3.1 FEC Encoding ID and FEC Instance ID. . . . . . . . . . .   5
  3.2 FEC Payload ID and FEC Object Transmission Information .   6
4.  Applicability Statement . . .  . . . . . . . . . . . . . .   7
5.  Packet Header Fields . . . . . . . . . . . . . . . . . . .   8
  5.1 Small Block, Large Block and Expandable FEC Codes. . . .   8
  5.2 Small Block Systematic FEC Codes . . . . . . . . . . . .   9
6.  Requirements from other building blocks. . . . . . . . . .  11
7.  Security Considerations. . . . . . . . . . . . . . . . . .  11
8.  IANA Considerations. . . . . . . . . . . . . . . . . . . .  12
  8.1 Explicit IANA Assignment Guidelines. . . . . . . . . . .  12
9.  Intellectual Property Disclosure . . . . . . . . . . . . .  13
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . .  14
11. References . . . . . . . . . . . . . . . . . . . . . . . .  14
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . .  15
13. Full Copyright Statement . . . . . . . . . . . . . . . . .  16

1. Introduction 🦋

This doc describes how to use Forward Error Correction (FEC) codes to support reliable delivery of content using IP multicast 💅. You should read it alongside the companion document [4], which covers how FEC codes get used in reliable IP multicast transport and gives an intro to some commonly used FEC codes 🌸. It uses that doc's terminology too, so keep it open!

This document describes a building block as defined in RFC 3048 [9] ✨. It's a product of the IETF RMT WG and follows the general guidelines in RFC 3269 [3] 🎀.

Okay, here's the key words lineup 🔥: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". In this document they're interpreted as described in RFC2119 [2] 💜.

Statement of Intent

This memo contains part of the definitions needed to fully specify a Reliable Multicast Transport protocol, following RFC 2357 🌈. As RFC 2357 says, using any reliable multicast protocol on the Internet requires an adequate congestion control scheme 🚦.

Until a scheme like that is available, or until an existing one gets proven adequate, the Reliable Multicast Transport working group (RMT) is publishing this Request for Comments in the "Experimental" category 🧪.

RMT intends to resubmit this specification as an IETF Proposed Standard as soon as that condition is met ⭐.

2. Rationale 💖

FEC codes are a super valuable basic component of any transport protocol that wants to provide reliable delivery of content 🫶. They're especially valuable with IP multicast because FEC encoding symbols can help every receiver rebuild the content, even when different receivers got different encoding symbols 🦋. On top of that, FEC codes can reduce or even get rid of the need for receivers to send feedback to the sender asking for lost packets to be retransmitted 🙌.

The goal of the FEC building block is to describe the FEC-related functionality that all reliable content delivery IP multicast protocols have in common, and to leave out anything specific to a particular protocol 🧚. The main shared functionality here is the FEC encoding symbols for an object, which travel in packets from a sender to receivers 📦. This document doesn't describe how receivers might request transmission of particular encoding symbols for an object 🙈. That's because some protocols do find those requests useful, but others don't need them at all 🤷‍♀️.

The companion document [4] is the place to go for the full scoop on the benefits of using FEC codes for reliable content delivery over IP multicast 💜. FEC codes are also useful for unicast, so this document's scope and applicability aren't limited to IP multicast 🌸.

3. Functionality ✨

This section describes FEC information that is either sent out-of-band or in packets. The FEC information relates to transmitting data about a particular object 🎀. There are three classes of packets that may contain FEC information: data packets, session-control packets, and feedback packets 💅. They usually carry different kinds of FEC information 🌈. Also, some protocols may not use session-control or feedback packets at all 🦋.

Data packets can sometimes double as session-control packets too 🧚. Both data and session-control packets generally travel downstream from the sender toward receivers, and they're sent either to a multicast channel or to a specific receiver using unicast 🌊.

As a general rule, feedback packets travel upstream, from receivers back to the sender 🔙. Sometimes, though, they might go to a multicast channel, to another receiver, or to some intermediate node or neighboring router that provides recovery services 🤭.

This document specifies the FEC information that must be carried in data packets, plus the other FEC information that must be communicated either out-of-band or in data packets 💖. It doesn't specify out-of-band methods, and it doesn't specify how out-of-band FEC information is associated with FEC information carried in data packets 🙃. Those methods must be specified in a complete protocol instantiation that uses the FEC building block 🫶. Here's how the FEC information is classified 📋:

  1. FEC Encoding ID: This identifies the FEC encoder being used and lets receivers pick the right FEC decoder 🔑. The value of the FEC Encoding ID MUST be the same for all transmission of data related to a particular object 🔒. It MAY vary across transmissions of data about different objects, even if they go to the same set of multicast channels and/or use a single upper-layer session 🔀. The FEC Encoding ID is subject to IANA registration 📝.
  2. FEC Instance ID: This gives a more specific identification of the FEC encoder being used for an Under-Specified FEC scheme 🔍. This value is not used for Fully-Specified FEC schemes 🚫. (See Section 3.1 for the definition of Under-Specified and Fully-Specified FEC schemes.) The FEC Instance ID is scoped by the FEC Encoding ID, and it's subject to IANA registration 🌸.
  3. FEC Payload ID: This identifies the encoding symbol(s) in the payload of the packet 📦. The types and lengths of the fields in the FEC Payload ID, meaning its format, are determined by the FEC Encoding ID 🧩. The full specification of each field MUST be uniquely determined by the FEC Encoding ID for Fully-Specified FEC schemes, and MUST be uniquely determined by the combination of the FEC Encoding ID and the FEC Instance ID for Under-Specified FEC schemes 💎. For example, with the Under-Specified FEC scheme that has FEC Encoding ID 129, defined in Section 5.1, the fields in the FEC Payload ID are a 32-bit Source Block Number followed by a 32-bit Encoding Symbol ID. The full spec for both fields depends on the FEC Instance ID 🎀.
  4. FEC Object Transmission Information: This is the info about how a specific object was encoded, which the FEC decoder needs 🧠. For example, with the Under-Specified FEC scheme that has FEC Encoding ID 129, defined in Section 5.1, this info might include the lengths of the different source blocks that make up the object, plus the overall object length 📏. It might also include specific parameters of the FEC encoder ⚙️.

The FEC Encoding ID, the FEC Instance ID (for Under-Specified FEC schemes), and the FEC Object Transmission Information can be sent to a receiver within the data packet headers, within session control packets, or by some other means 🚀. Either way, how that info gets to a receiver is outside the scope of this document 🙅‍♀️. The FEC Payload ID MUST be included in the data packet header fields, because it describes the encoding symbols contained in the packet 💜🔥.

3.1. FEC Encoding ID and FEC Instance ID ✨

okay so the FEC Encoding ID is basically a numeric index 🔢 that points to either one specific FEC scheme OR a whole class of encoding schemes that all use the same FEC Payload ID format. bestie, that's giving organization 💅

A scheme counts as a Fully-Specified FEC scheme if it's formally and fully written down, so an independent implementor can build both the encoder and the decoder from an IETF RFC alone 📜 no mystery sauce needed. The FEC Encoding ID uniquely identifies a Fully-Specified FEC scheme 💖 and companion documents of this specification can define Fully-Specified schemes and link them to FEC Encoding ID values 🦋

These documents MUST also specify a format for the FEC Payload ID and spell out the information in the FEC Object Transmission Information 🎀

Now the plot twist 🙈 a scheme might NOT be fully specified, either because there's no spec available or because some party owns the encoding scheme and won't disclose the algorithm. We call these Under-Specified FEC schemes 🔒 and here's the deal for them:

  • The fields and their formats of the FEC Payload ID, plus the specific information in the FEC Object Transmission Information, MUST be defined for the Under-Specified FEC scheme ✨
  • A value for the FEC Encoding ID MUST be reserved and tied to those fields, formats, and information. If an already reserved FEC Encoding ID value has the same FEC Payload ID fields and formats, and the same FEC Object Transmission Information needs as the new scheme, then that existing value MUST be reused 🔁
  • A value for the FEC Instance ID MUST be reserved 🧚

An Under-Specified FEC scheme is fully identified by the pair (FEC Encoding ID, FEC Instance ID) 👑 That pair MUST identify a single scheme that has at least one implementation. The party that owns the pair MUST be able to explain how to get the scheme 🛍️ for example, a link to a publicly available reference implementation, or the name and contact details of a company that sells it, either as a standalone product or bundled into another product.

Different Under-Specified FEC schemes that share the same FEC Encoding ID but have different FEC Instance IDs also share the same fields and formats for the FEC Payload ID, and they specify the same information in the FEC Object Transmission Information 🌸 it's like sisters with different names but the same family rules 💜

This specification reserves the range 0-127 for FEC Encoding ID values used by Fully-Specified FEC schemes, and the range 128-255 for FEC Encoding ID values used by Under-Specified FEC schemes 🌈

3.2. FEC Payload ID and FEC Object Transmission Information 🎀

Any document that specifies an FEC scheme and reserves an FEC Encoding ID value MUST define the fields and their packet formats for the FEC Payload ID, and it MUST also specify the information in the FEC Object Transmission Information, based on what the encoding scheme needs 🧁 This goes for documents reserving FEC Encoding ID values for both Fully-Specified and Under-Specified schemes, so nobody gets left out 🫶

Here's the strict part 🥹 the spec for the FEC Payload ID fields MUST describe what each field means and how it's formatted, all the way down to the level of individual bits 🔬 Also, the total length of all the FEC Payload ID fields MUST be a multiple of a 4-byte word. This keeps packet fields lined up nicely when protocols are actually built 📦✨

4. Applicability Statement 🌟

The FEC building block is for creating and sending encoding symbols for objects that need reliable transport over IP multicast or unicast 🚀 It does NOT give you any higher-level session support, though. So, for example, lots of objects can ride in the same session, and then a higher-level building block can carry a unique Transport Object ID (TOI) for each object, so the receiver can sort out which packets belong to which object using the TOI in each packet 🗂️ Another example: a receiver might subscribe to more than one session at once 👀

In that case, a higher-level building block can carry a unique Transport Session ID (TSI) for each session, so the receiver can split up packets by the TSI in each packet 🦋

Other building blocks can directly support sending out-of-band information that matters to the FEC building block 📬 For instance, the object length is part of the FEC Object Transmission Information, and in some cases it may be shared with receivers out-of-band. One way to get it to receivers is through another building block that carries that info 💅

Some protocols use FEC codes to repair lost packets 🩹 In FEC repair schemes, feedback packets are (optionally) used to ask for FEC retransmission 🔁 The FEC-related info in feedback packets usually has an FEC Block ID, which says which block is being repaired, plus how many Repair Symbols are requested 🧮 That's the most common setup, but variants exist where receivers ask for something more specific, like an index range or a list of symbols they've already accepted 🎯 A single feedback packet can also hold multiple requests 📝 This document doesn't go into detail about feedback schemes used with FEC, or the format of FEC info in feedback packets 🙅‍♀️ If a complete protocol uses feedback packets, those details must be provided in the protocol instantiation specification 📑

The FEC building block doesn't provide any congestion control support at all 🚫🚗 So any complete protocol MUST provide congestion control that conforms to RFC 2357 [5], and that MUST come from another building block whenever the FEC building block is used in a protocol 🛡️

You can find a fuller description of where FEC codes apply in the companion document [4] 📚

5. Packet Header Fields 🎀

This section lays out the FEC Encoding ID, the matching FEC Payload ID format, and the specific FEC Object Transmission Information for a bunch of known Under-Specified FEC schemes 🧠 Under-Specified FEC schemes that use the same FEC Payload ID fields, formats, and specific FEC Object Transmission Information as one of the FEC Encoding IDs in this section MUST use that corresponding FEC Encoding ID 🔑 Other FEC Encoding IDs can be specified for other Under-Specified schemes in companion documents 💜

5.1. Small Block, Large Block and Expandable FEC Codes 💖

This subsection reserves FEC Encoding ID value 128 for the Under-Specified FEC schemes described in [4] that are called Small Block FEC codes, Large Block FEC codes and Expandable FEC codes 🌸

The FEC Payload ID is made of a Source Block Number and an Encoding Symbol ID, laid out like this 👇

  0                   1                   2                   3
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Source Block Number                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Encoding Symbol ID                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Source Block Number tells you which source block of the object the encoding symbol(s) in the payload came from 🧩 These blocks are numbered consecutively, from 0 to N-1, where N is the number of source blocks in the object 🔢

The Encoding Symbol ID tells you which specific encoding symbol(s) generated from that source block are carried in the packet payload 📦 How Encoding Symbol IDs match up with the encoding symbol(s) in the payload depends on the encoding algorithm identified by the FEC Encoding ID and the FEC Instance ID, and those details may be proprietary 🤫

For this scheme, the FEC Object Transmission Information has this specific info:

  • The FEC Encoding ID 128. 🔖
  • The FEC Instance ID associated with FEC Encoding ID 128 to be used. 🪪
  • The total length of the object in bytes. 📏
  • The number of source blocks the object is split into, and the length of each source block in bytes. ✂️

How this out-of-band info gets to the receiver is outside the scope of this document 🙃 Some options: the source block lengths might be derived from the object length using a fixed algorithm 🧮 All source blocks might be the same length, and that length gets passed out-of-band to the receiver 🤝 Or the full-sized source block length could be given, and used for every source block except the last one, whose length is calculated from the full source block length and the object length 🧁

5.2. Small Block Systematic FEC Codes 🧁

okay so this subsection reserves the FEC Encoding ID value 129 for the Under-Specified FEC schemes described in [4] that are called Small Block Systematic FEC codes 🦋 for these codes, each source block is of length at most 65536 source symbols.

ngl these codes can mostly fit under the FEC Encoding ID from Section 5.1, but a specific FEC Encoding ID gets its own spot for Small Block Systematic FEC codes so there's more flexibility and the header stays compact 🎀 small source block lengths and small expansion factors are super common with systematic codes, so the data source might need to keep changing the source block length. so the block length gets included in the FEC Payload ID, which lets it vary dynamically and tells the receivers about it with low overhead 💅

the FEC Payload ID is made of the Source Block Number, Source Block Length and the Encoding Symbol ID:

  0                   1                   2                   3
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Source Block Number                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Source Block Length      |       Encoding Symbol ID      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the Source Block Number tells you which source block of the object the encoding symbol(s) in the payload came from 🧚 these blocks get numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.

the Source Block Length is the length, measured in units of source symbols, of the source block identified by the Source Block Number ✨

the Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload 🌸 each encoding symbol is either an original source symbol or a redundant symbol made by the encoder. the exact correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload depends on the particular encoding algorithm identified by the FEC Encoding ID and the FEC Instance ID, and those details may be proprietary 🙈

the FEC Object Transmission Information has the following specific info:

  • The FEC Encoding ID 129.
  • The FEC Instance ID associated with the FEC Encoding ID 129 to be used.
  • The total length of the object in bytes.
  • The maximum number of encoding symbols that can be generated for any source block. this field is provided, for example, so receivers can preallocate buffer space that is suitable for decoding to recover any source block 🫶
  • For each source block, the length in bytes of encoding symbols for the source block.

how this out-of-band info gets communicated is outside the scope of this document, so don't come for me on that 🙅‍♀️ as an example, the length in bytes of encoding symbols for each source block may be the same for all source blocks. as another example, the encoding symbol length may be the same for all source blocks of a given object, and this length is communicated for each object. as a third example, there may be a threshold value I, and for all source blocks consisting of less than I source symbols, the encoding symbol length is one fixed number of bytes, but for all source blocks consisting of I or more source symbols, the encoding symbol length is a different fixed number of bytes 🌈

note that each encoding symbol, i.e., each source symbol and redundant symbol, must be the same length for a given source block, and this implies that each source block length is a multiple of its encoding symbol length. if the original source block length is not a multiple of the encoding symbol length, it is up to the sending application to appropriately pad the original source block to form the source block to be encoded, and to communicate this padding to the receiving application. the form of this padding, if used, and how it's communicated to the receiving application, is outside the scope of this document and must be handled at the application level 💖

6. Requirements from other building blocks 🌷

okay this one is important bestie 🚨 the FEC building block does not provide any support for congestion control. any complete protocol MUST provide congestion control that conforms to RFC 2357 [5], and thus this MUST be provided by another building block when the FEC building block is used in a protocol 👑

there are no other specific requirements from other building blocks for the use of this FEC building block. however, any protocol that uses the FEC building block will inevitably use other building blocks, for example to support sending higher level session information within data packets containing FEC encoding symbols ✨

7. Security Considerations 💀

this section is serious, so buckle up 😭 data delivery can be subject to denial-of-service attacks by attackers who send corrupted packets that are accepted as legitimate by receivers. this is especially a concern for multicast delivery, because a corrupted packet may be injected into the session close to the root of the multicast tree, in which case the corrupted packet will arrive at many receivers. it's also a big deal for the FEC building block, because the use of even one corrupted packet containing encoding data may result in decoding an object that is completely corrupted and unusable 🔥

so it is RECOMMENDED that decoded objects be checked for integrity before they get delivered to an application. for example, an MD5 hash [8] of an object may be appended before transmission, and the MD5 hash is computed and checked after the object is decoded but before it's delivered to an application. moreover, to get strong cryptographic integrity protection, a digital signature verifiable by the receiver SHOULD be computed on top of such a hash value. it is also RECOMMENDED that a packet authentication protocol such as TESLA [7] be used to detect and discard corrupted packets upon arrival. furthermore, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers, to limit the possibility of a bad agent successfully injecting a corrupted packet into the multicast tree data path 🛡️

another security concern: some FEC information may be obtained by receivers out-of-band in a session description. if the session description is forged or corrupted, the receivers will not use the correct protocol for decoding content from received packets. to avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders 🙅‍♀️

8. IANA Considerations 🧾

values of FEC Encoding IDs and FEC Instance IDs are subject to IANA registration. FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding IDs scope ranges of FEC Instance IDs. only FEC Encoding IDs that correspond to Under-Specified FEC schemes scope a corresponding set of FEC Instance IDs 🌸

the FEC Encoding ID is a numeric non-negative index. in this document, the range of values for FEC Encoding IDs is 0 to 255. values from 0 to 127 are reserved for Fully-Specified FEC schemes, and values from 128 to 255 are reserved for Under-Specified FEC schemes, as described in more detail in Section 3.1. this specification already assigns the values 128 and 129, as described in Section 5 🎀

each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an independent range of FEC Instance IDs (i.e., the same value of FEC Instance ID can be reused for different FEC Encoding IDs). an FEC Instance ID is a numeric non-negative index 🦋

8.1. Explicit IANA Assignment Guidelines 📋

this document defines a name-space for FEC Encoding IDs named:

                       ietf:rmt:fec:encoding

IANA has established and manages the new registry for the "ietf:rmt:fec:encoding" name-space. the values that can be assigned within the "ietf:rmt:fec:encoding" name-space are numeric indexes in the range [0, 255], boundaries included. assignment requests are granted on a "Specification Required" basis as defined in RFC 2434 [6]: an IETF RFC MUST exist and specify the FEC Payload ID fields and formats, as well as the FEC Object Transmission Information, for the value of "ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned by IANA (see Section 3.1 for more details). note that the values 128 and 129 of "ietf:rmt:fec:encoding" are already assigned by this document, as described in Section 5 💖

this document also defines a name-space for FEC Instance IDs named:

                  ietf:rmt:fec:encoding:instance

the "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space associated with the "ietf:rmt:fec:encoding" name-space. each value of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a separate "ietf:rmt:fec:encoding:instance" sub-name-space that it scopes. values of "ietf:rmt:fec:encoding" in the range [0, 127] do not scope a "ietf:rmt:fec:encoding:instance" sub-name-space 🧚

the values that can be assigned within each "ietf:rmt:fec:encoding:instance" sub-name-space are non-negative numeric indices. assignment requests are granted on a "First Come First Served" basis as defined in RFC 2434 [6]. the same value of "ietf:rmt:fec:encoding:instance" can be assigned within multiple distinct sub-name-spaces, i.e., the same value of "ietf:rmt:fec:encoding:instance" can be used for multiple values of "ietf:rmt:fec:encoding" ✨

requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide the following information:

  • The value of "ietf:rmt:fec:encoding" that scopes the "ietf:rmt:fec:encoding:instance" sub-name-space. This must be in the range [128, 255].
  • Point of contact information.
  • A pointer to publicly accessible documentation describing the Under-Specified FEC scheme, associated with the value of "ietf:rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g., a pointer to a publicly available reference implementation, or the name and contacts of a company that sells it, either separately or embedded in a product).

it is the responsibility of the requestor to keep all the above information up to date 🫶

9. Intellectual Property Disclosure ⚖️

the IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. for more information, consult the online list of claimed rights 🌈

10. Acknowledgments 🫶

Brian Adamson contributed to this document by shaping Section 5.2 and providing general feedback. we also wish to thank Vincent Roca, Justin Chapweske and Roger Kermode for their extensive comments 💜

11. References 📚✨

Okay bestie, this is the reading list, and it's a whole lot. Nine refs, every one exactly as written so nothing gets lost 💅

  • [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
  • [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
  • [5] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
  • [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [7] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
  • [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
  • [9] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.

12. Authors' Addresses 🎀

Meet the squad behind this spec 🫶 Here are the authors' addresses, copied exactly so you can reach them.

Michael Luby
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA  94538

EMail: luby@digitalfountain.com

Lorenzo Vicisano
Cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134

EMail: lorenzo@cisco.com

Jim Gemmell
Microsoft Research
455 Market St. #1690
San Francisco, CA, 94105

EMail: jgemmell@microsoft.com

Luigi Rizzo
Dip. di Ing. dell'Informazione
Universita` di Pisa
via Diotisalvi 2, 56126 Pisa, Italy

EMail: luigi@iet.unipi.it

Mark Handley
ICSI Center for Internet Research
1947 Center St.
Berkeley CA, USA, 94704

EMail: mjh@icir.org

Jon Crowcroft
Marconi Professor of Communications Systems
University of Cambridge
Computer Laboratory
William Gates Building
J J Thomson Avenue
Cambridge
CB3 0FD

EMail: Jon.Crowcroft@cl.cam.ac.uk

The legal bit, and it's important, so read it all 🙈

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💜

Last but not least, the RFC Editor's funding 💖

Funding for the RFC Editor function is currently provided by the Internet Society.

📦 where this page comes from