Re: Protocols over Frame Relay [multicasting]

[Andy Malis <[e-mail]>]

> 	With regard to making multicast work, we have the same
> situation with frame-relay as we had starting up the smds working
> group:
> 	Is this a WAN primarily for gateways or for end-systems (and
> gateways)?

The canonical application for frame relay is LAN interconnect -
replacing a bunch of router-router T1 trunks with one frame relay
interface on each router.  The owner of the routers then pays for
one FR interface per router, rather than for a mesh net of T1
trunks.  It presumably lowers the cost of the routers as well,
since they require fewer physical interfaces.

You probably will not see many direct host connections to frame
relay, except when the host is also a router.

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

Yes.

You'll actually see quite a bit of both.  In the public arena,
both Sprint and NYNEX are building public FR nets even as we
type.  Other RBOCs and IEX carriers may also have work underway,
but just haven't yet announced anything.

In the private area, there are a number of vendors that are
adding FR interfaces to existing equipment such as T1 muxes and
circuit switches.  Then, companies with existing T1 networks
between their sites can replace their existing dedicated
inter-router trunk bandwidth with frame relay.  The assumption is
that their existing inter-router bandwidth is mostly
underutilized, and using the frame relay interface will allow
them to better use their T1s (or even require less overall
bandwidth).

> 	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.

Absolutely.  However, as someone noted earlier, multicasting is
strictly optional, and it's hard to use protocols which depend
on features your service provider may not provide.

> 	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?

Certainly should.  In some cases, such as on the public FR nets,
or on FR nets that do not offer multicasting, then you would use
the resolution servers from the beginning.

Andy