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

		       Layered Coding Transport:
	    A massively scalable multicast protocol content delivery transport

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 multicast protocol, reliable content delivery and stream delivery

^L
     transport, hereafter referred to as LCT.

^L  LCT can be used for
     multi-rate content delivery (for both
     reliable bulk data transfer and unreliable data streams) to large sets of receivers. In LCT,
     scalability and congestion control are supported through the
     use of layered coding techniques. When Coding techniques can be
     combined with LCT is used for reliable data transfer, the
     coding also provides to provide support for reliability.

     Congestion control is receiver driven, and is achieved by
     sending packets in the session to multiple ``LCT groups'', channels'',
     and having receivers join and leave LCT groups 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. . . . . . . . . . . . . . . . . .   5   6
      1.2. Environmental Requirements . . . . . . . . . . and Considerations. . . .   6
     2. General Architecture. . . . . . . . . . . . . . . . . .   8
      2.1. Delivery service models. . . . . . . . . . . . . . .   9  10
      2.2. Congestion Control . . . . . . . . . . . . . . . . .  10  11
     3. Packet Formats. . . . . . . . . . . . . . . . LCT packets . . . . .  11
      3.1. Data-Packet format . . . . . . . . . . . . . . . . .  11
      3.2. Request-Packet
      3.1. LCT packet format. . . . . . . . . . . . . . . . . .  12
      3.3.
      3.2. LCT Packet packet header fields . . . . . . . . . . . . . .  13
      3.4. Transmission Extensions. . . . . . . . . . . . . . .  15
      3.5.
      3.3. Header-Extension Fields. . . . . . . . . . . . . . .  16
     4. Procedures. . . . . . . . . . . . . . . . . . . . . . .  19
      4.1. Sender Operation . . . . . . . . . . . . . . . . . .  19
      4.2. Receiver Operation . . . . . . . . . . . . . . . . .  21
     5. Security Considerations . . . . . . . . . . . . . . . .  23  22
     6. IANA Considerations . . . . . . . . . . . . . . . . . .  23  22
     7. Intellectual Property Issues. . . . . . . . . . . . . .  23  22
     8. Acknowledgments . . . . . . . . . . . . . . . . . . . .  24  23
     9. Authors' Addresses. . . . . . . . . . . . . . . . . . .  25  24
     10. Full Copyright Statement . . . . . . . . . . . . . . .  27  26

^L

1.  Introduction

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

IP multicast [5]

LCT is a building block as defined in RFC3048.	Complete protocol
instantiations MAY be built by combining the LCT framework with other
components.  A complete protocol instantiation that uses LCT MUST
include a congestion control protocol that is compatible with LCT and
that conforms to RFC2357.  A complete protocol instantiation that uses
LCT MAY include a scalable reliability protocol that is compatible with
LCT, it MAY include an session control protocol that is compatible with
LCT, and it 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 and that does not guarantee packet
reception, or packet reception order. Also it order, and which does not provide have any support
for flow or congestion control. While  For example, the basic service provided
by 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, adding features such as providing congestion control or reliability on top of it might cause should be
done carefully to avoid severe scalability limitations, especially in
presence of heterogeneous sets of receivers.

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

Congestion control refers to the ability of the protocol to adapt its
throughput to the available bandwidth on the path to the receivers, and
to share bandwidth fairly with competing flows such as TCP. It is
required
REQUIRED that protocols implement some form of congestion control on
each session so that they not compete unfairly with existing and
adaptive protocols such as TCP.

Multi-rate protocols aim at splitting

For multi-rate protocols, 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 receivers into multiple
subsets, channels they are joined to at each point in time
depending on the available bandwidth between the receiver and the
sender, but 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, the sender typically sends packets to one has channel at variable
rates over time depending on feedback from receivers, and all receivers
attempt to receive all packets transmitted by the
source.  Conversely, sender at all points
in time.   Thus, for single-rate multicast protocols make protocols, the packet reception rate of
all receivers may vary dynamically over time in a session experience exactly the same throughput.  The partitioning way
dependent on the feedback of other receivers to the sender.  Generally,
a multi-rate protocol is preferable to a single-rate protocol in a
heterogeneous receiver environment, but only if it can be done statically or adaptively. achieved
without sacrificing scalability.

Layered coding refers to the ability to produce a coded stream that can
be split into multiple substreams (transmitted over layers that can be sent to different multicast
groups). channels.
The coded stream can be generated either from a fixed piece of content,
or from an ongoing data stream, and has the property that the quality
experienced by a receiver (in terms of quality of playout, or overall
transfer speed) is proportional to how many of the substreams layers the receiver
is joined.  Layered joined to.  LCT MAY be combined with a reliability protocol such as
the general class of protocols described in [7]. LCT MUST be combined
with a congestion control protocol that is compliant with RFC 2357 must be used by receivers to dynamically adjust their
reception rate by appropriately joining RFC2357, and
this MAY be either single-rate or leaving groups carrying multi-rate congestion control over the
entire session.  It is most compelling to use LCT in conjunction with a
layered congestion control protocol such as the substreams. class of protocols
described in [9], and specified in [9], which are multi-rate congestion
control protocols.

The concept of layered coding was first introduced with reference to
audio and video streams.  For example, the information associated with a

^L
TV broadcast can be thought as made of 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 bulk
data transfer
content delivery protocols when Forward Error Correction (FEC)
techniques are used for coding the data stream [12] [10] [3] [14] [15] [16] [7] [17] [18] [3].
[1]. 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 groups it layers a receiver is
receiving from, a the receiver can reduce the transfer time accordingly.
More details on the use of FEC for reliable multicast content delivery can be
found in
[11]. [6].  Reliable protocols aim at giving guarantees on the

^L

reliable delivery of data from the source sender to the intended recipients.
Guarantees vary from simple packet data integrity to strict ordering and atomic delivery. reliable delivery
of a precise copy of a data object to all intended recipients.	Several
reliable multicast 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 [PGM], (see for example [13] ), an approach which has an
impact on near term
deployment. 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 FEC codes or a layered
codec to achieve reliability with little or no feedback.

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

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2]. RFC2119.

1.1.  Related Documents

A more in-depth description of the use of FEC in Reliable Multicast
Transport (RMT) protocols is given in [11]. [6]. Some of the FEC codecs that
may
MAY be used by LCT for reliable bulk data transfer content delivery are specified in
[12]. [7].
LCT reserves opaque header fields that can be used to transport
information related to the payload encoding.

Implementors of LCT MUST also implement congestion control in accordance
to RFC2357 [13]. One possible scheme RFC2357, where the congestion control is over the entire session.
Some possible schemes are specified in [1]. [9]. LCT reserves

^L opaque header
fields that can be used by the congestion control scheme to transport
information related to congestion control.

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

1.2.  Environmental Requirements and Considerations

LCT is intended for congestion controlled, multi-rate delivery of
objects and streams (both reliable bulk data transfer content delivery and unreliable 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 to all multicast enabled networks, including
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, 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
and demultiplex LCT packets for a given LCT session, and supply packet
length information to the LCT receiver. In IP networks, this is normally often
achieved by using UDP, or any protocol that can provide an equivalent
service, as the underlying transport protocol.

In this document, we refer to the original multicast service model
defined in RFC1112 as Any-Source Multicast, or ASM for short.  We refer
to the multicast service model 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, LCT works with both the
original multicast model introduced in [5], which we call Internet
Standard Multicast (ISM) in this document, ASM and with the Source Specific
Multicast (SSM) model that is based on [10]. SSM.

The definition of an LCT
group channel used throughout this document is
slightly different with ISM ASM and with SSM.  When using ISM, packets of an ASM, a sender S
sends LCT group are sent packets to a multicast group address G.  When using SSM, packets of an G, and the LCT group are
sent to a channel address
consists of the pair (S,G), where S is the IP address of the sender and
G is a multicast group address.

SSM is more attractive to LCT than ISM for  When using SSM, a few 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, LCT a sender may allocate and use several LCT groups channels in a
session, sessions may come and the large, local namespace

^L

for allocating multicast groups in go dynamically. A sender can locally
allocate unique SSM greatly simplifies 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 problem.

Second, of LCT over
channel addresses more difficult with ASM.

^L

In general SSM performs well even in presence of very large and
dynamically changing receiver sets.  Changes in the multicast tree
topology with SSM are light weight operations (a new branch from the
receiver towards S grows when a receiver joins, and the branch is
deleted when the receiver leaves), whereas with ISM ASM changes can be
heavier weight (involving transitions from a (*,G)-tree rooted at an RP
to the tree rooted at S).

Third, LCT over SSM scales well even  This efficiency is important when receivers span the global
Internet, as the light weight mechanisms that SSM uses to cross ISP
boundaries (standard BGP+ routing tables) a
congestion control protocol is distinct advantage over the
heavier weight mechanisms used by ISM (the MSDP and BGMP protocols, both
of which are not needed by SSM).

Finally, a receiver joins an with LCT group by that relies upon joining a channel (S,G) with
SSM,
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 from to the
sender S. requested LCT channel.  With ISM, ASM, the
receiver joins an LCT group channel by joining a multicast group G, and all
packets sent to G, regardless of their origin the sender, will 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 ISM ASM for prevention of denial of service attacks.

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

The particular layered encoder and congestion control protocols used by
with LCT to provide a complete protocol 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, thus providing a very
coarse control in the throughput reception rate of packets by receivers in a
session.  When LCT is used for reliable data transfer, some FEC coders 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 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.

^L

2.  General Architecture

An LCT session comprises all LCT packets sent to one or more LCT groups
channels from a single sender, and pertaining to the transmission of one
or more objects that can be of interest for the receivers.

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

^L

three groups.  The channels.  Receiving the first group would channel could allow black and white
reception, receiving the first two groups channels would permit color
reception, whereas receiving the set of three groups channels delivers HDTV
quality images.  Objects in this example
would could correspond to individual
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 groups channels at
different rates, using FEC coding.  A receiver may MAY join and concurrently
receive LCT packets from subsets of these groups, channels, until it has enough
packets in total to recover the object, then leave the session (or
remain there listening to control 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 obtain a session
description, which MUST include the relevant session parameters needed
by a receiver to participate in the session.  The session description is
determined and agreed upon by the senders, and typically communicated to
the receivers out of band. In some cases, part of the session
description MAY be included in the header of each LCT packet.

A layered

An encoder is MAY be used to generate the data that is placed in the
payload of LCT packets.
packet payload in order to provide reliability.  A suitable decoder is
used to extract reproduce the original information from the payload.

LCT congestion control is achieved by sending packets associated with  There MAY
be a
given session to several LCT groups. 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] could be used.

For LCT, when layered 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 to one or more
of these groups, channels, according to the network congestion as seen by the
receiver.  LCT packet headers include an opaque field which 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.  One
Some examples of the algorithms that can be used to
achieve congestion control protocols that MAY be suitable for
content delivery are described in [9]. Other congestion controls MAY be
suitable when LCT is described in [1]. used for a streaming application.

LCT can be used with other congestion control algorithms protocols such as the one
described in
[17], [14], or router-assisted scheme 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 [4] [2] for a preliminary design description.	We do
not discuss this approach

^L further in this document.

Depending on the service model in use, receiver can generate LCT request
packets, which have no payload, and are used to request an extension of
the duration of the session.

2.1.  Delivery service models

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

Streaming

Push service model.

This is the basic

One way a push service model can be used for the reliable content delivery
is to deliver a series of unreliable streams,
such as the TV example of Section 1. In this case the receivers objects.  For example, a receiver could join
the
session, session and dynamically adapt the number of LCT groups they subscribe
to (and channels the reception quality) according
receiver is joined to until enough packets have been received to
reconstruct an object. After reconstructing the available bandwidth.
Receivers then drop from object the session when they are not interested receiver may
stay in the
stream anymore.

This service model can also be used session and wait for reliable data transfer, in case the transmission of objects that need periodic updates such as the weather maps example
mentioned next object.

The push model is particularly attractive in Section 1. satellite networks and
wireless networks.  In this case, 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 groups channels they subscribe to until they
have accumulated a sufficient number of packets (and the reception quality)
according to reconstruct the
object. Afterwards, they available bandwidth. Receivers then drop from the
session (or listen to the lowest
LCT group only) and wait for the transmission of the next object to
resubscribe or restart bandwidth adaptation according when they have received enough packets to recover the congestion
control scheme. object.

As an example, assume that each an object to be transmitted has a size of
5000 1KB packets, and objects are updated every hour. is 50 MB.	The sender could set the
data rate on the lowest LCT group channel to 5 50 1KB packets/s, packets per second, so
that receivers using just this LCT group channel could complete reception of
the object in 1000 1,000 seconds in absence of loss, and would be able to
complete reception even in presence of some substantial amount of losses or because they join
the session after
with the start use of a transmission. coding for reliability.  Furthermore, the sender could
use a number of LCT groups channels such that the aggregate data rate when
using all LCT groups channels is 100 1,000 1KB packets/s, packets per second, so that a
receiver could be able to complete reception of a single 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 groups).

^L

On demand channels).

Other service models.

There are many other delivery model.

This service model is mostly relevant for reliable models that LCT session, where
the same object is made available by the sender can be used for
that are not covered above.  As examples, a sufficiently long
amount of time (typically much larger than the download time for the
object) to make it convenient for receivers to enact the download at
their discretion.

Receivers may join the ongoing object transmission session at their
discretion, obtain the necessary encoding symbols to reproduce the
object, and then leave the session.

For an on demand 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.

Other service models.

There are many other delivery service models that LCT can be used for
that are not covered above.  The description 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 mechanism. transport.

2.2.  Congestion Control

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

A

Some possible congestion control algorithm protocols for reliable content delivery
using LCT sessions is
specified are described in [1]. [9]. Different session types delivery service models might
require a different congestion control algorithm.

^L protocols.

3.  Packet Formats  LCT packets

The primary type of packets packet used by LCT sessions is "Data "LCT Packet".  Data  LCT packets
are sent by the data sender(s) senders to an LCT group. channels.

Some instances of LCT sessions may MAY require the generation of feedback
from the receivers to the sender.  Such information  However, the mechanism for doing this
is carried in
Request packets, which are OPTIONAL and have outside the sole purpose scope of
implementing the "transmission extension" mechanism described in Section
3.4. LCT.

The LCT packet format described in this document is intended to be used
in conjunction to with the UDP transport protocol [14], as defined in RFC768 or
other transport protocols that satisfy the requirements stated in
Section 1.2, specifically about demultiplexing and delivery of packet
size information.

LCT Data packets consist of an LCT packet header and an optional OPTIONAL LCT packet
payload, as shown in Figure 1.	When present, the LCT packet payload

^L

immediately follows the LCT packet header.  The LCT Request Packets only consist of an LCT header, packet payload MAY
contain headers for other protocols, such as shown in Figure 2. reliability protocols.

LCT Packet Headers packet headers have variable size, which is specified by a length
field in the 3dr third byte of the header.	In the LCT Packet Header, 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 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.  Data-Packet  LCT packet format

The format of LCT Data Packets packets is depicted in Figure 1.

^L

  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 |D|r|T|X|Trans.Obj.Id.(TOI)	 |    r    | I |S|E|X|A|B|   HDR_LEN	 | Codepoint (CP)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |	       Congestion Control Information (CCI)		 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		      Demux Label (DL,	  Transport Object Identifier (TOI, if D = I >= 1)		 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		 Sender Current Time (SCT, if T =		  TOI continued  (if I >= 2)			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		  TOI continued  (if I = 3)			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		  TOI continued  (if I = 3)			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		 Sender Current Time (SCT, if S = 1)		 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		Expected Residual Time (ERT, if T E = 1)		 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		  Header Extensions (only present if (if X = 1 ) 		 |
 |								 |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |								 |
 |			    Payload				 |
 |								 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 - LCT Data Packet format

3.2.  Request-Packet format

When using on-demand service, LCT receivers MAY request that the sender
extend the transmission of the packets pertaining to a given object.
Requests should only be sent in response to data packets which are
carrying the TEI field (have the T bit set).  Request packets MUST be
unicast to the node (designated out of band) in charge of receiving
Request packets.

The packet format of Request Packets is shown in Figure 2.

^L
  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 |D|r|1|X| Trans.Obj.Id.(TOI)|    HDR_LEN	 |	 0	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		     Desired End Time (DET)			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		   Demux Label (DL, if D = 1)			 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |	   Header Extensions (only present if X = 1 )		 |
 |								 |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Figure 2: LCT Request Packet format

3.3.

3.2.  LCT Packet packet header fields

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

  LCT version number (V): 2 4 bits

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

  Demux Label Present

  Reserved (r): 5 bits

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

  Transport Object Identifier flag (D): 1 bit

      D = 1 (I): 2 bits

      I=0 indicates no Transport Object Identifier (TOI) field is
      present.
      I=1 indicates that the Demux Label (DL) a 32-bit TOI field is present. D = 0
      I=2 indicates "no DL field".	The DL that a 64-bit TOI field contains is present.
      I=3 indicates that a 32-bit
      identifier 128-bit TOI field is present.
      The TOI field indicates which can be used to filter packets belonging to object within the
      session.

  Transmission Extension Information Present session this LCT
      packet pertains to.

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

      T

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

  Expected Residual Time present flag (E): 1 bit

      E = 0 indicates that the Expected Residual Time (ERT) field is not
      present.
      E = 1 indicates that the ERT field is present.
      The ERT is inserted by senders when they are willing to accept
      Transmission Extension Request packets from indicate to receivers how much
      longer the receivers. session will continue.
      Senders MUST NOT set E = 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 extension present flag (X): 1 bit

      X = 1 0 indicates that no Header Extensions are present.
      X = 0 1 indicates "no that Header Extensions". Extensions are present.
      Header Extensions are used in

^L LCT to accommodate optional OPTIONAL header
      fields which are not always used or have variable size.

  Transport Object Identifier (TOI): 10 bits

  Close TOI flag (A): 1 bit

      Normally, the Close TOI flag is set to 0.  The Transport Object Identifier (TOI) field indicates which
      Transport Object within sender MAY set the session this Data packet or Request
      packet pertains to.  For example, a source might send a number
      Close TOI flag to 1 when termination of
      files in the same session, using TOI=0 for the first file, TOI=1 transmission of LCT
      packets for the second one, etc.

  LCT Header Length (HDR_LEN): 8 bits

      Length of object identified by the variable portion of TOI is imminent.  The
      Close TOI flag MAY be set to 1 in just the last LCT header in units of
      32-bit words (excluding IP packet
      transmitted for the object, or UDP headers). The total LCT header
      length is (HDR_LEN+2) 32-bit words.
      This field can it MAY be used for direct access set to 1 in the beginning last
      couple of the seconds LCT payload.

  Codepoint (CP): 8 bits

      An opaque identifier which is passed to the payload decoder to
      convey information on the codec being used packets transmitted for the payload. The
      mapping between object.  Once
      the codepoint and sender sets the actual codec is defined on Close TOI flag to 1 in one packet for a
      per session basis and communicated out-of-band as part of
      particular object, the
      session description information.

      The use of sender SHOULD set the CP field is similar Close TOI flag to the Payload Type (PT) field 1
      in RTP headers [].

  Congestion Control Information (CCI): 32 bits

      Used to carry Congestion Control Information, e.g. all subsequent packets for the scheme
      described in [1] or other congestion control schemes. This field
      is opaque object until termination of
      transmission of LCT packets for the purpose of this specification.

  Demux Label (DL): 32 bits (OPTIONAL)

      Used object.  A received packet
      with the Close TOI flag set to carry a 32-bit identifier 1 indicates to be used for filtering
      purposes. All a receiver that the
      sender will immediately stop sending LCT packets belonging to for the same LCT group MUST
      have object
      identified by the same DL value TOI.  When a receiver receives a packet with the
      Close TOI flag set to 1 then it should assume that has been communicated out of band no more LCT
      packets will be sent to
      receivers as part of the session description information.
      Receivers MUST discard packets with a non-matching DL.
      In order for this object.

  Close Session flag (B): 1 bit

      Normally, the Close Session flag is set to minimize 0.  The sender MAY set
      the amount of information Close Session flag to be supplied out 1 when termination of band, it is suggested that transmission of
      LCT packets for the same DL session is used for all imminent.	The Close Session flag
      MAY be set to 1 in just the last LCT
      layers packet transmitted for the
      session, or it MAY be set to 1 in the same last couple of seconds LCT
      packets transmitted for the session.

^L
  Sender Current Time (SCT): 32 bits (OPTIONAL)

      This field represents  Once the current clock at sender sets the
      Close Session flag to 1 in one packet, the sender at SHOULD set the time
      this packet was transmitted, measured
      Close Session flag to 1 in units all subsequent packets until
      termination of 1ms and computed
      modulo 2^32 units.
      SCT is used, in conjunction transmission of LCT packets for the session.  A
      received packet with the ERT and DET fields, Close Session flag set to
      support 1 indicates to
      a receiver request generation as described in Section 3.4.
      This field is only present in Data Packets when T=1.

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

      This field represents that the expected residual transmission time sender will immediately stop sending LCT
      packets for the current object, measured in units of 1ms. Senders MUST NOT
      include SCT and ERT if the transmission of session.	When a receiver receives a packet with
      the current object is
      expected Close Session flag set to last for 1 then it should assume that no more than 2^32-1 time units (approximately 49
      days).  See Section 3.4 for a detailed description on
      LCT packets will be sent to the use of
      this field.  This field is only present in Data Packets when T=1.

  Desired End Time (DET): 32 session.

^L
  LCT packet header length (HDR_LEN): 8 bits

      This field represents the desired finish time for the transmission

      Length of the object, measured LCT packet header in units of 1ms and computed modulo 2^32
      time units. See Section 3.4 32-bit words
      (excluding IP or UDP headers).
      This field can be used for a detailed description on direct access to the use beginning of this field.  This field is only present in Request Packets when
      T=1.

3.4.  Transmission Extensions

Four fields in the
      LCT packet headers are used payload.

  Codepoint (CP): 8 bits

      An opaque identifier which is passed to support the Transmission
Extension mechanism: T, SCT, ERT, DET.	These fields have the following
purposes:

  o to communicate payload decoder to receivers
      convey information on the expected finish time codec being used for the
    transmission of the current object

  o to let receivers produce requests to extend transmission which are
    idempotent.

When a sender is willing to accept extension requests, it will set T=1
in payload. The
      mapping between the data packets, codepoint and also include the SCT actual codec is defined on a
      per session basis and ERT fields communicated out-of-band as follows:

  o SCT is set to the current time known at part of the sender, measured in
    units
      session description information.	The use of 1ms, and computed modulo 2^32 units.

^L
  o ERT the CP field is set
      similar to the expected residual transmission time, Payload Type (PT) field in RTP headers as known described
      in RFC1889.

  Congestion Control Information (CCI): 32 bits

      Used to carry congestion control information, e.g. for the sender, and measured
      congestion control specified in units [9] or other congestion control
      schemes.	This field is opaque for the purpose of 1ms.  The maximum value that
    can be accommodated in this
      specification.

  Transport Object Identifier (TOI): 32, 64 or 128 bits (OPTIONAL)

      This field is approximately 49 days.  A
    sender MUST NOT generate these fields if indicates which object within the residual transmission
    time is larger than session this maximum value.

The Expected Finish Time (EFT) LCT
      packet pertains to.  For example, a sender might send a number of
      files in the transmission at the sender site
can be computed as
			    EFT = SCT + ERT.

A receiver can determine same session, using TOI=0 for the Desired Residual Time (DRT) based on
external information, such as first file, TOI=1
      for the amount second one, etc.	The mapping of missing data and the
incoming data rate.  DRT is TOI field values to
      objects MUST be done out of band.
      This field MUST NOT be present if I=0.
      This field MUST be 32 bits if I=1.
      This field MUST be 64 bits if I=2.
      This field MUST be 128 bits if I=3.

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

      This field represents the (estimated) transmission extention
needed, measured from current clock at the time of estimation to sender at the time of the desired
end of transmission.  The maximum value for DRT is 2^32-1
      this packet was transmitted, measured in units of 1ms
each.  Higher values must be upper bounded to 2^32-1.
A receiver and computed
      modulo 2^32 units from the start of the session.
      This field MUST NOT generate Request packets be present if S=0 and MUST be present if S=1.

^L
  Expected Residual Time (ERT): 32 bits (OPTIONAL)

      This field represents the reception is likely
to complete before the sender expected end of residual transmission
      time for the current session, i.e. measured in units of 1ms.
      This field MUST NOT be present if DRT << ERT .

If a receiver needs to extend the transmission, they compute the Desired
End Time value to E=0 and MUST be put into Request packets as

			    DET = SCT + DRT.

The above procedures make requests idempotent.

3.5. present if E=1.

3.3.  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 are included within the LCT packet header beyond the predefined
fields.  When additional headers beyond the predefined fields are used,
the value of "X" within the LCT packet header MUST be set to 1.

Examples of use of header extensions Header Extensions include:

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

  o Sender and Receiver authentication information.

If present, Header Extensions must MUST be processed to ensure that they are
recognized before performing any congestion control procedure or
otherwise accepting the an LCT packet.  Packets LCT packets with unrecognised Header
Extensions MUST be discarded by the receiving

^L agent, hence the expected
use of extentions should extensions SHOULD be signalled out-of-
band signaled out-of-band before session startup.

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

^L
  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)  |	 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)  |	 Header Extension Content (HEC) 	 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5 - format 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 a an
      LCT packet header, MUST be set to 0 in all the others.

  Header Extension Type (HET): 7 bits

      The type of the header extension. 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 are used
      for variable-length Header Extensions. HET values from 64 to 127
      are used for fixed-length Header Extensions.

  Header Extension Length (HEL): 8 bits (OPTIONAL)

      The length of the whole Header Extension field, expressed in
      multiples of 32-bit words. This field is only MUST be present for

^L
      variable-length extension extensions (HET between 0 and 63). 63) and MUST NOT be
      present for fixed-length extensions (HET between 64 and 127).

   Header Extension Content (HEC): variable length

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

The originator of a

An LCT packet with header extensions Header Extensions MUST not leave
additional NOT have space between the end
of the last Header Extension and the beginning of the LCT packet
payload.

All senders and receivers of LCT agents packets MUST support the EXT_NOP header extension. Header
Extension.

The following header extension Header Extension types are defined:

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

EXT_CCI=1

EXT_CCI_V=1   Congestion Control Information extension. 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 bits 32-bit CCI field.
	      When this option is present, receivers MUST ignore the CCI
	      field and use the value provided in this option instead.
	      The interpretation of the data contained in EXT_CCI MUST
	      be negotiated out-of-band.

EXT_TOI=2     Tranport Object Identifier extension.
	      This extension field extends the TOI field concatenation of the fixed
	      header. It is used when the Tranport Object Identifier
	      does not fit in 10 bits.	When this option is present,
	      receivers MUST ignore the TOI
	      32-bit CCI field in the fixed part of the header
	      and use together
	      with the variable length value provided in this option instead. is
	      used as the congestion control information.  The
	      interpretation of the data contained in EXT_TOI EXT_CCI_V MUST be
	      negotiated out-of-band.

EXT_AUTH=3  The use of EXT_CCI_V and
	      EXT_CCI_F is mutually exclusive.

EXT_AUTH=2    Authentication Extension extension
	      Information used to authenticate the source sender of the LCT
	      packet.

^L  If present, the format of this header extension Header Extension
	      and its processing must MUST be communicated out-of-band as
	      part of the session description.
	      It is recommended RECOMMENDED that senders and receivers provide some form of
	      authentication on the packet LCT packets they transmit.	If
	      EXT_AUTH is present, whatever 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 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 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 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 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.

4.  Procedures

4.1.  Sender Operation

Before a session starts, an LCT sender MUST make available all
applicable information regarding the session, including session.  This information could
include, but is not limited to:

  o The number of LCT groups; channels;

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

  o the The format of the payload (for payload. For example, the mapping of codepoints
    used in the session to FEC codec types payload could contain
    other protocol headers such as an FEC header.  Then for example the
    information could include the mapping of codepoints used in the
    session to FEC codec types and parameters); parameters;

  o the The congestion control scheme being used;

  o The possible Header Extensions that could be used in the Demux Label (DL) session;

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

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

  o the address of the node in charge of receiving Request packets;

^L

The session description could be in a form such as SDP [8], as defined in
RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a
session announcement protocol such as SAP [9], [4], obtained using RCCP
session control as described in [8], located on a Web page with

^L
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 sender transmits a sequence of data LCT packets
each containing a payload encoded according to one of the codecs defined
in the session description.  Data  LCT packets are sent over one or more LCT groups
channels which together constitute a session.  Transmission rates
may MAY be
different in different groups. channels. This document does not specify the
policy used to place symbols into packets, LCT
packet payload, nor the order in which LCT packets are transmitted, nor
the scheduling organization of packets in a session into multiple
groups. channels. Although these
issues affect the efficiency of the protocol, they do not affect the
correctness nor the inter-operability between senders and receivers.

Multiple transport objects can be carried within the same LCT session.
Each  In this
case, each object is identified by a unique Transport Object Identifier (TOI). TOI.  Objects MUST MAY be
transmitted sequentially, and the TOIs MUST or they MAY be used in
strict sequential order. A sender is not allowed to transmit packets for
old objects after starting the transmission of packets for a new one.
Note that despite this restriction, both the network and the underlying
protocol layers can cause some reordering of packets, especially when
sent over different LCT groups, and thus receivers MUST NOT assume that
the reception of a packet for a new object means that there are no more
packets in transit for the previous one, at least for some amount of
time. transmitted concurrently.

Typically, the sender(s) continues to send data 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. Feedback through LCT Request packets MAY also be used to
determine the end of the session.

The specification of the processing of the payload carried in LCT
packets is beyond the scope of this document.  LCT will only act as a
transport layer and will merely implement congestion control and convey payload and associated information (Codepoint
and TOI) to the receivers. 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
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

^L sizes, as this can have a severe impact on the effectiveness of
congestion control schemes such as the one ones described in [1].  An LCT [9].  A sender
of LCT packets MUST implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC 2357, RFC2357, and the

^L

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

If a Sender implements the Transmission Extensions, then it MUST operate
as described in Section 3.4.

4.2.  Receiver Operation

Receivers can operate differently depending on

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 multicast groups LCT channels to
download all objects in a session.

To be able to participate in a session, a receiver 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 algorithm protocol specified in the session description. If a
receiver is not able to implement the congestion control algorithm protocol used
in the session, it MUST NOT join the session.

If source sender authentication information is present in data packets, an LCT packet header,
it must MUST be used as specified in Section 3.5. 3.3. If a receiver is unable to
implement the authentication mechanism used by the session, it MUST NOT
join the session.

To be able to participate be a receiver in a session, receivers the receiver MUST be able to
process the payload of the packets. At a minimum this involves the
ability LCT packet header.	The receiver MUST be able to forward or discard,
forward, store or process the payload, and possibly (in case of
reliable LCT session) determine when an object can be successfully
recovered. packet payload.  If a receiver is not
able to process the payload of packets, a LCT packet header, it MUST either drop from the
session, or reduce the receive bandwidth to the minimum value allowed by
the congestion control algorithm protocol being used.

When the session is transmitted on multiple LCT groups, channels, receivers MUST
do it according to the specified startup behaviour behavior of the congestion
control algorithm protocol itself. For a layered transmission on multiple groups,
channels, this typically means that a receiver will only initially join only
a minimal set of LCT
groups, channels, possibly a single one.  This rule has the
purpose of preventing

^L receivers from starting at high data rates.

If

Multiple objects can be carried within the Transmission Extension Information field same LCT session.  In this
case, each object is present in data
packets, receivers MAY originate Request identified by a unique TOI.  Note that even if a
server stops sending LCT packets to extend the
transmission of for an old object as specified in Section 3.4.	Receivers MUST
NOT originate transmission extension request if the T flag in incoming
data packets is set before starting to 0.

Receivers which generate Request
transmit LCT packets MUST implement feedback-
implosion avoidance procedures as follows:

  o Receivers must use the Expected Finishing Time advertised by the
    sender(s) to predict whether or not they will be able to recover the
    object from for a new object, both the packets they have already received network and from the
    packets they
underlying protocol layers can expect to receive in the future. This prediction
    SHOULD also consider data-rate fluctuations caused by congestion
    control adaptations.

  o When a receiver predicts cause some reordering of packets,
especially when sent over different LCT channels, and thus receivers

^L

MUST NOT assume that the residual object transmission time
    is not sufficient to successfully recover the object, it MAY
    schedule the transmission reception of an extension request at LCT packet for a random time new object
means that there are no more LCT packets in the future, before the scheduled end of the transmission.

  o When a receiver has a pending extension request scheduled transit for
    transmission, it must keep monitoring the progress of the reception
    and cancel the pending request if either of the following happens:

       -
      The residual object transmission time becomes larger the predicted
      time needed to complete the reception.

       -
      A Data packet previous
one, at least for the object some amount of interest is received with the T
      flag set to 0.

  o time.

A receiver MUST cancel pending extension-requests when the
    transmission time of an object is over.

The rules stated above are not sufficient to obtain a good implosion
prevention in all the cases. For improved performance the following
guidelines SHOULD be followed:

  o Extension requests should MAY be *scheduled* only when the reception of
    the object is in an advanced status of completion (e.g.  more than
    50%). This improves the accuracy of the receivers' prediction

^L
    reducing the chance that an extension is requested uselessly.

  o The time needed for a Request to suppress pending Request from other
    receivers is approximatively a packet round trip time (unicast
    request to the sender and multicast data packets concurrently joined to multiple LCT sessions.  The
receiver MUST perform congestion control on each such LCT session.  If
the receivers).
    Using random-time scheduling for requests is an effective
    suppression mechanism only if congestion control protocol allows the length receiver some flexibility in
terms of its actions within a session then the interval from which
    the transmission time is selected is much larger than a round trip
    time.  For this reason extension requests should be *scheduled* at
    least a few seconds before the end of transmission. receiver 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.

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 LCT agents implement some form of
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 LCT may introduce additional IANA
considerations.

7.  Intellectual Property Issues

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

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

^L

8.  Acknowledgments

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

[1] Luby, M., Vicisano, L., Haken, A., "Layered congestion control
building block", draft-ietf-rmt-bb-lcc-00.txt, November 2000.

[2] Bradner, S., Key words for use in RFCs to Indicate Requirement
Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt

[3] 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 1998.

[4]

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

[5] Deering, S., "Host Extensions for IP Multicasting", RFC 1058,
Stanford University, Stanford, CA, 1988.

[6] Fielding, R., Gettys, J., Mogul, J. Frystyk, H., Berners-Lee, T.,
Hypertext Transfer Protocol - HTTP/1.1 (IETF RFC2068) http://www.rfc-
editor.org/rfc/rfc2068.txt

[7]

[3] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast
File Distribution: Caching and Parameters Optimizations", Technical
Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999.

[8] Handley, M., and Jacobson, V., "SDP: Session Description Protocol",
RFC 2327, April 1998.

[9]

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

[10] 1996, a work in progress.

[5] Holbrook, H., Cheriton, D., "IP Cain, B., "Source-Specific Multicast Channels: Experss Support
for Large-scale Single-source Applications", ACM SIGCOMM'99

[11] for IP", Internet
Draft, SSM Working Group, March 2001, draft-holbrook-ssm-arch-02.txt, a
work in progress.

[6] 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.

[12]
2000, a work in progress.

[7] Luby, M., Gemmell, J., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,

^L
Crowcroft, J., "RMT BB: BB Forward Error Correction Codes", Internet Draft
draft-ietf-rmt-bb-fec-01.txt, November 2000.

[13] Mankin, A., Romanow, A., Brander,
draft-ietf-rmt-bb-fec-03.txt, July 2001.

[8] Luby, M., Hernek, D., Kushi, D., Rasmussen, L., Simu, S., Paxson, V., "IETF Criteria 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] Rizzo, L., "Effective Erasure Codes for Evaluating Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication Review,
Vol.27, No.2, pp.24-36, Apr 1997.

^L

[11] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:
Multicast Transport and Application Protocols,"
RFC2357, June 1998.

[14] J. Postel, "User Datagram Protocol", RFC768, August 1980.

[15] Source Authentication Transform", draft-irtf-smug-
tesla-00.txt, November, 2000, a work in progress.

[12] 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, Greece, June
1997.

[16]

[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., Rizzo, L., "Effective Erasure Codes for Sumanasekera, R., Vicisano, L.,
"PGM Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication Review,
Vol.27, No.2, pp.24-36, Apr 1997.

[17] Transport Protocol", draft-speakman-pgm-spec-06.txt, a
work in progress.

[14] 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.

[18]

[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.  Authors' Addresses

   Michael Luby
   luby@digitalfountain.com
   Digital Fountain
   600 Alabama Street
   San Francisco,
   39141 Civic Center Drive
   Suite 300
   Fremont, CA, USA, 94110 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.,

^L
   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.  Full Copyright Statement

Copyright (C) The Internet Society (2000).  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
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."

^L