Re: Protocols over Frame Relay

Joel Halpern <jmh@petunia.network.com> Fri, 16 November 1990 14:58 UTC

Received: from nsco.network.com by NRI.NRI.Reston.VA.US id aa04863; 16 Nov 90 9:58 EST
Received: from petunia.network.com by nsco.network.com (5.61/1.34) id AA00421; Fri, 16 Nov 90 08:59:33 -0600
Received: by petunia.network.com (4.1/SMI-4.1) id AA00203; Fri, 16 Nov 90 09:00:57 CST
Date: Fri, 16 Nov 90 09:00:57 CST
From: Joel Halpern <jmh@petunia.network.com>
Message-Id: <9011161500.AA00203@petunia.network.com>
To: ddp+@andrew.cmu.edu
Subject: Re: Protocols over Frame Relay
Cc: frame-relay@NRI.Reston.VA.US

Drew Daniel asks what my reasoning was behind saying that I felt
that a better solution than simply PPP was needed.

First, there is the possibility of capabilities in PPP which I am
not aware of.  Also, it is likely that the solutions can be created within
the existing PPP framework.  My impression was that PPP as it currently
exists/is planned would not be sufficient.  However, here is my thinking:

Given that Frame Relay is a multi-point network, it is necessary to
dynamically determine the IP addresses associated with destination
Virtual circuit numbers.  Given the large number of supported PVCs,
and that circuits may go up and down, static configuration seems
to me to be insufficient. 

There are several possiblities that I can see.  One way would be to use
multi-cast capabilities and ARP or its equivalent to determine
which PVC has a destination.

Another way would be at startup to send an announcment/query message
over each PVC which is enabled, record and reply to any
announcement/query messages which arrive, and resend whenever a
PVC comes up.

One could also use an approach such as is being recommend in ISO for
ES-IS over non-broadcast networks, and have one or more servers
profiled, who would keep track of everyones address.

While all of these would work, we need to pick one.

Also, I have been told that PPP has a lot of startup logic.  I am not
clear on how often people actually expect PVCs to go up and down, but
if it is too frequent, this might be a problem.

Joel M. Halpern			jmh@nsco.network.com
Network Systems Corporation