draft-ietf-rmt-bb-lct-04.txt   rfc3451.txt 
Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-lct-04.txt J.Gemmell/Microsoft
L.Vicisano/Cisco
L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI
J. Crowcroft/UCL
8 February 2002
Expires: August 2002
Layered Coding Transport building block Network Working Group M. Luby
Request for Comments: 3451 Digital Fountain
Status of this Document Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
This document is an Internet-Draft and is in full conformance with all Layered Coding Transport (LCT) Building Block
provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are valid for a maximum of six months and may be Status of this Memo
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at This memo defines an Experimental Protocol for the Internet
http://www.ietf.org/ietf/1id-abstracts.txt community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
To view the list Internet-Draft Shadow Directories, see Copyright Notice
http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be Copyright (C) The Internet Society (2002). All Rights Reserved.
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.
Abstract Abstract
Layered Coding Transport (LCT) provides transport level Layered Coding Transport (LCT) provides transport level support for
support for reliable content delivery and stream delivery reliable content delivery and stream delivery protocols. LCT is
protocols. LCT is specifically designed to support protocols specifically designed to support protocols using IP multicast, but
using IP multicast, but also provides support to protocols also provides support to protocols that use unicast. LCT is
that use unicast. LCT is compatible with congestion control compatible with congestion control that provides multiple rate
that provides muliple rate delivery to receivers and is also delivery to receivers and is also compatible with coding techniques
compatible with coding techniques that provide reliable that provide reliable delivery of content.
delivery of content.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction...................................................2
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 4 2. Rationale......................................................3
3. Functionality . . . . . . . . . . . . . . . . . . . . . 5 3. Functionality..................................................4
4. Applicability . . . . . . . . . . . . . . . . . . . . . 8 4. Applicability..................................................7
4.1. Environmental Requirements and Considerations. . . . 9 4.1 Environmental Requirements and Considerations...............8
4.2. Delivery service models. . . . . . . . . . . . . . . 11 4.2 Delivery service models....................................10
4.3. Congestion Control . . . . . . . . . . . . . . . . . 12 4.3 Congestion Control.........................................11
5. Packet Header Fields. . . . . . . . . . . . . . . . . . 12 5. Packet Header Fields..........................................12
5.1. Default LCT header format. . . . . . . . . . . . . . 13 5.1 Default LCT header format..................................12
5.2. Header-Extension Fields. . . . . . . . . . . . . . . 19 5.2 Header-Extension Fields....................................17
6. Operations. . . . . . . . . . . . . . . . . . . . . . . 22 6. Operations....................................................20
6.1. Sender Operation . . . . . . . . . . . . . . . . . . 22 6.1 Sender Operation...........................................20
6.2. Receiver Operation . . . . . . . . . . . . . . . . . 24 6.2 Receiver Operation.........................................22
7. Requirements from Other Building Blocks . . . . . . . . 25 7. Requirements from Other Building Blocks.......................23
8. Security Considerations . . . . . . . . . . . . . . . . 26 8. Security Considerations.......................................24
9. IANA Considerations . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations...........................................25
10. Intellectual Property Issues . . . . . . . . . . . . . 27 10. Acknowledgments..............................................25
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . 27 11. References...................................................25
12. References . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses...............................................28
13. Authors' Addresses . . . . . . . . . . . . . . . . . . 29 Full Copyright Statement.........................................29
14. Full Copyright Statement . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document describes a massively scalable reliable content delivery Layered Coding Transport provides transport level support for
and stream delivery transport level support, Layered Coding Transport reliable content delivery and stream delivery protocols. Layered
(LCT), for multiple rate content delivery primarily designed to be used Coding Transport is specifically designed to support protocols using
with the IP multicast network service, but may also be used with other IP multicast, but also provides support to protocols that use
basic underlying network or transport services such as unicast UDP. LCT unicast. Layered Coding Transport is compatible with congestion
supports both reliable and unreliable delivery. control that provides multiple rate delivery to receivers and is also
compatible with coding techniques that provide reliable delivery of
content.
This document describes a building block as defined in RFC3048 [26]. This document describes a building block as defined in RFC 3048 [26].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is a product of the IETF RMT WG and follows the
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this general guidelines provided in RFC 3269 [24].
document are to be interpreted as described in RFC2119 [2].
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 BCP 14, RFC 2119 [2].
Statement of Intent
This memo contains part of the definitions necessary to fully
specify a Reliable Multicast Transport protocol in accordance with
RFC 2357. As per RFC 2357, the use of any reliable multicast
protocol in the Internet requires an adequate congestion control
scheme.
While waiting for such a scheme to be available, or for an
existing scheme to be proven adequate, the Reliable Multicast
Transport working group (RMT) publishes this Request for Comments
in the "Experimental" category.
It is the intent of RMT to re-submit this specification as an IETF
Proposed Standard as soon as the above condition is met.
2. Rationale 2. Rationale
LCT provides transport level support for massively scalable protocols LCT provides transport level support for massively scalable protocols
using the IP multicast network service. The support that LCT provides using the IP multicast network service. The support that LCT
is common to a variety of very important applications, including provides is common to a variety of very important applications,
reliable content delivery and streaming applications. including reliable content delivery and streaming applications.
An LCT session comprises multiple channels originating at a single An LCT session comprises multiple channels originating at a single
sender that are used for some period of time to carry packets pertaining sender that are used for some period of time to carry packets
to the transmission of one or more objects that can be of interest to pertaining to the transmission of one or more objects that can be of
receivers. The logic behind defining a session as originating from a interest to receivers. The logic behind defining a session as
single sender is that this is the right granularity to regulate packet originating from a single sender is that this is the right
traffic via congestion control. One rationale for using multiple granularity to regulate packet traffic via congestion control. One
channels within the same session is that there are massively scalable rationale for using multiple channels within the same session is that
congestion control protocols that use multiple channels per session. there are massively scalable congestion control protocols that use
These congestion control protocols are considered to be layered because multiple channels per session. These congestion control protocols
a receiver joins and leaves channels in a layered order during its are considered to be layered because a receiver joins and leaves
participation in the session. The use of layered channels is also channels in a layered order during its participation in the session.
useful for streaming applications. The use of layered channels is also useful for streaming
applications.
There are coding techniques that provide massively scalable reliability There are coding techniques that provide massively scalable
and asynchronous delivery which are compatible with both layered reliability and asynchronous delivery which are compatible with both
congestion control and with LCT. When all are combined the result is a layered congestion control and with LCT. When all are combined the
massively scalable reliable asynchronous content delivery protocol that result is a massively scalable reliable asynchronous content delivery
is network friendly. LCT also provides functionality that can be used protocol that is network friendly. LCT also provides functionality
for other applications as well, e.g., layered streaming applications. that can be used for other applications as well, e.g., layered
streaming applications.
LCT avoids providing functionality that is not massively scalable. For LCT avoids providing functionality that is not massively scalable.
example, LCT does not provide any mechanisms for sending information For example, LCT does not provide any mechanisms for sending
from receivers to senders, although this does not rule out protocols information from receivers to senders, although this does not rule
that both use LCT and do require sending information from receivers to out protocols that both use LCT and do require sending information
senders. from receivers to senders.
LCT includes general support for congestion control that must be used LCT includes general support for congestion control that must be
but does not specify which congestion control should be used. The used. It does not, however, specify which congestion control should
rationale for this is that congestion control must be provided by any be used. The rationale for this is that congestion control must be
protocol that is network friendly, and yet the different applications provided by any protocol that is network friendly, and yet the
that can use LCT will not have the same requirements for congestion different applications that can use LCT will not have the same
control. For example, a content delivery protocol may strive to use all requirements for congestion control. For example, a content delivery
available bandwidth between receivers and the sender, and thus it must protocol may strive to use all available bandwidth between receivers
drastically back off its rate when there is competing traffic. On the and the sender. It must, therefore, drastically back off its rate
other hand, a streaming delivery protocol may strive to maintain a when there is competing traffic. On the other hand, a streaming
constant rate instead of trying to use all available bandwidth, and thus delivery protocol may strive to maintain a constant rate instead of
it may not back off its rate as fast when there is competing traffic. trying to use all available bandwidth, and it may not back off its
rate as fast when there is competing traffic.
Beyond support for congestion control, LCT provides a number of fields Beyond support for congestion control, LCT provides a number of
and supports functionality commonly required by many protocols. For fields and supports functionality commonly required by many
example, LCT provides a Transmission Session ID that can be used to protocols. For example, LCT provides a Transmission Session ID that
identify which session each received packet belongs to. This is can be used to identify which session each received packet belongs
important because a receiver may be joined to many sessions to. This is important because a receiver may be joined to many
concurrently, and thus it is very useful to be able to demultiplex sessions concurrently, and thus it is very useful to be able to
packets as they arrive according to which session they belong to. As demultiplex packets as they arrive according to which session they
another example, LCT provides optional support for identifying which belong to. As another example, LCT provides optional support for
object each packet is carrying information about. Thus, LCT provides identifying which object each packet is carrying information about.
many of the commonly used fields and support for functionality required Therefore, LCT provides many of the commonly used fields and support
by many protocols. for functionality required by many protocols.
3. Functionality 3. Functionality
An LCT session consists of a set of logically grouped LCT channels An LCT session consists of a set of logically grouped LCT channels
associated with a single sender carrying packets with LCT headers for associated with a single sender carrying packets with LCT headers for
one or more objects. An LCT channel is defined by the combination of a one or more objects. An LCT channel is defined by the combination of
sender and an address associated with the channel by the sender. A a sender and an address associated with the channel by the sender. A
receiver joins a channel to start receiving the data packets sent to the receiver joins a channel to start receiving the data packets sent to
channel by the sender, and a receiver leaves a channel to stop receiving the channel by the sender, and a receiver leaves a channel to stop
data packets from the channel. receiving data packets from the channel.
LCT is meant to be combined with other building blocks so that the
resulting overall protocol is massively scalable. Scalability refers to
the behavior of the protocol in relation to the number of receivers and
network paths, their heterogeneity, and the ability to accommodate
dynamically variable sets of receivers. Scalability limitations can
come from memory or processing requirements, or from the amount of
feedback control and redundant data 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 LCT header provides a number of fields that are useful for conveying LCT is meant to be combined with other building blocks so that the
in-band session information to receivers. One of the required fields is resulting overall protocol is massively scalable. Scalability refers
the Transmission Session ID (TSI), which allows the receiver of a to the behavior of the protocol in relation to the number of
session to uniquely identify received packets as part of the session. receivers and network paths, their heterogeneity, and the ability to
Another required field is the Congestion Control Information (CCI), accommodate dynamically variable sets of receivers. Scalability
which allows the receiver to perform the required congestion control on limitations can come from memory or processing requirements, or from
the packets received within the session. Other LCT fields provide the amount of feedback control and redundant data packet traffic
optional but often very useful other information for the session. For generated by the protocol. In turn, such limitations may be a
example, the Transport Object Identifier (TOI) identifies which object consequence of the features that a complete reliable content delivery
the packet contains data for. As other examples, the Sender Current or stream delivery protocol is expected to provide.
Time (SCT) conveys the time when the packet was sent from the sender to
the receiver, the Expected Residual Time (ERT) conveys the amount of
time the session will be continue for, flags for indicating the close of
the session and the close of sending packets for an object, and header
extensions for fields that for example can be used for packet
authentication.
LCT provides support for congestion control. Congestion control MUST be The LCT header provides a number of fields that are useful for
used that conforms to RFC2357 [16] between receivers and the sender for conveying in-band session information to receivers. One of the
each LCT session. Congestion control refers to the ability to adapt required fields is the Transmission Session ID (TSI), which allows
throughput to the available bandwidth on the path from the sender to a the receiver of a session to uniquely identify received packets as
receiver, and to share bandwidth fairly with competing flows such as part of the session. Another required field is the Congestion
TCP. Thus, the total flow of packets flowing to each receiver Control Information (CCI), which allows the receiver to perform the
participating in an LCT session MUST NOT compete unfairly with existing required congestion control on the packets received within the
flow adaptive protocols such as TCP. session. Other LCT fields provide optional but often very useful
additional information for the session. For example, the Transport
Object Identifier (TOI) identifies which object the packet contains
data for. As other examples, the Sender Current Time (SCT) conveys
the time when the packet was sent from the sender to the receiver,
the Expected Residual Time (ERT) conveys the amount of time the
session will be continued for, flags for indicating the close of the
session and the close of sending packets for an object, and header
extensions for fields that for example can be used for packet
authentication.
A multiple rate or a single rate congestion control protcol can be used LCT provides support for congestion control. Congestion control MUST
with LCT. For multiple rate protocols, a session typically consists of be used that conforms to RFC 2357 [13] between receivers and the
more than one channel and the sender sends packets to the channels in sender for each LCT session. Congestion control refers to the
the session at rates that do not depend on the receivers. Each receiver ability to adapt throughput to the available bandwidth on the path
adjusts its reception rate during its participation in the session by from the sender to a receiver, and to share bandwidth fairly with
joining and leaving channels dynamically depending on the available competing flows such as TCP. Thus, the total flow of packets flowing
bandwidth to the sender independent of all other receivers. Thus, for to each receiver participating in an LCT session MUST NOT compete
multiple rate protocols, the reception rate of each receiver may vary unfairly with existing flow adaptive protocols such as TCP.
dynamically independent of the other receivers.
For single rate protocols, a session typically consists of one channel A multiple rate or a single rate congestion control protocol can be
and the sender sends packets to the channel at variable rates over time used with LCT. For multiple rate protocols, a session typically
depending on feedback from receivers. Each receiver remains joined to consists of more than one channel and the sender sends packets to the
the channel during its participation in the session. Thus, for single channels in the session at rates that do not depend on the receivers.
rate protocols, the reception rate of each receiver may vary dynamically Each receiver adjusts its reception rate during its participation in
but in coordination with all receivers. Generally, a multiple rate the session by joining and leaving channels dynamically depending on
protocol is preferable to a single rate protocol in a heterogeneous the available bandwidth to the sender independent of all other
receiver environment, since generally it more easily achieves receivers. Thus, for multiple rate protocols, the reception rate of
scalability to many receivers and provides higher throughput to each each receiver may vary dynamically independent of the other
individual receiver. Some possible multiple rate congestion control receivers.
protocols are described in [25] and [3]. A possible single rate
congestion control protocol is described in [22].
Layered coding refers to the ability to produce a coded stream of For single rate protocols, a session typically consists of one
packets that can be partioned into an ordered set of layers. The coding channel and the sender sends packets to the channel at variable rates
is meant to provide some form of reliability, and the layering is meant over time depending on feedback from receivers. Each receiver
to allow the receiver experience (in terms of quality of playout, or remains joined to the channel during its participation in the
overall transfer speed) to vary in a predictable way depending on how session. Thus, for single rate protocols, the reception rate of each
many consecutive layers of packets the receiver is receiving. receiver may vary dynamically but in coordination with all receivers.
Layered coding can be naturally combined with multiple rate congestion Generally, a multiple rate protocol is preferable to a single rate
control. For example, the sender could send the packets for each layer protocol in a heterogeneous receiver environment, since generally it
to a separate channel associated with the session, and then receivers more easily achieves scalability to many receivers and provides
dynamically join and leave channels to adjust their reception rate higher throughput to each individual receiver. Some possible
according to the multiple rate congestion control protocol. multiple rate congestion control protocols are described in [22],
[3], and [25]. A possible single rate congestion control protocol is
described in [19].
Layered coding can also be combined with single rate congestion control. Layered coding refers to the ability to produce a coded stream of
For example, the sender could dynamically vary how many layers are sent packets that can be partitioned into an ordered set of layers. The
to the channel associated with the session as the rate of transmission coding is meant to provide some form of reliability, and the layering
varies according to the single rate congestion control protocol. is meant to allow the receiver experience (in terms of quality of
playout, or overall transfer speed) to vary in a predictable way
depending on how many consecutive layers of packets the receiver is
receiving.
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
TV broadcast could be partitioned into three layers, corresponding to with a TV broadcast could be partitioned into three layers,
black and white, color, and HDTV quality. Receivers can experience corresponding to black and white, color, and HDTV quality. Receivers
different quality without the need for the sender to replicate can experience different quality without the need for the sender to
information in the different layers. replicate 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. Descriptions of this techniques are used for coding the data stream. Descriptions of this
can be found in [23], [21], [7], [25] and [4]. By using FEC, the data can be found in [20], [18], [7], [22] and [4]. By using FEC, the
stream is transformed in such a way that reconstruction of a data object data stream is transformed in such a way that reconstruction of a
does not depend on the reception of specific data packets, but only on data object does not depend on the reception of specific data
the number of different packets received. As a result, by increasing packets, but only on the number of different packets received. As a
the number of layers a receiver is receiving from, the receiver can result, by increasing the number of layers a receiver is receiving
reduce the transfer time accordingly. Using FEC to provide reliability from, the receiver can reduce the transfer time accordingly. Using
can increase scalability dramatically in comparison to other methods for FEC to provide reliability can increase scalability dramatically in
providing reliability. More details on the use of FEC for reliable comparison to other methods for providing reliability. More details
content delivery can be found in [14]. on the use of FEC for reliable content delivery can be found in [11].
Reliable protocols aim at giving guarantees on the reliable delivery of Reliable protocols aim at giving guarantees on the reliable delivery
data from the sender to the intended recipients. Guarantees vary from of data from the sender to the intended recipients. Guarantees vary
simple packet data integrity to reliable delivery of a precise copy of from simple packet data integrity to reliable delivery of a precise
an object to all intended recipients. Several reliable content delivery copy of an object to all intended recipients. Several reliable
protocols have been built on top of IP multicast using methods other content delivery protocols have been built on top of IP multicast
than FEC, but scalability was not the primary design goal for many of using methods other than FEC, but scalability was not the primary
them. design goal for many of them.
Two of the key difficulties in scaling reliable content delivery using Two of the key difficulties in scaling reliable content delivery
IP multicast are dealing with the amount of data that flows from using IP multicast are dealing with the amount of data that flows
receivers back to the sender, and the associated response (generally from receivers back to the sender, and the associated response
data retransmissions) from the sender. Protocols that avoid any such (generally data retransmissions) from the sender. Protocols that
feedback, and minimize the amount of retransmissions, can be massively avoid any such feedback, and minimize the amount of retransmissions,
scalable. LCT can be used in conjunction with FEC codes or a layered can be massively scalable. LCT can be used in conjunction with FEC
codec to achieve reliability with little or no feedback. codes or a layered codec to achieve reliability with little or no
feedback.
Protocol instantiations MAY be built by combining the LCT framework with Protocol instantiations MAY be built by combining the LCT framework
other components. A complete protocol instantiation that uses LCT MUST with other components. A complete protocol instantiation that uses
include a congestion control protocol that is compatible with LCT and LCT MUST include a congestion control protocol that is compatible
that conforms to RFC2357 [16]. A complete protocol instantiation that with LCT and that conforms to RFC 2357 [13]. A complete protocol
uses LCT MAY include a scalable reliability protocol that is compatible instantiation that uses LCT MAY include a scalable reliability
with LCT, it MAY include an session control protocol that is compatible protocol that is compatible with LCT, it MAY include an session
with LCT, and it MAY include other protocols such as security protocols. control protocol that is compatible with LCT, and it MAY include
other protocols such as security protocols.
4. Applicability 4. Applicability
An LCT session comprises a logically related set of one or more LCT 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 channels originating at a single sender. The channels are used for
time to carry packets containing LCT headers pertaining to the some period of time to carry packets containing LCT headers, and
transmission of one or more objects that can be of interest to these headers pertain to the transmission of one or more objects that
receivers. can be of interest to receivers.
LCT is most applicable for delivery of objects or streams of substantial LCT is most applicable for delivery of objects or streams in a
length, i.e., objects or streams that range in length from hundreds of session of substantial length, i.e., objects or streams that range in
kilobytes to many gigabytes, and whose transfer time is in the order of aggregate length from hundreds of kilobytes to many gigabytes, and
tens of seconds or more. where the duration of the session is on the order of tens of seconds
or more.
As an example, an LCT session could be used to deliver a TV program As an example, an LCT session could be used to deliver a TV program
using three LCT channels. Receiving packets from the first LCT channel using three LCT channels. Receiving packets from the first LCT
could allow black and white reception, receiving the first two LCT channel could allow black and white reception. Receiving the first
channels could also permit color reception, whereas receiving all three two LCT channels could also permit color reception. Receiving all
channels could allow HDTV quality reception. Objects in this example three channels could allow HDTV quality reception. Objects in this
could correspond to individual TV programs being transmitted. 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
different rates, using FEC coding. A receiver may join and concurrently at different rates, using FEC coding. A receiver may join and
receive packets from subsets of these channels, until it has enough concurrently receive packets from subsets of these channels, until it
packets in total to recover the object, then leave the session (or has enough packets in total to recover the object, then leave the
remain connected listening for session description information only) session (or remain connected listening for session description
until it is time to receive the next object. In this case, the quality information only) until it is time to receive the next object. In
metric is the time required to receive each object. this case, the quality metric is the time required to receive each
object.
Before joining a session, the receivers MUST obtain enough of the Before joining a session, the receivers MUST obtain enough of the
session description to start the session. This MUST include the session description to start the session. This MUST include the
relevant session parameters needed by a receiver to participate in the relevant session parameters needed by a receiver to participate in
session, including all information relevant to congestion control. The the session, including all information relevant to congestion
session description is determined by the sender, and is typically control. The session description is determined by the sender, and is
communicated to the receivers out-of-band. In some cases, as described typically communicated to the receivers out-of-band. In some cases,
later, parts of the session description that are not required to as described later, parts of the session description that are not
initiate a session MAY be included in the LCT header or communicated to required to initiate a session MAY be included in the LCT header or
a receiver out-of-band after the receiver has joined the session. communicated to a receiver out-of-band after the receiver has joined
the session.
An encoder MAY be used to generate the data that is placed in the packet An encoder MAY be used to generate the data that is placed in the
payload in order to provide reliability. A suitable decoder is used to packet payload in order to provide reliability. A suitable decoder
reproduce the original information from the packet payload. There MAY is used to reproduce the original information from the packet
be a reliability header that follows the LCT header if such an encoder payload. There MAY be a reliability header that follows the LCT
and decoder is used. The reliability header helps to describe the header if such an encoder and decoder is used. The reliability
encoding data carried in the payload of the packet. The format of the header helps to describe the encoding data carried in the payload of
reliability header depends on the coding used, and this is negotiated the packet. The format of the reliability header depends on the
out-of-band. As an example, one of the FEC headers described in [15] coding used, and this is negotiated out-of-band. As an example, one
could be used. of the FEC headers described in [12] could be used.
For LCT, when multiple rate congestion control is used, congestion For LCT, when multiple rate congestion control is used, congestion
control is achieved by sending packets associated with a given session control is achieved by sending packets associated with a given
to several LCT channels. Individual receivers dynamically join one or session to several LCT channels. Individual receivers dynamically
more of these channels, according to the network congestion as seen by join one or more of these channels, according to the network
the receiver. LCT headers include an opaque field which MUST be used to congestion as seen by the receiver. LCT headers include an opaque
convey congestion control information to the receivers. The actual field which MUST be used to convey congestion control information to
congestion control scheme to use with LCT is negotiated out-of-band. the receivers. The actual congestion control scheme to use with LCT
Some examples of congestion control protocols that may be suitable for is negotiated out-of-band. Some examples of congestion control
content delivery are described in [25] and [3]. Other congestion protocols that may be suitable for content delivery are described in
controls may be suitable when LCT is used for a streaming application. [22], [3], and [25]. Other congestion controls may be suitable when
LCT is used for a streaming application.
This document does not specify and restrict the type of exchanges This document does not specify and restrict the type of exchanges
between LCT (or any PI built on top of LCT) and an upper application. between LCT (or any PI built on top of LCT) and an upper application.
Some upper APIs may use an object-oriented approach, where the only Some upper APIs may use an object-oriented approach, where the only
possible unit of data exchanged between LCT (or any PI built on top of possible unit of data exchanged between LCT (or any PI built on top
LCT) and an application, either at a source or at a receiver, is an of LCT) and an application, either at a source or at a receiver, is
object. Other APIs may enable a sending or receiving application to an object. Other APIs may enable a sending or receiving application
exchange a subset of an object with LCT (or any PI built on top of LCT), to exchange a subset of an object with LCT (or any PI built on top of
or may even follow a streaming model. These considerations are outside LCT), or may even follow a streaming model. These considerations are
the scope of this document. outside the scope of this document.
4.1. Environmental Requirements and Considerations 4.1 Environmental Requirements and Considerations
LCT is intended for congestion controlled delivery of objects and LCT is intended for congestion controlled delivery of objects and
streams (both reliable content delivery and streaming of multimedia streams (both reliable content delivery and streaming of multimedia
information). information).
LCT can be used with both multicast and unicast delivery. LCT requires LCT can be used with both multicast and unicast delivery. LCT
connectivity between a sender and receivers, but does not require requires connectivity between a sender and receivers but does not
connectivity from receivers to a sender. LCT inherently works with all require connectivity from receivers to a sender. LCT inherently
types of networks, including LANs, WANs, Intranets, the Internet, works with all types of networks, including LANs, WANs, Intranets,
asymmetric networks, wireless networks, and satellite networks. Thus, the Internet, asymmetric networks, wireless networks, and satellite
the inherent raw scalability of LCT is unlimited. However, when other networks. Thus, the inherent raw scalability of LCT is unlimited.
specific applications are built on top of LCT, then these applications However, when other specific applications are built on top of LCT,
by their very nature may limit scalability. For example, if an then these applications by their very nature may limit scalability.
application requires receivers to retrieve out of band information in For example, if an application requires receivers to retrieve out of
order to join a session, or an application allows receivers to send band information in order to join a session, or an application allows
requests back to the sender to report reception statistics, then the receivers to send requests back to the sender to report reception
scalability of the application is limited by the ability to send, statistics, then the scalability of the application is limited by the
receive, and process this additional data. ability to send, receive, and process this additional data.
LCT requires receivers to be able to uniquely identify and demultiplex LCT requires receivers to be able to uniquely identify and
packets associated with an LCT session. In particular, there MUST be a demultiplex packets associated with an LCT session. In particular,
Transport Session Identifier (TSI) associated with each LCT session. there MUST be a Transport Session Identifier (TSI) associated with
The TSI is scoped by the IP address of the sender, and the IP address of each LCT session. The TSI is scoped by the IP address of the sender,
the sender together with the TSI MUST uniquely identify the session. If and the IP address of the sender together with the TSI MUST uniquely
the underlying transport is UDP as described in RFC768 [19], then the 16 identify the session. If the underlying transport is UDP as
bit UDP source port number MAY serve as the TSI for the session. The described in RFC 768 [16], then the 16 bit UDP source port number MAY
TSI value MUST be the same in all places it occurs within a packet. If serve as the TSI for the session. The TSI value MUST be the same in
there is no underlying TSI provided by the network, transport or any all places it occurs within a packet. If there is no underlying TSI
other layer, then the TSI MUST be included in the LCT header. provided by the network, transport or any other layer, then the TSI
MUST be included in the LCT header.
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
reception, packet reception order, and which does not have any support packet reception or packet reception order, and which does not have
for flow or congestion control. For example, the Any-Source Multicast any support for flow or congestion control. For example, the Any-
(ASM) model of IP multicast as defined in RFC1112 [5] is such a "best Source Multicast (ASM) model of IP multicast as defined in RFC 1112
effort" network service. While the basic service provided by RFC1112 is [5] is such a "best effort" network service. While the basic service
largely scalable, providing congestion control or reliability should be provided by RFC 1112 is largely scalable, providing congestion
done carefully to avoid severe scalability limitations, especially in control or reliability should be done carefully to avoid severe
presence of heterogeneous sets of receivers. scalability limitations, especially in presence of heterogeneous sets
of receivers.
There are currently two models of multicast delivery, the Any-Source There are currently two models of multicast delivery, the Any-Source
Multicast (ASM) model as defined in RFC1112 [5] and the Source-Specific Multicast (ASM) model as defined in RFC 1112 [5] and the Source-
Multicast (SSM) model as defined in [10]. LCT works with both multicast Specific Multicast (SSM) model as defined in [10]. LCT works with
models, but in a slightly different way with somewhat different both multicast models, but in a slightly different way with somewhat
environmental concerns. When using ASM, a sender S sends packets to a different environmental concerns. When using ASM, a sender S sends
multicast group G, and the LCT channel address consists of the pair packets to a multicast group G, and the LCT channel address consists
(S,G), where S is the IP address of the sender and G is a multicast of the pair (S,G), where S is the IP address of the sender and G is a
group address. When using SSM, a sender S sends packets to an SSM multicast group address. When using SSM, a sender S sends packets to
channel (S,G), and the LCT channel address coincides with the SSM an SSM channel (S,G), and the LCT channel address coincides with the
channel address. SSM channel address.
A sender can locally allocate unique SSM channel addresses, and this A sender can locally allocate unique SSM channel addresses, and this
makes allocation of LCT channel addresses easy with SSM. To allocate makes allocation of LCT channel addresses easy with SSM. To allocate
LCT channel addresses using ASM, the sender must uniquely chose the ASM LCT channel addresses using ASM, the sender must uniquely chose the
multicast group address across the scope of the group, and this makes ASM multicast group address across the scope of the group, and this
allocation of LCT channel addresses more difficult with ASM. makes allocation of LCT channel addresses more difficult with ASM.
LCT channels and SSM channels coincide, and thus the receiver will only LCT channels and SSM channels coincide, and thus the receiver will
receive packets sent to the requested LCT channel. With ASM, the only receive packets sent to the requested LCT channel. With ASM,
receiver joins an LCT channel by joining a multicast group G, and all the receiver joins an LCT channel by joining a multicast group G, and
packets sent to G, regardless of the sender, may be received by the all packets sent to G, regardless of the sender, may be received by
receiver. Thus, SSM has compelling security advantages over ASM for the receiver. Thus, SSM has compelling security advantages over ASM
prevention of denial of service attacks. In either case, receivers for prevention of denial of service attacks. In either case,
SHOULD use mechanisms to filter out packets from unwanted sources. receivers SHOULD use mechanisms to filter out packets from unwanted
sources.
Some networks are not amenable to some congestion control protocols that Some networks are not amenable to some congestion control protocols
could be used with LCT. In particular, for a satellite or wireless that could be used with LCT. In particular, for a satellite or
network, there may be no mechanism for receivers to effectively reduce wireless network, there may be no mechanism for receivers to
their reception rate since there may be a fixed transmission rate effectively reduce their reception rate since there may be a fixed
allocated to the session. transmission rate allocated to the session.
4.2. Delivery service models 4.2 Delivery service models
LCT can support several different delivery service models. Two examples LCT can support several different delivery service models. Two
are briefly described here. examples 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
is to deliver a series of objects. For example, a receiver could join delivery is to deliver a series of objects. For example, a receiver
the session and dynamically adapt the number of LCT channels the could join the session and dynamically adapt the number of LCT
receiver is joined to until enough packets have been received to channels the receiver is joined to until enough packets have been
reconstruct an object. After reconstructing the object the receiver may received to reconstruct an object. After reconstructing the object
stay in the session and wait for the transmission of the next object. the receiver may stay in the session and wait for the transmission of
the next object.
The push model is particularly attractive in satellite networks and The push model is particularly attractive in satellite networks and
wireless networks. In these cases, a session may consist of one fixed wireless networks. In these cases, a session may consist of one
rate LCT channel. fixed rate LCT channel.
On-demand content delivery model. On-demand content delivery model.
For an on-demand content delivery service model, senders typically For an on-demand content delivery service model, senders typically
transmit for some given time period selected to be long enough to allow transmit for some given time period selected to be long enough to
all the intended receivers to join the session and recover the object. allow all the intended receivers to join the session and recover the
For example a popular software update might be transmitted using LCT for object. For example a popular software update might be transmitted
several days, even though a receiver may be able to complete the using LCT for several days, even though a receiver may be able to
download in one hour total of connection time, perhaps spread over complete the download in one hour total of connection time, perhaps
several intervals of time. spread over 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
number of LCT channels they subscribe to (and the reception quality) the number of LCT channels they subscribe to according to the
according to the available bandwidth. Receivers then drop from the available bandwidth. Receivers then drop from the session when they
session when they have received enough packets to recover the object. have received enough packets to recover the object.
As an example, assume that an object is 50 MB. The sender could send 1 As an example, assume that an object is 50 MB. The sender could send
KB packets to the first LCT channel at 50 packets per second, so that 1 KB packets to the first LCT channel at 50 packets per second, so
receivers using just this LCT channel could complete reception of the that receivers using just this LCT channel could complete reception
object in 1,000 seconds in absence of loss, and would be able to of the object in 1,000 seconds in absence of loss, and would be able
complete reception even in presence of some substantial amount of losses to complete reception even in presence of some substantial amount of
with the use of coding for reliability. Furthermore, the sender could losses with the use of coding for reliability. Furthermore, the
use a number of LCT channels such that the aggregate rate of 1 KB sender could use a number of LCT channels such that the aggregate
packets to all LCT channels is 1,000 packets per second, so that a rate of 1 KB packets to all LCT channels is 1,000 packets per second,
receiver could be able to complete reception of the object in as little so that a receiver could be able to complete reception of the object
50 seconds (assuming no loss and that the congestion control mechanism in as little 50 seconds (assuming no loss and that the congestion
immediately converges to the use of all LCT channels). control mechanism 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. A description of
many potential applications, the appropriate delivery service model, and the many potential applications, the appropriate delivery service
the additional mechanisms to support such functionalities when combined model, and the additional mechanisms to support such functionalities
with LCT is beyond the scope of this document. This document only when combined with LCT is beyond the scope of this document. This
attempts to describe the minimal common scalable elements to these document only attempts to describe the minimal common scalable
diverse applications using LCT as the delivery transport. elements to these diverse applications using LCT as the delivery
transport.
4.3. Congestion Control 4.3 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
in presence of congestion and gradually increase it in the absence of throughput in presence of congestion and gradually increase it in the
congestion, the actual dynamic behavior (e.g. response to single losses) absence of congestion, the actual dynamic behavior (e.g. response to
can vary. single losses) can vary.
Some possible congestion control protocols for reliable content delivery Some possible congestion control protocols for reliable content
using LCT are described in [25] and [3]. Different delivery service delivery using LCT are described in [22], [3], and [25]. Different
models might require different congestion control protocols. delivery service models might require different congestion control
protocols.
5. Packet Header Fields 5. Packet Header Fields
Packets sent to an LCT session MUST include an "LCT header". The LCT Packets sent to an LCT session MUST include an "LCT header". The LCT
header format described below is the default format, and this is the header format described below is the default format, and this is the
format that is recommended for use by protocol instantiations to ensure format that is recommended for use by protocol instantiations to
a uniform format across different protocol instantiations. Other LCT ensure a uniform format across different protocol instantiations.
header formats MAY be used by protocol instantiations, but if the Other LCT header formats MAY be used by protocol instantiations, but
default LCT header format is not used by a protocol instantiation that if the default LCT header format is not used by a protocol
uses LCT, then the protocol instantiation MUST specify the lengths and instantiation that uses LCT, then the protocol instantiation MUST
positions within the LCT header it uses of all fields described in the specify the lengths and positions within the LCT header it uses of
default LCT header. all fields described in the default LCT header.
Other building blocks MAY describe some of the same fields as described Other building blocks MAY describe some of the same fields as
for the LCT header. It is RECOMMENDED that protocol instantiations described for the LCT header. It is RECOMMENDED that protocol
using multiple building blocks include shared fields at most once in instantiations using multiple building blocks include shared fields
each packet. Thus, for example, if another building block is used with at most once in each packet. Thus, for example, if another building
LCT that includes the optional Expected Residual Time field, then the block is used with LCT that includes the optional Expected Residual
Expected Residual Time field SHOULD be carried in each packet at most Time field, then the Expected Residual Time field SHOULD be carried
once. in each packet at most once.
The position of the LCT header within a packet MUST be specified by any The position of the LCT header within a packet MUST be specified by
protocol instantiation that uses LCT. any protocol instantiation that uses LCT.
5.1. Default LCT header format 5.1 Default LCT header format
The default LCT header is of variable size, which is specified by a The default LCT header is of variable size, which is specified by a
length field in the third byte of the header. In the LCT header, all 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
receivers. Unless otherwise noted, numeric constants in this by receivers. Unless otherwise noted, numeric constants in this
specification are in decimal (base 10). specification are in decimal (base 10).
The format of the default LCT header is depicted in Figure 1. The format of the default LCT header 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 | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)| | V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) | | Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) | | Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) | | Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) | | Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) | | Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) | | Header Extensions (if applicable) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Default LCT header format Figure 1 - Default LCT header format
The function and length of each field in the default LCT header is the The function and length of each field in the default LCT header is
following. Fields marked as "1" mean that the corresponding bits MUST the following. Fields marked as "1" mean that the corresponding bits
be set to "1" by the sender. Fields marked as "r" or "0" mean that the MUST be set to "1" by the sender. Fields marked as "r" or "0" mean
corresponding bits MUST be set to "0" by the sender. that the corresponding bits MUST be set to "0" by the sender.
LCT version number (V): 4 bits LCT version number (V): 4 bits
Indicates the LCT version number. The LCT version number for this Indicates the LCT version number. The LCT version number for
specification is 1. this specification is 1.
Congestion control flag (C): 2 bits Congestion control flag (C): 2 bits
C=0 indicates the Congestion Control Information (CCI) field is C=0 indicates the Congestion Control Information (CCI) field is
32-bits in length. 32-bits in length. C=1 indicates the CCI field is 64-bits in
C=1 indicates the CCI field is 64-bits in length. length. C=2 indicates the CCI field is 96-bits in length. C=3
C=2 indicates the CCI field is 96-bits in length. indicates the CCI field is 128-bits in length.
C=3 indicates the CCI field is 128-bits in length.
Reserved (r): 2 bits Reserved (r): 2 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
a receiver MUST ignore these bits. and a receiver MUST ignore these bits.
Transport Session Identifier flag (S): 1 bit Transport Session Identifier flag (S): 1 bit
This is the number of full 32-bit words in the TSI field. The TSI This is the number of full 32-bit words in the TSI field. The
field is 32*S + 16*H bits in length, i.e. the length is either 0 TSI field is 32*S + 16*H bits in length, i.e. the length is
bits, 16 bits, 32 bits, or 48 bits. either 0 bits, 16 bits, 32 bits, or 48 bits.
Transport Object Identifier flag (O): 2 bits Transport Object Identifier flag (O): 2 bits
This is the number of full 32-bit words in the TOI field. The TOI This is the number of full 32-bit words in the TOI field. The
field is 32*O + 16*H bits in length, i.e., the length is either 0 TOI field is 32*O + 16*H bits in length, i.e., the length is
bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96
bits. bits, or 112 bits.
Half-word flag (H): 1 bit Half-word flag (H): 1 bit
The TSI and the TOI fields are both multiples of 32-bits plus 16*H The TSI and the TOI fields are both multiples of 32-bits plus
bits in length. This allows the TSI and TOI field lengths to be 16*H bits in length. This allows the TSI and TOI field lengths
multiples of a half-word (16 bits), while ensuring that the to be multiples of a half-word (16 bits), while ensuring that
aggregate length of the TSI and TOI fields is a multiple of the aggregate length of the TSI and TOI fields is a multiple of
32-bits. 32-bits.
Sender Current Time present flag (T): 1 bit Sender Current Time present flag (T): 1 bit
T = 0 indicates that the Sender Current Time (SCT) field is not T = 0 indicates that the Sender Current Time (SCT) field is not
present. present. T = 1 indicates that the SCT field is present. The
T = 1 indicates that the SCT field is present. 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 (R): 1 bit Expected Residual Time present flag (R): 1 bit
R = 0 indicates that the Expected Residual Time (ERT) field is not R = 0 indicates that the Expected Residual Time (ERT) field is
present. not present. R = 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
The ERT is inserted by senders to indicate to receivers how much much longer the session / object transmission will continue.
longer the session / object transmission will continue.
Senders MUST NOT set R = 1 when the ERT for the session is more
than 2^32-1 time units (approximately 49 days), where time is
measured in units of milliseconds.
Close Session flag (A): 1 bit Senders MUST NOT set R = 1 when the ERT for the session is more
than 2^32-1 time units (approximately 49 days), where time is
measured in units of milliseconds.
Normally, A is set to 0. The sender MAY set A to 1 when Close Session flag (A): 1 bit
termination of transmission of packets for the session is
imminent. A MAY be set to 1 in just the last packet transmitted
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 Object flag (B): 1 bit Normally, A is set to 0. The sender MAY set A to 1 when
termination of transmission of packets for the session is
imminent. A MAY be set to 1 in just the last packet
transmitted 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.
Normally, B is set to 0. The sender MAY set B to 1 when Close Object flag (B): 1 bit
termination of transmission of packets for an object is imminent.
If the TOI field is in use and B is set to 1 then termination of
transmission for the object identified by the TOI field is
imminent. If the TOI field is not in use and B is set to 1 then
termination of transmission for the one object in the session
identified by out-of-band information is imminent. B MAY be set
to 1 in just the last packet transmitted for the object, or B MAY
be set to 1 in the last few seconds packets transmitted for the
object. Once the sender sets B to 1 in one packet for a
particular object, the sender SHOULD set B to 1 in all subsequent
packets for the object until termination of transmission of
packets for the object. A received packet with B set to 1
indicates to a receiver that the sender will immediately stop
sending packets for the object. When a receiver receives a packet
with B set to 1 then it SHOULD assume that no more packets will be
sent for the object to the session.
LCT header length (HDR_LEN): 8 bits Normally, B is set to 0. The sender MAY set B to 1 when
termination of transmission of packets for an object is
imminent. If the TOI field is in use and B is set to 1 then
termination of transmission for the object identified by the
TOI field is imminent. If the TOI field is not in use and B is
set to 1 then termination of transmission for the one object in
the session identified by out-of-band information is imminent.
B MAY be set to 1 in just the last packet transmitted for the
object, or B MAY be set to 1 in the last few seconds packets
transmitted for the object. Once the sender sets B to 1 in one
packet for a particular object, the sender SHOULD set B to 1 in
all subsequent packets for the object until termination of
transmission of packets for the object. A received packet with
B set to 1 indicates to a receiver that the sender will
immediately stop sending packets for the object. When a
receiver receives a packet with B set to 1 then it SHOULD
assume that no more packets will be sent for the object to the
session.
Total length of the LCT header in units of 32-bit words. The LCT header length (HDR_LEN): 8 bits
length of the LCT header MUST be a multiple of 32-bits. This
field can be used to directly access the portion of the packet
beyond the LCT header, i.e., to the first other header if it
exists, or to the packet payload if it exists and there is no
other header, or to the end of the packet if there are no other
headers or packet payload.
Codepoint (CP): 8 bits Total length of the LCT header in units of 32-bit words. The
length of the LCT header MUST be a multiple of 32-bits. This
field can be used to directly access the portion of the packet
beyond the LCT header, i.e., to the first other header if it
exists, or to the packet payload if it exists and there is no
other header, or to the end of the packet if there are no other
headers or packet payload.
An opaque identifier which is passed to the packet payload decoder Codepoint (CP): 8 bits
to convey information on the codec being used for the packet
payload. The mapping between the codepoint and the actual codec is
defined on a per session basis and communicated out-of-band as
part of the session description information. The use of the CP
field is similar to the Payload Type (PT) field in RTP headers as
described in RFC1889 [24].
Congestion Control Information (CCI): 32, 64, 96 or 128 bits An opaque identifier which is passed to the packet payload
decoder to convey information on the codec being used for the
packet payload. The mapping between the codepoint and the
actual codec is defined on a per session basis and communicated
out-of-band as part of the session description information.
The use of the CP field is similar to the Payload Type (PT)
field in RTP headers as described in RFC 1889 [21].
Used to carry congestion control information. For example, the Congestion Control Information (CCI): 32, 64, 96 or 128 bits
congestion control information could include layer numbers,
logical channel numbers, and sequence numbers. This field is
opaque for the purpose of this specification.
This field MUST be 32 bits if C=0.
This field MUST be 64 bits if C=1.
This field MUST be 96 bits if C=2.
This field MUST be 128 bits if C=3.
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits Used to carry congestion control information. For example, the
congestion control information could include layer numbers,
logical channel numbers, and sequence numbers. This field is
opaque for the purpose of this specification.
The TSI uniquely identifies a session among all sessions from a This field MUST be 32 bits if C=0.
particular sender. The TSI is scoped by the IP address of the This field MUST be 64 bits if C=1.
sender, and thus the IP address of the sender and the TSI together This field MUST be 96 bits if C=2.
uniquely identify the session. Although a TSI in conjunction with This field MUST be 128 bits if C=3.
the IP address of the sender always uniquely identifies a session,
whether or not the TSI is included in the LCT header depends on
what is used as the TSI value. If the underlying transport is
UDP, then the 16 bit UDP source port number MAY serve as the TSI
for the session. If the TSI value appears multiple times in a
packet then all occurrences MUST be the same value. If there is
no underlying TSI provided by the network, transport or any other
layer, then the TSI MUST be included in the LCT header.
The TSI MUST be unique among all sessions served by the sender Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
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 is outside the scope of
this document and is to be done out-of-band.
The length of the TSI field is 32*S + 16*H bits. Note that the
aggregate lengths of the TSI field plus the TOI field is a
multiple of 32 bits.
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 The TSI uniquely identifies a session among all sessions from a
bits. particular sender. The TSI is scoped by the IP address of the
sender, and thus the IP address of the sender and the TSI
together uniquely identify the session. Although a TSI in
conjunction with the IP address of the sender always uniquely
identifies a session, whether or not the TSI is included in the
LCT header depends on what is used as the TSI value. If the
underlying transport is UDP, then the 16 bit UDP source port
number MAY serve as the TSI for the session. 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.
This field indicates which object within the session this packet The TSI MUST be unique among all sessions served by the sender
pertains to. For example, a sender might send a number of files during the period when the session is active, and for a large
in the same session, using TOI=0 for the first file, TOI=1 for the period of time preceding and following when the session is
second one, etc. As another example, the TOI may be a unique active. A primary purpose of the TSI is to prevent receivers
global identifier of the object that is being transmitted from from inadvertently accepting packets from a sender that belong
several senders concurrently, and the TOI value may be the ouptut to sessions other than the sessions receivers are subscribed
of a hash function applied to the object. The mapping of TOI field to. For example, suppose a session is deactivated and then
values to objects is outside the scope of this document and is to another session is activated by a sender and the two sessions
be done out-of-band. The TOI field MUST be used in all packets if use an overlapping set of channels. A receiver that connects
more than one object is to be transmitted in a session, i.e. the and remains connected to the first session during this sender
TOI field is either present in all the packets of a session or is activity could possibly accept packets from the second session
never present. as belonging to the first session if the TSI for the two
The length of the TOI field is 32*O + 16*H bits. Note that the sessions were identical. The mapping of TSI field values to
aggregate lengths of the TSI field plus the TOI field is a sessions is outside the scope of this document and is to be
multiple of 32 bits. done out-of-band.
Sender Current Time (SCT): 0 or 32 bits 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 represents the current clock at the sender at the time Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112
this packet was transmitted, measured in units of 1ms and computed bits.
modulo 2^32 units from the start of the session.
This field MUST NOT be present if T=0 and MUST be present if T=1.
Expected Residual Time (ERT): 0 or 32 bits This field indicates which object within the session this
packet pertains to. For example, a sender might send a number
of files in the same session, using TOI=0 for the first file,
TOI=1 for the second one, etc. As another example, the TOI may
be a unique global identifier of the object that is being
transmitted from several senders concurrently, and the TOI
value may be the output of a hash function applied to the
object. The mapping of TOI field values to objects is outside
the scope of this document and is to 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.
This field represents the sender expected residual transmission The length of the TOI field is 32*O + 16*H bits. Note that the
time for the current session or for the transmission of the aggregate lengths of the TSI field plus the TOI field is a
current object, measured in units of 1ms. If the packet containing multiple of 32 bits.
the ERT field also contains the TOI field, then ERT refers to the
object corresponding to the TOI field, otherwise it refers to the
session.
This field MUST NOT be present if R=0 and MUST be present if R=1.
5.2. Header-Extension Fields Sender Current Time (SCT): 0 or 32 bits
Header Extensions are used in LCT to accommodate optional header fields This field represents the current clock at the sender and at
that are not always used or have variable size. Examples of the use of the time this packet was transmitted, measured in units of 1ms
Header Extensions include: and computed modulo 2^32 units from the start of the session.
o Extended-size versions of already existing header fields. This field MUST NOT be present if T=0 and MUST be present if
T=1.
o Sender and Receiver authentication information. Expected Residual Time (ERT): 0 or 32 bits
The presence of Header Extensions can be inferred by the LCT header This field represents the sender expected residual transmission
length (HDR_LEN): if HDR_LEN is larger than the length of the standard time for the current session or for the transmission of the
header then the remaining header space is taken by Header Extension current object, measured in units of 1ms. If the packet
fields. containing the ERT field also contains the TOI field, then ERT
refers to the object corresponding to the TOI field, otherwise
it refers to the session.
If present, Header Extensions MUST be processed to ensure that they are This field MUST NOT be present if R=0 and MUST be present if
recognized before performing any congestion control procedure or R=1.
otherwise accepting a packet. The default action for unrecognized header
extensions is to ignore them. This allows the future introduction of
backward-compatible enhancements to LCT without changing the LCT version
number. Non backward-compatible header extensions CANNOT be introduced
without changing the LCT version number.
Protocol instantiation MAY override this default behavior for PI- 5.2 Header-Extension Fields
specific extensions (see below).
There are two formats for Header Extension fields, as depicted below. Header Extensions are used in LCT to accommodate optional header
The first format is used for variable-length extensions, with Header fields that are not always used or have variable size. Examples of
Extension Type (HET) values between 0 and 127. The second format is used the use of Header Extensions include:
for fixed length (one 32-bit word) extensions, using HET values from 127
to 255.
0 1 2 3 o Extended-size versions of already existing header fields.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 o Sender and Receiver authentication information.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Format of additional headers The 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.
The explanation of each sub-field is the following. If present, Header Extensions MUST be processed to ensure that they
are recognized before performing any congestion control procedure or
otherwise accepting a packet. The default action for unrecognized
header extensions is to ignore them. This allows the future
introduction of backward-compatible enhancements to LCT without
changing the LCT version number. Non backward-compatible header
extensions CANNOT be introduced without changing the LCT version
number.
Header Extension Type (HET): 8 bits Protocol instantiation MAY override this default behavior for PI-
specific extensions (see below).
The type of the Header Extension. This document defines a number There are two formats for Header Extension fields, as depicted below.
of possible types. Additional types may be defined in future The first format is used for variable-length extensions, with Header
versions of this specification. HET values from 0 to 127 are used Extension Type (HET) values between 0 and 127. The second format is
for variable-length Header Extensions. HET values from 128 to 255 used for fixed length (one 32-bit word) extensions, using HET values
are used for fixed-length 32-bit Header Extensions. from 127 to 255.
Header Extension Length (HEL): 8 bits 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the whole Header Extension field, expressed in 0 1 2 3
multiples of 32-bit words. This field MUST be present for 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
variable-length extensions (HET between 0 and 127) and MUST NOT be +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
present for fixed-length extensions (HET between 128 and 255). | HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Content (HEC): variable length Figure 2 - Format of additional headers
The content of the Header Extension. The format of this sub-field The explanation of each sub-field is the following:
depends on the Header Extension type. For fixed-length Header
Extensions, the HEC is 24 bits. For variable-length Header
Extensions, the HEC field has variable size, as specified by the
HEL field. Note that the length of each Header Extension field
MUST be a multiple of 32 bits. Also note that the total size of
the LCT header, including all Header Extensions and all optional
header fields, cannot exceed 255 32-bit words.
Header Extensions are further divided between general LCT extensions and Header Extension Type (HET): 8 bits
Protocol Instantiation specific extensions (PI-specific). General LCT
extensions have HET in the ranges 0:63 and 128:191 inclusive. PI-
specific extensions have HET in the ranges 64:127 and 192:255 inclusive.
General LCT extensions are intended to allow the introduction of The type of the Header Extension. This document defines a
backward-compatible enhancements to LCT without changing the LCT version number of possible types. Additional types may be defined in
number. Non backward-compatible header extensions CANNOT be introduced future versions of this specification. HET values from 0 to
without changing the LCT version number. 127 are used for variable-length Header Extensions. HET values
from 128 to 255 are used for fixed-length 32-bit Header
Extensions.
PI-specific extensions are reserved for PI-specific use with semantic Header Extension Length (HEL): 8 bits
and default parsing actions defined by the PI.
The following general LCT Header Extension types are defined: The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 127) and MUST NOT
be present for fixed-length extensions (HET between 128 and
255).
EXT_NOP=0 No-Operation extension. Header Extension Content (HEC): variable length
The information present in this extension field MUST be
ignored by receivers.
EXT_AUTH=1 Packet authentication extension The content of the Header Extension. The format of this sub-
Information used to authenticate the sender of the packet. field depends on the Header Extension type. For fixed-length
The format of this Header Extension and its processing is Header Extensions, the HEC is 24 bits. For variable-length
outside the scope of this document and is to be Header Extensions, the HEC field has variable size, as
communicated out-of-band as part of the session specified by the HEL field. Note that the length of each
description. Header Extension field MUST be a multiple of 32 bits. Also
It is RECOMMENDED that senders provide some form of packet note that the total size of the LCT header, including all
authentication. If EXT_AUTH is present, whatever packet Header Extensions and all optional header fields, cannot exceed
authentication checks that can be performed immediately 255 32-bit words.
upon reception of the packet SHOULD be performed before
accepting the packet and performing any congestion
control-related action on it.
Some packet authentication schemes impose a delay of
several seconds between when a packet is received and when
the packet is fully authenticated. Any congestion control
related action that is appropriate MUST NOT be postponed
by any such full packet authentication.
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extensions are further divided between general LCT extensions
Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to and Protocol Instantiation specific extensions (PI-specific).
parse its content. General LCT extensions have HET in the ranges 0:63 and 128:191
inclusive. PI-specific extensions have HET in the ranges 64:127 and
192:255 inclusive.
6. Operations General LCT extensions are intended to allow the introduction of
backward-compatible enhancements to LCT without changing the LCT
version number. Non backward-compatible header extensions CANNOT be
introduced without changing the LCT version number.
6.1. Sender Operation PI-specific extensions are reserved for PI-specific use with semantic
and default parsing actions defined by the PI.
Before joining an LCT session a receiver MUST obtain a session The following general LCT Header Extension types are defined:
description. The session description MUST include:
o The sender IP address; EXT_NOP=0 No-Operation extension.
The information present in this extension field MUST be
ignored by receivers.
o The number of LCT channels; EXT_AUTH=1 Packet authentication extension
Information used to authenticate the sender of the
packet. The format of this Header Extension and its
processing is outside the scope of this document and is
to be communicated out-of-band as part of the session
description.
o The addresses and port numbers used for each LCT channel; It is RECOMMENDED that senders provide some form of
packet authentication. If EXT_AUTH is present,
whatever packet authentication checks that can be
performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and
performing any congestion control-related action on it.
o The Transport Session ID (TSI) to be used for the session; Some packet authentication schemes impose a delay of
several seconds between when a packet is received and
when the packet is fully authenticated. Any congestion
control related action that is appropriate MUST NOT be
postponed by any such full packet authentication.
o Enough information to determine the congestion control protocol All senders and receivers implementing LCT MUST support the EXT_NOP
being used; Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to
parse its content.
o Enough information to determine the packet authentication scheme 6. Operations
being used if it is being used.
The session description could also include, but is not limited to: 6.1 Sender Operation
o The data rates used for each LCT channel; Before joining an LCT session a receiver MUST obtain a session
description. The session description MUST include:
o The length of the packet payload; o The sender IP address;
o The mapping of TOI value(s) to objects for the session; o The number of LCT channels;
o Any information that is relevant to each object being transported, o The addresses and port numbers used for each LCT channel;
such as when it will be available within the session, for how long,
and the length of the object;
Protocol instantiations using LCT MAY place additional requirements on o The Transport Session ID (TSI) to be used for the session;
what must be included in the session description. For example, a
protocol instantiation might require that the data rates for each
channel, or the mapping of TOI value(s) to objects for the session, or
other information related to other headers that might be required to be
included in the session description.
The session description could be in a form such as SDP as defined in o Enough information to determine the congestion control protocol
RFC2327 [8], or XML metadata as defined in RFC3023 [17], or HTTP/Mime being used;
headers as defined in RFC2068 [6], etc. It might be carried in a
session announcement protocol such as SAP as defined in RFC2974 [9],
obtained using a proprietary session control protocol, located on a Web
page with scheduling information, or conveyed via E-mail or other out-
of-band methods. Discussion of session description format, and
distribution of session descriptions is beyond the scope of this
document.
Within an LCT session a sender using LCT transmits a sequence of packets o Enough information to determine the packet authentication scheme
each in the format defined above. Packets are sent from a sender using being used if it is being used.
one or more LCT channels which together constitute a session.
Transmission rates may be different in different channels and may vary
over time. The specification of the other building block headers and
the packet payload used by a complete protocol instantiation using LCT
is beyond the scope of this document. This document does not specify
the order in which packets are transmitted, nor the organization of a
session into multiple channels. Although these issues affect the
efficiency of the protocol, they do not affect the correctness nor the
inter-operability of LCT between senders and receivers.
Several objects can be carried within the same LCT session. In this The session description could also include, but is not limited to:
case, each object MUST be identified by a unique TOI. Objects MAY be
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 packets in a session until o The data rates used for each LCT channel;
the transmission is considered complete. The transmission may be
considered complete when some time has expired, a certain number of
packets have been sent, or some out-of-band signal (possibly from a
higher level protocol) has indicated completion by a sufficient number
of receivers.
For the reasons mentioned above, this document does not pose any o The length of the packet payload;
restriction on packet sizes. However, network efficiency considerations o The mapping of TOI value(s) to objects for the session;
recommend that the sender uses as large as possible packet payload size,
but in such a way that packets do not exceed the network's maximum
transmission unit size (MTU), or fragmentation coupled with packet loss
might introduce severe inefficiency in the transmission.
It is recommended that all packets have the same or very similar sizes, o Any information that is relevant to each object being
as this can have a severe impact on the effectiveness of congestion transported, such as when it will be available within the
control schemes such as the ones described in [25] and [3]. A sender of session, for how long, and the length of the object;
packets using LCT MUST implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357 [16] using
the Congestion Control Information field provided in the LCT header, and
the corresponding receiver congestion control scheme is to be
communicated out-of-band and MUST be implemented by any receivers
participating in the session.
6.2. Receiver Operation Protocol instantiations using LCT MAY place additional requirements
on what must be included in the session description. For example, a
protocol instantiation might require that the data rates for each
channel, or the mapping of TOI value(s) to objects for the session,
or other information related to other headers that might be required
to be included in the session description.
Receivers can operate differently depending on the delivery service The session description could be in a form such as SDP as defined in
model. For example, for an on demand service model receivers may join a RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or
session, obtain the necessary encoding symbols to reproduce the object, HTTP/Mime headers as defined in RFC 2068 [6], etc. It might be
and then leave the session. As another example, for a streaming service carried in a session announcement protocol such as SAP as defined in
model a receiver may be continuously joined to a set of LCT channels to RFC 2974 [9], obtained using a proprietary session control protocol,
download all objects in a session. located on a Web page with scheduling information, or conveyed via
E-mail or other out-of-band methods. Discussion of session
description format, and distribution of session descriptions is
beyond the scope of this document.
To be able to participate in a session, a receiver MUST obtain the Within an LCT session, a sender using LCT transmits a sequence of
relevant session description information as listed in Section 6.1. packets, each in the format defined above. Packets are sent from a
sender using one or more LCT channels which together constitute a
session. Transmission rates may be different in different channels
and may vary over time. The specification of the other building
block headers and the packet payload used by a complete protocol
instantiation using LCT is beyond the scope of this document. This
document does not specify the order in which packets are transmitted,
nor the organization of a session into multiple channels. Although
these issues affect the efficiency of the protocol, they do not
affect the correctness nor the inter-operability of LCT between
senders and receivers.
If packet authentication information is present in an LCT header, it Several objects can be carried within the same LCT session. In this
SHOULD be used as specified in Section 5.2. To be able to be a receiver case, each object MUST be identified by a unique TOI. Objects MAY be
in a session, the receiver MUST be able to process the LCT header. The transmitted sequentially, or they MAY be transmitted concurrently.
receiver MUST be able to discard, forward, store or process the other It is good practice to only send objects concurrently in the same
headers and the packet payload. If a receiver is not able to process a session if the receivers that participate in that portion of the
LCT header, it MUST drop from the session. 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.
To be able to participate in a session, a receiver MUST implement the Typically, the sender(s) continues to send packets in a session until
congestion control protocol specified in the session description using the transmission is considered complete. The transmission may be
the Congestion Control Information field provided in the LCT header. If considered complete when some time has expired, a certain number of
a receiver is not able to implement the congestion control protocol used packets have been sent, or some out-of-band signal (possibly from a
in the session, it MUST NOT join the session. When the session is higher level protocol) has indicated completion by a sufficient
transmitted on multiple LCT channels, receivers MUST initially join number of receivers.
channels according to the specified startup behavior of the congestion
control protocol. For a multiple rate congestion control protocol that
uses multiple channels, this typically means that a receiver will
initially join only a minimal set of LCT channels, possibly a single
one, that in aggregate are carrying packets at a low rate. This rule
has the purpose of preventing receivers from starting at high data
rates.
Several objects can be carried either sequentially or concurrently For the reasons mentioned above, this document does not pose any
within the same LCT session. In this case, each object is identified by restriction on packet sizes. However, network efficiency
a unique TOI. Note that even if a server stops sending packets for an considerations recommend that the sender uses an as large as possible
old object before starting to transmit packets for a new object, both packet payload size, but in such a way that packets do not exceed the
the network and the underlying protocol layers can cause some reordering network's maximum transmission unit size (MTU), or when fragmentation
of packets, especially when sent over different LCT channels, and thus coupled with packet loss might introduce severe inefficiency in the
receivers SHOULD NOT assume that the reception of a packet for a new transmission.
object means that there are no more packets in transit for the previous
one, at least for some amount of time.
A receiver MAY be concurrently joined to multiple LCT sessions from one It is recommended that all packets have the same or very similar
or more senders. The receiver MUST perform congestion control on each sizes, as this can have a severe impact on the effectiveness of
such LCT session. If the congestion control protocol allows the congestion control schemes such as the ones described in [22], [3],
receiver some flexibility in terms of its actions within a session then and [25]. A sender of packets using LCT MUST implement the sender-
the receiver MAY make choices to optimize the packet flow performance side part of one of the congestion control schemes that is in
across the multiple LCT sessions, as long as the receiver still adheres accordance with RFC 2357 [13] using the Congestion Control
to the congestion control rules for each LCT session individually. Information field provided in the LCT header, and the corresponding
receiver congestion control scheme is to be communicated out-of-band
and MUST be implemented by any receivers participating in the
session.
7. Requirements from Other Building Blocks 6.2 Receiver Operation
As described in RFC3048 [26], LCT is a building block that is intended Receivers can operate differently depending on the delivery service
to be used, in conjunction with other building blocks, to help specify a model. For example, for an on demand service model, receivers may
protocol instantiation. A congestion control building block that uses join a session, obtain the necessary packets to reproduce the object,
the Congestion Control information field within the LCT header MUST be and then leave the session. As another example, for a streaming
used by any protocol instantiation that uses LCT, and other building service model, a receiver may be continuously joined to a set of LCT
blocks MAY also be used, such as a reliability building block. channels to download all objects in a session.
The congestion control MUST be applied to the LCT session as an entity, To be able to participate in a session, a receiver MUST obtain the
i.e., over the aggregate of the traffic carried by all of the LCT relevant session description information as listed in Section 6.1.
channels associated with the LCT session. Some possible schemes are
specified in [25] and [3]. 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.
The particular layered encoder and congestion control protocols used If packet authentication information is present in an LCT header, it
with LCT have an impact on the performance and applicability of LCT. SHOULD be used as specified in Section 5.2. To be able to be a
For example, some layered encoders used for video and audio streams can receiver in a session, the receiver MUST be able to process the LCT
produce a very limited number of layers, thus providing a very coarse header. The receiver MUST be able to discard, forward, store or
control in the reception rate of packets by receivers in a session. process the other headers and the packet payload. If a receiver is
When LCT is used for reliable data transfer, some FEC codecs are not able to process a LCT header, it MUST drop from the session.
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.
A more in-depth description of the use of FEC in Reliable Multicast To be able to participate in a session, a receiver MUST implement the
Transport (RMT) protocols is given in [14]. Some of the FEC codecs that congestion control protocol specified in the session description
MAY be used in conjunction with LCT for reliable content delivery are using the Congestion Control Information field provided in the LCT
specified in [15]. The Codepoint field in the LCT header is an opaque header. If a receiver is not able to implement the congestion control
field that can be used to carry information related to the encoding of protocol used in the session, it MUST NOT join the session. When the
the packet payload. session is transmitted on multiple LCT channels, receivers MUST
initially join channels according to the specified startup behavior
of the congestion control protocol. For a multiple rate congestion
control protocol that uses multiple channels, this typically means
that a receiver will initially join only a minimal set of LCT
channels, possibly a single one, that in aggregate are carrying
packets at a low rate. This rule has the purpose of preventing
receivers from starting at high data rates.
LCT also requires receivers to obtain a session description, as Several objects can be carried either sequentially or concurrently
described in Section 6.1. The session description could be in a form within the same LCT session. In this case, each object is identified
such as SDP as defined in RFC2327 [8], or XML metadata as defined in by a unique TOI. Note that even if a server stops sending packets
RFC3023 [17], or HTTP/Mime headers as defined in RFC2068 [6], and for an old object before starting to transmit packets for a new
distributed with SAP as defined in RFC2974 [9], using HTTP, or in other object, both the network and the underlying protocol layers can cause
ways. It is RECOMMENDED that an authentication protocol such as IPSEC some reordering of packets, especially when sent over different LCT
[11] be used to deliver the session description to receivers to ensure channels, and thus receivers SHOULD NOT assume that the reception of
the correct session description arrives. a packet for a new object means that there are no more packets in
transit for the previous one, at least for some amount of time.
It is recommended that LCT implementors use some packet authentication A receiver MAY be concurrently joined to multiple LCT sessions from
scheme to protect the protocol from attacks. An example of a possibly one or more senders. The receiver MUST perform congestion control on
suitable scheme is described in [18]. each such LCT session. If the congestion control protocol allows the
receiver some flexibility in terms of its actions within a session
then the receiver MAY make choices to optimize the packet flow
performance across the multiple LCT sessions, as long as the receiver
still adheres to the congestion control rules for each LCT session
individually.
Some protocol instantiations that use LCT MAY use building blocks that 7. Requirements from Other Building Blocks
require the generation of feedback from the receivers to the sender.
However, the mechanism for doing this is outside the scope of LCT.
8. Security Considerations As described in RFC 3048 [23], 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.
LCT can be subject to denial-of-service attacks by attackers which try The congestion control MUST be applied to the LCT session as an
to confuse the congestion control mechanism, or send forged packets to entity, i.e., over the aggregate of the traffic carried by all of the
the session which would prevent successful reconstruction or cause LCT channels associated with the LCT session. Some possible schemes
inaccurate reconstruction of large portions of the object by receivers. are specified in [22], [3], and [25]. The Congestion Control
LCT is particularly affected by such an attack since many receivers may Information field in the LCT header is an opaque field that is
receive the same forged packet. It is therefore RECOMMENDED that an reserved to carry information related to congestion control. There
integrity check be made on received content before delivery to an MAY also be congestion control Header Extension fields that carry
application, e.g., by appending an MD5 hash [20] to the content before additional information related to congestion control.
it is sent and then computing the MD5 hash once the content is
reconstructed to ensure it is the same as the sent content. Moreover,
in order to obtain strong cryptographic integrity protection a digital
signature verifiable by the receiver SHOULD be computed on top of such a
hash value. It is also RECOMMENDED that protocol instantiations that
use LCT implement some form of packet authentication such as TESLA [18]
to protect against such attacks. Furthermore, it is RECOMMENDED that
Reverse Path Forwarding checks be enabled in all network routers and
switches along the path from the sender to receivers to limit the
possibility of a bad agent injecting forged packets into the multicast
tree data path.
Another vulnerability of LCT is the potential of receivers obtaining an The particular layered encoder and congestion control protocols used
incorrect session description for the session. The consequences of this with LCT have an impact on the performance and applicability of LCT.
could be that legitimate receivers with the wrong session description For example, some layered encoders used for video and audio streams
are unable to correctly receive the session content, or that receivers can produce a very limited number of layers, thus providing a very
inadvertently try to receive at a much higher rate than they are capable coarse control in the reception rate of packets by receivers in a
of, thereby disrupting traffic in portions of the network. To avoid session. When LCT is used for reliable data transfer, some FEC
these problems, it is RECOMMENDED that the receiver authenticate the codecs are inherently limited in the size of the object they can
session description, for example by using either the ESP (with enabled encode, and for objects larger than this size the reception overhead
authentication service) [13] or AH [12] protocols of IPSEC [11] to on the receivers can grow substantially.
ensure the authenticity of the session description.
A receiver with an incorrect or corrupted implementation of the A more in-depth description of the use of FEC in Reliable Multicast
congestion control building block may affect health of the network in Transport (RMT) protocols is given in [11]. Some of the FEC codecs
the path between the sender and the receiver, and may also affect the that MAY be used in conjunction with LCT for reliable content
reception rates of other receivers joined to the session. It is delivery are specified in [12]. The Codepoint field in the LCT
therefore RECOMMENDED that receivers identify themselves as legitimate header is an opaque field that can be used to carry information
before they receive the session description needed to join the session. related to the encoding of the packet payload.
9. IANA Considerations LCT also requires receivers to obtain a session description, as
described in Section 6.1. The session description could be in a form
such as SDP as defined in RFC 2327 [8], or XML metadata as defined in
RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], and
distributed with SAP as defined in RFC 2974 [9], using HTTP, or in
other ways. It is RECOMMENDED that an authentication protocol such
as IPSEC [11] be used to deliver the session description to receivers
to ensure the correct session description arrives.
No information in this specification is subject to IANA registration. It is recommended that LCT implementors use some packet
authentication scheme to protect the protocol from attacks. An
example of a possibly suitable scheme is described in [15].
Building blocks used in conjunction with LCT MAY introduce additional Some protocol instantiations that use LCT MAY use building blocks
IANA considerations. that require the generation of feedback from the receivers to the
sender. However, the mechanism for doing this is outside the scope
of LCT.
10. Intellectual Property Issues 8. Security Considerations
No specific reliability protocol or congestion control protocol is LCT can be subject to denial-of-service attacks by attackers which
specified or referenced as mandatory in this document. try to confuse the congestion control mechanism, or send forged
packets to the session which would prevent successful reconstruction
or cause inaccurate reconstruction of large portions of an object by
receivers. LCT is particularly affected by such an attack since many
receivers may receive the same forged packet. It is therefore
RECOMMENDED that an integrity check be made on received objects
before delivery to an application, e.g., by appending an MD5 hash
[17] to an object before it is sent and then computing the MD5 hash
once the object is reconstructed to ensure it is the same as the sent
object. Moreover, in order to obtain strong cryptographic integrity
protection a digital signature verifiable by the receiver SHOULD be
computed on top of such a hash value. It is also RECOMMENDED that
protocol instantiations that use LCT implement some form of packet
authentication such as TESLA [15] to protect against such attacks.
Finally, it is RECOMMENDED that Reverse Path Forwarding checks be
enabled in all network routers and switches along the path from the
sender to receivers to limit the possibility of a bad agent injecting
forged packets into the multicast tree data path.
LCT MAY be used with congestion control protocols and other protocols, Another vulnerability of LCT is the potential of receivers obtaining
such as reliability protocols, which are proprietary or have pending or an incorrect session description for the session. The consequences
granted patents. of this could be that legitimate receivers with the wrong session
description are unable to correctly receive the session content, or
that receivers inadvertently try to receive at a much higher rate
than they are capable of, thereby disrupting traffic in portions of
the network. To avoid these problems, it is RECOMMENDED that
measures be taken to prevent receivers from accepting incorrect
Session Descriptions, e.g., by using source authentication to ensure
that receivers only accept legitimate Session Descriptions from
authorized senders.
11. Acknowledgments A receiver with an incorrect or corrupted implementation of the
multiple rate congestion control building block may affect health of
the network in the path between the sender and the receiver, and may
also affect the reception rates of other receivers joined to the
session. It is therefore RECOMMENDED that receivers be required to
identify themselves as legitimate before they receive the Session
Description needed to join the session. How receivers identify
themselves as legitimate is outside the scope of this document.
Thanks to Vincent Roca and Roger Kermode for detailed comments and 9. IANA Considerations
contributions to this document. Thanks also to Bruce Lueckenhoff,
Hayder Radha and Justin Chapweske for detailed comments on this
document.
12. References No information in this specification is subject to IANA registration.
[1] Bradner, S., "The Internet Standards Process -- Revision 3", Building blocks used in conjunction with LCT MAY introduce additional
RFC2026, October 1996. IANA considerations.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 10. Acknowledgments
Levels", RFC2119, March 1997.
[3] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Thanks to Vincent Roca and Roger Kermode for detailed comments and
Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered contributions to this document. Thanks also to Bruce Lueckenhoff,
Multicast", Proceedings of Second International Workshop on Networked Hayder Radha and Justin Chapweske for detailed comments on this
Group Communications (NGC 2000), Palo Alto, CA, November 2000. document.
[4] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital 11. References
Fountain Approach to Reliable Distribution of Bulk Data", Proceedings
ACM SIGCOMM '98, Vancouver, Canada, September 1998.
[5] Deering, S., "Host Extensions for IP Multicasting", RFC1112, August [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
1989. 9, RFC 2026, October 1996.
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Berners-Lee, T., [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
"Hypertext Transfer Protocol -- HTTP/1.1", RFC2068, January 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Gemmell, J., Schooler, E., and Gray, J., "Fcast Multicast File [3] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000. Roetter, A. and W. Shaver, "FLID-DL: Congestion Control for
Layered Multicast", Proceedings of Second International Workshop
on Networked Group Communications (NGC 2000), Palo Alto, CA,
November 2000.
[8] Handley, M., Jacobson, V., "SDP: Session Description Protocol", [4] Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital
RFC2327, April 1998. Fountain Approach to Reliable Distribution of Bulk Data",
Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
[9] Handley, M., Perkins, C., Whelan, E., "Session Announcement [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
Protocol", RFC2974, October 2000. 1112, August 1989.
[10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D. [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Dissertation, Stanford University, Department of Computer Science, Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
Stanford, California, August 2001. 2616, January 1997.
[11] Kent, S., Atkinson, R., "Security Architecture for the Internet [7] Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File
Protocol", RFC2401, November 1998. Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January
2000.
[12] Kent, S., Atkinson, R., "IP Authentication Header", RFC2406, [8] Handley, M. and V. Jacobson, "SDP: Session Description
November 1998. Protocol", RFC 2327, April 1998.
[13] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
RFC2406, November 1998. Protocol", RFC 2974, October 2000.
[14] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M., [10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
Crowcroft, J., "The use of Forward Error Correction in Reliable Dissertation, Stanford University, Department of Computer
Multicast", Internet Draft draft-ietf-rmt-info-fec-02.txt, January 2002, Science, Stanford, California, August 2001.
a work in progress.
[15] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., [11] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
Crowcroft, J., "Forward Error Correction building block", Internet Draft J. Crowcroft, "The Use of Forward Error Correction (FEC) in
draft-ietf-rmt-bb-fec-06.txt, January 2002. Reliable Multicast", RFC 3453, December 2002.
[16] Mankin, A., Romanow, A., Bradner, S., Paxson V., "IETF Criteria for [12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
Evaluating Reliable Multicast Transport and Application Protocols", J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC2357, June 1998. RFC 3452, December 2002.
[17] Murata, M., St.Laurent, S., Kohn, D., "XML Media Types", RFC3023, [13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
January 2001. Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[18] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and [14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
Secure Source Authentication for Multicast", Network and Distributed 3023, January 2001.
System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[19] Postel, J., "User Datagram Protocol", RFC768, August 1980. [15] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and
Secure Source Authentication for Multicast", Network and
Distributed System Security Symposium, NDSS 2001, pp. 35-46,
February 2001.
[20] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April [16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1992. 1980.
[21] Rizzo, L., "Effective Erasure Codes for Reliable Computer [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
Communication Protocols", ACM SIGCOMM Computer Communication Review, 1992.
Vol.27, No.2, pp.24-36, Apr 1997.
[22] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion [18] Rizzo, L., "Effective Erasure Codes for Reliable Computer
control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August Communication Protocols", ACM SIGCOMM Computer Communication
2000. Review, Vol.27, No.2, pp.24-36, Apr 1997.
[23] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution [19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast
protocol based on software FEC techniques", Proceedings of the Fourth congestion control scheme", Proceedings of SIGCOMM 2000,
IEEES Workshop on the Architecture and Implementation of High Stockholm Sweden, August 2000.
Performance Communication Systems, HPCS'97, Chalkidiki Greece, June
1997.
[24] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A [20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution
Transport Protocol for Real-Time Applications", RFC1889, January 1996. protocol based on software FEC techniques", Proceedings of the
Fourth IEEES Workshop on the Architecture and Implementation of
High Performance Communication Systems, HPCS'97, Chalkidiki
Greece, June 1997.
[25] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion [21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
Control for Layered Multicast Data Transfer", IEEE Infocom '98, San "RTP: A Transport Protocol for Real-Time Applications", RFC
Francisco, CA, Mar.28-Apr.1 1998. 1889, January 1996.
[26] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., [22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion
Luby, M., "Reliable Multicast Transport Building Blocks for One-to-Many Control for Layered Multicast Data Transfer", IEEE Infocom'98,
Bulk-Data Transfer", RFC3048, January 2001. San Francisco, CA, Mar.28-Apr.1 1998.
13. Authors' Addresses [23] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.
and M. Luby, "Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[24] Kermode, R., Vicisano, L., "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC 3269, April 2002.
[25] Luby, M., Goyal V. K, Skaria S., Horn, G., "Wave and Equation
Based Rate Control using Multicast Round-trip Time", Proceedings
of ACM SIGCOMM 2002, Pittsburgh PA, August, 2002.
Authors' Addresses
Michael Luby Michael Luby
luby@digitalfountain.com
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Dr.
Suite 300 Suite 300
Fremont, CA, USA, 94538 Fremont, CA, USA, 94538
EMail: luby@digitalfountain.com
Jim Gemmell Jim Gemmell
jgemmell@microsoft.com
Microsoft Research Microsoft Research
301 Howard St., #830 455 Market St. #1690
San Francisco, CA, USA, 94105 San Francisco, CA, 94105
EMail: jgemmell@microsoft.com
Lorenzo Vicisano Lorenzo Vicisano
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
EMail: lorenzo@cisco.com
Luigi Rizzo Luigi Rizzo
luigi@iet.unipi.it
ACIRI/ICSI,
1947 Center St, Berkeley, CA, USA, 94704
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
EMail: luigi@iet.unipi.it
Mark Handley Mark Handley
mjh@aciri.org ICIR
ACIRI, 1947 Center St.
1947 Center St,
Berkeley, CA, USA, 94704 Berkeley, CA, USA, 94704
EMail: mjh@icir.org
Jon Crowcroft Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk Marconi Professor of Communications Systems
Department of Computer Science University of Cambridge
University College London Computer Laboratory
Gower Street, William Gates Building
London WC1E 6BT, UK J J Thomson Avenue
Cambridge CB3 0FD, UK
14. Full Copyright Statement EMail: Jon.Crowcroft@cl.cam.ac.uk
Copyright (C) The Internet Society (2001). All Rights Reserved. Full Copyright Statement
This document and translations of it may be copied and furnished to Copyright (C) The Internet Society (2002). All Rights Reserved.
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.
The limited permissions granted above are perpetual and will not be This document and translations of it may be copied and furnished to
revoked by the Internet Society or its successors or assigns. others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
This document and the information contained herein is provided on an "AS The limited permissions granted above are perpetual and will not be
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK revoked by the Internet Society or its successors or assigns.
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not This document and the information contained herein is provided on an
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
FITNESS FOR A PARTICULAR PURPOSE." TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 226 change blocks. 
1032 lines changed or deleted 1078 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/