One document matched: draft-ietf-rmt-fcast-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: draft-ietf-rmt-fcast-06.xml 79 2012-10-10 07:31:11Z roca $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- <rfc category="std" ipr="trust200902"> -->
<rfc category="exp" docName="draft-ietf-rmt-fcast-08" ipr="trust200902">
<!--
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-->
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="FCAST Object Delivery">FCAST: Object Delivery for the ALC
and NORM Protocols</title>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/people/roca/</uri>
</address>
</author>
<author fullname="Brian Adamson" initials="B." surname="Adamson">
<organization>Naval Research Laboratory</organization>
<address>
<postal>
<street/>
<city>Washington, DC</city>
<code>20375</code>
<country>USA</country>
</postal>
<email>adamson@itd.nrl.navy.mil</email>
<uri>http://cs.itd.nrl.navy.mil</uri>
</address>
</author>
<date/>
<area>Transport</area>
<workgroup>RMT</workgroup>
<keyword>ALC, NORM</keyword>
<abstract>
<t>This document introduces the FCAST reliable object (e.g., file)
delivery application. It is designed to operate either on top of the
underlying Asynchronous Layer Coding (ALC)/Layered Coding Transport
(LCT) or the NACK-Oriented Reliable Multicast (NORM) reliable multicast
transport protocols.</t>
</abstract>
</front>
<middle>
<!--
<t>
<list style="empty">
<t> *** Editor's note:
XXX </t>
</list>
</t>
-->
<section anchor="intro" title="Introduction">
<!-- ==================================== -->
<t>This document introduces the FCAST reliable and scalable object
(e.g., file) delivery application. Two variants of FCAST exist: <list
style="symbols">
<t>FCAST/ALC that relies on the Asynchronous Layer Coding (ALC)
<xref target="RFC5775"/> and the Layered Coding Transport (LCT)
<xref target="RFC5651"/> reliable multicast transport protocol,
and</t>
<t>FCAST/NORM that relies on the NACK-Oriented Reliable Multicast
(NORM) <xref target="RFC5740"/> reliable multicast transport
protocol.</t>
</list> Hereafter, the term FCAST denotes either FCAST/ALC or
FCAST/NORM. FCAST is not a new protocol specification per se. Instead it
is a set of data format specifications and instructions on how to use
ALC and NORM to implement a file-casting service.</t>
<t>FCAST is expected to work in many different environments and is
designed to be flexible. The service provided by FCAST can differ
according to the exact conditions FCAST is used. For instance the
delivery service provided by FCAST might be fully reliable, or only
partially reliable depending upon the exact way FCAST is used. Indeed,
if FCAST/ALC is used for a finite duration over purely unidirectional
networks (where no feedback is possible), a fully reliable service may
not be possible in practice. This is different with NORM that can
collect reception and loss feedbacks from receivers. This is discussed
in <xref target="op_considerations"/>.</t>
<t>The delivery service provided by FCAST might also differ in terms of
scalability with respect to the number of receivers. The FCAST/ALC
service is naturally massively scalable since neither FCAST nor ALC
limit the number of receivers (there is no feedback message at all). On
the opposite FCAST/NORM scalability is typically limited by NORM itself
as NORM relies on feedback messages from the receivers. However NORM is
designed in such a way to offer a reasonably scalable service (e.g.
through the use of proactive Forward Erasure Corrections (FEC) codes),
and so does the service provided by FCAST/NORM. This aspect is also
discussed in <xref target="op_considerations"/>.</t>
<t>A design goal behind FCAST is to define a streamlined solution, in
order to enable lightweight implementations of the protocol stack, and
limit the operational processing and storage requirements. A consequence
of this choice is that FCAST cannot be considered as a versatile
application, capable of addressing all the possible use-cases. On the
contrary, FCAST has some intrinsic limitations. From this point of view
it differs from FLUTE <xref target="RFC6726"/> which favors flexibility
at the expense of some additional complexity.</t>
<t>A good example of the design choices meant to favor simplicity is the
way FCAST manages the object meta-data: by default, the meta-data and
the object content are sent together, in a compound object. This
solution has many advantages in terms of simplicity as will be described
later on. However this solution has an intrinsic limitation since it
does not enable a receiver to decide in advance, before beginning the
reception of the compound object, whether the object is of interest or
not, based on the information that may be provided in the meta-data.
Therefore this document discusses additional techniques that may be used
to mitigate this limitation. When use-cases require that each receiver
download the whole set of objects sent in the session (e.g., with
mirroring tools), this limitation is not considered a problem.</t>
<t>Finally, <xref target="compliance_requirements"/> provides guidance
for compliant implementation of the specification and identifies those
features that are optional.</t>
<section title="Requirements Notation">
<!-- ==================================== -->
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
<section title="Definitions, Notations and Abbreviations">
<!-- ================================================= -->
<t>This document uses the following definitions: <list hangIndent="7"
style="hanging">
<t hangText="FCAST/ALC:">denotes the FCAST application running on
top of the ALC/LCT reliable transport protocol;</t>
<t hangText="FCAST/NORM:">denotes the FCAST application running on
top of the NORM reliable transport protocol;</t>
<t hangText="FCAST:">denotes either FCAST/ALC or FCAST/NORM;</t>
<t hangText="Compound Object:">denotes an ALC or NORM transport
object composed of the FCAST Header and the Object Data (some
Compound Objects may not include any Object Data);</t>
<t hangText="FCAST Header:">denotes the header prepended to the
Object Data, that together form the Compound Object. This FCAST
Header usually contains the Object meta-data, among other
things;</t>
<t hangText="Object Data:">denotes the original object (e.g., a
file) that forms the payload of the Compound Object;</t>
<t hangText="Carousel:">denotes the building block that enables an
FCAST sender to transmit Compound Objects in a cyclic manner;</t>
<t hangText="Carousel Instance:">denotes a fixed set of registered
Compound Objects that are sent by the carousel during a certain
number of cycles. Whenever Compound Objects need to be added or
removed, a new Carousel Instance is defined;</t>
<t hangText="Carousel Instance Descriptor (CID):">denotes a
special object that lists the Compound Objects that comprise a
given Carousel Instance;</t>
<t hangText="Carousel Instance IDentifier (CIID):">numeric value
that identifies a Carousel Instance.</t>
<t hangText="Carousel Cycle:">denotes a transmission round within
which all the Compound Objects registered in the Carousel Instance
are transmitted a certain number of times. By default, Compound
Objects are transmitted once per cycle, but higher values are
possible, that might differ on a per-object basis;</t>
<t hangText="Transport Object Identifier (TOI):">denotes the
numeric identifier associated to a specific object by the
underlying transport protocol. In the case of ALC, this
corresponds to the TOI described in <xref target="RFC5651"/>. In
the case of NORM, this corresponds to the NormTransportId
described in <xref target="RFC5740"/>.</t>
<t hangText="FEC Object Transmission Information (FEC OTI):">FEC
information associated with an object and that is essential for
the FEC decoder to decode a specific object.</t>
</list></t>
</section>
</section>
<section anchor="fcast_specifications" title="FCAST Data Formats">
<!-- ================================================= -->
<t>This section details the various data formats used by FCAST.</t>
<section anchor="compound_obj_format" title="Compound Object Format">
<!-- ================================================= -->
<t>In an FCAST session, Compound Objects are constructed by prepending
the FCAST Header (which usually contains the meta-data of the object)
to the Object Data (see <xref target="meta-data_tx"/>). <xref
target="header_with_md_format"/> illustrates the associated format.
All multi-byte fields MUST be in network (Big Endian) byte order.</t>
<figure anchor="header_with_md_format" title="Compound Object Format.">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Ver |Resvd|G|C| MDFmt | MDEnc | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| FCAST Header Length | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d
| Object Meta-Data (variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| |
. Object Data (optional, variable length) .
. .
. .]]></artwork>
</figure>
<t>The FCAST Header fields are:</t>
<texttable>
<ttcol align="right" width="15%">Field</ttcol>
<ttcol align="left">Description</ttcol>
<c>Version</c>
<c>3-bit field that MUST be set to 0 in this specification and
indicates the FCAST protocol version number.</c>
<c>Reserved</c>
<c>3-bit field that MUST be set to 0 in this specification and is
reserved for future use. Receivers MUST ignore this field.</c>
<c>G</c>
<c>1-bit field that, when set to 1, indicates that the checksum
encompasses the whole Compound Object (Global checksum). When set to
0, this field indicates that the checksum encompasses only the FCAST
header.</c>
<c>C</c>
<c>1-bit field that, when set to 1, indicates the object is a
Carousel Instance Descriptor (CID). When set to 0, this field
indicates that the transported object is a standard object.</c>
<c>Meta-Data Format (MDFmt)</c>
<c>4-bit field that defines the format of the Object Meta-Data field
(see <xref target="iana"/>). An HTTP/1.1 meta information format
<xref target="RFC2616"/> MUST be supported and is associated to
value 0. Other formats (e.g., XML) may be defined in the future.</c>
<c>Meta-Data Encoding (MDEnc)</c>
<c>4-bit field that defines the optional encoding of the Object
Meta-Data field (see <xref target="iana"/>). Two values are
currently defined. A value of 0 indicates that the field contains
UTF-8 <xref target="RFC2279"/> encoded text. A value of 1 indicates
that the field contains GZIP<xref target="RFC1952"/> compressed
UTF-8 encoded text.</c>
<c>Checksum</c>
<c>16-bit field that contains the checksum computed over either the
whole Compound Object (when G is set to 1), or over the FCAST Header
(when G is set to 0), using the Internet checksum algorithm
specified in <xref target="RFC1071"/>. More precisely, the checksum
field is the 16-bit one's complement of the one's complement sum of
all 16-bit words to be considered. If a segment contains an odd
number of octets to be checksummed, the last octet is padded on the
right with zeros to form a 16-bit word for checksum purposes (this
pad is not transmitted). While computing the checksum, the checksum
field itself MUST be set to zero.</c>
<c>FCAST Header Length</c>
<c>32-bit field indicating total length (in bytes) of all fields of
the FCAST Header, except the optional padding. A header length field
set to value 8 means that there is no meta-data included. When this
size is not multiple to 32-bits words and when the FCAST Header is
followed by a non null Object Data, padding MUST be added. It should
be noted that the meta-data field maximum size is equal to (2^32 -
8) bytes.</c>
<c>Object Meta-Data</c>
<c>Variable length field that contains the meta-data associated to
the object. The format and encoding of this field are defined
respectively by the MDFmt and MDEnc fields. With the default format
and encoding, the Object Meta-Data field, if not empty, MUST contain
a UTF-8 encoded text that follows the "TYPE" ":" "VALUE" "<CR-LF>"
format used in HTTP/1.1 for meta information <xref
target="RFC2616"/>. The various meta-data items can appear in any
order. The receiver MUST NOT assume this string is NULL-terminated.
When no meta-data is communicated, this field MUST be empty and the
FCAST Header Length MUST be equal to 8.</c>
<c>Padding</c>
<c>Optional, variable length field of zero-value bytes to align the
start of the Object Data to a 32-bit boundary. Padding is only used
when the FCAST Header Length value, in bytes, is not multiple of 4
and when the FCAST Header is followed by non null Object Data.</c>
</texttable>
<t>The FCAST Header is then followed by the Object Data, i.e., either
an original object (possibly encoded by FCAST) or a CID. Note that the
length of the Object Data content is the ALC or NORM transported
object length (e.g., as specified by the FEC OTI) minus the FCAST
Header Length and optional padding if any.</t>
</section>
<section anchor="carousel_instance_descr"
title="Carousel Instance Descriptor Format">
<!-- ==================================== -->
<t>In an FCAST session, a Carousel Instance Descriptor (CID) MAY be
sent in order to carry the list of Compound Objects that are part of a
given Carousel Instance (see <xref target="cio"/>). The format of the
CID, that is sent as a special Compound Object, is given in <xref
target="cid_format"/>. Being a special case of Compound Object, this
format is in line with the format described in <xref
target="compound_obj_format"/>.</t>
<figure anchor="cid_format"
title="Carousel Instance Descriptor Format.">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Ver |Resvd|G|C| MDFmt | MDEnc | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| FCAST Header Length | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d
| Object Meta-Data (variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
. . ^
. Object List (variable length) . |
. . o
. +-+-+-+-+-+-+-+-+ b
. | j
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v ]]></artwork>
</figure>
<t>Because the CID is transmitted as a special Compound Object, the
following CID-specific meta-data entries are defined and MUST be
supported: <list style="symbols">
<t>Fcast-CID-Complete: this is an optional entry that, when set to
"Fcast-CID-Complete: 1", indicates no new object (if we ignore CID
Compound Objects) in addition to the ones whose TOI are listed in
this CID or the ones that have been listed in the previous CID(s),
will be sent in the future. Conversely, if it is set to
"Fcast-CID-Complete: 0", or if this entry is absent, it indicates
that the session is not complete.. An FCAST sender MUST NOT use
any other value for this entry.</t>
<t>Fcast-CID-ID: this entry contains the Carousel Instance
IDentifier, or CIID. It starts from 0 upon FCAST session creation
and is incremented by 1 for each new carousel instance. This entry
is optional if the FCAST session consists of a single, complete,
carousel instance (no need for the FCAST sender to specify it and
for the FCAST receiver to process it). In all other cases, this
entry MUST be defined. In particular, the CIID is used by the TOI
equivalence mechanism thanks to which any object is uniquely
identified, even if the TOI is updated (e.g., after re-enqueuing
the object with NORM). The Fcast-CID-ID value can also be useful
to detect possible gaps in the Carousel Instances, for instance
caused by long disconnection periods. Finally, it can also be
useful to avoid problems when TOI wrapping to 0 takes place to
differentiate the various incarnations of the TOIs if need be.</t>
</list></t>
<t>The following standard meta-data entry types are also used (<xref
target="meta-data_content"/>): <list style="symbols">
<t>Content-Length: it specifies the size in bytes of the object
list, before any content encoding (if any).</t>
<t>Content-Encoding: it specifies the optional encoding of the
object list, performed by FCAST.</t>
</list></t>
<t>An empty Object List is valid and indicates that the current
carousel instance does not include any objects (<xref target="cio"/>).
This can be specified by using the following meta-data entry: <figure>
<artwork align="left"><![CDATA[ Content-Length: 0 ]]></artwork>
</figure> or simply by leaving the Object List empty. In both cases,
padding MUST NOT be used and consequently the ALC or NORM transported
object length (e.g., as specified by the FEC OTI) minus the FCAST
Header Length equals zero.</t>
<t>The Object List, when non empty and with MDEnc=0, is a UTF-8 encoded text
that is not necessarily NULL-terminated. It can contain two things:
<list style="symbols">
<t>a list of TOI values, and</t>
<t>a list of TOI equivalences;</t>
</list>A list of TOIs included in the current carousel instance is
specified as an ASCII string containing comma-delimited individual TOI
values and/or TOI intervals. Individual TOIs consist of a single
integer value while TOI intervals are a hyphen-delimited pair of TOI
values to indicate a inclusive range of TOI values (e.g., "1,2,4-6"
would indicate the list of TOI values of 1,2,4,5, and 6). For a TOI
Interval indicated by ""TOI_a-TOI_b", the 'TOI_a' value MUST be
strictly inferior to the 'TOI_b' value. If a TOI wrapping to 0 occurs
in an interval, then two TOI intervals MUST be specified,
TOI_a-MAX_TOI and 0-TOI_b.</t>
<t>This string can also contain the TOI equivalences, if any. The
format is a comma-separated list of equivalence TOI value pairs with a
delimiting equals sign '=' to indicate the equivalence assignment
(e.g., " newTOI "=" 1stTOI "/" 1stCIID "). Each equivalence indicates
that the new TOI, for the current Carousel Instance, is equivalent to
(i.e., refers to the same object as) the provided identifier, 1stTOI,
for the Carousel Instance of ID 1stCIID. In the case of the NORM
protocol where NormTransportId values need to monotonically increase
for NACK-based protocol operation, this allows an object from a prior
Carousel Instance to be relisted in a subsequent Carousel Instance
with the receiver set informed of the equivalence so that unnecessary
retransmission requests can be avoided.</t>
<t>The ABNF <xref target="RFC5234"/> specification is the
following:</t>
<figure>
<artwork align="left"><![CDATA[cid-list = *(list-elem *( "," list-elem))
list-elem = toi-elem / toieq-elem
toi-elem = toi-value / toi-interval
toi-value = 1*DIGIT
toi-interval = toi-value "-" toi-value
; additionally, the first toi-value MUST be
; strictly inferior to the second toi-value
toieq-elem = "(" toi-value "=" toi-value "/" ciid-value ")"
ciid-value = 1*DIGIT
DIGIT = %x30-39
; a digit between 0 and 9, inclusive]]></artwork>
</figure>
<t>For readability purposes and to simplify processing, the TOI values
in the list MUST be given in increasing order handling wrap of the TOI
space appropriately. TOI equivalence elements MUST be grouped together
at the end of the list in increasing newTOI order. Specifying a TOI
equivalence for a given newTOI relieves the sender from specifying
newTOI explicitly in the TOI list. A receiver MUST be able to handle
situations where the same TOI appears both in the TOI value and TOI
equivalence lists. Finally, a given TOI value or TOI equivalence item
MUST NOT be included multiple times in either list.</t>
<t>For instance, the following object list specifies that the current
Carousel Instance is composed of 8 objects, and that TOIs 100 to 104
are equivalent to the TOIs 10 to 14 of Carousel Instance ID 2 and
refer to the same objects:</t>
<figure>
<artwork align="left"><![CDATA[
97,98,99,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2)
]]></artwork>
</figure>
<t>or equivalently:</t>
<figure>
<artwork align="left"><![CDATA[
97-104,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2)
]]></artwork>
</figure>
</section>
</section>
<!-- ======================================================================= -->
<section anchor="fcast_principles" title="FCAST Principles">
<!-- ==================================== -->
<t>This section details the principles of FCAST.</t>
<section anchor="fcast_service" title="FCAST Content Delivery Service">
<!-- ==================================== -->
<t>The basic goal of FCAST is to transmit objects to a group of
receivers in a reliable way, where the receiver set may be restricted
to a single receiver or may include possibly a very large number of
receivers. FCAST supports two forms of operation: <list
style="numbers">
<t>FCAST/ALC, where the FCAST application works on top of the
ALC/LCT reliable multicast transport protocol, without any
feedback from the receivers, and</t>
<t>FCAST/NORM, where the FCAST application works on top of the
NORM reliable multicast transport protocol, that requires
positive/negative acknowledgements from the receivers.</t>
</list></t>
<t>This specification is designed such that both forms of operation
share as much commonality as possible. <xref
target="op_considerations"/> discusses some operational aspects and
the content delivery service that is provided by FCAST for a given
use-case.</t>
</section>
<section anchor="meta-data_tx"
title="Compound Object and Meta-Data Transmission">
<!-- ==================================== -->
<t>FCAST carries meta-data elements by prepending them to the object
they refer to. As a result, a Compound Object is created that is
composed of an FCAST Header followed by the Object Data (<xref
target="fig_compound_obj"/>). This header is itself composed of the
object meta-data (if any) as well as several fields (e.g., to indicate
format, encoding or boundaries <xref
target="compound_obj_format"/>).</t>
<figure anchor="fig_compound_obj" title="Compound Object composition.">
<artwork align="center"><![CDATA[
<------------------------ Compound Object ----------------------->
+-------------------------+--------------------------------------+
| FCAST Header | Object Data |
| (can include meta-data) | (can be encoded by FCAST) |
+-------------------------+--------------------------------------+
]]></artwork>
</figure>
<t>Attaching the meta-data to the object is an efficient solution,
since it guaranties that meta-data are received along with the
associated object, and it allows the transport of the meta-data to
benefit from any transport-layer erasure protection of the Compound
Object (e.g., using FEC encoding and/or NACK-based repair). However a
limit of this scheme is that a client does not know the meta-data of
an object before beginning its reception, and in case of erasures
affecting the meta-data, not until the object decoding is completed.
The details of course depend upon the transport protocol and the FEC
code used.</t>
<t><xref target="annex_add_meta_data_tx_mechanisms"/> describes
extensions that provide additional means to carry meta-data, e.g., to
communicate meta-data ahead of time.</t>
</section>
<section anchor="meta-data_content" title="Meta-Data Content">
<!-- ==================================== -->
<t>The following meta-data types are defined in <xref
target="RFC2616"/>: <list style="symbols">
<t>Content-Location: the URI of the object, which gives the name
and location of the object; <!-- This URI MUST be considered as a string that identifies an object
(i.e., two different strings are two different identifiers).
Any use of the "Content-Location" field for anything else other
than to identify the object is out of scope of this specification;
--></t>
<t>Content-Type: a string that contains the MIME type of the
object;</t>
<t>Content-Length: an unsigned 64-bit integer that contains the
size in bytes of the initial object, before any content encoding
(if any) and without considering the FCAST Header. Note that the
use of certain FEC schemes MAY further limit the maximum value of
the object;</t>
<t>Content-Encoding: a string that contains the optional encoding
of the object performed by FCAST. For instance: <figure>
<artwork align="left"><![CDATA[ Content-Encoding: gzip ]]></artwork>
</figure> indicates that the object has been encoded
with GZIP <xref target="RFC1952"/>. If there is no
Content-Encoding entry, the receiver MUST assume that FCAST did
not modify the original encoding of the object (default).</t>
</list></t>
<t>The following additional meta-data type is defined to check object
integrity: <list style="symbols">
<t>Fcast-Obj-Digest-SHA256: a string that contains the "base64"
<xref target="RFC4648"/> encoding of the SHA-256 message digest of
the object <xref target="RFC3174"/><xref target="RFC6234"/>,
before any content encoding is applied (if any) and without
considering the FCAST Header. <!-- This is the default algorithm for message digest calculation.-->
This digest is meant to protect from transmission and processing
errors, not from deliberate attacks by an intelligent attacker
(see <xref target="security"/>). This digest only protects the
object, not the header, and therefore not the meta-data. A
separate checksum is provided to that purpose (<xref
target="compound_obj_format"/>);</t>
<t>Fcast-Obj-Digest-SHA1: it is similar to Fcast-Obj-Digest-SHA256
with the only exception that SHA-256 is replaced by SHA-1. An
FCAST sender MAY include both an Fcast-Obj-Digest-SHA1 and an
Fcast-Obj-Digest-SHA256 message digest in the meta-data, in order
to let a receiver select the most appropriate algorithm (e.g.,
depending on local processing power);</t>
</list></t>
<t>The following additional meta-data types are used for dealing with
very large objects (e.g., that largely exceed the working memory of a
receiver). When this happens, the meta-data associated to each
sub-object MUST include the following entries: <list style="symbols">
<t>Fcast-Obj-Slice-Nb: an unsigned 32-bit integer that contains
the total number of slices. A value greater than 1 indicates that
this object is the result of a split of the original object;</t>
<t>Fcast-Obj-Slice-Idx: an unsigned 32-bit integer that contains
the slice index (in the {0 .. SliceNb - 1} interval);</t>
<t>Fcast-Obj-Slice-Offset: an unsigned 64-bit integer that
contains the offset at which this slice starts within the original
object;</t>
</list> <!-- A compliant FCAST implementation MUST support all the above meta-data types
(<ref target="compliance_requirements"/>).--> Future standards actions can
extend the set of meta-data types supported by FCAST.</t>
</section>
<section anchor="carousel" title="Carousel Transmission">
<!-- ==================================== -->
<t>A set of FCAST Compound Objects scheduled for transmission are
considered a logical "Carousel". A given "Carousel Instance" is
comprised of a fixed set of Compound Objects. Whenever the FCAST
application needs to add new Compound Objects to or remove old
Compound Objects from the transmission set, a new Carousel Instance is
defined since the set of Compound Objects changes. Because of the
native object multiplexing capability of both ALC and NORM, sender and
receiver(s) are both capable to multiplex and demultiplex FCAST
Compound Objects.</t>
<t>For a given Carousel Instance, one or more transmission cycles are
possible. During each cycle, all of the Compound Objects comprising
the Carousel are sent. By default, each object is transmitted once per
cycle. However, in order to allow different levels of priority, some
objects MAY be transmitted more often that others during a cycle,
and/or benefit from higher FEC protection than others. For example,
this can be the case for the CID objects (<xref target="cio"/>) where
extra protection can benefit overall carousel integrity. For some
FCAST usage (e.g., a unidirectional "push" mode), a Carousel Instance
may be sent in a single transmission cycle. In other cases it may be
conveyed in a large number of transmission cycles (e.g., in
"on-demand" mode, where objects are made available for download during
a long period of time).</t>
</section>
<section anchor="cio"
title="Carousel Instance Descriptor Special Object">
<!-- ==================================== -->
<t>The FCAST sender can transmit an OPTIONAL Carousel Instance
Descriptor (CID). The CID carries the list of the Compound Objects
that are part of a given Carousel Instance, by specifying their
respective Transmission Object Identifiers (TOI). However the CID does
not describe the objects themselves (i.e., there is no meta-data).
Additionally, the CID MAY include an "Fcast-CID-Complete: 1" meta-data
entry to indicate that no further modification to the enclosed list
will be done in the future. Finally, the CID MAY include a Carousel
Instance ID (CIID) that identifies the Carousel Instance it pertains
to. These aspects are discussed in <xref
target="carousel_instance_descr"/>.</t>
<t>There is no reserved TOI value for the CID Compound Object itself,
since this special object is regarded by ALC/LCT or NORM as a standard
object. On the contrary, the nature of this object (CID) is indicated
by means of a specific FCAST Header field (the "C" flag from
<xref target="header_with_md_format"/>) so that it can be recognized
and processed by the FCAST application as needed. A direct consequence
is the following: since a receiver does not know in advance which TOI
will be used for the following CID (in case of a dynamic session), it
MUST NOT filter out packets that are not in the current CID's TOI
list. Said differently, the goal of CID is not to setup ALC or NORM
packet filters (this mechanism would not be secure in any case).</t>
<t>The use of a CID remains OPTIONAL. If it is not used, then the
clients progressively learn what files are part of the carousel
instance by receiving ALC or NORM packets with new TOIs. However using
a CID has several benefits: <list style="symbols">
<t>When an "Fcast-CID-Complete" meta-data entry set to
"Fcast-CID-Complete: 1" is included, the receivers know when they
can leave the session, i.e., when they have received all the
objects that are part of the last carousel instance of this
delivery session;</t>
<t>In case of a session with a dynamic set of objects, the sender
can reliably inform the receivers that some objects have been
removed from the carousel with the CID. This solution is more
robust than the "Close Object flag (B)" of ALC/LCT since a client
with an intermittent connectivity might loose all the packets
containing this B flag. And while NORM provides a robust object
cancellation mechanism in the form of its NORM_CMD(SQUELCH)
message in response to receiver NACK repair requests, the use of
the CID provides an additional means for receivers to learn of
objects for which it is futile to request repair;</t>
<t>The TOI equivalence (<xref target="object_id"/>) is signaled
within the CID. <!-- This is often preferable to the alternative
solution where the equivalence is identified by examining the
object meta-data, especially in case of erasures. --></t>
</list></t>
<t>During idle periods, when the carousel instance does not contain
any object, a CID with an empty TOI list MAY be transmitted. In that
case, a new carousel instance ID MUST be used to differentiate this
(empty) carousel instance from the other ones. This mechanism can be
useful to inform the receivers that: <list style="symbols">
<t>all the previously sent objects have been removed from the
carousel. It therefore improves the FCAST robustness even during
"idle" period;</t>
<t>the session is still active even if there is currently no
content being sent. Said differently, it can be used as a
heartbeat mechanism. If no "Fcast-CID-Complete" meta-data entry is
included (or if set to "Fcast-CID-Complete: 0"), it informs
the receivers the carousel instance may be modified and that new
objects could be sent in the future;</t>
</list></t>
</section>
<section anchor="object_id" title="Compound Object Identification">
<!-- ==================================== -->
<t>The FCAST Compound Objects are directly associated with the
object-based transport service that the ALC and NORM protocols
provide. In each protocol, the packets containing transport object
content are labeled with a numeric transport object identifier: the
TOI with ALC, and the NormTransportId with NORM. For the purposes of
this document, this identifier in either case (ALC or NORM) is
referred to as the TOI.</t>
<t>There are several differences between ALC and NORM: <list
style="symbols">
<t>the ALC use of TOI is rather flexible, since several TOI field
sizes are possible (from 16 to 112 bits), since this size can be
changed at any time, on a per-packet basis, and since the TOI
management is totally free as long as each object is associated to
a unique TOI (if no wraparound happened);</t>
<t>the NORM use of TOI is more directive, since the TOI field is
16 bit long and since TOIs MUST be managed sequentially;</t>
</list></t>
<t>In both NORM and ALC, it is possible that the transport
identification space eventually wraps for long-lived sessions
(especially with NORM where this phenomenon is expected to happen more
frequently). This can possibly introduce some ambiguity in FCAST
object identification if a sender retains some older objects in newer
Carousel Instances with updated object sets. <!-- Thus, when an updated
object set, for a new Carousel Instance, would transport identifiers
that exceed one-half of the TOI sequence space (or otherwise exceed
the sender repair window capability in the case of NORM), it MAY be
necessary to re-enqueue old objects within the Carousel with new TOI
to stay within transport identifier limits. --> To avoid ambiguity the
active TOIs (i.e., the TOIs corresponding to objects being
transmitted) can only occupy half of the TOI sequence space. If an old
object, whose TOI has fallen outside the current window, needs to be
transmitted again, a new TOI must be used for it. In case of NORM,
this constraint limits to 32768 the maximum number of objects that can
be part of any carousel instance.</t>
<t>In order to allow receivers to properly combine the transport
packets with a newly-assigned TOI to those associated to the
previously-assigned TOI, a mechanism is required to equate the objects
with the new and the old TOIs. This mechanism consists in signaling,
within the CID, that the newly assigned TOI, for the current Carousel
Instance, is equivalent to the TOI used within a previous Carousel
Instance. By convention, the reference tuple for any object is the
{TOI; CIID} tuple used for its first transmission within a Carousel
Instance. This tuple MUST be used whenever a TOI equivalence is
provided. <xref target="carousel_instance_descr"/> details how to
describe these TOI equivalences.</t>
<!-- removed to avoid making Content-Location a MUST
<t>An alternative solution, when meta-data can be processed rapidly
(e.g., by using NORM-INFO messages), consists for the receiver in
identifying that both objects are the same, after examining the
Content-Location meta-data. The receiver can then take appropriate
measures. Of course, this possibility requires that the sender
fills-in this Content-Location field for any object it sends.</t>
-->
</section>
<!--
<section anchor="alc_specifics"
title="FCAST/ALC Additional Specificities">
<t>There are no additional detail or option for FCAST/ALC
operation.</t>
</section>
<section anchor="norm_specifics"
title="FCAST/NORM Additional Specificities">
<t>The NORM Protocol provides a few additional capabilities that can
be used to specifically support FCAST operation:</t>
<t><list style="numbers">
<t>The NORM_INFO message can convey "out-of-band" content with
respect to a given transport object. With FCAST, it MAY be used to
provide to the receivers a new, associated, Compound Object which
contains the main Compound Object meta-data, or a subset of it.
In that case the NORM_INFO Compound Object MUST NOT contain any
Object Data field (i.e., it is only
composed of the header), it MUST feature a non global checksum, and
it MUST NOT include any padding field. The main Compound
Object MUST in any case contain the whole meta-data (e.g., because
a receiver MAY not support the NORM_INFO facility). Additionally, the
meta-data entries contained in the NORM_INFO MUST be identical to
the same entries in the main Compound Object. Finally, note that
the availability of NORM_INFO for a given object is signaled
through the use of a dedicated flag in the NORM_DATA message
header. Along with NORM's NACK-based repair request signaling, it
allows a receiver to quickly (and independently) request an
object's NORM_INFO content. However, a limitation here is that the
NORM_INFO Compound Object header MUST fit within the byte size
limit defined by the NORM sender's configured "segment size"
(typically a little less than the network MTU);</t>
<t>The NORM_CMD(SQUELCH) messages are used by the NORM protocol
sender to inform receivers of objects that have been canceled when
receivers make repair requests for such invalid objects. Along
with the CID mechanism, a receiver has two efficient and reliable
ways to discover old objects that have been removed from the
carousel instance;</t>
<t>NORM also supports an optional positive acknowledgment
mechanism that can be used for small-scale multicast receiver
group sizes. Also, it may be possible in some cases for the sender
to infer, after some period without receiving NACKs at the end of
its transmission that the receiver set has fully received the
transmitted content. In particular, if the sender completes its
end-of-transmission series of NORM_CMD(FLUSH) messages without
receiving repair requests from the group, it may have some
assurance that the receiver set has received the content prior to
that point. These mechanisms are likely to help FCAST in achieving
fully reliable transmissions;</t>
</list></t>
<t>It should be noted that the NORM_INFO message header may carry
the EXT_FTI extension. The reliable delivery of the NORM_INFO content
allows the individual objects' FEC Transmission Information to be
provided to the receivers without burdening every packet (i.e.
NORM_DATA messages) with this additional, but important, content.
Examples are provided in <xref target="fcast_exple"></xref>.</t>
</section>
-->
<section anchor="sender_behavior" title="FCAST Sender Behavior">
<!-- ==================================== -->
<t>This section provides an informative description of expected FCAST
sender behavior. The following operations can take place at a sender:
<list style="numbers">
<t>The user (or another application) selects a set of objects
(e.g., files) to deliver and submits them, along with their
meta-data, to the FCAST application;</t>
<t>For each object, FCAST creates the Compound Object and
registers this latter in the carousel instance;</t>
<t>The user then informs FCAST that all the objects of the set
have been submitted. If the user knows that no new object will be
submitted in the future (i.e., if the session's content is now
complete), the user informs FCAST. Finally, the user specifies how
many transmission cycles are desired (this number may be
infinite);</t>
<t>At this point, the FCAST application knows the full list of
Compound Objects that are part of the Carousel Instance and can
create a CID if desired, possibly with the complete flag set;</t>
<t>The FCAST application can now define a transmission schedule of
these Compound Objects, including the optional CID. This schedule
defines in which order the packets of the various Compound Objects
should be sent. This document does not specify any scheme. This is
left to the developer within the provisions of the underlying ALC
or NORM protocol used and the knowledge of the target
use-case.</t>
<t>The FCAST application then starts the carousel transmission,
for the number of cycles specified. Transmissions take place
until: <list style="symbols">
<t>the desired number of transmission cycles has been reached,
or</t>
<t>the user wants to prematurely stop the transmissions,
or</t>
<t>the user wants to add one or several new objects to the
carousel, or on the contrary wants to remove old objects from
the carousel. In that case a new carousel instance must be
created.</t>
</list></t>
<t>If the session is not finished, then continue at Step 1
above;</t>
</list></t>
</section>
<section anchor="receiver_behavior" title="FCAST Receiver Behavior">
<!-- ==================================== -->
<t>This section provides an informative description of expected FCAST
receiver behavior. The following operations can take place at a
receiver: <list style="numbers">
<t>The receiver joins the session and collects incoming
packets;</t>
<t>If the header portion of a Compound Object is entirely received
(which may happen before receiving the entire object with some
ALC/NORM configurations), or if the meta-data is sent by means of
another mechanism prior to the object, the receiver processes the
meta-data and chooses to continue to receive the object content or
not;</t>
<t>When a Compound Object has been entirely received, the receiver
processes the header, retrieves the object meta-data, perhaps
decodes the meta-data, and processes the object accordingly;</t>
<t>When a CID is received, which is indicated by the 'C' flag set
in the FCAST Header, the receiver decodes the CID, and retrieves
the list of objects that are part of the current carousel
instance. This list can be used to remove objects sent in a
previous carousel instance that might not have been totally
decoded and that are no longer part of the current carousel
instance;</t>
<t>When a CID is received, the receiver also retrieves the list of
TOI equivalences, if any, and takes appropriate measures, for
instance by informing the transport layer;</t>
<t>When a receiver receives a CID with an "Fcast-CID-Complete"
meta-data entry set to 'Fcast-CID-Complete: 1', and has
successfully received all the objects of the current carousel
instance, it can safely exit from the current FCAST session;</t>
<t>Otherwise continue at Step 2 above.</t>
</list></t>
</section>
</section>
<!-- ======================================================================= -->
<section anchor="compliance_requirements"
title="Requirements for Compliant Implementations">
<!-- ==================================== -->
<t>This section lists the features that any compliant FCAST/ALC or
FCAST/NORM implementation MUST support, and those that remain OPTIONAL,
e.g., in order to enable some optimizations for a given use-case, at a
receiver.</t>
<section title="Requirements Related to the Object Meta-Data">
<!-- ==================================== -->
<t>Meta-data transmission mechanisms:</t>
<texttable>
<preamble/>
<ttcol align="left" width="33%">Feature</ttcol>
<ttcol align="left">Status</ttcol>
<c>meta-data transmission using FCAST's in-band mechanism</c>
<c>An FCAST sender MUST send meta-data with the in-band mechanism
provided by FCAST, i.e., within the FCAST Header. All the FCAST
receivers MUST be able to process meta-data sent with this FCAST
in-band mechanism.</c>
<c>meta-data transmission using other mechanisms</c>
<c>In addition to the FCAST in-band transmission of meta-data, an
FCAST sender MAY send a subset or all of the meta-data using another
mechanism. Supporting this mechanism in a compliant FCAST receiver
is OPTIONAL, and its use is OPTIONAL too. An FCAST receiver MAY
support this mechanism and take advantage of the meta-data sent in
this way. If it is not the case, the FCAST receiver will anyway
receive and process meta-data sent in-band. See <xref
target="annex_add_meta_data_tx_mechanisms"/>.</c>
</texttable>
<t>Meta-data format and encoding:</t>
<texttable>
<preamble/>
<ttcol align="left" width="33%">Feature</ttcol>
<ttcol align="left">Status</ttcol>
<c>Meta-Data Format (MDFmt field)</c>
<c>All FCAST implementations MUST support an HTTP/1.1 meta
information format <xref target="RFC2616"/>.</c>
<c>Meta-Data Encoding (MDEnc field)</c>
<c>All FCAST implementations MUST support both UTF-8 encoded text
and a GZIP compressed <xref target="RFC1952"/> of UTF-8 encoded
text, for the Object Meta-Data field.</c>
</texttable>
<t>Meta-data items (<xref target="meta-data_content"/>):</t>
<texttable>
<preamble/>
<ttcol align="left" width="33%">Feature</ttcol>
<ttcol align="left">Status</ttcol>
<c>Content-Location</c>
<c>MUST be supported</c>
<c>Content-Type</c>
<c>MUST be supported</c>
<c>Content-Length</c>
<c>MUST be supported</c>
<c>Content-Encoding</c>
<c>MUST be supported. All FCAST implementations MUST support GZIP
encoding <xref target="RFC1952"/></c>
<c>Fcast-Obj-Digest-SHA1</c>
<c>MUST be supported</c>
<c>Fcast-Obj-Digest-SHA256</c>
<c>MUST be supported</c>
<c>Fcast-Obj-Slice-Nb</c>
<c>MUST be supported</c>
<c>Fcast-Obj-Slice-Idx</c>
<c>MUST be supported</c>
<c>Fcast-Obj-Slice-Offset</c>
<c>MUST be supported</c>
</texttable>
</section>
<section title="Requirements Related to the Carousel Instance Descriptor (CID)">
<!-- ==================================== -->
<t>Any compliant FCAST implementation MUST support the CID mechanism,
in order to list the Compound Objects that are part of a given
Carousel Instance. However its use is OPTIONAL.</t>
<t>CID-specific Meta-data items (<xref
target="carousel_instance_descr"/>):</t>
<texttable>
<preamble/>
<ttcol align="left" width="33%">Feature</ttcol>
<ttcol align="left">Status</ttcol>
<c>Fcast-CID-Complete</c>
<c>MUST be supported</c>
<c>Fcast-CID-ID</c>
<c>MUST be supported</c>
</texttable>
</section>
</section>
<section anchor="security" title="Security Considerations">
<!-- ==================================== -->
<section anchor="pb_statement" title="Problem Statement">
<!-- ==================================== -->
<t>A content delivery system may be subject to attacks that target:
<list style="symbols">
<t>the network, to compromise the delivery infrastructure (e.g.,
by creating congestion),</t>
<t>the Content Delivery Protocol (CDP), to compromise the delivery
mechanism (i.e., FCAST in this case), or</t>
<t>the content itself, to corrupt the objects being
transmitted.</t>
</list></t>
<t>These attacks can be launched against all or any subset of the
following: <list style="symbols">
<t>against the data flow itself (e.g., by sending forged
packets),</t>
<t>against the session control parameters (e.g., by corrupting the
session description, the CID, the object meta-data, or the ALC/LCT
control parameters), that are sent either in-band or out-of-band,
or</t>
<t>against some associated building blocks (e.g., the congestion
control component).</t>
</list></t>
<t>More details on these possible attacks are provided in the
following sections along with possible counter-measures.
Recommendations are made in <xref
target="min-sec-recommendations"/>.</t>
</section>
<section anchor="attacks_against_data"
title="Attacks Against the Data Flow">
<!-- ==================================== -->
<t>The following types of attacks exist against the data flow: <list
style="symbols">
<t>attacks that are meant to gain unauthorized access to a
confidential object (e.g., obtaining non-free content without
purchasing it) and</t>
<t>attacks that try to corrupt the object being transmitted (e.g.,
to inject malicious code within an object, or to prevent a
receiver from using an object, which is a kind of Denial of
Service (DoS)).</t>
</list></t>
<section anchor="access_to_confidential_obj"
title="Attacks Meant to Gain Access to Confidential Objects">
<!-- ==================================== -->
<t>Modern cryptographic mechanisms can provide access control to
transmitted objects. One way to do this is by encrypting the entire
object prior to transmission, knowing that authenticated receivers
have the cryptographic mechanisms to decrypt the content. Another
way is to encrypt individual packets using IPsec/ESP <xref
target="RFC4303"/> (<xref target="min-sec-recommendations"/>). These
two techniques can also provide confidentiality to the objects being
transferred.</t>
<t>If access control and/or confidentiality services are desired,
one of these mechanisms is RECOMMENDED and SHOULD be deployed.</t>
</section>
<section anchor="obj_corruption"
title="Attacks Meant to Corrupt Objects">
<!-- ==================================== -->
<t>Protection against attacks on the data integrity of the object
may be achieved by a mechanism agreed upon between the sender and
receiver, that features sender authentication and a method to verify
that the object integrity has remained intact during transmission.
This service can be provided at the object level, but in that case a
receiver has no way to identify what symbols are corrupted if the
object is detected as corrupted. This service can also be provided
at the packet level. In some cases, after removing all corrupted
packets, the object may be recovered. Several techniques can provide
the data integrity and sender authentication services: <list
style="symbols">
<t>at the object level, the object can be digitally signed, for
instance by using RSASSA-PKCS1-v1_5 <xref target="RFC3447"/>.
This signature enables a receiver to check the object integrity.
Even if digital signatures are computationally expensive, this
calculation occurs only once per object, which is usually
acceptable;</t>
<t>at the packet level, each packet can be digitally signed
<xref target="RFC6584"/>. A major limitation is the high
computational and transmission overheads that this solution
requires;</t>
<t>at the packet level, a Group Message Authentication Code
(MAC) <xref target="RFC2104"/><xref target="RFC6584"/> scheme
can be used, for instance by using HMAC-SHA-256 with a secret
key shared by all the group members, senders and receivers. This
technique creates a cryptographically secured digest of a packet
that is sent along with the packet. The Group MAC scheme does
not create prohibitive processing load nor transmission
overhead, but it has a major limitation: it only provides a
group authentication/integrity service since all group members
share the same secret group key, which means that each member
can send a forged packet. It is therefore restricted to
situations where group members are fully trusted, or in
association with another technique as a preliminary check to
quickly detect attacks initiated by non-group members and
discard their packets;</t>
<t>at the packet level, Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) <xref target="RFC4082"/><xref
target="RFC5776"/> is an attractive solution that is robust to
losses, provides an authentication and integrity verification
service, and does not create any prohibitive processing load or
transmission overhead. Yet, a delay is incurred in checking a
TESLA authenticated packet which may be more than what is
desired in some use-cases;</t>
<t>at the packet level, IPsec/ESP <xref target="RFC4303"/> can
be used to check the integrity and authenticate the sender of
all the packets being exchanged in a session (see <xref
target="min-sec-recommendations"/>).</t>
</list></t>
<t>Techniques relying on public key cryptography (digital signatures
and TESLA during the bootstrap process, when used) require that
public keys be securely associated to the entities. This can be
achieved by a Public Key Infrastructure (PKI), or by a PGP Web of
Trust, or by securely preplacing the public keys of each group
member.</t>
<t>Techniques relying on symmetric key cryptography (Group MAC)
require that a secret key be shared by all group members. This can
be achieved by means of a group key management protocol, or simply
by securely preplacing the secret key (but this manual solution has
many limitations).</t>
<t>It is up to the developer and deployer, who know the security
requirements and features of the target application area, to define
which solution is the most appropriate. In any case, whenever there
is a threat of object corruption, it is RECOMMENDED that at least
one of these techniques be used. <xref
target="min-sec-recommendations"/> defines minimum security
recommendations that can be used to provide such services.</t>
</section>
</section>
<section anchor="attack_against_ctrl_param"
title="Attacks Against the Session Control Parameters and Associated Building Blocks">
<!-- ==================================== -->
<t>Let us now consider attacks against the session control parameters
and the associated building blocks. The attacker has at least the
following opportunities to launch an attack: <list style="symbols">
<t>the attack can target the session description,</t>
<t>the attack can target the FCAST CID,</t>
<t>the attack can target the meta-data of an object,</t>
<t>the attack can target the ALC/LCT parameters, carried within
the LCT header or</t>
<t>the attack can target the FCAST associated building blocks, for
instance the multiple rate congestion control protocol.</t>
</list></t>
<t>The consequences of these attacks are potentially serious, since
they can compromise the behavior of the content delivery system or
even compromise the network itself.</t>
<section anchor="attack_against_sdp"
title="Attacks Against the Session Description">
<!-- ==================================== -->
<t>An FCAST receiver may potentially obtain an incorrect Session
Description for the session. The consequence of this is that
legitimate receivers with the wrong Session Description will be
unable to correctly receive the session content, or that receivers
will inadvertently try to receive at a much higher rate than they
are capable of, thereby possibly disrupting other traffic in the
network.</t>
<t>To avoid these problems, it is RECOMMENDED that measures be taken
to prevent receivers from accepting incorrect Session Descriptions.
One such measure is sender authentication to ensure that receivers
only accept legitimate Session Descriptions from authorized senders.
How these measures are achieved is outside the scope of this
document since this session description is usually carried
out-of-band.</t>
</section>
<section anchor="attack_against_cio"
title="Attacks Against the FCAST CID">
<!-- ==================================== -->
<t>Corrupting the FCAST CID is one way to create a Denial of Service
attack. For example, the attacker can insert an "Fcast-CID-Complete:
1" meta-data entry to make the receivers believe that no further
modification will be done.</t>
<t>It is therefore RECOMMENDED that measures be taken to guarantee
the integrity and to check the sender's identity of the CID. To that
purpose, one of the counter-measures mentioned above (<xref
target="obj_corruption"/>) SHOULD be used. These measures will
either be applied on a packet level, or globally over the whole CID
object. When there is no packet level integrity verification scheme,
it is RECOMMENDED to digitally sign the CID.</t>
</section>
<section anchor="attack_against_meta_data"
title="Attacks Against the Object Meta-Data">
<!-- ==================================== -->
<t>Modifying the object meta-data is another way to launch an
attack. For example, the attacker may change the message digest
associated to an object, leading a receiver to reject an object,
even if it has been correctly received. More generally, a receiver
SHOULD be very careful during meta-data processing. For instance a
receiver SHOULD NOT try to follow links (e.g., the URI contained in
th Content-Location meta-data). As another example, malformed HTTP
contents can be used as an attack vector and a receiver should take
great care.</t>
<t>It is therefore RECOMMENDED that measures be taken to guarantee
the integrity and to check the sender's identity of the Compound
Object. To that purpose, one of the counter-measures mentioned above
(<xref target="obj_corruption"/>) SHOULD be used. These measures
will either be applied on a packet level, or globally over the whole
Compound Object. When there is no packet level integrity
verification scheme, it is RECOMMENDED to digitally sign the
Compound Object.</t>
<!-- XXX: how can we digitally sign a compound object? -->
</section>
<section anchor="attack_against_alc"
title="Attacks Against the ALC/LCT and NORM Parameters">
<!-- ==================================== -->
<t>By corrupting the ALC/LCT header (or header extensions) one can
execute attacks on the underlying ALC/LCT implementation. For
example, sending forged ALC packets with the Close Session flag (A)
set to one can lead the receiver to prematurely close the session.
Similarly, sending forged ALC packets with the Close Object flag (B)
set to one can lead the receiver to prematurely give up the
reception of an object. The same comments can be made for NORM.</t>
<t>It is therefore RECOMMENDED that measures be taken to guarantee
the integrity and to check the sender's identity of each ALC or NORM
packet received. To that purpose, one of the counter-measures
mentioned above (<xref target="obj_corruption"/>) SHOULD be
used.</t>
</section>
<section anchor="attack_against_bb"
title="Attacks Against the Associated Building Blocks">
<!-- ==================================== -->
<t>Let us first focus on the congestion control building block that
may be used in an ALC or NORM session. A receiver with an incorrect
or corrupted implementation of the multiple rate congestion control
building block may affect the health of the network in the path
between the sender and the receiver. That may also affect the
reception rates of other receivers who joined the session.</t>
<t>When congestion control is applied with FCAST, it is therefore
RECOMMENDED that receivers be authenticated as legitimate receivers
before they can join the session. If authenticating a receiver does
not prevent this latter to launch an attack, it will enable the
network operator to easily identify him and to take
counter-measures. The details of how this is done are outside the
scope of this document.</t>
<t>When congestion control is applied with FCAST, it is also
RECOMMENDED that a packet level authentication scheme be used, as
explained in <xref target="obj_corruption"/>. Some of them, like
TESLA, only provide a delayed authentication service, whereas
congestion control requires a rapid reaction. It is therefore
RECOMMENDED <xref target="RFC5775"/> that a receiver using TESLA
quickly reduces its subscription level when the receiver believes
that a congestion did occur, even if the packet has not yet been
authenticated. Therefore TESLA will not prevent DoS attacks where an
attacker makes the receiver believe that a congestion occurred. This
is an issue for the receiver, but this will not compromise the
network. Other authentication methods that do not feature this
delayed authentication could be preferred, or a group MAC scheme
could be used in parallel to TESLA to prevent attacks launched from
outside of the group.</t>
</section>
</section>
<section title="Other Security Considerations">
<!-- ==================================== -->
<t>Lastly, we note that the security considerations that apply to, and
are described in, ALC <xref target="RFC5775"/>, LCT <xref
target="RFC5651"/>, NORM <xref target="RFC5740"/> and FEC <xref
target="RFC5052"/> also apply to FCAST as FCAST builds on those
specifications. In addition, any security considerations that apply to
any congestion control building block used in conjunction with FCAST
also applies to FCAST. Finally, the security discussion of <xref
target="I-D.ietf-rmt-sec-discussion"/> also applies here.</t>
</section>
<section anchor="min-sec-recommendations"
title="Minimum Security Recommendations">
<!-- ==================================== -->
<t>We now introduce a mandatory to implement but not necessarily to
use security configuration, in the sense of <xref target="RFC3365"/>.
Since FCAST/ALC relies on ALC/LCT, it inherits the "baseline secure
ALC operation" of <xref target="RFC5775"/>. Similarly, since
FCAST/NORM relies on NORM, it inherits the "baseline secure NORM
operation" of <xref target="RFC5740"/>. Therefore, IPsec/ESP in
transport mode MUST be implemented, but not necessarily used, in
accordance to <xref target="RFC5775"/> and <xref target="RFC5740"/>.
<xref target="RFC4303"/> explains that ESP can be used to potentially
provide confidentiality, data origin authentication, content
integrity, anti-replay and (limited) traffic flow confidentiality.
<xref target="RFC5775"/> specifies that the data origin
authentication, content integrity and anti-replay services SHALL be
used, and that the confidentiality service is RECOMMENDED. If a short
lived session MAY rely on manual keying, it is also RECOMMENDED that
an automated key management scheme be used, especially in case of long
lived sessions.</t>
<t>Therefore, the RECOMMENDED solution for FCAST provides per-packet
security, with data origin authentication, integrity verification and
anti-replay. This is sufficient to prevent most of the in-band attacks
listed above. If confidentiality is required, a per-packet encryption
SHOULD also be used.</t>
</section>
</section>
<!-- ======================================================================= -->
<section anchor="op_considerations" title="Operational Considerations">
<!-- ==================================== -->
<t>FCAST is compatible with any congestion control protocol designed for
ALC/LCT or NORM. However, depending on the use-case, the data flow
generated by the FCAST application might not be constant, but instead be
bursty in nature. Similarly, depending on the use-case, an FCAST session
might be very short. Whether and how this will impact the congestion
control protocol is out of the scope of the present document.</t>
<t>FCAST is compatible with any security mechanism designed for ALC/LCT
or NORM. The use of a security scheme is strongly RECOMMENDED (see <xref
target="security"/>).</t>
<t>FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM.
Whether FEC is used or not, and the kind of FEC scheme used, is to some
extent transparent to FCAST.</t>
<t>FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST
specification has any implication on the source or destination IP
address type.</t>
<t>The delivery service provided by FCAST might be fully reliable, or
only partially reliable depending upon: <list style="symbols">
<t>the way ALC or NORM is used (e.g., whether FEC encoding and/or
NACK-based repair requests are used or not),</t>
<t>the way the FCAST carousel is used (e.g., whether the objects are
made available for a long time span or not), and</t>
<t>the way in which FCAST itself is employed (e.g., whether there is
a session control application that might automatically extend an
existing FCAST session until all receivers have received the
transmitted content).</t>
</list></t>
<t>The receiver set can be restricted to a single receiver or possibly a
very large number of receivers. While the choice of the underlying
transport protocol (i.e., ALC or NORM) and its parameters may limit the
practical receiver group size, nothing in FCAST itself limits it. For
instance, if FCAST/ALC is used on top of purely unidirectional transport
channels, with no feedback information at all, which is the default mode
of operation, then the scalability is maximum since neither FCAST, nor
ALC, UDP or IP generates any feedback message. On the contrary, the
FCAST/NORM scalability is typically limited by NORM scalability itself.
For example, NORM can be configured to operate using proactive FEC
without feedback similar to ALC, with receivers configured to provide
NACK and optionally ACK feedback, or a hybrid combination of these.
Similarly, if FCAST is used along with a session control application
that collects reception information from the receivers, then this
session control application may limit the scalability of the global
object delivery system. This situation can of course be mitigated by
using a hierarchy of servers or feedback message aggregation. The
details of this are out of the scope of the present document.</t>
<t>The content of a carousel instance MAY be described by means of an
OPTIONAL Carousel Instance Descriptor (CID) (<xref target="cio"/>). The
decisions of whether a CID should be used or not, how often and when a
CID should be sent, are left to the sender and depend on many
parameters, including the target use case and the session dynamics. For
instance it may be appropriate to send a CID at the beginning of each
new carousel instance, and then periodically. These operational aspects
are out of the scope of the present document.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<!-- ==================================== -->
<t>This specification requires IANA to create three new registries.</t>
<!--<section title="Namespace declaration for Object Meta-Data Format">-->
<section title="Creation of the FCAST Object Meta-Data Format Registry">
<!-- ==================================== -->
<t>This document requires IANA to create a new registry, "FCAST Object
Meta-Data Format" (MDFmt), with a reference to this document. The
registry entries consist of a numeric value from 0 to 15, inclusive
(i.e., they are 4-bit positive integers) that define the format of the
object meta-data (see <xref target="compound_obj_format"/>).</t>
<t>The initial value for this registry is defined below. Future
assignments are to be made through Expert Review with Specification
Required <xref target="RFC5226"/>.</t>
<texttable>
<preamble/>
<ttcol>Value</ttcol>
<ttcol align="center">Format Name</ttcol>
<ttcol align="center">Format Reference</ttcol>
<ttcol>Reference</ttcol>
<c>0 (default)</c>
<c>HTTP/1.1 meta information format</c>
<c><xref target="RFC2616"/>, Section 7.1</c>
<c>This specification</c>
</texttable>
<!-- <t> All implementations MUST support format 0 (default). </t> -->
</section>
<section title="Creation of the FCAST Object Meta-Data Encoding Registry">
<!-- ==================================== -->
<t>This document requires IANA to create a new registry, "FCAST Object
Meta-Data Encoding" (MDEnc), with a reference to this document. The
registry entries consist of a numeric value from 0 to 15, inclusive
(i.e., they are 4-bit positive integers) that defines the encoding of
the Object Meta-Data field (see <xref
target="compound_obj_format"/>).</t>
<t>The initial values for this registry are defined below. Future
assignments are to be made through Expert Review <xref
target="RFC5226"/>.</t>
<texttable>
<preamble/>
<ttcol align="center">Value</ttcol>
<ttcol align="center">Encoding Name</ttcol>
<ttcol align="center">Encoding Reference</ttcol>
<ttcol align="center">Reference</ttcol>
<c>0</c>
<c>UTF-8 encoded text</c>
<c><xref target="RFC2279"/></c>
<c>This specification</c>
<c>1</c>
<c>GZIP'ed UTF-8 encoded text</c>
<c><xref target="RFC1952"/><xref target="RFC2279"/></c>
<c>This specification</c>
</texttable>
</section>
<section title="Creation of the FCAST Object Meta-Data Types Registry">
<!-- ==================================== -->
<t>This document requires IANA to create a new registry, "FCAST Object
Meta-Data Types" (MDType), with a reference to this document. The
registry entries consist of additional text meta-data type identifiers
and descriptions for meta-data item types that are specific to FCAST
operation and not previously defined in <xref target="RFC1952"/>. The
initial values are those described in <xref
target="meta-data_content"/> of this specification. This table
summarizes those initial registry entries. Future assignments are to
be made through Expert Review <xref target="RFC5226"/>.</t>
<texttable align="center">
<preamble/>
<ttcol align="left">Meta-Data Type</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="center">Reference</ttcol>
<c>Fcast-Obj-Digest-SHA1</c>
<c>a string that contains the "base64" encoding of the SHA-1 message
digest of the object before any content encoding is applied (if any)
and without considering the FCAST Header</c>
<c>This specification</c>
<c>Fcast-Obj-Digest-SHA256</c>
<c>a string that contains the "base64" encoding of the SHA-256
message digest of the object before any content encoding is applied
(if any) and without considering the FCAST Header</c>
<c>This specification</c>
<c>Fcast-Obj-Slice-Nb</c>
<c>Unsigned 32-bit integer that contains the total number of slices.
A value greater than 1 indicates that this object is the result of a
split of the original object</c>
<c>This specification</c>
<c>Fcast-Obj-Slice-Idx</c>
<c>Unsigned 32-bit integer that contains the slice index (in the {0
.. SliceNb - 1} interval)</c>
<c>This specification</c>
<c>Fcast-Obj-Slice-Offset</c>
<c>Unsigned 64-bit integer that contains the byte offset at which
this slice starts within the original object</c>
<c>This specification</c>
</texttable>
</section>
</section>
<section title="Acknowledgments">
<t>The authors are grateful to the authors of <xref target="ALC-00"/>
for specifying the first version of FCAST/ALC. The authors are also
grateful to David Harrington, Gorry Fairhurst and Lorenzo Vicisano for
their valuable comments. The authors are also grateful to Jari Arkko,
Ralph Droms, Wesley Eddy, Roni Even, Stephen Farrell, Russ Housley,
Chris Lonvick, Pete Resnick, Joseph Yee, and Martin Stiemerling.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.1071'?>
<?rfc include='reference.RFC.5651'?>
<?rfc include='reference.RFC.5740'?>
<?rfc include='reference.RFC.5775'?>
<?rfc include='reference.RFC.1952'?>
<?rfc include='reference.RFC.2279'?>
<?rfc include='reference.RFC.2616'?>
<?rfc include='reference.RFC.5234'?>
<?rfc include='reference.RFC.4648'?>
<?rfc include='reference.RFC.3174'?>
<?rfc include='reference.RFC.6234'?>
</references>
<references title="Informative References">
<reference anchor="ALC-00">
<front>
<title>Asynchronous Layered Coding: a Scalable Reliable Multicast
Protocol</title>
<author initials="M." surname="Luby">
<organization/>
</author>
<author initials="G." surname="Gemmell">
<organization/>
</author>
<author initials="L." surname="Vicisano">
<organization/>
</author>
<author initials="J." surname="Crowcroft">
<organization/>
</author>
<author initials="B." surname="Lueckenhoff">
<organization/>
</author>
<date month="March" year="2000"/>
</front>
</reference>
<?rfc include="reference.RFC.6726"?>
<?rfc include="reference.I-D.ietf-rmt-sec-discussion"?>
<?rfc include='reference.RFC.3365'?>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.3447'?>
<?rfc include='reference.RFC.4082'?>
<?rfc include='reference.RFC.4303'?>
<?rfc include='reference.RFC.5052'?>
<?rfc include='reference.RFC.5510'?>
<?rfc include='reference.RFC.5776'?>
<?rfc include='reference.RFC.6584'?>
</references>
<section anchor="fcast_exple" title="FCAST Examples">
<!-- ==================================== -->
<t>This appendix provides informative examples of FCAST Compound Objects
and Carousel Instance Descriptor formats.</t>
<section title="Simple Compound Object Example">
<!-- ==================================== -->
<figure anchor="expl_object" title="Simple Compound Object Example.">
<artwork align="center"><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver=0| 0 |1|0|MDFmt=0|MDEnc=0| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Length=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. "Content-Location: example_1.txt<CR-LF>" meta-data (33 bytes) .
. .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><xref target="expl_object"/> shows a simple Compound Object where
the meta-data string, in HTTP/1.1 meta-information format (MDFmt=0)
contains:</t>
<figure>
<artwork align="left"><![CDATA[
Content-Location: example_1.txt<CR-LF>
]]></artwork>
</figure>
<t>This UTF-8 encoded text (since MDEnc=0) is 33 bytes long (there is no
final '\0' character). Therefore 3 padding bytes are added. There is
no Content-Length meta-data entry for the object transported (without
FCAST additional encoding) in the Object Data field, since this length
can easily be calculated by the receiver as the FEC OTI transfer
length minus the header length. Finally, the checksum encompasses the
whole Compound Object (G=1).</t>
<!-- removed because only on rare circunstances a compound object will
not contain any meta data -->
<!--
<figure anchor="expl_no_meta-data"
title="Compound Object Example with no Meta-Data.">
<artwork align="center"><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |1|0| 0 | 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><xref target="expl_no_meta-data"></xref> shows a Compound Object
without any meta-data. The fact there is no meta-data is indicated by
the value 8 of the FCAST Header Length field. No
padding is required.</t>
-->
</section>
<section title="Carousel Instance Descriptor Example">
<!-- ==================================== -->
<figure align="center" anchor="expl_cid"
title="Example of CID, in case of a static session.">
<artwork align="center"><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver=0| 0 |1|1|MDFmt=0|MDEnc=0| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Length=31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. "Fcast-CID-Complete: 1<CR-LF>" meta-data string (23 bytes) .
. .
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Object List string .
. .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><xref target="expl_cid"/> shows an example CID object, in the case
of a static FCAST session, i.e., a session where the set of objects is
set once and for all. The meta-data UTF-8 encoded text only contains the
following entry since Fcast-CID-ID is implicit:</t>
<figure>
<artwork align="left"><![CDATA[
Fcast-CID-Complete: 1<CR-LF>]]></artwork>
</figure>
<t>This UTF-8 encoded text (since MDEnc=0) is 23 bytes long (there no final
'\0' character). Therefore 1 padding byte is added.</t>
<t>The object list contains the following 25 byte long string, (there
is no final '\0' character):</t>
<figure>
<artwork align="left"><![CDATA[
1,2,3,100-104,200-203,299
]]></artwork>
</figure>
<t>There are therefore a total of 3+5+4+1 = 13 objects in the carousel
instance, and therefore in the FCAST session. There is no meta-data
associated to this CID. The session being static and composed of a
single Carousel Instance, the sender did not feel the necessity to
carry a Carousel Instance ID meta-data.</t>
</section>
</section>
<section anchor="annex_add_meta_data_tx_mechanisms"
title="Additional Meta-Data Transmission Mechanisms">
<!-- ==================================== -->
<section title="Supporting Additional Mechanisms">
<!-- ==================================== -->
<t>In certain use-cases, FCAST can take advantage of another in-band
(e.g., via NORM_INFO messages <xref target="norm_specifics"/>) or
out-of-band signaling mechanism. This section provides an overview of
how other signaling mechanism could be employed and a normative
specification for how FCAST information is embedded when NORM_INFO
messages are used for carrying FCAST Headers. Such additional
signaling schemes can be used to carry the whole meta-data, or a
subset of it, ahead of time, before the associated compound object.
Therefore a receiver could be able to decide in advance, before
beginning the reception of the compound object, whether the object is
of interest or not, based on the information retrieved by this way,
which mitigates FCAST limitations. While out-of-band techniques are
out of the scope of this document, we explain below how this can be
achieved in case of FCAST/NORM.</t>
<t>Supporting additional mechanisms is OPTIONAL in FCAST
implementations. In any case, an FCAST sender MUST continue to send
all the required meta-data in the compound object, even if the whole
meta-data, or a subset of it, is sent by another mechanism (<xref
target="compliance_requirements"/>). Additionally, when meta-data is
sent several times, there MUST NOT be any contradiction in the
information provided by the different mechanisms. In case a mismatch
is detected, the meta-data contained in the Compound Object MUST be
used as the definitive source.</t>
<t>When meta-data elements are communicated out-of-band, in advance of
data transmission, the following piece of information can be useful:
<list style="symbols">
<t>TOI: a positive integer that contains the Transmission Object
Identifier (TOI) of the object, in order to enable a receiver to
easily associate the meta-data to the object. The valid range for
TOI values is discussed in <xref target="object_id"/>;</t>
</list></t>
</section>
<section anchor="norm_specifics"
title="Using NORM_INFO Messages with FCAST/NORM">
<!-- ==================================== -->
<t>The NORM_INFO message of NORM can convey "out-of-band" content with
respect to a given transport object. With FCAST, this message MAY be
used as an additional mechanism to transmit meta-data. In that case,
the NORM_INFO message carries a new Compound Object that contains all
the meta-data of the original object, or a subset of it. The NORM_INFO
Compound Object MUST NOT contain any Object Data field (i.e., it is
only composed of the header), it MUST feature a non global checksum,
and it MUST NOT include any padding field. <!-- The main Compound
Object MUST in any case contain the whole meta-data (e.g., because
a receiver MAY not support the NORM_INFO facility). Additionally, the
meta-data entries contained in the NORM_INFO MUST be identical to
the same entries in the main Compound Object.
--> Finally, note that the availability of NORM_INFO for a given
object is signaled through the use of a dedicated flag in the
NORM_DATA message header. Along with NORM's NACK-based repair request
signaling, it allows a receiver to quickly (and independently) request
an object's NORM_INFO content. However, a limitation here is that the
FCAST Header MUST fit within the byte size limit defined by the NORM
sender's configured "segment size" (typically a little less than the
network MTU);</t>
<section title="Example">
<!-- ==================================== -->
<t>In case of FCAST/NORM, the object meta-data (or a subset of it)
can be carried as part of a NORM_INFO message, as a new Compound
Object that does not contain any Object Data. In the following
informative example we assume that the whole meta-data is carried in
such a message. <xref target="expl_norm_info"/> shows an example
NORM_INFO message that contains the FCAST Header, including
meta-data. In this example, the first 16 bytes are the NORM_INFO
base header, the next 12 bytes are a NORM EXT_FTI header extension
containing the FEC Object Transport Information for the associated
object, and the remaining bytes are the FCAST Header, including
meta-data. Note that "padding" MUST NOT be used and that the FCAST
checksum only encompasses the Compound Object Header (G=0).</t>
<figure align="center" anchor="expl_norm_info"
title="NORM_INFO containing an EXT_FTI header extension and an FCAST Header">
<artwork align="center"><![CDATA[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
|version| type=1| hdr_len = 7 | sequence | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| source_id | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o
| instance_id | grtt |backoff| gsize | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ m
| flags | fec_id = 5 | object_transport_id | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
| HET = 64 | HEL = 3 | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + f
| Transfer Length = 41 | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
| Encoding Symbol Length (E) | MaxBlkLen (B) | max_n | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
| 0 | 0 |0|0| 0 | 0 | Checksum | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 41 | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| c
. . a
. meta-data UTF-8 encoded text (32 bytes) . s
. . t
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | v
+-+-+-+-+-+-+-+-+ --]]></artwork>
</figure>
<t>The NORM_INFO message shown in <xref target="expl_norm_info"/>
contains the EXT_FTI header extension to carry the FEC OTI. In this
example, the FEC OTI format is that of the Reed-Solomon FEC coding
scheme for fec_id = 5 as described in <xref target="RFC5510"/>.
Other alternatives for providing the FEC OTI would have been to
either include it directly in the meta-data of the FCAST Header, or
to include an EXT_FTI header extension to all NORM_DATA packets (or
a subset of them). Note that the NORM "Transfer_Length" is the total
length of the associated Compound Object, i.e., 41 bytes.</t>
<t>The Compound Object in this example does contain the same
meta-data and is formatted as in the example of <xref
target="expl_object"/>. With the combination of the FEC_OTI and the
FCAST meta-data, the NORM protocol and FCAST application have all of
the information needed to reliably receive and process the
associated object. Indeed, the NORM protocol provides rapid
(NORM_INFO has precedence over the associated object content),
reliable delivery of the NORM_INFO message and its payload, the
FCAST Compound Object.</t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:33:42 |