3 - 4 - 6 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W
FEC
Click on the red underlined text to get to the source
... stream types. NORM senders
provide for repair transmission of data and/or FEC content in
response to NACK messages received from the receiver ...
... NORM
provides for the use of packet-level forward error correction (FEC)
techniques for efficient multicast repair and optional proactive
...
... multicast repair and optional proactive
transmission robustness [10]. FEC-based repair can be used to
greatly reduce the quantity of reliable multicast repair requests and
...
... as it is transported.
All NormObjects are logically segmented into FEC coding blocks and
symbols for transmission by the sender. In NORM ...
... symbols for transmission by the sender. In NORM, an FEC encoding
symbol directly corresponds to the payload ...
... DATA messages or
"segment". Note that when systematic FEC codes are used, the payload
of NORM ...
... of NORM_DATA messages sent for the first portion of a FEC encoding
block are source symbols (actual segments ...
... user data),
while the remaining symbols for the block consist of parity symbols
generated by FEC encoding. These parity symbols are generally sent
in response to repair requests, but some number may be sent
...
... proactively at the end each encoding block to increase the robustness
of transmission. When non-systematic FEC codes are used, all symbols
sent consist of FEC encoding ...
... of transmission. When non-systematic FEC codes are used, all symbols
sent consist of FEC encoding parity content. In this case, the
receiver ...
... receiver must receive a sufficient number of symbols to reconstruct
(via FEC decoding) the original user data for the given block. In
this document, the terms "symbol" and "segment ...
... individual segments or symbols of the NormObject are further
identified with FEC payload identifiers which include coding block
and symbol identifiers ...
... NORM_DATA. These
messages carry original data segments or FEC symbols and repair
segments/symbols for the bulk data/file or stream ...
... segments/symbols for the bulk data/file or stream NormObjects being
transferred. By default, redundant FEC symbols are sent only in
response to receiver repair requests (NACKs ...
... NACKs) and thus normally little
or no additional transmission overhead is imposed due to FEC
encoding. However, the NORM ...
... encoding. However, the NORM implementation MAY be optionally
configured to proactively transmit some amount of redundant FEC
symbols along with the original content to potentially enhance
performance ...
... messages can be NACKed and repaired with a slightly lower delay
process than NORM's general FEC-encoded data content. NORM_INFO may
serve special purposes for some bulk transfer, reliable multicast ...
... Payload ID as
specified by the FEC Building Block Document [5]. Additionally, for
congestion control ...
... detect missing reliable data content and does NOT identify the
application data or FEC payload that may be attached. With message
authentication, the "sequence" field may also be leveraged for
...
... header extensions are defined within this document
for NORM baseline FEC and congestion control operations.
...
... portions: 1) a fixed-format NORM_DATA header portion, 2) a FEC
Payload ID portion with a format dependent upon the FEC ...
... MAY also extend the NORM_DATA header to include a FEC Object
Transmission Information (EXT_FTI) header extension. This allows
...
... NORM receivers to automatically allocate resources and properly
perform FEC decoding without the need for pre-configuration or out-
of-band information.
...
... NORM stream control functions. When systematic
FEC codes (e.g., "fec_id" = 129) are used, the "payload_len" and
"payload ...
... contain parity information, these fields are not actual length or
offset values, but instead are values computed from FEC encoding the
"payload ...
... payload_id" field. The "fec_payload_id" field size depends upon
the FEC encoding used for the referenced NormObject. The "fec_id"
field is used to indicate the FEC ...
... FEC encoding used for the referenced NormObject. The "fec_id"
field is used to indicate the FEC coding type. For example, when
small block, systematic codes are used, a "fec_id" value of 129 is
indicated and the size of the "fec_payload ...
... | | | the sender for general purpose (with |
| | | respect to an FEC coding block) erasure |
| | | filling. |
+--------------------+-------+-----------------------------------------+
...
... stream by the application.
The "fec_id" field corresponds to the FEC Encoding Identifier
described in the FEC ...
... FEC Encoding Identifier
described in the FEC Building Block document [5]. The "fec_id" value
implies the format of the "fec_payload ...
... implies the format of the "fec_payload_id" field and, coupled with
FEC Object Transmission Information, the procedures to decode FEC
...
... FEC Object Transmission Information, the procedures to decode FEC
encoded content. Small block, systematic codes ("fec_id" = 129) are
expected to be used for most NORM ...
... content. The size and format of the "fec_payload_id" field depends
upon the FEC type indicated by the "fec_id" field. These formats are
given in the FEC Building Block document [5 ...
... upon the FEC type indicated by the "fec_id" field. These formats are
given in the FEC Building Block document [5] and any subsequent
extensions of that document. As an example, the format of the
...
... payload_id" Format
The FEC payload identifier "source_block_number", "source_block_len",
and "encoding ...
... Number", "Source Block Length, and "Encoding Symbol ID" fields of the
FEC Payload ID format given by the IETF FEC ...
... FEC Payload ID format given by the IETF FEC Building Block document
[5]. The "source_block_number" identifies the coding block's
...
... symbol (segment) referenced may be a user data or an FEC parity
segment. For systematic codes, encoding ...
... FEC Object Transmission Information (as described in the
FEC Building Block document [5]) is required to properly receive and
decode NORM ...
... receiver operation with minimal preconfiguration. For
this purpose, the NORM FEC Object Transmission Information Header
Extension (EXT_FTI) is defined. This header extension ...
... NORM_DATA and NORM_INFO messages to provide this necessary
information. The exact format of the extension depends upon the FEC
code in use, but in general it SHOULD contain any required details on
the FEC ...
... FEC
code in use, but in general it SHOULD contain any required details on
the FEC code in use (e.g., FEC Instance ID, etc.) and the byte size
of the associated NormObject (For the NORM ...
... code in use, but in general it SHOULD contain any required details on
the FEC code in use (e.g., FEC Instance ID, etc.) and the byte size
of the associated NormObject (For the NORM_OBJECT_STREAM type ...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object Transmission Information Header Extension (EXT_FTI) for
...
... is 64. The header extension length "hel" depends upon the format of
the FTI for FEC code type identified by the "fec_id" field. In this
example (for "fec_id" = 129), the "hel" field value is 4.
...
... corresponding size.
The "fec_instance_id" corresponds to the "FEC Instance ID" described
in the FEC Building Block document [5 ...
... The "fec_instance_id" corresponds to the "FEC Instance ID" described
in the FEC Building Block document [5]. In this case, the
"fec_instance_id" SHALL be a value corresponding to the particular
...
... GF(2^8), Reed-Solomon GF(2^16), etc). The standardized assignment of
FEC Instance ID values is described in [5]. The "segment_size" field
...
... The "fec_max_block_len" indicates the current maximum number of user
data segments per FEC coding block to be used by the sender during
the session ...
... encoding
symbols that can be generated for any source block" as described in
for FEC Object Transmission Information for Small Block Systematic
Codes in the FEC ...
... FEC Object Transmission Information for Small Block Systematic
Codes in the FEC Building Block document [5]. For example, Reed-
Solomon codes may be arbitrarily shortened to create ...
... payload portion of NORM_DATA messages includes source data or FEC
encoded application content.
...
... payload. For
senders employing systematic FEC encoding, these fields contain
_actual_ length and offset values (in bytes) for the payload ...
... NORM_DATA
messages containing calculated parity content, these fields will
actually contain values computed by FEC encoding of the "payload_len"
...
... NORM_DATA data segments of the
corresponding FEC coding block. Thus, the "payload_len" and
"payload ...
... "payload_offset" values of missing data content can be determined
upon decoding a FEC coding block. Note that these fields do NOT
contribute to the value of the NORM ...
... encoding data
segments of varying sizes, the FEC encoder SHALL assume ZERO value
padding for data segments ...
... this configuration. The "payload_data" content may be delivered
directly to the application for source symbols (when systematic FEC
encoding is used) or upon decoding of the FEC ...
... NORM_OBJECT_FILE, the flush process (if there are no further pending
objects) occurs at the end of these objects. Thus, FEC repair
information is always available for repairs in response to repair
requests elicited by the flush command. However, for
...
... NORM_OBJECT_STREAM, the flush may occur at any time, including in the
middle of an FEC coding block if systematic FEC codes are employed.
In this case, the sender ...
... STREAM, the flush may occur at any time, including in the
middle of an FEC coding block if systematic FEC codes are employed.
In this case, the sender will not yet be able to provide FEC ...
... FEC codes are employed.
In this case, the sender will not yet be able to provide FEC parity
content as repair for the concurrent coding block and will be limited
to explicitly repairing stream ...
... Applications that anticipate frequent flushing of stream content
SHOULD be judicious in the selection of the FEC coding block size
(i.e., do not use a very large coding block size ...
... versus the NORM_OBJECT_STREAM paradigm with an appropriate FEC coding
block size. This is analogous to application trade-offs for other
...
... sender.
The "fec_id" field indicates the FEC type used for the flushing
"object_transport_id" and implies the size and format of the
...
... For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers
MUST request "explicit-only" repair of the identified
...
... sender has not
yet completed encoding the corresponding FEC block and parity content
is not yet available. An "explicit-only" repair request consists of
NACK ...
... NORM
sender applications to "flush" an ongoing stream of transmission when
needed, even if in the middle of an FEC block. Once the sender
resumes stream ...
... NACKs from receivers SHALL request parity-based
repair as usual. Note that the use of a systematic FEC code is
assumed here. Normal receiver NACK ...
... payload_id" field, the sender's repair window
SHOULD be aligned on FEC coding block boundaries and thus the
"encoding_symbol_id" SHOULD be zero.
...
...
with less state than the transfer of FEC encoded reliable content
requires while taking advantage of NORM transmission and round-trip ...
... NORM Repair Request
consists of a list of items, ranges, and/or FEC coding block erasure
counts for needed NORM_DATA and/or NORM ...
... of the "fec_payload_id" field of the repair request item (see below)
is to be interpreted as an "erasure count" for the FEC coding block
identified by the repair request item's "source_block_number".
...
... content for which the repair request items apply (i.e., an individual
segment, entire FEC coding block, or entire transport object).
Possible flag values include:
...
... NORM Repair Request Item Format
The "fec_id" indicates the FEC type and can be used to determine the
format of the "fec_payload_id" field. The "reserved" field is kept
...
... repair is being requested and the "fec_payload_id" identifies the
specific FEC coding block and/or segment being requested. When the
NORM ...
... is ignored. When the NORM_NACK_BLOCK flag is set, only the FEC code
block identifier portion of the "fec_payload ...
... NACK Content Examples:
In these examples, a small block, systematic FEC code ("fec_id" =
129) is assumed with a user data block length of 32 segments ...
... possible content of a NORM_NACK message. Note that FEC coding block
erasure counts could also be provided in each case. However, the
erasure counts are not really necessary since the sender ...
... NACK content.
However, the erasure count option may be useful for operation with
other FEC codes or for intermediate system purposes.
Example 1: NORM ...
... NORM_DATA messages labeled with NormTransportIds and
logically identified with FEC encoding block numbers and symbol
identifiers. NORM ...
... sender sends repairs for the earliest
ordinal transmit position first and maintains this ordinal repair
transmission sequence. Previously untransmitted FEC parity
content for the applicable FEC coding block is used for repair
...
... transmission sequence. Previously untransmitted FEC parity
content for the applicable FEC coding block is used for repair
transmissions to the greatest extent possible. If the sender
...
... transmissions to the greatest extent possible. If the sender
exhausts its available FEC parity content on multiple repair
cycles for the same coding block, it resorts to an explicit repair
strategy (possibly using parity content) to complete repairs.
...
...
With inclusion of the OPTIONAL NORM FEC Object Transmission
Information Header Extension, the NORM ...
... headers can contain all information necessary to prepare receivers
for subsequent reliable reception. This includes FEC coding
parameters, the sender NormSegmentSize, and other information. If
...
... header extension is not used, it is presumed that receivers have
received the FEC Object Transmission Information via other means.
Additionally, applications may leverage the use of NORM ...
... algorithm for logically
segmenting transport data into FEC encoding blocks and symbols so
that appropriate NACKs ...
... NACKs can be constructed to request repair of
missing data. NORM FEC coding blocks are comprised of multi-byte
symbols which are transmitted in the payload of NORM ...
... NormSegmentSize sender parameter defines the maximum symbol size in
bytes. The FEC encoding type and associated parameters govern the
source block size ...
... block size (number of source symbols per coding block). NORM
senders and receivers use these FEC parameters, along with the
NormSegmentSize and transport object size to compute the source block
structure ...
... source block
structure for transport objects. These parameters are provided in
the FEC Transmission Information for each object. The algorithm
given below is used to compute a source block structure ...
... source blocks are as close to being equal length as possible. This
helps avoid the performance disadvantages of "short" FEC blocks.
Note this algorithm applies only to the statically-sized
...
... STREAM
objects, the object is segmented according to the maximum source
block length given in the FEC Transmission Information, unless the
FEC Payload ...
... block length given in the FEC Transmission Information, unless the
FEC Payload ID indicates an alternative size for a given block.
...
... transport object of a given length (L_obj) in bytes, a first number
of FEC source blocks (N_large) is delineated of a larger block size
(B_large), and a second number of source blocks (N_small) is
...
... (B_large), and a second number of source blocks (N_small) is
delineated of a smaller block size (B_small). Given the maximum FEC
source block size (B_max) and the sender ...
... receivers are allowed to request repair only for coding blocks with a
NormTransportId and FEC coding block number greater than or equal to
the first non-repair NORM_DATA or NORM ...
... receivers to start reliable reception at the current FEC coding block
for which non-repair content is received.
...
... NORM
transmissions, it initiates its NACKing procedure. The NACKing
procedure SHALL be initiated _only_ at FEC coding block boundaries,
NormObject boundaries, and upon receipt of a NORM_CMD ...
... receiver's lowest ordinal repair needs.
For each partially-received FEC coding block requiring repair, the
receiver SHALL, on its _first_ repair attempt for the block, request
...
... receiver SHALL, on its _first_ repair attempt for the block, request
the parity portion of the FEC coding block beginning with the lowest
ordinal _parity_ "encoding_symbol_id" (i.e., "encoding ...
... encoding_symbol_id" (i.e., "encoding_symbol_id" =
"source_block_len") and request the number of FEC symbols
corresponding to its data segment erasure count for the block. On
...
... also be used to satisfy the local receiver's erasure-filling needs.
In the case where the erasure count for a partially-received FEC
coding block exceeds the maximum number of parity symbols available
from the sender ...
... of this strategy is for the overall receiver set to request a lowest
common denominator set of repair symbols for a given FEC coding
block. This allows the sender to construct the most efficient repair
...
... sender.
For FEC coding blocks or NormObjects missed in their entirety, the
NORM receiver constructs repair requests with NORM ...
...
The NORM sender should leverage transmission of FEC parity content
for repair to the greatest extent possible. Recall that the
receivers ...
... receivers' repair needs, the sender can make use of the
general erasure-filling capability of FEC-generated parity segments.
The sender ...
... The sender can determine the maximum erasure filling needs for
individual FEC coding blocks from the NORM_NACK messages received
...
... sender resort to explicit transmission of the receiver
set's repair needs. In general, if a sufficiently powerful FEC code
is used, the need for explicit repair will be an exception, and the
fulfillment of reliable multicast ...
... multicast routing sub-tree's erasure filling needs for a given FEC
coding block. When the sender has resorted to explicit repair, then
...
... The same security considerations that apply to the NORM, and FEC
Building Blocks also apply to the NORM protocol. In addition to
...
... 22]. It is important to note that
while NORM does leverage FEC-based repair for scalability, this does
not alone guarantee integrity ...
... NORM
may introduce additional IANA considerations. In particular, the FEC
Building Block used by NORM does require IANA registration ...
... Building Block used by NORM does require IANA registration of the FEC
codecs used. The registration ...
... independent of network structure and in environments with high packet
loss, delay, and misordering. Hybrid proactive/reactive FEC-based
repairing improve protocol performance in some multicast scenarios ...
... Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452exp, December 2002. ...
... 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. ...