Home > Articles > Delivering Broadband Access Today: An Access Technologies Primer

Delivering Broadband Access Today: An Access Technologies Primer

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jan 21, 2005.

Contents

  1. Architecture 1: Bridged Access Networks
  2. Architecture 2: Point-to-Point Protocol Networks
  3. Summary

Chapter Description

This chapter explains the infrastructure required to provide broadband internet access to customers. DSL, cable, and Ethernet technologies are covered, and the respective network systems that are required to serve internet in these environments is explained.

Architecture 2: Point-to-Point Protocol Networks

Dial-up access was the first remote-access mechanism and PPP was extensively enhanced to work in this environment. Because of this long deployment experience, PPP is a very mature solution that includes a rich control plane that lends itself to wholesale services. PPP is a more complex protocol than simple bridging, and this additional cost is incurred both on the client stack and on the router.

The following sections look at the variants of PPP used in broadband networks. PPPoE, by far the most prevalent variant today, involves a very simple bridging CPE. As you will see, the PPP session can be initiated from a PC. PPPoA is less common and usually (but not always) the session is initiated from a router.

PPP over Ethernet—The CPE as a Bridge

PPPoE is an interesting protocol. As the name implies, it involves a PPP session running over an Ethernet MAC layer. PPPoE is interesting because PPP was created for point-to-point interfaces, so it needed some enhancements to allow it to run on broadcast media. These enhancements included a discovery process very like the one in DHCP, which serves to establish a logical point-to-point relationship between a PPPoE client and server. All this can sometimes be confusing until you realize that PPPoE is really a superset protocol of PPP in which there is a supplementary setup protocol that runs before regular PPP starts. Cisco IOS debug output shows this really well.

Although the explanation that follows is DSL based, PPPoE is also a perfectly valid possibility for cable and ETTX networks. Figure 2-14 and the list that follows describe PPPoE operation in more detail.

Figure 14Figure 2-14 PPPoE Protocol Operation

The PPPoE protocol starts before a PPP session comes up, as follows:

  1. A host broadcasts an Active Discovery Initiation packet, called a PADI.

  2. In theory, a number of different servers (called Access Concentrators in the RFC) can now reply with an Active Discovery Offer packet, or PADO. In the case of DSL, all the Ethernet traffic is bridged across an (point-to-point) ATM virtual circuit by the bridged CPE to a single aggregation router, which is, in fact, the PPP Access Concentrator, so it is hard to imagine a host receiving more than a single PADO on an operational network. However, it is possible. Depending on the implementation of the PPPoE stack on the client, the client may accept only the first PADO returned, or the first PADO returned with the service it wishes to connect to.

  3. The host sends an Active Discovery Request (PADR) packet to a single Access Concentrator.

  4. The handshake completes when the Access Concentrator sends an Active Discovery Session-confirmation (PADS) packet, which contains a session ID. In the fairly rare case where the Access Concentrator and host are on a broadcast network, this session ID establishes a logical point-to-point connection (The combination of the host MAC address and session ID is unique on the server.)

  5. Standard PPP negotiation starts, with LCP and IPCP, just as for point-to-point serial connections.

  6. Either side can terminate the session with an Active Discovery Terminate (PADT) packet. This is equivalent to cutting a wire because no more traffic is passed, not even to close the upper-layer PPP session.

Figure 2-15 shows the Ethernet payload for PPPoE.

Figure 15Figure 2-15 PPPoE Header (Source: RFC 2516)

Packet flow is very simple. Each subscriber is terminated on the PPP peer using a virtual-access interface. Just as with dial-up operation in Cisco IOS, these interfaces are cloned from virtual templates. All traffic is routed by the aggregation router to and from each subscriber, often referred to as hair-pinning. Host routes are also automatically created for each subscriber. The router treats each virtual access as a directly connected interface, and routing table entries are marked appropriately (with a letter C in a show ip route command). Figure 2-16 shows the packet encapsulations used at different points of a PPPoE network.

Figure 16Figure 2-16 PPPoE Network Cross Section

PPPoE Configuration

The PPPoE protocol runs over Ethernet frames. The host sends PPP packets in Ethernet frames, which are in turn segmented by the bridge CPE into ATM cells and sent onward over the DSL network. There are two Ethernet type values for PPPoE: 0x8863 for PPPoE discovery and 0x8864 for the actual PPPoE data sessions.

PPPoE is configured in two parts on a Cisco IOS router. The first part involves creating a PPPoE server. The second part is the standard configuration for PPP. Figure 2-17 shows the typical PPPoE architecture.

Figure 17Figure 2-17 PPPoE Architecture

Example 2-14 demonstrates how you would configure a network such as the one shown in Figure 2-17.

Example 2-14 PPPoE Configuration

vpdn enable
! configuration for pppoe server
! interfaces for sessions will be cloned from virtual-template 1
vpdn-group 1
 accept dialin
 protocol pppoe
 virtual-template 1
! enable pppoe on this subinterface
! subscriber interface
interface ATM0/0/0.132 point-to-point
no ip directed-broadcast
pvc 1/32
 encapsulation aal5snap
 protocol pppoe

! virtual template for pppoe virtual-access interfaces
! note MTU size adjustment
interface virtual-template 1
ip unnumbered loopback0
no ip directed-broadcast
ip mtu 1492
peer default ip address pool pppoe-pool
ppp authentication pap
! pool of addresses for pppoe subscribers
ip local pool pppoe-pool 192.168.10.10 192.168.10.100

Example 2-15 shows the PPPoE configuration for the network in Figure 2-16 using Ethernet instead of ATM subscriber interfaces.

Example 2-15 PPPoE Configuration

vpdn-group pppoe
accept-dialin
protocol pppoe
virtual-template 1
!
interface FastEthernet2/0.2
encapsulation dot1Q 2
pppoe enable
!
interface FastEthernet2/0.3
encapsulation dot1Q 3
pppoe enable

NOTE

Examples 2-14 and 2-15 use vpdn-group commands. In more recent versions of Cisco IOS, this syntax has been changed to use the newer bba-group commands. Chapter 6 shows how to use bba-group, but a lot of networks still run Cisco IOS images that have vpdn-group, which is why those commands are shown here and in Chapter 3, "VPNs in Broadband Networks."

PPPoE Service Selection and Discovery

Another innovation in the PPPoE protocol is the use of PADS messages to advertise services to clients. The premise behind this use is that each host potentially is subscribed to multiple network-based services and needs to choose between them or, alternatively, to discover the list of subscribed or permitted service names. Example services might include a public Internet connection, a private VPN connection, and an extranet managed by a financial institution. To switch between each service, the end customer must have some way of identifying and selecting the service in the first place. Similarly, to subscribe to a brand new service, there has to be some way to inform the customer that it exists.

It is possible to do service selection using PPPoE. To do this, the PPPoE Access Concentrator sends a list of available service names (such as Internet, VPN, SafeShopping) to the PPPoE client. The client then displays the list of services to the user, who can chose whichever one she wants to use.

From an architecture perspective, PPPoE service selection poses an interesting quandary. In the DSL reference model, only ISPs sell services to end users. Yet here is a protocol that only the wholesale providers (the Access Concentrator is a PTT device) can typically use to announce services they do not typically sell to customers they do not typically own.

That said, there is a proposal at the IETF that would allow just the PADS messages to be carried over L2TP. This would allow the ISP's network server to terminate the PPPoE protocol and manage service announcements, which is probably a more logical arrangement from a business perspective. The Cisco implementation is called PPPoE Relay.

PPP over ATM: The CPE as a Router

PPPoA was first standardized at the DSL Forum. It is commonly used, but not as widely as PPPoE. PPPoA is actually simpler than PPPoE because there is no need for any of the extensions, such as discovery.

PPPoA can be run directly from a host with an ATM NIC card. This scenario is fairly rare in operational networks because Ethernet NICs are so much cheaper. Our discussion will focus on a CPE with PPPoA.

To higher-layer protocols, a PPPoA link appears as a routed connection, with remote peer authentication and the possibility of dynamic address assignment.

PPPoA Configuration

PPPoA runs over AAL5 MUX or SNAP encapsulation. The CPE runs IP on its LAN interface and PPP as the link layer protocol on the ATM WAN interface, as shown in Figure 2-18.

Figure 18Figure 2-18 PPPoA Network Cross Section

As soon as the PPP software detects that the ATM PVC is up, it tries to establish a session in classic PPP fashion. The router sends an LCP request, then changes state to authenticate and remains in this mode until either authentication succeeds or it times out. In case of timeout, the process starts over until a session is opened. This behavior can be disabled using atm pppatm passive but it is on by default on Cisco routers.

PPP Address Assignments

During PPP session negotiation, the client typically requests an address from the router. The router can find an address in one of several places. Either an ip pool is configured on the router, as in our example, or an address (or pool, for that matter) must be downloaded from a RADIUS server. (There is also the option of allowing the remote peer to keep its address, using ip address negotiate on the virtual template.)

The address download options are as follows:

  • Download of a single address

  • Download of a pool name

  • Download of a pool at startup

  • Use of On-Demand Address Pools

Download of a Single Address

When downloading a single address from RADIUS (using, for example, the framed-ip-address attribute), preference is given to downloaded attributes over parameters configured from the command line.

Example 2-16 shows how to use this attribute in a subscriber profile.

Example 2-16 Framed-IP-Address RADIUS Profile

jondoe Password = "cisco"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    Framed-IP-Address = "192.168.11.1"

There are some special values for framed-ip-address that you should remember. If the AAA server returns a value of 255.255.255.254, that is an instruction to the router to fetch a dynamic IP address for this subscriber. In other words, the AAA server says to the router. "I want you to find a dynamic address for this subscriber." The router will probably do this using DHCP, and Example 2-17 shows the little bit of magic you need to combine DHCP and AAA.

Example 2-17 Pools with DHCP

! global command
ip dhcp-server 1.1.1.1
!
interface virtual-template 1
peer default ip address pool dhcp

Download of a Pool Name

In this scenario, a pool is already configured on the router and the RADIUS server just has to tell the router which one to use.

On the router, you would need the configuration in Example 2-18, with a virtual-template that does not have a pool name (or that would override the one coming from the RADIUS server) and a standard ip address pool.

Example 2-18 Downloading Pool Names Router Configuration

!Note no pool name
interface virtual-template 1
description PPPoE Clients
ip unnumbered loopback0
ppp authentication chap pap
ip local pool FOO 192.168.10.10 192.168.10.100

The corresponding AAA profile with a pool name would look like Example 2-19.

Example 2-19 Downloading Pool Names RADIUS Profile

janedoe Password = "cisco"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    av-pair = "ip:addr-pool=FOO"

Download of a Pool at Startup

This trick is very similar to using AAA to download IP routes, in which case a Cisco IOS router can be configured to read static routing entries from an AAA server when it starts up. (The configuration is a little esoteric.)

The router is configured with a name that it uses to issue a RADIUS Access-Request at startup. The Access-Accept reply from the server includes one or more pools of IP addresses. These can be referenced in subscriber AAA profiles just as if they had been configured on the router. If a subscriber references an unknown pool, the router tries to download the complete list again. Example 2-20 shows how to activate this behavior in Cisco IOS. The router now sends an Access-Request using the name load-pools.

Example 2-20 Downloading Pools Router Configuration

! add this to the router configuration
aaa configuration config-username load-pools

Now the RADIUS server needs a user profile that uses the same name as the router does, which is the case of the RADIUS profile in Example 2-21.

Example 2-21 Downloading Pools RADIUS Profile

nas1-pools Password = "cisco"
    Service-Type = Outbound-User,
    av-pair = "ip:pool-def#1=BAR 1921.168.11.10 192.168.11.100"

You can use these downloaded pools just like you do an IP address pool. Example 2-22 shows an example with a virtual-template configuration with a pool called BAR that was defined in Example 2-21.

Example 2-22 Using Downloaded Pool Definitions

interface virtual-template 2
description PPPoE Clients
ip unnumbered loopback0
peer default ip address pool BAR
ppp authentication chap pap

Use of On-Demand Address Pools

On-Demand Address Pools (ODAP), which is discussed in more detail in the Chapter 6, "Wholesale MPLS-VPN Related Service Features," is a powerful mechanism to allow a router to request IP pools dynamically from a DHCP server as existing ones are used.

All the techniques just described are well and good, but they let you allocate only a single host address (or pool from which a single address will be handed out to the host). What about the case of home networks with a broadband router connected to many different home computers? For that, the service provider needs other techniques, such as the following:

  • CPE PAT—The CPE uses port address translation (PAT) to map many private host addresses to the single, public address assigned during PPP session negotiation.

  • IPCP subnet mask—The CPE is assigned an IP subnet mask and an address during PPP session negotiation. It takes the first address of this subnet for its WAN interface and uses the rest of the pool to do network address translation (NAT) of host addresses. It is not possible to assign these addresses using DHCP, or else two links would be on the same IP subnet.

As usual, the subnet mask can either be configured on a b or in AAA. To make the IPCP subnet option work, you need to coordinate the aggregator, the CPE, and the AAA server.

Example 2-23 shows the configuration needed on the aggregation router.

Example 2-23 IPCP Subnet Mask Router Configuration

interface Virtual-Template2
ip unnumbered Loopback0
no peer default ip address
ppp authentication pap chap
ppp ipcp mask 255.255.255.240
!

Example 2-24 shows the configuration on the CPE, which needs to ask for the subnet mask when it brings up its PPP session.

Example 2-24 IPCP Subnet Mask CPE Configuration

!
interface Dialer 0
ppp ipcp mask request

Finally, Example 2-25 shows the RADIUS profile, which has a regular framed-ip-address, but also a subnet mask in the framed-ip-netmask attribute.

Example 2-25 IPCP Subnet Mask RADIUS Profile

CPE Password = "cisco"
Service-Type = Framed,
Framed-Protocol = PPP,
Framed-IP-Address=192.168.2.1
Framed-IP-netmask=255.255.255.248

PPP Quality of Service

There are two things to understand regarding QoS on PPP links: what type of QoS is supported and how to provision it.

One detail needs clarification at the outset: IP QoS on PPP interfaces is not as complete as on other Layer 2 interfaces. Depending on the actual router you are using, you can have classification, marking, and policing but probably not queuing. Of course, PPP runs on top of another Layer 2 interface and you can use the complete range of ATM CoS for DSL subscribers, for example. In each case (i.e., Layer 2 under PPP, or Layer 3 on the interface itself), use the classic Cisco IOS commands that were covered earlier in the chapter.

Provisioning QoS for PPP is a little different. Think first about what layer you are going to use to do the QoS and what type of QoS you need. Is it the policing at the ATM layer? Or classification at the IP layer? IP QoS commands, such as the service-policy command in Example 2-2, should go under the virtual-template on the router. ATM QoS parameters go under the PVC block. As with most things in PPP, you can provision QoS at either of these layers in a RADIUS profile.

Dynamic Bandwidth Selection (DBS) is the name of the Cisco IOS feature that lets you set a subscriber's ATM CoS profile using RADIUS. The idea behind the name is that a service provider would define different policies for subscribers: one for basic Internet access, one for VoIP, and so on. If there are different profiles predefined in RADIUS, then all the subscriber needs to do is to connect with a new username to get the new and improved QoS on his circuit. Using DBS means that the service provider operations team doesn't have to configure anything in the network as customers change back and forth between different levels of QoS.

Example 2-26 shows how to enable the DBS feature in Cisco IOS under an individual PVC, followed by Example 2-27, which gives the specific DBS RADIUS attributes.

Example 2-26 DBS Router Configuration

interface atm0/0/0.5 point-to-point
 ip address 192.168.2.1 255.255.255.0
 pvc 1/100
 dbs enable
 encapsulation aal5snap
 protocol ppp virtual-template1

Example 2-27 DBS av-pairs RADIUS Profile

Cisco-Avpair = "atm:peak-cell-rate=155000"
Cisco-Avpair = "atm:sustainable-cell-rate=155000"

The AAA parameters in Example 2-26 set the peak cell rate, which is mandatory and a sustainable cell rate. It behaves as UBR if only the PCR is given; otherwise it operates as a VRB-nrt circuit.

There is a similar set of special RADIUS attributes that let you download IP policing parameters to the aggregation router.

All in all, PPP is a little blunt when it comes to QoS support. With bridged access, there are very clear ways to map QoS policy between the IP layer and the transport layers, all of which have a good level of native QoS. The extra PPP layer blinds the access network, which cannot look into the PPP packets to know what QoS level to apply to the frames: There is no QoS marking in the PPP header and the original IP header is too deeply encapsulated to be able to look for the DSCP settings in hardware. In fact, all you are really doing with PPP QoS is prioritizing traffic on the aggregation router itself. None of the devices downstream (i.e., those between the aggregator and the subscriber) can automatically change its CoS settings if a subscriber uses a different DBS profile: This is not end-to-end QoS. Bridged access does offer, or is closer to offering, end-to-end QoS.

DSL Forum has been especially active in working on a new model that supports true multiservice traffic throughout the network, not just on the aggregation router. Interested readers should look for WT-59–related documents on the DSL Forum web site at http://www.dslforum.org.

PPP Authentication, Accounting, and Security

PPP has excellent authentication and accounting support. Millions of broadband and dial-up customers around the world use PPP for their Internet connection. The beautiful thing with PPP is that subscriber configuration can be centralized on a RADIUS server, which is a much more scalable way to run a network than to have to configure the devices independently. PPP is very well documented in other books, so the details are not going to be covered here, with the following two exceptions:

  • PPP port-based authentication

  • PPP security

Port-Based Authentication

Configuring a username in AAA for the CPE might seem easy to do but is in fact very awkward, because it means having a different username configured for each and every CPE. If a subscriber changes CPE, the username would have to be updated on the new device to make sure that the subscriber still gets the correct IP address. Rather than go to the pain of maintaining such a database, wouldn't life be easier if a CPE could be authenticated using the subscriber circuit ID? Happily, this is possible. The syntax on the router is radius-server attribute nas-port format d.

This simple statement makes the router include the circuit ID in the Radius NAS-port field. The format for ATM, which makes this value globally unique, is IP address/module/port/VPI/VCI. A corresponding format exists for Ethernet and VLANs (even QinQ) also. Obviously, the RADIUS server must support this.

PPP Security

Bridged access security is complex because it involves many subscribers who are all part of the same broadcast domain. Regardless of the actual tricks, DSL, cable, and Ethernet networks have many different bells and whistles to limit the broadcast domain as much as possible, ideally to a single subscriber.

PPP architectures just don't have this problem, because the subscriber links are actually routed interfaces and the aggregation router knows which address it assigned to whom. This removes a lot of the risk of IP and MAC layer spoofing, especially of the variety that lets one subscriber attack their neighbor because of weaknesses in the aggregator or the broadband architecture itself. It's important to be realistic here: suitably motivated subscribers at the other end of a PPP session can launch DoS and other nasty attacks. However, because the architecture provides a point-to-point link for each and every subscriber, there is inherently more security than on a network in which subscribers share the same Layer 2 segment.

You should remember the basic best practices for securing PPP connections and use CHAP authentication for the actual session itself. Also, protect the aggregation router. A PPP subscriber can still mount an attack against the default gateway. Ironically, PPP isn't as well served as Ethernet (but it doesn't have the same risks of ARP- and broadcast-based attacks), but URPF and NetFlow are also really good techniques to use in PPP architectures. A PPP-specific attack would be to launch a DoS attack against the RADIUS server by opening a gazillion sessions, or opening and closing them constantly. Cisco IOS can limit the number of sessions per connection or per MAC address, and this is a good feature to turn on. Perhaps best of all, RADIUS billing records provide a great way to track unusual usage back to an individual subscriber—even if he spoofs IP addresses and blasts a week's worth of traffic in a couple of hours, his billing record will show the volume of traffic sent over the subscriber line (ATM VC or Ethernet port).

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020