One document matched: draft-ohta-mcast-large-cloud-00.txt

                Multicast Inscalability over Large Cloud

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.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This memo describes a scalability issue when multicasting to a large
   number of recipients over a large cloud.

1. The Problem

   Multicast algorithms for the Internet are often designed to support a
   large number of receivers.

   For the scalability, it is important to not to concentrate lage
   amount of load to a few locations.

   To distribute large amount of load caused by a large number of
   recipients, routers between the sender and the receivers are expected
   to perform some amount of computation.

   For example, with RSVP [RSVP], join is receiver initiated and
   multiple join requests to a single sender are merged on intermediate
   routers. As a result, each input port of a sender or intermediate
   routers receives only as many join request as the number of the hosts
   of the subnet of the input port.

   The other example of load distribution with RSVP [RSVP] is



M. Ohta                 Expires on Aug 22, 1996                 [Page 1]

INTERNET DRAFT  Multicast Inscalability over Large Cloud   February 1996


   computation of Adspec, which gives information on available resource
   between the sender and the receivers.  In this case, Adspec received
   from upstream sender side is modified and distributed to limited
   number of routers or hosts in the direct downstream subnet.

   The problem with a large cloud [NHRP], then, is that the cloud does
   not contain entity to recognize IP specific information.

   It is impossible to let entities in the cloud perform some operation
   of IP based protocols.

   That is, large scale multicast does not scales over a large cloud.

2. A Solution

   There seems to exists only one solution: to make some of the
   intermediate link layer entities recognize IP protocols including IP
   addresses and filter specs [RSVP].

   That is, to put IP routers in the large cloud.

   As a result, the cloud is divided into a collection of small clouds
   and we don't need a large cloud model [NHRP].

   It should be noted that, though the large cloud model was proposed
   mainly for ATM, when it was not known that IP routers can relay data
   cell-by-cell, ATM data can be relayed cell-by-cells end-to-end all
   over the Internet through intermediate IP routers.

3. References

   [RSVP]

   [NHRP]

4. Security Considerations

   (to be provided)

5. Author's Address

   Masataka Ohta
   Computer Center
   Tokyo Institute of Technology
   2-12-1, O-okayama
   Meguro-ku, Tokyo 152, JAPAN

   Phone: +81-3-5734-3299



M. Ohta                 Expires on Aug 22, 1996                 [Page 2]

INTERNET DRAFT  Multicast Inscalability over Large Cloud   February 1996


   Fax: +81-3-5734-3415
   EMail: mohta@necom830.hpcl.titech.ac.jp

















































M. Ohta                 Expires on Aug 22, 1996                 [Page 3]