Subject: Re: (IPng 1371) ipatm, rolc, and joint LA session agendas

From: List Manager Account <[email-masked]>
Date: Sat, 17 Feb 96 21:57:14 PST

------- Forwarded Message

Date:    Thu, 15 Feb 1996 15:41:00 -0500
From:    "Myjak, Michael" <[email-masked]>
To:      int-serv-request <[email-masked]>
Subject: Re: (IPng 1371) ipatm, rolc, and joint LA session agendas

Joel M. Halpern    < [email-masked] > writes:

I suspect that discussion of scalability of multicasting over ATM
(including scalability of shortcuts, however maintained) probably belongs
in the ipatm/rsvp/intserv discussion if there is sufficient time.
 ----------
I agree with Joel.  Given my background in distributed interactive 
simulation, I am extremely interested in this area. Particularly as it 
relates to deficiencies between IPmc and IPATM/mc.

 -- Michael Myjak
   Senior Research Scientist
   Institute for Simulation and Training
   University of Central Florida
   3280 Progress Drive
   Orlando, Florida   32826
   email: [email-masked]
   voice: 407.658.5043
   FAX:   407.658.5059

     Off the keyboard, over the bridge, through the router... nothing but 
'net!

------- End of Forwarded Message

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Feb 96 13:02:32 JST

> Andy;
> 
> > Please respond, either publicly or privately, if you have specific
> > topics and/or internet drafts you would like to put on any of the
> > above agendas.
> 
> I'd like to discuss lose of multicast scalability caused by NHRP.
> 
> It could be discussed in ipatm, ipatm/rsvp/intserv or ipatm/rolc/ipng
> meeting, I think.
> 
> I'll prepare an ID (2 or 3 pages long, I think) before 2/22 deadline.

Below is the draft. But, as I forgot to get finename assigned,
please don't expect it will be published as an Internet Draft
before LA meeting.

							Masataka Ohta

INTERNET DRAFT                                                   M. Ohta
                                           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: [email-masked]

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