One document matched: draft-armitage-ipatm-mcserv-00.txt

Internet-Draft                                      Grenville Armitage
                                                              Bellcore
                                                     November 3rd, 1994


             Multicast Servers in an RFC 1577 Environment.
                  <draft-armitage-ipatm-mcserv-00.txt>


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]