INTERNET DRAFT M. Ohta draft-ohta-mcast-large-cloud-00.txt Tokyo Institute of Technology February 1996 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]