[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 RFC 3451

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


                       Layered Coding Transport:
                A massively scalable multicast protocol



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 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, hereafter referred to as LCT.



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft                   [Page 1]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


     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 LCT is used for reliable data transfer, the
     coding also provides support for reliability.

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







































Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft                   [Page 2]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


                           Table of Contents


     1. Introduction. . . . . . . . . . . . . . . . . . . . . .   4
      1.1. Related Documents. . . . . . . . . . . . . . . . . .   5
      1.2. Environmental Requirements . . . . . . . . . . . . .   6
     2. General Architecture. . . . . . . . . . . . . . . . . .   8
      2.1. Delivery service models. . . . . . . . . . . . . . .   9
      2.2. Congestion Control . . . . . . . . . . . . . . . . .  10
     3. Packet Formats. . . . . . . . . . . . . . . . . . . . .  11
      3.1. Data-Packet format . . . . . . . . . . . . . . . . .  11
      3.2. Request-Packet format. . . . . . . . . . . . . . . .  12
      3.3. LCT Packet header fields . . . . . . . . . . . . . .  13
      3.4. Transmission Extensions. . . . . . . . . . . . . . .  15
      3.5. Header-Extension Fields. . . . . . . . . . . . . . .  16
     4. Procedures. . . . . . . . . . . . . . . . . . . . . . .  19
      4.1. Sender Operation . . . . . . . . . . . . . . . . . .  19
      4.2. Receiver Operation . . . . . . . . . . . . . . . . .  21
     5. Security Considerations . . . . . . . . . . . . . . . .  23
     6. IANA Considerations . . . . . . . . . . . . . . . . . .  23
     7. Intellectual Property Issues. . . . . . . . . . . . . .  23
     8. Acknowledgments . . . . . . . . . . . . . . . . . . . .  24
     9. Authors' Addresses. . . . . . . . . . . . . . . . . . .  25
     10. Full Copyright Statement . . . . . . . . . . . . . . .  27



























Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft                   [Page 3]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


1.  Introduction

This document describes a massively scalable protocol, Layered Coding
Transport (LCT), for multi-rate content delivery using IP multicast. LCT
supports both reliable and unreliable data transfer, and supports a
congestion control mechanism which conformings to RFC2357.

IP multicast [5] is a "best effort" service and does not guarantee
packet reception, or reception order. Also it does not provide any
support for flow or congestion control. While the basic service provided
by IP multicast is largely scalable, adding features such as congestion
control or reliability on top of it might cause severe scalability
limitations, especially in presence of heterogeneous sets of receivers.

Scalability refers to the behaviour of the protocol in relation to the
number of receivers and network paths, their heterogeneity, and the
ability to accommodate dynamically variable groups.  Scalability
limitations can come from memory or processing requirement, or from the
amount of traffic generated by the protocol.  In turn, such limitations
derive from the features that a multicast transport 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 that protocols implement some form of congestion control so
that they not compete unfairly with existing and adaptive protocols such
as TCP.

Multi-rate protocols aim at splitting the set of receivers into multiple
subsets, according to the available bandwidth each one has to the
source.  Conversely, single-rate multicast protocols make all receivers
in a session experience the same throughput.  The partitioning of
receivers can be done statically or adaptively.

Layered coding refers to the ability to produce a coded stream that can
be split into multiple substreams (transmitted over different multicast
groups). 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
the receiver is joined.  Layered congestion control that is compliant
with RFC 2357 must be used by receivers to dynamically adjust their
reception rate by appropriately joining and or leaving groups carrying
the substreams.

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



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft       Section 1.  [Page 4]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


TV broadcast can be thought as made of 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 protocols when Forward Error Correction (FEC) techniques
are used for coding the data stream [15] [16] [7] [17] [18] [3]. 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 is
receiving from, a receiver can reduce the transfer time accordingly.
More details on the use of FEC for reliable multicast can be found in
[11].  Reliable protocols aim at giving guarantees on the reliable
delivery of data from the source to the intended recipients.  Guarantees
vary from simple data integrity to strict ordering and atomic delivery.
Several reliable multicast 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], an approach which has an impact on near term
deployment.

Two of the key difficulties in scaling reliable 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 a layered codec to achieve reliability with little or no
feedback.

In this document we present the architecture of LCT, and illustrate its
support for multi-rate 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].

1.1.  Related Documents

A more in-depth description of the use of FEC in Reliable Multicast
Transport (RMT) protocols is given in [11]. Some of the FEC codecs that
may be used by LCT for reliable bulk data transfer are specified in
[12]. 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 is specified in [1]. LCT reserves



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft     Section 1.1.  [Page 5]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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

It is recommended that LCT implementors use some authentication scheme
to protect the protocol from attacks. Suitable schemes are discussed in
[]

1.2.  Environmental Requirements

LCT is intended for congestion controlled, multi-rate delivery of
objects (both reliable bulk data transfer and unreliable streaming of
multimedia information).

LCT is most applicable for delivery of objects of substantial length,
i.e., objects 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 layer can deliver and
demultiplex packets for a given LCT session, and supply packet length
information to the LCT receiver. In IP networks, this is normally
achieved by using UDP, or any protocol that can provide an equivalent
service, as the underlying transport protocol.

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, and with the Source Specific
Multicast (SSM) model that is based on [10].  The definition of an LCT
group used throughout this document is slightly different with ISM and
with SSM.  When using ISM, packets of an LCT group are sent to a
multicast group address G.  When using SSM, packets of an LCT group are
sent to a channel address (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 a few reasons.  First, LCT
may use several LCT groups in a session, and the large, local namespace



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft     Section 1.2.  [Page 6]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


for allocating multicast groups in SSM greatly simplifies the address
allocation problem.

Second, LCT over 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 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 when receivers span the global
Internet, as the light weight mechanisms that SSM uses to cross ISP
boundaries (standard BGP+ routing tables) 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 LCT group by joining a channel (S,G) with
SSM, and thus the receiver will only receive packets sent from the
sender S. With ISM, the receiver joins an LCT group by joining a
multicast group G, and all packets sent to G, regardless of their origin
sender, will be received by the receiver.  Thus, SSM has compelling
security advantages over ISM 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], or XML metadata, or
HTTP/Mime headers [6], and distributed with SAP, HTTP or in other ways.

The particular layered encoder and congestion control protocols used by
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 of a session.  When
LCT is used for reliable data transfer, some FEC coders 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.






Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft     Section 1.2.  [Page 7]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


2.  General Architecture

An LCT session comprises all packets sent to one or more LCT groups 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
three groups.  The first group would allow black and white reception,
the first two groups would permit color reception, whereas the set of
three groups delivers HDTV quality images.  Objects in this example
would 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 at
different rates, using FEC coding.  A receiver may join and concurrently
receive packets from subsets of these groups, 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 packet.


A layered encoder is used to generate the data that is placed in the
payload of LCT packets. A suitable decoder is used to extract the
original information from the payload.

LCT congestion control is achieved by sending packets associated with a
given session to several LCT groups. Individual receivers dynamically
join to one or more of these groups, 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 of the algorithms that can be used to
achieve congestion control in LCT is described in [1]. LCT can be used
with other congestion control algorithms such as the one described in
[17], or router-assisted scheme 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 infrastructure.  See [4]
for a preliminary design description.  We do not discuss this approach



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft       Section 2.  [Page 8]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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

This is the basic service model for the delivery of unreliable streams,
such as the TV example of Section 1. In this case the receivers join the
session, and dynamically adapt the number of LCT groups they subscribe
to (and the reception quality) according to the available bandwidth.
Receivers then drop from the session when they are not interested in the
stream anymore.

This service model can also be used for reliable data transfer, in case
of objects that need periodic updates such as the weather maps example
mentioned in Section 1. In this case, receivers join the session and
dynamically adapt the number of LCT groups they subscribe to until they
have accumulated a sufficient number of packets to reconstruct the
object. Afterwards, they 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 to the congestion
control scheme.

As an example, assume that each object to be transmitted has a size of
5000 1KB packets, and objects are updated every hour. The sender could
set the data rate on the lowest LCT group to 5 1KB packets/s, so that
receivers using just this LCT group could complete reception in 1000
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 the start of a transmission.  Furthermore, the sender
could use a number of LCT groups such that the aggregate data rate when
using all LCT groups is 100 1KB packets/s, so that a receiver could be
able to complete reception of a single object in as little 50 seconds
(assuming no loss and that the congestion control mechanism immediately
converges to the use of all LCT groups).





Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft     Section 2.1.  [Page 9]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


On demand delivery model.


This service model is mostly relevant for reliable LCT session, where
the same object is made available by the sender for 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 of the many potential
applications, the appropriate delivery service model, and the additional
mechanisms to support such functionalities 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.


2.2.  Congestion Control

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

A possible congestion control algorithm for reliable LCT sessions is
specified in [1]. Different session types might require a different
congestion control algorithm.







Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 2.2.  [Page 10]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


3.  Packet Formats

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

Some instances of LCT sessions may require the generation of feedback
from the receivers to the sender.  Such information is carried in
Request packets, which are OPTIONAL and have the sole purpose of
implementing the "transmission extension" mechanism described in Section
3.4.  The LCT packet format described in this document is intended to be
used in conjunction to the UDP transport protocol [14], 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 header and an optional payload, as
shown in Figure 1.  When present, the LCT payload immediately follows
the LCT header.

LCT Request Packets only consist of an LCT header, as shown in Figure 2.

LCT Packet Headers have variable size, which is specified by a length
field in the 3dr byte of the header.  In the LCT Packet Header, all
integer fields are carried in "big-endian" or "network order" format,
that is, most significant byte (octet) first.  Bits designated as
"padding" or "reserved" (r) MUST 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 format

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


















Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.1.  [Page 11]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


  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) |    HDR_LEN    | Codepoint (CP)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Congestion Control Information (CCI)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Demux Label (DL, if D = 1)                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Sender Current Time (SCT, if T = 1)             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Expected Residual Time (ERT, if T = 1)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Header Extensions (only present 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 format of Request Packets is shown in Figure 2.















Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.2.  [Page 12]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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

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

  Demux Label Present flag (D): 1 bit

      D = 1 indicates that the Demux Label (DL) field is present. D = 0
      indicates "no DL field".  The DL field contains a 32-bit
      identifier which can be used to filter packets belonging to the
      session.

  Transmission Extension Information Present flag (T): 1 bit

      T = 1 indicates that the Transmission Extension Information (TEI)
      field is present. T = 0 indicates "no TEI field".  The TEI field
      is inserted by senders when they are willing to accept
      Transmission Extension Request packets from the receivers.

  Header Extension Present flag (X): 1 bit

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



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.3.  [Page 13]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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

  Transport Object Identifier (TOI): 10 bits

      The Transport Object Identifier (TOI) field indicates which
      Transport Object within the session this Data packet or Request
      packet pertains to.  For example, a source might send a number of
      files in the same session, using TOI=0 for the first file, TOI=1
      for the second one, etc.


  LCT Header Length (HDR_LEN): 8 bits

      Length of the variable portion of the LCT header in units of
      32-bit words (excluding IP or UDP headers). The total LCT header
      length is (HDR_LEN+2) 32-bit words.
      This field can be used for direct access to the beginning of the
      LCT payload.

  Codepoint (CP): 8 bits

      An opaque identifier which is passed to the payload decoder to
      convey information on the codec being used for the 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 [].

  Congestion Control Information (CCI): 32 bits

      Used to carry Congestion Control Information, e.g. for the scheme
      described in [1] or other congestion control schemes. This field
      is opaque for the purpose of this specification.


  Demux Label (DL): 32 bits (OPTIONAL)

      Used to carry a 32-bit identifier to be used for filtering
      purposes. All LCT packets belonging to the same LCT group MUST
      have the same DL value that has been communicated out of band to
      receivers as part of the session description information.
      Receivers MUST discard packets with a non-matching DL.
      In order to minimize the amount of information to be supplied out
      of band, it is suggested that the same DL is used for all LCT
      layers in the same session.



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.3.  [Page 14]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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

      This field represents the current clock at the sender at the time
      this packet was transmitted, measured in units of 1ms and computed
      modulo 2^32 units.
      SCT is used, in conjunction with the ERT and DET fields, to
      support 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 the expected residual transmission time for
      the current object, measured in units of 1ms. Senders MUST NOT
      include SCT and ERT if the transmission of the current object is
      expected to last for more than 2^32-1 time units (approximately 49
      days).  See Section 3.4 for a detailed description on the use of
      this field.  This field is only present in Data Packets when T=1.


  Desired End Time (DET): 32 bits

      This field represents the desired finish time for the transmission
      of the object, measured in units of 1ms and computed modulo 2^32
      time units. See Section 3.4 for a detailed description on the use
      of this field.  This field is only present in Request Packets when
      T=1.


3.4.  Transmission Extensions

Four fields in the packet headers are used to support the Transmission
Extension mechanism: T, SCT, ERT, DET.  These fields have the following
purposes:

  o to communicate to receivers the expected finish time 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 the data packets, and also include the SCT and ERT fields as follows:

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




Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.4.  [Page 15]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


  o ERT is set to the expected residual transmission time, as known to
    the sender, and measured in units of 1ms.  The maximum value that
    can be accommodated in this field is approximately 49 days.  A
    sender MUST NOT generate these fields if the residual transmission
    time is larger than this maximum value.


The Expected Finish Time (EFT) of the transmission at the sender site
can be computed as
                            EFT = SCT + ERT.

A receiver can determine the Desired Residual Time (DRT) based on
external information, such as the amount of missing data and the
incoming data rate.  DRT is the (estimated) transmission extention
needed, measured from the time of estimation to the time of the desired
end of transmission.  The maximum value for DRT is 2^32-1 units of 1ms
each.  Higher values must be upper bounded to 2^32-1.
A receiver MUST NOT generate Request packets if the reception is likely
to complete before the expected end of the session, i.e. if DRT << ERT .

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

                            DET = SCT + DRT.

The above procedures make requests idempotent.



3.5.  Header-Extension Fields

To allow for additional header fields and to extend the size of some of
the predefined fields, the LCT header contains an additional header
field flag, "X". If "X" is set to 0 then no additional header fields are
included within the LCT header beyond the predefined fields.  When
additional headers beyond the predefined fields are used, the value of
"X" within the LCT header MUST be set to 1.

Examples of use of header extensions include:

  o extended-size version of already existing header fields.

  o Sender and Receiver authentication information.


If present, Header Extensions must be processed before performing any
congestion control procedure or otherwise accepting the packet.  Packets
with unrecognised Header Extensions MUST be discarded by the receiving



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.5.  [Page 16]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


agent, hence the expected use of extentions should be signalled 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 values
between 0 and 63. The second format is used for fixed length (one word)
extension, using HET values from 64 to 127.


  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 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
      packet header, MUST be set to 0 in all the others.

  Header Extension Type (HET): 7 bits

      The type of the header extension. This document defines a number
      of possible types. Additional types may be defined in future
      version of this specification. HET values from 0 to 63 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 present for



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.5.  [Page 17]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


      variable-length extension (HET between 0 and 63).

   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 be a multiple of 32-bit.  Also note that the total size of
      all header extensions plus optional header fields cannot exceed
      255 32-bit words.


The originator of a packet with header extensions MUST not leave
additional space between the end of the last Header Extension and the
beginning of the LCT payload.

All LCT agents MUST support the EXT_NOP header extension.

The following 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     Congestion Control Information extension.
              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 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 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 field in the fixed header
              and use the value provided in this option instead. The
              interpretation of the data contained in EXT_TOI MUST be
              negotiated out-of-band.


EXT_AUTH=3    Authentication Extension
              Information used to authenticate the source of the packet.



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 3.5.  [Page 18]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


              If present, the format of this header extension and its
              processing must be communicated out-of-band as part of the
              session description.
              It is recommended that senders and receivers provide some
              form of authentication on the packet they transmit.  If
              EXT_AUTH is present, whatever authentication checks that
              can be performed immediately upon reception of the packet
              must be performed before accepting the packet and
              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 be delayed by
              any such full authentication delay.




4.  Procedures


4.1.  Sender Operation


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

  o number of LCT groups;

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

  o the format of the payload (for example, the mapping of codepoints
    used in the session to FEC codec types and parameters);

  o the congestion control scheme being used;

  o the Demux Label (DL) value(s) used for the session;

  o 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;


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



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 4.1.  [Page 19]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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
packets each containing a payload encoded according to one of the codecs
defined in the session description.  Data packets are sent over one or
more LCT groups which together constitute a session.  Transmission rates
may be different in different groups. This document does not specify the
policy used to place symbols into packets, nor the order in which
packets are transmitted, nor the scheduling of packets in multiple
groups. 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 object is identified by a unique Transport Object Identifier (TOI).
Objects MUST be transmitted sequentially, and the TOIs MUST 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.

Typically, the sender(s) continues to send data 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 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.

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 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 also recommended that all packets have the same or very similar



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 4.1.  [Page 20]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


sizes, as this can have a severe impact on the effectiveness of
congestion control schemes such as the one described in [1].  An LCT
sender MUST implement the sender-side part of one of the congestion
control schemes that is in accordance with RFC 2357, and the
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 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 multicast groups
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 specified in the session description. If a
receiver is not able to implement the congestion control algorithm used
in the session, it MUST NOT join the session.

If source authentication information is present in data packets, it must
be used as specified in Section 3.5. 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 in a session, receivers MUST be able to
process the payload of the packets. At a minimum this involves the
ability to forward or store the payload, and possibly (in case of
reliable LCT session) determine when an object can be successfully
recovered.  If a receiver is not able to process the payload of packets,
it MUST either drop from the session, or reduce the receive bandwidth to
the minimum value allowed by the congestion control algorithm being
used.

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



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 4.2.  [Page 21]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


receivers from starting at high data rates.


If the Transmission Extension Information field is present in data
packets, receivers MAY originate Request packets to extend the
transmission of an object as specified in Section 3.4.  Receivers MUST
NOT originate transmission extension request if the T flag in incoming
data packets is set to 0.

Receivers which generate Request 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 the packets they have already received and from the
    packets they 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 that the residual object transmission time
    is not sufficient to successfully recover the object, it MAY
    schedule the transmission of an extension request at a random time
    in the future, before the scheduled end of the transmission.

  o When a receiver has a pending extension request scheduled 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 for the object of interest is received with the T
      flag set to 0.

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



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft    Section 4.2.  [Page 22]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


    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 to the receivers).
    Using random-time scheduling for requests is an effective
    suppression mechanism only if the length of 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.


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 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 or congestion control scheme are specified or
referenced as mandatory in this document.

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





Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft      Section 7.  [Page 23]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


8.  Acknowledgments

Thanks to Bruce Lueckenhoff, 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] 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] 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] Handley, M., "SAP: Session Announcement Protocol", Internet Draft,
IETF MMUSIC Working Group, Nov 1996.

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

[11] 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] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft      Section 8.  [Page 24]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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

[13] Mankin, A., Romanow, A., Brander, S., Paxson, V., "IETF Criteria
for Evaluating Reliable Multicast Transport and Application Protocols,"
RFC2357, June 1998.

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

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

[17] 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] 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, CA, USA, 94110

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



Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft      Section 9.  [Page 25]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


   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
   Department of Computer Science
   University College London
   Gower Street,
   London WC1E 6BT, UK




























Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft      Section 9.  [Page 26]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000


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


























Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft     Section 10.  [Page 27]

^L
INTERNET-DRAFT              Expires: May 2001              November 2000





















































Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft     Section 10.  [Page 28]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/