|
|
|
|
TRACK Reliable Multicast Standard (IETF RMT WG)TRACK Protocol Instantiation Over UDP draft-ietf-rmt-track-pi-udp-00.txt TRACK Building Block draft-ietf-rmt-track-bb-02.txt Auto Tree Configuration Building Block draft-ietf-rmt-bb-tree-config-03.txt TRACK stands for TRee ACKnowledgement based protocol. There are two fundamental types of multicast reliability, receiver based and sender based. Receiver based reliability allows receivers to detect failures, but provides anonymous membership to the sender. Sender based reliability adds group membership knowledge and explicit confirmation of receipt, at the cost of added complexity and lower isolation of the impact of failures between receivers. The IETF is standardizing three reliable multicast protocols, NORM, TRACK, and ALC. NORM is a single-rate receiver reliable multicast protocol, and ALC is a multi-rate receiver reliable protocol. TRACK provides sender level reliability on top of NORM, as well as the ability to create and organize nodes in to hierarchical trees, for increased scalability. The IETF has also granted EXPERIMENTAL RFC status to the PGM reliable multicast protocol, which is of the same category as NORM. Vendors such as Cisco, Talarian, Tibco, Microsoft, and Nortel all provide commercial support for PGM, making it the current de-facto standard for reliable multicast. TRACK provides application layer confirmed delivery of messages, statistics aggregation, hierarchical distribution, and improved flow and congestion control on top of NORM. It is also designed to provide these functions in conjunction with other protocols, such as PGM or an application layer multicast system such as Talarian's SmartSockets product. TRACK is being developed by a number of people, including For the most current list of standards documents, please go to the IETF web site at http://www.ietf.org/html.charters/rmt-charter.html. IETF Reliable Multicast Architecture DocumentsAfter years of work as an IRTF research group (the Reliable Multicast Research Group - RMRG), the reliable multicast research community became convinced that we had found provably safe approaches to the requirements laid out in RFC2357. This led to the chartering of the IETF Reliable Multicast Transport (RMT) working group. The first deliverables of the group was the following two documents, laying out the design space and architecture we would follow in our creation of reliable multicast standards. A number of authors worked on each. The Reliable Multicast Design Space for Bulk Data Transfer (RFC2887)Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer (RFC3048)RMTP-II Reliable Multicast ProtocolRMTP-II was a commercial reliable multicast protocol, co-developed by Lucent Technologies and GlobalCast Communications. It is no longer commercially available, but provided a great deal of experience with reliable multicast requirements and design tradeoffs. TRACK borrows heavily from RMTP-II, as well as from the TRAM protocol out of Sun labs. In terms of a reliable multicsat taxonomy, RMTP-II provided roughly the same functionality as NORM + TRACK, in a single integrated protocol. The current draft specification for RMTP-II was released on April 8, 1998. A new version will be released in the near future. The document is broken in to two halves. The first half contains the core protocol specification, while the second document covers optional features and appendices. In addition to the specficiation, the below published paper provides a top level overview of the protocol. Finally, my dissertation covers both RMTP-II as well as multicast congestion control. An Overview of the Reliable Multicast Transport Protocol II (.pdf)Abstract: This document provides an overview of the Reliable Multicast Transport Protocol II, RMTP-II. RMTP-II is a reliable multicast protocol, designed to reliably and efficiently send data from a few senders to large groups of simultaneous recipients. It works over both symmetric networks, as well as over asymmetrical network topologies such as those provided by satellite, cable modem or Asymmetrical Digital Subscriber Line (ADSL) carriers. Before sending, each sender must connect with a trusted Top Node, to receive permission and control parameters for its data stream. The top node provides network managers with a single point of control for the senders, allowing them to monitor and control the traffic being sent. RMTP-II builds on a rich field of existing work, and adds to it the following novel contributions. It differentiates the roles of the nodes in the protocol, provides algorithms for smoothing and control of the return (TRACK) traffic, and provides explicit support for highly asymmetrical networks. It provides explicit network management controls through a centralized point of control, a fully distributed membership protocol that enables positive confirmation of data delivery, and fault recovery algorithms which are integrated to the reliability semantics of the protocol. It includes a novel reliability level called Time Bounded Reliability, and offers a unique combination of TRACKs, NACKs and FEC for increased scalability and real time performance. Finally, it integrates distributed algorithms for RTT calculation to each receiver, and provides automatic configuration of receiver nodes.
RMTP-II
Draft Specification (text, 152k)
|
| Abstract: The Reliable Multicast Transport Protocol II,
RMTP-II, is a
reliable multicast protocol which reliably and efficiently sends data from
a few senders to large groups of simultaneous recipients. RMTP-II works
over all types of networks, including symmetric networks as well as
asymmetrical networks such as those provided by satellite, cable modem or
Asymmetrical Digital Subscriber Line (ADSL) carriers. RMTP-II presently
requires some configuration of topology.
The objectives of RMTP-II are guaranteed reliability, high throughput, and low end-to-end delay on any network topology, while providing the network manager with control over transmission traffic. RMTP-II is based on a hierarchical tree structure in which receivers are grouped into local regions. In each region a special control node is responsible for maintaining receiver membership and for aggregating the acknowledgments from the receivers in its region and forwarding them to the sender. The control node may also take responsibility for retransmitting dropped packets to the local receivers. RMTP-II is a sender-reliable multicast protocol which uses a fully distributed membership protocol to keep track of the current membership of the tree. This allows senders to determine when packets become stable and may be deleted. RMTP-II provides strong guarantees on packet delivery and gives the senders a count of the number of receivers that successfully received each packet. It also supports optional negative acknowledgements of missed packets for faster recovery of data and lower control traffic on low loss networks. The Internet is highly dependent on the TCP congestion control mechanisms which allow all streams to share bandwidth fairly. Widespread deployment of a transport protocol that does not interact gracefully with the TCP protocol has the potential to do significant damage to the Internet. This has been an obstacle to the standardization of a reliable multicast protocol. RMTP-II is designed to interact closely with congestion control algorithms and provide these algorithms with constant information about the loss rates and round trip times in the tree. The RMTP-II congestion control algorithms are under development and will be presented in a companion document. RMTP-II complements its congestion control algorithms with additional centralized management control over all RMTP-II streams running on the network. RMTP requires senders to interact with a trusted Top Node and accept configuration information from this node. The Top Node provides the network manager with an SNMP interface for monitoring and controlling the streams with which it is associated. The network manager can place bandwidth limits on each stream and can specify the congestion control parameters that each sender must use. This provides graceful, controlled deployment of reliable multicast that protects the network both through explicit management and automatic congestion control policies. RMTP-II requires some topology configuration which is left to an external Session Manager. A Session Manager can be implemented as either a centralized tool controlled by the network manager, as static configuration files, or as a set of fully distributed algorithms. The Session Manager is also responsible for optional session advertisements and optional total group membership tracking. RMTP-II provides the following additional features:
|
In order to pass the requirements on reliable multicast standards laid out in IETF RFC2357, a security analysis of TRACK is required. This document was done in conjunction with Thomas Hardjorno, a co-chair of the MSEC WG, and has helped define the requirements of multicast security in the IETF.
RMP was a commercial reliable multicast protocol, and was the core IP that GlobalCast Communications was founded on. It was also one of the first academic reliable multicast protocols, first released in 1993. Where all of the IETF protocols are targeted at distribution of bulk data from a single sender to tens of thousands of receivers, RMP provides a wide range of distributed systems guarantees, along with very high levels of performance, for groups of up to a hundred receivers. RMP was co-developed with Todd Montgomery (of West Virginia University, and a co-founder of GlobalCast), with the help of many other wonderful researchers.
|
Copyright © 2005
Brian Whetten
|
