Robert E. Braudes and Steve Zabele. Requirements for multicast protocols. IETF Request for Comments (RFC 1458), May 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....difficult to implement, and is suitable for ATM networks. The non optimality of routing in this approach is not a major issue when there is a large number of flows present. In addition, this approach represents a fairly simple mechanism of managing multicast data distribution trees [11] Refer to [9] for more information on the requirements for multicast protocols, including routing protocols, and group address and membership authority [9] 3 Current ATM Multipoint Services and IP Multicast over ATM ATM multiway communication has been studied at the ATM Forum multiway BOF (birds of a ....

....large number of flows present. In addition, this approach represents a fairly simple mechanism of managing multicast data distribution trees [11] Refer to [9] for more information on the requirements for multicast protocols, including routing protocols, and group address and membership authority [9]. 3 Current ATM Multipoint Services and IP Multicast over ATM ATM multiway communication has been studied at the ATM Forum multiway BOF (birds of a feather) and at the International Telecommunications Union (ITU) study groups 11 and 13 [37] The Internet Engineering Task Force (IETF) has also ....

[Article contains additional citation context not shown here]

R. Braudes and S. Zabele. Requirements for multicast protocols. IETF RFC 1458, May 1993.

....for error control in multicast connections. This protocol combines the main features from the above protocols; ST II [20] and RSVP [22] allow quality of service parameters negotiation through resource reservation mechanisms; MTP [2] token based point to multipoint protocol; RAMP [4]: provides different levels of QOS according to the desired level of reliability. Although these protocols try to achieve high performance by simplifying their processing overhead, each one has its specific characteristics, which make them best suited for a particular class of applications. ....

R. Braudes and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, Network Information Center, SRI International, May 1993.

....SRM[ 10] RMTP[ 11 ] TMTP[ 12] and PGM[ 13] are all receiver initiated protocols that build relaibility on top of a best effort service. Further classification of reliable multicasting schemes is based upon the method used to recover from packet losses [14] Some protocols, for instance RAMP [25], use centralized error recovery, also known as source based recovery, in which missing data is recovered exclusively from the original source. Others, like RMTP and LBRM[26] use distributed error recovery and may provide retransmissions from nodes other than the original source. Such schemes may ....

....require larger Proactive Window sizes. N=O N=4 Figure 23 Performance of the Proactive Window in presence of loss bursts Appendix E. List of Selected Reliable Multicast Protocols . m m XTP Xpress Transport Protocol 1987 IFIP 89 [8] RAMP Reliable Adaptive Multicast Protocol 1993 RFC1458 [25] RMP Reliable Multicast Protocol 1994 [20] SRM Scalable Reliable Multicast 1995 Sigcomm 95 [10] RMTP Reliable Multicast Transport Protocol 1995 Infocom 96 [11 ] TMTP Tree based Multicast Transport Protocol 1995 ACM Mltmd 95 [ 12] LBRM Log Based receiver Reliable Multicast 1995 Sigcomm 95 ....

R. Braudes and S. Zabele, Requirements for Multicast Protocols (RAMP), RFC-1458, IETF, May 1993.

....even small amounts of packet loss can be perceptible to the human ear [DeLW94] We will show in Sections 4 and 5 that retransmissions are both practical and useful for real time media. 3 Overview of Literature As in many light weight transport protocols for high speed networks, ARMS92] and [BRAU93] propose a NACK only, block basis scheme, to improve data throughput. Our own preference, for reasons that are elaborated in the next section, is towards such a scheme with one qualification: the block sizes cannot be too large, as this will lead to long delays. Again as in most high speed ....

....whereby only one host may transmit at a given time. This is not practical for applications such as videoconferencing, where all hosts need to transmit simultaneously. CrPa88] has a feature where a list of those hosts required to acknowledge packets is sent in the multicast packet. In both [BRAU93] and [CrPa88] the authors propose a threshold based scheme for retransmissions in order to achieve a compromise between unicast (which is time consuming and reduces source throughput) and multicast (which unnecessarily increases load on those networks with no packet loss) The threshold is based ....

[Article contains additional citation context not shown here]

R. Braudes and S. Zabele, "Requirements for Multicast Protocols," RFC 1458, TASC, Reading, MA, May 1993.

....name a few examples, SRM[10] RMTP, TMTP and PGM are all receiver initiated protocols that build relaibility on top of a best effort service. Further classification of reliable multicasting schemes is based upon the method used to recover from packet losses [14] Some protocols, for instance RAMP [25], use centralized error recovery, also known as source based recovery, in which missing data is recovered exclusively from the original source. Others, like RMTP and LBRM, use distributed errorrecovery and may provide retransmissions from nodes other than the original source. Such schemes may ....

R. Braudes and S. Zabele, Requirements for Multicast Protocols (RAMP), RFC-1458, IETF, May 1993.

....Distributed Interactive Simulation Intranet Using RAMP, a Reliable Adaptive Multicast Protocol W. Garth Smith (wgsmith tasc.com) Alex Koifman (akoifman tasc.com) TASC, Inc. 55 Walkers Brook Drive Reading, MA 01830 Abstract A dynamic, heterogeneous, multicast environment has been fielded as a simulation Intranet over a wide area network (WAN) for distributed interactive simulation (DIS) By replacing the usual UDP based unreliable broadcast and TCP based reliable unicast mechanisms with a single ....

....transmission times for point to point communications from existing standards were compared to actual observed latency between network hosts. Initial benchmarks were determined from the Communication Architecture Requirements (CAS) document Standard for Distributed Interactive Simulation draft 1278.2 IEEE [2] which provides details of acceptable latencies for given types of simulations. This standard was recently balloted and is currently undergoing a number of modifications. The CAS document indicates that crewed simulators have minimal latency tolerances between 100 to 300 milliseconds ....

[Article contains additional citation context not shown here]

R. Braudes, S. Zabele, "Requirements for Multicast Protocols," RFC 1458 , May 1993.

....Each quality of service is realized as a separate layer where either the default or a customized implementation can be used. The TeCo3D prototype uses the default iBus implementation for reliable multicast, which relies on an algorithm similar to the Reliable Adaptive Multicast Protocol (RAMP) [3] to achieve reliability on top of IP multicast. The services of the iBus library are used by the TeCo3D communication component, which acts on behalf of the applet, exchanging events and files with peer communication components. The applet and communication component communicate via local socket ....

Braudes, R.; Zabele, S.: Requirements for Multicast Protocols, Network Working Group, Request for Comments 1458, May 1993. On-line: ftp://src.doc.ic.ac.uk/rfc/rfc1458.txt

....also calls for establishing subgroups, which is rather difficult in the current IP multicast environments. 3.3. A Critique of MTP As well as it works for the applications mentioned, MTP as defined in RFC 1301 still has some limitations. Some of these have been described in the literature [5], while others were identified in our work with Xy. Master concept The master function causes additional load on the machine on which it is being executed and its network connection, in particular membership management and token processing; every packet has to be processed by the master to ....

....every packet has to be processed by the master to update its view of the state of each producer. More significantly, the master also is a single point of failure. Missing address management The management of multicast group addresses is one of the less well understood issues in IP multicasting [5]. Unfortunately, the MTP specification is rather confused about various aspects of addressing; e.g. it specifies a single predefined IP multicast group to be used with all MTP multicast groups. Our MTP implementation uses the connection identifier fields of the MTP protocol as a crude mechanism ....

[Article contains additional citation context not shown here]

R. Braudes and S. Zabele, "Requirements for Multicast Protocols, " Internet RFC 1458, May 1993.

....have been carried out to explore how to support multicast in various networking environments. Especially, these include systems that use multicast to deliver data and multimedia traffic [1] 2] 3] Other systems support reliable and unreliable multicast over LANs [4] 5] 6] Internet [7] 8] [9] [10] 11] 12] 13] 14] 15] ATM [16] 17] and networks including mobile hosts [18] 19] 20] 21] 22] Multicast flow control is essential for high performance multicast applications. Mishra and Wu [23] studied several techniques of flow control for atomic multicast protocols by simulations. ....

R. Braudes and S. Zabele, "Requirements for multicast protocols," RFC 1458, TSAC, 1993.

....the acks from all its receivers it proceeds to send the ack to its higher level DR. This propagates up the hierarchy and the sender proceeds with its transmission. There are also mechanisms for late joining receiver and caching of data that is transmitted. Some more protocols are discussed in [1]. 2.6 Common characteristics of the protocols As seen above there are several multicast transport mechanisms that have been proposed. They provide support for a wide variety of applications ranging from real time 11 conferencing to multipoint data distribution. Earlier multicast mechanisms were ....

R. Braudes and S. Zabele. Requirements for multicast protocols. RFC 1458, May 1993.

....the different steps and definitions of QoS usage are explained. 3. 1 Architecture The architecture of GMS is similar to that of other directory services, in the sense that the GMS service is available through a GMS access protocol (GAP) which is used by GMS user agents (GUA) to access Zabele [9]. 6 GMS system agents (GSA) The GMS service is implemented by the GMS system protocol (GSP) which is used by GSAs to communicate with each other. The overall view of this architecture is shown in figure 4. In this figure, it can be seen that the connection to GMS (through the GUAs using GAP) ....

R. Braudes and S. Zabele. Requirements for Multicast Protocols. Internet RFC 1458, May 1993.

....sender to a group of nodes. For instance wb(white board) videoconferencing and traffic report dissemination are multicast applications [5] Most of them are realized by IP multicast. In IP multicast transmission of an IP datagram to a host group is identified by a single IP destination address[6] [7]. Based on communication requirement, they can be grouped into two criteria, real time application and reliable application. In real time application, voice and motion picture are transmitted under bounded delay constraint[8] If packet arrival rate at one of receivers exceeds its capability, ....

R.Braudes and S.Zabele,"Requirements for Multicast Protocols," RFC-1458 1993.

....One complication is that there is a fixed number of multicast addresses. Because most telecollaborations will be transient, address assignment and reassignment will be highly dynamic. A global scheme is required to avoid unwanted address collisions and to promote reasonable address space sharing [Pej94, Bra93, Sc92b], by partitioning the address space either randomly or among a hierarchy of multicast address servers. To off load dynamic addressing mechanisms, we can make use of fixed multicast addresses for static conferences, such as regularly held conferences or task force meetings, and use unicast ....

] R. Braudes, S. Zabele; Requirements for Multicast Protocols, RFC 1458, May 1993.

....acknowledgements and localize retransmissions at a subtree level. Node failure detection and isolation is essential to maintain multicast communications, specially for nodes that assume a particular role besides receiving multicast traffic. For example, the failure of the master node in MTP [BZ93] a domain manager node in TMTP [YGS95] or a designated receiver in [LP96] will terminate the multicast connection. Therefore, some protocols provide mechanisms to detect, isolate, and replace faulty nodes. A common mechanism for detecting node failure is a heartbeat. A heartbeat is an interval ....

....length of a heartbeat interval is impacted by the longest round trip delay of communicating nodes. Longer heartbeat intervals delay the availability of information while shorter heartbeat intervals incur higher bandwidth utilization and require more processing. Braudes and Zabele introduced in [BZ93] a Multicast Group Authority, MGA, that arranges nodes into a tree and requires a parent to poll its children for heartbeats to check their connectivity. The owner of the transmit token in the MTP protocol [AFM92] must transmit at least one message in every heartbeat or the master node assumes ....

[Article contains additional citation context not shown here]

R. Braudes and S. Zabele. "Requirements for Multicast Protocols ". Internet Request for Comment (RFC 1458), May 1993.

....is significantly simplified. Although there have been a number of proposals for multicast transport protocols such as XTP [1] MTP [2] RTP [19] and the simple and heavily used UDP they all assume that there exists some outside authority for allocating and managing multicast addresses [3] 2 . Currently, however, there is no mechanism for the management and dynamic allocation of multicast addresses (with the features described above) within the Internet, and hosts have to communicate all relevant communications parameters (such as multicast address and port numbers) a priori. ....

....Directory (SD) 3 multicast address allocation program that is widely used today follows this approach, but is not general enough to satisfy the requirements for a multicast address management mechanism, as is further discussed in Section IV C. Recently, a couple of schemes have been proposed [3], 10] In [3] an architecture has been introduced where multicast addresses are managed by a tree structured Multicast Group Authority (MGA) Such a scheme, however, suffers from large set up delay, and is not very robust. In [10] the multicast address space is partitioned according to ....

[Article contains additional citation context not shown here]

R. Braudes and S. Zabele. Requirements for Multicast Protocols. RFC 1458, TASC, Reading, MA, May 1993.

....costly. Thus, SRM is strongly focused on the specific environment it was designed for and on the kind of application it aims to support. Reference [20] describes the MTP protocol that has a feature where a list of hosts that require to acknowledge packets is sent in the multicast packet. In both [21] and [20] the authors propose a threshold based scheme for retransmissions in order to achieve a trade off between unicast (which is time consuming and reduces source throughput) and multicast (which unnecessarily increases load on those networks with no packet losses) The threshold is based on ....

R. Braudes and S. Zabele, "Requirements for Multicast Protocols," RFC 1458, May 1993.

No context found.

R. Braudes, S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.

No context found.

Robert E. Braudes and Steve Zabele. Requirements for multicast protocols. IETF Request for Comments (RFC 1458), May 1993.

No context found.

Braudes, R. and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.

No context found.

R. Braudes and S. Zabele, "Requirements for multicast protocols," TSAC, RFC 1458, 1993.

No context found.

R. Braudes, S. Zabele, "Requirements' for Multicast Protocols'", Internet Request for Comment 1458, May 1993.

No context found.

R. Braudes, S.Zabele. \Requirements for Multicast protocols". RFC1458, TASC, 1993.

No context found.

Braudes, R and S. Zabele, "Requirements for Multicast Protocols," RFC 1458, 5/93.

No context found.

R. Braudes and S. Zabele. Requirements for Multicast Protocols. RFC-1458, May 1993.

No context found.

Braudes, R and S. Zabele, "Requirements for Multicast Protocols," RFC 1458, 5/93.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC