Internet Engineering Task Force                                 RMT WG
INTERNET-DRAFT                                  M.Luby/Digital Fountain
draft-ietf-rmt-bb-lct-01.txt
draft-ietf-rmt-bb-lct-02.txt                     J.Gemmell/Microsoft
                                                        L.Vicisano/Cisco
                                            L.Rizzo/ACIRI and Univ. Pisa
                                                         M.Handley/ACIRI
                                                        J. Crowcroft/UCL
							    19 July
                                                         18 October 2001
                                                     Expires: January April 2002

                       Layered Coding Transport:
     A massively scalable content delivery transport building block

Status of this Document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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 valid for a maximum of six months and MAY 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 a "work in progress".

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

This document is a product of the IETF RMT WG.  Comments should be
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.

                                Abstract

     This document describes Layered Coding Transport, a massively
     scalable reliable content delivery and stream delivery

^L
     transport, hereafter referred to as LCT.  LCT can be used for
     multi-rate delivery to large sets of receivers.  In LCT,
     scalability and congestion control are supported through the
     use of layered coding techniques. Coding techniques can be
     combined with LCT to provide support for reliability.

     Congestion control is receiver driven, and is can be achieved by
     sending packets in the session to multiple ``LCT channels'',
     and having receivers join and leave LCT channels (thus
     adjusting their reception rate) in reaction to network
     conditions in a manner that is network friendly.

^L

                           Table of Contents

     1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
      1.1. Related Documents. . . . . . . . . . . . . . . . . . 6
      1.2. Environmental Requirements and Considerations. . . .   6 7
     2. General Architecture. . . . . . . . . . . . . . . . . .   8 9
      2.1. Delivery service models. . . . . . . . . . . . . . . 10
      2.2. Congestion Control . . . . . . . . . . . . . . . . .  11 12
     3. LCT packets header. . . . . . . . . . . . . . . . . . . . . . .  11 12
      3.1. Default LCT packet header format. . . . . . . . . . . . . . . . . . 12
      3.2. LCT packet header fields . . . . . . . . . . . . . .  13
      3.3. Header-Extension Fields. . . . . . . . . . . . . . .  16 18
     4. Procedures. . . . . . . . . . . . . . . . . . . . . . .  19 21
      4.1. Sender Operation . . . . . . . . . . . . . . . . . .  19 21
      4.2. Receiver Operation . . . . . . . . . . . . . . . . .  21 23
     5. Security Considerations . . . . . . . . . . . . . . . .  22 24
     6. IANA Considerations . . . . . . . . . . . . . . . . . .  22 24
     7. Intellectual Property Issues. . . . . . . . . . . . . .  22 24
     8. Acknowledgments . . . . . . . . . . . . . . . . . . . .  23 25
     9. Authors' Addresses. References. . . . . . . . . . . . . . . . . . .  24 . . . . 25
     10. Authors' Addresses . . . . . . . . . . . . . . . . . . 26
     11. Full Copyright Statement . . . . . . . . . . . . . . .  26

^L 28

1.  Introduction

This document describes a massively scalable reliable content delivery
and stream delivery transport, Layered Coding Transport (LCT), for
multi-rate content delivery primarily designed to be used with the IP
multicast network service, but MAY may also be used with other basic
underlying network or transport services such as unicast UDP.  LCT
supports both reliable and unreliable delivery, and supports congestion
control mechanisms which conform to RFC2357. delivery.

LCT is a building block as defined in RFC3048.	Complete protocol  Protocol instantiations MAY
may be built by combining the LCT framework with other components.  A
complete protocol instantiation that uses LCT MUST must include a congestion
control protocol that is compatible with LCT and that conforms to
RFC2357.  A complete protocol instantiation that uses LCT MAY may include a
scalable reliability protocol that is compatible with LCT, it MAY may
include an session control protocol that is compatible with LCT, and it MAY
may include other protocols such as security protocols.

LCT is presumed to be used with an underlying network or transport
service that is a "best effort" service that does not guarantee packet
reception, packet reception order, and which does not have any support
for flow or congestion control. For example, the Any-Source Multicast
(ASM) model of IP multicast as defined in RFC1112 is such a "best
effort" network service.  While the basic service provided by RFC1112 is
largely scalable, providing congestion control or reliability should be
done carefully to avoid severe scalability limitations, especially in
presence of heterogeneous sets of receivers.

Scalability refers to the behavior of the protocol

Packets with LCT headers are carried in relation to LCT channels. An LCT channel is
defined by the
number combination of receivers and network paths, their heterogeneity, a sender and an address associated with
the
ability channel by the sender.  A receiver may join a channel to accommodate dynamically variable sets of receivers.
Scalability limitations can come from memory or processing requirements,
or from start
receiving the amount of packet traffic generated data packets sent to the channel by the protocol.  In
turn, such limitations sender, and a
receiver may be leave a consequence of channel to stop receiving data packets from the features that
channel.

An LCT session consists of a
complete reliable content delivery set of logically grouped LCT channels
associated with a single sender carrying packets with LCT headers for
one or stream delivery protocol is
expected more objects.  Congestion control that conforms to provide. RFC2357 must
be used between receivers and the sender for each LCT session.
Congestion control refers to the ability of the protocol to adapt its throughput to the
available bandwidth on the path to from the receivers, sender to a receiver, and to
share bandwidth fairly with competing flows such as TCP. It is
REQUIRED that protocols implement some form Thus, the total
flow of congestion control on packets flowing to each receiver participating in an LCT session so that they
must not compete unfairly with existing and flow adaptive protocols such as
TCP.

A multi-rate or a single-rate congestion control protcol can be used
with LCT.  For multi-rate protocols, a session typically consists of

more than one channel and the sender typically sends packets at a
constant aggregate rate to multiple channels, but individual receivers
adjust which portion of these packets they attempt to receive by

^L

adjusting which set of the channels they are joined to in
the session at each point rates that do not depend on the receivers.  Each receiver
adjusts its reception rate during its participation in time the session by
joining and leaving channels dynamically depending on the available
bandwidth between the receiver and to the
sender, but sender independent of all other receivers.  Thus, for
multi-rate protocols, the packet reception rate of each receiver may vary
dynamically according to the available bandwidth between each receiver
and the sender, independent of the other receivers.

For single-rate protocols, a session typically consists of one channel
and the sender typically sends packets to one the channel at variable rates over time
depending on feedback from receivers, and all receivers
attempt receivers. Each receiver remains joined to receive all packets transmitted by
the sender at all points channel during its participation in time. the session.  Thus, for single-rate single-
rate protocols, the packet reception rate of
all receivers each receiver may vary dynamically over time
but in exactly the same way
dependent on the feedback of other receivers to the sender. coordination with all receivers. Generally, a multi-rate
protocol is preferable to a single-rate protocol in a heterogeneous
receiver environment, but only if it can be achieved without sacrificing
scalability.  Some possible multi-rate congestion control protocols are
described in [11] and [1]. A possible single-rate congestion control
protocol is described in [10].

Layered coding refers to the ability to produce a coded stream of
packets that can be split partioned into multiple layers that can be sent to different channels. an ordered set of layers.  The coded stream can be generated either from a fixed piece coding
is meant to provide some form of content,
or from an ongoing data stream, reliability, and has the property that layering is meant
to allow the quality
experienced by a receiver experience  (in terms of quality of playout, or
overall transfer speed) is proportional to vary in a predictable way depending on how
many of the consecutive layers of packets the receiver is joined to.  LCT MAY be combined with a reliability protocol such as
the general class of protocols described in [7]. LCT MUST receiving.

Layered coding can be naturally combined with a multi-rate congestion control protocol that is compliant
control.  For example, the sender could send the packets for each layer
to a separate channel associated with RFC2357, the session, and
this MAY be either single-rate or then receivers
dynamically join and leave channels to adjust their reception rate
according to the multi-rate congestion control over protocol.

Layered coding can also be combined with single-rate congestion control.
For example, the
entire session.  It is most compelling sender could dynamically vary how many layers are sent
to use LCT in conjunction the channel associated with a
layered congestion control protocol such the session as the class rate of protocols
described in [9], and specified in [9], which are multi-rate transmission
varies according to the single-rate congestion control protocols. protocol.

The concept of layered coding was first introduced with reference to
audio and video streams.  For example, the information associated with a
TV broadcast can could be partitioned into three layers, corresponding to
black and white, color, and HDTV quality. Receivers can experience
different quality without the need for the sender to replicate
information in the different layers.

The concept of layered coding can be naturally extended to reliable
content delivery protocols when Forward Error Correction (FEC)
techniques are used for coding the data stream [12] [10] [9] [7] [3] [14] [15]
[1]. [11] [2]. By

using FEC, the data stream is transformed in such a way that
reconstruction of a data object does not depend on the reception of
specific data packets, but only on the number of different packets
received.  As a result, by increasing the number of layers a receiver is
receiving from, the receiver can reduce the transfer time accordingly.
More details on the use of FEC for reliable content delivery can be
found in [6]. [5].  Reliable protocols aim at giving guarantees on the

^L
reliable delivery of data from the sender to the intended recipients.
Guarantees vary from simple packet data integrity to reliable delivery
of a precise copy of a data an object to all intended recipients.  Several
reliable content delivery protocols have been built on top of IP
multicast, but scalability was not a design goal for many of them.  In
some cases, scalability is achieved by introducing changes to routers or
other infrastructure (see for example [13] ), an approach which has an
impact on near term deployment across the Internet.

Two of the key difficulties in scaling reliable content delivery using
IP multicast are dealing with the amount of data that flows from
receivers back to the sender, and the associated response (generally
data retransmissions) from the sender.  Protocols that avoid any such
feedback, and minimize the amount of retransmissions, can be massively
scalable.  LCT relies on the availability of can be used in conjunction with FEC codes or a layered
codec to achieve reliability with little or no feedback.

Scalability refers to the behavior of the protocol in relation to the
number of receivers and network paths, their heterogeneity, and the
ability to accommodate dynamically variable sets of receivers.
Scalability limitations can come from memory or processing requirements,
or from the amount of packet traffic generated by the protocol. In
turn, such limitations may be a consequence of the features that a
complete reliable content delivery or stream delivery protocol is
expected to provide.

In this document we present the architecture and abstract LCT packet header
structure, and illustrate describe its support for multi-rate layered congestion control.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "OPTIONAL" "optional" in this
document are to be interpreted as described in RFC2119.

1.1.  Related Documents

A more in-depth description of the use of FEC

As described in RFC3048, LCT is a building block that is intended to be
used, in conjunction with other building blocks, to help specify a
protocol instantiation. A congestion control building block that uses
the Congestion Control information field within the LCT header must be
used by any protocol instantiation that uses LCT, and other building
blocks may also be used, such as a reliability building block.

A more in-depth description of the use of FEC in Reliable Multicast

Transport (RMT) protocols is given in [6]. [5]. Some of the FEC codecs that
MAY
may be used by in conjunction with LCT for reliable content delivery are
specified in [7]. [6]. The Codepoint field in the LCT reserves opaque header fields is an opaque
field that can be used to transport carry information related to the payload encoding. encoding of
the packet payload.

Implementors of protocol instantiations that use LCT MUST must also implement
congestion control in accordance to RFC2357, where the congestion
control is over the entire session.  Some possible schemes are specified
in [9]. [11] and [1]. The Congestion Control Information field in the LCT reserves opaque
header
fields is an opaque field that can is reserved to carry information related
to congestion control.  There may also be used by the congestion control scheme to transport Header
Extension fields that carry additional information related to congestion
control.

Generic Router Assist may be used in conjunction with LCT.

It is RECOMMENDED recommended that LCT implementors use some packet authentication
scheme to protect the protocol from attacks. An example of a possibly
suitable scheme is described in [11]. [8].

1.2.  Environmental Requirements and Considerations

LCT is intended for congestion controlled, multi-rate controlled delivery of objects and
streams (both reliable content delivery and streaming of

^L multimedia
information).

LCT is most applicable for delivery of objects or streams of substantial
length, i.e., objects or streams that range in length from hundreds of
kilobytes to many gigabytes, and whose transfer time is in the order of
tens of seconds or more.

LCT is directly applicable can be used with both multicast and unicast delivery.  LCT requires
connectivity between a sender and receivers, but does not require
connectivity from receivers to a sender.  LCT inherently works with all multicast enabled
types of networks, including LANs, WANs, Intranets, the Internet,
asymmetric networks, wireless networks, and satellite networks. Thus,
the inherent raw scalability of LCT is unlimited.  However, when other
specific applications are built on top of LCT, then these applications
by their very nature may limit scalability.  For example, if an
application requires receivers to retrieve out of band information in
order to join a session, or an application allows receivers to send
requests back to the sender in order to extend an ongoing session, report reception statistics, then the
scalability of the application is limited by the ability to send,
receive, and process this additional data.

LCT requires that the underlying network or transport layer can deliver receivers to be able to uniquely identify and demultiplex LCT
packets for a given LCT session, and supply packet
length information to the associated with an LCT receiver. session. In IP networks, this particular, there must be a

Transport Session Identifier (TSI) associated with each LCT session.
The TSI is often
achieved scoped by using UDP, or any protocol that can provide an equivalent
service, as the underlying transport protocol.

In IP address of the sender, and the IP address of
the sender together with the TSI must uniquely identify the session.  If
the underlying transport is UDP as described in RFC768, then the 16 bit
UDP source port number may serve as the TSI for the session.  If Generic
Router Assist (GRA) is being used then additional dependencies may be
introduced by GRA on the TSI field.  GRA work is ongoing within the RMT
working group at this document, we refer to time.  The TSI value must be the original same in all
places it occurs within a packet.  If there is no underlying TSI
provided by the network, transport or any other layer, then the TSI must
be included in the LCT header.

There are currently two models of multicast service delivery, the Any-Source
Multicast (ASM) model as defined in RFC1112 as Any-Source Multicast, or ASM for short.  We refer
to and the multicast service Source-Specific
Multicast (SSM) model as defined in [5] as Source-Specific
Multicast, or SSM for short.  LCT does not require reverse multicast
connectivity, i.e. LCT receivers do not send multicast traffic.  As
such, [4]. LCT works with both ASM and SSM.

The definition of an LCT channel used throughout this document is multicast
models, but in a slightly different way with ASM and with SSM. somewhat different
environmental concerns. When using ASM, a sender S sends LCT packets to a
multicast group G, and the LCT channel address consists of the pair
(S,G), where S is the IP address of the sender and G is a multicast
group address.  When using SSM, a sender S sends LCT packets to an SSM
channel (S,G), and the LCT channel address coincides with the SSM
channel address.

SSM is more attractive to deployment of LCT than ASM for several
reasons.  First, a sender may allocate and use several LCT channels in a
session, sessions may come and go dynamically.

A sender can locally allocate unique SSM channel addresses, and this
makes allocation of LCT channel addresses easy with SSM.  To allocate
LCT channel addresses using ASM, the sender must uniquely chose the ASM
multicast group address across the scope of the group, and this makes
allocation of LCT channel addresses more difficult with ASM.

^L

In general

LCT channels and SSM performs well even in presence of very large channels coincide, and
dynamically changing thus the receiver sets.  Changes in will only
receive packets sent to the multicast tree
topology with SSM are light weight operations (a new branch from requested LCT channel.  With ASM, the
receiver towards S grows when joins an LCT channel by joining a receiver joins, multicast group G, and the branch is
deleted when the receiver leaves), whereas with ASM changes can be
heavier weight (involving transitions from a (*,G)-tree rooted at an RP
to the tree rooted at S).  This efficiency is important when a
congestion control protocol is used with LCT that relies upon joining
and leaving channels to nimbly increase and decrease reception rate.

LCT channels and SSM channels coincide, and thus the receiver will only
receive packets sent to the requested LCT channel.  With ASM, the
receiver joins an LCT channel by joining a multicast group G, and all
packets sent to G, regardless of all
packets sent to G, regardless of the sender, may be received by the
receiver.  In either case, receivers should use mechanisms to filter out
packets from unwanted sources.  Thus, SSM has compelling security advantages over ASM for
prevention of denial of service attacks.  In either case, receivers
should use mechanisms to filter out packets from unwanted sources.

LCT also requires receivers to obtain Session Description Information
before joining a session, Information,
as described in Section 4.1. The session description could be in a form
such as SDP as defined in RFC2327, or XML metadata, or HTTP/Mime headers
as defined in RFC2068, and distributed with SAP [4], as defined in RFC2974,
using RCCP [8], HTTP, or in other ways.

The particular layered encoder and congestion control protocols used
with LCT have an impact on the performance and applicability of LCT.
For example, some layered encoders used for video and audio streams can
produce a very limited number of substreams, layers, thus providing a very coarse
control in the reception rate of packets by receivers in a session.

When LCT is used for reliable data transfer, some FEC codecs are
inherently limited in the size of the object they can encode, and for
objects larger than this size the reception overhead on the receivers
can grow substantially.

As another example, some

Some networks are not amenable to some congestion control protocols that
could be used with LCT. In particular, for a satellite or wireless
network, there may be no mechanism for receivers to effectively reduce
their reception rate since there may be a fixed transmission rate
allocated to the session.

Some protocol instantiations that use LCT may require the generation of
feedback from the receivers to the sender.  For example, Generic Router
Assist may be used to help in passing real-time statistics in a scalable
manner from receivers back to the sender. However, the mechanism for
doing this is outside the scope of LCT.

2.  General Architecture

An LCT session comprises all LCT packets sent to a logically related set of one or more LCT
channels from originating at a single sender, and sender that are used for some period of
time to carry packets containing LCT headers pertaining to the
transmission of one or more objects that can be of interest for the to
receivers.

For example, an LCT session could be used to deliver a TV channel program using

^L
three LCT channels.  Receiving packets from the first LCT channel could
allow black and white reception, receiving the first two LCT channels would
could also permit color reception, whereas receiving the set of all three channels delivers
could allow HDTV quality images. reception.  Objects in this example could
correspond to individual TV programs (movies, news, commercial) being transmitted.

As another example, a reliable LCT session could be used to reliably
deliver hourly-updated weather maps (objects) using ten LCT channels at
different rates, using FEC coding.  A receiver MAY may join and concurrently
receive LCT packets from subsets of these channels, until it has enough
packets in total to recover the object, then leave the session (or
remain there connected listening to control for session description information only)
until it is time to receive the next object.  In this case, the quality
metric is the time required to receive each object.

Before joining a session, the receivers MUST must obtain a enough of the
session
description, which MUST description to start the session.  This must include the
relevant session parameters needed by a receiver to participate in the session.
session, including all information relevant to congestion control.  The
session description is determined and agreed upon by the senders, sender, and is typically
communicated to the receivers out of band. In some cases, part of the as described

later, parts of the session description MAY that are not required to
initiate a session may be included in the LCT packet. header or communicated to
a receiver out of band after the receiver has joined the session.

An encoder MAY may be used to generate the data that is placed in the LCT packet
payload in order to provide reliability.  A suitable decoder is used to
reproduce the original information from the packet payload.  There MAY may
be a reliability packet header that follows the LCT packet header if such an encoder
and decoder is used.  The reliability packet header helps to describe the
encoding data carried in the payload of the packet.  The format of the
reliability packet header depends on the coding used, and this is negotiated
out-of-band.  As an example, one of the FEC packet headers described in [7] [6]
could be used.

For LCT, when layered multi-rate congestion control is used, congestion control
is achieved by sending LCT packets associated with a given session to
several LCT channels.  Individual receivers dynamically join one or more
of these channels, according to the network congestion as seen by the
receiver.  LCT packet headers include an opaque field which MUST must be used to
convey congestion control information to the receivers. The actual
congestion control scheme to use with LCT is negotiated out-of-band.
Some examples of congestion control protocols that MAY may be suitable for
content delivery are described in [9]. [11] and [1]. Other congestion
controls MAY may be suitable when LCT is used for a streaming application.

LCT can be used with other congestion control protocols such as the one
described in [14], [11], or router-assisted Generic Router Assist schemes where the selection
of which packets to forward is performed by routers. This latter
approach potentially allows for finer grain congestion control and a
faster reaction to network congestion, but requires changes to the
router

^L infrastructure.  See [2] for a preliminary design description.  We do not discuss this approach further in this
document.

2.1.  Delivery service models

LCT can support several different delivery service models. Two examples
are briefly described here.

Push service model.

One way a push service model can be used for reliable content delivery
is to deliver a series of objects.  For example, a receiver could join
the session and dynamically adapt the number of LCT channels the
receiver is joined to until enough packets have been received to
reconstruct an object. After reconstructing the object the receiver may
stay in the session and wait for the transmission of the next object.

The push model is particularly attractive in satellite networks and
wireless networks.  In these cases, a session may consist of one fixed
rate LCT channel.

On-demand content delivery model.

For an on-demand content delivery service model, senders typically
transmit for some given time period selected to be long enough to allow
all the intended receivers to join the session and recover the object.
For example a popular software update might be transmitted using LCT for
several days, even though a receiver may be able to complete the
download in one hour total of connection time, perhaps spread over
several intervals of time.

In this case the receivers join the session, and dynamically adapt the
number of LCT channels they subscribe to (and the reception quality)
according to the available bandwidth. Receivers then drop from the
session when they have received enough packets to recover the object.

As an example, assume that an object is 50 MB.  The sender could set the
data rate on send 1
KB packets to the lowest first LCT channel to at 50 1KB packets per second, so that
receivers using just this LCT channel could complete reception of the
object in 1,000 seconds in absence of loss, and would be able to
complete reception even in presence of some substantial amount of losses
with the use of coding for reliability. Furthermore, the sender could
use a number of LCT channels such that the aggregate data rate when
using of 1 KB
packets to all LCT channels is 1,000 1KB packets per second, so that a
receiver could be able to complete reception of the object in as little

^L
50 seconds (assuming no loss and that the congestion control mechanism
immediately converges to the use of all LCT channels).

Other service models.

There are many other delivery service models that LCT can be used for
that are not covered above.  As examples, a live streaming or an on-
demand archival content streaming service model.  The description of the
many potential applications, the appropriate delivery service model, and
the additional mechanisms to support such functionalities when combined
with LCT is beyond the scope of this document.  This document only
attempts to describe the minimal common scalable elements to these
diverse applications using LCT as the delivery transport.

2.2.  Congestion Control

The specific congestion control protocol to be used for LCT sessions
depends on the type of content to be delivered. While the general
behavior of the congestion control protocol is to reduce the throughput
in presence of congestion and gradually increase it in the absence of
congestion, the actual dynamic behavior (e.g. response to single losses)
can vary.

Some possible congestion control protocols for reliable content delivery
using LCT are described in [9]. [11] and [1]. Different delivery service
models might require a different congestion control protocols.

3.  LCT packets

The type of packet used by LCT sessions is "LCT Packet".  LCT packets
are header

Packets sent by senders to an LCT channels.

Some instances of session must include an "LCT header".  The LCT sessions MAY require the generation of feedback
from the receivers to the sender.  However,
header format described below is the mechanism for doing default format, and this is outside the scope of LCT.

The LCT packet
format described in this document that is intended recommended for use by protocol instantiations to ensure
a uniform format across different protocol instantiations.  Other LCT
header formats may be used
in conjunction with by protocol instantiations, but if the UDP transport
default LCT header format is not used by a protocol as defined in RFC768 or
other transport protocols insantiation that satisfy
uses LCT, then the requirements stated in
Section 1.2, specifically about demultiplexing protocol instantiation must specify the lengths and delivery of packet
size information.

LCT packets consist of an
positions within the LCT packet header and an OPTIONAL LCT packet
payload, as shown it uses of all fields described in Figure 1.	When present, the LCT packet payload

^L

immediately follows the
default LCT packet header.  The LCT packet payload MAY
contain headers for other protocols, such

Other building blocks may describe some of the same fields as reliability protocols. described
for the LCT packet headers have variable header.  It is recommended that protocol instantiations
using multiple building blocks include shared fields at most once in
each packet.  Thus, for example, if another building block is used with
LCT that includes the optional Expected Residual Time field, then the
Expected Residual Time field should be carried in each packet at most
once.

The position of the LCT header within a packet must be specified by any
protocol instantiation that uses LCT.

3.1.  Default LCT header format

The default LCT header is of variable size, which is specified by a
length field in the third byte of the header.  In the LCT packet header, all
integer fields are carried in "big-endian" or "network order" format,
that is, most significant byte (octet) first.  Bits designated as
"padding" or "reserved" (r) MUST must by set to 0 by senders and ignored by
receivers.  Unless otherwise noted, numeric constants in this
specification are in decimal (base 10).

3.1.  LCT packet format

The format of the default LCT packets header is depicted in Figure 1.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   V	 |   |C|  r    | I |S|E|X|A|B|  |H|S| O |T|R|A|B|   HDR_LEN     | Codepoint (CP)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Congestion Control Information (CCI)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |	  Transport Object Identifier (TOI, if I >= 1)		 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		  TOI                 CCI continued (if I >= 2) C = 1)                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		  TOI continued  (if I  Transport Session Identifier (TSI, length = 3) 32*S+16*H bits)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		  TOI continued  (if I                         ...                                   |
 +                                                               +
 |   Transport Object Identifier (TOI, length = 3) 32*O+16*H bits)  |
 |                         ...                                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Sender Current Time (SCT, if S T = 1)             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Expected Residual Time (ERT, if E R = 1)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Header Extensions (if X = 1 ) 		 |
 |								 |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |								 |
 |			    Payload applicable)               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 - Default LCT packet format

^L

3.2.  LCT packet header fields format

The function and length of each field in the default LCT packet headers header is the
following.  Fields marked as "1" mean that the corresponding bits MUST must
be set to "1" by the
generating agent. sender.  Fields marked as "r" or "0" mean that the
corresponding bits MUST must be set to "0" by the generating agent. sender.

  LCT version number (V): 4 bits

      Indicates the LCT protocol version. version number. The LCT version number for this
      specification is 0.

  Congestion control flag (C): 1 bit

      C=0 indicates the Congestion Control Information (CCI) field is
      32-bits in length.
      C=1 indicates the CCI field is 64-bits in length.

  Reserved (r): 5 3 bits

      Reserved for future use. A sender MUST must set these bits to zero and
      a receiver MUST must ignore these bits.

  Transport Object Identifier

  Half-word flag (I): 2 (H): 1 bit

      The TSI and the TOI fields are both multiples of 32-bits plus 16*H
      bits

      I=0 indicates no Transport Object Identifier (TOI) field is
      present.
      I=1 indicates that a 32-bit in length.  This allows the TSI and TOI field is present.
      I=2 indicates that lengths to be
      multiples of a 64-bit half-word (16 bits), while ensuring that the
      aggregate length of the TSI and TOI field fields is present.
      I=3 indicates that a 128-bit TOI field multiple of
      32-bits.

  Transport Session Identifier flag (S): 1 bit

      This is present. the number of full 32-bit words in the TSI field. The TOI TSI
      field indicates which object within is 32*S + 16*H bits in length, i.e. the session this LCT
      packet pertains to. length is either 0
      bits, 16 bits, 32 bits, or 48 bits.

  Transport Object Identifier flag (O): 2 bits

      This is the number of full 32-bit words in the TOI field. The TOI
      field is 32*O + 16*H bits in length, i.e., the length is either 0
      bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112
      bits.

  Sender Current Time present flag (S): (T): 1 bit

      S

      T = 0 indicates that the Sender Current Time (SCT) field is not
      present.
      S
      T = 1 indicates that the SCT field is present.
      The SCT is inserted by senders to indicate to receivers how long
      the session has been in progress.

  Expected Residual Time present flag (E): (R): 1 bit

      E

      R = 0 indicates that the Expected Residual Time (ERT) field is not
      present.
      E
      R = 1 indicates that the ERT field is present.
      The ERT is inserted by senders to indicate to receivers how much
      longer the session / object transmission will continue.
      Senders MUST NOT must not set E R = 1 when the ERT for the session is more

^L
      than 2^32-1 time units (approximately 49 days), where time is
      measured in units of milliseconds.

  Header extension present flag (X): 1 bit

      X = 0 indicates no Header Extensions are present.
      X = 1 indicates that Header Extensions are present.
      Header Extensions are used in LCT to accommodate OPTIONAL header
      fields which are not always used or have variable size.

  Close TOI Session flag (A): 1 bit

      Normally, the Close TOI flag A is set to 0.  The sender MAY may set the
      Close TOI flag A to 1 when
      termination of transmission of LCT packets for the object identified by the TOI session is
      imminent.  The
      Close TOI flag MAY A may be set to 1 in just the last LCT packet transmitted
      for the object, session, or it MAY A may be set to 1 in the last
      couple of few seconds LCT of
      packets transmitted for the object. session.  Once the sender sets the Close TOI flag A to 1
      in one packet for a
      particular object, packet, the sender SHOULD should set the Close TOI flag A to 1 in all subsequent
      packets for the object until termination of transmission of LCT packets for the object.
      session.  A received packet with the Close TOI flag A set to 1 indicates to a
      receiver that the sender will immediately stop sending LCT packets for
      the object
      identified by the TOI. session.  When a receiver receives a packet with the
      Close TOI flag A set to 1 then it
      the receiver should assume that no more LCT packets will be sent to
      the session for this object. session.

  Close Session Object flag (B): 1 bit

      Normally, the Close Session flag B is set to 0.  The sender MAY may set
      the Close Session flag B to 1 when
      termination of transmission of
      LCT packets for the session an object is imminent.	The Close Session flag
      MAY be set to 1 in just the last LCT packet transmitted for
      If the
      session, or it MAY be TOI field is in use and B is set to 1 in the last couple then termination of seconds LCT
      packets transmitted
      transmission for the session.  Once the sender sets object identified by the
      Close Session flag TOI field is
      imminent. If the TOI field is not in use and B is set to 1 then
      termination of transmission for the one object in the session
      identified by out of band information is imminent.  B may be set
      to 1 in just the last packet transmitted for the object, or B may
      be set to 1 in the last few seconds packets transmitted for the
      object.  Once the sender sets B to 1 in one packet, packet for a
      particular object, the sender SHOULD should set the
      Close Session flag B to 1 in all subsequent
      packets for the object until termination of transmission of LCT
      packets for the session. object.  A received packet with the Close Session flag B set to 1
      indicates to a receiver that the sender will immediately stop
      sending LCT packets for the session. object.  When a receiver receives a packet
      with
      the Close Session flag B set to 1 then it should assume that no more
      LCT packets will be
      sent for the object to the session.

^L

  LCT packet header length (HDR_LEN): 8 bits

      Length

      Total length of the LCT packet header in units of 32-bit words
      (excluding IP or UDP headers). words.  The
      length of the LCT header must be a multiple of 32-bits.  This
      field can be used for direct access to directly access the beginning portion of the packet
      beyond the LCT header, i.e., to the first other header if it
      exists, or to the packet payload if it exists and there is no
      other header, or to the end of the packet if there are no other
      headers or packet payload.

  Codepoint (CP): 8 bits

      An opaque identifier which is passed to the packet payload decoder
      to convey information on the codec being used for the packet
      payload. The mapping between the codepoint and the actual codec is
      defined on a per session basis and communicated out-of-band as
      part of the session description information.  The use of the CP
      field is similar to the Payload Type (PT) field in RTP headers as
      described in RFC1889.

  Congestion Control Information (CCI): 32 or 64 bits

      Used to carry congestion control information, e.g. for information.  For example, the
      congestion control specified in [9] or other congestion control
      schemes. information could include layer numbers,
      logical channel numbers, and sequence numbers. This field is
      opaque for the purpose of this specification.
      This field must be 32 bits if C=0.
      This field must be 64 bits if C=1.

  Transport Object Session Identifier (TOI): 32, 64 (TSI): 0, 16, 32 or 128 48 bits (OPTIONAL)

      This field indicates which object within the session this LCT
      packet pertains to.  For example,

      The TSI uniquely identifies a sender might send session among all sessions from a number
      particular sender.  The TSI is scoped by the IP address of
      files in the same session, using TOI=0 for
      sender, and thus the first IP address of the sender and the TSI together
      uniquely identify the session.  Although a TSI in conjunction with
      the IP address of the sender must always uniquely identify a
      session, whether or not the TSI is incuded in the LCT header
      depends on what is used as the TSI value. If the underlying
      transport is UDP, then the 16 bit UDP source port number may serve
      as the TSI for the session.  If Generic Router Assist (GRA) is
      being used then additional dependencies may be introduced by GRA
      on the TSI field. If the TSI value appears multiple times in a
      packet then all occurrences must be the same value.  If there is
      no underlying TSI provided by the network, transport or any other
      layer, then the TSI must be included in the LCT header.

      The TSI must be unique among all sessions served by the sender
      during the period when the session is active, and for a large
      period of time preceding and following when the session is active.
      A primary purpose of the TSI is to prevent receivers from
      inadvertently accepting packets from a sender that belong to
      sessions other than sessions receivers are subscribed to. For
      example, suppose a session is deactivated and then another session
      is activated by a sender and the two sessions use an overlapping
      set of channels.  A receiver that connects and remains connected
      to the first session during this sender activity could possibly
      accept packets from the second session as belonging to the first
      session if the TSI for the two sessions were identical.  The
      mapping of TSI field values to sessions must be done out of band.
      The length of the TSI field is 32*S + 16*H bits.  Note that the
      aggregate lengths of the TSI field plus the TOI field is a
      multiple of 32 bits.

  Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112
  bits.

      This field indicates which object within the session this packet
      pertains to.  For example, a sender might send a number of files
      in the same session, using TOI=0 for the first file, TOI=1 for the
      second one, etc. As another example, the TOI may be a unique
      global identifier of the object that is being transmitted from
      several senders concurrently, and the TOI value may be the ouptut
      of a hash function applied to the object. The mapping of TOI field
      values to objects MUST must be done out of band.
      This  The TOI field MUST NOT must be present
      used in all packets if I=0.
      This field MUST more than one object is to be 32 bits if I=1.
      This transmitted
      in a session, i.e. the TOI field MUST be 64 bits if I=2.
      This is either present in all the
      packets of a session or is never present.
      The length of the TOI field MUST be 128 bits if I=3. is 32*O + 16*H bits.  Note that the
      aggregate lengths of the TSI field plus the TOI field is a
      multiple of 32 bits.

  Sender Current Time (SCT): 0 or 32 bits (OPTIONAL)

      This field represents the current clock at the sender at the time
      this packet was transmitted, measured in units of 1ms and computed
      modulo 2^32 units from the start of the session.
      This field MUST NOT must not be present if S=0 T=0 and MUST must be present if S=1.

^L T=1.

  Expected Residual Time (ERT): 0 or 32 bits (OPTIONAL)

      This field represents the sender expected residual transmission
      time for sender expected residual transmission
      time for the current session or for the transmission of the
      current object, measured in units of 1ms. If the packet containing
      the ERT field also contains the TOI field, then ERT refers to the
      object corresponding to the current session, measured in units of 1ms. TOI field, otherwise it refers to the
      session.
      This field MUST NOT must not be present if E=0 R=0 and MUST must be present if E=1.

3.3. R=1.

3.2.  Header-Extension Fields

To allow for additional header fields and to extend the size of some of
the predefined fields, the LCT packet header contains an additional
header field flag, "X". If "X" is set to 0 then no additional header
fields

Header Extensions are included within the used in LCT packet to accommodate optional header beyond the predefined
fields.  When additional headers beyond the predefined fields
that are used,
the value of "X" within the LCT packet header MUST be set to 1. not always used or have variable size. Examples of the use of
Header Extensions include:

  o Extended-size version versions of already existing header fields.

  o Sender and Receiver authentication information.

The presence of Header Extensions can be inferred by the LCT header
length (HDR_LEN): if HDR_LEN is larger than the length of the standard
header then the remaining header space is taken by Header Extension
fields.

If present, Header Extensions MUST must be processed to ensure that they are
recognized before performing any congestion control procedure or
otherwise accepting an LCT a packet. LCT packets with unrecognised Header
Extensions MUST be discarded by the receiving agent, hence The default action for unrecognized header
extensions is to ignore them. This allows the expected
use future introduction of
backward-compatible enhancements to LCT without changing the LCT version
number. Non backward-compatible header extensions SHOULD CANNOT be signaled out-of-band before session startup. introduced
without changing the LCT version number.

Protocol instantiation may override this default behavior for PI-
specific extensions (see below).

There are two formats for Header Extension fields, as depicted below.
The first format is used for variable-length extensions, with Header
Extension Type (HET) values between 0 and 63. 127. The second format is used
for fixed length (one 32-bit word) extension, extensions, using HET values from 64 127
to 127.

^L 255.

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |L|
 |  HET (<=63) (<=127)  |       HEL     |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 .                                                               .
 .              Header Extension Content (HEC)                   .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |L|
 |  HET (>=64) (>=128)  |       Header Extension Content (HEC)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5 - Format of additional headers

The explanation of each sub-field is the following.

  Last Header Extension (L): 1 bit

      MUST be set to 1 in the last Header Extension field present in an
      LCT packet header, MUST be set to 0 in all the others.

  Header Extension Type (HET): 7 8 bits

      The type of the Header Extension. This document defines a number
      of possible types. Additional types may be defined in future
      version of this specification. HET values from 0 to 63 127 are used
      for variable-length Header Extensions. HET values from 64 128 to 127 255
      are used for fixed-length 32-bit Header Extensions.

  Header Extension Length (HEL): 8 bits

      The length of the whole Header Extension field, expressed in
      multiples of 32-bit words. This field MUST must be present for
      variable-length extensions (HET between 0 and 63) 127) and MUST NOT must not be
      present for fixed-length extensions (HET between 64 128 and 127). 255).

  Header Extension Content (HEC): variable length

^L

      The content of the Header Extension. The format of this sub-field
      depends on the Header Extension type.  For fixed-length Header
      Extensions, the HEC is 24 bits.  For variable-length Header
      Extensions, the HEC field has variable size, as specified by the
      HEL field.  Note that the length of each Header Extension field
      MUST
      must be a multiple of 32 bits.  Also note that the total size of
      the LCT packet header, including all Header Extensions and all
      OPTIONAL optional
      header fields, cannot exceed 255 32-bit words.

An LCT packet with

Header Extensions MUST NOT have space are further divided between general LCT extensions and
Protocol Instantiation specific extensions (PI-specific).  General LCT
extensions have HET in the end
of ranges 0:63 and 128:191 inclusive.  PI-
specific extensions have HET in the last Header Extension ranges 64:127 and 192:255 inclusive.

General LCT extensions are intended to allow the beginning introduction of
backward-compatible enhancements to LCT without changing the LCT packet
payload.

All senders and receivers of version
number. Non backward-compatible header extensions CANNOT be introduced
without changing the LCT packets MUST support version number.

PI-specific extensions are reserved for PI-specific use with semantic
and default parsing actions defined by the EXT_NOP Header
Extension. PI.

The following general LCT Header Extension types are defined:

EXT_NOP=0     No-Operation extension.
              The information present in this extension field MUST must be
              ignored by receivers.

EXT_CCI_V=1   Congestion Control Information extension, variable length.
	      This extension field extends the CCI field present in the
	      fixed part of the header. It is used when the congestion
	      control information does not fit in the 32-bit CCI field.
	      When this option is present, the concatenation of the
	      32-bit CCI field in the fixed part of the header together
	      with the variable length value provided in this option is
	      used as the congestion control information.  The
	      interpretation of the data contained in EXT_CCI_V MUST be
	      negotiated out-of-band.  The use of EXT_CCI_V and
	      EXT_CCI_F is mutually exclusive.

EXT_AUTH=2    Authentication    Packet authentication extension
              Information used to authenticate the sender of the LCT packet.
              If present, the format of this Header Extension and its
              processing MUST must be communicated out-of-band as part of the
              session description.
              It is RECOMMENDED recommended that senders provide some form of
	      authentication on the LCT packets they transmit. packet
              authentication.  If EXT_AUTH is present, whatever packet
              authentication checks that can be performed immediately
              upon reception of the packet
	      MUST must be performed before
              accepting the packet and

^L performing any congestion
              control-related action on it.
              Some packet authentication schemes impose a delay of
              several seconds between when a packet is received and when
              the packet is fully authenticated.  Any congestion control
              related action that is appropriate MUST NOT must not be delayed postponed
              by any such full authentication delay.

EXT_CCI_F=65  Congestion Control Information extension, fixed length.
	      This extension field extends the CCI field present in the
	      fixed part of the header. It is used when packet authentication.

All senders and receivers implementing LCT must support the congestion
	      control information does EXT_NOP
Header Extension and must recognize EXT_AUTH, but may not fit in the 32-bit CCI field.
	      When this option is present, the concatenation of the
	      32-bit CCI field in the fixed part of the header together
	      with the 24-bit fixed length value provided in this option
	      is used as the congestion control information.  The
	      interpretation of the data contained in EXT_CCI_F MUST be
	      negotiated out-of-band.  The use of EXT_CCI_V and
	      EXT_CCI_F is mutually exclusive. able to
parse its content.

4.  Procedures

4.1.  Sender Operation

Before

A sender using LCT must make a session starts, description available to clients
that want to join an LCT sender MUST make available all
applicable information regarding the session.  This information could include, but
is not limited to:

  o The number of LCT channels;

  o The addresses, port numbers and data rates used for each LCT
    channel;

  o The format formats of the payload. any other headers.  For example, the payload an FEC header as
    described in [6] could contain
    other protocol headers be such as an FEC other header.  Then for example
    the information could include the mapping of codepoints used in the
    session to FEC codec types and parameters;

  o The congestion control scheme being used; format and lengths of the packet payload;

  o The possible Header Extensions that could Transport Session ID (TSI) to be used in for the session;

  o Whether or not Generic Router Assist (GRA) is being used;

  o The congestion control scheme being used;

  o The mapping of TOI value(s) to objects for the session;

  o Any information that is relevant to each object being transported,
    such as when it will be available within the session, for how long,
    and the length of the object;

  o The packet authentication scheme being used, and all relevant
    information which is necessary for sender client packet authentication
    purposes;

^L

Some of the session description information must be obtained by
receivers before they connect to the session.  This includes the number
and addresses of the LCT channels, the TSI value for the session, the
formats of any other headers, the congestion control scheme being used
and the packet authentication scheme if it is used.  Some of the session
description information may be obtained by receivers while they are
connected to the session, e.g., information relevant to objects being
transported within the session such as their TOI, when they are
available within the session, for how long, and their lengths.

The session description could be in a form such as SDP as defined in
RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a
session announcement protocol such as SAP [4], as defined in RFC2974,
obtained using RCCP a proprietary session control as described in [8], protocol, located on a Web
page with scheduling information, or conveyed via E-mail or other out of
band methods.  Discussion of session description format, and
distribution of session descriptions is beyond the scope of this
document.

Within an LCT session, an LCT a sender using LCT transmits a sequence of LCT
packets each containing in a payload encoded according to one of the codecs format defined in the session description.  LCT packets  Packets
are sent over from a sender using one or more LCT channels which together
constitute a session.  Transmission rates MAY may be different in different channels.
channels and may vary over time.  The specification of the other
building block headers and the packet payload used by a complete
protocol instantiation using LCT is beyond the scope of this document.
This document does not specify the LCT
packet payload, nor the order in which LCT packets are
transmitted, nor the organization of a session into multiple channels.
Although these issues affect the efficiency of the protocol, they do not
affect the correctness nor the inter-operability of LCT between senders
and receivers.

Multiple objects can be carried within the same LCT session.  In this
case, each object is must be identified by a unique TOI.  Objects MAY may be
transmitted sequentially, or they MAY may be transmitted concurrently.  It
is good practice to only send objects concurrently in the same session
if the receivers that participate in that portion of the session have
interest in receiving all the objects.  The reason for this is that it
wastes bandwidth and networking resources to have receivers receive data
for objects that they have no interest in.

Typically, the sender(s) continues to send LCT packets in a session until
the transmission is considered complete.  The transmission MAY may be
considered complete when some time has expired, a certain number of
packets have been sent, or some out of band signal (possibly from a
higher level protocol) has indicated completion by a sufficient number
of receivers.

The specification of the processing of the payload carried in LCT
packets is beyond the scope of this document.  LCT will act as a
transport layer and convey payload and associated information (Codepoint
and TOI) to the receivers and any complete protocol using LCT will
implement congestion control .

For the reasons mentioned above, this document does not pose any
restriction on LCT packet sizes. However, network efficiency considerations
recommend that the sender uses as large as possible packet payload size,
but in such a way that LCT packets do not exceed the network's maximum
transmission unit size (MTU), or fragmentation coupled with packet loss
might introduce severe inefficiency in the transmission.

It is also RECOMMENDED recommended that all LCT packets have the same or very similar sizes,
as this can have a severe impact on the effectiveness of congestion
control schemes such as the ones described in [9]. [11] and [1].  A sender of LCT

packets MUST using LCT must implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357, RFC2357 using the
Congestion Control Information field provided in the LCT header, and the

^L
corresponding receiver congestion control scheme MUST must be communicated
out of band and implemented by any receivers participating in the
session.

4.2.  Receiver Operation

Receivers can operate differently depending on the delivery service
model.  For example, for an on demand service model receivers MAY may join a
session, obtain the necessary encoding symbols to reproduce the object,
and then leave the session.  As another example, for a streaming service
model a receiver MAY may be continuously joined to a set of LCT channels to
download all objects in a session.

To be able to participate in a session, a receiver MUST must first obtain the
relevant session description information as listed in Section 4.1.

To be able to participate in a session, a receiver MUST implement the
congestion control protocol specified in the session description.

If a
receiver is not able to implement the congestion control protocol used
in the session, it MUST NOT join the session.

If sender packet authentication information is present in an LCT packet header, it MUST
should be used as specified in Section 3.3. If a receiver is unable to
implement the authentication mechanism used by the session, it MUST NOT
join the session. 3.2.  To be able to be a receiver
in a session, the receiver MUST must be able to process the LCT packet header.  The
receiver MUST must be able to discard, forward, store or process the LCT other
headers and the packet payload. If a receiver is not able to process a
LCT packet header, it MUST either must drop from the session.

To be able to participate in a session, or reduce a receiver must implement the receive bandwidth to
congestion control protocol specified in the minimum value allowed by session description using
the Congestion Control Information field provided in the LCT header. If
a receiver is not able to implement the congestion control protocol being used. used
in the session, it must not join the session.  When the session is
transmitted on multiple LCT channels, receivers MUST
do it must initially join
channels according to the specified startup behavior of the congestion
control protocol itself. For a layered transmission on multiple
channels, this typically means that a receiver will initially join only
a minimal set of LCT channels, possibly a single one. one, that in aggregate
are carrying packets at a low rate.  This rule has the purpose of
preventing receivers from starting at high data rates.

Multiple objects can be carried either sequentially or concurrently
within the same LCT session.  In this case, each object is identified by
a unique TOI.  Note that even if a server stops sending LCT packets for an
old object before starting to transmit LCT packets for a new object, both
the network and the underlying protocol layers can cause some reordering
of packets, especially when sent over different LCT channels, and thus
receivers

^L

MUST NOT should not assume that the reception of an LCT a packet for a new
object means that there are no more LCT packets in transit for the previous

one, at least for some amount of time.

A receiver MAY may be concurrently joined to multiple LCT sessions. sessions from one
or more senders. The receiver MUST must perform congestion control on each
such LCT session.  If the congestion control protocol allows the
receiver some flexibility in terms of its actions within a session then
the receiver MAY may make choices to optimize the packet flow performance
across the multiple LCT sessions, as long as the receiver still adheres
to the congestion control rules for each LCT session individually.

5.  Security Considerations

LCT can be subject to denial-of-service attacks by attackers which try
to confuse the congestion control mechanism, or send forged packets to
the session which would prevent successful reconstruction of large
portions of the data stream. objects.

The same exact problems are present in TCP, where an attacker can forge
packets and either slow down or increase the throughput of the session,
or replace parts of the data stream with forged data. If the stream is
carrying compressed or otherwise coded data, even a single forged packet
could also cause incorrect reconstruction of the rest of the data
stream.

It is therefore RECOMMENDED recommended that protocol instantiations that use LCT agents
implement some form of packet authentication to protect themselves
against such attacks.

6.  IANA Considerations

No information in this specification is subject to IANA registration.

Building blocks components used by in conjunction with LCT may introduce additional
IANA considerations.

7.  Intellectual Property Issues

No specific reliability protocol or congestion control protocol is
specified or referenced as mandatory in this document.

LCT MAY may be used with congestion control protocols and other protocols protocols,
such as reliability protocols, which are proprietary, proprietary or have pending or
granted patents.

^L

8.  Acknowledgments

Thanks to Vincent Roca, Bruce Lueckenhoff and Lueckenhoff, Hayder Radha and Justin
Chapweske for detailed comments on this document.

9.  References

[1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered
Multicast", Proceedings of Second International Workshop on Networked
Group Communications (NGC 2000), Palo Alto, CA, November 2000.

[2] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital
Fountain Approach to Reliable Distribution of Bulk Data", Proceedings
ACM SIGCOMM '98, Vancouver, Canada, Sept September 1998.

[2] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist
(GRA) Building Block, Motivation and Architecture", Internet Draft
draft-ietf-rmt-gra-arch-00.txt, a work in progress.

[3] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable "Fcast Multicast File Distribution: Caching and Parameters Optimizations", Technical
Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999.
Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.

[4] Handley, M., "SAP: Session Announcement Protocol", Internet Draft,
IETF MMUSIC Working Group, Nov 1996, a work in progress.

[5] Holbrook, H., Cain, B., "Source-Specific Multicast H. W., "A Channel Model for IP", Internet
Draft, SSM Working Group, March 2001, draft-holbrook-ssm-arch-02.txt, a
work in progress.

[6] Multicast," Ph.D.
Dissertation, Stanford University, Department of Computer Science,
Stanford, California, August 2001.

[5] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,
Crowcroft, J., "The use of Forward Error Correction in Reliable
Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November
2000, draft-ietf-rmt-info-fec-01.txt, October 2001,
a work in progress.

[7]

[6] Luby, M., Vicisano, L., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft
draft-ietf-rmt-bb-fec-03.txt, July
draft-ietf-rmt-bb-fec-04.txt, October 2001.

[8] Luby, M., Hernek, D., Kushi, D., Rasmussen, L., Simu, S., Vainish,
R., "Rich Content Control Protocol: A session control protocol
instantiation", Digital Fountain document, a work in progress.

[9] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion
control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in
progress.

[10]

[7] Rizzo, L., "Effective Erasure Codes for Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication Review,
Vol.27, No.2, pp.24-36, Apr 1997.

^L

[11]

[8] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:
Multicast Tygar, J.D., "Efficient and
Secure Source Authentication Transform", draft-irtf-smug-
tesla-00.txt, November, 2000, a work in progress.

[12] for Multicast", Network and Distributed
System Security Symposium, NDSS 2001, pp. 35-46, February 2001.

[9] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution
protocol based on software FEC techniques", Proceedings of the Fourth
IEEES Workshop on the Architecture and Implementation of High
Performance Communication Systems, HPCS'97, Chalkidiki, Chalkidiki Greece, June
1997.

[13] Speakman, T., Farinacci, D., Crowcroft, J., Gemmell, J., Lin, S.,
Tweedly, A., Leshchiner, D., Luby, M., Bhaskar, N., Edmonstone, R.,
Johnson, K., Montgomery, T.,

[10] Rizzo, L., Sumanasekera, R., Vicisano, L.,
"PGM Reliable Transport Protocol", draft-speakman-pgm-spec-06.txt, a
work in progress.

[14] L, "PGMCC: A TCP-friendly single-rate multicast congestion
control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August
2000.

[11] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion
Control for Layered Multicast Data Transfer", IEEE Infocom '98, San
Francisco, CA, Mar.28-Apr.1 1998.

[15] Vicisano, L., "Notes On a Cumulative Layered Organization of Data
Packets Across Multiple groups with Different Rates", University College
London Computer Science Research Note RN/98/25, Work in Progress (May
1998).

9.

10.  Authors' Addresses

   Michael Luby
   luby@digitalfountain.com
   Digital Fountain
   39141 Civic Center Drive
   Suite 300
   Fremont, CA, USA, 94538

   Jim Gemmell
   jgemmell@microsoft.com
   Microsoft Research
   301 Howard St., #830
   San Francisco, CA, USA, 94105

   Lorenzo Vicisano
   lorenzo@cisco.com
   cisco Systems, Inc.
   170 West Tasman Dr.,
   San Jose, CA, USA, 95134

^L

   Luigi Rizzo
   luigi@iet.unipi.it
   ACIRI/ICSI,
   1947 Center St, Berkeley, CA, USA, 94704
   and
   Dip. Ing. dell'Informazione,
   Univ. di Pisa
   via Diotisalvi 2, 56126 Pisa, Italy

   Mark Handley
   mjh@aciri.org
   ACIRI,
   1947 Center St,
   Berkeley, CA, USA, 94704

   Jon Crowcroft
   J.Crowcroft@cs.ucl.ac.uk
   Department of Computer Science
   University College London
   Gower Street,
   London WC1E 6BT, UK

^L

10.

11.  Full Copyright Statement

Copyright (C) The Internet Society (2000). (2001).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT not
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT not
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."

^L