G. J. Armitage, "Multicast and Multiprotocol support for ATM based Internets," ACM Sigcomm Computer Communication Review, vol. 25, April 1995.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....tree are CBT [5] and the sparse mode of PIM [6] In ATM, member initiated join and leave has been incorporated into ATM Forum UNI version 4.0 for point to multipoint communication. However, there has been no proposal for a convenient multipoint to multipoint communication mechanism. While MARS [7] uses a single tree spanning all receivers, rooted at a multicast server, senders have to create point to point (unicast) connections to the server, violating the network state scalability requirement above. Also, the server may be both a bottleneck (due to the necessity to perform ....

.... One way to circumvent this problem is by reassembling the packets, perform packet level scheduling, and re segment one packet after the other onto an outbound point to multipoint VC (or mesh of point topoint VCs) A multicast server typically used to do this function of reassembly and forwarding [7] makes for an obvious performance bottleneck and means that switches have to process packets. We show in this section that it is possible to achieve the same without reassembly and segmentation, by taking advantage of the fact that the AAL5 end of packet identifier is part of the ATM cell header. ....

G. J. Armitage, "Multicast and Multiprotocol support for ATM based Internets," ACM Sigcomm Computer Communication Review, vol. 25, April 1995.

....PIM [6] In ATM, member initiated joins and leaves have been incorporated into ATM Forum UNI version 4.0 for point to multipoint communication [2] However, there has been no proposal for a iconvenientj multipoint to multipoint communication mechanism. Using a multicast server (e.g. an option in [3]) results in a single tree spanning all receivers, rooted at the server. Senders have to create point to point (unicast) connections to the server, violating the network state requirement above. Also, the server is both a bottleneck (due to the necessity to perform reassembly segmentation in the ....

G. J. Armitage. Multicast and Multiprotocol support for ATM based Internets. ACM Sigcomm Computer Communication Review, 25(2), April 1995.

....up for multicasting IP data. The Internetworking over NBMA (ION, ION] working group (formerly known as the IP over ATM working group) of the Internet Engineering Task Force (IETF, IETF] has proposed the Multicast Address Resolution Server (MARS) protocol as a solution to this problem ( GA96] [GA95], GA97] The MARS server is used to maintain the mapping between IP multicast group addresses and the corresponding ATM addresses. Hosts in the ATM network use the MARS to resolve IP multicast addresses into corresponding lists of group members. The source has two options for multicasting data ....

Armitage, G.J., "Multicast and Multiprotocol Support for ATM based Internets", ACM Sigcomm Computer Communication Review, Vol.25, No.2, April 1995.

....the IETF and ATM Forum on specifying mechanisms for running IP and other network layer protocols over ATM. At the time of this writing, the ATM Forum s work on Multiprotocol over ATM is still under development. This approach and the technical challenges will be discussed in the article of Armitage [1] in this special issue. Another approach is the provision of an ATM protocol to emulate existing LAN services, allowing network layer protocols to operate as if they are still connected to a conventional LAN. The LAN emulation specification defines how an ATM network can emulate a sufficient set ....

G. J. Armitage. Multicast and Multiprotocol support for ATM based Internets. This Special Issue.

....out issues relevant to constructing the ack tree Supporting Reliable Concast with ATM Networks 18 and sending retransmissions. Multiplexing is not an issue for transmitting positive acknowledgments and repair requests. Mesh. As part of a IETF proposal for implementing IP over ATM, Armitage [1] suggests using multiple persource point to multipoint VCs in a mesh like structure (analogous to the DVMRP routing protocol for IP networks) There are a number of advantages to this approach. First, each per source tree is a shortest path to all receivers and therefore delay is at a minimum. ....

Armitage, G.J. Multicast and multiprotocol support for ATM based internets. In Computer Communication Review, April 1995, vol.25, (no.2):34-46.

....the recipients before establishing the connection. This does not make it straightforward to implement the same subscription based style of multicast service which can be supported LIS 1 LIS 2 Host 1 Host 2 Router Host 3 Host 4 Switching ATM Fabric Figure 4: Logical IP Subnets over IP Ethernet. In [1], Armitage suggests a workaround to allow IP multicast abilities over an ATM network. 4.1 IP over ATM The classical method for providing IP functionality on top of an ATM switching fabric is summarized in RFC 1577 [12] The general idea is to impose a virtual Ethernet like topology over the ATM ....

G. J. Armitage. Multicast and Multiprotocol support for ATM based Internets. ACM SIGCOMM Computer Communication Review, 25(2):34--46, April 1995.

....approach. These tree structures also present a very useful way to approach multipoint communication in ATM and it is worthwhile comparing this with other multipoint proposals involving ATM. In UNI 3.1 [ATM Forum94a] multipoint communication was limited to root initiated multicast trees. In [Armitage95] this UNI 3.1 capability was used to map IP multicasting onto ATM multicasting. The result was that either a multicast server was used, or a mesh of multicast trees had to be created. The OPENET architecture [Cidon95] proposes source and destination tree structures similar to those presented in ....

G.J. Armitage. Multicast and Multiprotocol support for ATM based Internets. Computer Communications Review, 25(2):34--46, April 1995. (p 137)

....for the ATM Forum s Multiprotocol BOF) 67] was a first attempt to reconcile the IETF s ATM multiprotocol developments with those of the ATM Forum, and perhaps the first IETF standard to deal with multicast in an IP ATM environment. In Multicast and Multiprotocol Support for ATM based Internets [6], Grenville Armitage has reviewed the multicast work being done in the IETF ION working group. There are at present two ways to implement multicast service over ATM ATM Multicast Servers (MCS) and ATM VC meshes. In the former, multicast packets are first sent to the server, and then are ....

Grenville J. Armitage. Multicast and multiprotocol support for ATM based internets. ACM SIGCOMM Computer Communications Review, 25(2):34-- 46, Apr 1995.

....messages should be confirmed, that is, they should be explicitly acknowledged by the router and retransmitted if an acknowledgment does not arrive before a timer expires. The join leave mechanism is similar to the proposal for tracking multicast group membership in the IP multicast over ATM case [11], although there connectivity between the multicast server and end hosts is over virtual circuits rather than physical PtP links, and the delivery mechanisms differ. The join leave mechanism is based on the observation that in PtP links the periodic queries result in end hosts sending repeatedly ....

G.J. Armitage, "Multicast and multiprotocol support for ATM based internets," Computer Communications Review, vol. 25, no. 2, pp. 34--46, April 1995.

....requirements. While the main purpose of the gather and distribution tree pairs introduced in Section IV was to illustrate the power of an SSCA, it is worthwhile comparing this with other approaches involving ATM. In UNI 3.1 [20] multicasting was limited to root initiated multicast trees. In [26], the UNI 3.1 facility was used to map IP multicasting onto ATM multicasting. The result was that either a multicast server was used, or a mesh of multicast trees were created. UNI 4.0 [21] extended multicast tree creation to also allow leaf initiated joins. Manuscript received 10 January 1997; ....

G.J. Armitage, "Multicast and Multiprotocol support for ATM based Internets," Computer Communications Review, vol. 25, no. 2, pp. 34--46, April 1995.

....re assembly of messages impossible. One solution is to use AAL3 4 and allocate multiplexing identifiers (MIDs) to sources, but this requires a coordinated distribution of MIDs and is usually made at the expense of generality. Various proposals exist to address this issue. One family of solutions [4, 5, 6, 7, 8] relies on the combination of servers and one to many connections. Data is sent by any end system to one server over a point to point connection; the server relays the data back to endsystems, and to other servers, over a one to many connection for which it is the root. Cell interleaving is ....

G. J. Armitage, "Multicast and Multiprotocol Support for ATM based Internets," ACM Sigcomm Computer Communication Review, Apr. 1995.

No context found.

G.J. Armitage, "Multicast and Multiprotocol Support for ATM based Internets" ACM SIGCOMM Computer Communication Review

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