DSL represents a form of broadband technology that utilizes existing telephony networks to allow for data communications. Communication is facilitated through a remote transceiver unit, or modem at the customer premises, which communicates over the existing telephone lines to a central office transceiver unit that takes the form of the Digital Subscriber Line Access Multiplexer (DSLAM) where traffic is multiplexed onto a high speed ATM or Ethernet network before reaching the broadband remote access server (BRAS) or PPPoA/PPPoE server within the service provider network.
The distance between the two transceivers can vary depending on the specific DSL technology applied. In the case of an Asynchronous Digital Subscriber Line (ADSL) the distance expands up to around 18000 feet or 5,460 meters traditionally over an ATM network, whereas with a Very High Speed Digital Subscriber Line (VDSL2), local loop distances of only around 1500 meters are supported with fiber (FTTx) technology applied to provide Ethernet based backend transmission to the BRAS (PPPoE server)
PPPoE refers to the encapsulation of PPP within Ethernet frames to support a connection over broadband technologies to a PPPoE broadband remote access server (BRAS), located within the service provider network. This is used to support the authentication and accounting process before access to the remote network such as the Internet is provided. The router RTA operates as the client for establishment of the PPPoE session with the PPPoE server via which an authorized connection is established for access to remote networks and resources. The DSL modem provides the modulation and demodulation of signals across the copper telephone wire infrastructure that traditionally exist in homes and offices.
PPPoE has two distinct stages, initially there is a Discovery stage followed by a PPP Session stage. When a client wishes to initiate a PPPoE session, it must first perform Discovery for which four stages are involved and rely on four individual packet types for the discovery process. These include the PPPoE Active Discovery Initiation (PADI), PPPoE Active Discovery Offer (PADO), PPPoE Active Discovery Request (PADR) and PPPoE Active Discovery Session-confirmation (PADS) protocol packet types. The termination process of the PPPoE session utilizes a PPPoE Active Discovery Terminate (PADT) packet for closure of the PPPoE session.
In the Discovery stage, when a client (RTA) accesses a server using PPPoE, the client is required to identify the Ethernet MAC address of the server and establish a PPPoE session ID. When the Discovery stage is complete, both peers know the PPPoE Session_ID and the peer Ethernet address. The PPPoE Session_ID and peer Ethernet address define the unique PPPoE session. The client will broadcast a PPPoE Active Discovery Initiation (PADI) packet. This packet contains the service information required by the client. After receiving this PADI packet, all servers in range compare the requested services to the services that they can provide. In the PADI packet, the Destination_address is a broadcast address, the Code field is set to 0x09, and the Session_ID field is set to 0x0000.
The servers that can provide the requested services send back PPPoE Active Discovery Offer (PADO) packets. The client (RTA) can receive more than one PADO packet from servers. The destination address is the unicast address of the client that sent the PADI packet. The Code field is set to 0x07 and the Session_ID field must be set to 0x0000.
Since the PADI packet is broadcast, the client can receive more than one PADO packet. It looks through all the received PADO packets and chooses one based on the AC-Name (which stands for the Access Concentrator name, and generally refers to a value the uniquely distinguishes one server from another), or the services offered by the PADO packet. The client looks through the PADO packets to choose a server, and sends a PPPoE Active Discovery Request (PADR) packet to the chosen server. The destination address is set to the unicast address of the access server that sent the selected PADO packet. The code field is set to 0x19 and the session ID field is set to 0x0000.
When receiving a PADR packet, the access server prepares to begin a PPPoE session. It generates a unique session ID for the PPPoE session and replies to the client with a PPPoE Active Discovery Session-confirmation (PADS) packet. The destination address field is the unicast Ethernet address of the client that sends the PADR packet. The code field is set to 0x65 and the session ID must be set to the value created for this PPPoE session. The server generates a unique session identifier to identify the PPPoE session with the client and sends this session identifier to the client with the PADS packet. If no errors occur, both the server and client enter the PPPoE Session stage.
Once the PPPoE session begins, PPP data is sent as in any other PPP encapsulation. All Ethernet packets are unicast. The ETHER_TYPE field is set to 0x8864. The PPPoE code must be set to 0x00. The SESSION_ID must not change for that PPPoE session and must be the value assigned in the discovery stage. The PPPoE payload contains a PPP frame. The frame begins with the PPP Protocol-ID.
In the PPPoE session establishment process, PPP LCP negotiation is performed, at which point the maximum receive unit (MRU) is negotiated. Ethernet typically has a maximum payload size of 1500 bytes, where the PPPoE header is 6 bytes, and the PPP Protocol ID is 2 bytes, the PPP maximum receive unit (MRU) cannot be greater than 1492 bytes since this will likely cause packet fragmentation. When LCP terminates, the client and access concentrator (server) stop using that PPPoE session. If the client needs to start another PPP session, it returns to the Discovery stage.
The PPPoE Active Discovery Terminate (PADT) packet can be sent anytime after a session is set up to indicate that a PPPoE session is terminated. It can be sent by the client or access server. The destination address field is a unicast Ethernet address. The Code field is set to 0xA7 and the session ID must be set to indicate the session to be terminated. No tag is required in the PADT packet. When a PADT packet is received, no PPP traffic can be sent over this PPPoE session. After a PADT packet is sent or received, even normal PPP termination packets cannot be sent. A PPP peer should use the PPP protocol to end a PPPoE session, but the PADT packet can be used when PPP cannot be used.
Three individual steps are required in the configuration of a PPPoE client, beginning with the configuration of a dialer interface. This enables the connection to be established on demand and a session connection to be disconnected after remaining idle for a period of time. The dialer-rule command enables the dialerrule view to be accessed from which the dialer-rule can be set to define conditions for initiating the PPPoE connection.
The dialer user chooses a dialer interface on which to receive a call according to the remote user name negotiated by PPP. The dialer user enables the dial control center and indicates the remote end user name, which must be the same as the PPP user name on the remote end server. If the user name parameter is not specified when using the undo dialer user command, the dial control centre function is disabled and all of the remote user names are deleted. If this parameter is specified, only the specified user name is deleted. The dialer bundle <number> command in the AR2200E is used to bind physical interfaces and dialer interfaces.
PPP authentication parameters are defined for authentication of the client connection to the server along with the ip address ppp-negotiate command for negotiation on an interface, to allow the interface to obtain an IP address from the remote device.
The second step involves the establishment of the PPPoE session binding of the dialer bundle to the interface over which negotiation is to take place for the configured dialer parameters. The pppoe-client dial-bundle-number <number> command is used to achieve this where the number refers to the bundle number configured as part of the dialer parameters.
If on-demand is not specified, the PPPoE session works in permanent online mode. If this parameter is specified, the PPPoE session works in on-demand dialing mode. The AR2200 supports the packet triggering mode for on-demand dialing. In permanent online mode, the AR2200 initiates a PPPoE session immediately after the physical link comes up. The PPPoE session persists until the undo pppoe-clientdial-bundle-number command is used to delete it. In triggered online mode, the AR2200 does not initiate a PPPoE session immediately after the physical link comes up. Instead, the AR2200 initiates a PPPoE session only when data needs to be transmitted on the link. If no data is transmitted on the PPPoE link within the interval specified by dialer timer idle <seconds>, the AR2200 terminates the PPPoE session. When data needs to be transmitted on the PPPoE link, the AR2200 sets up the PPPoE session again.
The final step requires that a default static route be configured to allow any traffic for which a network destination is not defined as a longer match in the routing table to initiate the PPPoE session through the dialer interface.
The display interface dialer command is used to verify the current status of the dialer configuration and allows for the locating of faults on a dialer interface. The dialer current state of UP identifies that the physical status of the interface is active, while a DOWN state would confirm that a fault currently exists. The line protocol state refers to the link layer protocol status for which an UP status confirms the active connection.
A link that has no IP address assigned to the interface or is suppressed will show to be in a DOWN state, where suppression can be identified by dampening to the interface mainly due to a persistent interface flapping. The hold timers represents the heartbeat of the PPP dialer connection after PPP LCP negotiation transitions to Opened. The Internet address is negotiated from the IP pool that exists within the PPPoE server, where no address is present, the system will display “Internet protocol processing: disabled.“ The IP address is assigned when a connection is negotiated i.e. through a ping request in the pool range.
The LCP negotiation status defines the current state, where “initial” indicates that the physical layer is faulty or no negotiation has been started. An “Opened” state indicates that the system has sent a Configure-Ack packet to the peer device and has received a Configure-Ack packet from the peer device, as such confirming that the link layer is operating correctly.
The display pppoe-client session summary command provides information regarding the PPPoE sessions on the Point-to-Point Protocol over Ethernet (PPPoE) client, including the session status and statistics. Two examples are given to highlight the difference between the PPPoE session states. The ID represents the PPPoE ID while the bundle ID and Dialer ID are related to the values in the dialer parameter configuration.
The interface defines the interface on which the client side negotiation is performed. The MAC address of the PPPoE client and server are also defined, however the Server-MAC is only determined after negotiation is established. The PPPoE has four states that are possible. An IDLE state indicates that the PPPoE session is currently not established and no attempt to establish the PPPoE connection has been made.
If the state is PADI, this indicates that the PPPoE session is at the Discovery stage and a PPPoE Active Discovery Initiation (PADI) packet has been sent. A PADR state indicates that the PPPoE session is at the Discovery stage and a PPPoE Active Discovery Request (PADR) packet has been sent. Finally, an UP state indicates that the PPPoE session has been established successfully.
Much of the implementation of PPPoE has focused on a general point-to-point connection reflective of a typical lab environment however in real world applications the PPPoE client often represents the gateway between an enterprise network and the Wide Area Network (WAN), to which external destinations and resources are accessed.
The internal network of an enterprise commonly employs a private network scheme in order to conserve addresses and these addresses cannot be used to establish IP communication over the public network infrastructure. This requires that the AR2200 provide the network address translation (NAT) function to translate private IP addresses into public IP addresses, and is a feature that is commonly applied to facilitate internal network communications over PPPoE
IP packets have a maximum payload size of 1500 bytes, however when used together with PPPoE, it requires an additional 6 bytes, as well as another 2 bytes for the PPP protocol ID, that causes the size of the packet to exceed the maximum supported payload size. As such the LCP negotiated MRU of a packet supporting PPPoE must be no larger than 1492 bytes.
The dialer bundle command binds the physical interface to the dialer interface that is used to establish the PPPoE connection.