Rationale behind PPPoE


The DSL service model was facing a chicken-and-egg sort of problem during the late 1998. The ADSL technology had existed for around a decade. Potential carriers and equipment vendors were pretty clear that broadband mediums like DSL or cable modems would soon replace the conventional dial-up services, however, there was a major low-quantity cost barrier both at the LEC and the customer premises levels. The starting estimates for deployment of DSLs showed a cost estimate in the range of $ 300 to $ 500 for DSL modems and around $ 300 per month access fee payable to the telecom companies. These were pretty steep figures for regular home-users. Hence, the initial focus of the service was small and home business users who couldn’t afford the T1 lines at that time, but needed a more feasible solution than the conventional dial-ups or ISDNs. If a large number of such customers were roped in, the quantities were bound to bring down the prices to a point where the home users would also be interested (more like in the range of $ 50 per month for access and $ 50 for modem).

However, small business users’ usage profile was quite different compared to home-based dial-up users. Some of the other problems were:
- Connecting a complete local area network (LAN) to Internet.
- Providing services available on local LAN accessible to the other end of the connections.
- Continuous work day usage, sometimes even round-the-clock.
- Simultaneous access to different external data sources like general-purpose ISP and company VPN.

These requirements made the development of a new model almost a necessity.

PPPoE is mainly used in cases where:
- A PPPoE-speaking modem-router is used for connecting to the DSL service and the Internet DSL service also speaks PPPoE.
- A DSL modem which speaks PPPoE is connected to an Ethernet-only router which speaks PPPoE too with an Ethernet cable.

A major problem
The development of a completely new protocol had a major problem – time. Even though the service and equipment were both available, developing a new protocol stack would’ve taken an extremely long time. Many critical decisions were taken for simplification of the implementation and standardization processes, in order to deliver a comprehensive solution as soon as possible.

Re-usage of existing software stacks
With PPPoE vendors hoped that they’d be able to merge the ubiquitous PPP with the widely spread Internet infrastructure, enabling them to leverage their already-existing software and to deliver their products quickly. All operating systems of the time were equipped with PPP stack. With PPPoE design all that was needed was a simple step at the line-encoding stage for conversion from PPP to PPPoE.

Simplification of hardware requirements
The competing wide area network (WAN) technologies such as ISDN, T1 etc. made router presence a must at all customer locations. As PPPoE employed a distinct Internet frame type, it allowed DSL hardware to simply function as a bridge, passing on few frames to WAN and ignoring the others.

Informational RFC
The release of RFC 2516 was initially only as an informational RFC and not as a standards-track RFC, as the latter would’ve taken a very long time to adopt.

The eventual success
The initial design of PPPoE was targeted at small LANs, in order to provide them with independent individual connections. However, this was achieved keeping the protocol light enough for the home-use market. This was a big achievement and success.