From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3451.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc3451.txt (limited to 'doc/rfc/rfc3451.txt') 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] + -- cgit v1.2.3