"Layered Coding Transport (LCT) Building Block", Michael Luby, Mark Watson, Lorenzo Vicisano, 13-Jul-09. ( bytes)
The Layered Coding Transport (LCT) Bulding Block 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. This document obsoletes RFC 3451.
"Asynchronous Layered Coding (ALC) Protocol Instantiation", Michael Luby, Mark Watson, Lorenzo Vicisano, 13-Jul-09. ( bytes)
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC3450.
"FLUTE - File Delivery over Unidirectional Transport", Toni Paila, Rod Walsh, Michael Luby, Rami Lehtonen, Vincent Roca, 6-Aug-09. ( bytes)
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC3926.
"NACK-Oriented Reliable Multicast Transport Protocol", Brian Adamson, Carsten Bormann, University London, Joseph Macker, 3-Jun-09. ( bytes)
This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. (This Internet-Draft is also available in PDF format [ bytes].)
"Simple Authentication Schemes for the ALC and NORM Protocols", Vincent Roca, 9-Mar-09. ( bytes)
This document introduces four schemes that provide a per-packet authentication and integrity service in the context of the ALC and NORM protocols. The first scheme is based on digital signatures. Because it relies on asymmetric cryptography, this scheme generates a high processing load at the sender and to a lesser extent at a receiver, as well as a significant transmission overhead. It is therefore well suited to low data rate sessions. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). If this approach also relies an asymmetric cryptography, the processing load and the transmission overhead are significantly reduced compared to traditional digital signature schemes. It is therefore well suited to medium data rate sessions. The third scheme relies on a group Message Authentication Code (MAC). Because this scheme relies on symmetric cryptography, MAC calculation and verification are fast operations, which makes it suited to high data rate sessions. However it only provides a group authentication and integrity service, which means that it only protects against attackers that are not group members. Finally, the fourth scheme merges the digital signature and group group schemes, and is useful to mitigate DoS attacks coming from attackers that are not group members.

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.