🚀 go-pugleaf

In article <BOB.92Oct15120100@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>In article <1992Oct14.173126.1438@pippen.ub.com> dvalley@andr.UB.com (Dave Valley) writes:
>   I am just beginning to learn about PPP and am trying understand how
>   it is typically implemented on a hardware platform that provides a
>   bit-synchronous serial line at high data rates such as T1 line rate
>   (1.544Mbps).  Is this commonly done?

>Yes.  Most router vendors can talk PPP on T1 lines.

>   What are the pros and cons of using PPP?  

>If a router vendor supports PPP, its routers can talk to routers from
>other vendors that also support PPP.  This allows them into a
>commodity market.  Before the widespread acceptance and availability
>of PPP in the router market, a customer was forever locked into using
>routers made by the vendor from which they bought their first pair,
>because the vendors each invented their own proprietary encapsulation
>scheme.  Now, customers can specify PPP in a purchase requirements
>document, and the router vendors must compete in other distinguishing
>areas like ease of management, performance, price, etc.

But a very major drawback to PPP is the use of multiple encapsulations
for the various network protocols which will essentially break the
path selection functionality of multi-media bridge routers.  

SLITHERNET which is currently supported (along with PPP) by
Clearpoint, DuPont, Datability and bridge routers from other vendors
in the near future is a better alternative for moderate to high-speed
WAN interconnectivity.

>   What type of processing power is required to implement the
>   protocol?

>Not much.  A UNIX PPP implementation running in user space on a lowly
>SPARCstation-1 requires only a few percent (3-5%) of the host's CPU to
>keep a T1 line full with a mix of packet sizes.  If you open the hood
>of many dedicated routers, you'll find that they're powered by
>surprisingly slow 68000s and i[23]86 engines.  

Actually, this is not surprising.  Creating value in a bridge router
means to a large extent hand-crafting the bridge router code to get
the highest possible performance from the CPU. 

>That's one good thing about PPP: a minimal implementation with few
>special features may be all you need for a particular application.  So
>long as it negotiates its options correctly, it will interoperate with
>other implementations that have all the full variety of bells and
>whistles.

But you would have to be very careful, because in many cases
corporations really need to build synchronous interworking backbone
wide area communications subnets constructed from point to point, X.25
and FR links.  PPP unlike the SLITHERNET formalism will fail miserably
for this purpose.  Buying bridges, routers and bridge routers which
only support PPP could lock the purchaser into an inferior form of
wide area networking.

>If you want to grill some PPP vendors on the completeness and
>correctness of their implementations, and let them brag about how easy
>it was for them to do and how studly their engineers are, come to the
>PPP Demonstration Center in booth 5384 at Interop (October 26-30) at
>the Moscone Center in San Francisco.


--
Joachim Carlo Santos Martillo Ajami

The article represents noone's opinions other than the author's.