summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3451.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3451.txt')
-rw-r--r--doc/rfc/rfc3451.txt1627
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc3451.txt b/doc/rfc/rfc3451.txt
new file mode 100644
index 0000000..b1bd75e
--- /dev/null
+++ b/doc/rfc/rfc3451.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group M. Luby
+Request for Comments: 3451 Digital Fountain
+Category: Experimental J. Gemmell
+ Microsoft
+ L. Vicisano
+ Cisco
+ L. Rizzo
+ Univ. Pisa
+ M. Handley
+ ICIR
+ J. Crowcroft
+ Cambridge Univ.
+ December 2002
+
+
+ Layered Coding Transport (LCT) Building Block
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ Layered Coding Transport (LCT) provides transport level support for
+ reliable content delivery and stream delivery protocols. LCT is
+ specifically designed to support protocols using IP multicast, but
+ also provides support to protocols that use unicast. LCT is
+ compatible with congestion control that provides multiple rate
+ delivery to receivers and is also compatible with coding techniques
+ that provide reliable delivery of content.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 1]
+
+RFC 3451 LCT Building Block December 2002
+
+
+Table of Contents
+
+ 1. Introduction...................................................2
+ 2. Rationale......................................................3
+ 3. Functionality..................................................4
+ 4. Applicability..................................................7
+ 4.1 Environmental Requirements and Considerations...............8
+ 4.2 Delivery service models....................................10
+ 4.3 Congestion Control.........................................11
+ 5. Packet Header Fields..........................................12
+ 5.1 Default LCT header format..................................12
+ 5.2 Header-Extension Fields....................................17
+ 6. Operations....................................................20
+ 6.1 Sender Operation...........................................20
+ 6.2 Receiver Operation.........................................22
+ 7. Requirements from Other Building Blocks.......................23
+ 8. Security Considerations.......................................24
+ 9. IANA Considerations...........................................25
+ 10. Acknowledgments..............................................25
+ 11. References...................................................25
+ Authors' Addresses...............................................28
+ Full Copyright Statement.........................................29
+
+1. Introduction
+
+ Layered Coding Transport provides transport level support for
+ reliable content delivery and stream delivery protocols. Layered
+ Coding Transport is specifically designed to support protocols using
+ IP multicast, but also provides support to protocols that use
+ unicast. Layered Coding Transport is compatible with congestion
+ 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 RFC 3048 [26].
+ This document is a product of the IETF RMT WG and follows the
+ general guidelines provided in RFC 3269 [24].
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 2]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ 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
+
+ LCT provides transport level support for massively scalable protocols
+ using the IP multicast network service. The support that LCT
+ provides is common to a variety of very important applications,
+ including reliable content delivery and streaming applications.
+
+ An LCT session comprises multiple channels originating at a single
+ sender that are used for some period of time to carry packets
+ pertaining to the transmission of one or more objects that can be of
+ interest to receivers. The logic behind defining a session as
+ originating from a single sender is that this is the right
+ granularity to regulate packet traffic via congestion control. One
+ rationale for using multiple channels within the same session is that
+ there are massively scalable congestion control protocols that use
+ multiple channels per session. These congestion control protocols
+ are considered to be layered because a receiver joins and leaves
+ channels in a layered order during its participation in the session.
+ The use of layered channels is also useful for streaming
+ applications.
+
+ There are coding techniques that provide massively scalable
+ reliability and asynchronous delivery which are compatible with both
+ layered congestion control and with LCT. When all are combined the
+ result is a massively scalable reliable asynchronous content delivery
+ protocol that is network friendly. LCT also provides functionality
+ that can be used for other applications as well, e.g., layered
+ streaming applications.
+
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 3]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ LCT avoids providing functionality that is not massively scalable.
+ For example, LCT does not provide any mechanisms for sending
+ information from receivers to senders, although this does not rule
+ out protocols that both use LCT and do require sending information
+ from receivers to senders.
+
+ LCT includes general support for congestion control that must be
+ used. It does not, however, specify which congestion control should
+ be used. The rationale for this is that congestion control must be
+ provided by any protocol that is network friendly, and yet the
+ different applications that can use LCT will not have the same
+ requirements for congestion control. For example, a content delivery
+ protocol may strive to use all available bandwidth between receivers
+ and the sender. It must, therefore, drastically back off its rate
+ when there is competing traffic. On the other hand, a streaming
+ delivery protocol may strive to maintain a constant rate instead of
+ 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 and supports functionality commonly required by many
+ protocols. For example, LCT provides a Transmission Session ID that
+ can be used to identify which session each received packet belongs
+ to. This is important because a receiver may be joined to many
+ sessions concurrently, and thus it is very useful to be able to
+ demultiplex packets as they arrive according to which session they
+ belong to. As another example, LCT provides optional support for
+ identifying which object each packet is carrying information about.
+ Therefore, LCT provides many of the commonly used fields and support
+ for functionality required by many protocols.
+
+3. Functionality
+
+ An LCT session consists of a set of logically grouped LCT channels
+ associated with a single sender carrying packets with LCT headers for
+ one or more objects. An LCT channel is defined by the combination of
+ 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 channel by the sender, and a receiver leaves a channel to stop
+ 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
+
+
+
+Luby, et. al. Experimental [Page 4]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ 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 in-band session information to receivers. One of the
+ required fields is the Transmission Session ID (TSI), which allows
+ the receiver of a session to uniquely identify received packets as
+ part of the session. Another required field is the Congestion
+ Control Information (CCI), which allows the receiver to perform the
+ required congestion control on the packets received within the
+ 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.
+
+ LCT provides support for congestion control. Congestion control MUST
+ be used that conforms to RFC 2357 [13] between receivers and the
+ sender for each LCT session. Congestion control refers to the
+ ability to adapt throughput to the available bandwidth on the path
+ from the sender to a receiver, and to share bandwidth fairly with
+ competing flows such as TCP. Thus, the total flow of packets flowing
+ to each receiver participating in an LCT session MUST NOT compete
+ unfairly with existing flow adaptive protocols such as TCP.
+
+ A multiple rate or a single rate congestion control protocol can be
+ used with LCT. For multiple rate protocols, a session typically
+ consists of more than one channel and the sender sends packets to the
+ channels in the session at rates that do not depend on the receivers.
+ Each receiver adjusts its reception rate during its participation in
+ the session by joining and leaving channels dynamically depending on
+ the available bandwidth to the sender independent of all other
+ receivers. Thus, for multiple rate protocols, the reception rate of
+ each receiver may vary dynamically independent of the other
+ receivers.
+
+ For single rate protocols, a session typically consists of one
+ channel and the sender sends packets to the channel at variable rates
+ over time depending on feedback from receivers. Each receiver
+ remains joined to the channel during its participation in the
+ session. Thus, for single rate protocols, the reception rate of each
+ receiver may vary dynamically but in coordination with all receivers.
+
+
+
+Luby, et. al. Experimental [Page 5]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ Generally, a multiple rate protocol is preferable to a single rate
+ protocol in a heterogeneous receiver environment, since generally it
+ more easily achieves scalability to many receivers and provides
+ higher throughput to each individual receiver. Some possible
+ 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 refers to the ability to produce a coded stream of
+ packets that can be partitioned into an ordered set of layers. The
+ coding is meant to provide some form of reliability, and the layering
+ 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
+ audio and video streams. For example, the information associated
+ with a TV broadcast could be partitioned into three layers,
+ corresponding to black and white, color, and HDTV quality. Receivers
+ can experience different quality without the need for the sender to
+ replicate information in the different layers.
+
+ The concept of layered coding can be naturally extended to reliable
+ content delivery protocols when Forward Error Correction (FEC)
+ techniques are used for coding the data stream. Descriptions of this
+ can be found in [20], [18], [7], [22] and [4]. By using FEC, the
+ data stream is transformed in such a way that reconstruction of a
+ data object does not depend on the reception of specific data
+ packets, but only on the number of different packets received. As a
+ result, by increasing the number of layers a receiver is receiving
+ from, the receiver can reduce the transfer time accordingly. Using
+ FEC to provide reliability can increase scalability dramatically in
+ comparison to other methods for providing reliability. More details
+ on the use of FEC for reliable content delivery can be found in [11].
+
+ Reliable protocols aim at giving guarantees on the reliable delivery
+ of data from the sender to the intended recipients. Guarantees vary
+ from simple packet data integrity to reliable delivery of a precise
+ copy of an object to all intended recipients. Several reliable
+ content delivery protocols have been built on top of IP multicast
+ using methods other than FEC, but scalability was not the primary
+ design goal for many of them.
+
+ Two of the key difficulties in scaling reliable content delivery
+ using IP multicast are dealing with the amount of data that flows
+ from receivers back to the sender, and the associated response
+ (generally data retransmissions) from the sender. Protocols that
+
+
+
+Luby, et. al. Experimental [Page 6]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ avoid any such feedback, and minimize the amount of retransmissions,
+ can be massively scalable. LCT can be used in conjunction with FEC
+ codes or a layered codec to achieve reliability with little or no
+ feedback.
+
+ Protocol instantiations MAY be built by combining the LCT framework
+ with other components. A complete protocol instantiation that uses
+ LCT MUST include a congestion control protocol that is compatible
+ with LCT and that conforms to RFC 2357 [13]. A complete protocol
+ instantiation that uses LCT MAY include a scalable reliability
+ protocol that is compatible with LCT, it MAY include an session
+ control protocol that is compatible with LCT, and it MAY include
+ other protocols such as security protocols.
+
+4. Applicability
+
+ An LCT session comprises a logically related set of one or more LCT
+ channels originating at a single sender. The channels are used for
+ some period of time to carry packets containing LCT headers, and
+ these headers pertain to the transmission of one or more objects that
+ can be of interest to receivers.
+
+ LCT is most applicable for delivery of objects or streams in a
+ session of substantial length, i.e., objects or streams that range in
+ aggregate length from hundreds of kilobytes to many gigabytes, and
+ 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
+ using three LCT channels. Receiving packets from the first LCT
+ channel could allow black and white reception. Receiving the first
+ two LCT channels could also permit color reception. Receiving all
+ three channels could allow HDTV quality reception. Objects in this
+ example could correspond to individual TV programs being transmitted.
+
+ As another example, a reliable LCT session could be used to reliably
+ deliver hourly-updated weather maps (objects) using ten LCT channels
+ at different rates, using FEC coding. A receiver may join and
+ concurrently receive packets from subsets of these channels, until it
+ has enough packets in total to recover the object, then leave the
+ session (or remain connected listening for session description
+ information only) until it is time to receive the next object. In
+ this case, the quality metric is the time required to receive each
+ object.
+
+ Before joining a session, the receivers MUST obtain enough of the
+ session description to start the session. This MUST include the
+ relevant session parameters needed by a receiver to participate in
+
+
+
+Luby, et. al. Experimental [Page 7]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ the session, including all information relevant to congestion
+ control. The session description is determined by the sender, and is
+ typically communicated to the receivers out-of-band. In some cases,
+ as described later, parts of the session description that are not
+ required 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.
+
+ 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 reproduce the original information from the packet
+ payload. There MAY be a reliability header that follows the LCT
+ header if such an encoder and decoder is used. The reliability
+ header helps to describe the encoding data carried in the payload of
+ the packet. The format of the reliability header depends on the
+ coding used, and this is negotiated out-of-band. As an example, one
+ of the FEC headers described in [12] could be used.
+
+ For LCT, when multiple rate congestion control is used, congestion
+ control is achieved by sending packets associated with a given
+ session to several LCT channels. Individual receivers dynamically
+ join one or more of these channels, according to the network
+ congestion as seen by the receiver. LCT headers include an opaque
+ field which MUST be used to convey congestion control information to
+ the receivers. The actual congestion control scheme to use with LCT
+ is negotiated out-of-band. Some examples of congestion control
+ protocols that may be suitable for content delivery are described in
+ [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
+ 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
+ outside the scope of this document.
+
+4.1 Environmental Requirements and Considerations
+
+ LCT is intended for congestion controlled delivery of objects and
+ streams (both reliable content delivery and streaming of multimedia
+ information).
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 8]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ LCT can be used with both multicast and unicast delivery. LCT
+ requires connectivity between a sender and receivers but does not
+ require connectivity from receivers to a sender. LCT inherently
+ works with all types of networks, including LANs, WANs, Intranets,
+ the Internet, asymmetric networks, wireless networks, and satellite
+ networks. Thus, the inherent raw scalability of LCT is unlimited.
+ However, when other specific applications are built on top of LCT,
+ then these applications by their very nature may limit scalability.
+ For example, if an application requires receivers to retrieve out of
+ band information in order to join a session, or an application allows
+ receivers to send requests back to the sender to report reception
+ statistics, then the scalability of the application is limited by the
+ ability to send, receive, and process this additional data.
+
+ LCT requires receivers to be able to uniquely identify and
+ demultiplex packets associated with an LCT session. In particular,
+ there MUST be a 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 sender together with the TSI MUST uniquely
+ identify the session. If the underlying transport is UDP as
+ described in RFC 768 [16], then the 16 bit UDP source port number MAY
+ serve as the TSI for the session. The TSI value MUST be the same in
+ all places it occurs within a packet. If there is no underlying TSI
+ provided by the network, transport or any other layer, then the TSI
+ MUST be included in the LCT header.
+
+ LCT is presumed to be used with an underlying network or transport
+ service that is a "best effort" service that does not guarantee
+ packet reception or packet reception order, and which does not have
+ any support for flow or congestion control. For example, the Any-
+ Source Multicast (ASM) model of IP multicast as defined in RFC 1112
+ [5] is such a "best effort" network service. While the basic service
+ provided by RFC 1112 is largely scalable, providing congestion
+ control or reliability should be done carefully to avoid severe
+ scalability limitations, especially in presence of heterogeneous sets
+ of receivers.
+
+ There are currently two models of multicast delivery, the Any-Source
+ Multicast (ASM) model as defined in RFC 1112 [5] and the Source-
+ Specific Multicast (SSM) model as defined in [10]. LCT works with
+ both multicast models, but in a slightly different way with somewhat
+ different environmental concerns. When using ASM, a sender S sends
+ packets to a multicast group G, and the LCT channel address consists
+ of the pair (S,G), where S is the IP address of the sender and G is a
+ multicast group address. When using SSM, a sender S sends packets to
+ an SSM channel (S,G), and the LCT channel address coincides with the
+ SSM channel address.
+
+
+
+
+Luby, et. al. Experimental [Page 9]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ A sender can locally allocate unique SSM channel addresses, and this
+ makes allocation of LCT channel addresses easy with SSM. To allocate
+ LCT channel addresses using ASM, the sender must uniquely chose the
+ ASM multicast group address across the scope of the group, and this
+ makes allocation of LCT channel addresses more difficult with ASM.
+
+ LCT channels and SSM channels coincide, and thus the receiver will
+ only receive packets sent to the requested LCT channel. With ASM,
+ the receiver joins an LCT channel by joining a multicast group G, and
+ all packets sent to G, regardless of the sender, may be received by
+ the receiver. Thus, SSM has compelling security advantages over ASM
+ for prevention of denial of service attacks. In either case,
+ receivers SHOULD use mechanisms to filter out packets from unwanted
+ sources.
+
+ Some networks are not amenable to some congestion control protocols
+ that could be used with LCT. In particular, for a satellite or
+ wireless network, there may be no mechanism for receivers to
+ effectively reduce their reception rate since there may be a fixed
+ transmission rate allocated to the session.
+
+4.2 Delivery service models
+
+ LCT can support several different delivery service models. Two
+ examples are briefly described here.
+
+ Push service model.
+
+ One way a push service model can be used for reliable content
+ delivery is to deliver a series of objects. For example, a receiver
+ could join the session and dynamically adapt the number of LCT
+ channels the receiver is joined to until enough packets have been
+ received to reconstruct an object. After reconstructing the object
+ the receiver may stay in the session and wait for the transmission of
+ the next object.
+
+ The push model is particularly attractive in satellite networks and
+ wireless networks. In these cases, a session may consist of one
+ fixed rate LCT channel.
+
+ On-demand content delivery model.
+
+ For an on-demand content delivery service model, senders typically
+ transmit for some given time period selected to be long enough to
+ allow all the intended receivers to join the session and recover the
+ object. For example a popular software update might be transmitted
+
+
+
+
+
+Luby, et. al. Experimental [Page 10]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ using LCT for several days, even though a receiver may be able to
+ complete the download in one hour total of connection time, perhaps
+ spread over several intervals of time.
+
+ In this case the receivers join the session, and dynamically adapt
+ the number of LCT channels they subscribe to according to the
+ available bandwidth. Receivers then drop from the session when they
+ have received enough packets to recover the object.
+
+ As an example, assume that an object is 50 MB. The sender could send
+ 1 KB packets to the first LCT channel at 50 packets per second, so
+ that receivers using just this LCT channel could complete reception
+ of the object in 1,000 seconds in absence of loss, and would be able
+ to complete reception even in presence of some substantial amount of
+ losses with the use of coding for reliability. Furthermore, the
+ sender could use a number of LCT channels such that the aggregate
+ rate of 1 KB packets to all LCT channels is 1,000 packets per second,
+ so that a receiver could be able to complete reception of the object
+ in as little 50 seconds (assuming no loss and that the congestion
+ control mechanism immediately converges to the use of all LCT
+ channels).
+
+ Other service models.
+
+ There are many other delivery service models that LCT can be used for
+ that are not covered above. As examples, a live streaming or an on-
+ demand archival content streaming service model. A description of
+ the many potential applications, the appropriate delivery service
+ model, and the additional mechanisms to support such functionalities
+ when combined with LCT is beyond the scope of this document. This
+ document only attempts to describe the minimal common scalable
+ elements to these diverse applications using LCT as the delivery
+ transport.
+
+4.3 Congestion Control
+
+ The specific congestion control protocol to be used for LCT sessions
+ depends on the type of content to be delivered. While the general
+ behavior of the congestion control protocol is to reduce the
+ throughput in presence of congestion and gradually increase it in the
+ absence of congestion, the actual dynamic behavior (e.g. response to
+ single losses) can vary.
+
+ Some possible congestion control protocols for reliable content
+ delivery using LCT are described in [22], [3], and [25]. Different
+ delivery service models might require different congestion control
+ protocols.
+
+
+
+
+Luby, et. al. Experimental [Page 11]
+
+RFC 3451 LCT Building Block December 2002
+
+
+5. Packet Header Fields
+
+ 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
+ format that is recommended for use by protocol instantiations to
+ ensure a uniform format across different protocol instantiations.
+ Other LCT header formats MAY be used by protocol instantiations, but
+ if the default LCT header format is not used by a protocol
+ instantiation that uses LCT, then the protocol instantiation MUST
+ specify the lengths and positions within the LCT header it uses of
+ all fields described in the default LCT header.
+
+ Other building blocks MAY describe some of the same fields as
+ described for the LCT header. It is RECOMMENDED that protocol
+ instantiations using multiple building blocks include shared fields
+ at most once in each packet. Thus, for example, if another building
+ block is used with LCT that includes the optional Expected Residual
+ Time field, then the Expected Residual Time field SHOULD be carried
+ in each packet at most once.
+
+ The position of the LCT header within a packet MUST be specified by
+ any protocol instantiation that uses LCT.
+
+5.1 Default LCT header format
+
+ The default LCT header is of variable size, which is specified by a
+ length field in the third byte of the header. In the LCT header, all
+ integer fields are carried in "big-endian" or "network order" format,
+ that is, most significant byte (octet) first. Bits designated as
+ "padding" or "reserved" (r) MUST by set to 0 by senders and ignored
+ by receivers. Unless otherwise noted, numeric constants in this
+ specification are in decimal (base 10).
+
+ The format of the default LCT header is depicted in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 12]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Congestion Control Information (CCI, length = 32*(C+1) bits) |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Transport Session Identifier (TSI, length = 32*S+16*H bits) |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Transport Object Identifier (TOI, length = 32*O+16*H bits) |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sender Current Time (SCT, if T = 1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Expected Residual Time (ERT, if R = 1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Header Extensions (if applicable) |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1 - Default LCT header format
+
+ The function and length of each field in the default LCT header is
+ the following. Fields marked as "1" mean that the corresponding bits
+ MUST 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.
+
+ LCT version number (V): 4 bits
+
+ Indicates the LCT version number. The LCT version number for
+ this specification is 1.
+
+ Congestion control flag (C): 2 bits
+
+ C=0 indicates the Congestion Control Information (CCI) field is
+ 32-bits in length. C=1 indicates the CCI field is 64-bits in
+ length. C=2 indicates the CCI field is 96-bits in length. C=3
+ indicates the CCI field is 128-bits in length.
+
+ Reserved (r): 2 bits
+
+ Reserved for future use. A sender MUST set these bits to zero
+ and a receiver MUST ignore these bits.
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 13]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ Transport Session Identifier flag (S): 1 bit
+
+ This is the number of full 32-bit words in the TSI field. The
+ TSI field is 32*S + 16*H bits in length, i.e. the length is
+ either 0 bits, 16 bits, 32 bits, or 48 bits.
+
+ Transport Object Identifier flag (O): 2 bits
+
+ This is the number of full 32-bit words in the TOI field. The
+ TOI field is 32*O + 16*H bits in length, i.e., the length is
+ either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96
+ bits, or 112 bits.
+
+ Half-word flag (H): 1 bit
+
+ The TSI and the TOI fields are both multiples of 32-bits plus
+ 16*H bits in length. This allows the TSI and TOI field lengths
+ to be multiples of a half-word (16 bits), while ensuring that
+ the aggregate length of the TSI and TOI fields is a multiple of
+ 32-bits.
+
+ Sender Current Time present flag (T): 1 bit
+
+ T = 0 indicates that the Sender Current Time (SCT) field is not
+ present. T = 1 indicates that the SCT field is present. The
+ SCT is inserted by senders to indicate to receivers how long
+ the session has been in progress.
+
+ Expected Residual Time present flag (R): 1 bit
+
+ R = 0 indicates that the Expected Residual Time (ERT) field is
+ not present. R = 1 indicates that the ERT field is present.
+ The ERT is inserted by senders to indicate to receivers how
+ much longer the session / object transmission will continue.
+
+ Senders MUST NOT set R = 1 when the ERT for the session is more
+ than 2^32-1 time units (approximately 49 days), where time is
+ measured in units of milliseconds.
+
+ Close Session flag (A): 1 bit
+
+ Normally, A is set to 0. The sender MAY 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
+
+
+
+Luby, et. al. Experimental [Page 14]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ 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, 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.
+
+ LCT header length (HDR_LEN): 8 bits
+
+ Total length of the LCT header in units of 32-bit words. The
+ length of the LCT header MUST be a multiple of 32-bits. This
+ field can be used to directly access the portion of the packet
+ beyond the LCT header, i.e., to the first other header if it
+ exists, or to the packet payload if it exists and there is no
+ other header, or to the end of the packet if there are no other
+ headers or packet payload.
+
+ Codepoint (CP): 8 bits
+
+ An opaque identifier which is passed to the packet payload
+ decoder to convey information on the codec being used for the
+ packet payload. The mapping between the codepoint and the
+ actual codec is defined on a per session basis and communicated
+ out-of-band as part of the session description information.
+ The use of the CP field is similar to the Payload Type (PT)
+ field in RTP headers as described in RFC 1889 [21].
+
+
+
+
+
+Luby, et. al. Experimental [Page 15]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ Congestion Control Information (CCI): 32, 64, 96 or 128 bits
+
+ Used to carry congestion control information. For example, the
+ congestion control information could include layer numbers,
+ logical channel numbers, and sequence numbers. This field is
+ opaque for the purpose of this specification.
+
+ This field MUST 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
+
+ The TSI uniquely identifies a session among all sessions from a
+ particular sender. The TSI is scoped by the IP address of the
+ sender, and thus the IP address of the sender and the TSI
+ together uniquely identify the session. Although a TSI in
+ conjunction with the IP address of the sender 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
+ 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 the 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.
+
+
+
+
+Luby, et. al. Experimental [Page 16]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112
+ bits.
+
+ This field indicates which object within the session this
+ packet pertains to. For example, a sender might send a number
+ of files in the same session, using TOI=0 for the first file,
+ TOI=1 for the second one, etc. As another example, the TOI may
+ be a unique global identifier of the object that is being
+ transmitted from several senders concurrently, and the TOI
+ value may be the 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.
+
+ The length of the TOI field is 32*O + 16*H bits. Note that the
+ aggregate lengths of the TSI field plus the TOI field is a
+ multiple of 32 bits.
+
+ Sender Current Time (SCT): 0 or 32 bits
+
+ This field represents the current clock at the sender and at
+ the time this packet was transmitted, measured in units of 1ms
+ and computed modulo 2^32 units from the start of the session.
+
+ This field MUST NOT be present if T=0 and MUST be present if
+ T=1.
+
+ Expected Residual Time (ERT): 0 or 32 bits
+
+ This field represents the sender expected residual transmission
+ time for the current session or for the transmission of the
+ current object, measured in units of 1ms. If the packet
+ containing the ERT field also contains the TOI field, then ERT
+ refers to the object corresponding to the TOI field, otherwise
+ it refers to the session.
+
+ This field MUST NOT be present if R=0 and MUST be present if
+ R=1.
+
+5.2 Header-Extension Fields
+
+ Header Extensions are used in LCT to accommodate optional header
+ fields that are not always used or have variable size. Examples of
+ the use of Header Extensions include:
+
+ o Extended-size versions of already existing header fields.
+
+
+
+Luby, et. al. Experimental [Page 17]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ o Sender and Receiver authentication information.
+
+ The presence of Header Extensions can be inferred by the LCT header
+ length (HDR_LEN): if HDR_LEN is larger than the length of the
+ standard header then the remaining header space is taken by Header
+ Extension fields.
+
+ If present, Header Extensions MUST be processed to ensure that they
+ are recognized before performing any congestion control procedure or
+ otherwise accepting a packet. The default action for unrecognized
+ header extensions is to ignore them. This allows the future
+ introduction of backward-compatible enhancements to LCT without
+ changing the LCT version number. Non backward-compatible header
+ extensions CANNOT be introduced without changing the LCT version
+ number.
+
+ Protocol instantiation MAY override this default behavior for PI-
+ specific extensions (see below).
+
+ There are two formats for Header Extension fields, as depicted below.
+ The first format is used for variable-length extensions, with Header
+ Extension Type (HET) values between 0 and 127. The second format is
+ used for fixed length (one 32-bit word) extensions, using HET values
+ from 127 to 255.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HET (<=127) | HEL | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ . .
+ . Header Extension Content (HEC) .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HET (>=128) | Header Extension Content (HEC) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2 - Format of additional headers
+
+ The explanation of each sub-field is the following:
+
+ Header Extension Type (HET): 8 bits
+
+ The type of the Header Extension. This document defines a
+ number of possible types. Additional types may be defined in
+
+
+
+Luby, et. al. Experimental [Page 18]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ future versions of this specification. HET values from 0 to
+ 127 are used for variable-length Header Extensions. HET values
+ from 128 to 255 are used for fixed-length 32-bit Header
+ Extensions.
+
+ Header Extension Length (HEL): 8 bits
+
+ The length of the whole Header Extension field, expressed in
+ multiples of 32-bit words. This field MUST 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).
+
+ Header Extension Content (HEC): variable length
+
+ The content of the Header Extension. The format of this sub-
+ field depends on the Header Extension type. For fixed-length
+ Header Extensions, the HEC is 24 bits. For variable-length
+ Header Extensions, the HEC field has variable size, as
+ specified by the HEL field. Note that the length of each
+ Header Extension field MUST be a multiple of 32 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 Protocol Instantiation specific extensions (PI-specific).
+ General LCT extensions have HET in the ranges 0:63 and 128:191
+ inclusive. PI-specific extensions have HET in the ranges 64:127 and
+ 192:255 inclusive.
+
+ General LCT extensions are intended to allow the introduction of
+ backward-compatible enhancements to LCT without changing the LCT
+ version number. Non backward-compatible header extensions CANNOT be
+ introduced without changing the LCT version number.
+
+ PI-specific extensions are reserved for PI-specific use with semantic
+ and default parsing actions defined by the PI.
+
+ The following general LCT Header Extension types are defined:
+
+ EXT_NOP=0 No-Operation extension.
+ The information present in this extension field MUST be
+ ignored by receivers.
+
+ EXT_AUTH=1 Packet authentication extension
+ Information used to authenticate the sender of the
+ packet. The format of this Header Extension and its
+
+
+
+Luby, et. al. Experimental [Page 19]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ processing is outside the scope of this document and is
+ to be communicated out-of-band as part of the session
+ description.
+
+ 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.
+
+ 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 Extension and MUST recognize EXT_AUTH, but MAY NOT be able to
+ parse its content.
+
+6. Operations
+
+6.1 Sender Operation
+
+ Before joining an LCT session a receiver MUST obtain a session
+ description. The session description MUST include:
+
+ o The sender IP address;
+
+ o The number of LCT channels;
+
+ o The addresses and port numbers used for each LCT channel;
+
+ o The Transport Session ID (TSI) to be used for the session;
+
+ o Enough information to determine the congestion control protocol
+ being used;
+
+ o Enough information to determine the packet authentication scheme
+ being used if it is being used.
+
+ The session description could also include, but is not limited to:
+
+ o The data rates used for each LCT channel;
+
+ o The length of the packet payload;
+
+
+
+
+Luby, et. al. Experimental [Page 20]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ o The mapping of TOI value(s) to objects for the session;
+
+ o Any information that is relevant to each object being
+ transported, such as when it will be available within the
+ session, for how long, and the length of the object;
+
+ 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.
+
+ 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], etc. It might be
+ carried in a session announcement protocol such as SAP as defined in
+ RFC 2974 [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, 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.
+
+ Several objects can be carried within the same LCT session. In this
+ 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
+ the transmission is considered complete. The transmission may be
+ considered complete when some time has expired, a certain number of
+
+
+
+Luby, et. al. Experimental [Page 21]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ 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
+ restriction on packet sizes. However, network efficiency
+ considerations recommend that the sender uses an 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 when fragmentation
+ coupled with packet loss might introduce severe inefficiency in the
+ transmission.
+
+ It is recommended that all packets have the same or very similar
+ sizes, as this can have a severe impact on the effectiveness of
+ congestion control schemes such as the ones described in [22], [3],
+ and [25]. A sender of packets using LCT MUST implement the sender-
+ side part of one of the congestion control schemes that is in
+ accordance with RFC 2357 [13] using the Congestion Control
+ Information field provided in the LCT header, and the corresponding
+ receiver congestion control scheme is to be communicated out-of-band
+ and MUST be implemented by any receivers participating in the
+ session.
+
+6.2 Receiver Operation
+
+ Receivers can operate differently depending on the delivery service
+ model. For example, for an on demand service model, receivers may
+ join a session, obtain the necessary packets to reproduce the object,
+ and then leave the session. As another example, for a streaming
+ service model, a receiver may be continuously joined to a set of LCT
+ channels to download all objects in a session.
+
+ To be able to participate in a session, a receiver MUST obtain the
+ relevant session description information as listed in Section 6.1.
+
+ If packet authentication information is present in an LCT header, it
+ SHOULD be used as specified in Section 5.2. To be able to be a
+ receiver in a session, the receiver MUST be able to process the LCT
+ header. The receiver MUST be able to discard, forward, store or
+ process the other headers and the packet payload. If a receiver is
+ not able to process a LCT header, it MUST drop from the session.
+
+ To be able to participate in a session, a receiver MUST implement the
+ congestion control protocol specified in the session description
+ using the Congestion Control Information field provided in the LCT
+ header. If a receiver is not able to implement the congestion control
+ protocol used in the session, it MUST NOT join the session. When the
+ session is transmitted on multiple LCT channels, receivers MUST
+
+
+
+Luby, et. al. Experimental [Page 22]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ 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.
+
+ Several objects can be carried either sequentially or concurrently
+ within the same LCT session. In this case, each object is identified
+ by a unique TOI. Note that even if a server stops sending packets
+ for an old object before starting to transmit packets for a new
+ object, both the network and the underlying protocol layers can cause
+ some reordering of packets, especially when sent over different LCT
+ channels, and thus receivers SHOULD NOT assume that the reception of
+ a packet for a new object means that there are no more packets in
+ transit for the previous one, at least for some amount of time.
+
+ A receiver MAY be concurrently joined to multiple LCT sessions from
+ one or more senders. The receiver MUST perform congestion control on
+ 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.
+
+7. Requirements from Other Building Blocks
+
+ 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.
+
+ The congestion control MUST be applied to the LCT session as an
+ entity, i.e., over the aggregate of the traffic carried by all of the
+ LCT channels associated with the LCT session. Some possible schemes
+ are specified in [22], [3], and [25]. 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.
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 23]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ The particular layered encoder and congestion control protocols used
+ with LCT have an impact on the performance and applicability of LCT.
+ For example, some layered encoders used for video and audio streams
+ can produce a very limited number of layers, thus providing a very
+ coarse control in the reception rate of packets by receivers in a
+ session. When LCT is used for reliable data transfer, some FEC
+ codecs are inherently limited in the size of the object they can
+ encode, and for objects larger than this size the reception overhead
+ on the receivers can grow substantially.
+
+ A more in-depth description of the use of FEC in Reliable Multicast
+ Transport (RMT) protocols is given in [11]. Some of the FEC codecs
+ that MAY be used in conjunction with LCT for reliable content
+ delivery are specified in [12]. The Codepoint field in the LCT
+ header is an opaque field that can be used to carry information
+ related to the encoding of the packet payload.
+
+ 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.
+
+ 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].
+
+ Some protocol instantiations that use LCT MAY use building blocks
+ that 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
+
+ LCT can be subject to denial-of-service attacks by attackers which
+ try to confuse the congestion control mechanism, or send forged
+ packets to the session which would prevent successful reconstruction
+ or cause inaccurate reconstruction of large portions of 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
+
+
+
+Luby, et. al. Experimental [Page 24]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ 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.
+
+ Another vulnerability of LCT is the potential of receivers obtaining
+ an incorrect session description for the session. The consequences
+ of this could be that legitimate receivers with 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.
+
+ 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.
+
+9. IANA Considerations
+
+ No information in this specification is subject to IANA registration.
+
+ Building blocks used in conjunction with LCT MAY introduce additional
+ IANA considerations.
+
+10. Acknowledgments
+
+ Thanks to Vincent Roca and Roger Kermode for detailed comments and
+ contributions to this document. Thanks also to Bruce Lueckenhoff,
+ Hayder Radha and Justin Chapweske for detailed comments on this
+ document.
+
+11. References
+
+ [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+
+
+Luby, et. al. Experimental [Page 25]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
+ 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.
+
+ [4] Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital
+ Fountain Approach to Reliable Distribution of Bulk Data",
+ Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
+
+ [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
+ 1112, August 1989.
+
+ [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+ 2616, January 1997.
+
+ [7] Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File
+ Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January
+ 2000.
+
+ [8] Handley, M. and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+ [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
+ Protocol", RFC 2974, October 2000.
+
+ [10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
+ Dissertation, Stanford University, Department of Computer
+ Science, Stanford, California, August 2001.
+
+ [11] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
+ J. Crowcroft, "The Use of Forward Error Correction (FEC) in
+ Reliable Multicast", RFC 3453, December 2002.
+
+ [12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
+ J. Crowcroft, "Forward Error Correction (FEC) Building Block",
+ RFC 3452, December 2002.
+
+ [13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
+ Criteria for Evaluating Reliable Multicast Transport and
+ Application Protocols", RFC 2357, June 1998.
+
+ [14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
+ 3023, January 2001.
+
+
+
+Luby, et. al. Experimental [Page 26]
+
+RFC 3451 LCT Building Block December 2002
+
+
+ [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.
+
+ [16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+ 1980.
+
+ [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+ 1992.
+
+ [18] Rizzo, L., "Effective Erasure Codes for Reliable Computer
+ Communication Protocols", ACM SIGCOMM Computer Communication
+ Review, Vol.27, No.2, pp.24-36, Apr 1997.
+
+ [19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast
+ congestion control scheme", Proceedings of SIGCOMM 2000,
+ Stockholm Sweden, August 2000.
+
+ [20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution
+ protocol based on software FEC techniques", Proceedings of the
+ Fourth IEEES Workshop on the Architecture and Implementation of
+ High Performance Communication Systems, HPCS'97, Chalkidiki
+ Greece, June 1997.
+
+ [21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", RFC
+ 1889, January 1996.
+
+ [22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion
+ Control for Layered Multicast Data Transfer", IEEE Infocom'98,
+ San Francisco, CA, Mar.28-Apr.1 1998.
+
+ [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.
+
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 27]
+
+RFC 3451 LCT Building Block December 2002
+
+
+Authors' Addresses
+
+ Michael Luby
+ Digital Fountain
+ 39141 Civic Center Dr.
+ Suite 300
+ Fremont, CA, USA, 94538
+
+ EMail: luby@digitalfountain.com
+
+ Jim Gemmell
+ Microsoft Research
+ 455 Market St. #1690
+ San Francisco, CA, 94105
+
+ EMail: jgemmell@microsoft.com
+
+ Lorenzo Vicisano
+ cisco Systems, Inc.
+ 170 West Tasman Dr.
+ San Jose, CA, USA, 95134
+
+ EMail: lorenzo@cisco.com
+
+ Luigi Rizzo
+ Dip. Ing. dell'Informazione,
+ Univ. di Pisa
+ via Diotisalvi 2, 56126 Pisa, Italy
+
+ EMail: luigi@iet.unipi.it
+
+ Mark Handley
+ ICIR
+ 1947 Center St.
+ Berkeley, CA, USA, 94704
+
+ EMail: mjh@icir.org
+
+ Jon Crowcroft
+ Marconi Professor of Communications Systems
+ University of Cambridge
+ Computer Laboratory
+ William Gates Building
+ J J Thomson Avenue
+ Cambridge CB3 0FD, UK
+
+ EMail: Jon.Crowcroft@cl.cam.ac.uk
+
+
+
+
+Luby, et. al. Experimental [Page 28]
+
+RFC 3451 LCT Building Block December 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al. Experimental [Page 29]
+