Internet Engineering Task Force                                   RMT WG
INTERNET-DRAFT                                   M.Luby/Digital Fountain
draft-ietf-rmt-bb-lct-03.txt
draft-ietf-rmt-bb-lct-04.txt                         J.Gemmell/Microsoft
                                                        L.Vicisano/Cisco
                                            L.Rizzo/ACIRI and Univ. Pisa
                                                         M.Handley/ACIRI
                                                        J. Crowcroft/UCL
							21 November 2001
                                                         8 February 2002
                                                    Expires: May August 2002

                Layered Coding Transport:
     A massively scalable content delivery transport 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. RFC2026 [1].  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 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 Transport (LCT) provides transport level
     support for reliable content delivery and stream delivery

^L
     transport, hereafter referred to as LCT.
     protocols.  LCT can be used for
     multi-rate delivery is specifically designed to large sets of receivers.  In LCT,
     scalability and congestion control are supported through the support protocols
     using IP multicast, but also provides support to protocols
     that use of layered coding techniques. Coding techniques can be
     combined with unicast.  LCT to provide support for reliability.

     Congestion control is receiver driven, and can be achieved by
     sending packets in the session compatible with congestion control
     that provides muliple rate delivery 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 also
     compatible with coding techniques that provide reliable
     delivery of content.

                           Table of Contents

     1. Introduction. . . . . . . . . . . . . . . . . . . . . .   4
      1.1. Related Documents.
     2. Rationale . . . . . . . . . . . . . . . . .   6
      1.2. Environmental Requirements and Considerations. . . .   7
     2. General Architecture. . . .   4
     3. Functionality . . . . . . . . . . . . . . . . . . . . .   5
     4. Applicability . . . . . . . . . . . . . . . . . . . . .   8
      4.1. Environmental Requirements and Considerations. . . .   9
      2.1.
      4.2. Delivery service models. . . . . . . . . . . . . . .  11
      2.2.
      4.3. Congestion Control . . . . . . . . . . . . . . . . .  12
     3. LCT header. . . . . .
     5. Packet Header Fields. . . . . . . . . . . . . . . . . .  12
      3.1.
      5.1. Default LCT header format. . . . . . . . . . . . . .  13
      3.2.
      5.2. Header-Extension Fields. . . . . . . . . . . . . . .  18
     4. Procedures.  19
     6. Operations. . . . . . . . . . . . . . . . . . . . . . .  21
      4.1.  22
      6.1. Sender Operation . . . . . . . . . . . . . . . . . .  21
      4.2.  22
      6.2. Receiver Operation . . . . . . . . . . . . . . . . .  23
     5.  24
     7. Requirements from Other Building Blocks . . . . . . . .  25
     8. Security Considerations . . . . . . . . . . . . . . . .  24
     6.  26
     9. IANA Considerations . . . . . . . . . . . . . . . . . .  24
     7.  27
     10. Intellectual Property Issues. . Issues . . . . . . . . . . . .  24
     8. Acknowledgments .  27
     11. Acknowledgments. . . . . . . . . . . . . . . . . . . .  25
     9. References.  27
     12. References . . . . . . . . . . . . . . . . . . . . . .  25
     10.  27
     13. Authors' Addresses . . . . . . . . . . . . . . . . . .  26
     11.  29
     14. Full Copyright Statement . . . . . . . . . . . . . . .  28

^L  31

1.  Introduction

This document describes a massively scalable reliable content delivery
and stream delivery transport, transport level support, Layered Coding Transport
(LCT), for
multi-rate multiple rate content delivery primarily designed to be used
with the IP 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 delivery.

LCT is

This document describes a building block as defined in RFC3048.	Protocol instantiations
may RFC3048 [26].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be built by combining the interpreted as described in RFC2119 [2].

2.  Rationale

LCT framework with other components.  A
complete protocol instantiation provides transport level support for massively scalable protocols
using the IP multicast network service.  The support that uses LCT must include a congestion
control protocol that provides
is compatible with LCT common to a variety of very important applications, including
reliable content delivery and streaming applications.

An LCT session comprises multiple channels originating at a single
sender that conforms are used for some period of time to
RFC2357.  A complete protocol instantiation carry packets pertaining
to the transmission of one or more objects that uses LCT may include can be of interest to
receivers.  The logic behind defining a
scalable reliability protocol session as originating from a
single sender is that this is compatible with LCT, it may
include an the right granularity to regulate packet
traffic via congestion control.  One rationale for using multiple
channels within the same session is that there are massively scalable
congestion control protocol protocols that use multiple channels per session.
These congestion control protocols are considered to be layered because
a receiver joins and leaves channels in a layered order during its
participation in the session.  The use of layered channels is also
useful for streaming applications.

There are coding techniques that provide massively scalable reliability
and asynchronous delivery which are compatible with LCT, both layered
congestion control and it
may include other protocols such as security protocols.

LCT with LCT.  When all are combined the result is presumed to a
massively scalable reliable asynchronous content delivery protocol that
is network friendly.  LCT also provides functionality that can be used with an underlying network or transport
service
for other applications as well, e.g., layered streaming applications.

LCT avoids providing functionality that is a "best effort" service that does not guarantee packet
reception, packet reception order, and which massively scalable.  For
example, LCT does not have provide any mechanisms for sending information
from receivers to senders, although this does not rule out protocols
that both use LCT and do require sending information from receivers to
senders.

LCT includes general 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 control that must be used
but does not specify which congestion control or reliability should be
done carefully to avoid severe scalability limitations, especially in
presence of heterogeneous sets of receivers.

Packets with LCT headers are carried in LCT channels. An LCT channel used.  The
rationale for this is
defined that congestion control must be provided by the combination of a sender any
protocol that is network friendly, and an address associated with yet the channel by different applications
that can use LCT will not have the sender.  A receiver may join same requirements for congestion
control. For example, a channel to start
receiving the data packets sent content delivery protocol may strive to the channel by use all
available bandwidth between receivers and the sender, and thus it must
drastically back off its rate when there is competing traffic.  On the
other hand, a
receiver streaming delivery protocol may leave a channel strive to stop receiving data packets from the
channel.

An LCT session consists of maintain a set
constant rate instead of logically grouped LCT channels
associated with a single sender carrying packets with LCT headers for
one or more objects.  Congestion control that conforms trying to RFC2357 must
be used between receivers use all available bandwidth, and the sender thus
it may not back off its rate as fast when there is competing traffic.

Beyond support for each congestion control, LCT session.
Congestion control refers to the ability to adapt throughput to the
available bandwidth on the path from the sender to provides a receiver, and to
share bandwidth fairly with competing flows such as TCP. Thus, the total
flow number of packets flowing to each receiver participating in an fields
and supports functionality commonly required by many protocols.  For
example, LCT session
must not compete unfairly with existing flow adaptive protocols such as
TCP.

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

^L

more than one channel and the sender sends packets to the channels in
the
identify which session at rates that do not depend on the receivers.  Each each received packet belongs to.  This is
important because a receiver
adjusts its reception rate during its participation in the session by
joining may be joined to many sessions
concurrently, and leaving channels dynamically depending on the available
bandwidth thus it is very useful to the sender independent of all other receivers.  Thus, be able to demultiplex
packets as they arrive according to which session they belong to.  As
another example, LCT provides optional support for
multi-rate protocols, the reception rate of identifying which
object each receiver may vary
dynamically independent packet is carrying information about.  Thus, LCT provides
many of the other receivers.

For single-rate protocols, a commonly used fields and support for functionality required
by many protocols.

3.  Functionality

An LCT session typically consists of a set of logically grouped LCT channels
associated with a single sender carrying packets with LCT headers for
one or more objects.  An LCT channel
and is defined by the combination of a
sender sends packets to and an address associated with the channel at variable rates over time
depending on feedback from receivers. Each by the sender.  A
receiver remains joined joins a channel to start receiving the channel during its participation in data packets sent to the session.  Thus, for single-
rate protocols,
channel by the reception rate of each sender, and a receiver may vary dynamically
but in coordination with all receivers.  Generally, leaves a multi-rate
protocol channel to stop receiving
data packets from the channel.

LCT is preferable meant 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 combined with other building blocks so that the
resulting overall protocol is described in [10].

Layered coding massively scalable.  Scalability refers to
the ability to produce a coded stream of
packets that can be partioned into an ordered set behavior of layers.  The coding
is meant the protocol in relation to provide some form the number of reliability, receivers and
network paths, their heterogeneity, and the layering is meant ability to allow accommodate
dynamically variable sets of receivers.  Scalability limitations can
come from memory or processing requirements, or from the receiver experience  (in terms amount of quality
feedback control and redundant data packet traffic generated by the
protocol.  In turn, such limitations may be a consequence of playout, the
features that a complete reliable content delivery or
overall transfer speed) stream delivery
protocol is expected to vary in provide.

The LCT header provides a predictable way depending on how
many consecutive layers number of fields that are useful for conveying

in-band session information to receivers.  One of packets the receiver required fields is receiving.

Layered coding can be naturally combined with multi-rate congestion
control.  For example,
the sender could send Transmission Session ID (TSI), which allows the packets for each layer
to receiver of a separate channel associated with the session, and then receivers
dynamically join and leave channels
session to adjust their reception rate
according uniquely identify received packets as part of the session.
Another required field is the Congestion Control Information (CCI),
which allows the receiver to perform the multi-rate required congestion control protocol.

Layered coding can also be combined with single-rate congestion control. on
the packets received within the session.  Other LCT fields provide
optional but often very useful other information for the session.  For
example, the sender could dynamically vary how many layers are sent
to Transport Object Identifier (TOI) identifies which object
the channel associated with packet contains data for.  As other examples, the session as Sender Current
Time (SCT) conveys the rate of transmission
varies according to time when the single-rate congestion control protocol.

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

The concept amount of layered coding can
time the session will be naturally extended to reliable
content delivery protocols when Forward Error Correction (FEC)
techniques are used continue for, flags for coding the data stream [9] [7] [3] [11] [2]. By

^L

using FEC, indicating the data stream is transformed in such a way that
reconstruction close of a data object does not depend on
the reception of
specific data packets, but only on session and the number close of different sending 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 an object, and header
extensions for fields that for example can be
found in [5].  Reliable protocols aim at giving guarantees on the
reliable delivery of data from used for packet
authentication.

LCT provides support for congestion control.  Congestion control MUST be
used that conforms to RFC2357 [16] between receivers and the sender for
each LCT session.  Congestion control refers to the intended recipients.
Guarantees vary from simple packet data integrity ability to reliable delivery
of a precise copy of an object adapt
throughput 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.

Two of the key difficulties in scaling reliable content delivery using
IP multicast are dealing with available bandwidth on the amount of data that flows path from
receivers back to the sender, sender to a
receiver, and the associated response (generally
data retransmissions) from the sender.	Protocols that avoid any to share bandwidth fairly with competing flows such
feedback, and minimize as
TCP. Thus, the amount total flow of retransmissions, can be massively
scalable. packets flowing to each receiver
participating in an LCT session MUST NOT compete unfairly with existing
flow adaptive protocols such as TCP.

A multiple rate or a single rate congestion control protcol can be used in conjunction
with FEC codes or LCT.  For multiple rate protocols, a layered
codec to achieve reliability with little or no feedback.

Scalability refers session typically consists of
more than one channel and the sender sends packets to the behavior of channels in
the protocol session at rates that do not depend on the receivers.  Each receiver
adjusts its reception rate during its participation in relation to the
number of receivers and network paths, their heterogeneity, session by
joining and leaving channels dynamically depending on the
ability available
bandwidth to accommodate dynamically variable sets the sender independent of all other receivers.
Scalability limitations can come from memory or processing requirements,
or from  Thus, for
multiple rate protocols, the amount reception rate of packet traffic generated by the protocol.  In
turn, such limitations each receiver may be vary
dynamically independent of the other receivers.

For single rate protocols, a consequence session typically consists of one channel
and the features that sender sends packets to the channel at variable rates over time
depending on feedback from receivers. Each receiver remains joined to
the channel during its participation in the session.  Thus, for single
rate protocols, the reception rate of each receiver may vary dynamically
but in coordination with all receivers.  Generally, a
complete reliable content delivery or stream delivery multiple rate
protocol is
expected preferable to provide.

In this document we present the architecture and abstract LCT header
structure, a single rate protocol in a heterogeneous
receiver environment, since generally it more easily achieves
scalability to many receivers and describe its support for provides higher throughput to each
individual receiver.  Some possible multiple rate congestion control.

The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document control
protocols are to be interpreted as described in RFC2119.

1.1.  Related Documents

As [25] and [3]. A possible single rate
congestion control protocol is described in RFC3048, LCT is [22].

Layered coding refers to the ability to produce a building block coded stream of
packets that is intended to can be
used, in conjunction with other building blocks, partioned into an ordered set of layers.  The coding
is meant to help specify a
protocol instantiation.  A congestion control building block that uses provide some form of reliability, and the Congestion Control information field within layering is meant
to allow 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 receiver experience  (in terms of the use quality of FEC in Reliable Multicast

^L

Transport (RMT) protocols is given playout, or
overall transfer speed) to vary in [5]. Some a predictable way depending on how
many consecutive layers of packets the FEC codecs that
may be used in conjunction with LCT for reliable content delivery are
specified in [6]. The Codepoint field in the LCT header receiver is an opaque
field that receiving.

Layered coding can be used to carry information related to naturally combined with multiple rate congestion
control.  For example, the encoding of sender could send the packet payload.

Implementors of protocol instantiations that use LCT must also implement
congestion control in accordance packets for each layer
to RFC2357, where the congestion
control is over a separate channel associated with the entire session.  Some possible schemes are specified
in [11] session, and [1]. The Congestion Control Information field in the LCT
header is an opaque field that is reserved then receivers
dynamically join and leave channels to carry information related adjust their reception rate
according to the multiple rate congestion control.	There may control protocol.

Layered coding can also be congestion control Header
Extension fields that carry additional information related to combined with single rate congestion control.

Generic Router Assist may be used in conjunction
For example, the sender could dynamically vary how many layers are sent
to the channel associated with LCT.

It is recommended that LCT implementors use some packet authentication
scheme the session as the rate of transmission
varies according to protect the protocol from attacks. An example single rate congestion control protocol.

The concept of layered coding was first introduced with reference to
audio and video streams.  For example, the information associated with a possibly
suitable scheme is described in [8].

1.2.  Environmental Requirements
TV broadcast could be partitioned into three layers, corresponding to
black and Considerations

LCT is intended white, color, and HDTV quality. Receivers can experience
different quality without the need for congestion controlled delivery the sender to replicate
information in the different layers.

The concept of objects and
streams (both layered coding can be naturally extended to reliable
content delivery and streaming of multimedia
information).

LCT is most applicable protocols when Forward Error Correction (FEC)
techniques are used for delivery of objects or streams coding the data stream.  Descriptions of substantial
length, i.e., objects or streams that range this
can be found in length from hundreds of
kilobytes to many gigabytes, [23], [21], [7], [25] and whose transfer time [4]. By using FEC, the data
stream is transformed in the order of
tens such a way that reconstruction of seconds or more.

LCT can be used with both multicast and unicast delivery.  LCT requires
connectivity between a sender and receivers, but data object
does not require
connectivity from receivers to a sender.  LCT inherently works with all
types of networks, including LANs, WANs, Intranets, depend on the Internet,
asymmetric networks, wireless networks, and satellite networks.  Thus,
the inherent raw scalability reception of LCT is unlimited.  However, when other specific applications are built data packets, but only on top
the number of LCT, then these applications different packets received.  As a result, by their very nature may limit scalability.  For example, if an
application requires receivers to retrieve out increasing
the number of band information in
order to join layers a session, or an application allows receivers to send
requests back to receiver is receiving from, the sender to report reception statistics, then receiver can
reduce the transfer time accordingly.  Using FEC to provide reliability
can increase scalability dramatically in comparison to other methods for
providing reliability.  More details on the use of FEC for reliable
content delivery can be found in [14].

Reliable protocols aim at giving guarantees on the application is limited by reliable delivery of
data from the ability to send,
receive, and process this additional data.

LCT requires receivers sender to be able the intended recipients.  Guarantees vary from
simple packet data integrity to uniquely identify and demultiplex
packets associated with an LCT session.  In particular, there must be reliable delivery of a

^L

Transport Session Identifier (TSI) associated with each LCT session.
The TSI is scoped by precise copy of
an object to all intended recipients.  Several reliable content delivery
protocols have been built on top of IP multicast using methods other
than FEC, but scalability was not the primary design goal for many of
them.

Two of the key difficulties in scaling reliable content delivery using
IP address multicast are dealing with the amount of data that flows from

receivers back to 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 associated response (generally
data retransmissions) from the TSI for sender.  Protocols that avoid any such
feedback, and minimize the session.  If Generic
Router Assist (GRA) is being used then additional dependencies may amount of retransmissions, can be
introduced by GRA on the TSI field.  GRA work is ongoing within the RMT
working group at this time.  The TSI value must massively
scalable.  LCT can be the same used in all
places it occurs within conjunction with FEC codes or a packet.  If there is layered
codec to achieve reliability with little or no underlying TSI
provided feedback.

Protocol instantiations MAY be built by combining the network, transport or any LCT framework with
other layer, then the TSI must
be included in the components.  A complete protocol instantiation that uses LCT MUST
include a congestion control protocol that is compatible with LCT header.

There are currently two models of multicast delivery, the Any-Source
Multicast (ASM) model as defined in RFC1112 and the Source-Specific
Multicast (SSM) model as defined in [4].
that conforms to RFC2357 [16]. A complete protocol instantiation that
uses LCT works with both multicast
models, but in MAY include a slightly different way scalable reliability protocol that is compatible
with somewhat different
environmental concerns.  When using ASM, LCT, it MAY include an session control protocol that is compatible
with LCT, and it MAY include other protocols such as security protocols.

4.  Applicability

An LCT session comprises a logically related set of one or more LCT
channels originating at a single sender S sends that are used for some period of
time to carry packets containing LCT headers pertaining to a
multicast group G, and the LCT channel address consists
transmission of one or more objects that can be of the pair
(S,G), where S interest to
receivers.

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

As an example, an LCT session could be used to deliver a multicast
group address.	When TV program
using SSM, a sender S sends three LCT channels.  Receiving packets to an SSM
channel (S,G), and from the first LCT channel address coincides with the SSM
channel address.

A sender can locally allocate unique SSM channel addresses,
could allow black and white reception, receiving the first two LCT
channels could also permit color reception, whereas receiving all three
channels could allow HDTV quality reception.  Objects in this
makes allocation of example
could correspond to individual TV programs being transmitted.

As another example, a reliable LCT channel addresses easy with SSM.  To allocate session could be used to reliably
deliver hourly-updated weather maps (objects) using ten LCT channel addresses channels at
different rates, using ASM, the sender must uniquely chose FEC coding.  A receiver may join and concurrently
receive packets from subsets of these channels, until it has enough
packets in total to recover the ASM
multicast group address across object, then leave the scope of session (or
remain connected listening for session description information only)
until it is time to receive the group, and next object.  In this makes
allocation of LCT channel addresses more difficult with ASM.

LCT channels and SSM channels coincide, and thus case, the quality
metric is the receiver will only time required to receive packets sent each object.

Before joining a session, the receivers MUST obtain enough of the
session description to start the requested LCT channel.  With ASM, session.  This MUST include the
receiver joins an LCT channel
relevant session parameters needed by joining a multicast group G, and all
packets sent receiver to G, regardless of participate in the sender, may be received

session, including all information relevant to congestion control.  The
session description is determined by the
receiver.  Thus, SSM has compelling security advantages over ASM for
prevention of denial of service attacks.  In either case, receivers
should use mechanisms sender, and is typically
communicated to filter out packets from unwanted sources.

LCT also requires the receivers to obtain Session Description Information, out-of-band. In some cases, as described in Section 4.1. The
later, parts of the session description could be in that are not required to
initiate a form
such as SDP as defined session MAY be included in RFC2327, or XML metadata, the LCT header or HTTP/Mime headers
as defined in RFC2068, and distributed with SAP as defined communicated to
a receiver out-of-band after the receiver has joined the session.

An encoder MAY be used to generate the data that is placed in RFC2974,
using HTTP, or the packet
payload in other ways.

The particular layered encoder and congestion control protocols order to provide reliability.  A suitable decoder is used
with to
reproduce the original information from the packet payload.  There MAY
be a reliability header that follows the LCT have header if such an impact encoder
and decoder is used.  The reliability header helps to describe the
encoding data carried in the payload of the packet.  The format of the
reliability header depends on the performance coding used, and applicability of LCT.
For this is negotiated
out-of-band.  As an example, some layered encoders used for video and audio streams can
produce a very limited number one of layers, thus providing a very coarse
control in the reception FEC headers described in [15]
could be used.

For LCT, when multiple rate of packets congestion control is used, congestion
control is achieved by receivers in sending packets associated with a session.

^L

When given session
to several LCT is used for reliable data transfer, some FEC codecs are
inherently limited in the size channels.  Individual receivers dynamically join one or
more of these channels, according to the object they can encode, and for
objects larger than this size network congestion as seen by
the reception overhead on receiver.  LCT headers include an opaque field which MUST be used to
convey congestion control information to the receivers
can grow substantially.

Some networks are not amenable receivers.  The actual
congestion control scheme to some use with LCT is negotiated out-of-band.
Some examples of congestion control protocols that
could may be suitable for
content delivery are described in [25] and [3]. Other congestion
controls may be suitable when LCT is used with LCT.  In particular, for a satellite streaming application.

This document does not specify and restrict the type of exchanges
between LCT (or any PI built on top of LCT) and an upper application.
Some upper APIs may use an object-oriented approach, where the only
possible unit of data exchanged between LCT (or any PI built on top of
LCT) and an application, either at a source or at a receiver, is an
object. Other APIs may enable a sending or wireless
network, there may be no mechanism for receivers receiving application to effectively reduce
their reception rate since there may be
exchange a fixed transmission rate
allocated to the session.

Some protocol instantiations that use subset of an object with LCT may require the generation (or any PI built on top of
feedback from the receivers to the sender.  For example, Generic Router
Assist LCT),
or may be used to help in passing real-time statistics in even follow a scalable
manner from receivers back to the sender. However, the mechanism for
doing this is streaming model.  These considerations are outside
the scope of LCT.

2.  General Architecture

An LCT session comprises a logically related set of one or more this document.

4.1.  Environmental Requirements and Considerations

LCT
channels originating at a single sender that are used is intended for some period of
time to carry packets containing LCT headers pertaining to the
transmission congestion controlled delivery of one or more objects that can be of interest to
receivers.

For example, an LCT session could be used to deliver a TV program using
three LCT channels.  Receiving packets from the first LCT channel could
allow black and white reception, receiving the first two LCT channels
could also permit color reception, whereas receiving all three channels
could allow HDTV quality reception.  Objects in this example could
correspond to individual TV programs being transmitted.

As another example, a
streams (both reliable content delivery and streaming of multimedia
information).

LCT session could can be used to reliably
deliver hourly-updated weather maps (objects) using ten with both multicast and unicast delivery.  LCT channels at
different rates, using FEC coding.  A receiver may join requires
connectivity between a sender and concurrently
receive packets receivers, but does not require
connectivity from subsets of these channels, until it has enough
packets in total receivers to recover a sender.  LCT inherently works with all

types of networks, including LANs, WANs, Intranets, the object, then leave Internet,
asymmetric networks, wireless networks, and satellite networks.  Thus,
the session (or
remain connected listening for session description information only)
until it inherent raw scalability of LCT is time 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 receive the next object.  In this case, the quality
metric is the time required retrieve out of band information in
order to receive each object.

Before joining join a session, the or an application allows receivers must obtain enough of the
session description to start the session.  This must include the
relevant session parameters needed by a receiver send
requests back to participate in the
session, including all information relevant sender to congestion control.  The
session description report reception statistics, then the
scalability of the application is determined limited by the sender, and is typically
communicated ability to the send,
receive, and process this additional data.

LCT requires receivers out of band. In some cases, as described

^L

later, parts of the session description that are not required to
initiate a session may be included in the LCT header or communicated able to uniquely identify and demultiplex
packets associated with an LCT session.  In particular, there MUST be a receiver out
Transport Session Identifier (TSI) associated with each LCT session.
The TSI is scoped by the IP address of band after the receiver has joined sender, and the IP address of
the sender together with the TSI MUST uniquely identify the session.

An encoder may be used to generate  If
the data that underlying transport is placed in the packet
payload UDP as described in order to provide reliability.  A suitable decoder is used to
reproduce RFC768 [19], then the original information from 16
bit UDP source port number MAY serve as the packet payload.  There may
be a reliability header that follows TSI for the LCT header if such an encoder
and decoder is used. session.  The reliability header helps to describe
TSI value MUST be the
encoding data carried same in the payload of the all places it occurs within a packet.  The format of  If
there is no underlying TSI provided by the
reliability header depends on network, transport or any
other layer, then the coding used, and this TSI MUST be included in the LCT header.

LCT is negotiated
out-of-band.  As 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, one of the FEC headers described Any-Source Multicast
(ASM) model of IP multicast as defined in [6]
could be used.

For LCT, when multi-rate congestion control RFC1112 [5] is used, such a "best
effort" network service.  While the basic service provided by RFC1112 is
largely scalable, providing congestion control
is achieved by sending packets associated with a given session to
several LCT channels.  Individual receivers dynamically join one or more
of these channels, according reliability should be
done carefully to avoid severe scalability limitations, especially in
presence of heterogeneous sets of receivers.

There are currently two models of multicast delivery, the network congestion Any-Source
Multicast (ASM) model as seen by defined in RFC1112 [5] and the
receiver. Source-Specific
Multicast (SSM) model as defined in [10]. LCT headers include an opaque field which must be used to
convey congestion control information works with both multicast
models, but in a slightly different way with somewhat different
environmental concerns.  When using ASM, a sender S sends packets to a
multicast group G, and the receivers.  The actual
congestion control scheme to use with LCT channel address consists of the pair
(S,G), where S is negotiated out-of-band.
Some examples the IP address of congestion control protocols that may be suitable for
content delivery are described in [11] the sender and [1]. Other congestion
controls may be suitable when LCT G is used for a streaming application. multicast
group address.  When using SSM, a sender S sends packets to an SSM
channel (S,G), and the LCT channel address coincides with the SSM
channel address.

A sender can be used locally allocate unique SSM channel addresses, and this
makes allocation of LCT channel addresses easy with other congestion control protocols such as SSM.  To allocate
LCT channel addresses using ASM, the one
described in [11], or Generic Router Assist schemes where sender must uniquely chose the ASM
multicast group address across the selection scope of which packets to forward is performed by routers. This latter
approach potentially allows for finer grain congestion control the group, and a
faster reaction to network congestion, but requires changes this makes
allocation of LCT channel addresses more difficult with ASM.

LCT channels and SSM channels coincide, and thus the receiver will only
receive packets sent to the
router infrastructure.	We do not discuss this approach further in this
document.

This document does not specify and restrict requested LCT channel.  With ASM, the type of exchanges
between
receiver joins an LCT (or any PI built on top of LCT) channel by joining a multicast group G, and an upper application.
Some upper APIs all
packets sent to G, regardless of the sender, may use an object-oriented approach, where be received by the only
possible unit
receiver.  Thus, SSM has compelling security advantages over ASM for
prevention of data exchanged between LCT (or any PI built on top denial of
LCT) and an application, service attacks.  In either at case, receivers
SHOULD use mechanisms to filter out packets from unwanted sources.

Some networks are not amenable to some congestion control protocols that
could be used with LCT.  In particular, for a source satellite or at a receiver, is an
object.  Other APIs wireless
network, there may enable a sending or receiving application be no mechanism for receivers to
exchange a subset of an object with LCT (or any PI built on top of LCT),
or effectively reduce
their reception rate since there may even follow be a streaming model.  These considerations are out of fixed transmission rate
allocated to the scope of this document."

2.1. session.

4.2.  Delivery service models

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

^L

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 send 1
KB packets to the first LCT channel at 50 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 rate of 1 KB
packets to all LCT channels is 1,000 packets per second, so that a
receiver could be able to complete reception of the object in as little
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

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

4.3.  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 [11] [25] and [1]. [3]. Different delivery service
models might require different congestion control protocols.

3.  LCT header

5.  Packet Header Fields

Packets sent to an LCT session must MUST include an "LCT header".  The LCT
header format described below is the default format, and this is the
format that is recommended for use by protocol instantiations to ensure

a uniform format across different protocol instantiations.  Other LCT
header formats may MAY be used by protocol instantiations, but if the
default LCT header format is not used by a protocol instantiation that
uses LCT, then the protocol instantiation must MUST specify the lengths and
positions within the LCT header it uses of all fields described in the
default LCT header.

Other building blocks may MAY describe some of the same fields as described
for the LCT header.  It is recommended 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 SHOULD be carried in each packet at most
once.

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

^L

3.1.

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

The format of the default LCT 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|   | C | r  |H|S| |S| O |T|R|A|B| |H|T|R|A|B|   HDR_LEN     | Codepoint (CP)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Congestion Control Information (CCI) (CCI, length = 32*(C+1) bits)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |		     CCI continued (if C = 1)                          ...                                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Transport Session Identifier (TSI, length = 32*S+16*H bits)  |
 |                          ...                                  |
 +								 +
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Transport Object Identifier (TOI, length = 32*O+16*H bits)  |
 |                          ...                                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Sender Current Time (SCT, if T = 1)             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Expected Residual Time (ERT, if R = 1)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Header Extensions (if applicable)              |
 |                          ...                                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 - Default LCT header format

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

  LCT version number (V): 4 bits

^L

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

  Congestion control flag (C): 1 bit 2 bits

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

  Reserved (r): 3 2 bits

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

  Half-word flag (H): 1 bit

      The TSI and the TOI fields are both multiples of 32-bits plus 16*H
      bits in length.  This allows the TSI and TOI field lengths to be
      multiples of a half-word (16 bits), while ensuring that the
      aggregate length of the TSI and TOI fields is a multiple of
      32-bits.

  Transport Session Identifier flag (S): 1 bit

      This is the number of full 32-bit words in the TSI field.  The TSI
      field is 32*S + 16*H bits in length, i.e. the 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.

  Half-word flag (H): 1 bit

      The TSI and the TOI fields are both multiples of 32-bits plus 16*H
      bits in length.  This allows the TSI and TOI field lengths to be
      multiples of a half-word (16 bits), while ensuring that the
      aggregate length of the TSI and TOI fields is a multiple of
      32-bits.

  Sender Current Time present flag (T): 1 bit

      T = 0 indicates that the Sender Current Time (SCT) field is not
      present.
      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.

^L

  Expected Residual Time present flag (R): 1 bit

      R = 0 indicates that the Expected Residual Time (ERT) field is not
      present.
      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 R = 1 when the ERT for the session is more
      than 2^32-1 time units (approximately 49 days), where time is
      measured in units of milliseconds.

  Close Session flag (A): 1 bit

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

  Close Object flag (B): 1 bit

      Normally, B is set to 0.  The sender may MAY set B to 1 when
      termination of transmission of packets for an object is imminent.
      If the TOI field is in use and B is set to 1 then termination of
      transmission for the object identified by the 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 out-of-band information is imminent.  B may MAY be set
      to 1 in just the last packet transmitted for the object, or B may 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 for a
      particular object, the sender should SHOULD set B to 1 in all subsequent
      packets for the object until termination of transmission of
      packets for the object.  A received packet with B set to 1
      indicates to a receiver that the sender will immediately stop
      sending packets for the object.  When a receiver receives a packet
      with B set to 1 then it should SHOULD assume that no more packets will be
      sent for the object to the session.

^L

  LCT header length (HDR_LEN): 8 bits

      Total length of the LCT header in units of 32-bit words.  The
      length of the LCT header must MUST be a multiple of 32-bits.  This
      field can be used to directly access the 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. RFC1889 [24].

  Congestion Control Information (CCI): 32 32, 64, 96 or 64 128 bits

      Used to carry congestion control information.  For example, the
      congestion control information could include layer numbers,
      logical channel numbers, and sequence numbers. This field is
      opaque for the purpose of this specification.
      This field must MUST be 32 bits if C=0.
      This field must MUST be 64 bits if C=1.
      This field MUST be 96 bits if C=2.
      This field MUST be 128 bits if C=3.

  Transport Session Identifier (TSI): 0, 16, 32 or 48 bits

      The TSI uniquely identifies a session among all sessions from a
      particular sender.  The TSI is scoped by the IP address of the
      sender, and thus the 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 identifies a session,
      whether or not the TSI is included 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 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 MUST be the same value.  If there is
      no underlying TSI provided by the network, transport or any other
      layer, then the TSI must MUST be included in the LCT header.

^L

      The TSI must 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 is outside the scope of
      this document and is to be done out of band. 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 is outside the scope of this document and is to
      be done out of band. out-of-band.  The TOI field must MUST be used in all packets if
      more than one object is to be transmitted in a session, i.e. the
      TOI field is either present in all the packets of a session or is
      never present.
      The length of the TOI field 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

      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 T=0 and must MUST be present if T=1.

  Expected Residual Time (ERT): 0 or 32 bits

^L

      This field represents the 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 TOI field, otherwise it refers to the
      session.
      This field must not MUST NOT be present if R=0 and must MUST be present if R=1.

3.2.

5.2.  Header-Extension Fields

Header Extensions are used in LCT to accommodate optional header fields
that are not always used or have variable size.  Examples of the use of
Header Extensions include:

  o Extended-size 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 a packet. The default action for unrecognized header
extensions is to ignore them. This allows the future introduction of
backward-compatible enhancements to LCT without changing the LCT version
number.  Non backward-compatible header extensions CANNOT be introduced
without changing the LCT version number.

Protocol instantiation may 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 127. The second format is used
for fixed length (one 32-bit word) extensions, using HET values from 127
to 255.

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

Figure 5 - Format of additional headers

The explanation of each sub-field is the following.

  Header Extension Type (HET): 8 bits

      The type of the Header Extension. This document defines a number
      of possible types. Additional types may be defined in future
      version
      versions of this specification. HET values from 0 to 127 are used
      for variable-length Header Extensions. HET values from 128 to 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 127) and must not MUST NOT be
      present for fixed-length extensions (HET between 128 and 255).

  Header Extension Content (HEC): variable length

      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 header, including all Header Extensions and all optional

^L
      header fields, cannot exceed 255 32-bit words.

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

General LCT extensions are intended to allow the introduction of
backward-compatible enhancements to LCT without changing the LCT version
number.  Non backward-compatible header extensions CANNOT be introduced
without changing the LCT version number.

PI-specific extensions are reserved for PI-specific use with semantic
and default parsing actions defined by the 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_AUTH=1    Packet authentication extension
              Information used to authenticate the sender of the packet.
	      If present, the
              The format of this Header Extension and its processing must is
              outside the scope of this document and is to be
              communicated out-of-band as part of the session
              description.
              It is recommended RECOMMENDED that senders provide some form of packet
              authentication.  If EXT_AUTH is present, whatever packet
              authentication checks that can be performed immediately
              upon reception of the packet must SHOULD be performed before
              accepting the packet and 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 postponed
              by any such full packet authentication.

All senders and receivers implementing LCT must MUST support the EXT_NOP
Header Extension and must MUST recognize EXT_AUTH, but may not MAY NOT be able to
parse its content.

^L

4.  Procedures

4.1.

6.  Operations

6.1.  Sender Operation

A sender using

Before joining an LCT must make session a receiver MUST obtain a session
description.  The session description available to clients
that want to join an LCT session.  This information could include, but
is not limited to: MUST include:

  o The sender IP address;

  o The number of LCT channels;

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

  o The formats of any other headers.  For example, an FEC header as
    described in [6] could be such an 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 format and lengths of the packet payload;

  o The Transport Session ID (TSI) to be used for the session;

  o Whether or not Generic Router Assist (GRA) is Enough information to determine the congestion control protocol
    being used;

  o The congestion control Enough information to determine the packet authentication scheme
    being used; used if it is being used.

The session description could also include, but is not limited to:

  o The data rates used for each LCT channel;

  o The length of the packet payload;

  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 client packet authentication
    purposes;

Some of the session description information

Protocol instantiations using LCT MAY place additional requirements on
what must be obtained by
receivers before they connect to the session.  This includes the number
and addresses of included in the LCT channels, session description.  For example, a
protocol instantiation might require that the TSI value data rates for each
channel, or the session, the
formats of any other headers, the congestion control scheme being used
and the packet authentication scheme if it is used.  Some mapping of the session
description information may be obtained by receivers while they are
connected TOI value(s) to objects for the session, e.g., or
other information relevant related to objects being
transported within other headers that might be required to be
included in the session such as their TOI, when they are
available within the session, for how long, and their lengths.

^L description.

The session description could be in a form such as SDP as defined in
RFC2327,
RFC2327 [8], or XML metadata, metadata as defined in RFC3023 [17], or HTTP/Mime headers,
headers as defined in RFC2068 [6], etc.  It might be carried in a
session announcement protocol such as SAP as defined in RFC2974, RFC2974 [9],
obtained using a proprietary session control protocol, located on a Web

page with scheduling information, or conveyed via E-mail or other out of
band 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, session a sender using LCT transmits a sequence of packets
each in a the format defined in the session description. above.  Packets are sent from a sender using
one or more LCT channels which together constitute a session.
Transmission rates may be different in different 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 order in which 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

Several objects can be carried within the same LCT session.  In this
case, each object must 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 packets in a session until
the transmission is considered complete.  The transmission may be
considered complete when some time has expired, a certain number of
packets have been sent, or some out of band out-of-band signal (possibly from a
higher level protocol) has indicated completion by a sufficient number
of receivers.

For the reasons mentioned above, this document does not pose any
restriction on packet sizes. However, network efficiency considerations
recommend that the sender uses as large as possible packet payload size,
but in such a way that 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 recommended that all 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 [11] [25] and [1]. [3].  A sender of

^L
packets using LCT must MUST implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357 [16] using
the Congestion Control Information field provided in the LCT header, and
the corresponding receiver congestion control scheme is to be
communicated out-of-band and MUST be implemented by any receivers

participating in the session.

6.2.  Receiver Operation

Receivers can operate differently depending on the delivery service
model.  For example, for an on demand service model receivers 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 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 obtain the
relevant session description information as listed in Section 6.1.

If packet authentication information is present in an LCT header, it
SHOULD be used as specified in Section 5.2.  To be able to be a receiver
in a session, the receiver MUST be able to process the LCT header.  The
receiver MUST be able to discard, forward, store or process the other
headers and the packet payload.  If a receiver is not able to process a
LCT header, it MUST drop from the session.

To be able to participate in a session, a receiver MUST implement the sender-side part of one of the
congestion control schemes that is protocol specified in accordance with RFC2357 the session description using
the Congestion Control Information field provided in the LCT header, and the
corresponding header. If
a receiver is not able to implement the congestion control scheme must be communicated
out of band and implemented by any receivers participating protocol used
in the session, it MUST NOT join the session.

4.2.  Receiver Operation

Receivers can operate differently depending on  When the delivery service
model.	For example, for an session is
transmitted on demand service model multiple LCT channels, receivers may MUST initially join
channels according to the specified startup behavior of the congestion
control protocol. For a multiple rate congestion control protocol that
uses multiple channels, this typically means that a receiver will
initially join only a
session, obtain minimal set of LCT channels, possibly a single
one, that in aggregate are carrying packets at a low rate.  This rule
has the necessary encoding symbols to reproduce purpose of preventing receivers from starting at high data
rates.

Several 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 packets for an
old object before starting to transmit packets for a new object, both
the network and then leave the session.  As another example, underlying protocol layers can cause some reordering
of packets, especially when sent over different LCT channels, and thus
receivers SHOULD 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 a streaming service
model a some amount of time.

A receiver may MAY be continuously concurrently joined to a set of multiple LCT sessions from one
or more senders. The receiver MUST perform congestion control on each

such LCT channels to
download all objects in a session.

To be able to participate  If the congestion control protocol allows the
receiver some flexibility in terms of its actions within a session, a session then
the receiver must first obtain MAY make choices to optimize the
relevant session description information as listed in Section 4.1.

If packet authentication information is present in an flow performance
across the multiple LCT header, it
should be used sessions, as specified long as the receiver still adheres
to the congestion control rules for each LCT session individually.

7.  Requirements from Other Building Blocks

As described in Section 3.2.  To be able RFC3048 [26], LCT is a building block that is intended
to be a receiver used, in conjunction with other building blocks, to help specify a session,
protocol instantiation.  A congestion control building block that uses
the receiver must be able to process Congestion Control information field within the LCT header.  The
receiver must header MUST be able to discard, forward, store or process the other
headers
used by any protocol instantiation that uses LCT, and the packet payload.  If other building
blocks MAY also be used, such as a receiver is not able reliability building block.

The congestion control MUST be applied to process a the LCT header, it must drop from session as an entity,
i.e., over the session.

To be able to participate in a session, a receiver must implement aggregate of the
congestion control protocol traffic carried by all of the LCT
channels associated with the LCT session. Some possible schemes are
specified in the session description using
the [25] and [3]. The Congestion Control Information field provided in
the LCT header. If
a receiver header is not able an opaque field that is reserved to implement the carry information
related to congestion control.  There MAY also be congestion control protocol
Header Extension fields that carry additional information related to
congestion control.

The particular layered encoder and congestion control protocols used
in the session, it must not join the session.  When the session is
transmitted on multiple
with LCT channels, receivers must initially join
channels according to have an impact on the specified startup behavior performance and applicability of the congestion
control protocol itself. LCT.
For a example, some layered transmission on multiple
channels, this typically means that a receiver will initially join only encoders used for video and audio streams can
produce a minimal set very limited number of LCT channels, possibly layers, thus providing a single one, that very coarse
control in aggregate
are carrying packets at a low rate.  This rule has the purpose reception rate of
preventing packets by receivers from starting at high data rates.

Multiple objects can be carried either sequentially or concurrently
within the same LCT in a session.  In this case, each object
When LCT is identified by
a unique TOI.  Note that even if a server stops sending packets for an
old object before starting to transmit packets used for a new object, both reliable data transfer, some FEC codecs are
inherently limited in the network and size of the underlying protocol layers object they can cause some reordering
of packets, especially when sent over different LCT channels, encode, and thus
receivers should not assume that for
objects larger than this size the reception overhead on the receivers
can grow substantially.

A more in-depth description of a packet for a new
object means the use of FEC in Reliable Multicast
Transport (RMT) protocols is given in [14]. Some of the FEC codecs that there are no more packets
MAY be used in transit conjunction with LCT for reliable content delivery are
specified in [15]. The Codepoint field in the previous

^L

one, at least for some amount of time.

A receiver may LCT header is an opaque
field that can be concurrently joined used to multiple carry information related to the encoding of
the packet payload.

LCT sessions from one
or more senders. also requires receivers to obtain a session description, as
described in Section 6.1. The receiver must perform congestion control on each session description could be in a form
such LCT session.  If the congestion control as SDP as defined in RFC2327 [8], or XML metadata as defined in
RFC3023 [17], or HTTP/Mime headers as defined in RFC2068 [6], and
distributed with SAP as defined in RFC2974 [9], using HTTP, or in other

ways.  It is RECOMMENDED that an authentication protocol allows such as IPSEC
[11] be used to deliver the
receiver some flexibility in terms of its actions within a session then
the receiver may make choices description to optimize receivers to ensure
the correct session description arrives.

It is recommended that LCT implementors use some packet flow performance
across authentication
scheme to protect the multiple protocol from attacks. An example of a possibly
suitable scheme is described in [18].

Some protocol instantiations that use LCT sessions, as long as MAY use building blocks that
require the receiver still adheres generation of feedback from the receivers to the congestion control rules for each LCT session individually.

5. sender.
However, the mechanism for doing this is outside the scope of LCT.

8.  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 or cause
inaccurate reconstruction of large portions of the objects.

The object by receivers.
LCT is particularly affected by such an attack since many receivers may
receive the same exact problems are present in TCP, where forged packet.  It is therefore RECOMMENDED that an attacker can forge
packets
integrity check be made on received content before delivery to an
application, e.g., by appending an MD5 hash [20] to the content before
it is sent and either slow down or increase then computing the throughput MD5 hash once the content is
reconstructed to ensure it is the same as the sent content.  Moreover,
in order to obtain strong cryptographic integrity protection a digital
signature verifiable by the receiver SHOULD be computed on top of such a
hash value.  It is also RECOMMENDED that protocol instantiations that
use LCT implement some form of packet authentication such as TESLA [18]
to protect against such attacks.  Furthermore, it is RECOMMENDED that
Reverse Path Forwarding checks be enabled in all network routers and
switches along the session,
or replace parts path from the sender to receivers to limit the
possibility of a bad agent injecting forged packets into the multicast
tree data stream path.

Another vulnerability of LCT is the potential of receivers obtaining an
incorrect session description for the session.  The consequences of this
could be that legitimate receivers with forged data. If the stream is
carrying compressed wrong session description
are unable to correctly receive the session content, or otherwise coded data, even that receivers
inadvertently try to receive at a single forged packet
could also cause much higher rate than they are capable
of, thereby disrupting traffic in portions of the network.  To avoid
these problems, it is RECOMMENDED that the receiver authenticate the
session description, for example by using either the ESP (with enabled
authentication service) [13] or AH [12] protocols of IPSEC [11] to
ensure the authenticity of the session description.

A receiver with an incorrect reconstruction or corrupted implementation of the

congestion control building block may affect health of the rest network in
the path between the sender and the receiver, and may also affect the
reception rates of other receivers joined to the data
stream. session.  It is
therefore recommended that protocol instantiations RECOMMENDED that use LCT
implement some form of packet authentication to protect receivers identify themselves
against such attacks.

6. as legitimate
before they receive the session description needed to join the session.

9.  IANA Considerations

No information in this specification is subject to IANA registration.

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

7.

10.  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,
such as reliability protocols, which are proprietary or have pending or
granted patents.

^L

8.

11.  Acknowledgments

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

9.

12.  References

[1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC2026, October 1996.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC2119, March 1997.

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

[4] 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, September 1998.

[3]

[5] Deering, S., "Host Extensions for IP Multicasting", RFC1112, August
1989.

[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Berners-Lee, T.,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC2068, January 1997.

[7] Gemmell, J., Schooler, E., and Gray, J., "Fcast Multicast File
Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.

[4]

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

[9] Handley, M., Perkins, C., Whelan, E., "Session Announcement
Protocol", RFC2974, October 2000.

[10] Holbrook, H. W., "A Channel Model for Multicast," Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer Science,
Stanford, California, August 2001.

[5]

[11] Kent, S., Atkinson, R., "Security Architecture for the Internet
Protocol", RFC2401, November 1998.

[12] Kent, S., Atkinson, R., "IP Authentication Header", RFC2406,
November 1998.

[13] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC2406, November 1998.

[14] 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-01.txt, October 2001, draft-ietf-rmt-info-fec-02.txt, January 2002,
a work in progress.

[6]

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

[7] Rizzo, L., "Effective Erasure Codes
draft-ietf-rmt-bb-fec-06.txt, January 2002.

[16] Mankin, A., Romanow, A., Bradner, S., Paxson V., "IETF Criteria for
Evaluating Reliable Computer
Communication Multicast Transport and Application Protocols", ACM SIGCOMM Computer Communication Review,
Vol.27, No.2, pp.24-36, Apr 1997.

[8]
RFC2357, June 1998.

[17] Murata, M., St.Laurent, S., Kohn, D., "XML Media Types", RFC3023,
January 2001.

[18] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and
Secure Source Authentication for Multicast", Network and Distributed
System Security Symposium, NDSS 2001, pp. 35-46, February 2001.

[9]

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

[20] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April
1992.

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

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

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

^L

[10] Rizzo, L, "PGMCC:

[24] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A TCP-friendly single-rate multicast congestion
control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August
2000.

[11]
Transport Protocol for Real-Time Applications", RFC1889, January 1996.

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

10.

[26] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.,
Luby, M., "Reliable Multicast Transport Building Blocks for One-to-Many
Bulk-Data Transfer", RFC3048, January 2001.

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

   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

^L
   Department of Computer Science
   University College London
   Gower Street,
   London WC1E 6BT, UK

^L

11.

14.  Full Copyright Statement

Copyright (C) The Internet Society (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
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