RMT V. Roca
Internet-Draft INRIA
Intended status: Experimental B. Adamson
Expires: April 3, 2009 Naval Research Laboratory
September 30, 2008
FCAST: Scalable Object Delivery for the ALC and NORM Protocols
draft-roca-rmt-newfcast-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 3, 2009.
Abstract
This document introduces the FCAST object (e.g., file) delivery
application on top of the ALC and NORM reliable multicast protocols.
FCAST is a highly scalable application that provides a reliable
object delivery service.
Roca & Adamson Expires April 3, 2009 [Page 1]
Internet-Draft FCAST: Scalable Object Delivery September 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions, Notations and Abbreviations . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4. FCAST Principles . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FCAST Content Delivery Service . . . . . . . . . . . . . . 6
4.2. Meta-Data Transmission . . . . . . . . . . . . . . . . . . 6
4.3. Meta-Data Content . . . . . . . . . . . . . . . . . . . . 7
4.4. Carousel Transmission . . . . . . . . . . . . . . . . . . 8
4.5. Carousel Instance Object . . . . . . . . . . . . . . . . . 9
4.6. Compound Object Identification . . . . . . . . . . . . . . 10
4.7. FCAST/ALC Additional Specificities . . . . . . . . . . . . 11
4.8. FCAST/NORM Additional Specificities . . . . . . . . . . . 11
4.9. FCAST Sender Behavior . . . . . . . . . . . . . . . . . . 12
4.10. FCAST Receiver Behavior . . . . . . . . . . . . . . . . . 13
5. FCAST Specifications . . . . . . . . . . . . . . . . . . . . . 14
5.1. Compound Object Header Format . . . . . . . . . . . . . . 14
5.2. Carousel Instance Object Format . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 17
6.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 18
6.2.1. Access to Confidential Objects . . . . . . . . . . . . 18
6.2.2. Object Corruption . . . . . . . . . . . . . . . . . . 18
6.3. Attacks Against the Session Control Parameters and
Associated Building Blocks . . . . . . . . . . . . . . . . 20
6.3.1. Attacks Against the Session Description . . . . . . . 20
6.3.2. Attacks Against the FCAST CIO . . . . . . . . . . . . 21
6.3.3. Attacks Against the Object Meta-Data . . . . . . . . . 21
6.3.4. Attacks Against the ALC/LCT Parameters . . . . . . . . 21
6.3.5. Attacks Against the Associated Building Blocks . . . . 22
6.4. Other Security Considerations . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. FCAST Examples . . . . . . . . . . . . . . . . . . . 24
A.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . . 25
A.2. FCAST/NORM with NORM_INFO Examples . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Roca & Adamson Expires April 3, 2009 [Page 2]
Internet-Draft FCAST: Scalable Object Delivery September 2008
1. Introduction
This document introduces the FCAST reliable and scalable object
(e.g., file) delivery application. Two versions of FCAST exist:
o FCAST/ALC that relies on the Asynchronous Layer Coding (ALC)
[RMT-PI-ALC] and the Layered Coding Transport (LCT) [RMT-BB-LCT]
reliable multicast transport protocol, and
o FCAST/NORM that relies on the NACK-Oriented Reliable Multicast
(NORM) [RMT-PI-NORM] reliable multicast transport protocol.
Hereafter, the term FCAST denotes either FCAST/ALC or FCAST/NORM.
Depending on the target use case, the delivery service provided by
FCAST is more or less reliable. For instance, with FCAST/ALC used in
ON-DEMAND mode over a time period that largely exceeds the typical
download time, the service can be considered as fully reliable.
Similarly, when FCAST is used along with a session control
application that collects reception information and takes appropriate
corrective measures (e.g., a direct point-to-point retransmission of
missing packets, or a new multicast recovery session), then the
service can be considered as fully reliable. On the opposite, if
FCAST operates in PUSH mode, then the service is usually only
partially reliable, and a receiver that is disconnected during a
sufficient time will perhaps not have the possibility to download the
object.
Depending on the target use case, the FCAST scalability is more or
less important. 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 opposite, the FCAST/NORM scalability is
typically limited by NORM scalability itself. Similarly, if FCAST is
used along with a session control application that collects reception
information from the receivers, then this session control application
limits the scalability of the global object delivery system. This
situation can of course be mitigated by using a hierarchy of feedback
message aggregators or servers. The details of this is out of the
scope of the present document.
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 opposite, FCAST has some intrinsic limitations. From
Roca & Adamson Expires April 3, 2009 [Page 3]
Internet-Draft FCAST: Scalable Object Delivery September 2008
this point of view it differs from FLUTE [RMT-FLUTE] which favors
flexibility at the expense of some additional complexity.
A good example of the design choices meant to favor the simplicitly
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, as such, it also 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 defines
additional techniques that may be used to mitigate this limitation.
It is also possible that some use-cases require that each receiver
download the whole set of objects sent in the session (e.g., with
mirroring tools). When this is the case, the above limitation is no
longer be a problem.
1.1. Applicability
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.
FCAST is compatible with any security mechanism designed for ALC/LCT
or NORM. The use of a security scheme is strongly RECOMMENDED (see
Section 6).
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.
FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST
specification has any implication on the source or destination IP
address.
2. Requirements notation
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 [RFC2119].
Roca & Adamson Expires April 3, 2009 [Page 4]
Internet-Draft FCAST: Scalable Object Delivery September 2008
3. Definitions, Notations and Abbreviations
3.1. Definitions
This document uses the following definitions:
FCAST/ALC denotes the FCAST application running on top of the ALC/
LCT reliable transport protocol;
FCAST/NORM denotes the FCAST application running on top of the
NORM reliable transport protocol;
FCAST denotes either FCAST/ALC or FCAST/NORM;
Compound Object denotes an ALC or NORM transport object composed
of the Compound Object Header Section 5.1, including any meta-data
and the content of the original application object (e.g., a file);
Carousel denotes the compound object transmission system of an
FCAST sender;
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;
Carousel Instance Object (CIO) denotes a specific object that
lists the compound objects that comprise a given carousel
instance;
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;
The Transmission Object Identifier (TOI) refers the numeric
identifier associated to a specific object by the underlying
transport layer. In the case of ALC, this corresponds to the TOI
described in that specification while for the NORM specification
this corresponds to the NormObjectId described there.
3.2. Abbreviations
This document uses the following abbreviations:
Roca & Adamson Expires April 3, 2009 [Page 5]
Internet-Draft FCAST: Scalable Object Delivery September 2008
+------------------+-------------------------------------+
| Abbreviation | Definition |
+------------------+-------------------------------------+
| CIO | Carousel Instance Object |
| FEC OTI | FEC Object Transmission Information |
| TOI | Transmission Object Identifier |
+------------------+-------------------------------------+
4. FCAST Principles
4.1. FCAST Content Delivery Service
The basic goal of FCAST is to transmit objects to a group of
receivers in a reliable way. The receiver set MAY be restricted to a
single receiver or MAY include possibly a very large number of
receivers. FCAST is specified to support two forms of operation.
1. FCAST/ALC: where the FCAST application is meant to run on top of
the ALC/LCT reliable multicast transport protocol, and
2. FCAST/NORM: where the FCAST application is meant to run on top of
the NORM reliable multicast transport protocol.
This specification is designed such that both forms of operation
share as much commonality as possible.
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. The transmission might be fully
reliable, or only partially reliable depending upon the way ALC or
NORM is used (e.g., whether FEC encoding and/or NACK-based repair
requests are used or not), the way the FCAST carousel is used (e.g.,
whether the objects are made available for a long time span or not),
and 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).
FCAST is designed to be as self-sufficient as possible, in particular
in the way object meta-data is attached to object data content.
However, for some uses, meta-data MAY also be communicated by an out-
of-band mechanism that is out of the scope of the present document.
4.2. Meta-Data Transmission
FCAST usually carries meta-data elements by prepending them to the
object it refers to. As a result, a compound object is created that
Roca & Adamson Expires April 3, 2009 [Page 6]
Internet-Draft FCAST: Scalable Object Delivery September 2008
is composed of a header followed by the original object content.
This header is itself composed of the meta-data as well as several
fields, for instance to indicate the boundaries between the various
parts of this compound object.
Attaching the meta-data to the object is an efficient solution, since
it guaranties that meta-data be received along with the associated
object, and it allows the transport of the meta-data to benefit from
any transport-layer FEC erasure protection of the compound object.
However a limit of this scheme, as such, is that a client does not
know the meta-data of an object before it begins receiving the object
and perhaps not until decoding the object completely depending upon
the transport protocol used and its particular FEC code type and
parameters.
However, this solution can be associated to another in-band (e.g.,
via NORM INFO messages, Section 4.8) or out-of-band signaling
mechanism in order to carry the whole meta-data (or a subset of it)
possibly ahead of time.
4.3. Meta-Data Content
The meta-data associated to an object can be composed of, but are not
limited to:
o Content-Location: the URI of the object, which gives the name and
location of the object;
o Content-Type: the MIME type of the object;
o Content-Length: the size of the initial object, before any content
encoding (if any). Note that this content length does not include
the meta-data nor the header of the compound object;
o Content-Encoding: the optional encoding of the object performed by
FCAST;
o Content-MD5: the MD5 message digest of the object in order to
check its integrity. Note that this digest is meant to protect
from transmission and processing errors, not from deliberate
attacks by an intelligent attacker. Note also that this digest
only protects the object, not the header, and therefore not the
meta-data;
o a digital signature for this object;
This list is not limited and new meta-data information can be added.
For instance, when dealing with very large objects (e.g., that
Roca & Adamson Expires April 3, 2009 [Page 7]
Internet-Draft FCAST: Scalable Object Delivery September 2008
largely exceed the working memory of a receiver), it can be
interesting to split this object into several sub-objects. When a
file is split into several objects by FCAST, the meta-data includes:
o Fcast_Obj_Slice_Nb: the total number of slices. A value strictly
greater than 1 indicates that this object is the result of a split
of the original object;
o Fcast_Obj_Slice_Idx: the slice index (in the [0 .. SliceNb[
interval);
o Fcast_Obj_Slice_Offset: the offset at which this slice starts
within the original object;
When meta-data elements are communicated out-of-band, in advance of
data transmission, the following pieces of information may also be
useful:
o TOI: the Transmission Object Identifier (TOI) of the object
(Section 4.6), in order to enable a receiver to easily associate
the meta-data to the object for which he receives packets;
o FEC Object Transmission Information (FEC OTI). In this case the
FCAST sender does not need to use the optional EXT_FTI mechanism
of ALC or NORM protocols.
4.4. Carousel Transmission
A set of FCAST compound objects scheduled for transmission are
considered a logical "Carousel". A single "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.
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. This
can be the case for instance of the CIO objects (Section 4.5). For
some FCAST usage (e.g., a unidirectional "push" mode), a Carousel
Instance may be associated to a single transmission cycle. In other
cases it may be associated to 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).
Roca & Adamson Expires April 3, 2009 [Page 8]
Internet-Draft FCAST: Scalable Object Delivery September 2008
4.5. Carousel Instance Object
The FCAST sender CAN transmit an OPTIONAL Carousel Instance Object
(CIO). The CIO 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 CIO does not
describe the objects themselves (i.e., there is no meta-data).
Additionally, the CIO includes a "Complete" flag that is used to
indicate that no further modification to the enclosed list will be
done in the future. Finally, the CIO includes a Carousel Instance ID
that identifies the Carousel Instance it pertains to.
There is no reserved TOI value for the CIO itself, since this object
is regarded by ALC/LCT or NORM as a standard object. On the
opposite, the nature of this object (CIO) is indicated by means of a
specific compound object header field (the "I" flag) 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 CIO (i.e., with
dynamic sessions), he MUST NOT filter out packets that are not in the
CIO's TOI list. Said differently, the goal of CIO is not to setup
ALC or NORM packet filters (this mechanism would not be secure in any
case).
The use of a CIO 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 CIO has several benefits:
o When the "Complete" flag is set (if ever), the receivers know when
they can leave the session, i.e., when they have received all the
objects that are part of the delivery session;
o 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 CIO. 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 CIO provides an
additional means for receivers to learn of objects for which it is
futile to request repair;
During idle periods, when the carousel instance does not contain any
object, a CIO 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
Roca & Adamson Expires April 3, 2009 [Page 9]
Internet-Draft FCAST: Scalable Object Delivery September 2008
useful to inform the receivers that:
o all the previously sent objects have been removed from the
carousel. It therefore improves the FCAST robustness even during
"idle" period;
o 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 the "Complete" flag has not been set, it implicity
informs the receivers that new objects may be sent in the future;
The decisions of whether a CIO should be used or not, how often and
when a CIO 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 CIO at the beginning of
each new carousel instance, and then periodically. These operational
aspects are out of the scope of the present document.
4.6. Compound Object Identification
The FCAST compound objects are directly associated with the object-
based transport service that the ALC and NORM protocols provide. In
each of these protocols, the messages containing transport object
content are labeled with a numeric transport object identifier (i.e.,
the ALC TOI and the NORM _NormTransportId_). For purposes of this
document, this identifier in either case (ALC or NORM) is referred to
as the TOI.
There are several differences between ALC and NORM:
o the ALC use of TOI is rather flexible, since several TOI field
sizes are possible (from 16 to 112 bits), this size can be changed
at any time, on a per-packet basis, and their management is
totally free as long as each object is associated to a unique TOI
(if no wraparound happened);
o the NORM use of TOI is more directive, since the TOI field is 16
bits long and TOIs MUST be managed sequentially;
In both NORM and ALC, it is possible that the transport
identification space may eventually wrap 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 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
Roca & Adamson Expires April 3, 2009 [Page 10]
Internet-Draft FCAST: Scalable Object Delivery September 2008
necessary to re-enqueue old objects within the Carousel with new TOI
to stay within transport identifier limits. To allow receivers to
properly combine new transport symbols for any older objects with
newly-assigned TOIs to achieve reliable transfer, a mechanism is
required to equate the object(s) with new TOI with the older object
TOI.
_*** Editor's note: This mechanism is TBD. Two complementary
possibilities are: (1) if the meta-data are processed rapidly
(e.g., by using NORM-INFO messages), a receiver quickly detects
that both objects are the same and take appropriate measures; (2)
we can also add a way, in the CIO, to say that {TOI, current CI}
== {prev_TOI, prev CI}. _
4.7. FCAST/ALC Additional Specificities
There are no additional detail or option for FCAST/ALC operation.
4.8. FCAST/NORM Additional Specificities
The NORM Protocol provides a few additional capabilities that can be
used to specifically support FCAST operation:
1. The NORM_INFO message for conveying "out-of-band" content with
respect to a given transport object MAY be used to provide the
compound object header, and in particular the object meta-data,
to the receivers. 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. Additionally, NORM's NACK-based
repair request signaling allows a receiver to request separately
and quickly an object's NORM_INFO content. However, the
limitation here is that the Compound Object Header and its meta-
data MUST fit within the byte size limit defined by the NORM
sender's configured "segment size" (typically a little less than
the network MTU);
2. 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 CIO mechanism, a receiver has an efficient and
reliable way to discover old objects that have been removed from
the carousel instance;
3. 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
Roca & Adamson Expires April 3, 2009 [Page 11]
Internet-Draft FCAST: Scalable Object Delivery September 2008
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;
When NORM_INFO is used with FCAST/NORM, the NORM_INFO content MUST
contain the FCAST Compound Object Header and meta-data for that
object, or a subset of the meta-data. In this case, the compound
object sent in the regular NORM_DATA packets MAY be streamlined in
order to contain no meta-data at all, or only the subset of the meta-
data that is not carried in the NORM_INFO message.
It should also 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 Appendix A.
4.9. FCAST Sender Behavior
The following operations take place at a sender:
1. 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;
2. For each object, FCAST creates the compound object and registers
this latter in the carousel instance.
3. The user then informs FCAST when 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);
4. At this point, the FCAST application knows the full list of
compound objects that are part of the carousel instance and can
create a CIO if desired, possibly with the complete flag set;
5. The FCAST application can now define a transmission schedule of
these compound objects, including the optional CIO(s). 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
Roca & Adamson Expires April 3, 2009 [Page 12]
Internet-Draft FCAST: Scalable Object Delivery September 2008
of the underlying ALC or NORM protocol used and the knowledge of
the target use-case.
6. The FCAST application then starts the carousel transmission, for
the number of cycles specified. Transmissions take place until:
* the desired number of transmission cycles has been reached, or
* the user wants to prematurely stop the transmissions, or
* the user wants to add one or several new objects to the
carousel, or on the opposite wants to remove old objects from
the carousel. In that case a new carousel instance must be
created.
Then continue at Step 1 above.
4.10. FCAST Receiver Behavior
The following operations take place at an FCAST receiver:
1. The receiver joins the session and collects symbols;
2. If the header portion of a compound object is entirely received
(which may happen before receiving the entire object with some
ALC/NORM transport configurations), the receiver processes the
meta-data and chooses to continue to receive the object content
or not;
3. 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;
4. When a CIO is received, which is indicated by the 'I' flag set in
the compound object header, the receiver decodes the CIO, 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;
5. When a receiver has received a CIO with the "Complete" flag set,
and has successfully received all the objects of the current
carousel instance, it can safely exit from the current FCAST
session;
6. Otherwise continue at Step 2 above.
Roca & Adamson Expires April 3, 2009 [Page 13]
Internet-Draft FCAST: Scalable Object Delivery September 2008
5. FCAST Specifications
This section details the technical aspects of FCAST.
5.1. Compound Object Header Format
In an FCAST session, its compound objects are constructed by
prepending the Compound Object Header including any meta-data content
as shown in Figure 1 before the original object data content.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
|rsvd |I|MDE|MDF| Compound Object Header Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
| Object Meta-Data Content (optional, variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| |
. Object Data Content (optional, variable length) .
. .
. .
Figure 1: Compound Object Header with Meta-Data
The Compound Object Header fields are:
+------------+------------------------------------------------------+
| Field | Description |
+------------+------------------------------------------------------+
| I | 1-bit field that, when set to 1, indicates the |
| | object is a Carousel Instance Object (CIO). When set |
| | to 0, this field indicates that the transported |
| | object is a standard object. |
| Meta-Data | 2-bit field that defines the optional encoding of |
| Encoding | the Object Meta-Data Content field (see Section 7). |
| (MDEnc) | A plain text encoding is the default encoding and is |
| | associated value 0. A gzip encoding MAY be supported |
| | and is associated to value 1. Other encodings MAY be |
| | defined in the future. |
| Meta-Data | 2-bit field that defines the format of the object |
| Format | meta-data (see Section 7). An HTTP/1.1 |
| (MDFmt) | metainformation format [RFC2068] MUST be supported |
| | and is associated to value 0. Other formats (e.g., |
| | XML) MAY be defined in the future. |
Roca & Adamson Expires April 3, 2009 [Page 14]
Internet-Draft FCAST: Scalable Object Delivery September 2008
| Compound | 24-bit field indicating total length (in bytes) of |
| Object | all fields of the Compound Object Header, except the |
| Header | optional padding. A header length field set to value |
| Length | 4 means that there is no meta-data included. When |
| | this size is not multiple to 32 bits words, padding |
| | is added. It should be noted that the meta-data |
| | field maximum size is equal to 2^24 - 4 bytes. |
| Object | Optional, variable length field that contains the |
| Meta-Data | meta-data associated to the object, either in plain |
| | text or encoded, as specified by the MDEnc field. |
| | The Meta-Data is NULL-terminated plain text of the |
| | "TYPE" ":" "VALUE" "<CR-LF>" format used in HTTP/1.1 |
| | for metainformation [RFC2068]. The various meta-data |
| | items can appear in any order. The associated |
| | string, when non empty, MUST be NULL-terminated. |
| | When no meta-data is communicated, this field MUST |
| | be empty. |
| Padding | Optional, variable length field of zero-value bytes |
| | to align the start of the object data content to |
| | 32-bit boundary. Padding is only used when the |
| | header length value, in bytes, is not multiple of 4. |
| Object | Data content of original object represented by this |
| Data | Compound Object. Note that the length of this |
| Content | content is the transported object size minus the |
| | Compound Object Header Length |
+------------+------------------------------------------------------+
_*** Editor's note: Should we add a checksum to protect the header
itself? Since meta-data do not use an XML encoding, there is no
way to digitally sign it to check its integrity. A checksum could
offer some integrity guaranty (not security of course). _
5.2. Carousel Instance Object Format
The format of the CIO, which is a particular compound object, is
given in Figure 2.
Roca & Adamson Expires April 3, 2009 [Page 15]
Internet-Draft FCAST: Scalable Object Delivery September 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
|rsvd |1|MDE|MDF| Compound Object Header Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
| Object Meta-Data Content (optional, variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
. . |
. Object List (variable length) . O
. . b
. +-+-+-+-+-+-+-+-+ j
. | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
Figure 2: Carousel Instance Object Format
Because the CIO is transmitted as a special compound object, the
following CIO-specific meta-data entries are defined:
o Fcast_CIO_complete: when set to 1, it indicates that no new
objects in addition to the ones whose TOI are specified in this
CIO, or the ones that have been specified in the previous CIO(s),
will be sent in the future;
o Fcast_CIO_ID: this value identifies the carousel instance. It
starts from 0 and is incremented by 1 for each new carousel
instance. This entry is not mandatory since the TOI numbering of
the compound objects carrying a CIO can be used to identify the
latest CIO instance. However, this value can be useful to detect
possible gaps in the carousel instances, for instance caused by
long disconnection periods. It can also be useful to avoid
problems when TOI wrapping to 0 takes place.
Additionally, the following standard meta-data entries are often
used:
o Content-Encoding: the optional encoding of the CIO object, by
FCAST. For instance:
Content-Encoding: gzip
indicates that the Object List field has been encoded with gzip
[RFC1952]. When set to 0, this flag indicates the the Object List
field is plain text. The support of gzip encoding is MANDATORY,
both for an FCAST sender and for an FCAST receiver
The CIO fields are:
Roca & Adamson Expires April 3, 2009 [Page 16]
Internet-Draft FCAST: Scalable Object Delivery September 2008
+------------+------------------------------------------------------+
| Field | Description |
+------------+------------------------------------------------------+
| Object | List of TOIs included in the current carousel |
| List | instance, in an exhaustive way. This list, whose |
| | format is defined below, can be either in plain text |
| | (if Z is not set) or gzip'ed (if Z is set). An empty |
| | list (0 length field) indicates that the current |
| | carousel instance does not include any object. |
+------------+------------------------------------------------------+
The non-encoded (i.e., plain text) Object List is a NULL-terminated,
ASCII string containing the list of TOIs included in the current
carousel instance, specified either as the individual TOIs of each
object, or as TOI spans, or combinations of these. The format of the
ASCII string is a comma-separated list of individual "TOI" values or
"TOI_a-TOI_b" elements. This latter case means that all values
between TOI_a and TOI_b, inclusive, are part of the list. We further
require that TOI_a be strictly inferior to TOI_b. In case of TOI
wrapping to 0 and when a TOI range is specified, two separate lists
MUST be specified.
The ABNF specification is the following:
cio-list = *(list-elem *( "," list-elem))
list-elem = toi-value / toi-range
toi-value = 1*DIGIT
toi-range = toi-value "-" toi-value
; additionally, the first toi-value MUST be
; strictly inferior to the second toi-value
DIGIT = %x30-39
; a digit between O and 9, inclusive
It is RECOMMENDED, for processing reasons, that all the TOI values in
the list be given in increasing order. However a receiver MUST be
able to handle non-monotonically increasing values. It is
RECOMMENDED, for processing reasons, that a given TOI value NOT be
included multiple times in the list.
6. Security Considerations
6.1. Problem Statement
A content delivery system is potentially subject to attacks. Attacks
may target:
o the network (to compromise the routing infrastructure, e.g., by
creating congestion),
Roca & Adamson Expires April 3, 2009 [Page 17]
Internet-Draft FCAST: Scalable Object Delivery September 2008
o the Content Delivery Protocol (CDP) (e.g., to compromise the
normal behavior of FCAST) or
o the content itself (e.g., to corrupt the objects being
transmitted).
These attacks can be launched either:
o against the data flow itself (e.g., by sending forged packets),
o against the session control parameters (e.g., by corrupting the
session description, the CIO, the object meta-data, or the ALC/LCT
control parameters), that are sent either in-band or out-of-band,
or
o against some associated building blocks (e.g., the congestion
control component).
In the following sections we provide more details on these possible
attacks and sketch some possible counter-measures.
6.2. Attacks Against the Data Flow
Let us consider attacks against the data flow first. At least, the
following types of attacks exist:
o attacks that are meant to give access to a confidential object
(e.g., in case of a non-free content) and
o 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)).
6.2.1. Access to Confidential Objects
Access control to the object being transmitted is typically provided
by means of encryption. This encryption can be done over the whole
object (e.g., by the content provider, before submitting the object
to FCAST), or be done on a packet per packet basis (e.g., when IPSec/
ESP is used [RFC4303]). If confidentiality is a concern, it is
RECOMMENDED that one of these solutions be used.
6.2.2. Object Corruption
Protection against corruptions (e.g., in case of forged packets) is
achieved by means of a content integrity verification/sender
authentication scheme. This service can be provided at the object
level, but in that case a receiver has no way to identify which
Roca & Adamson Expires April 3, 2009 [Page 18]
Internet-Draft FCAST: Scalable Object Delivery September 2008
symbol(s) is(are) corrupted if the object is detected as corrupted.
This service can also be provided at the packet level. In this case,
after removing all corrupted packets, the file may be in some cases
recovered. Several techniques can provide this content integrity/
sender authentication service:
o at the object level, the object can be digitally signed (with
public key cryptography), for instance by using RSASSA-PKCS1-v1_5
[RFC3447]. This signature enables a receiver to check the object
integrity, once this latter has been fully decoded. Even if
digital signatures are computationally expensive, this calculation
occurs only once per object, which is usually acceptable;
o at the packet level, each packet can be digitally signed. A major
limitation is the high computational and transmission overheads
that this solution requires (unless perhaps if Elliptic Curve
Cryptography (ECC) is used). To avoid this problem, the signature
may span a set of packets (instead of a single one) in order to
amortize the signature calculation. But if a single packets is
missing, the integrity of the whole set cannot be checked;
o at the packet level, a Group Message Authentication Code (MAC)
[RFC2104] scheme can be used, for instance by using HMAC-SHA-1
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 pre-check);
o at the packet level, Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) [RFC4082] is an attractive solution that is
robust to losses, provides a true authentication/integrity
service, and does not create any prohibitive processing load or
transmission overhead. Yet checking a packet requires a small
delay (a second or more) after its reception;
o at the packet level, IPSec/AH [RFC4302] (possibly associated to
IPSec/ ESP) can be used to protect all the packets being exchanged
in a session.
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
Roca & Adamson Expires April 3, 2009 [Page 19]
Internet-Draft FCAST: Scalable Object Delivery September 2008
a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by
pre-distributing securely the public keys of each group member.
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
pre-distributing securely the secret key (but this manual solution
has many limitations).
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 any concern of the threat of file corruption, it is RECOMMENDED
that at least one of these techniques be used.
6.3. Attacks Against the Session Control Parameters and Associated
Building Blocks
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:
o the attack can target the session description,
o the attack can target the FCAST CIO,
o the attack can target the meta-data of an object,
o the attack can target the ALC/LCT parameters, carried within the
LCT header or
o the attack can target the FCAST associated building blocks.
The latter one is particularly true with the multiple rate congestion
control protocol which may be required.
The consequences of these attacks are potentially serious, since they
can compromise the behavior of content delivery system or even
compromise the network itself.
6.3.1. Attacks Against the Session Description
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 are unable to
correctly receive the session content, or that receivers
inadvertently try to receive at a much higher rate than they are
capable of, thereby possibly disrupting other traffic in the network.
Roca & Adamson Expires April 3, 2009 [Page 20]
Internet-Draft FCAST: Scalable Object Delivery September 2008
To avoid these problems, it is RECOMMENDED that measures be taken to
prevent receivers from accepting incorrect Session Descriptions. One
such measure is the sender authentication to ensure that receivers
only accept legitimate Session Descriptions from authorized senders.
How these measures are archived is outside the scope of this document
since this session description is usually carried out-of-band.
6.3.2. Attacks Against the FCAST CIO
Corrupting the FCAST CIO is one way to create a Denial of Service
attack. For example, the attacker removes legitimate object TOIs
from the list.
It is therefore RECOMMENDED that measures be taken to guarantee the
integrity and to check the sender's identity of the CIO. To that
purpose, one of the counter-measures mentioned above (Section 6.2.2)
SHOULD be used. These measures will either be applied on a packet
level, or globally over the whole CIO object. When there is no
packet level integrity verification scheme, it is RECOMMENDED to
digitally sign the CIO.
6.3.3. Attacks Against the Object Meta-Data
Corrupting the object meta-data is another way to create a Denial of
Service attack. For example, the attacker changes the MD5 sum
associated to a file. This possibly leads a receiver to reject the
files received, no matter whether the files have been correctly
received or not. When the meta-data are appended to the object,
corrupting the meta-data means that the compound object will be
corrupted.
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
(Section 6.2.2) 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.
6.3.4. Attacks Against the ALC/LCT Parameters
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 one can lead the receiver to prematurely close the session.
Similarly, sending forged ALC packets with the Close Object flag (B)
set one can lead the receiver to prematurely give up the reception of
an object.
Roca & Adamson Expires April 3, 2009 [Page 21]
Internet-Draft FCAST: Scalable Object Delivery September 2008
It is therefore RECOMMENDED that measures be taken to guarantee the
integrity and to check the sender's identity of each ALC packet
received. To that purpose, one of the counter-measures mentioned
above (Section 6.2.2) SHOULD be used.
6.3.5. Attacks Against the Associated Building Blocks
Let us first focus on the congestion control building block that may
be used in the ALC 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.
When congestion control building block is applied with FCAST, it is
therefore RECOMMENDED that receivers be required to identify
themselves as legitimate before they receive the Session Description
needed to join the session. How receivers identify themselves as
legitimate is outside the scope of this document. If authenticating
a receiver does not prevent this latter to launch an attack, it will
enable the network operator to identify him and to take counter-
measures.
When congestion control building block is applied with FCAST/ALC, it
is also RECOMMENDED that a packet level authentication scheme be
used, as explained in Section 6.2.2. Some of them, like TESLA, only
provide a delayed authentication service, whereas congestion control
requires a rapid reaction. It is therefore RECOMMENDED [2] 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 since no congestion actually
occurred. 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 reduce the probability of this
attack.
6.4. Other Security Considerations
Lastly, we note that the security considerations that apply to, and
are described in, ALC [2], LCT [3] and FEC [4] 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.
Roca & Adamson Expires April 3, 2009 [Page 22]
Internet-Draft FCAST: Scalable Object Delivery September 2008
7. IANA Considerations
This document requires a IANA registration for the following
attributes:
Object meta-data format (MDFmt): All implementations MUST support
format 0 (default).
+----------------------------------------+-------------+
| format name | Value |
+----------------------------------------+-------------+
| as per HTTP/1.1 metainformation format | 0 (default) |
+----------------------------------------+-------------+
Object Meta-Data Encoding (MDENC): All implementations MUST support
value 0 (default).
+------------+-------------+
| Name | Value |
+------------+-------------+
| plain text | 0 (default) |
| gzip | 1 |
+------------+-------------+
8. Acknowledgments
The authors are grateful to the authors of [ALC_00] for specifying
the first version of FCAST/ALC.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RMT-PI-ALC]
Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", Work
in Progress, November 2007.
[RMT-BB-LCT]
Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", Work in Progress,
July 2008.
Roca & Adamson Expires April 3, 2009 [Page 23]
Internet-Draft FCAST: Scalable Object Delivery September 2008
[RMT-PI-NORM]
Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", Work in Progress, May 2008.
[RMT-FLUTE]
Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca,
"FLUTE - File Delivery over Unidirectional Transport",
Work in Progress, October 2007.
9.2. Informative References
[ALC_00] Luby, M., Gemmell, G., Vicisano, L., Crowcroft, J., and B.
Lueckenhoff, "Asynchronous Layered Coding: a Scalable
Reliable Multicast Protocol",
draft-ietf-rmt-pi-alc-00.txt, March 2000.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
Randers-Pehrson, "GZIP file format specification version
4.3", RFC 1952, May 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Appendix A. FCAST Examples
Roca & Adamson Expires April 3, 2009 [Page 24]
Internet-Draft FCAST: Scalable Object Delivery September 2008
A.1. Basic Examples
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| 0 | 0 | 37 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. meta-data ASCII null terminated string (33 bytes) .
. .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Compound Object Example
Figure 3 shows a regular compound object where the meta-data ASCII
string, in HTTP/1.1 meta-information format contains:
Content-Location: example.txt <CR-LF>
This string is 33 bytes long, including the NULL-termination
character. There is no gzip encoding of the meta-data (Z=0) and
there is no Content-Length information either since this length can
easily be calculated by the receiver as the FEC OTI transfer length
minus the header length.
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| 0 | 0 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Compound Object Example with no Meta-Data.
Figure 4 shows a compound object without any meta-data. The fact
there is no meta-data is indicated by the value 3 of the Header
Length field.
Figure 5 shows an example CIO object, in the case of a static FCAST
session, i.e., a session where the set of objects is set once and for
all.
Roca & Adamson Expires April 3, 2009 [Page 25]
Internet-Draft FCAST: Scalable Object Delivery September 2008
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 |1| 0 | 0 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object List string .
. .
. +-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example of CIO, in case of a static session.
The object list contains the following string:
1,2,3,100-104,200-203,299
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 CIO. The session being static the sender did not
feel the necessity to carry a Carousel Instance ID meta-data.
A.2. FCAST/NORM with NORM_INFO Examples
In case of FCAST/NORM, the meta-data (or a subset of it) can be
carried as part of a NORM_INFO message. In the following example we
assume that the whole meta-data is carried in such a message for a
certain object.
The NORM_INFO message is the following... TODO
Note that this message contains the EXT_FTI header extension to carry
the FEC OTI. Two alternatives would have been to either include FEC
OTI directly in the meta-data part of the NORM_INFO message, or to
include an EXT_FTI header extension to all NORM_DATA packets (or a
subset of them).
The FCAST compound object does not contain any meta-data and is
formatted as in >Figure 4.
Roca & Adamson Expires April 3, 2009 [Page 26]
Internet-Draft FCAST: Scalable Object Delivery September 2008
Authors' Addresses
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/~roca/
Brian Adamson
Naval Research Laboratory
Washington, DC 20375
USA
Email: adamson@itd.nrl.navy.mil
URI: http://cs.itd.nrl.navy.mil
Roca & Adamson Expires April 3, 2009 [Page 27]
Internet-Draft FCAST: Scalable Object Delivery September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Roca & Adamson Expires April 3, 2009 [Page 28]