Re: Protocols over Frame Relay

[[e-mail]]

>     I believe the big win using PPP over FR networks is the ability
>     to run multiple protocols over the same PVC. However, viewing the
>     PVC subscribed as a "virtual point-to-point" link may have scaling
>     problems. Specifically, I wouldn't want to run the LCP FSM n times.
>     Furthermore, one may subscribe to n PVCs but not have frequent 
>     traffic to all nodes. The PPP overhead (LQM packets) could consume
>     the single-link bandwidth to the network.

I don't see why you wouldn't want to run the PPP FSM n times: the whole point
of FR is to put the end-to-end responsibility in your hands(so that the DCE
side of the system is easier, and presumably faster).

You ought to be able to negotiate a low rate of LQM traffic per link, if that
is your only problem.  Or skip it, since LQM is negotiable.  You can just
trust that the FR DCE will supply you with correct up/down indications for
each PVC.  Note that routers typically have a higher layer protocol that
ensures connectivity for routing purposes in any case.


To change the subject: I definitely fall on the directory service, as opposed
to ARP/multicast, side of the fence.  On LAN's, the overhead from broadcast
protocols can be severe drain on hosts even without the broadcast storm
problems.  In this regard, broadcast and "public" multicast are antisocial,
requiring responses and using network resources of many users for a single
connection attempt.

Further, the service seems (to me) inapropriate for a WAN environment where
physical duplication of bits and multiplication of bandwidth is required.
I'll give in a little for limited multicast, where a well-known logical
address is used to locate service that may be provided by several servers and
also for duplication as a special service(for conferencing, for example), but
the general case is clearly best suited to LAN's where everyone listens to the
same bits.

Tracy