RFC 5445
Basic Forward Error Correction (FEC) Schemes
RFC 5445: Basic Forward Error Correction (FEC) Schemes ✨
Okay bestie, first the receipts 🧾🎀. This is RFC 5445, written by M. Watson at Digital Fountain and dated March 2009. It's a Standards Track doc from the Network Working Group, and it obsoletes RFC 3452 and RFC 3695 💜.
Status of This Memo
This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💅.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions with respect to this document 📜.
Abstract
Okay so the big idea: this document gives you Forward Error Correction (FEC) Scheme specifications under the Reliable Multicast Transport (RMT) FEC building block. The schemes are the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme 🦋. This document obsoletes RFC 3695 and takes responsibility for the FEC Schemes defined in RFC 3452 💖.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Compact No-Code FEC Scheme . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 4
3.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 4
3.2.2. FEC Object Transmission Information . . . . . . . . . 5
3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 7
3.4.1. Source Block Logistics . . . . . . . . . . . . . . . . 7
3.4.2. Sending and Receiving a Source Block . . . . . . . . . 8
4. Small Block, Large Block, and Expandable FEC Scheme . . . . . 9
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 9
4.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 9
4.2.2. FEC Object Transmission Information . . . . . . . . . 10
4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 12
5. Small Block Systematic FEC Scheme . . . . . . . . . . . . . . 12
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12
5.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 12
5.2.2. FEC Object Transmission Information . . . . . . . . . 13
5.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 15
6. Compact FEC Scheme . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 15
6.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 15
6.2.2. FEC Object Transmission Information . . . . . . . . . 15
6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Changes from Schemes Defined in RFC 3452 and RFC 3695 . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 181. Introduction ✨
This doc specifies the following FEC Schemes, following the specification requirements of the FEC building block [RFC5052]:
- Compact No-Code FEC Scheme
- Small Block, Large Block, and Expandable FEC Scheme
- Small Block Systematic FEC Scheme
- Compact FEC Scheme
This document inherits the context, language, declarations and restrictions of the FEC building block [RFC5052]. It also uses the terminology of the companion document [RFC3453], which describes how FEC codes are used in reliable IP multicast transport and gives an intro to some commonly used FEC codes 🦋.
Building blocks are defined in [RFC3048]. This document follows the general guidelines in [RFC3269] 💅.
[RFC3452] and [RFC3695] contain earlier versions of the FEC Schemes defined here. Both were published in the "Experimental" category. The RMT working group intended to resubmit these specifications as an IETF Proposed Standard eventually. This document obsoletes [RFC3695]. [RFC3452] has already been obsoleted by [RFC5052], and this document takes responsibility for the parts of [RFC3452] that [RFC5052] didn't include 🌸.
This Proposed Standard spec is based on the FEC Schemes in [RFC3452] and [RFC3695], and it stays backwards compatible with them. It's been updated based on accumulated experience and a more mature protocol since those originals came out 🧚. That experience applies to this spec itself and also to the congestion control strategies used with it.
The differences between the FEC Scheme specifications in [RFC3452] and [RFC3695] and this document are listed in Section 10 📜.
Integer fields specified in this document are all encoded in network byte order 🔢.
2. Requirements Notation
Here's the key word situation 💖. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in [RFC2119].
3. Compact No-Code FEC Scheme 🌈
3.1. Introduction
The Compact No-code FEC Scheme is a Fully-Specified FEC Scheme 🫶. It needs no FEC coding at all. It's mainly here so different implementations of protocol instantiations that use the FEC building block can do simple interoperability testing with each other 🧪.
3.2. Formats and Codes
3.2.1. FEC Payload ID(s)
The FEC Payload ID for the Compact No-Code FEC Scheme is made of a Source Block Number and an Encoding Symbol ID, as shown in Figure 1 🎀.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: FEC Payload ID Format for Compact No-Code FEC Scheme
Okay so the Source Block Number (SBN) is a 16-bit unsigned integer that tells you which source block of the object the encoding symbol in the packet payload was generated from 🧚. There are two modes, bestie. In the unique SBN mode, every source block in the object gets its own Source Block Number. In the non-unique SBN mode, the same Source Block Number can be used for more than one source block in the object. Which mode is used for an object is outside the scope of this document, but it MUST be communicated to receivers, either explicitly or implicitly, out-of-band 💅.
If the unique SBN mode is used, the successive Source Block Numbers go with consecutive source blocks of the object, starting at Source Block Number 0 for the first source block of the object. In this case, there are at most 2^^16 source blocks in the object 🔥.
If the non-unique SBN mode is used, the mapping from source blocks to Source Block Numbers MUST be communicated to receivers out-of-band, and how that's done is outside the scope of this document 🙈. The mapping could be implicit, for example determined by the transmission order of the source blocks. In non-unique SBN mode, packets for two different source blocks that map to the same Source Block Number SHOULD NOT be sent within an interval of time shorter than the transport time of a source block. The transport time of a source block includes the time needed to process it at the sender transport layer, the network transit time for packets, and the time needed to process it at the receiver transport. This lets the receiver clearly decide which packets belong to which source block 🦋.
The Encoding Symbol ID is a 16-bit unsigned integer that identifies which specific encoding symbol generated from the source block is carried in the packet payload. The exact details of how Encoding Symbol IDs correspond to the encoding symbols in the packet payload are specified in Section 3.4 ✨.
3.2.2. FEC Object Transmission Information
3.2.2.1. Mandatory
The mandatory FEC Object Transmission Information element for the Compact No-Code FEC Scheme is:
FEC Encoding ID: zero (0)
3.2.2.2. Common ✨
okay bestie, the Common FEC OTI bits are the stuff every Compact No-Code FEC Scheme setup has to agree on 🫶 Here are the elements and their value ranges:
Transfer-Length: a non-negative integer, less than 2^48, giving the object's length in octets 📦Encoding-Symbol-Length: a non-negative integer, less than 2^16, giving the length of each encoding symbol in octets 🧩Maximum-Source-Block-Length: a non-negative integer, less than 2^32, giving the max number of source symbols in one source block 🎀
and here's the encoded layout, Figure 2 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Encoded Common FEC Object Transmission Information (OTI) for Compact No-Code FEC Scheme
so the Transfer Length is encoded as an unsigned integer that's 48 bits, the Encoding Symbol Length is 16 bits, and the Maximum Source Block Length is 32 bits 💅
Now the rules, and these are serious 🥺 All Encoding Symbols of a transport object MUST have length equal to the length in the Encoding Symbol Length element. The one exception is the last source symbol of the last source block, so redundant padding isn't mandatory in that symbol 🌸 That last source symbol MUST be logically padded out with zeroes whenever another Encoding Symbol gets computed from it, so the sender and receiver read that Encoding Symbol value the same way 🔥 The padding doesn't actually have to be sent along with the last source symbol's data, which is lowkey a nice little win ✨
The Reserved field in the Encoded FEC Object Transmission Information MUST be set to zero by senders, and its value MUST be ignored by receivers 🙈
Note: this FEC Scheme was first defined in [RFC3695], which didn't require the Encoding Symbol Length to be the same for every source block. This document introduces a general requirement that the Encoding Symbol Length be the same across source blocks. Since no protocols were defined that support variation in the Encoding Symbol Length between source blocks, this can be done without introducing backwards compatibility issues 💜
3.2.2.3. Scheme-Specific
No Scheme-Specific FEC Object Transmission Information elements are defined by this FEC Scheme 🍓 Nothing extra to track here, bestie.
3.3. Procedures
To split the file into source blocks, the algorithm defined in Section 9.1. of [RFC5052] MUST be used 🧚
3.4. FEC Code Specification
Okay, this part is kinda iconic. The Compact No-Code FEC Scheme doesn't need any FEC encoding or decoding at all 💅 Instead, each encoding symbol is just consecutive bytes of a source block of the object. Clean, simple, slay.
The next two subsections explain how the Compact No-Code FEC Scheme works for each source block of an object 🦋
3.4.1. Source Block Logistics
Let X > 0 be the length of a source block in bytes. Let L > 0 be the length of the encoding symbol in each packet's payload. X and L are part of the FEC Object Transmission Information, and how that info gets to a receiver is outside the scope of this document 📬
For a source block that's X bytes long with Source Block Number I, let N = X/L rounded up to the nearest integer. The encoding symbol in a packet's payload is a consecutive chunk of the source block. The source block is logically split into N encoding symbols, each L bytes long, and their Encoding Symbol IDs run from 0 through N-1, starting at the beginning of the source block and going to the end ✨ So the encoding symbol with Encoding Symbol ID Y is bytes L*Y through L*(Y+1)-1 of the source block, where the bytes are numbered 0 through X-1. If X/L isn't a whole number, the last encoding symbol (Encoding Symbol ID = N-1) is bytes L*(N-1) through the last byte X-1 of the source block, and the remaining L*N - X bytes of that encoding symbol can be padded out with zeroes 🌈
Here's an example, okay? Say the source block length X = 20,400 and the encoding symbol length L = 1,000. The encoding symbol with Encoding Symbol ID = 10 holds bytes 10,000 through 10,999 of the source block. The encoding symbol with Encoding Symbol ID = 20 holds bytes 20,000 through the last byte 20,399 of the source block, and the remaining 600 bytes of that encoding symbol can be padded with zeroes 🎀
There are no restrictions beyond the rules above on how a sender generates the encoding symbols it sends from a source block. Even so, it is recommended that an implementor check out the companion document [RFC3452] for general advice 📚
The next subsection recommends a procedure for sending and receiving source blocks 🫶
3.4.2. Sending and Receiving a Source Block
Okay, sender side first 📤 The following carousel procedure is RECOMMENDED for a sender to generate packets containing FEC Payload IDs and matching encoding symbols for a source block with Source Block Number I. Set the length in bytes of an encoding symbol to a fixed value L. L should be reasonable for a packet payload (for example, make sure the total packet size doesn't go past the MTU), and it should be smaller than the source block length X, e.g., L = 1,000 for X >= 1,000. Initialize Y to a value randomly chosen in the interval [0..N-1]. Then repeat the following for each packet of the source block to be sent:
- If Y <= N-1, then generate encoding symbol Y.
- Within the FEC Payload ID, set the Source Block Length to X, set the Source Block Number to I, set the Encoding Symbol ID to Y, and place the FEC Payload ID and the encoding symbol into the packet to send.
- To get ready for the next packet: if Y < N-1, increment Y by one; else if Y = N-1, reset Y to zero.
Now receiver side 📥 The following procedure is RECOMMENDED for a receiver to recover the source block from packets it gets from a sender using the carousel procedure above. The receiver can tell which source block a packet came from by checking the Source Block Number in the FEC Payload ID. When the receiver gets the first FEC Payload ID for a source block, it uses the Source Block Length and Encoding Symbol Length (received out-of-band as part of the FEC Object Transmission Information) to work out X, the source block length in bytes, and L, the length of each encoding symbol in bytes. It allocates space for the X bytes the source block needs. The receiver also works out the encoding symbol length in the packet's payload by subtracting the packet header length from the total length of the received packet. It checks that this symbol length equals L, except when this is the last symbol of the source block, in which case the symbol in the packet may be shorter than L 🙈 After calculating N = X/L rounded up to the nearest integer, the receiver allocates a boolean array RECEIVED[0..N-1] with all N entries set to false, to track which encoding symbols have arrived ✨ It keeps receiving packets for the source block as long as at least one RECEIVED entry is still false, or until the application decides to give up on this source block and move on to others.
For each received packet of the source block (including the first one), the receiver does the following to help recover the source block. Let Y be the Encoding Symbol ID in the packet's FEC Payload ID. If Y <= N-1, the receiver copies the encoding symbol into the right place in the space reserved for the source block and sets RECEIVED[Y] = true. If all N entries of RECEIVED are true, the receiver has recovered the entire source block 👑
4. Small Block, Large Block, and Expandable FEC Scheme ✨
4.1. Introduction
This section defines an Under-Specified FEC Scheme for Small Block FEC codes, Large Block FEC codes, and Expandable FEC codes, as described in [RFC3453] 🌸
4.2. Formats and Codes
4.2.1. FEC Payload ID(s)
The FEC Payload ID is made of a Source Block Number and an Encoding Symbol ID, structured like Figure 3 🧁
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: FEC Payload ID Format for Small Block, Large Block, and Expandable FEC Codes
The Source Block Number is a 32-bit unsigned integer that 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 is a 32-bit unsigned integer that identifies which specific encoding symbol(s) generated from the source block are in the packet payload. How Encoding Symbol IDs map to the encoding symbol(s) in the payload depends on the particular FEC Scheme instance, identified by the FEC Encoding ID and the FEC Instance ID, and these details may be proprietary 🔐
4.2.2. FEC Object Transmission Information
4.2.2.1. Mandatory
The mandatory FEC Object Transmission Information element for the Small Block, Large Block, and Expandable FEC Scheme is:
- FEC Encoding ID: 128 💖
4.2.2.2. Common
okay bestie, the Common FEC OTI is the stuff the whole Small Block, Large Block, and Expandable FEC Scheme family agrees on ✨ here are the elements and their value ranges:
- FEC Instance ID: a non-negative integer less than
2^^16. 🎀 - Transfer-Length: a non-negative integer less than
2^^48, saying how long the object is in octets. 📏 - Encoding-Symbol-Length: a non-negative integer less than
2^^16, saying how long each encoding symbol is in octets. 🦋 - Maximum-Source-Block-Length: a non-negative integer less than
2^^32, saying the max number of source symbols in a source block. 👑
the encoded version is in Figure 4, and it's giving very organized 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Encoded Common FEC OTI for Small Block, Large Block, and Expandable FEC Scheme
the Transfer Length (48 bits), FEC Instance ID (16 bits), Encoding Symbol Length (16 bits), and Maximum Source Block Length (32 bits) are all encoded as unsigned integers 🔥
4.2.2.3. Scheme-Specific
the Scheme-Specific FEC OTI field is where this scheme makes room for Instance-specific FEC OTI 🧚 its format is defined in Figure 5:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Instance-specific FEC OTI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance-specific FEC OTI contd. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Encoded Scheme-Specific FEC OTI for Small Block, Large Block, and Expandable FEC Scheme
this field has two sub-fields, and they're both very important ngl:
- Length (1 octet): an unsigned integer that specifies the length of the Scheme-Specific FEC OTI in four-octet words (including this length field), except that the value zero indicates that no Instance-specific FEC OTI Information is provided. When the Length is zero, three padding bytes containing value zero SHALL follow the Length field to maintain 4-octet alignment. 🫶
- Instance-specific FEC OTI Information: the contents of this field are FEC Scheme Instance-specific. ✨
Note that in the case of a Content Delivery protocol that supports external signaling of the total FEC Object Transmission Information length, then the Scheme-Specific FEC OTI field defined here is optional. Otherwise, this field MUST be included. 💀
4.3. Procedures
the algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks 🍓
4.4. FEC Code Specification
the FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme, so they're out of scope of this document 🙈
5. Small Block Systematic FEC Scheme
5.1. Introduction
okay so this section defines an Under-Specified FEC Scheme for Small Block Systematic FEC codes, as described in [RFC3453]. For Small Block Systematic FEC codes, each source block is at most 65535 source symbols, no more 🌈
although these codes can usually fit under the FEC Encoding ID from Section 4, this scheme gets its own FEC Encoding ID so it has more flexibility and stays compact in the header 🦋 systematic codes often have small source blocks and small expansion factors, so the data source might need to change the source block length a lot. to let that length change dynamically and tell receivers about it with low overhead, the block length is included in the FEC Payload ID 💖
5.2. Formats and Codes
5.2.1. FEC Payload ID(s)
the FEC Payload ID is made of the Source Block Number, Source Block Length, and Encoding Symbol ID, structured like Figure 6:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: FEC Payload ID Format for Small Block Systematic FEC Scheme
the Source Block Number is a 32-bit unsigned integer that 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 Source Block Length is a 16-bit unsigned integer that gives the length, in units of source symbols, of the source block identified by the Source Block Number ✨
the Encoding Symbol ID is a 16-bit unsigned integer that 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 generated by the encoder. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload depend on the particular FEC Scheme instance used, as identified by the FEC Instance ID, and these details may be proprietary 🤫
5.2.2. FEC Object Transmission Information
5.2.2.1. Mandatory
the mandatory FEC Object Transmission Information element for the Small Block Systematic FEC Scheme is:
- FEC Encoding ID: 129 🌸
5.2.2.2. Common
the Common FEC OTI elements and their value ranges for the Small Block Systematic FEC Scheme are:
- FEC Instance ID: a non-negative integer less than
2^^16. 🎀 - Transfer-Length: a non-negative integer less than
2^^48, indicating the length of the object in octets. 📏 - Encoding-Symbol-Length: a non-negative integer less than
2^^16, indicating the length of each encoding symbol in octets. 🦋 - Maximum-Source-Block-Length: a non-negative integer less than
2^^16, indicating the maximum number of source symbols in a source block. 👑 - Max-Number-of-Encoding-Symbols: a non-negative integer less than
2^^16, indicating the maximum number of encoding symbols per block (i.e., source plus repair symbols in the case of a systematic code). 🧚
the encoded Common FEC OTI is defined in Figure 7 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: FEC OTI Format for Small Block Systematic FEC Scheme
the Transfer Length (48 bits), FEC Instance ID (16 bits), Encoding Symbol Length (16 bits), Maximum Source Block Length (16 bits), and Maximum Number of Encoding Symbols (16 bits) are encoded as unsigned integers 🔥
all Encoding Symbols of a transport object MUST have length equal to the length specified in the Encoding Symbol Length field, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol, to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding need not be actually sent with the data of the last source symbol. 🙈
Note: this FEC Scheme was first defined in [RFC3452], which did not require that the Encoding Symbol Length should be the same for every source block. However, no protocols have been defined that support variation in the Encoding Symbol Length between source blocks, and thus introduction of a general requirement that the Encoding Symbol Length be the same across source blocks (as defined here) should not cause backwards compatibility issues and will aid interoperability. 🌈
5.2.2.3. Scheme-Specific
the Scheme-Specific FEC OTI format defined in Section 4.2.2.3 SHALL be used 💖
5.3. Procedures
the algorithm defined in Section 9.1. of [RFC5052] MAY be used to partition the file into source blocks. Otherwise, the FEC Scheme instance MUST specify the algorithm that is used 🦋
5.4. FEC Code Specification
the FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme, so they're out of scope of this document 🙈
6. Compact FEC Scheme
6.1. Introduction
the Compact FEC Scheme is an Under-Specified FEC Scheme. It's similar in spirit to the Compact No-Code FEC Scheme, except that a non-trivial FEC encoding (that is Under-Specified) may be used to generate encoding symbol(s) placed in the payload of each packet, and a corresponding FEC decoder may be used to produce the source block from received packets 👑
6.2. Formats and Codes
6.2.1. FEC Payload ID(s)
the FEC Payload ID format defined in Section 3.2.1 SHALL be used 🧚
6.2.2. FEC Object Transmission Information
6.2.2.1. Mandatory
the mandatory FEC Object Transmission Information element for the Compact No-Code FEC Scheme is:
- FEC Encoding ID: 130 🌸
6.2.2.2. Common
the Common FEC OTI elements and their encoding are the same as defined for the Small Block, Large Block, and Expandable FEC Scheme in Figure 4 💅
6.2.2.3. Scheme-Specific
the Scheme-Specific FEC OTI format defined in Section 4.2.2.3 SHALL be used 🫶
6.3. Procedures
the algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks 🔥
6.4. FEC Code Specification ✨
Okay bestie, the actual FEC code spec and the way Encoding Symbol IDs get matched up with encoding symbols are both defined by specific instances of this scheme, so they're totally out of scope for this document 🎀
7. Security Considerations 🔒
Good news: this spec doesn't add any new security considerations on top of what [RFC5052] already covers 💖
8. Acknowledgements 🫶
This document is basically built on [RFC3695] by Michael Luby and Lorenzo Vicisano, and on [RFC3452] by Michael Luby, Lorenzo Vicisano, Jim Gemmell, Luigi Rizzo, Mark Handley, and Jon Crowcroft. Iconic legends, all of them 👑
9. IANA Considerations 🦋
FEC Encoding IDs 0 and 130 were first defined and registered in the ietf:rmt:fec:encoding namespace by [RFC3695]. This document updates and obsoletes the definitions from that specification, so references to that specification should be replaced with references to this document.
FEC Encoding IDs 128 and 129 were first defined and registered in the ietf:rmt:fec:encoding namespace by [RFC3452]. This document updates and obsoletes the definitions from that specification, so references to that specification should be replaced with references to this document.
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA registration. For general guidance on how IANA considerations apply to this document, check out [RFC5052].
This document assigns the Fully-Specified FEC Encoding ID 0 under the ietf:rmt:fec:encoding name-space (previously assigned by [RFC3695], which this document obsoletes) to "Compact No-Code" as specified in Section 3 above.
This document assigns the Under-Specified FEC Encoding ID 128 under the ietf:rmt:fec:encoding name-space (previously assigned by [RFC3452]) to "Small Block, Large Block, and Please note that we have added a comma between large block and expandable throughout this document (RFC Editor style is to include a comme before the last item of a series). If you do not object, we will ask IANA to include this comma in their registry for consistency. --> Expandable FEC Codes" as specified in Section 4 above.
This document assigns the Under-Specified FEC Encoding ID 129 under the ietf:rmt:fec:encoding name-space (previously assigned by [RFC3452]) to "Small Block Systematic FEC Codes" as specified in Section 5 above.
This document assigns the Under-Specified FEC Encoding ID 130 under the ietf:rmt:fec:encoding name-space (previously assigned by [RFC3695], which this document obsoletes) to "Compact FEC" as specified in Section 6 above.
Since FEC Encoding IDs 128, 129, and 130 are Under-Specified, "FEC Instance ID" sub-name-spaces must be established in accordance with [RFC5052]. That means this document also takes on responsibility for the "FEC Instance ID" registries named below 🌸
ietf:rmt:fec:encoding:instance:128, scoped by ietf:rmt:fec:
encoding = 128
ietf:rmt:fec:encoding:instance:129, scoped by ietf:rmt:fec:
encoding = 129
ietf:rmt:fec:encoding:instance:130, scoped by ietf:rmt:fec:
encoding = 130The values that can be assigned within these namespaces are non-negative numeric indices. Assignment requests are granted on a "First Come First Served" basis. [RFC5052] specifies additional criteria that MUST be met for assignment within the generic ietf:rmt:fec:encoding:instance name-space. These criteria also apply to ietf:rmt:fec:encoding:instance:128, ietf:rmt:fec:encoding:instance:129, and ietf:rmt:fec:encoding:instance:130 💅
10. Changes from Schemes Defined in RFC 3452 and RFC 3695 🎀
This section is the glow-up recap: it lists what changed between the Experimental versions of these FEC Scheme specs in RFC 3452 [RFC3452] and RFC 3695 [RFC3695] and what's defined in this specification ✨
- Scheme definitions were updated so they meet the requirements of [RFC5052]. Iykyk 🙈
- The complete encoding formats for the FEC Object Transmission Information of each scheme are now defined here, instead of inside the content delivery protocol specs, since the exact format depends on the FEC Scheme 🧚
- The earlier specs for the Compact No-Code and Small Block Systematic FEC Schemes didn't require every encoding symbol of an object to have the same length. This specification introduces that requirement. Since no protocols have been defined that support varying the encoding symbol length within an object, this shouldn't cause backwards compatibility issues 🌈
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.11.2. Informative References
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "Forward Error Correction (FEC)
Building Block", RFC 3452, December 2002.
[RFC3453] 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.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for
Reliable Multicast Transport (RMT) Building Blocks and
Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3048] 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.
[RFC3695] Luby, M. and L. Vicisano, "Compact Forward Error
Correction (FEC) Schemes", RFC 3695, February 2004.Author's Address 💌
Mark Watson
Digital Fountain
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
USA
EMail: mark@digitalfountain.com📦 where this page comes from
- ietf: rfc5445 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms