Making Sense of Broadband networks: PPPoE Explained

A bit of background First ..

PPPoE stands for Point to Point over Ethernet and is the successor of PPPoA. PPPoE is simply a method of encapsulating PPP packets into Ethernet frames. The standard is defined in RFC2516 . IPoE is growing very quickly but as far as I can tell PPPoE is still very widely deployed model in broadband networks.

PPP protocol is a very mature protocol that was originally implemented to create and maintain direct connections between two nodes. PPP is such a protocol that provides many features but the one that is most interesting to broadband providers is the ability to authenticate and identify users separately for accounting and other purposes.

PPP was commonly deployed in ATM networks, known as PPPoA. When the time came to move to Ethernet there was a challenge for broadband network designers and that is that Ethernet is a multiaccess media by default and doesn't provide the separation for subscribers that PPP provides/requires.  This created the need for a new method to allow PPP to run over Ethernet networks with all its wanted features to broadband networks.

PPP over Ethernet:

PPP expects a point to point media as we stated earlier for a connection to be established; now the question is how do we provide this requirement for PPP to run over a multiaccess media like Ethernet and at what cost?

The creators of the RFC (Redbacks at that time) achieved this via two distinct phases that a PPPoE client has to go through. The first is called the discovery phase and the second is the session phase.

The main goal of the discovery phase is to discover and identify the two ends that are going to negotiate the PPP connection (MAC addresses and a session ID).

In the session phase the unique session ID will be used for each PPPoE client so that the BNG/BRAS is able to uniquely identify the client and to start negotiating a separate PPP connection.

The unique session ID and the unique MAC address of the client will allow a point to point connection to work over a multiaccess media. The cost of this is an extra header to keep the information for each PPPoE session encapsulated into the ethernet frame.

PPPoE discovery phase:

PPPoE discovery is somehow similar to DHCP negotiations, it works like below.

1. Client's CPE sends a broadcast PPPoE active discovery initiation  packet (PADI) to discover any BNGs on the broadcast domain that are willing to provide him the service.
2. Every BNG in the segment that is capable of providing the service will reply back with a unicast PPPoE active discovery offer (PADO) back to the client.
3. The client will consider all the offers received from different BNGs on the segment and respond back with a PPPoE active discovery request packet (PADR) toward the selected BNG (first received PADO by default).
4. If all goes well at this stage, the BNG will allocate a unique SESSION-ID to the client and respond back with a PPPoE active discovery Session packet (PADS).
5. Finally there is a PADT message, which is not part of the discovery process but can be sent at any time by any of the two ends to terminate the connection.

 

 

By finalizing step four both parties will be ready for establishing a PPP connection over an ethernet medium. In reality there are many features/techniques to gain control over the process described above but they are out of the scope of this post for now.

PPPoE session phase:

Now the PPPoE session stage can begin. The purpose of this phase is to establish the PPP connection between the two ends. In this phase PPP connection establishment can run normally as if it was running over a point to point media. The three known phases of the PPP connections are LCP phase, Authentication phase and NCP phase as shown below.

All PPP negotiation packets will be encapsulated into PPPoE header always identifying the unique session ID of the connection.

[caption id="" align="aligncenter" width="492"] Overview of PPP connection establishment.[/caption]

 

In order to fully understand this process, nothing is better than a packet capture. Click on image to view PPPoE negotiations capture.

[caption id="attachment_1081" align="aligncenter" width="509"] PPPoE/PPP Captured Negotiations[/caption]

 

Once a PPP connection is established, it is typically maintained using keep-alives (PPP echo requests/replies) as seen in the captured file.

 

Some final thoughts about PPPoE:

• Connection mode: A PPPoE connection can be established between the CPE and the BRAS directly (typically the case). In such scenario the the CPE acts as a L3 device performing routing between your LAN and the internet. Although this is the most famous deployment, it's not the only one. Almost every operating system, has a PPPoE client and you can run the PPPoE connection directly from your computer or even your phone. In such case, typically the CPE will be acting as a bridge.
• PPPoE MTU: One of the major costs of using PPPoE is the extra header overhead of an 8 bytes, that it inserts in the ethernet frame to identify the connection. This leaves us 1492 bytes by default for actual data over a PPPoE connection. The reduced MTU is sometimes a source of problems and can typically show itself in slow or bad browsing experience for the subscribers.
• PPPoE header TAGs: TAGs are simple TLV fields that can be added to the PPPoE header to provide extra features or to extend PPPoE functionality.  Check the IANA PPPoE assigned tags values here and their relevant RFCs.

 

That's it for this Post, will probably touch more some of the features and deployments on future posts.