PPPoE (Point-to-Point Protocol over Ethernet) is a specification for connecting multiple computer users on an Ethernet local area network to a remote site through common customer premises equipment, which is the telephone company's term for a modem and similar devices. PPPoE can be used to have an office or building-full of users share a common Digital Subscriber Line (DSL), cable modem, or wireless connection to the Internet. PPPoE combines the Point-to-Point Protocol (PPP), commonly used in dialup connections, with the Ethernet protocol, which supports multiple users in a local area network. The PPP protocol information is encapsulated within an Ethernet frame.
PPPoE has the advantage that neither the telephone company nor the Internet service provider (ISP) needs to provide any special support. Unlike dialup connections, DSL and cable modem connections are "always on." Since a number of different users are sharing the same physical connection to the remote service provider, a way is needed to keep track of which user traffic should go to and which user should be billed. PPPoE provides for each user-remote site session to learn each other's network addresses (during an initial exchange called "discovery"). Once a session is established between an individual user and the remote site (for example, an Internet service provider), the session can be monitored for billing purposes. Many apartment houses, hotels, and corporations are now providing shared Internet access over DSL lines using Ethernet and PPPoE.
Original rationale
In late 1998 the DSL service model had a chicken-and-egg problem. ADSL technology had been proposed a decade earlier. Potential equipment vendors and carriers alike recognized that broadband such as cable modem or DSL would eventually replace dialup service, but the hardware (both customer premises and LEC) faced a significant low-quantity cost barrier. Initial estimates for low-quantity deployment of DSL showed costs in the $300–$500 range for a DSL modem and $300/mo access fee from the telco[citation needed] which was well beyond what a home user would pay. Thus the initial focus was on small & home business customers for whom a T1 line (at the time $800–$1500 per month) was not economical, but who needed more than dialup or ISDN could deliver. If enough of these customers paved the way, quantities would drive the prices down to where the home-use dialup user might be interested: more like $50 for the modem and $50/mo for the access.
Different usage profile
The problem was that small business customers had a different usage profile than a home-use dialup user, including
1 - connecting an entire LAN to the internet
2 - providing services on a local LAN accessible from the far side of the connection
3 - simultaneous access to multiple external data sources, such as a company VPN and a general purpose ISP
4 - continuous usage throughout the workday, or even around the clock
These requirements didn't lend themselves to the connection establishment lag of a dialup process, nor its one-computer-to-one-ISP model, nor even the many-to-one that NAT + dialup provided. A new model was required.
Time to market: simpler is better
A problem with creating a completely new protocol to fill these needs was time. The equipment was available immediately, as was the service, and a whole new protocol stack (Microsoft at the time was advocating fiber-based atm-cells-to-the-desktop, and L2TP was brewing as well, but was not near completion) would take so long to implement that the window of opportunity might slip by. Several decisions were made to simplify implementation and standardization in an effort to deliver a complete solution quickly.
Reuse existing software stacks
PPPoE hoped to merge the widespread Ethernet infrastructure with the ubiquitous PPP, allowing vendors on both sides of the connection to heavily leverage their existing software and deliver products in the very near term. Essentially all operating systems at the time had a PPP stack, and the design of PPPoE allowed for a simple shim at the line-encoding stage to convert from PPP to PPPoE.
Simplify hardware requirements
Competing WAN technologies (T1, ISDN) required a router on the customer premises. PPPoE used a different Ethernet frame type, which allowed the DSL hardware to function as simply a bridge, passing some frames to the WAN and ignoring the others. Implementation of such a bridge is multiple orders of magnitude simpler than a router.
Informational RFC
RFC 2516 was initially released as an informational (rather than standards-track) RFC for the same reason: the adoption period for a standards-track RFC was prohibitively long.
Success
PPPoE was initially designed to provide a small LAN with individual independent connections to the internet at large, but also such that the protocol itself would be lightweight enough that it wouldn't impinge on the hoped-for home usage market when it finally arrived. While success on the second matter may be debated (some complain that 8 bytes per packet is too much) PPPoE clearly succeeded in bringing sufficient volume to drive the price for service down to what a home user would pay. It remains the dominant DSL connectivity mechanism as of 2011, more than a decade later.
We prepared a few questions for you to answer with 3 grades peer question
go to this link for questions. Click Here
PPPoE has the advantage that neither the telephone company nor the Internet service provider (ISP) needs to provide any special support. Unlike dialup connections, DSL and cable modem connections are "always on." Since a number of different users are sharing the same physical connection to the remote service provider, a way is needed to keep track of which user traffic should go to and which user should be billed. PPPoE provides for each user-remote site session to learn each other's network addresses (during an initial exchange called "discovery"). Once a session is established between an individual user and the remote site (for example, an Internet service provider), the session can be monitored for billing purposes. Many apartment houses, hotels, and corporations are now providing shared Internet access over DSL lines using Ethernet and PPPoE.
Original rationale
In late 1998 the DSL service model had a chicken-and-egg problem. ADSL technology had been proposed a decade earlier. Potential equipment vendors and carriers alike recognized that broadband such as cable modem or DSL would eventually replace dialup service, but the hardware (both customer premises and LEC) faced a significant low-quantity cost barrier. Initial estimates for low-quantity deployment of DSL showed costs in the $300–$500 range for a DSL modem and $300/mo access fee from the telco[citation needed] which was well beyond what a home user would pay. Thus the initial focus was on small & home business customers for whom a T1 line (at the time $800–$1500 per month) was not economical, but who needed more than dialup or ISDN could deliver. If enough of these customers paved the way, quantities would drive the prices down to where the home-use dialup user might be interested: more like $50 for the modem and $50/mo for the access.
Different usage profile
The problem was that small business customers had a different usage profile than a home-use dialup user, including
1 - connecting an entire LAN to the internet
2 - providing services on a local LAN accessible from the far side of the connection
3 - simultaneous access to multiple external data sources, such as a company VPN and a general purpose ISP
4 - continuous usage throughout the workday, or even around the clock
These requirements didn't lend themselves to the connection establishment lag of a dialup process, nor its one-computer-to-one-ISP model, nor even the many-to-one that NAT + dialup provided. A new model was required.
Time to market: simpler is better
A problem with creating a completely new protocol to fill these needs was time. The equipment was available immediately, as was the service, and a whole new protocol stack (Microsoft at the time was advocating fiber-based atm-cells-to-the-desktop, and L2TP was brewing as well, but was not near completion) would take so long to implement that the window of opportunity might slip by. Several decisions were made to simplify implementation and standardization in an effort to deliver a complete solution quickly.
Reuse existing software stacks
PPPoE hoped to merge the widespread Ethernet infrastructure with the ubiquitous PPP, allowing vendors on both sides of the connection to heavily leverage their existing software and deliver products in the very near term. Essentially all operating systems at the time had a PPP stack, and the design of PPPoE allowed for a simple shim at the line-encoding stage to convert from PPP to PPPoE.
Simplify hardware requirements
Competing WAN technologies (T1, ISDN) required a router on the customer premises. PPPoE used a different Ethernet frame type, which allowed the DSL hardware to function as simply a bridge, passing some frames to the WAN and ignoring the others. Implementation of such a bridge is multiple orders of magnitude simpler than a router.
Informational RFC
RFC 2516 was initially released as an informational (rather than standards-track) RFC for the same reason: the adoption period for a standards-track RFC was prohibitively long.
Success
PPPoE was initially designed to provide a small LAN with individual independent connections to the internet at large, but also such that the protocol itself would be lightweight enough that it wouldn't impinge on the hoped-for home usage market when it finally arrived. While success on the second matter may be debated (some complain that 8 bytes per packet is too much) PPPoE clearly succeeded in bringing sufficient volume to drive the price for service down to what a home user would pay. It remains the dominant DSL connectivity mechanism as of 2011, more than a decade later.
We prepared a few questions for you to answer with 3 grades peer question
go to this link for questions. Click Here
I see much information but little learning occurring in these posts. Where are your activities?
ReplyDelete