<------------------------ Compound Object ----------------------->
+-------------------------+--------------------------------------+
|       FCAST Header      |              Object Data             |
| (can include meta-data) |       (can be encoded by FCAST)      |
+-------------------------+--------------------------------------+

Figure 3: Compound Object composition.

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.

Appendix B describes extensions that provide additional means to carry meta-data, e.g., to communicate meta-data ahead of time.

3.3. Meta-Data Content

        Content-Encoding: gzip  

The following meta-data types are defined in [RFC2616]:

• Content-Location: the URI of the object, which gives the name and location of the object;
• Content-Type: a string that contains the MIME type of the object;
• 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;
• Content-Encoding: a string that contains the optional encoding of the object performed by FCAST. For instance: [RFC1952]. If there is no Content-Encoding entry, the receiver MUST assume that FCAST did not modify the original encoding of the object (default).

The following additional meta-data type is defined to check object integrity:

• Fcast-Obj-Digest-SHA256: a string that contains the "base64" [RFC4648] encoding of the SHA-256 message digest of the object [RFC3174][RFC6234], before any content encoding is applied (if any) and without considering the FCAST Header. This digest is meant to protect from transmission and processing errors, not from deliberate attacks by an intelligent attacker (see Section 5). This digest only protects the object, not the header, and therefore not the meta-data. A separate checksum is provided to that purpose (Section 2.1);
• 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);

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:

• 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;
• Fcast-Obj-Slice-Idx: an unsigned 32-bit integer that contains the slice index (in the {0 .. SliceNb - 1} interval);
• Fcast-Obj-Slice-Offset: an unsigned 64-bit integer that contains the offset at which this slice starts within the original object;

Future standards actions can extend the set of meta-data types supported by FCAST.

3.4. Carousel Transmission

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.

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 (Section 3.5) 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).

3.5. Carousel Instance Descriptor Special Object

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 Section 2.2.

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 Figure 1) 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).

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:

• 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;
• 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;
• The TOI equivalence (Section 3.6) is signaled within the CID.

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:

• all the previously sent objects have been removed from the carousel. It therefore improves the FCAST robustness even during "idle" period;
• 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;

3.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 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.

There are several differences between ALC and NORM:

• 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);
• the NORM use of TOI is more directive, since the TOI field is 16 bit long and since TOIs MUST be managed sequentially;

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. 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.

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. Section 2.2 details how to describe these TOI equivalences.

3.7. FCAST Sender Behavior

This section provides an informative description of expected FCAST sender behavior. The following operations can 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 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);
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 CID 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 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.
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 contrary wants to remove old objects from the carousel. In that case a new carousel instance must be created.
7. If the session is not finished, then continue at Step 1 above;

3.8. FCAST Receiver Behavior

This section provides an informative description of expected FCAST receiver behavior. The following operations can take place at a receiver:

1. The receiver joins the session and collects incoming packets;
2. 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;
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 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;
5. 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;
6. 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;
7. Otherwise continue at Step 2 above.

4. Requirements for Compliant Implementations

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.

4.1. Requirements Related to the Object Meta-Data

Meta-data transmission mechanisms:

Meta-data format and encoding:

Meta-data items (Section 3.3):

4.2. Requirements Related to the Carousel Instance Descriptor (CID)

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.

CID-specific Meta-data items (Section 2.2):

5. Security Considerations

5.1. Problem Statement

A content delivery system may be subject to attacks that target:

• the network, to compromise the delivery infrastructure (e.g., by creating congestion),
• the Content Delivery Protocol (CDP), to compromise the delivery mechanism (i.e., FCAST in this case), or
• the content itself, to corrupt the objects being transmitted.

These attacks can be launched against all or any subset of the following:

• against the data flow itself (e.g., by sending forged packets),
• 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
• against some associated building blocks (e.g., the congestion control component).

More details on these possible attacks are provided in the following sections along with possible counter-measures. Recommendations are made in Section 5.5.

5.2. Attacks Against the Data Flow

The following types of attacks exist against the data flow:

• attacks that are meant to gain unauthorized access to a confidential object (e.g., obtaining non-free content without purchasing it) and
• 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)).

5.2.1. Attacks Meant to Gain Access to Confidential Objects

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 [RFC4303] (Section 5.5). These two techniques can also provide confidentiality to the objects being transferred.

If access control and/or confidentiality services are desired, one of these mechanisms is RECOMMENDED and SHOULD be deployed.

5.2.2. Attacks Meant to Corrupt Objects

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:

• at the object level, the object can be digitally signed, for instance by using RSASSA-PKCS1-v1_5 [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;
• at the packet level, each packet can be digitally signed [RFC6584]. A major limitation is the high computational and transmission overheads that this solution requires;
• at the packet level, a Group Message Authentication Code (MAC) [RFC2104][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;
• at the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082][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;
• at the packet level, IPsec/ESP [RFC4303] can be used to check the integrity and authenticate the sender of all the packets being exchanged in a session (see Section 5.5).

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.

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).

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. Section 5.5 defines minimum security recommendations that can be used to provide such services.

5.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:

• the attack can target the session description,
• the attack can target the FCAST CID,
• the attack can target the meta-data of an object,
• the attack can target the ALC/LCT parameters, carried within the LCT header or
• the attack can target the FCAST associated building blocks, for instance the multiple rate congestion control protocol.

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.

5.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 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.

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.

5.3.2. Attacks Against the FCAST CID

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.

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 (Section 5.2.2) 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.

5.3.3. Attacks Against the Object Meta-Data

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.

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 5.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.

5.3.4. Attacks Against the ALC/LCT and NORM 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 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.

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 (Section 5.2.2) SHOULD be used.

5.3.5. Attacks Against the Associated Building Blocks

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.

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.

When congestion control is applied with FCAST, it is also RECOMMENDED that a packet level authentication scheme be used, as explained in Section 5.2.2. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction. It is therefore RECOMMENDED [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.

5.4. Other Security Considerations

Lastly, we note that the security considerations that apply to, and are described in, ALC [RFC5775], LCT [RFC5651], NORM [RFC5740] and FEC [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 [I-D.ietf-rmt-sec-discussion] also applies here.

5.5. Minimum Security Recommendations

We now introduce a mandatory to implement but not necessarily to use security configuration, in the sense of [RFC3365]. Since FCAST/ALC relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [RFC5775]. Similarly, since FCAST/NORM relies on NORM, it inherits the "baseline secure NORM operation" of [RFC5740]. Therefore, IPsec/ESP in transport mode MUST be implemented, but not necessarily used, in accordance to [RFC5775] and [RFC5740]. [RFC4303] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti-replay and (limited) traffic flow confidentiality. [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.

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.

6. Operational Considerations

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 5).

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 type.

The delivery service provided by FCAST 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).

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.

The content of a carousel instance MAY be described by means of an OPTIONAL Carousel Instance Descriptor (CID) (Section 3.5). 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.

7. IANA Considerations

This specification requires IANA to create three new registries.

7.1. Creation of the FCAST Object Meta-Data Format Registry

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 Section 2.1).

The initial value for this registry is defined below. Future assignments are to be made through Expert Review with Specification Required [RFC5226].

7.2. Creation of the FCAST Object Meta-Data Encoding Registry

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 Section 2.1).

The initial values for this registry are defined below. Future assignments are to be made through Expert Review [RFC5226].

7.3. Creation of the FCAST Object Meta-Data Types Registry

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 [RFC1952]. The initial values are those described in Section 3.3 of this specification. This table summarizes those initial registry entries. Future assignments are to be made through Expert Review [RFC5226].

8. Acknowledgments

The authors are grateful to the authors of [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.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. FCAST Examples

This appendix provides informative examples of FCAST Compound Objects and Carousel Instance Descriptor formats.

A.1. Simple Compound Object Example

 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                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Content-Location: example_1.txt<CR-LF>
  

 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                             .
.                                                               .
.               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.               |
+-+-+-+-+-+-+-+-+

Fcast-CID-Complete: 1<CR-LF>

1,2,3,100-104,200-203,299
  

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
+-+-+-+-+-+-+-+-+                                                 --