draft-ietf-rmt-bb-lct-01.txt   draft-ietf-rmt-bb-lct-02.txt 
Internet Engineering Task Force RMT WG Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-lct-01.txt J.Gemmell/Microsoft draft-ietf-rmt-bb-lct-02.txt J.Gemmell/Microsoft
L.Vicisano/Cisco L.Vicisano/Cisco
L.Rizzo/ACIRI and Univ. Pisa L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI M.Handley/ACIRI
J. Crowcroft/UCL J. Crowcroft/UCL
19 July 2001 18 October 2001
Expires: January 2002 Expires: April 2002
Layered Coding Transport: Layered Coding Transport:
A massively scalable content delivery transport A massively scalable content delivery transport building block
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are valid for a maximum of six months and MAY be 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 updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite inappropriate to use Internet-Drafts as reference material or to cite
them other than as a "work in progress". them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be 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. addressed to the authors, or the WG's mailing list at rmt@lbl.gov.
Abstract Abstract
This document describes Layered Coding Transport, a massively This document describes Layered Coding Transport, a massively
scalable reliable content delivery and stream delivery scalable reliable content delivery and stream delivery
^L
transport, hereafter referred to as LCT. LCT can be used for transport, hereafter referred to as LCT. LCT can be used for
multi-rate delivery to large sets of receivers. In LCT, multi-rate delivery to large sets of receivers. In LCT,
scalability and congestion control are supported through the scalability and congestion control are supported through the
use of layered coding techniques. Coding techniques can be use of layered coding techniques. Coding techniques can be
combined with LCT to provide support for reliability. combined with LCT to provide support for reliability.
Congestion control is receiver driven, and is achieved by Congestion control is receiver driven, and can be achieved by
sending packets in the session to multiple ``LCT channels'', sending packets in the session to multiple ``LCT channels'',
and having receivers join and leave LCT channels (thus and having receivers join and leave LCT channels (thus
adjusting their reception rate) in reaction to network adjusting their reception rate) in reaction to network
conditions in a manner that is network friendly. conditions in a manner that is network friendly.
^L
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Related Documents. . . . . . . . . . . . . . . . . . 6 1.1. Related Documents. . . . . . . . . . . . . . . . . . 6
1.2. Environmental Requirements and Considerations. . . . 6 1.2. Environmental Requirements and Considerations. . . . 7
2. General Architecture. . . . . . . . . . . . . . . . . . 8 2. General Architecture. . . . . . . . . . . . . . . . . . 9
2.1. Delivery service models. . . . . . . . . . . . . . . 10 2.1. Delivery service models. . . . . . . . . . . . . . . 10
2.2. Congestion Control . . . . . . . . . . . . . . . . . 11 2.2. Congestion Control . . . . . . . . . . . . . . . . . 12
3. LCT packets . . . . . . . . . . . . . . . . . . . . . . 11 3. LCT header. . . . . . . . . . . . . . . . . . . . . . . 12
3.1. LCT packet format. . . . . . . . . . . . . . . . . . 12 3.1. Default LCT header format. . . . . . . . . . . . . . 12
3.2. LCT packet header fields . . . . . . . . . . . . . . 13 3.2. Header-Extension Fields. . . . . . . . . . . . . . . 18
3.3. Header-Extension Fields. . . . . . . . . . . . . . . 16 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 21
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 21
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 19 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 23
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . 22 7. Intellectual Property Issues. . . . . . . . . . . . . . 24
7. Intellectual Property Issues. . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 23 9. References. . . . . . . . . . . . . . . . . . . . . . . 25
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 24 10. Authors' Addresses . . . . . . . . . . . . . . . . . . 26
10. Full Copyright Statement . . . . . . . . . . . . . . . 26 11. Full Copyright Statement . . . . . . . . . . . . . . . 28
^L
1. Introduction 1. Introduction
This document describes a massively scalable reliable content delivery This document describes a massively scalable reliable content delivery
and stream delivery transport, Layered Coding Transport (LCT), for and stream delivery transport, Layered Coding Transport (LCT), for
multi-rate content delivery primarily designed to be used with the IP multi-rate content delivery primarily designed to be used with the IP
multicast network service, but MAY also be used with other basic multicast network service, but may also be used with other basic
underlying network or transport services such as unicast UDP. LCT underlying network or transport services such as unicast UDP. LCT
supports both reliable and unreliable delivery, and supports congestion supports both reliable and unreliable delivery.
control mechanisms which conform to RFC2357.
LCT is a building block as defined in RFC3048. Complete protocol LCT is a building block as defined in RFC3048. Protocol instantiations
instantiations MAY be built by combining the LCT framework with other may be built by combining the LCT framework with other components. A
components. A complete protocol instantiation that uses LCT MUST complete protocol instantiation that uses LCT must include a congestion
include a congestion control protocol that is compatible with LCT and control protocol that is compatible with LCT and that conforms to
that conforms to RFC2357. A complete protocol instantiation that uses RFC2357. A complete protocol instantiation that uses LCT may include a
LCT MAY include a scalable reliability protocol that is compatible with scalable reliability protocol that is compatible with LCT, it may
LCT, it MAY include an session control protocol that is compatible with include an session control protocol that is compatible with LCT, and it
LCT, and it MAY include other protocols such as security protocols. may include other protocols such as security protocols.
LCT is presumed to be used with an underlying network or transport LCT is presumed to be used with an underlying network or transport
service that is a "best effort" service that does not guarantee packet service that is a "best effort" service that does not guarantee packet
reception, packet reception order, and which does not have any support reception, packet reception order, and which does not have any support
for flow or congestion control. For example, the Any-Source Multicast for flow or congestion control. For example, the Any-Source Multicast
(ASM) model of IP multicast as defined in RFC1112 is such a "best (ASM) model of IP multicast as defined in RFC1112 is such a "best
effort" network service. While the basic service provided by RFC1112 is effort" network service. While the basic service provided by RFC1112 is
largely scalable, providing congestion control or reliability should be largely scalable, providing congestion control or reliability should be
done carefully to avoid severe scalability limitations, especially in done carefully to avoid severe scalability limitations, especially in
presence of heterogeneous sets of receivers. presence of heterogeneous sets of receivers.
Scalability refers to the behavior of the protocol in relation to the Packets with LCT headers are carried in LCT channels. An LCT channel is
number of receivers and network paths, their heterogeneity, and the defined by the combination of a sender and an address associated with
ability to accommodate dynamically variable sets of receivers. the channel by the sender. A receiver may join a channel to start
Scalability limitations can come from memory or processing requirements, receiving the data packets sent to the channel by the sender, and a
or from the amount of packet traffic generated by the protocol. In receiver may leave a channel to stop receiving data packets from the
turn, such limitations may be a consequence of the features that a channel.
complete reliable content delivery or stream delivery protocol is
expected to provide.
Congestion control refers to the ability of the protocol to adapt its An LCT session consists of a set of logically grouped LCT channels
throughput to the available bandwidth on the path to the receivers, and associated with a single sender carrying packets with LCT headers for
to share bandwidth fairly with competing flows such as TCP. It is one or more objects. Congestion control that conforms to RFC2357 must
REQUIRED that protocols implement some form of congestion control on be used between receivers and the sender for each LCT session.
each session so that they not compete unfairly with existing and Congestion control refers to the ability to adapt throughput to the
adaptive protocols such as TCP. available bandwidth on the path from the sender to a receiver, and to
share bandwidth fairly with competing flows such as TCP. Thus, the total
flow of packets flowing to each receiver participating in an LCT session
must not compete unfairly with existing flow adaptive protocols such as
TCP.
For multi-rate protocols, the sender typically sends packets at a A multi-rate or a single-rate congestion control protcol can be used
constant aggregate rate to multiple channels, but individual receivers with LCT. For multi-rate protocols, a session typically consists of
adjust which portion of these packets they attempt to receive by
^L more than one channel and the sender sends packets to the channels in
the session at rates that do not depend on the receivers. Each receiver
adjusts its reception rate during its participation in the session by
joining and leaving channels dynamically depending on the available
bandwidth to the sender independent of all other receivers. Thus, for
multi-rate protocols, the reception rate of each receiver may vary
dynamically independent of the other receivers.
adjusting which set of channels they are joined to at each point in time For single-rate protocols, a session typically consists of one channel
depending on the available bandwidth between the receiver and the and the sender sends packets to the channel at variable rates over time
sender, but independent of all other receivers. Thus, for multi-rate depending on feedback from receivers. Each receiver remains joined to
protocols, the packet reception rate of each receiver may vary the channel during its participation in the session. Thus, for single-
dynamically according to the available bandwidth between each receiver rate protocols, the reception rate of each receiver may vary dynamically
and the sender, independent of the other receivers. For single-rate but in coordination with all receivers. Generally, a multi-rate
protocols, the sender typically sends packets to one channel at variable protocol is preferable to a single-rate protocol in a heterogeneous
rates over time depending on feedback from receivers, and all receivers receiver environment, but only if it can be achieved without sacrificing
attempt to receive all packets transmitted by the sender at all points scalability. Some possible multi-rate congestion control protocols are
in time. Thus, for single-rate protocols, the packet reception rate of described in [11] and [1]. A possible single-rate congestion control
all receivers may vary dynamically over time in exactly the same way protocol is described in [10].
dependent on the feedback of other receivers to the sender. Generally,
a multi-rate protocol is preferable to a single-rate protocol in a
heterogeneous receiver environment, but only if it can be achieved
without sacrificing scalability.
Layered coding refers to the ability to produce a coded stream that can Layered coding refers to the ability to produce a coded stream of
be split into multiple layers that can be sent to different channels. packets that can be partioned into an ordered set of layers. The coding
The coded stream can be generated either from a fixed piece of content, is meant to provide some form of reliability, and the layering is meant
or from an ongoing data stream, and has the property that the quality to allow the receiver experience (in terms of quality of playout, or
experienced by a receiver (in terms of quality of playout, or overall overall transfer speed) to vary in a predictable way depending on how
transfer speed) is proportional to how many of the layers the receiver many consecutive layers of packets the receiver is receiving.
is joined to. LCT MAY be combined with a reliability protocol such as
the general class of protocols described in [7]. LCT MUST be combined Layered coding can be naturally combined with multi-rate congestion
with a congestion control protocol that is compliant with RFC2357, and control. For example, the sender could send the packets for each layer
this MAY be either single-rate or multi-rate congestion control over the to a separate channel associated with the session, and then receivers
entire session. It is most compelling to use LCT in conjunction with a dynamically join and leave channels to adjust their reception rate
layered congestion control protocol such as the class of protocols according to the multi-rate congestion control protocol.
described in [9], and specified in [9], which are multi-rate congestion
control protocols. Layered coding can also be combined with single-rate congestion control.
For example, the sender could dynamically vary how many layers are sent
to the channel associated with the session as the rate of transmission
varies according to the single-rate congestion control protocol.
The concept of layered coding was first introduced with reference to The concept of layered coding was first introduced with reference to
audio and video streams. For example, the information associated with a audio and video streams. For example, the information associated with a
TV broadcast can be partitioned into three layers, corresponding to TV broadcast could be partitioned into three layers, corresponding to
black and white, color, and HDTV quality. Receivers can experience black and white, color, and HDTV quality. Receivers can experience
different quality without the need for the sender to replicate different quality without the need for the sender to replicate
information in the different layers. information in the different layers.
The concept of layered coding can be naturally extended to reliable The concept of layered coding can be naturally extended to reliable
content delivery protocols when Forward Error Correction (FEC) content delivery protocols when Forward Error Correction (FEC)
techniques are used for coding the data stream [12] [10] [3] [14] [15] techniques are used for coding the data stream [9] [7] [3] [11] [2]. By
[1]. By using FEC, the data stream is transformed in such a way that
using FEC, the data stream is transformed in such a way that
reconstruction of a data object does not depend on the reception of reconstruction of a data object does not depend on the reception of
specific data packets, but only on the number of different packets specific data packets, but only on the number of different packets
received. As a result, by increasing the number of layers a receiver is received. As a result, by increasing the number of layers a receiver is
receiving from, the receiver can reduce the transfer time accordingly. receiving from, the receiver can reduce the transfer time accordingly.
More details on the use of FEC for reliable content delivery can be More details on the use of FEC for reliable content delivery can be
found in [6]. Reliable protocols aim at giving guarantees on the found in [5]. Reliable protocols aim at giving guarantees on the
^L
reliable delivery of data from the sender to the intended recipients. reliable delivery of data from the sender to the intended recipients.
Guarantees vary from simple packet data integrity to reliable delivery Guarantees vary from simple packet data integrity to reliable delivery
of a precise copy of a data object to all intended recipients. Several of a precise copy of an object to all intended recipients. Several
reliable content delivery protocols have been built on top of IP reliable content delivery protocols have been built on top of IP
multicast, but scalability was not a design goal for many of them. In multicast, but scalability was not a design goal for many of them.
some cases, scalability is achieved by introducing changes to routers or
other infrastructure (see for example [13] ), an approach which has an
impact on near term deployment across the Internet.
Two of the key difficulties in scaling reliable content delivery using Two of the key difficulties in scaling reliable content delivery using
IP multicast are dealing with the amount of data that flows from IP multicast are dealing with the amount of data that flows from
receivers back to the sender, and the associated response (generally receivers back to the sender, and the associated response (generally
data retransmissions) from the sender. Protocols that avoid any such data retransmissions) from the sender. Protocols that avoid any such
feedback, and minimize the amount of retransmissions, can be massively feedback, and minimize the amount of retransmissions, can be massively
scalable. LCT relies on the availability of FEC codes or a layered scalable. LCT can be used in conjunction with FEC codes or a layered
codec to achieve reliability with little or no feedback. codec to achieve reliability with little or no feedback.
In this document we present the architecture and abstract LCT packet Scalability refers to the behavior of the protocol in relation to the
structure, and illustrate its support for multi-rate layered congestion number of receivers and network paths, their heterogeneity, and the
control. ability to accommodate dynamically variable sets of receivers.
Scalability limitations can come from memory or processing requirements,
or from the amount of packet traffic generated by the protocol. In
turn, such limitations may be a consequence of the features that a
complete reliable content delivery or stream delivery protocol is
expected to provide.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", In this document we present the architecture and abstract LCT header
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this structure, and describe its support for 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. document are to be interpreted as described in RFC2119.
1.1. Related Documents 1.1. Related Documents
As described in RFC3048, LCT is a building block that is intended to be
used, in conjunction with other building blocks, to help specify a
protocol instantiation. A congestion control building block that uses
the Congestion Control information field within the LCT header must be
used by any protocol instantiation that uses LCT, and other building
blocks may also be used, such as a reliability building block.
A more in-depth description of the use of FEC in Reliable Multicast A more in-depth description of the use of FEC in Reliable Multicast
Transport (RMT) protocols is given in [6]. Some of the FEC codecs that
MAY be used by LCT for reliable content delivery are specified in [7].
LCT reserves opaque header fields that can be used to transport
information related to the payload encoding.
Implementors of LCT MUST also implement congestion control in accordance Transport (RMT) protocols is given in [5]. Some of the FEC codecs that
to RFC2357, where the congestion control is over the entire session. may be used in conjunction with LCT for reliable content delivery are
Some possible schemes are specified in [9]. LCT reserves opaque header specified in [6]. The Codepoint field in the LCT header is an opaque
fields that can be used by the congestion control scheme to transport field that can be used to carry information related to the encoding of
information related to congestion control. the packet payload.
It is RECOMMENDED that LCT implementors use some authentication scheme Implementors of protocol instantiations that use LCT must also implement
to protect the protocol from attacks. An example of a possibly suitable congestion control in accordance to RFC2357, where the congestion
scheme is described in [11]. control is over the entire session. Some possible schemes are specified
in [11] and [1]. The Congestion Control Information field in the LCT
header is an opaque field that is reserved to carry information related
to congestion control. There may also be congestion control Header
Extension fields that carry additional information related to congestion
control.
1.2. Environmental Requirements and Considerations Generic Router Assist may be used in conjunction with LCT.
LCT is intended for congestion controlled, multi-rate delivery of It is recommended that LCT implementors use some packet authentication
objects and streams (both reliable content delivery and streaming of scheme to protect the protocol from attacks. An example of a possibly
suitable scheme is described in [8].
^L 1.2. Environmental Requirements and Considerations
multimedia information). LCT is intended for congestion controlled delivery of objects and
streams (both reliable content delivery and streaming of multimedia
information).
LCT is most applicable for delivery of objects or streams of substantial LCT is most applicable for delivery of objects or streams of substantial
length, i.e., objects or streams that range in length from hundreds of length, i.e., objects or streams that range in length from hundreds of
kilobytes to many gigabytes, and whose transfer time is in the order of kilobytes to many gigabytes, and whose transfer time is in the order of
tens of seconds or more. tens of seconds or more.
LCT is directly applicable to all multicast enabled networks, including LCT can be used with both multicast and unicast delivery. LCT requires
connectivity between a sender and receivers, but does not require
connectivity from receivers to a sender. LCT inherently works with all
types of networks, including LANs, WANs, Intranets, the Internet,
asymmetric networks, wireless networks, and satellite networks. Thus, asymmetric networks, wireless networks, and satellite networks. Thus,
the inherent raw scalability of LCT is unlimited. However, when other the inherent raw scalability of LCT is unlimited. However, when other
specific applications are built on top of LCT, then these applications specific applications are built on top of LCT, then these applications
by their very nature may limit scalability. For example, if an by their very nature may limit scalability. For example, if an
application requires receivers to retrieve out of band information in application requires receivers to retrieve out of band information in
order to join a session, or an application allows receivers to send 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 requests back to the sender to report reception statistics, then the
the scalability of the application is limited by the ability to send, scalability of the application is limited by the ability to send,
receive, and process this additional data. receive, and process this additional data.
LCT requires that the underlying network or transport layer can deliver LCT requires receivers to be able to uniquely identify and demultiplex
and demultiplex LCT packets for a given LCT session, and supply packet packets associated with an LCT session. In particular, there must be a
length information to the LCT receiver. In IP networks, this is often
achieved by using UDP, or any protocol that can provide an equivalent
service, as the underlying transport protocol.
In this document, we refer to the original multicast service model
defined in RFC1112 as Any-Source Multicast, or ASM for short. We refer
to the multicast service model defined in [5] as Source-Specific
Multicast, or SSM for short. LCT does not require reverse multicast
connectivity, i.e. LCT receivers do not send multicast traffic. As
such, LCT works with both ASM and SSM.
The definition of an LCT channel used throughout this document is
slightly different with ASM and with SSM. When using ASM, a sender S
sends LCT packets to a multicast group G, and the LCT channel address
consists of the pair (S,G), where S is the IP address of the sender and
G is a multicast group address. When using SSM, a sender S sends LCT
packets to an SSM channel (S,G), and the LCT channel address coincides
with the SSM channel address.
SSM is more attractive to deployment of LCT than ASM for several Transport Session Identifier (TSI) associated with each LCT session.
reasons. First, a sender may allocate and use several LCT channels in a The TSI is scoped by the IP address of the sender, and the IP address of
session, sessions may come and go dynamically. A sender can locally the sender together with the TSI must uniquely identify the session. If
allocate unique SSM channel addresses, and this makes allocation of LCT the underlying transport is UDP as described in RFC768, then the 16 bit
channel addresses easy with SSM. To allocate LCT channel addresses UDP source port number may serve as the TSI for the session. If Generic
using ASM, the sender must uniquely chose the ASM multicast group Router Assist (GRA) is being used then additional dependencies may be
address across the scope of the group, and this makes allocation of LCT introduced by GRA on the TSI field. GRA work is ongoing within the RMT
channel addresses more difficult with ASM. working group at this time. The TSI value must be the same in all
places it occurs within a packet. If there is no underlying TSI
provided by the network, transport or any other layer, then the TSI must
be included in the LCT header.
^L 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]. LCT 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 LCT channel address consists of the pair
(S,G), where S is the IP address of the sender and G is a multicast
group address. When using SSM, a sender S sends packets to an SSM
channel (S,G), and the LCT channel address coincides with the SSM
channel address.
In general SSM performs well even in presence of very large and A sender can locally allocate unique SSM channel addresses, and this
dynamically changing receiver sets. Changes in the multicast tree makes allocation of LCT channel addresses easy with SSM. To allocate
topology with SSM are light weight operations (a new branch from the LCT channel addresses using ASM, the sender must uniquely chose the ASM
receiver towards S grows when a receiver joins, and the branch is multicast group address across the scope of the group, and this makes
deleted when the receiver leaves), whereas with ASM changes can be allocation of LCT channel addresses more difficult with ASM.
heavier weight (involving transitions from a (*,G)-tree rooted at an RP
to the tree rooted at S). This efficiency is important when a
congestion control protocol is used with LCT that relies upon joining
and leaving channels to nimbly increase and decrease reception rate.
LCT channels and SSM channels coincide, and thus the receiver will only LCT channels and SSM channels coincide, and thus the receiver will only
receive packets sent to the requested LCT channel. With ASM, the receive packets sent to the requested LCT channel. With ASM, the
receiver joins an LCT channel by joining a multicast group G, and all receiver joins an LCT channel by joining a multicast group G, and all
packets sent to G, regardless of the sender, may be received by the packets sent to G, regardless of the sender, may be received by the
receiver. In either case, receivers should use mechanisms to filter out receiver. Thus, SSM has compelling security advantages over ASM for
packets from unwanted sources. Thus, SSM has compelling security prevention of denial of service attacks. In either case, receivers
advantages over ASM for prevention of denial of service attacks. should use mechanisms to filter out packets from unwanted sources.
LCT also requires receivers to obtain Session Description Information LCT also requires receivers to obtain Session Description Information,
before joining a session, as described in Section 4.1. The session as described in Section 4.1. The session description could be in a form
description could be in a form such as SDP as defined in RFC2327, or XML such as SDP as defined in RFC2327, or XML metadata, or HTTP/Mime headers
metadata, or HTTP/Mime headers as defined in RFC2068, and distributed as defined in RFC2068, and distributed with SAP as defined in RFC2974,
with SAP [4], using RCCP [8], HTTP, or in other ways. using HTTP, or in other ways.
The particular layered encoder and congestion control protocols used The particular layered encoder and congestion control protocols used
with LCT have an impact on the performance and applicability of LCT. with LCT have an impact on the performance and applicability of LCT.
For example, some layered encoders used for video and audio streams can For example, some layered encoders used for video and audio streams can
produce a very limited number of substreams, thus providing a very produce a very limited number of layers, thus providing a very coarse
coarse control in the reception rate of packets by receivers in a control in the reception rate of packets by receivers in a session.
session. When LCT is used for reliable data transfer, some FEC codecs
are inherently limited in the size of the object they can encode, and
for objects larger than this size the reception overhead on the
receivers can grow substantially.
As another example, some networks are not amenable to some congestion When LCT is used for reliable data transfer, some FEC codecs are
control protocols that could be used with LCT. In particular, for a inherently limited in the size of the object they can encode, and for
satellite or wireless network, there may be no mechanism for receivers objects larger than this size the reception overhead on the receivers
to effectively reduce their reception rate since there may be a fixed can grow substantially.
transmission rate allocated to the session.
2. General Architecture 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.
An LCT session comprises all LCT packets sent to one or more LCT Some protocol instantiations that use LCT may require the generation of
channels from a single sender, and pertaining to the transmission of one feedback from the receivers to the sender. For example, Generic Router
or more objects that can be of interest for the receivers. Assist may be used to help in passing real-time statistics in a scalable
manner from receivers back to the sender. However, the mechanism for
doing this is outside the scope of LCT.
For example, an LCT session could be used to deliver a TV channel using 2. General Architecture
^L An LCT session comprises a logically related set of one or more LCT
channels originating at a single sender that are used for some period of
time to carry packets containing LCT headers pertaining to the
transmission of one or more objects that can be of interest to
receivers.
three channels. Receiving the first channel could allow black and white For example, an LCT session could be used to deliver a TV program using
reception, receiving the first two channels would permit color three LCT channels. Receiving packets from the first LCT channel could
reception, whereas receiving the set of three channels delivers HDTV allow black and white reception, receiving the first two LCT channels
quality images. Objects in this example could correspond to individual could also permit color reception, whereas receiving all three channels
programs (movies, news, commercial) being transmitted. could allow HDTV quality reception. Objects in this example could
correspond to individual TV programs being transmitted.
As another example, a reliable LCT session could be used to reliably As another example, a reliable LCT session could be used to reliably
deliver hourly-updated weather maps (objects) using ten LCT channels at deliver hourly-updated weather maps (objects) using ten LCT channels at
different rates, using FEC coding. A receiver MAY join and concurrently different rates, using FEC coding. A receiver may join and concurrently
receive LCT packets from subsets of these channels, until it has enough receive packets from subsets of these channels, until it has enough
packets in total to recover the object, then leave the session (or packets in total to recover the object, then leave the session (or
remain there listening to control information only) until it is time to remain connected listening for session description information only)
receive the next object. In this case, the quality metric is the time until it is time to receive the next object. In this case, the quality
required to receive each object. metric is the time required to receive each object.
Before joining a session, the receivers MUST obtain a session Before joining a session, the receivers must obtain enough of the
description, which MUST include the relevant session parameters needed session description to start the session. This must include the
by a receiver to participate in the session. The session description is relevant session parameters needed by a receiver to participate in the
determined and agreed upon by the senders, and typically communicated to session, including all information relevant to congestion control. The
the receivers out of band. In some cases, part of the session session description is determined by the sender, and is typically
description MAY be included in the LCT packet. communicated to the receivers out of band. In some cases, as described
An encoder MAY be used to generate the data that is placed in the LCT later, parts of the session description that are not required to
packet payload in order to provide reliability. A suitable decoder is initiate a session may be included in the LCT header or communicated to
used to reproduce the original information from the payload. There MAY a receiver out of band after the receiver has joined the session.
be a reliability packet header that follows the LCT packet header if
such an encoder and decoder is used. The reliability packet header
helps to describe the encoding data carried in the payload of the
packet. The format of the reliability packet header depends on the
coding used, and this is negotiated out-of-band. As an example, one of
the FEC packet headers described in [7] could be used.
For LCT, when layered congestion control is used, congestion control is An encoder may be used to generate the data that is placed in the packet
achieved by sending LCT packets associated with a given session to payload in order to provide reliability. A suitable decoder is used to
reproduce the original information from the packet payload. There may
be a reliability header that follows the LCT header if such an 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 coding used, and this is negotiated
out-of-band. As an example, one of the FEC headers described in [6]
could be used.
For LCT, when multi-rate congestion control is used, congestion control
is achieved by sending packets associated with a given session to
several LCT channels. Individual receivers dynamically join one or more several LCT channels. Individual receivers dynamically join one or more
of these channels, according to the network congestion as seen by the of these channels, according to the network congestion as seen by the
receiver. LCT packet headers include an opaque field which MUST be used receiver. LCT headers include an opaque field which must be used to
to convey congestion control information to the receivers. The actual convey congestion control information to the receivers. The actual
congestion control scheme to use with LCT is negotiated out-of-band. congestion control scheme to use with LCT is negotiated out-of-band.
Some examples of congestion control protocols that MAY be suitable for Some examples of congestion control protocols that may be suitable for
content delivery are described in [9]. Other congestion controls MAY be content delivery are described in [11] and [1]. Other congestion
suitable when LCT is used for a streaming application. controls may be suitable when LCT is used for a streaming application.
LCT can be used with other congestion control protocols such as the one LCT can be used with other congestion control protocols such as the one
described in [14], or router-assisted schemes where the selection of described in [11], or Generic Router Assist schemes where the selection
which packets to forward is performed by routers. This latter approach of which packets to forward is performed by routers. This latter
potentially allows for finer grain congestion control and a faster approach potentially allows for finer grain congestion control and a
reaction to network congestion, but requires changes to the router faster reaction to network congestion, but requires changes to the
router infrastructure. We do not discuss this approach further in this
^L document.
infrastructure. See [2] for a preliminary design description. We do
not discuss this approach further in this document.
2.1. Delivery service models 2.1. Delivery service models
LCT can support several different delivery service models. Two examples LCT can support several different delivery service models. Two examples
are briefly described here. are briefly described here.
Push service model. Push service model.
One way a push service model can be used for reliable content delivery 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 is to deliver a series of objects. For example, a receiver could join
skipping to change at page 10, line 43 skipping to change at page 11, line 24
For example a popular software update might be transmitted using LCT for For example a popular software update might be transmitted using LCT for
several days, even though a receiver may be able to complete the several days, even though a receiver may be able to complete the
download in one hour total of connection time, perhaps spread over download in one hour total of connection time, perhaps spread over
several intervals of time. several intervals of time.
In this case the receivers join the session, and dynamically adapt the In this case the receivers join the session, and dynamically adapt the
number of LCT channels they subscribe to (and the reception quality) number of LCT channels they subscribe to (and the reception quality)
according to the available bandwidth. Receivers then drop from the according to the available bandwidth. Receivers then drop from the
session when they have received enough packets to recover the object. session when they have received enough packets to recover the object.
As an example, assume that an object is 50 MB. The sender could set the As an example, assume that an object is 50 MB. The sender could send 1
data rate on the lowest LCT channel to 50 1KB packets per second, so KB packets to the first LCT channel at 50 packets per second, so that
that receivers using just this LCT channel could complete reception of receivers using just this LCT channel could complete reception of the
the object in 1,000 seconds in absence of loss, and would be able to 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 complete reception even in presence of some substantial amount of losses
with the use of coding for reliability. Furthermore, the sender could with the use of coding for reliability. Furthermore, the sender could
use a number of LCT channels such that the aggregate data rate when use a number of LCT channels such that the aggregate rate of 1 KB
using all LCT channels is 1,000 1KB packets per second, so that a 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 receiver could be able to complete reception of the object in as little
^L
50 seconds (assuming no loss and that the congestion control mechanism 50 seconds (assuming no loss and that the congestion control mechanism
immediately converges to the use of all LCT channels). immediately converges to the use of all LCT channels).
Other service models. Other service models.
There are many other delivery service models that LCT can be used for 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- that are not covered above. As examples, a live streaming or an on-
demand archival content streaming service model. The description of the demand archival content streaming service model. The description of the
many potential applications, the appropriate delivery service model, and many potential applications, the appropriate delivery service model, and
the additional mechanisms to support such functionalities when combined the additional mechanisms to support such functionalities when combined
skipping to change at page 11, line 31 skipping to change at page 12, line 15
2.2. Congestion Control 2.2. Congestion Control
The specific congestion control protocol to be used for LCT sessions The specific congestion control protocol to be used for LCT sessions
depends on the type of content to be delivered. While the general depends on the type of content to be delivered. While the general
behavior of the congestion control protocol is to reduce the throughput behavior of the congestion control protocol is to reduce the throughput
in presence of congestion and gradually increase it in the absence of in presence of congestion and gradually increase it in the absence of
congestion, the actual dynamic behavior (e.g. response to single losses) congestion, the actual dynamic behavior (e.g. response to single losses)
can vary. can vary.
Some possible congestion control protocols for reliable content delivery Some possible congestion control protocols for reliable content delivery
using LCT are described in [9]. Different delivery service models might using LCT are described in [11] and [1]. Different delivery service
require a different congestion control protocols. models might require different congestion control protocols.
3. LCT packets
The type of packet used by LCT sessions is "LCT Packet". LCT packets
are sent by senders to LCT channels.
Some instances of LCT sessions MAY require the generation of feedback 3. LCT header
from the receivers to the sender. However, the mechanism for doing this
is outside the scope of LCT.
The LCT packet format described in this document is intended to be used Packets sent to an LCT session must include an "LCT header". The LCT
in conjunction with the UDP transport protocol as defined in RFC768 or header format described below is the default format, and this is the
other transport protocols that satisfy the requirements stated in format that is recommended for use by protocol instantiations to ensure
Section 1.2, specifically about demultiplexing and delivery of packet a uniform format across different protocol instantiations. Other LCT
size information. header formats may be used by protocol instantiations, but if the
default LCT header format is not used by a protocol insantiation that
uses LCT, then the protocol instantiation must specify the lengths and
positions within the LCT header it uses of all fields described in the
default LCT header.
LCT packets consist of an LCT packet header and an OPTIONAL LCT packet Other building blocks may describe some of the same fields as described
payload, as shown in Figure 1. When present, the LCT packet payload for the LCT header. It is recommended that protocol instantiations
using multiple building blocks include shared fields at most once in
each packet. Thus, for example, if another building block is used with
LCT that includes the optional Expected Residual Time field, then the
Expected Residual Time field should be carried in each packet at most
once.
^L The position of the LCT header within a packet must be specified by any
protocol instantiation that uses LCT.
immediately follows the LCT packet header. The LCT packet payload MAY 3.1. Default LCT header format
contain headers for other protocols, such as reliability protocols.
LCT packet headers have variable size, which is specified by a length The default LCT header is of variable size, which is specified by a
field in the third byte of the header. In the LCT packet header, all 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, integer fields are carried in "big-endian" or "network order" format,
that is, most significant byte (octet) first. Bits designated as that is, most significant byte (octet) first. Bits designated as
"padding" or "reserved" (r) MUST by set to 0 by senders and ignored by "padding" or "reserved" (r) must by set to 0 by senders and ignored by
receivers. Unless otherwise noted, numeric constants in this receivers. Unless otherwise noted, numeric constants in this
specification are in decimal (base 10). specification are in decimal (base 10).
3.1. LCT packet format The format of the default LCT header is depicted in Figure 1.
The format of LCT packets is depicted in Figure 1.
0 1 2 3 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 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 | r | I |S|E|X|A|B| HDR_LEN | Codepoint (CP)| | V |C| r |H|S| O |T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI) | | Congestion Control Information (CCI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, if I >= 1) | | CCI continued (if C = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOI continued (if I >= 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOI continued (if I = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOI continued (if I = 3) | | 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 S = 1) | | Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if E = 1) | | Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if X = 1 ) | | Header Extensions (if applicable) |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - LCT packet format Figure 1 - Default LCT header format
^L 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
be set to "1" by the sender. Fields marked as "r" or "0" mean that the
corresponding bits must be set to "0" by the sender.
3.2. LCT packet header fields LCT version number (V): 4 bits
The function each field in LCT packet headers is the following. Fields Indicates the LCT version number. The LCT version number for this
marked as "1" mean that the corresponding bits MUST be set to "1" by the specification is 0.
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): 4 bits Congestion control flag (C): 1 bit
Indicates the LCT protocol version. The LCT version number for C=0 indicates the Congestion Control Information (CCI) field is
this specification is 0. 32-bits in length.
C=1 indicates the CCI field is 64-bits in length.
Reserved (r): 5 bits Reserved (r): 3 bits
Reserved for future use. A sender MUST set these bits to zero and Reserved for future use. A sender must set these bits to zero and
a receiver MUST ignore these bits. a receiver must ignore these bits.
Transport Object Identifier flag (I): 2 bits Half-word flag (H): 1 bit
I=0 indicates no Transport Object Identifier (TOI) field is The TSI and the TOI fields are both multiples of 32-bits plus 16*H
present. bits in length. This allows the TSI and TOI field lengths to be
I=1 indicates that a 32-bit TOI field is present. multiples of a half-word (16 bits), while ensuring that the
I=2 indicates that a 64-bit TOI field is present. aggregate length of the TSI and TOI fields is a multiple of
I=3 indicates that a 128-bit TOI field is present. 32-bits.
The TOI field indicates which object within the session this LCT
packet pertains to.
Sender Current Time present flag (S): 1 bit Transport Session Identifier flag (S): 1 bit
S = 0 indicates that the Sender Current Time (SCT) field is not 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.
Sender Current Time present flag (T): 1 bit
T = 0 indicates that the Sender Current Time (SCT) field is not
present. present.
S = 1 indicates that the SCT field is present. T = 1 indicates that the SCT field is present.
The SCT is inserted by senders to indicate to receivers how long The SCT is inserted by senders to indicate to receivers how long
the session has been in progress. the session has been in progress.
Expected Residual Time present flag (E): 1 bit Expected Residual Time present flag (R): 1 bit
E = 0 indicates that the Expected Residual Time (ERT) field is not R = 0 indicates that the Expected Residual Time (ERT) field is not
present. present.
E = 1 indicates that the ERT field is present. R = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how much The ERT is inserted by senders to indicate to receivers how much
longer the session will continue. longer the session / object transmission will continue.
Senders MUST NOT set E = 1 when the ERT for the session is more Senders must not set R = 1 when the ERT for the session is more
^L
than 2^32-1 time units (approximately 49 days), where time is than 2^32-1 time units (approximately 49 days), where time is
measured in units of milliseconds. measured in units of milliseconds.
Header extension present flag (X): 1 bit Close Session flag (A): 1 bit
X = 0 indicates no Header Extensions are present. Normally, A is set to 0. The sender may set A to 1 when
X = 1 indicates that Header Extensions are present. termination of transmission of packets for the session is
Header Extensions are used in LCT to accommodate OPTIONAL header imminent. A may be set to 1 in just the last packet transmitted
fields which are not always used or have variable size. for the session, or A 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 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 assume that no more packets will be sent to
the session.
Close TOI flag (A): 1 bit Close Object flag (B): 1 bit
Normally, the Close TOI flag is set to 0. The sender MAY set the Normally, B is set to 0. The sender may set B to 1 when
Close TOI flag to 1 when termination of transmission of LCT termination of transmission of packets for an object is imminent.
packets for the object identified by the TOI is imminent. The If the TOI field is in use and B is set to 1 then termination of
Close TOI flag MAY be set to 1 in just the last LCT packet transmission for the object identified by the TOI field is
transmitted for the object, or it MAY be set to 1 in the last imminent. If the TOI field is not in use and B is set to 1 then
couple of seconds LCT packets transmitted for the object. Once termination of transmission for the one object in the session
the sender sets the Close TOI flag to 1 in one packet for a identified by out of band information is imminent. B may be set
particular object, the sender SHOULD set the Close TOI flag to 1 to 1 in just the last packet transmitted for the object, or B may
in all subsequent packets for the object until termination of be set to 1 in the last few seconds packets transmitted for the
transmission of LCT packets for the object. A received packet object. Once the sender sets B to 1 in one packet for a
with the Close TOI flag set to 1 indicates to a receiver that the particular object, the sender should set B to 1 in all subsequent
sender will immediately stop sending LCT packets for the object packets for the object until termination of transmission of
identified by the TOI. When a receiver receives a packet with the packets for the object. A received packet with B set to 1
Close TOI flag set to 1 then it should assume that no more LCT indicates to a receiver that the sender will immediately stop
packets will be sent to the session for this object. sending packets for the object. When a receiver receives a packet
with B set to 1 then it should assume that no more packets will be
sent for the object to the session.
Close Session flag (B): 1 bit LCT header length (HDR_LEN): 8 bits
Normally, the Close Session flag is set to 0. The sender MAY set Total length of the LCT header in units of 32-bit words. The
the Close Session flag to 1 when termination of transmission of length of the LCT header must be a multiple of 32-bits. This
LCT packets for the session is imminent. The Close Session flag field can be used to directly access the portion of the packet
MAY be set to 1 in just the last LCT packet transmitted for the beyond the LCT header, i.e., to the first other header if it
session, or it MAY be set to 1 in the last couple of seconds LCT exists, or to the packet payload if it exists and there is no
packets transmitted for the session. Once the sender sets the other header, or to the end of the packet if there are no other
Close Session flag to 1 in one packet, the sender SHOULD set the headers or packet payload.
Close Session flag to 1 in all subsequent packets until
termination of transmission of LCT packets for the session. A
received packet with the Close Session flag set to 1 indicates to
a receiver that the sender will immediately stop sending LCT
packets for the session. When a receiver receives a packet with
the Close Session flag set to 1 then it should assume that no more
LCT packets will be sent to the session.
^L Codepoint (CP): 8 bits
LCT packet header length (HDR_LEN): 8 bits
Length of the LCT packet header in units of 32-bit words An opaque identifier which is passed to the packet payload decoder
(excluding IP or UDP headers). to convey information on the codec being used for the packet
This field can be used for direct access to the beginning of the payload. The mapping between the codepoint and the actual codec is
LCT packet payload. 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.
Codepoint (CP): 8 bits Congestion Control Information (CCI): 32 or 64 bits
An opaque identifier which is passed to the payload decoder to Used to carry congestion control information. For example, the
convey information on the codec being used for the payload. The congestion control information could include layer numbers,
mapping between the codepoint and the actual codec is defined on a logical channel numbers, and sequence numbers. This field is
per session basis and communicated out-of-band as part of the opaque for the purpose of this specification.
session description information. The use of the CP field is This field must be 32 bits if C=0.
similar to the Payload Type (PT) field in RTP headers as described This field must be 64 bits if C=1.
in RFC1889.
Congestion Control Information (CCI): 32 bits Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
Used to carry congestion control information, e.g. for the The TSI uniquely identifies a session among all sessions from a
congestion control specified in [9] or other congestion control particular sender. The TSI is scoped by the IP address of the
schemes. This field is opaque for the purpose of this sender, and thus the IP address of the sender and the TSI together
specification. uniquely identify the session. Although a TSI in conjunction with
the IP address of the sender must always uniquely identify a
session, whether or not the TSI is incuded in the LCT header
depends on what is used as the TSI value. If the underlying
transport is UDP, then the 16 bit UDP source port number may serve
as the TSI for the session. If Generic Router Assist (GRA) is
being used then additional dependencies may be introduced by GRA
on the TSI field. If the TSI value appears multiple times in a
packet then all occurrences must be the same value. If there is
no underlying TSI provided by the network, transport or any other
layer, then the TSI must be included in the LCT header.
Transport Object Identifier (TOI): 32, 64 or 128 bits (OPTIONAL) The TSI must be unique among all sessions served by the sender
during the period when the session is active, and for a large
period of time preceding and following when the session is active.
A primary purpose of the TSI is to prevent receivers from
inadvertently accepting packets from a sender that belong to
sessions other than sessions receivers are subscribed to. For
example, suppose a session is deactivated and then another session
is activated by a sender and the two sessions use an overlapping
set of channels. A receiver that connects and remains connected
to the first session during this sender activity could possibly
accept packets from the second session as belonging to the first
session if the TSI for the two sessions were identical. The
mapping of TSI field values to sessions must be done out of band.
The length of the TSI field is 32*S + 16*H bits. Note that the
aggregate lengths of the TSI field plus the TOI field is a
multiple of 32 bits.
This field indicates which object within the session this LCT Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112
packet pertains to. For example, a sender might send a number of bits.
files in the same session, using TOI=0 for the first file, TOI=1
for the second one, etc. The mapping of TOI field values to
objects MUST be done out of band.
This field MUST NOT be present if I=0.
This field MUST be 32 bits if I=1.
This field MUST be 64 bits if I=2.
This field MUST be 128 bits if I=3.
Sender Current Time (SCT): 32 bits (OPTIONAL) This field 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 be done out of band. The TOI field 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 field represents the current clock at the sender at the time
this packet was transmitted, measured in units of 1ms and computed this packet was transmitted, measured in units of 1ms and computed
modulo 2^32 units from the start of the session. modulo 2^32 units from the start of the session.
This field MUST NOT be present if S=0 and MUST be present if S=1. This field must not be present if T=0 and must be present if T=1.
^L Expected Residual Time (ERT): 0 or 32 bits
Expected Residual Time (ERT): 32 bits (OPTIONAL)
This field represents the sender expected residual transmission This field represents the sender expected residual transmission
time for the current session, measured in units of 1ms. time for the current session or for the transmission of the
This field MUST NOT be present if E=0 and MUST be present if E=1. current object, measured in units of 1ms. If the packet containing
the ERT field also contains the TOI field, then ERT refers to the
3.3. Header-Extension Fields object corresponding to the TOI field, otherwise it refers to the
session.
This field must not be present if R=0 and must be present if R=1.
To allow for additional header fields and to extend the size of some of 3.2. Header-Extension Fields
the predefined fields, the LCT packet header contains an additional
header field flag, "X". If "X" is set to 0 then no additional header
fields are included within the LCT packet header beyond the predefined
fields. When additional headers beyond the predefined fields are used,
the value of "X" within the LCT packet header MUST be set to 1.
Examples of use of Header Extensions include: 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 version of already existing header fields. o Extended-size versions of already existing header fields.
o Sender and Receiver authentication information. o Sender and Receiver authentication information.
If present, Header Extensions MUST be processed to ensure that they are 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 be processed to ensure that they are
recognized before performing any congestion control procedure or recognized before performing any congestion control procedure or
otherwise accepting an LCT packet. LCT packets with unrecognised Header otherwise accepting a packet. The default action for unrecognized header
Extensions MUST be discarded by the receiving agent, hence the expected extensions is to ignore them. This allows the future introduction of
use of extensions SHOULD be signaled out-of-band before session startup. 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 override this default behavior for PI-
specific extensions (see below).
There are two formats for Header Extension fields, as depicted below. There are two formats for Header Extension fields, as depicted below.
The first format is used for variable-length extensions, with Header The first format is used for variable-length extensions, with Header
Extension Type (HET) values between 0 and 63. The second format is used Extension Type (HET) values between 0 and 127. The second format is used
for fixed length (one word) extension, using HET values from 64 to 127. for fixed length (one 32-bit word) extensions, using HET values from 127
to 255.
^L
0 1 2 3 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 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 | | | HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Header Extension Content (HEC) . . Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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) | | HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Format of additional headers Figure 5 - Format of additional headers
The explanation of each sub-field is the following. The explanation of each sub-field is the following.
Last Header Extension (L): 1 bit Header Extension Type (HET): 8 bits
MUST be set to 1 in the last Header Extension field present in an
LCT packet header, MUST be set to 0 in all the others.
Header Extension Type (HET): 7 bits
The type of the Header Extension. This document defines a number The type of the Header Extension. This document defines a number
of possible types. Additional types may be defined in future of possible types. Additional types may be defined in future
version of this specification. HET values from 0 to 63 are used version of this specification. HET values from 0 to 127 are used
for variable-length Header Extensions. HET values from 64 to 127 for variable-length Header Extensions. HET values from 128 to 255
are used for fixed-length Header Extensions. are used for fixed-length 32-bit Header Extensions.
Header Extension Length (HEL): 8 bits Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field, expressed in The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for multiples of 32-bit words. This field must be present for
variable-length extensions (HET between 0 and 63) and MUST NOT be variable-length extensions (HET between 0 and 127) and must not be
present for fixed-length extensions (HET between 64 and 127). present for fixed-length extensions (HET between 128 and 255).
Header Extension Content (HEC): variable length Header Extension Content (HEC): variable length
^L
The content of the Header Extension. The format of this sub-field The content of the Header Extension. The format of this sub-field
depends on the Header Extension type. For fixed-length Header depends on the Header Extension type. For fixed-length Header
Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC is 24 bits. For variable-length Header
Extensions, the HEC field has variable size, as specified by the Extensions, the HEC field has variable size, as specified by the
HEL field. Note that the length of each Header Extension field HEL field. Note that the length of each Header Extension field
MUST be a multiple of 32 bits. Also note that the total size of must be a multiple of 32 bits. Also note that the total size of
the LCT packet header, including all Header Extensions and all the LCT header, including all Header Extensions and all optional
OPTIONAL header fields, cannot exceed 255 32-bit words. header fields, cannot exceed 255 32-bit words.
An LCT packet with Header Extensions MUST NOT have space between the end Header Extensions are further divided between general LCT extensions and
of the last Header Extension and the beginning of the LCT packet Protocol Instantiation specific extensions (PI-specific). General LCT
payload. 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.
All senders and receivers of LCT packets MUST support the EXT_NOP Header General LCT extensions are intended to allow the introduction of
Extension. 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.
The following Header Extension types are defined: 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. EXT_NOP=0 No-Operation extension.
The information present in this extension field MUST be The information present in this extension field must be
ignored by receivers. ignored by receivers.
EXT_CCI_V=1 Congestion Control Information extension, variable length. EXT_AUTH=2 Packet authentication extension
This extension field extends the CCI field present in the Information used to authenticate the sender of the packet.
fixed part of the header. It is used when the congestion If present, the format of this Header Extension and its
control information does not fit in the 32-bit CCI field. processing must be communicated out-of-band as part of the
When this option is present, the concatenation of the session description.
32-bit CCI field in the fixed part of the header together It is recommended that senders provide some form of packet
with the variable length value provided in this option is authentication. If EXT_AUTH is present, whatever packet
used as the congestion control information. The authentication checks that can be performed immediately
interpretation of the data contained in EXT_CCI_V MUST be upon reception of the packet must be performed before
negotiated out-of-band. The use of EXT_CCI_V and accepting the packet and performing any congestion
EXT_CCI_F is mutually exclusive. control-related action on it.
Some packet authentication schemes impose a delay of
EXT_AUTH=2 Authentication extension several seconds between when a packet is received and when
Information used to authenticate the sender of the LCT the packet is fully authenticated. Any congestion control
packet. If present, the format of this Header Extension related action that is appropriate must not be postponed
and its processing MUST be communicated out-of-band as by any such full packet authentication.
part of the session description.
It is RECOMMENDED that senders provide some form of
authentication on the LCT packets 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
^L
performing any congestion control-related action on it.
Some authentication schemes impose a delay of several
seconds between when a packet is received and when the
packet is fully authenticated. Any congestion control
related action that is appropriate MUST NOT be delayed by
any such full authentication delay.
EXT_CCI_F=65 Congestion Control Information extension, fixed length. All senders and receivers implementing LCT must support the EXT_NOP
This extension field extends the CCI field present in the Header Extension and must recognize EXT_AUTH, but may not be able to
fixed part of the header. It is used when the congestion parse its content.
control information does not fit in the 32-bit CCI field.
When this option is present, the concatenation of the
32-bit CCI field in the fixed part of the header together
with the 24-bit fixed length value provided in this option
is used as the congestion control information. The
interpretation of the data contained in EXT_CCI_F MUST be
negotiated out-of-band. The use of EXT_CCI_V and
EXT_CCI_F is mutually exclusive.
4. Procedures 4. Procedures
4.1. Sender Operation 4.1. Sender Operation
Before a session starts, an LCT sender MUST make available all A sender using LCT must make a session description available to clients
applicable information regarding the session. This information could that want to join an LCT session. This information could include, but
include, but is not limited to: is not limited to:
o The number of LCT channels; o The number of LCT channels;
o The addresses, port numbers and data rates used for each LCT o The addresses, port numbers and data rates used for each LCT
channel; channel;
o The format of the payload. For example, the payload could contain o The formats of any other headers. For example, an FEC header as
other protocol headers such as an FEC header. Then for example the described in [6] could be such an other header. Then for example
information could include the mapping of codepoints used in the the information could include the mapping of codepoints used in the
session to FEC codec types and parameters; session to FEC codec types and parameters;
o The congestion control scheme being used; o The format and lengths of the packet payload;
o The possible Header Extensions that could be used in the session; o The Transport Session ID (TSI) to be used for the session;
o Whether or not Generic Router Assist (GRA) is being used;
o The congestion control scheme being used;
o The mapping of TOI value(s) to objects for the session; o The mapping of TOI value(s) to objects for the session;
o The authentication scheme being used, and all relevant information o Any information that is relevant to each object being transported,
which is necessary for sender authentication purposes; such as when it will be available within the session, for how long,
and the length of the object;
^L 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 must be obtained by
receivers before they connect to the session. This includes the number
and addresses of the LCT channels, the TSI value for the session, the
formats of any other headers, the congestion control scheme being used
and the packet authentication scheme if it is used. Some of the session
description information may be obtained by receivers while they are
connected to the session, e.g., information relevant to objects being
transported within the session such as their TOI, when they are
available within the session, for how long, and their lengths.
The session description could be in a form such as SDP as defined in The session description could be in a form such as SDP as defined in
RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a
session announcement protocol such as SAP [4], obtained using RCCP session announcement protocol such as SAP as defined in RFC2974,
session control as described in [8], located on a Web page with obtained using a proprietary session control protocol, located on a Web
scheduling information, or conveyed via E-mail or other out of band page with scheduling information, or conveyed via E-mail or other out of
methods. Discussion of session description format, and distribution of band methods. Discussion of session description format, and
session descriptions is beyond the scope of this document. distribution of session descriptions is beyond the scope of this
document.
Within an LCT session, an LCT sender transmits a sequence of LCT packets Within an LCT session, a sender using LCT transmits a sequence of
each containing a payload encoded according to one of the codecs defined packets each in a format defined in the session description. Packets
in the session description. LCT packets are sent over one or more LCT are sent from a sender using one or more LCT channels which together
channels which together constitute a session. Transmission rates MAY be constitute a session. Transmission rates may be different in different
different in different channels. This document does not specify the LCT channels and may vary over time. The specification of the other
packet payload, nor the order in which LCT packets are transmitted, nor building block headers and the packet payload used by a complete
the organization of a session into multiple channels. Although these protocol instantiation using LCT is beyond the scope of this document.
issues affect the efficiency of the protocol, they do not affect the This document does not specify the order in which packets are
correctness nor the inter-operability between senders and receivers. transmitted, nor the organization of a session into multiple channels.
Although these issues affect the efficiency of the protocol, they do not
affect the correctness nor the inter-operability of LCT between senders
and receivers.
Multiple objects can be carried within the same LCT session. In this Multiple objects can be carried within the same LCT session. In this
case, each object is identified by a unique TOI. Objects MAY be case, each object must be identified by a unique TOI. Objects may be
transmitted sequentially, or they MAY be transmitted concurrently. transmitted sequentially, or they may be transmitted concurrently. It
is good practice to only send objects concurrently in the same session
if the receivers that participate in that portion of the session have
interest in receiving all the objects. The reason for this is that it
wastes bandwidth and networking resources to have receivers receive data
for objects that they have no interest in.
Typically, the sender(s) continues to send LCT packets in a session Typically, the sender(s) continues to send packets in a session until
until the transmission is considered complete. The transmission MAY be the transmission is considered complete. The transmission may be
considered complete when some time has expired, a certain number of considered complete when some time has expired, a certain number of
packets have been sent, or some out of band signal (possibly from a packets have been sent, or some out of band signal (possibly from a
higher level protocol) has indicated completion by a sufficient number higher level protocol) has indicated completion by a sufficient number
of receivers. of receivers.
The specification of the processing of the payload carried in LCT
packets is beyond the scope of this document. LCT will act as a
transport layer and convey payload and associated information (Codepoint
and TOI) to the receivers and any complete protocol using LCT will
implement congestion control .
For the reasons mentioned above, this document does not pose any For the reasons mentioned above, this document does not pose any
restriction on LCT packet sizes. However, network efficiency restriction on packet sizes. However, network efficiency considerations
considerations recommend that the sender uses as large as possible recommend that the sender uses as large as possible packet payload size,
payload size, but in such a way that LCT packets do not exceed the but in such a way that packets do not exceed the network's maximum
network's maximum transmission unit size (MTU), or fragmentation coupled transmission unit size (MTU), or fragmentation coupled with packet loss
with packet loss might introduce severe inefficiency in the might introduce severe inefficiency in the transmission.
transmission.
It is also RECOMMENDED that all LCT packets have the same or very
similar sizes, as this can have a severe impact on the effectiveness of
congestion control schemes such as the ones described in [9]. A sender
of LCT packets MUST implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357, and the
^L 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] and [1]. A sender of
corresponding receiver congestion control scheme MUST be communicated packets using LCT must implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357 using the
Congestion Control Information field provided in the LCT header, and the
corresponding receiver congestion control scheme must be communicated
out of band and implemented by any receivers participating in the out of band and implemented by any receivers participating in the
session. session.
4.2. Receiver Operation 4.2. Receiver Operation
Receivers can operate differently depending on the delivery service Receivers can operate differently depending on the delivery service
model. For example, for an on demand service model receivers MAY join a model. For example, for an on demand service model receivers may join a
session, obtain the necessary encoding symbols to reproduce the object, session, obtain the necessary encoding symbols to reproduce the object,
and then leave the session. As another example, for a streaming service 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 model a receiver may be continuously joined to a set of LCT channels to
download all objects in a session. download all objects in a session.
To be able to participate in a session, a receiver MUST first obtain the To be able to participate in a session, a receiver must first obtain the
relevant session description information as listed in Section 4.1. relevant session description information as listed in Section 4.1.
To be able to participate in a session, a receiver MUST implement the If packet authentication information is present in an LCT header, it
congestion control protocol specified in the session description. If a should be used as specified in Section 3.2. To be able to be a receiver
receiver is not able to implement the congestion control protocol used in a session, the receiver must be able to process the LCT header. The
in the session, it MUST NOT join the session. 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
If sender authentication information is present in an LCT packet header, LCT header, it must drop from the session.
it MUST be used as specified in Section 3.3. If a receiver is unable to
implement the authentication mechanism used by the session, it MUST NOT
join the session.
To be able to be a receiver in a session, the receiver MUST be able to
process the LCT packet header. The receiver MUST be able to discard,
forward, store or process the LCT packet payload. If a receiver is not
able to process a LCT packet header, it MUST either drop from the
session, or reduce the receive bandwidth to the minimum value allowed by
the congestion control protocol being used.
When the session is transmitted on multiple LCT channels, receivers MUST To be able to participate in a session, a receiver must implement the
do it according to the specified startup behavior of the congestion congestion control protocol specified in the session description using
the Congestion Control Information field provided in the LCT header. If
a receiver is not able to implement the congestion control protocol used
in the session, it must not join the session. When the session is
transmitted on multiple LCT channels, receivers must initially join
channels according to the specified startup behavior of the congestion
control protocol itself. For a layered transmission on multiple control protocol itself. For a layered transmission on multiple
channels, this typically means that a receiver will initially join only channels, this typically means that a receiver will initially join only
a minimal set of LCT channels, possibly a single one. This rule has the a minimal set of LCT channels, possibly a single one, that in aggregate
purpose of preventing receivers from starting at high data rates. are carrying packets at a low rate. This rule has the purpose of
preventing receivers from starting at high data rates.
Multiple objects can be carried within the same LCT session. In this
case, each object is identified by a unique TOI. Note that even if a
server stops sending LCT packets for an old object before starting to
transmit LCT packets for a new object, both the network and the
underlying protocol layers can cause some reordering of packets,
especially when sent over different LCT channels, and thus receivers
^L Multiple objects can be carried either sequentially or concurrently
within the same LCT session. In this case, each object is identified by
a unique TOI. Note that even if a server stops sending packets for an
old object before starting to transmit packets for a new object, both
the network and the underlying protocol layers can cause some reordering
of packets, especially when sent over different LCT channels, and thus
receivers 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
MUST NOT assume that the reception of an LCT packet for a new object
means that there are no more LCT packets in transit for the previous
one, at least for some amount of time. one, at least for some amount of time.
A receiver MAY be concurrently joined to multiple LCT sessions. The A receiver may be concurrently joined to multiple LCT sessions from one
receiver MUST perform congestion control on each such LCT session. If or more senders. The receiver must perform congestion control on each
the congestion control protocol allows the receiver some flexibility in such LCT session. If the congestion control protocol allows the
terms of its actions within a session then the receiver MAY make choices receiver some flexibility in terms of its actions within a session then
to optimize the packet flow performance across the multiple LCT the receiver may make choices to optimize the packet flow performance
sessions, as long as the receiver still adheres to the congestion across the multiple LCT sessions, as long as the receiver still adheres
control rules for each LCT session individually. to the congestion control rules for each LCT session individually.
5. Security Considerations 5. Security Considerations
LCT can be subject to denial-of-service attacks by attackers which try LCT can be subject to denial-of-service attacks by attackers which try
to confuse the congestion control mechanism, or send forged packets to to confuse the congestion control mechanism, or send forged packets to
the session which would prevent successful reconstruction of large the session which would prevent successful reconstruction of large
portions of the data stream. portions of the objects.
The same exact problems are present in TCP, where an attacker can forge 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, 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 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 carrying compressed or otherwise coded data, even a single forged packet
could also cause incorrect reconstruction of the rest of the data could also cause incorrect reconstruction of the rest of the data
stream. stream.
It is therefore RECOMMENDED that LCT agents implement some form of It is therefore recommended that protocol instantiations that use LCT
authentication to protect themselves against such attacks. implement some form of packet authentication to protect themselves
against such attacks.
6. IANA Considerations 6. IANA Considerations
No information in this specification is subject to IANA registration. No information in this specification is subject to IANA registration.
Building blocks components used by LCT may introduce additional IANA Building blocks used in conjunction with LCT may introduce additional
considerations. IANA considerations.
7. Intellectual Property Issues 7. Intellectual Property Issues
No specific reliability protocol or congestion control protocol is No specific reliability protocol or congestion control protocol is
specified or referenced as mandatory in this document. specified or referenced as mandatory in this document.
LCT MAY be used with congestion control protocols and other protocols LCT may be used with congestion control protocols and other protocols,
which are proprietary, or have pending or granted patents. such as reliability protocols, which are proprietary or have pending or
granted patents.
^L
8. Acknowledgments 8. Acknowledgments
Thanks to Vincent Roca, Bruce Lueckenhoff and Hayder Radha for detailed Thanks to Vincent Roca, Bruce Lueckenhoff, Hayder Radha and Justin
comments on this document. Chapweske for detailed comments on this document.
[1] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital 9. References
Fountain Approach to Reliable Distribution of Bulk Data", Proceedings
ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.
[2] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist [1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
(GRA) Building Block, Motivation and Architecture", Internet Draft Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered
draft-ietf-rmt-gra-arch-00.txt, a work in progress. Multicast", Proceedings of Second International Workshop on Networked
Group Communications (NGC 2000), Palo Alto, CA, November 2000.
[3] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast [2] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital
File Distribution: Caching and Parameters Optimizations", Technical Fountain Approach to Reliable Distribution of Bulk Data", Proceedings
Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999. ACM SIGCOMM '98, Vancouver, Canada, September 1998.
[4] Handley, M., "SAP: Session Announcement Protocol", Internet Draft, [3] Gemmell, J., Schooler, E., and Gray, J., "Fcast Multicast File
IETF MMUSIC Working Group, Nov 1996, a work in progress. Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.
[5] Holbrook, H., Cain, B., "Source-Specific Multicast for IP", Internet [4] Holbrook, H. W., "A Channel Model for Multicast," Ph.D.
Draft, SSM Working Group, March 2001, draft-holbrook-ssm-arch-02.txt, a Dissertation, Stanford University, Department of Computer Science,
work in progress. Stanford, California, August 2001.
[6] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M., [5] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,
Crowcroft, J., "The use of Forward Error Correction in Reliable Crowcroft, J., "The use of Forward Error Correction in Reliable
Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November Multicast", Internet Draft draft-ietf-rmt-info-fec-01.txt, October 2001,
2000, a work in progress. a work in progress.
[7] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., [6] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft
draft-ietf-rmt-bb-fec-03.txt, July 2001. draft-ietf-rmt-bb-fec-04.txt, October 2001.
[8] Luby, M., Hernek, D., Kushi, D., Rasmussen, L., Simu, S., Vainish,
R., "Rich Content Control Protocol: A session control protocol
instantiation", Digital Fountain document, a work in progress.
[9] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion
control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in
progress.
[10] Rizzo, L., "Effective Erasure Codes for Reliable Computer [7] Rizzo, L., "Effective Erasure Codes for Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication Review, Communication Protocols", ACM SIGCOMM Computer Communication Review,
Vol.27, No.2, pp.24-36, Apr 1997. Vol.27, No.2, pp.24-36, Apr 1997.
^L [8] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and
Secure Source Authentication for Multicast", Network and Distributed
[11] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA: System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
Multicast Source Authentication Transform", draft-irtf-smug-
tesla-00.txt, November, 2000, a work in progress.
[12] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution [9] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution
protocol based on software FEC techniques", Proceedings of the Fourth protocol based on software FEC techniques", Proceedings of the Fourth
IEEES Workshop on the Architecture and Implementation of High IEEES Workshop on the Architecture and Implementation of High
Performance Communication Systems, HPCS'97, Chalkidiki, Greece, June Performance Communication Systems, HPCS'97, Chalkidiki Greece, June
1997. 1997.
[13] Speakman, T., Farinacci, D., Crowcroft, J., Gemmell, J., Lin, S., [10] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion
Tweedly, A., Leshchiner, D., Luby, M., Bhaskar, N., Edmonstone, R., control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August
Johnson, K., Montgomery, T., Rizzo, L., Sumanasekera, R., Vicisano, L., 2000.
"PGM Reliable Transport Protocol", draft-speakman-pgm-spec-06.txt, a
work in progress.
[14] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion [11] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion
Control for Layered Multicast Data Transfer", IEEE Infocom '98, San Control for Layered Multicast Data Transfer", IEEE Infocom '98, San
Francisco, CA, Mar.28-Apr.1 1998. Francisco, CA, Mar.28-Apr.1 1998.
[15] Vicisano, L., "Notes On a Cumulative Layered Organization of Data 10. Authors' Addresses
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 Michael Luby
luby@digitalfountain.com luby@digitalfountain.com
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA, USA, 94538 Fremont, CA, USA, 94538
Jim Gemmell Jim Gemmell
jgemmell@microsoft.com jgemmell@microsoft.com
Microsoft Research Microsoft Research
301 Howard St., #830 301 Howard St., #830
San Francisco, CA, USA, 94105 San Francisco, CA, USA, 94105
Lorenzo Vicisano Lorenzo Vicisano
lorenzo@cisco.com lorenzo@cisco.com
cisco Systems, Inc. cisco Systems, Inc.
170 West Tasman Dr., 170 West Tasman Dr.,
San Jose, CA, USA, 95134 San Jose, CA, USA, 95134
^L
Luigi Rizzo Luigi Rizzo
luigi@iet.unipi.it luigi@iet.unipi.it
ACIRI/ICSI, ACIRI/ICSI,
1947 Center St, Berkeley, CA, USA, 94704 1947 Center St, Berkeley, CA, USA, 94704
and and
Dip. Ing. dell'Informazione, Dip. Ing. dell'Informazione,
Univ. di Pisa Univ. di Pisa
via Diotisalvi 2, 56126 Pisa, Italy via Diotisalvi 2, 56126 Pisa, Italy
Mark Handley Mark Handley
skipping to change at page 26, line 5 skipping to change at page 28, line 5
1947 Center St, 1947 Center St,
Berkeley, CA, USA, 94704 Berkeley, CA, USA, 94704
Jon Crowcroft Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street, Gower Street,
London WC1E 6BT, UK London WC1E 6BT, UK
^L 11. Full Copyright Statement
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself 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 may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE." FITNESS FOR A PARTICULAR PURPOSE."
^L
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/