Re: Protocols over Frame Relay

["k1io@FN42jk 16-Nov-1990 0944" <[e-mail]>]

Multicasting is a fairly risky extension to Frame Relay.  While it is 
supported on some FR devices, it's easy to see how heavy multicast use 
could really harm a network.  It doesn't get throttled back like TCP 
traffic, and has a nasty tendency to grow to displace "real" traffic.

Mapping PPP over FR, on the other hand, is rather straightforward. 
Beginning with the "control" field, after the DLCI, frame relay delivers 
the PPP frame across a virtual point to point link.  It's quite simple.
In the event that the network is congested and drops the frame (which is 
a normal occurrence during "slow-start" cycles), then TCP can recover 
and shrink its window size.  That's precisely what you want to have 
happen.  Bulk UDP is always a bad idea on WANs since it lacks that 
feature, but Frame Relay is no different from IP itself in that regard.

Multicast seems a convenient way to autoconfigure networks, but there 
are certainly other approaches. You'd have to administer each node to 
know what multicast address(es) to use.  You can also administer each 
node to know what non-multicast address to use for routing assistance 
(i.e., the ISIS "designated router").

The Frame Relay standards (T1.6ca, to be precise) provide for three 
syntactic mechanisms for explicit congestion avoidance signaling too.  
Unfortunately, IP doesn't yet have any way of conveying that to the 
controlling TCP.  ISO CLNP does have a congestion bit which TP4 reacts 
to, under the NIST agreements.  PPP wouldn't have to be touched if IP 
were to follow up on that: The congestion bits are stolen from the 
"address" field (second octet of DLCI, to be specific), which a Frame 
Relay flavor of PPP would presumably support.
     fred

Disclaimer: Opinions are mine alone, sharing requires permission.
On the other hand I do give them out freely at ANSI T1S1 frame relay 
standards meetings.