draft-ietf-rmt-bb-lct-02.txt   draft-ietf-rmt-bb-lct-03.txt 
Internet Engineering Task Force RMT WG Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-lct-02.txt J.Gemmell/Microsoft draft-ietf-rmt-bb-lct-03.txt J.Gemmell/Microsoft
L.Vicisano/Cisco L.Vicisano/Cisco
L.Rizzo/ACIRI and Univ. Pisa L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI M.Handley/ACIRI
J. Crowcroft/UCL J. Crowcroft/UCL
18 October 2001 21 November 2001
Expires: April 2002 Expires: May 2002
Layered Coding Transport: Layered Coding Transport:
A massively scalable content delivery transport building block A massively scalable content delivery transport building block
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at page 2, line 4 skipping to change at page 2, line 4
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be This document is a product of the IETF RMT WG. Comments should be
addressed to the authors, or the WG's mailing list at rmt@lbl.gov. addressed to the authors, or the WG's mailing list at rmt@lbl.gov.
Abstract Abstract
This document describes Layered Coding Transport, a massively This document describes Layered Coding Transport, a massively
scalable reliable content delivery and stream delivery scalable reliable content delivery and stream delivery
^L
transport, hereafter referred to as LCT. LCT can be used for transport, hereafter referred to as LCT. LCT can be used for
multi-rate delivery to large sets of receivers. In LCT, multi-rate delivery to large sets of receivers. In LCT,
scalability and congestion control are supported through the scalability and congestion control are supported through the
use of layered coding techniques. Coding techniques can be use of layered coding techniques. Coding techniques can be
combined with LCT to provide support for reliability. combined with LCT to provide support for reliability.
Congestion control is receiver driven, and can be achieved by Congestion control is receiver driven, and can be achieved by
sending packets in the session to multiple ``LCT channels'', sending packets in the session to multiple ``LCT channels'',
and having receivers join and leave LCT channels (thus and having receivers join and leave LCT channels (thus
adjusting their reception rate) in reaction to network adjusting their reception rate) in reaction to network
conditions in a manner that is network friendly. conditions in a manner that is network friendly.
^L
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Related Documents. . . . . . . . . . . . . . . . . . 6 1.1. Related Documents. . . . . . . . . . . . . . . . . . 6
1.2. Environmental Requirements and Considerations. . . . 7 1.2. Environmental Requirements and Considerations. . . . 7
2. General Architecture. . . . . . . . . . . . . . . . . . 9 2. General Architecture. . . . . . . . . . . . . . . . . . 9
2.1. Delivery service models. . . . . . . . . . . . . . . 10 2.1. Delivery service models. . . . . . . . . . . . . . . 11
2.2. Congestion Control . . . . . . . . . . . . . . . . . 12 2.2. Congestion Control . . . . . . . . . . . . . . . . . 12
3. LCT header. . . . . . . . . . . . . . . . . . . . . . . 12 3. LCT header. . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Default LCT header format. . . . . . . . . . . . . . 12 3.1. Default LCT header format. . . . . . . . . . . . . . 13
3.2. Header-Extension Fields. . . . . . . . . . . . . . . 18 3.2. Header-Extension Fields. . . . . . . . . . . . . . . 18
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 21 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 21 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 21
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 23 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . 24
7. Intellectual Property Issues. . . . . . . . . . . . . . 24 7. Intellectual Property Issues. . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 25
9. References. . . . . . . . . . . . . . . . . . . . . . . 25 9. References. . . . . . . . . . . . . . . . . . . . . . . 25
10. Authors' Addresses . . . . . . . . . . . . . . . . . . 26 10. Authors' Addresses . . . . . . . . . . . . . . . . . . 26
11. Full Copyright Statement . . . . . . . . . . . . . . . 28 11. Full Copyright Statement . . . . . . . . . . . . . . . 28
^L
1. Introduction 1. Introduction
This document describes a massively scalable reliable content delivery This document describes a massively scalable reliable content delivery
and stream delivery transport, Layered Coding Transport (LCT), for and stream delivery transport, Layered Coding Transport (LCT), for
multi-rate content delivery primarily designed to be used with the IP multi-rate content delivery primarily designed to be used with the IP
multicast network service, but may also be used with other basic multicast network service, but may also be used with other basic
underlying network or transport services such as unicast UDP. LCT underlying network or transport services such as unicast UDP. LCT
supports both reliable and unreliable delivery. supports both reliable and unreliable delivery.
LCT is a building block as defined in RFC3048. Protocol instantiations LCT is a building block as defined in RFC3048. Protocol instantiations
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Congestion control refers to the ability to adapt throughput to the Congestion control refers to the ability to adapt throughput to the
available bandwidth on the path from the sender to a receiver, and to available bandwidth on the path from the sender to a receiver, and to
share bandwidth fairly with competing flows such as TCP. Thus, the total share bandwidth fairly with competing flows such as TCP. Thus, the total
flow of packets flowing to each receiver participating in an LCT session flow of packets flowing to each receiver participating in an LCT session
must not compete unfairly with existing flow adaptive protocols such as must not compete unfairly with existing flow adaptive protocols such as
TCP. TCP.
A multi-rate or a single-rate congestion control protcol can be used A multi-rate or a single-rate congestion control protcol can be used
with LCT. For multi-rate protocols, a session typically consists of with LCT. For multi-rate protocols, a session typically consists of
^L
more than one channel and the sender sends packets to the channels in more than one channel and the sender sends packets to the channels in
the session at rates that do not depend on the receivers. Each receiver the session at rates that do not depend on the receivers. Each receiver
adjusts its reception rate during its participation in the session by adjusts its reception rate during its participation in the session by
joining and leaving channels dynamically depending on the available joining and leaving channels dynamically depending on the available
bandwidth to the sender independent of all other receivers. Thus, for bandwidth to the sender independent of all other receivers. Thus, for
multi-rate protocols, the reception rate of each receiver may vary multi-rate protocols, the reception rate of each receiver may vary
dynamically independent of the other receivers. dynamically independent of the other receivers.
For single-rate protocols, a session typically consists of one channel For single-rate protocols, a session typically consists of one channel
and the sender sends packets to the channel at variable rates over time and the sender sends packets to the channel at variable rates over time
skipping to change at page 6, line 5 skipping to change at page 6, line 5
audio and video streams. For example, the information associated with a audio and video streams. For example, the information associated with a
TV broadcast could be partitioned into three layers, corresponding to TV broadcast could be partitioned into three layers, corresponding to
black and white, color, and HDTV quality. Receivers can experience black and white, color, and HDTV quality. Receivers can experience
different quality without the need for the sender to replicate different quality without the need for the sender to replicate
information in the different layers. information in the different layers.
The concept of layered coding can be naturally extended to reliable The concept of layered coding can be naturally extended to reliable
content delivery protocols when Forward Error Correction (FEC) content delivery protocols when Forward Error Correction (FEC)
techniques are used for coding the data stream [9] [7] [3] [11] [2]. By techniques are used for coding the data stream [9] [7] [3] [11] [2]. By
^L
using FEC, the data stream is transformed in such a way that using FEC, the data stream is transformed in such a way that
reconstruction of a data object does not depend on the reception of reconstruction of a data object does not depend on the reception of
specific data packets, but only on the number of different packets specific data packets, but only on the number of different packets
received. As a result, by increasing the number of layers a receiver is received. As a result, by increasing the number of layers a receiver is
receiving from, the receiver can reduce the transfer time accordingly. receiving from, the receiver can reduce the transfer time accordingly.
More details on the use of FEC for reliable content delivery can be More details on the use of FEC for reliable content delivery can be
found in [5]. Reliable protocols aim at giving guarantees on the found in [5]. Reliable protocols aim at giving guarantees on the
reliable delivery of data from the sender to the intended recipients. reliable delivery of data from the sender to the intended recipients.
Guarantees vary from simple packet data integrity to reliable delivery Guarantees vary from simple packet data integrity to reliable delivery
of a precise copy of an object to all intended recipients. Several of a precise copy of an object to all intended recipients. Several
skipping to change at page 7, line 5 skipping to change at page 7, line 5
As described in RFC3048, LCT is a building block that is intended to be As described in RFC3048, LCT is a building block that is intended to be
used, in conjunction with other building blocks, to help specify a used, in conjunction with other building blocks, to help specify a
protocol instantiation. A congestion control building block that uses protocol instantiation. A congestion control building block that uses
the Congestion Control information field within the LCT header must be the Congestion Control information field within the LCT header must be
used by any protocol instantiation that uses LCT, and other building used by any protocol instantiation that uses LCT, and other building
blocks may also be used, such as a reliability building block. blocks may also be used, such as a reliability building block.
A more in-depth description of the use of FEC in Reliable Multicast A more in-depth description of the use of FEC in Reliable Multicast
^L
Transport (RMT) protocols is given in [5]. Some of the FEC codecs that Transport (RMT) protocols is given in [5]. Some of the FEC codecs that
may be used in conjunction with LCT for reliable content delivery are may be used in conjunction with LCT for reliable content delivery are
specified in [6]. The Codepoint field in the LCT header is an opaque specified in [6]. The Codepoint field in the LCT header is an opaque
field that can be used to carry information related to the encoding of field that can be used to carry information related to the encoding of
the packet payload. the packet payload.
Implementors of protocol instantiations that use LCT must also implement Implementors of protocol instantiations that use LCT must also implement
congestion control in accordance to RFC2357, where the congestion congestion control in accordance to RFC2357, where the congestion
control is over the entire session. Some possible schemes are specified control is over the entire session. Some possible schemes are specified
in [11] and [1]. The Congestion Control Information field in the LCT in [11] and [1]. The Congestion Control Information field in the LCT
skipping to change at page 8, line 5 skipping to change at page 8, line 5
by their very nature may limit scalability. For example, if an by their very nature may limit scalability. For example, if an
application requires receivers to retrieve out of band information in application requires receivers to retrieve out of band information in
order to join a session, or an application allows receivers to send order to join a session, or an application allows receivers to send
requests back to the sender to report reception statistics, then the requests back to the sender to report reception statistics, then the
scalability of the application is limited by the ability to send, scalability of the application is limited by the ability to send,
receive, and process this additional data. receive, and process this additional data.
LCT requires receivers to be able to uniquely identify and demultiplex LCT requires receivers to be able to uniquely identify and demultiplex
packets associated with an LCT session. In particular, there must be a packets associated with an LCT session. In particular, there must be a
^L
Transport Session Identifier (TSI) associated with each LCT session. Transport Session Identifier (TSI) associated with each LCT session.
The TSI is scoped by the IP address of the sender, and the IP address of The TSI is scoped by the IP address of the sender, and the IP address of
the sender together with the TSI must uniquely identify the session. If the sender together with the TSI must uniquely identify the session. If
the underlying transport is UDP as described in RFC768, then the 16 bit the underlying transport is UDP as described in RFC768, then the 16 bit
UDP source port number may serve as the TSI for the session. If Generic UDP source port number may serve as the TSI for the session. If Generic
Router Assist (GRA) is being used then additional dependencies may be Router Assist (GRA) is being used then additional dependencies may be
introduced by GRA on the TSI field. GRA work is ongoing within the RMT introduced by GRA on the TSI field. GRA work is ongoing within the RMT
working group at this time. The TSI value must be the same in all working group at this time. The TSI value must be the same in all
places it occurs within a packet. If there is no underlying TSI places it occurs within a packet. If there is no underlying TSI
provided by the network, transport or any other layer, then the TSI must provided by the network, transport or any other layer, then the TSI must
skipping to change at page 9, line 5 skipping to change at page 9, line 5
such as SDP as defined in RFC2327, or XML metadata, or HTTP/Mime headers such as SDP as defined in RFC2327, or XML metadata, or HTTP/Mime headers
as defined in RFC2068, and distributed with SAP as defined in RFC2974, as defined in RFC2068, and distributed with SAP as defined in RFC2974,
using HTTP, or in other ways. using HTTP, or in other ways.
The particular layered encoder and congestion control protocols used The particular layered encoder and congestion control protocols used
with LCT have an impact on the performance and applicability of LCT. with LCT have an impact on the performance and applicability of LCT.
For example, some layered encoders used for video and audio streams can For example, some layered encoders used for video and audio streams can
produce a very limited number of layers, thus providing a very coarse produce a very limited number of layers, thus providing a very coarse
control in the reception rate of packets by receivers in a session. control in the reception rate of packets by receivers in a session.
^L
When LCT is used for reliable data transfer, some FEC codecs are When LCT is used for reliable data transfer, some FEC codecs are
inherently limited in the size of the object they can encode, and for inherently limited in the size of the object they can encode, and for
objects larger than this size the reception overhead on the receivers objects larger than this size the reception overhead on the receivers
can grow substantially. can grow substantially.
Some networks are not amenable to some congestion control protocols that Some networks are not amenable to some congestion control protocols that
could be used with LCT. In particular, for a satellite or wireless could be used with LCT. In particular, for a satellite or wireless
network, there may be no mechanism for receivers to effectively reduce network, there may be no mechanism for receivers to effectively reduce
their reception rate since there may be a fixed transmission rate their reception rate since there may be a fixed transmission rate
allocated to the session. allocated to the session.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
until it is time to receive the next object. In this case, the quality until it is time to receive the next object. In this case, the quality
metric is the time required to receive each object. 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 the
session, including all information relevant to congestion control. The session, including all information relevant to congestion control. The
session description is determined by the sender, and is typically session description is determined by the sender, and is typically
communicated to the receivers out of band. In some cases, as described communicated to the receivers out of band. In some cases, as described
^L
later, parts of the session description that are not required to later, parts of the session description that are not required to
initiate a session may be included in the LCT header or communicated to initiate a session may be included in the LCT header or communicated to
a receiver out of band after the receiver has joined the session. 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 packet
payload in order to provide reliability. A suitable decoder is used to payload in order to provide reliability. A suitable decoder is used to
reproduce the original information from the packet payload. There may reproduce the original information from the packet payload. There may
be a reliability header that follows the LCT header if such an encoder be a reliability header that follows the LCT header if such an encoder
and decoder is used. The reliability header helps to describe the and decoder is used. The reliability header helps to describe the
encoding data carried in the payload of the packet. The format of the encoding data carried in the payload of the packet. The format of the
skipping to change at page 10, line 38 skipping to change at page 10, line 40
controls may be suitable when LCT is used for a streaming application. controls may be suitable when LCT is used for a streaming application.
LCT can be used with other congestion control protocols such as the one LCT can be used with other congestion control protocols such as the one
described in [11], or Generic Router Assist schemes where the selection described in [11], or Generic Router Assist schemes where the selection
of which packets to forward is performed by routers. This latter of which packets to forward is performed by routers. This latter
approach potentially allows for finer grain congestion control and a approach potentially allows for finer grain congestion control and a
faster reaction to network congestion, but requires changes to the faster reaction to network congestion, but requires changes to the
router infrastructure. We do not discuss this approach further in this router infrastructure. We do not discuss this approach further in this
document. document.
This document does not specify and restrict the type of exchanges
between LCT (or any PI built on top of LCT) and an upper application.
Some upper APIs may use an object-oriented approach, where the only
possible unit of data exchanged between LCT (or any PI built on top of
LCT) and an application, either at a source or at a receiver, is an
object. Other APIs may enable a sending or receiving application to
exchange a subset of an object with LCT (or any PI built on top of LCT),
or may even follow a streaming model. These considerations are out of
the scope of this document."
2.1. Delivery service models 2.1. Delivery service models
LCT can support several different delivery service models. Two examples LCT can support several different delivery service models. Two examples
are briefly described here. are briefly described here.
^L
Push service model. Push service model.
One way a push service model can be used for reliable content delivery One way a push service model can be used for reliable content delivery
is to deliver a series of objects. For example, a receiver could join is to deliver a series of objects. For example, a receiver could join
the session and dynamically adapt the number of LCT channels the the session and dynamically adapt the number of LCT channels the
receiver is joined to until enough packets have been received to receiver is joined to until enough packets have been received to
reconstruct an object. After reconstructing the object the receiver may reconstruct an object. After reconstructing the object the receiver may
stay in the session and wait for the transmission of the next object. 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
skipping to change at page 11, line 41 skipping to change at page 12, line 4
packets to all LCT channels is 1,000 packets per second, so that a packets to all LCT channels is 1,000 packets per second, so that a
receiver could be able to complete reception of the object in as little receiver could be able to complete reception of the object in as little
50 seconds (assuming no loss and that the congestion control mechanism 50 seconds (assuming no loss and that the congestion control mechanism
immediately converges to the use of all LCT channels). immediately converges to the use of all LCT channels).
Other service models. Other service models.
There are many other delivery service models that LCT can be used for There are many other delivery service models that LCT can be used for
that are not covered above. As examples, a live streaming or an on- that are not covered above. As examples, a live streaming or an on-
demand archival content streaming service model. The description of the demand archival content streaming service model. The description of the
^L
many potential applications, the appropriate delivery service model, and many potential applications, the appropriate delivery service model, and
the additional mechanisms to support such functionalities when combined the additional mechanisms to support such functionalities when combined
with LCT is beyond the scope of this document. This document only with LCT is beyond the scope of this document. This document only
attempts to describe the minimal common scalable elements to these attempts to describe the minimal common scalable elements to these
diverse applications using LCT as the delivery transport. diverse applications using LCT as the delivery transport.
2.2. Congestion Control 2.2. Congestion Control
The specific congestion control protocol to be used for LCT sessions The specific congestion control protocol to be used for LCT sessions
depends on the type of content to be delivered. While the general depends on the type of content to be delivered. While the general
skipping to change at page 12, line 25 skipping to change at page 12, line 33
using LCT are described in [11] and [1]. Different delivery service using LCT are described in [11] and [1]. Different delivery service
models might require different congestion control protocols. models might require different congestion control protocols.
3. LCT header 3. LCT header
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 ensure
a uniform format across different protocol instantiations. Other LCT a uniform format across different protocol instantiations. Other LCT
header formats may be used by protocol instantiations, but if the header formats may be used by protocol instantiations, but if the
default LCT header format is not used by a protocol insantiation that default LCT header format is not used by a protocol instantiation that
uses LCT, then the protocol instantiation must specify the lengths and uses LCT, then the protocol instantiation must specify the lengths and
positions within the LCT header it uses of all fields described in the positions within the LCT header it uses of all fields described in the
default LCT header. 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 described
for the LCT header. It is recommended that protocol instantiations for the LCT header. It is recommended that protocol instantiations
using multiple building blocks include shared fields at most once in using multiple building blocks include shared fields at most once in
each packet. Thus, for example, if another building block is used with each packet. Thus, for example, if another building block is used with
LCT that includes the optional Expected Residual Time field, then the LCT that includes the optional Expected Residual Time field, then the
Expected Residual Time field should be carried in each packet at most Expected Residual Time field should be carried in each packet at most
once. 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 any
protocol instantiation that uses LCT. protocol instantiation that uses LCT.
^L
3.1. Default LCT header format 3.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 by
receivers. Unless otherwise noted, numeric constants in this receivers. Unless otherwise noted, numeric constants in this
specification are in decimal (base 10). specification are in decimal (base 10).
skipping to change at page 13, line 39 skipping to change at page 14, line 5
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 the
following. Fields marked as "1" mean that the corresponding bits must following. Fields marked as "1" mean that the corresponding bits must
be set to "1" by the sender. Fields marked as "r" or "0" mean that the be set to "1" by the sender. Fields marked as "r" or "0" mean that the
corresponding bits must be set to "0" by the sender. corresponding bits must be set to "0" by the sender.
LCT version number (V): 4 bits LCT version number (V): 4 bits
^L
Indicates the LCT version number. The LCT version number for this Indicates the LCT version number. The LCT version number for this
specification is 0. specification is 0.
Congestion control flag (C): 1 bit Congestion control flag (C): 1 bit
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 length. C=1 indicates the CCI field is 64-bits in length.
Reserved (r): 3 bits Reserved (r): 3 bits
skipping to change at page 14, line 39 skipping to change at page 15, line 5
bits. 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. T = 1 indicates that the SCT field is present.
The SCT is inserted by senders to indicate to receivers how long The SCT is inserted by senders to indicate to receivers how long
the session has been in progress. the session has been in progress.
^L
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 not
present. 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 much The ERT is inserted by senders to indicate to receivers how 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 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 than 2^32-1 time units (approximately 49 days), where time is
measured in units of milliseconds. measured in units of milliseconds.
skipping to change at page 15, line 41 skipping to change at page 16, line 5
be set to 1 in the last few seconds packets transmitted for the 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 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 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 until termination of transmission of
packets for the object. A received packet with B set to 1 packets for the object. A received packet with B set to 1
indicates to a receiver that the sender will immediately stop indicates to a receiver that the sender will immediately stop
sending packets for the object. When a receiver receives a packet 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 with B set to 1 then it should assume that no more packets will be
sent for the object to the session. sent for the object to the session.
^L
LCT header length (HDR_LEN): 8 bits LCT header length (HDR_LEN): 8 bits
Total length of the LCT header in units of 32-bit words. The 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 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 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 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 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 other header, or to the end of the packet if there are no other
headers or packet payload. headers or packet payload.
skipping to change at page 16, line 32 skipping to change at page 16, line 42
This field must be 32 bits if C=0. This field must be 32 bits if C=0.
This field must be 64 bits if C=1. This field must be 64 bits if C=1.
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
The TSI uniquely identifies a session among all sessions from a The TSI uniquely identifies a session among all sessions from a
particular sender. The TSI is scoped by the IP address of the 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 sender, and thus the IP address of the sender and the TSI together
uniquely identify the session. Although a TSI in conjunction with uniquely identify the session. Although a TSI in conjunction with
the IP address of the sender must always uniquely identify a the IP address of the sender must always uniquely identify a
session, whether or not the TSI is incuded in the LCT header session, whether or not the TSI is included in the LCT header
depends on what is used as the TSI value. If the underlying 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 transport is UDP, then the 16 bit UDP source port number may serve
as the TSI for the session. If Generic Router Assist (GRA) is as the TSI for the session. If Generic Router Assist (GRA) is
being used then additional dependencies may be introduced by GRA being used then additional dependencies may be introduced by GRA
on the TSI field. If the TSI value appears multiple times in a on the TSI field. If the TSI value appears multiple times in a
packet then all occurrences must be the same value. If there is packet then all occurrences must be the same value. If there is
no underlying TSI provided by the network, transport or any other no underlying TSI provided by the network, transport or any other
layer, then the TSI must be included in the LCT header. layer, then the TSI must be included in the LCT header.
^L
The TSI must be unique among all sessions served by the sender The TSI must be unique among all sessions served by the sender
during the period when the session is active, and for a large during the period when the session is active, and for a large
period of time preceding and following when the session is active. period of time preceding and following when the session is active.
A primary purpose of the TSI is to prevent receivers from A primary purpose of the TSI is to prevent receivers from
inadvertently accepting packets from a sender that belong to inadvertently accepting packets from a sender that belong to
sessions other than sessions receivers are subscribed to. For sessions other than sessions receivers are subscribed to. For
example, suppose a session is deactivated and then another session example, suppose a session is deactivated and then another session
is activated by a sender and the two sessions use an overlapping is activated by a sender and the two sessions use an overlapping
set of channels. A receiver that connects and remains connected set of channels. A receiver that connects and remains connected
to the first session during this sender activity could possibly to the first session during this sender activity could possibly
skipping to change at page 17, line 41 skipping to change at page 18, line 5
Sender Current Time (SCT): 0 or 32 bits Sender Current Time (SCT): 0 or 32 bits
This field represents the current clock at the sender at the time This field represents the current clock at the sender at the time
this packet was transmitted, measured in units of 1ms and computed this packet was transmitted, measured in units of 1ms and computed
modulo 2^32 units from the start of the session. modulo 2^32 units from the start of the session.
This field must not be present if T=0 and must be present if T=1. This field must not be present if T=0 and must be present if T=1.
Expected Residual Time (ERT): 0 or 32 bits Expected Residual Time (ERT): 0 or 32 bits
^L
This field represents the sender expected residual transmission This field represents the sender expected residual transmission
time for the current session or for the transmission of the time for the current session or for the transmission of the
current object, measured in units of 1ms. If the packet containing current object, measured in units of 1ms. If the packet containing
the ERT field also contains the TOI field, then ERT refers to the the ERT field also contains the TOI field, then ERT refers to the
object corresponding to the TOI field, otherwise it refers to the object corresponding to the TOI field, otherwise it refers to the
session. session.
This field must not be present if R=0 and must be present if R=1. This field must not be present if R=0 and must be present if R=1.
3.2. Header-Extension Fields 3.2. Header-Extension Fields
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Protocol instantiation may override this default behavior for PI- Protocol instantiation may override this default behavior for PI-
specific extensions (see below). specific extensions (see below).
There are two formats for Header Extension fields, as depicted below. There are two formats for Header Extension fields, as depicted below.
The first format is used for variable-length extensions, with Header The first format is used for variable-length extensions, with Header
Extension Type (HET) values between 0 and 127. The second format is used Extension Type (HET) values between 0 and 127. The second format is used
for fixed length (one 32-bit word) extensions, using HET values from 127 for fixed length (one 32-bit word) extensions, using HET values from 127
to 255. to 255.
^L
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | | | HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Header Extension Content (HEC) . . Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3
skipping to change at page 20, line 4 skipping to change at page 20, line 4
Header Extension Content (HEC): variable length Header Extension Content (HEC): variable length
The content of the Header Extension. The format of this sub-field The content of the Header Extension. The format of this sub-field
depends on the Header Extension type. For fixed-length Header depends on the Header Extension type. For fixed-length Header
Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC is 24 bits. For variable-length Header
Extensions, the HEC field has variable size, as specified by the Extensions, the HEC field has variable size, as specified by the
HEL field. Note that the length of each Header Extension field HEL field. Note that the length of each Header Extension field
must be a multiple of 32 bits. Also note that the total size of must be a multiple of 32 bits. Also note that the total size of
the LCT header, including all Header Extensions and all optional the LCT header, including all Header Extensions and all optional
^L
header fields, cannot exceed 255 32-bit words. header fields, cannot exceed 255 32-bit words.
Header Extensions are further divided between general LCT extensions and Header Extensions are further divided between general LCT extensions and
Protocol Instantiation specific extensions (PI-specific). General LCT Protocol Instantiation specific extensions (PI-specific). General LCT
extensions have HET in the ranges 0:63 and 128:191 inclusive. PI- 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. specific extensions have HET in the ranges 64:127 and 192:255 inclusive.
General LCT extensions are intended to allow the introduction of General LCT extensions are intended to allow the introduction of
backward-compatible enhancements to LCT without changing the LCT version backward-compatible enhancements to LCT without changing the LCT version
number. Non backward-compatible header extensions CANNOT be introduced number. Non backward-compatible header extensions CANNOT be introduced
skipping to change at page 20, line 25 skipping to change at page 20, line 27
PI-specific extensions are reserved for PI-specific use with semantic PI-specific extensions are reserved for PI-specific use with semantic
and default parsing actions defined by the PI. and default parsing actions defined by the PI.
The following general LCT Header Extension types are defined: The following general LCT Header Extension types are defined:
EXT_NOP=0 No-Operation extension. EXT_NOP=0 No-Operation extension.
The information present in this extension field must be The information present in this extension field must be
ignored by receivers. ignored by receivers.
EXT_AUTH=2 Packet authentication extension EXT_AUTH=1 Packet authentication extension
Information used to authenticate the sender of the packet. Information used to authenticate the sender of the packet.
If present, the format of this Header Extension and its If present, the format of this Header Extension and its
processing must be communicated out-of-band as part of the processing must be communicated out-of-band as part of the
session description. session description.
It is recommended that senders provide some form of packet It is recommended that senders provide some form of packet
authentication. If EXT_AUTH is present, whatever packet authentication. If EXT_AUTH is present, whatever packet
authentication checks that can be performed immediately authentication checks that can be performed immediately
upon reception of the packet must be performed before upon reception of the packet must be performed before
accepting the packet and performing any congestion accepting the packet and performing any congestion
control-related action on it. control-related action on it.
Some packet authentication schemes impose a delay of Some packet authentication schemes impose a delay of
several seconds between when a packet is received and when several seconds between when a packet is received and when
the packet is fully authenticated. Any congestion control the packet is fully authenticated. Any congestion control
related action that is appropriate must not be postponed related action that is appropriate must not be postponed
by any such full packet authentication. by any such full packet authentication.
All senders and receivers implementing LCT must support the EXT_NOP All senders and receivers implementing LCT must support the EXT_NOP
Header Extension and must recognize EXT_AUTH, but may not be able to Header Extension and must recognize EXT_AUTH, but may not be able to
parse its content. parse its content.
^L
4. Procedures 4. Procedures
4.1. Sender Operation 4.1. Sender Operation
A sender using LCT must make a session description available to clients A sender using LCT must make a session description available to clients
that want to join an LCT session. This information could include, but that want to join an LCT session. This information could include, but
is not limited to: is not limited to:
o The number of LCT channels; o The number of LCT channels;
skipping to change at page 22, line 5 skipping to change at page 22, line 5
Some of the session description information must be obtained by Some of the session description information must be obtained by
receivers before they connect to the session. This includes the number receivers before they connect to the session. This includes the number
and addresses of the LCT channels, the TSI value for the session, the and addresses of the LCT channels, the TSI value for the session, the
formats of any other headers, the congestion control scheme being used formats of any other headers, the congestion control scheme being used
and the packet authentication scheme if it is used. Some of the session and the packet authentication scheme if it is used. Some of the session
description information may be obtained by receivers while they are description information may be obtained by receivers while they are
connected to the session, e.g., information relevant to objects being connected to the session, e.g., information relevant to objects being
transported within the session such as their TOI, when they are transported within the session such as their TOI, when they are
available within the session, for how long, and their lengths. available within the session, for how long, and their lengths.
^L
The session description could be in a form such as SDP as defined in The session description could be in a form such as SDP as defined in
RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a
session announcement protocol such as SAP as defined in RFC2974, session announcement protocol such as SAP as defined in RFC2974,
obtained using a proprietary session control protocol, located on a Web obtained using a proprietary session control protocol, located on a Web
page with scheduling information, or conveyed via E-mail or other out of page with scheduling information, or conveyed via E-mail or other out of
band methods. Discussion of session description format, and band methods. Discussion of session description format, and
distribution of session descriptions is beyond the scope of this distribution of session descriptions is beyond the scope of this
document. document.
Within an LCT session, a sender using LCT transmits a sequence of Within an LCT session, a sender using LCT transmits a sequence of
skipping to change at page 23, line 5 skipping to change at page 23, line 5
restriction on packet sizes. However, network efficiency considerations restriction on packet sizes. However, network efficiency considerations
recommend that the sender uses as large as possible packet payload size, 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 but in such a way that packets do not exceed the network's maximum
transmission unit size (MTU), or fragmentation coupled with packet loss transmission unit size (MTU), or fragmentation coupled with packet loss
might introduce severe inefficiency in the transmission. might introduce severe inefficiency in the transmission.
It is recommended that all packets have the same or very similar sizes, It is recommended that all packets have the same or very similar sizes,
as this can have a severe impact on the effectiveness of congestion as this can have a severe impact on the effectiveness of congestion
control schemes such as the ones described in [11] and [1]. A sender of control schemes such as the ones described in [11] and [1]. A sender of
^L
packets using LCT must implement the sender-side part of one of the packets using LCT must implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357 using the congestion control schemes that is in accordance with RFC2357 using the
Congestion Control Information field provided in the LCT header, and the Congestion Control Information field provided in the LCT header, and the
corresponding receiver congestion control scheme must be communicated corresponding receiver congestion control scheme must be communicated
out of band and implemented by any receivers participating in the out of band and implemented by any receivers participating in the
session. session.
4.2. Receiver Operation 4.2. Receiver Operation
Receivers can operate differently depending on the delivery service Receivers can operate differently depending on the delivery service
skipping to change at page 24, line 5 skipping to change at page 24, line 5
Multiple objects can be carried either sequentially or concurrently Multiple objects can be carried either sequentially or concurrently
within the same LCT session. In this case, each object is identified by within the same LCT session. In this case, each object is identified by
a unique TOI. Note that even if a server stops sending packets for an a unique TOI. Note that even if a server stops sending packets for an
old object before starting to transmit packets for a new object, both old object before starting to transmit packets for a new object, both
the network and the underlying protocol layers can cause some reordering the network and the underlying protocol layers can cause some reordering
of packets, especially when sent over different LCT channels, and thus of packets, especially when sent over different LCT channels, and thus
receivers should not assume that the reception of a packet for a new receivers should not assume that the reception of a packet for a new
object means that there are no more packets in transit for the previous object means that there are no more packets in transit for the previous
^L
one, at least for some amount of time. one, at least for some amount of time.
A receiver may be concurrently joined to multiple LCT sessions from one A receiver may be concurrently joined to multiple LCT sessions from one
or more senders. The receiver must perform congestion control on each or more senders. The receiver must perform congestion control on each
such LCT session. If the congestion control protocol allows the such LCT session. If the congestion control protocol allows the
receiver some flexibility in terms of its actions within a session then receiver some flexibility in terms of its actions within a session then
the receiver may make choices to optimize the packet flow performance the receiver may make choices to optimize the packet flow performance
across the multiple LCT sessions, as long as the receiver still adheres across the multiple LCT sessions, as long as the receiver still adheres
to the congestion control rules for each LCT session individually. to the congestion control rules for each LCT session individually.
skipping to change at page 25, line 5 skipping to change at page 25, line 5
7. Intellectual Property Issues 7. Intellectual Property Issues
No specific reliability protocol or congestion control protocol is No specific reliability protocol or congestion control protocol is
specified or referenced as mandatory in this document. specified or referenced as mandatory in this document.
LCT may be used with congestion control protocols and other protocols, LCT may be used with congestion control protocols and other protocols,
such as reliability protocols, which are proprietary or have pending or such as reliability protocols, which are proprietary or have pending or
granted patents. granted patents.
^L
8. Acknowledgments 8. Acknowledgments
Thanks to Vincent Roca, Bruce Lueckenhoff, Hayder Radha and Justin Thanks to Vincent Roca for detailed comments and contributions to this
document. Thanks also to Bruce Lueckenhoff, Hayder Radha and Justin
Chapweske for detailed comments on this document. Chapweske for detailed comments on this document.
9. References 9. References
[1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., [1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered
Multicast", Proceedings of Second International Workshop on Networked Multicast", Proceedings of Second International Workshop on Networked
Group Communications (NGC 2000), Palo Alto, CA, November 2000. Group Communications (NGC 2000), Palo Alto, CA, November 2000.
[2] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital [2] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital
skipping to change at page 26, line 5 skipping to change at page 26, line 5
[8] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and [8] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and
Secure Source Authentication for Multicast", Network and Distributed Secure Source Authentication for Multicast", Network and Distributed
System Security Symposium, NDSS 2001, pp. 35-46, February 2001. System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[9] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution [9] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution
protocol based on software FEC techniques", Proceedings of the Fourth protocol based on software FEC techniques", Proceedings of the Fourth
IEEES Workshop on the Architecture and Implementation of High IEEES Workshop on the Architecture and Implementation of High
Performance Communication Systems, HPCS'97, Chalkidiki Greece, June Performance Communication Systems, HPCS'97, Chalkidiki Greece, June
1997. 1997.
^L
[10] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion [10] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion
control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August
2000. 2000.
[11] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion [11] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion
Control for Layered Multicast Data Transfer", IEEE Infocom '98, San Control for Layered Multicast Data Transfer", IEEE Infocom '98, San
Francisco, CA, Mar.28-Apr.1 1998. Francisco, CA, Mar.28-Apr.1 1998.
10. Authors' Addresses 10. Authors' Addresses
skipping to change at page 27, line 4 skipping to change at page 27, line 4
via Diotisalvi 2, 56126 Pisa, Italy via Diotisalvi 2, 56126 Pisa, Italy
Mark Handley Mark Handley
mjh@aciri.org mjh@aciri.org
ACIRI, ACIRI,
1947 Center St, 1947 Center St,
Berkeley, CA, USA, 94704 Berkeley, CA, USA, 94704
Jon Crowcroft Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk J.Crowcroft@cs.ucl.ac.uk
^L
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street, Gower Street,
London WC1E 6BT, UK London WC1E 6BT, UK
^L
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
skipping to change at line 1149 skipping to change at page 29, line 4
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE." FITNESS FOR A PARTICULAR PURPOSE."
^L
 End of changes. 

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