Re: Protocols over Frame Relay

Drew Daniel Perkins <ddp+@andrew.cmu.edu> Fri, 16 November 1990 17:10 UTC

Received: from po2.andrew.cmu.edu by NRI.NRI.Reston.VA.US id aa07333; 16 Nov 90 12:10 EST
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA04707> for frame-relay@nri.reston.va.us; Fri, 16 Nov 90 12:09:08 EST
Received: via switchmail; Fri, 16 Nov 90 12:09:03 -0500 (EST)
Received: from valkyries.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.EbF1mrC00iU440RlAl>; Fri, 16 Nov 90 12:07:10 -0500 (EST)
Received: from valkyries.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr15/ddp/.Outgoing/QF.obF1mom00iU4A2mY8S>; Fri, 16 Nov 90 12:07:00 -0500 (EST)
Received: from BatMail.robin.v2.10.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.30 via MS.5.6.valkyries.andrew.cmu.edu.pmax_30; Fri, 16 Nov 90 12:06:58 -0500 (EST)
Message-Id: <EbF1mmK00iU402mXxp@andrew.cmu.edu>
Date: Fri, 16 Nov 90 12:06:58 -0500 (EST)
From: Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To: Joel Halpern <jmh@petunia.network.com>
Subject: Re: Protocols over Frame Relay
Cc: frame-relay@NRI.Reston.VA.US
In-Reply-To: <9011161500.AA00203@petunia.network.com>
References: <9011161500.AA00203@petunia.network.com>

jmh@petunia.network.com (Joel Halpern) writes:
> My impression was that PPP as it currently
> exists/is planned would not be sufficient.

I believe that there are only two areas where PPP may be currently
deficient: multicast and address size.  However, PPP was purposely
designed to be extensible in these areas if necessary.  If frame-relay
want to use multicast services, PPP is sufficiently malleable to
support this.  PPP can also be easily modified to support 16 bit
addresses.  PPP is currently a draft standard, which by definition
means it can still be changed for reasons such as this.

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

I agree (who wouldn't?) that static configuration is insufficient.
One of the main goals of PPP was to make connections dynamic!  Hence
the entire PPP option negotiation protocol.

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

Given the potentially HUGE number of possible destinations, I
personally don't think that multicast ARP makes any sense whatsoever.
Something like Robert Ullmann's ISDN DNS RR (RFC 1183) seem to make more sense.

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

PPP can do this.  Today.

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

See RFC 1183.

My proposal is that PPP and the ISDN RR should be the starting points
for supporting IP over the frame relay.  PPP should have two small
modifications - address length and multicast support - as mentioned
above.  I have yet to hear convincing arguments as to why these would
be inappropriate.

Drew