Internetworking Over NBMA Yasser Seif INTERNET-DRAFT Hani Harb Expires Mars 1999 Multicast Manager (MCM): A Multipoint-to-Multipoint Multicasting Protocol for ATM Status of this Memo This document is an Internet-Draft. 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. Internet-Drafts are draft documents 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 ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes MCM, a protocol for controlling a shared ATM multicast tree supporting Mutipoint-to-Multipoint communication. The protocol guarantees that there is no cell interleaving at any group receiver. No cell buffering inside the network is required, and all cell forwarding is performed at the ATM layer. 1. Introduction Multicasting is the process whereby a source host or protocol entity sends a packet to multiple destinations simultaneously using a single, local ‘transmit’ operation. Unicasting and Broadcasting may be considered to be special cases of Multicasting (with the packet delivered to one destination, or ‘all’ destinations, respectively). Asynchronous Transfer Mode (ATM) is a connection-oriented non- broadcast multiple access (NBMA) technology which is increasingly being used for local and wide area networking. A Virtual Circuit (VC) has to be established between participating hosts on an ATM network before transfer of data can take place. Unicast communication is over a point-to-point (unidirectional or bidirectional) VC. The ATM Forum’s signalling specifications UNI 3.0/3.1 do not provide the multicast address abstraction. Multicatsing is supported through point-to-multipoint unidirectional VCs. The key limitation is that the sender must have prior knowledge of each intended recipient, and explicitly establish a VC with itself as the root node and the recipients as the leaf nodes. The absence of ATM multicast address presents a problem of mapping a layer 3 multicast address to the corresponding set of ATM addresses. The ATM working group of the Internet Engineering Task Force (IETF) has proposed the Multicast Address Resolution Server (MARS) protocol as a solution to this problem [1]. The fundamental limitations of the MARS are: 0 Only point-to-multipoint, unidirectional VCs may be established. 0 Only the root (source) node of a given VC may add or remove leaf nodes. 0 The source or server needs to know which receivers are listening to which multicast group. This incurs a management overhead leading to scalability problems for very large multicast groups. One of the main problems to be solved is the cell interleaving problem which is defined as the ability of the receiver in a multicast group to distinguish cells coming from different concurrent senders. Potential solutions to the cell interleaving problem with AAL5 have been discussed in [8]. 2. The Research Motivations The fundamental goal of our proposal is to have a single shared tree between all senders and receivers of a group. A shared tree architecture offers an improvement in scalability over source based tree architectures by a factor of number of active sources. Other advantages may be gained by using a single shared tree as has been discussed in [5,9]. First, Group membership changes decrease the generated level of signaling load. This is especially beneficial for large groups with several senders, when the group is highly dynamic, or when the links between the switch and the cluster members are error-prone. This allows group of members to be temporarily dropped from the multicast group. Second, more than one group of members may be added in one step, initiated by the core. In contrast, a scheme using per-sender trees can not permit this where either each sender has to setup a tree to all the receivers, which means that the set of receivers has to be communicated with the senders, or the receivers join the sender tree of all the senders, which means that, in turn, the receivers need to know the set of senders. This gives us better performance due to rapid setup of centrally controlled groups. Third, Using a single shared tree results in allocating a single VC per link for the entire group. This results in “traffic concentration”, which is an advantage in terms of manageability. The major disadvantage of shared tree is the delays that are potentially higher than in the case of shortest-path sender-based trees. 3. Overview of the MCM scheme The core concept in MCM is introduced as the concept of the ‘core’ in CBT [2,3], where is defined as the root of the tree to be set up. The core does not have to know the leaf nodes of the tree, but it must keep track of current senders (senders that actually have data to send at current time). The core does not work as a Multicast Server (MCS), where each sender must forward its packets to the server, and the server, in turn, reforwards it to the group members. But, the core acts a manager that controls the multiaccess to the shared tree and the core also schedules among senders when several senders simultaneously request access to the shared tree. No extra buffering is needed in the ATM switch as proposed by SEAM architecture [6,7]. 4. MCM Proposal This section discusses the proposed scheme while a detailed architecture and protocol specification is delayed to published in next paper. 4.1. MCM Control Messages The MCM defines may control messages as it follows. 0 MCM_REQUEST: sent by a member of the multicasting group to the core to request the access to the shared tree. The core then appends this member to the sender’s list. 0 MCM_SEND_ALL: sent by the core to specified member granting it an absolute access to the shared tree, so allowing this member to transmit all of its data packets over the shared tree. 0 MCM_SEND: sent by the core to specified member allowing it to transmit only a single packet over the shared tree. 0 MCM_PAUSE: sent by the core to the current sender (a member that currently has the right to access the multicast tree) forcing this sender to stop forwarding its data after completing the current packet. 0 MCM_ACK: sent by the current sender to the core to notify the core that it has completed forwarding a data packet. The core then transmits the access to the shared tree to another sender. 0 MCM_EOD: sent by the current sender to the core to notify the core that it has no more data to transmit over the shared tree. The core then removes that sender from its sender’s list. 4.2. Data Forwarding When a member of the multicasting group (S1) has data packets to transmit over the shared tree, this member first establishes a point-to-point bidirectional VC (if it does not exist) with the core to be used as a control VC that enables both the member and the core to exchange the MCM control messages. This implies that all the group members must have a previous knowledge of the ATM address of the core of their group. After establishing that VC, the member transmits a MCM_REQUEST message to the core through that VC. The core responds to this request by adding this sender to the sender’s list (a simple list that enables the core to keep track of the whole senders that currently requested access to the shared tree). Assume that the sender’s list contains only the sender (S1), so the core attempts to transmit a MCM_SEND_ALL message to (S1) through the established VC. Upon receiving the MCM_SEND_ALL, (S1) attempts to transmit all its data packets through the shared tree. (S1) keeps the access to the shared tree until there is no packets to transmit, at this time (S1) sends MCM_EOD message to the core to be removed from the senders list. (S1) may also set up an idle timer to release the point-to-point VC established with the core if not used for a configurable period of time. If another member (S2) has data packets to transmit over the shared tree, it also establishes its own point-to-point VC with the core, and then it sends a MCM_REQUEST message to the core. The core then appends (S2) to the sender’s list and starts a scheduling procedure between the current senders (S1, S2 in this case). Assuming, S2 is given the privilege according the applied priority-based scheduling policy, S2 gets the access to send all its data packets as long as there is no higher priority member requesting sending. If S1 and S2 have the same priority, they alternate sending their data packets. If this is the case, the core sends MCM_PAUSE message to (S1). Upon receiving the pause message, (S1) completes sending the current packet, stops forwarding more packets and sends a MCM_ACK message to the core. The core then sends a MCM_SEND message to (S2). (S2) now gains the access to the shared tree and starts forwarding a single data packet then transmits a MCM_ACK message to the core. The core gives the access to (S1) by sending MCM_SEND to (S1), which, in turn, transmits a single packet over the shared tree followed by a MCM_ACK on the control VC to the core, and so on. 4.3 Scheduling among multiple senders In MCM the core keeps track of all senders that have requested the access to the shared tree. The core schedules among multiple senders in a round robin basis allowing each sender to transmit only a single data packet. Priority system may be applied where a priority value may be assigned to each member when it is joined a group. A member requesting access to the shared tree has to pass this value to the core within the MCM_REQUEST message. The core can also allow a sender to transmit more than one packet by including the number of packets that the sender will transmit in the MCM_SEND message. 5. Conclusion and Future Work A new scheme was proposed, Multicast Manager (MCM), which manages the multi-access to the shared multicast tree. MCM guarantees that only one sender is allowed to transmit its data packets over the shared tree at a time, and thus it performs a very simple traffic management function. MCM also prohibits cell interleaving at any receiver. MCM schedules among several group senders in a data packet basis. A complete architecture of MCM will is the target of our current work. 6. References [1] G. Armitage. Support for multicast over UNI 3.0/3.1 based ATM networks. Request for Comments 2022, November 1996. [2] A. Ballardie. Core Based Trees (CBT) Multicast Routing Architecture. Request for Comments 2201, September 1997. [3] A. Ballardie. Core Based Trees (CBT version 2) Multicast Routing; Protocol Specification. Request for Comments 2189, September 1997. [4] ATM User Network Interface (UNI) Signalling Specification Version 4.0. ATM Forum Specifications /af-sig-0061.000, ATM Forum, July 1996. [5] ATM Forum. ATM User-Network Interface Specification Version 3.0. Englewood Cliffs, NJ: Prentice Hall, September 1993. [6] M. Grossglauser and K. K. Ramakrishnan, SEAM: Scalable and Efficient ATM Multipoint-to-Multipoint Communication [Extended Abstract], Proc. 6h Intl. Workshop on Network and Operating System Support (NOSSDAV '96), Zushi, Japan, April 1996. [7] M. Grossglauser and K. K. Ramakrishnan, SEAM: Architecture for Scalable and Efficient ATM Multipoint-to-Multipoint Communication, 15th International Teletraffic Congress (ITC), Washington DC, USA, June 1997. [8] Sonia Fahmy, Raj Jain, Shivkumar Kalyanaraman, Rohit Goyal, Bobby Vandalore and Xiangrong Cai, ``A Survey of Protocols and Open Issues in ATM Multipoint Communications", OSU Technical Report, August 21, 1997, http://www.cis.ohio-state.edu / ~jain /papers /mcast.htm". [9] Talpade, R., Ammar, M. H., Multicast Server Architectures for Supporting IP Multicast over ATM, in Proceedings of the 7th IFIP Conference on High Performance Networking, April 1997. Authors' Information: Yasser Seif Systems & Computer Dept. Al-AZHAR UNIVERSITY NASR CITY CAIRO E-MAIL: yasser_seif@usa.net FAX: 00202-2432066 Prof. Hani Harb Systems & Computer Dept. Al-AZHAR UNIVERSITY CAIRO E-MAIL: harb@frcu.eun.eg Expires Mars 1999