RMT Working Group B. Whetten, Talarian Internet Engineering Task Force L. Vicisano, Cisco INTERNET-DRAFT R.Kermode, Motorola draft-ietf-rmt-buildingblocks-00.txt M.Handley, ACIRI 15 June 1999 S.Floyd, ACIRI Expires 15 December 1999 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer <draft-ietf-rmt-buildingblocks-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. vInternet-Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a framework for the standardization of bulk-data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalties between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as "building blocks." The remaining parts of the protocols, consisting of highly protocol specific tightly intertwined functions shall be designated as "protocol cores." Thus, each protocol can then be constructed by merging a "protocol core" with a number of "building blocks" which can be re-used across multiple protocols. Draft RMT Building Blocks 15 June 1999 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 1. Introduction RFC2357 lays out the requirements for reliable multicast protocols that are to be considered for standardization by the IETF. They include: o Congestion Control. The protocol must be safe to deploy in the widespread Internet. Specifically, it must adhere to three mandates: a) it must achieve good throughput (i.e. it must not consistently overload links with excess data or repair traffic), b) it must achieve good link utilization, and c) it must not starve competing flows. o Scalability. The protocol should be able to work under a variety of conditions that include multiple network topologies, link speeds, and the receiver set size. It is more important to have a good understanding of how and when a protocol breaks than when it works. o Security. The protocol must be analyzed to show what is necessary to allow it to cope with security and privacy issues. This includes understanding the role of the protocol in data confidentiality and sender authentication, as well as how the protocol will provide defenses against denial of service attacks. These requirements are primarily directed towards making sure that any standards will be safe for widespread Internet deployment. The advancing maturity of current work on reliable multicast congestion control (TFMCC) [HFW99] in the IRTF Reliable Multicast Research Group (RMRG) has been one of the events that has allowed the IETF to charter the RMT working group. RMCC only addresses a subset of the design space for reliable multicast. Fortuitously, the requirements it addresses are also the most pressing application and market requirements. A protocol's ability to meet the requirements of congestion control, scalability, and security is affected by a number of factors that are described in a separate document [HWKFV99]. In summary, these are: Expires 15 December 1999 [Page 2]
Draft RMT Building Blocks 15 June 1999 o Ordering Guarantees. A protocol must offer at least one of either source ordered or unordered delivery guarantees. Support for total ordering across multiple senders is not recommended, as it makes it more difficult to scale the protocol, and can more easily be implemented at a higher level. o Receiver Scalability. A protocol should be able to support a "large" number of simultaneous receivers per transport group. A typical receiver set should be on the order of 1,000 - 10,000 simultaneous receivers per group. However, this number may be larger or smaller depending upon the factors that follow. o Real-Time Feedback. RMCC requires soft real-time feedback, so a protocol must provide some means for this information to be measured and returned to the sender. While this does not require that a protocol deliver data in soft real-time, it is an important application requirement that can be provided easily given real-time feedback. o Delivery Guarantees. A protocol must provide at least statistically reliable delivery (it must be able to guarantee delivery of a minimum percentage of the data to a minimum percentage of the receiver set). It may optionally provide message stability (TCP level delivery guarantees), and/or time bounded reliability (attempt repairs for a specific amount of time before giving up). o Network Topologies. A protocol must not break the network when deployed in the full Internet. However, we recognize that intranets will be where the first wave of deployments happen, and so are also very important to support. Thus, support for satellite networks (including those with terrestrial return paths or no return paths at all) is encouraged, but not required. o Group Membership. The group membership algorithms must be scaleable. Membership can be anonymous (where the sender does not know the list of receivers), or fully distributed (where the sender receives a count of the number of receivers, and optionally a list of failures). o Example Applications. Some of the applications that a RM protocol could be designed to support include multimedia broadcasts, real time financial market data distribution, multicast file transfer, and server replication. Expires 15 December 1999 [Page 3]
Draft RMT Building Blocks 15 June 1999 1.1. Protocol Families The design-space document [HWKFV99] also provides a taxonomy of the most popular approaches that have been proposed over the last ten years. After congestion control, the primary challenge has been that of meeting the requirement for receiver scalability. For protocols that include a back-channel for recovery of lost packets, the ability to take advantage of support of elements in the network has been found to be very beneficial for supporting large numbers of receivers. ,lp This taxonomy breaks proposed protocols in to four families. 1 No network assist. Protocols such as SRM [FJM95] and MDP2 [MA99] attempt to limit traffic by only using NACKs for requesting packet retransmission. These protocols provide statistical reliability, but do not provide known message stability. They do not require network infrastructure, but this introduces some questions about how well the protocols will scale [LESZ97, Kermode98, LDW98, OXB99]. 2 Server assist. Protocols such as RMTP [LP96, PSLM97], RMTP-II [WBPM98] and TRAM [KCW98], use positive acknowledgements (ACKs) to achieve stronger delivery guarantees. These ACKs also make it easier to implement RMCC. However, in order to avoid ACK implosion in scaled up deployments, the protocol requires that servers be placed in the network. 3 Router assist. Like SRM, protocols such as PGM [FLST98] and [LG97] also use negative acknowledgements for packet recovery, and therefore do not provide message stability. These protocols take advantage of new router software to do constrained negative acknowledgements and retransmissions. 4 Open-Loop delivery. For some applications, lower reliability guarantees can be accepted. Thus, one can deploy a protocol built using sender-based Forward Error Correction (FEC) methods with no feedback from the receivers or the network. Such protocols are particularly well suited for highly-asymmetric networks (e.g. satellite). 2. Building Blocks Rationale As specified in RFC2357 [MRBP98], no single reliable multicast protocol can meet the needs of all applications. Therefore, the IETF expects to standardize a number of protocols that are tailored to application and network specific needs. This document concentrates on the requirements for "one-to-many bulk-data transfer", but in the future, additional Expires 15 December 1999 [Page 4]
Draft RMT Building Blocks 15 June 1999 protocols and building-blocks are expected that will address the needs of other types of applications, including "many-to-many" applications. Note that bulk-data transfer does not refer to the timeliness of the data, rather it states that there is a large amount of data transferred in a session. The scope and approach taken for the development of protocols for these additional scenarios will depend upon large part on the success of the "building-block" approach put forward in this document. 2.1. Building Blocks Advantages Building a large piece of software out of smaller modular components is a well understood technique of software engineering. Some of the advantages that can come from this include: o Software Reuse. Modules can be used in multiple protocols, which reduces the amount of development time required. o Reduced Complexity. To the extent that each module can be easily defined with a simple API, breaking a large protocol in to smaller pieces typically reduces the total complexity of the system. o Reduced Verification and Debugging Time. Reduced complexity results in reduced time to debug the modules. It is also usually faster to verify a set of smaller modules than a single larger module. o Easier Future Upgrades. There is still ongoing research in reliable multicast, and we expect the state of the art to continue to evolve. Building protocols with smaller modules allows them to be more easily upgraded to reflect future research. o Common Diagnostics. To the extent that multiple protocols share common packet headers, packet analyzers and other diagnostic tools can be built which work with multiple protocols. o Reduces Effort for New Protocols. As new application requirements drive the need for new standards, some existing modules may be reused in these protocols. o Parallelism of Development. If the APIs are defined clearly, the development of each module can proceed in parallel. Expires 15 December 1999 [Page 5]
Draft RMT Building Blocks 15 June 1999 2.2. Building Block Risks Like most software engineering, this technique of breaking down a protocol in to smaller components also brings tradeoffs. After a certain point, the disadvantages outweigh the advantages, and it is not worthwhile to further subdivide a problem. These risks include: o Delaying Development. Defining the API for how each two modules inter-operate takes time and effort. As the number of modules increases, the number of APIs can increase at more than a linear rate. The more tightly coupled and complex a component is, the more difficult it is to define a simple API, and the less opportunity there is for reuse. In particular, the problem of how to build and standardize fine grained building blocks for a transport protocol is a difficult one, and in some cases requires fundamental research. o Increased Complexity. If there are too many modules, the total complexity of the system actually increases, due to the preponderance of interfaces between modules. o Reduced Performance. Each extra API adds some level of processing overhead. If an API is inserted in to the "common case" of packet processing, this risks degrading total protocol performance. o Abandoning Prior Work. The development of robust transport protocols is a long and time intensive process, which is heavily dependent on feedback from real deployments. A great deal of work has been done over the past five years on components of protocols such as RMTP-II, SRM, and PGM. Attempting to dramatically re-engineer these components risks losing the benefit of this prior work. 2.3. Building Block Requirements Given these tradeoffs, we propose that a building block must meet the following requirements: o Wide Applicability. In order to have confidence that the component can be reused, it must be clear that the component can apply across the majority of the protocol classes. We note that the fourth class (with no back-channel) is fundamentally different than the first three, and so may be less amenable to building blocks. Expires 15 December 1999 [Page 6]
Draft RMT Building Blocks 15 June 1999 o Simplicity. In order to have confidence that the specification of the component APIs will not dramatically slow down the standards process, APIs must be simple and straight forward to define. No new fundamental research should be done in defining these APIs. o Performance. To the extent possible, the building blocks should attempt to avoid breaking up the "fast track", or common case packet processing. 3. Protocol Components This section proposes a functional decomposition of RM bulk-data protocols from the perspective of the functional components provided to an application by a transport protocol. It also covers some components that while not necessarily part of the transport protocol, are directly impacted by the specific requirements of a reliable multicast transport. The next section then specifies recommended building blocks that can implement these components. Although this list tries to cover all the most common transport-related needs of one-to-many bulk-data transfer applications, new application requirements may arise during the process of standardization, hence this list must not be interpreted as a statement of what the transport layer should provide and what it should not. Nevertheless, it must be pointed out that some functional components have been deliberately omitted since they have been deemed irrelevant to the type of application considered (i.e. one-to-many bulk-data transfer). Among these are advanced message ordering (i.e. those which cannot be implemented through a simple sequence number) and atomic delivery. It is also worth mentioning that some of the functional components listed below may be required by other functional components and not directly by the application (e.g. membership knowledge is usually required to implement ACK-based reliability). The following list covers various transport functional components and splits them in sub-components. o Data Reliability | | - Loss Detection/Notification | - Loss Recovery | - Loss Protection Expires 15 December 1999 [Page 7]
Draft RMT Building Blocks 15 June 1999 o Congestion Control | | - Congestion Feedback | - Rate Regulation | - Receiver Controls o Security o Group membership | | - Membership Notification | - Membership Management o Session Management | | - Group Membership Tracking | - Session Advertisement | - Session Start/Stop | - Session Configuration/Monitoring o Tree Configuration Note that not all components are required by all protocols. In particular, the fourth class of protocols defined above does not require many of these functions, including loss notification, loss recovery, and group membership. 3.1. Sub-Components Definition Loss Detection/Notification. This includes how missing packets are detected during transmission and how knowledge of these events are propagated to one or more agents which are designated to recover from the transmission error. This task raises major scalability issues and can led to feedback implosion if not properly handled. Mechanisms based on HACKs (hierarchical positive acknowledgements) or NAKs (negative acknowledgements) are the most widely used to perform this function. Mechanisms based on a combination of HACKs and NAKs are also possible. Loss Recovery. This function responds to loss notification events through the transmission of additional packets, either in the form of copies of those packets lost or in the form of FEC parity packets. The manner in which this function is implemented can significantly affect the scalability of a protocol. Loss Protection. This function attempts to eliminate packet-losses so that they don't become Loss Notification events. This function can be realized through the pro-active transmission of additional FEC packets. Expires 15 December 1999 [Page 8]
Draft RMT Building Blocks 15 June 1999 Each additional FEC packet is redundantly constructed from multiple data packets, a fact that allows a receiver to recover from some packet loss without further retransmissions. The number of losses that can be recovered from without requiring retransmission depends on the amount of FEC provided in the first place. Loss protection can also be pushed to the extreme when reliability is achieved without any Loss Detection/Notification and Loss Recovery functionality, as in the fourth class of open loop protocols defined above. Congestion Feedback. For sender driven congestion control protocols, the receiver must provide some type of feedback on congestion to the sender. This typically involves loss rate and round trip time measurements. Rate Regulation. Given the congestion feedback, the sender then must adjust its rate in a way that is fair to the network. One proposal that defines this notion of fairness and other congestion control requirements is [Whetten99]. Receiver Controls. In order to avoid allowing an extremely slow receiver to stop all progress, a congestion control algorithm will often involve having receivers leave groups in this case. For multi-layered schemes, the receivers may choose which layers of data they subscribe to. Security. Security for reliable Multicast contains a number of complex and tricky issues that stem in large part from the IP multicast service model. In this service model, hosts do not send traffic to another host, but instead elect to receive traffic from a multicast group. This means that any host may join a group and receive its traffic. Conversely, hosts may also leave a group at any time. Therefore, the protocol must address how it impacts the following security issues: o sender authentication (since any host can send to a group), o data encryption (since any host can join a group) o denial of service attacks (through corruption of transport state, or requests for unauthorized resources) o group key management (since hosts may join and leave a group at any time) [WHA98] Expires 15 December 1999 [Page 9]
Draft RMT Building Blocks 15 June 1999 In particular, a transport protocol needs to pay particular attention to how it protects itself from denial of service attacks, through mechanisms such as lightweight authentication of control packets. [HW99] Data Authentication and Encryption. While data authentication and encryption is not typically part of the transport layer per se, a protocol needs to understand what ramifications it has on data security, and may need to have special interfaces to the security layer in order to accommodate these ramifications. Transport Protection. The primary security task for a transport layer is that of protecting the transport layer itself from attack. The most important function for this is typically lightweight authentication of control packets in order to prevent corruption of state and other denial of service attacks. Membership Notification. This is the function through which the data source--or upper level agent in a possible hierarchical organization-- learns about the identity and/or number of receivers or lower level agents. To be scaleable, this typically will not provide total knowledge of the identity of each receiver. Membership Management. This implements the mechanisms for members to join and leave the group, to accept/refuse new members, or to terminate the membership of existing members. Group Membership Tracking. As an optional feature, a protocol may interface with a component which tracks the identity of each receiver in a large group. If so, this feature will typically be implemented out of band, and may be implemented by an upper level protocol. Session Advertisement. This publishes the session name/contents and the parameters needed for its reception. This function is usually performed by an upper layer protocol (e.g. [HPW99] and [HJ98]). Session Start/Stop. These functions determine the start/stop time of sender and/or receivers. In many cases this is implicit or performed by an upper level application or protocol. In some protocols, however, this is a task best performed by the transport layer due to scalability requirements. As an example, in the case of the "data fountain" approach, where receivers can complete their reception by tuning in asynchronously and leaving the group when done, the source must be notified when it can stop transmitting because there are no receivers tuned. Expires 15 December 1999 [Page 10]
Draft RMT Building Blocks 15 June 1999 Session Configuration/Monitoring. Due to the potentially far reaching scope of a multicast session, it is particularly important for a protocol to include tools for configuring and monitoring the protocols operation. Tree Configuration. For protocols which include hierarchical elements (such as PGM and RMTP-II), it is important to configure these elements in a way that has approximate congruence with the multicast routing topology. While tree configuration could be included as part of the session configuration tools, it is clearly better if this configuration can be made automatic. 4. Building Block Recommendations The families of protocols introduced in section 1.1 generally use different mechanisms to implement the protocol functional components described in section 3. This section tries to group these mechanisms in macro components that define protocol building blocks. A building block is defined as "a logical protocol component that results in explicit APIs for use by other building blocks or by the protocol client." Building blocks are generally specified in terms of the set of algorithms and packet formats that implement protocol functional components. A building block may also have API's through which it communicates to applications and/or other building blocks. Most building blocks should also have a management API, through which it communicates to SNMP and/or other management protocols. In the following section we will list a number of building blocks which, at this stage, seem to cover most of the functional components needed to implement the protocol families presented in section 1.1. Nevertheless this list represent the "best current guess", and as such it is not meant to be exhaustive. The actual building block decomposition, i.e. the division of functional components into building blocks, may also have to be revised in the future. 4.1. NAK-based Reliability This building block defines NAK-based loss detection/notification and recovery. The major issues it addresses are implosion prevention (suppression) and NAK semantics (i.e. how packets to be retransmitted should be specified, both in the case of selective and FEC loss repair). Expires 15 December 1999 [Page 11]
Draft RMT Building Blocks 15 June 1999 Suppression mechanisms to be considered are: o Multicast NAKs o Unicast NAKs and Multicast confirmation These suppression mechanisms primarily need to both minimize delay while also minimizing redundant messages. They may also need to have special weighting to work with Congestion Feedback. 4.2. FEC Repair This building block is concerned with packet level FEC repair. It specifies the FEC codec selection and the FEC packet naming (indexing) for both on-demand FEC and pro-active FEC. 4.3. Congestion Control There will likely be multiple versions of this building block, corresponding to different design policies in addressing congestion control. Two main approaches are considered for the time being: a source-based rate regulation with a single rate provided to all the receivers in the session, and a multiple rate receiver-driven approach based on layered transmission. Both approaches are still in the phase of study, however the first seems to be mature enough [HFW99] to allow the standardization process to begin. At the time of writing this document, a third class of congestion control algorithm based on router support is beginning to emerge in the IRTF RMRG. This work may lead to the future standardization of one or more additional building blocks for congestion control. 4.4. Generic Router Support The task of designing RM protocols can be made much easier by the presence of some specific support in routers. In some application- specific cases, the increased benefits afforded by the addition of special router support can justify the resulting additional complexity and expense [FLST98]. Expires 15 December 1999 [Page 12]
Draft RMT Building Blocks 15 June 1999 Functional components which can take advantage of router support include feedback aggregation/suppression (both for loss notification and congestion control) and constrained retransmission of repair packets. The process of designing and deploying these mechanisms inside router can be much slower than the one required for end-host protocol mechanisms. Therefore, it would be highly advantageous to define these mechanisms in a generic way that multiple protocols can use if it is available, but do not necessarily need to depend on. This component has two halves, a signaling protocol and actual router algorithms. The signaling protocol allows the transport protocol to request from the router the functions that it wishes to perform, and the router algorithms actually perform these functions. It is more urgent to define the signaling protocol, since it will likely impact the common case protocol headers. An important component of the signaling protocol is some level of commonality between the packet headers of multiple protocols, which allows the router to recognize and interpret the headers. 4.5. Tree Configuration It has been shown that the scalability of RM protocols can be greatly enhanced by the insertion of some kind of retransmission or feedback aggregation agents between the source and receivers. These agents are then used to form a tree with the source at (or near) the root, the receivers at the leaves of the tree, and the aggregation/local repair nodes in the middle. The internal nodes can either be dedicated software for this task, or they may be receivers that are performing dual duty. The effectiveness of these agents to assist in the delivery of data is highly dependent upon on how well the logical tree they use to communicate matches the underlying routing topology. The purpose of this building block would be to construct and manage the logical tree connecting the agents. Ideally, this building block would perform these functions in a manner that adapts to changes in session membership, routing topology, and network availability. Expires 15 December 1999 [Page 13]
Draft RMT Building Blocks 15 June 1999 4.6. Security At the time of writing, the security issues are the subject of research within the IRTF Secure Multicast Group (SMuG). Solutions for these requirements will be standardized within the IETF when ready. 4.7. Common Headers As pointed out in the generic router support section, it is important to have some level of commonality across packet headers. It may also be useful to have common data header formats for other reasons. This building block would consist of recommendations on fields in their packet headers that protocols should make common across themselves. 4.8. Protocol Cores The above building blocks consist of the functional components listed in section 3 that appear to meet the requirements for being implemented as building blocks presented in section 2. The other functions from section 3, which are not covered above, should be implemented as part of "protocol cores", specific to each protocol standardized. 5. Conclusions In this document, we briefly described a number of building blocks that may be used for the generation of reliable multicast protocols to be used in the application space of one-to-many reliable bulk-data transfer. The list of building blocks presented was derived from considering the functions that a protocol in this space must perform and how these functions should be grouped. This list is not intended to be all-inclusive but instead to act as guide as to which building blocks are considered during the standardization process within the Reliable Multicast Transport WG. Expires 15 December 1999 [Page 14]
Draft RMT Building Blocks 15 June 1999 6. Acknowledgements This document represents an overview of a number of building blocks for one to many bulk data transfer that may be ready for standardization within the RMT working group. The ideas presented are not those of the authors, they are a summarization of many years of research into multicast transport combined with the varied presentations and discussions in the IRTF Reliable Multicast Research Group. Although they are too numerous to list here, we thank everyone who has participated in these discussions for their contributions. 7. References [FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing," Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356. [FLST98] D. Farinacci, A. Lin, T. Speakman, and A. Tweedly, "PGM reliable transport protocol specification," Internet Draft, Internet Engineering Task Force, Aug. 1998. Work in progress. [HFW99] M. Handley, S. Floyd, B. Whetten, "Strawman Specification for TCP Friendly (Reliable) Multicast Congestion Control (TFMCC)," work in progress. [HJ98] M. Handley, V. Jacobson, "SDP: Session Description Protocol," RFC2327, April 1998. [HPW99] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol," Internet Draft, work in progress, June 1999. [HW99] T. Hardjorno, B. Whetten, "Security Requirements for RMTP-II," Internet Draft, work in progress, June 1999. [HWKFV99] M. Handley, B.Whetten, R. Kermode, S.Floyd, and L. Vicisano, "The Reliable Multicast Design Space for Bulk Data Transfer," Internet Draft, Internet Engineering Task Force, June 1999. Expires 15 December 1999 [Page 15]
Draft RMT Building Blocks 15 June 1999 [KCW98] M. Kadansky, D. Chiu, and J. Wesley, `"Tree-based reliable multicast (TRAM),'" Internet Draft, Internet Engineering Task Force, Nov. 1998. Work in progress. [Kermode98] R. Kermode, "Scoped Hybrid Automatic Repeat Request with Forward Error Correction," Proc ACM SIGCOMM 98, Sept 1998. [LDW98] M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed Error Recovery for Multimedia Streams in Wide-Area Multicast Networks" [LESZ97] C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local Error Recovery in SRM: Comparison of Two Approaches," USC Technical Report 97- 648, Jan 1997. [LG97] B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving Internet Multicast Routing with Routing Labels," IEEE International Conference on Network Protocols (ICNP-97), Oct 28-31, 1997, p.241-250. [LP96] K. Lin and S. Paul. "RMTP: A Reliable Multicast Transport Protocol," IEEE INFOCOMM 1996, March 1996, pp. 1414-1424. [MA99] J. Macker, B. Adamson. "Multicast Dissemination Protocol version 2 (MDPv2)," work in progress, http://manimac.itd.nrl.navy.mil/MDP. [MRBP98] A. Mankin, A. Romanow, S.Brander, V.Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols," RFC2357, June 1998. [OXB99] O. Ozkasap, Z. Xiao, K. Birman. "Scalability of Two Reliable Multicast Protocols," Work in progress, May 1999. [PSLB97] "Reliable Multicast Transport Protocol (RMTP)," S. Paul, K. K. Sabnani, J. C. Lin, and S. Bhattacharyya, IEEE Journal on Selected Areas in Communications, Vol. 15, No. 3, April 1997. Expires 15 December 1999 [Page 16]
Draft RMT Building Blocks 15 June 1999 [RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast Data Distribution Protocol Based on Software FEC Techniques," Proc. of The Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems (HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25, 1997. [WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N. Rastogi, J. Conlan, and T. Yeh, "THE RMTP-II PROTOCOL," Internet Draft, Internet Engineering Task Force, Apr. 1998. Work in progress [WHA98] D. Wallner, E. Hardler, R. Agee, `"Key Management for Multicast: Issues and Architectures," Internet Draft, work in progress, Sept 1998. [Whetten99] B. Whetten, "A Proposal for Reliable Multicast Congestion Control Requirements," work in progress. http://www.talarian.com/rmtp- ii/overview.htm 8. Authors' Addresses Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA whetten@talarian.com Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA lorenzo@cisco.com Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia. Roger.Kermode@motorola.com Expires 15 December 1999 [Page 17]
Draft RMT Building Blocks 15 June 1999 Mark Handley, Sally Floyd ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA mjh@aciri.org, floyd@aciri.org 9. Full Copyright Statement Copyright (C) The Internet Society (1998). 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 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." Expires 15 December 1999 [Page 18]
Draft RMT Building Blocks 15 June 1999 Table of Contents 1 Introduction .................................................... 2 1.1 Protocol Families ............................................. 4 2 Building Blocks Rationale ....................................... 4 2.1 Building Blocks Advantages .................................... 5 2.2 Building Block Risks .......................................... 6 2.3 Building Block Requirements ................................... 6 3 Protocol Components ............................................. 7 3.1 Sub-Components Definition ..................................... 8 4 Building Block Recommendations .................................. 11 4.1 NAK-based Reliability ......................................... 11 4.2 FEC Repair .................................................... 12 4.3 Congestion Control ............................................ 12 4.4 Generic Router Support ........................................ 12 4.5 Tree Configuration ............................................ 13 4.6 Security ...................................................... 14 4.7 Common Headers ................................................ 14 4.8 Protocol Cores ................................................ 14 5 Conclusions ..................................................... 14 6 Acknowledgements ................................................ 15 7 References ...................................................... 15 8 Authors' Addresses .............................................. 17 9 Full Copyright Statement ........................................ 18 Expires 15 December 1999 [Page 19]
