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

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.

In article <11261@crackers.clearpoint.com> martillo@stars.clearpoint.com (Joachim Martillo) writes:
   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.

For true believers of the pure Router faith, that's not a problem.

   SLITHERNET which is currently supported (along with PPP) by
   Clearpoint, DuPont, Datability and bridge routers from other
   vendors in the near future

I'll look for the SLITHERNET Demo Center at Interop.  (I doubt it will
be as crowded as PPP's :-)

   is a better alternative for moderate to high-speed WAN
   interconnectivity.

Yes, for those users who want to use SLITHERNET.  We've all been round
and round about this many times before, and I doubt we'll cover any
new ground here.

   ... corporations really need to build ... from point to point, X.25
   and FR links.  PPP unlike the SLITHERNET formalism will fail
   miserably for this purpose.

That's why they should use RFC-1356 or RFC-877 encapsulation over
X.25, and RFC-1294 over Frame Relay, rather than RFC-1331 PPP.  The
IETF has blessed different encapsulations for different media.  A user
should also be cautioned not to use a drill press where {s}he really
needs a putty knife.

   Buying bridges, routers and bridge routers which only support PPP
   could lock the purchaser into an inferior form of wide area
   networking.

That sounds like a piece of IBM marketing literature I recently heard
about: "Don't let yourself be locked into open systems!"