Protocols over Frame Relay

Fred Baker <fbaker@acc.com> Fri, 16 November 1990 01:47 UTC

Received: from emerald.acc.com by NRI.NRI.Reston.VA.US id aa15457; 15 Nov 90 20:47 EST
Received: by emerald.acc.com (4.1/SMI-4.1) id AA13073; Thu, 15 Nov 90 17:47:48 PST
Date: Thu, 15 Nov 90 17:47:48 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9011160147.AA13073@emerald.acc.com>
To: frame-relay@NRI.Reston.VA.US
Subject: Protocols over Frame Relay

> One can use PPP and treat it as a collection of point-to-point
> links.  For now, that will work.  However, that is clearly not
> desirable in the long run.  We need a better solution.

Some consideration was given to putting PPP on Frame Relay during last
May's IETF meeting, but we had inadequate information to formulate that
well, and didn't want to slow down the Point to Point standard to
enhance in a multipoint capability.  We basically said that we or
someone else could write that RFC later, which I think may mean now.

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

This may sound horrendous, but the answer may be to use something
comparable to OSPF's Multi-access Non-Broadcast Network model here,
especially if multi/broad/cast will not be uniformly supported.

Fred