🚀 go-pugleaf

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.

However, if a T1 line connects routers from the same vendor, there may
be some advantage to using the vendor's own proprietary encapsulation
on that link, because they may support some unique features in their
own encapsulation scheme that haven't yet been implemented over their
PPP interface.  Those advantages, if any, would vary depending upon
which vendor you're talking to.

   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.  Of course, lots of tiny
packets would require more horsepower, and the box may be spending
some of its time doing SNMP or packet filtering or something ele.
These aren't directly related to the PPP protocol, but they affect the
selection of the engine inside the box.

One advantage for sync PPP designers is that the basic HDLC framing
has already been implemented in hardware, in (e.g.) the MC68302 CPU
and in other parts (UARTs, etc.) at various levels of the food chain.

   In typical PPP implementations, how much of RFC-1331, RFC-1332, and
   RFC-1333 is adhered to?

As much as possible, and all the important parts :-)

You can buy some implementations that don't completely and correctly
support even RFCs 1171 and 1172.  And there are others that take great
care to follow the relevant bits of RFCs 1331, 1332, and 1332 to the
letter.

But Link Quality Monitoring (RFC 1333) is not a required feature of
something that aspires to call itself PPP.  Nor is "VJ" TCP header
compression (RFCs 1332 and 1144), and even those that support TCP
header compression may legally support differing numbers of slots.
And the use of TCP header compression isn't even recommended at T1
speeds, because it may absorb more router horsepower than it saves in
bits on the wire, and have a net negative effect on latency.

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.

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.