Internet-Draft Grenville Armitage Bellcore November 3rd, 1994 Multicast Servers in an RFC 1577 Environment. Status of this Memo This document was submitted to the IETF IP over ATM WG. Publication of this document does not imply acceptance by the IP over ATM WG of any ideas expressed within. Comments should be submitted to the ip- atm@matmos.hpl.hp.com mailing list. Distribution of this memo is unlimited. This memo 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract In some environments the consumption of reassembly contexts and VC space may be too high for all Class D groups to use full VC meshes as described in Internet Draft draft-armitage-ipatm-ipmc-02.txt ("IP Multicast over UNI 3.0 based ATM Networks"). This memo explores possible ways of sharing the load between Multicast Servers and full VC meshes in an RFC 1577/UNI3.0 environment. 1. Hidden Multicast Servers. In some environments the consumption of reassembly contexts and VC space may be too high for all Class D groups to use full VC meshes. Using multicast servers has been proposed as a solution in these cases. It is possible to modify draft-armitage-ipatm-ipmc-02.txt to Armitage Expires May 3rd, 1995 [Page 1] Internet Draft November 3rd, 1994 support the construction of a hybrid, where some Class D groups are based on a mesh of VCs between the participating hosts, and other Class D groups are supported through a separate node acting as a multicast server. The key is to enable administrative modification of the ARP Server's behaviour on a per-Class D address basis. To simplify initial introduction of this idea, manual configuration will be assumed. Assume the following model of a multicast server: It is a client of an LLC entity on an addressable ATM node that LIS members may establish VCs to. It joins the 224.0.0.1 group, so the ARP Server keeps it informed of ARP_MCJOIN and ARP_MCLEAVE traffic. From this information it tracks the membership of the group is configured to serve. It establishes and manages a point to point VCs to all members of the group it is configured to serve. When LLC/SNAP encapsulated IP packets arrive from individual hosts they are retransmitted on each of the server's outgoing point to point VCs, thus reaching all other members in the group. The server retains enough information about the VCs it terminates and originates so that it can refrain from sending incoming packets back to their source host. To make this scheme work both the ARP Server and ARP client side behaviour must be varied a little from the pure VC mesh environment. The first variation is to the ARP Server's behaviour when resolving requests for a Class D address that it knows there is a multicast server for. ARP Server is configured with ATM address of multicast server and the Class D address of the group it is to serve. ARP Server tracks and propogates ARP_MCJOIN and ARP_MCLEAVE messages as previously defined. The ARP Server checks the source ATM address of incoming ARP_REQUESTs to distinguish between LIS hosts and the multicast server. When a LIS host ARP_REQUESTs for a multicast server's Class D address it gets back a conventional ARP_REPLY message containing the multicast server's ATM address. Armitage Expires May 3rd, 1995 [Page 2] Internet Draft November 3rd, 1994 When the multicast server ARP_REQUESTs for the Class D address it supports, it gets back the ARP_MULTI response sequence containing all the LIS hosts that have joined the group. The hosts must be fooled into thinking that only one leaf node (the multicast server itself) needs to be added to the multicast VC they establish when transmitting to a group served by a multicast server. If an ARP_REPLY is returned in response to an ARP_REQUEST on a Class D address the local host must ignore any subsequent ARP_MCJOINs or ARP_MCLEAVEs it sees that would otherwise encompass that Class D address. A host still sends ARP_MCJOINs and ARP_MCLEAVEs when it joins any Class D group. The multicast server establishes the membership of its Class D group by issuing an ARP_REQUEST and monitoring subsequent ARP_MCJOIN and ARP_MCLEAVE traffic (just as a normal host's transmit side would for a mesh supported group). 2. Conclusion. This memo is offered to provide a basis for interested parties to discuss a specific variation to draft-armitage-ipatm-ipmc-02.txt. Support for multicast servers may or may not migrate into the core text based on response to this draft. Security Consideration Security consideration are not addressed in this memo. Author's Address Grenville Armitage MRE 2P340, 445 South Street Morristown, NJ, 07960-6438 USA Email: gja@thumper.bellcore.com Armitage Expires May 3rd, 1995 [Page 3]