Re: Protocols over Frame Relay [multicasting]

Kent England <> Fri, 16 November 1990 14:58 UTC

Received: from by NRI.NRI.Reston.VA.US id aa04867; 16 Nov 90 9:58 EST
Received: from BU-IT.BU.EDU by BU.EDU (1.99) Fri, 16 Nov 90 09:58:58 EST
Received: from BUITB.BU.EDU by (12/20/89); Fri, 16 Nov 90 09:58:55 EST
Received: from ( by buitb (4.12/4.7) id AA06513; Fri, 16 Nov 90 09:58:55 est
Date: Fri, 16 Nov 90 09:58:55 est
From: Kent England <>
Message-Id: <9011161458.AA06513@buitb>
To: frame-relay@NRI.Reston.VA.US
Subject: Re: Protocols over Frame Relay [multicasting]

> > It seems like multi/broad/cast capability is a very useful way to
> > solve some of these problems, if the traffic can be kept down.
> Yes and no.  Traffic being kept down is the gating issue, as traffic
> volume is roughly proportional to the square of the affected stations.
> LANs, which have no such throughput issue, get loaded with multicasts
> as it stands.  The idea of every station multicasting ES-IS End Station
> Hellos every few seconds doesn't sound very appealing.

	From my point of view, multicast capability is not so much a
traffic issue as it is an issue of dynamic discovery.  Multicasting
can make management, configuration, and maintenance of a WAN so much
easier for the service provider and for the end-user.

	With regard to making multicast work, we have the same
situation with frame-relay as we had starting up the smds working

	Is this a WAN primarily for gateways or for end-systems (and

	Will there be one big FR network or will there be many smaller
virtual private FR networks?

	If you assume one big FR network with lots of end systems you
face a big scaling problem with multicast.  If you assume many virtual
private FR networks of routers, then you can see that multicast
(confined to a single virtual private FR net) can be a big win for
routing information exchange and address resolution.

	In the smds group there was an assumption that IP would start
small and run on virtual nets and would use multicast for routing and
ARP.  If things get big and multicast runs into problems, then the
multicast groups can be changed to point to routing and address
resolution servers, transparently to the attached routers.

	Shouldn't that approach work as well with FR?