Chapter 6: IP Location in Wireline Public Carrier Networks

In the previous chapter, we examined location determination and acquisition techniques that can be applied to enterprise IP networks. In this chapter, we will look at location determination and acquisition techniques for residential broadband networks, and specifically focus on DSL and cable networks.

Digital Subscriber Line (DSL) Networks

DSL is the fastest growing technology, enabling the deployment of residential broadband networks globally. By the end of 2005, there were 139 million DSL subscribers worldwide and 48.2 million subscribers in Europe, while China, the Middle East, and Africa all had growth rates above 100 percent. This fantastic growth rate has largely been due to DSL's ability to work over existing copper telephone lines that run to most houses in urban areas throughout the world.

DSL uses special modems at each end of the phone line that make use of the bandwidth available in the wires that is not used for conventional voice traffic. This allows a residence to have high-speed Internet connectivity and a normal telephone service at the same time over the same copper pair. At the telephone exchange, the DSL signal is separated from the voice traffic and ultimately routed through the subscriber's ISP.

Incumbent telephone companies have a preference toward DSL broadband since it enables them to make use of existing copper cables to provide next-generation network access at a fraction of what it would cost to install new purpose-built cable plants (see Figure 6.1).

Figure 6.1: Basic DSL deployment.

It should be noted that DSL networks are evolving, and that the responsibilities of nodes, and the interfaces between them, are changing. This section provides a cursory overview of the responsibilities and interfaces between nodes only. For intricate details about any specific issue concerning DSL networks, the reader should refer to the DSL forum web site at www.dslforum.org/index.shtml.

DSL Entities

DSL networks often require the cooperation of several organizations in order for a service to be delivered. This is because different aspects and functions may reside in the different organizations and all are required for any connection to be established and maintained. The DSL forum is the internationally recognized organization that is responsible for formulating architectures and recommendations for DSL networks. The main entities required to establish and maintain a DSL connection that have been identified by the DSL forum are shown in Figure 6.2, while the complete architecture is detailed in the DSL Forum's Technical Report (see Reference 1 at the end of the chapter). The entities shown in Figure 6.2 are described in detail next. The loop provider is responsible for:

• Providing a physical loop from the local network equipment to the customer's premises

• The integrity of the physical loop and its repair

• Granting the access network provider aggregated access to remotely deployed DSL equipment owned, operated, and maintained by the loop provider

Figure 6.2: DSL access entities.

The access network provider is responsible for:

• Providing digital connectivity to the customer via the physical loop

• The performance and repair of the access transmission equipment

The regional network provider is responsible for:

• Providing connectivity between the access network and Internet service providers.

• Regional network performance and repair

• Possibly performing aggregation services to Internet service providers and/or providing any connectivity within the regional broadband network on behalf of the Internet service providers

The regional/access network provider (RANP) is responsible for:

• Aggregating subscriber traffic and/or routing and forwarding traffic throughout the network

• Aggregating subscriber traffic to ISPs for IP address allocation and network authentication

The Internet service provider (ISP) is responsible for:

• Overall service assurance

• Providing or specifying required CPE and software to support a given service

• Being the customer contact point for any and all customer-related problems concerning the provision of the service

• Authenticating customers for access

• Providing IP address to authenticated customers and managing IP address pools

DSL Interfaces

The previous section showed that several different organizational bodies may be required to provide DSL connectivity. In this section, we shall examine the main DSL interfaces as defined by the DSL forum.

A DSL network can be thought of as consisting of three main communications segments, with each segment running its own protocol stack to transport data around the network. These segments are the loop segment, the access segment, and the service provider segment, which are highlighted in Figure 6.3.

Figure 6.3: DSL segments.

The segments shown in Figure 6.3 are deemed the U-interface, the V-interface, and the A10-interface, respectively, by the DSL forum in Technical Report (see Reference 2). The DSL forum defines an additional interface, the T-interface, which runs from the DSL modem to a host device inside the customer premises. Where the customer premises are large-say an enterprise campus-then the location solutions described in Chapter 5 should be applied. Where the customer's premises are small, like a residential house, unit, or apartment, then the T-interface is of little consequence with regards to location. This is because the same location can be applied to the modem and to all hosts directly connected to it. As a result, the T-interface is not described further in this document.

The U-Interface

The U-interface is associated with the loop segment, which provides the connectivity between the DSL modem and the Access Node (DSLAM). Seven protocol stacks are defined in the DSL forum, and run over two transport variants, either ATM over DSL, or Ethernet over DSL. They are shown in Figure 6.4 and are described in detail in Reference 3 and Reference 4.

Figure 6.4: U-Interface protocol stacks.

Most DSL residential broadband routers will run IP over Ethernet (IPoE), PPP over Ethernet (PPPoE), or PPP over ATM (PPPoA). These equate to stacks 1 and 5 for IPoE, stacks 2 and 6 for PPPoE, and stack 4 for PPPoA. Since these stacks represent the vast majority of residential broadband deployments, these stacks will be the ones used for examples in this chapter.

The V-Interface

The V-interface is associated with the access segment which provides the connectivity between the Access Node (DSLAM) and Regional Aggregator. Generally, the V-interface uses an ATM or Ethernet transport. ATM is the more traditional means of providing connectivity from the DSLAM to the core network. This is achieved by having one Permanent Virtual Circuit (PVC) established from the DSLAM to the Aggregator for each DSL port on the DSLAM. Ethernet is becoming more common and is generally preferred in newer DSLAMs. In networks that use an Ethernet U-interface, traffic stream segregation is maintained through the use of VLANs. As will be shown in later sections, there are several ways that VLANs can be used to keep data streams orthogonal between the DSLAM, the Aggregator, and ultimately the ISP.

The A10-Interface

The A10-interface is associated with the service provider segment which provides connectivity between the Aggregator and the ISP. The three protocol stacks supported over the A10-interface are shown in Figure 6.5, and all are described in examples later in this chapter.

Figure 6.5: A10-interface protocol stacks.

Protocol Background

Before we further explore DSL, it is very important to be grounded in some of the protocols used in the DSL protocol stack. Many of the public Internet providers have their roots in dial-up, and dial-up used serial point-to-point (PPP) connections. ISPs generally use a central database to manage user authentication and configuration profiles, user session establishment includes querying the profile database using RADIUS to authenticate the user and obtain configuration parameters to complete the connection. The growth of Ethernet and the shear volume of PPP and RADIUS deployments resulted in the need to encapsulate PPP packets into Ethernet frames. This is referred to as PPP over Ethernet (PPPoE).

This section is a quick tutorial/introduction to PPP, PPPoE, RADIUS, and RADIUS accounting. Understanding what these protocols are, how they evolved, and why they are pertinent today will help greatly with understanding the subsequent sections describing DSL location determination and acquisition. The introduction concludes with a cursory look at the Layer 2 Tunneling Protocol (L2TP), and the RADIUS and RADIUS accounting extensions required to support it.

Point-to-Point Protocol (PPP)

Point-to-Point Protocol (PPP) is not a single protocol but a suite of protocols consisting of literally dozens of specifications. We are not interested in all of them however, only a very few select ones. The base PPP specification is defined in Reference 5 and describes PPP as a protocol designed for transporting multiprotocol datagrams over point-to-point links. The base PPP specification describes PPP encapsulation and Link Control Protocol. Support for network-layer protocols is provided in PPP through network control protocols (NCPs) that are established across the link after the link has been configured and tested, and often after a peer has been authenticated.

The encapsulation mechanism in PPP is simple, and is designed for the peers to easily determine which protocol a specific packet is destined for. The general encapsulation model is shown in Figure 6.6.

0 1 2 3 4 5 6 7 8 9 A B C D E F	0 1 2 3 4 5 6 7 8 9 A B C D E F
Protocol	Protocol Message Data
Protocol Message Data (Cont) [*]
Padding [**]
[*]Protocol message may be up to the maximum receive unit MRU size for the protocol. By default, this is 1500 Octets. [**]Padding is optional, Padding + Protocol Message Data must not exceed MRU.

Figure 6.6: PPP data encapsulation.

PPP consists of a number of phases. The first phase is the link establishment phase. In order to establish communications over the link, it needs to be configured and tested, this is done using the Link Configuration Protocol (LCP).

One of the things that a peer can request during the link establishment phase is that authentication occur. This actually occurs after the establishment of the link using the PPP authentication protocols, of which the two most common are password authentication protocol (PAP) and challenge handshake authentication protocol (CHAP). PAP and CHAP are defined in Reference 6, with CHAP being later updated in Reference 7.

After the link has been established and peers have authenticated one another, the peers can request to start using other network-layer protocols such as IP. This is done through configuring a network control protocol (NCP). The NCP for the Internet Protocol is called Internet Protocol Control Protocol (IPCP) and is defined in Reference 8. IPCP follows a similar message sequence to LCP, and will not be described in detail here except to say that it supports assignment of an IP address and identification on DNS servers amongst other things. After the IPCP NCP is configured, then peers can start to exchange IP datagrams. IP datagrams are encapsulated as shown in the previous figure, by setting the protocol value to 0x0021, and placing the datagram itself into the protocol message data section of the PPP payload.

PPP over Ethernet (PPPoE)

PPP over Ethernet (PPPoE) is documented in Reference 9, and used extensively in ADSL deployments. PPPoE consists of two main parts, a peer discovery part, and a PPP establishment part. Discovery is required because PPP is a peer-to-peer protocol and it is necessary for an Ethernet host to first find a peer with which it can establish a relationship.

PPPoE Discovery

PPPoE functions follow a client/server model in the discovery stage, with the client being a host or DSL modem, searching for a server (access concentrator AC) and establishing a session with that server.

1. The client discovers the AC by sending out a broadcast message called a PPPoE Active Discovery Initiation (PADI) packet. A PADI packet can include data passed from the client to would-be ACs specifying options that the client needs, or certain characteristics of the client. These are specified in what are referred to as Tags. A PADI request providing information about the point of attachment of a client would look something like Figure 6.7.

2. Any ACs that see this message then respond with a PPPoE Active Discovery Offer (PADO) packet indicating that they can service the client. This response is unicast addressed to the client's Ethernet address.

3. The client will select one of the AC responses. The client will use the MAC address of the selected AC response to identify the AC as its peer.

4. The client determines the service-name to request from the AC, and along with other options places them in a PPPoE Active Discovery Request (PADR) packet. The client sends the PADR packet to the selected AC in hopes of establishing a session. This is a unicast Ethernet packet and is sent to the MAC address of the selected AC.

5. The AC receives the PADR packet and generates a unique SESSION_ID for the PPPoE session and returns this in a PPPoE Active Discovery Session (PADS) confirmation packet to the client. This packet is addressed to the client's MAC address. A SESSION_ID of 0 is returned if the AC cannot provide the requested service-name.

6. The two peers, the client and the AC, have each other's MAC addresses and share a common SESSION_ID. The PPP stage can begin at this point.

7. Either peer can terminate the session by sending a PPPoE Active Discovery Terminate (PADT) packet.

0 1 2 3 4 5 6 7 8 9 A B C D E F		0 1 2 3 4 5 6 7 8 9 A B C D E F
0xFFFFFFFF
0xFFFF		Host MAC Address
Host MAC Address (cont)
ETHER_TYPE = 0x8864		0x01	0x01	Code = 0x09
SESSION_ID = 0x0000		LENGTH = 0x2C
TAG_TYPE = 0x0105		LENGTH = 0x28
0x00000DE9 (ADSL Forum Vendor Tag)
0x01	Len = 0x22	Circuit-ID
Circuit-ID (cont)
Circuit-ID (cont)
Circuit-ID (cont)
Circuit-ID (cont)
Circuit-ID (cont)
Circuit-ID (cont)
Circuit-ID (cont)
Circuit-ID (cont)

Figure 6.7: PPPoE PADI message with TAG.

PPP Session Establishment

Once the PPPoE session is established, then PPP session negotiation can occur. PPP data are encapsulated into Ethernet packets that are addressed directly to the AC, and the SESSION_ID must be set to the value that was assigned in the PPPoE discovery stage. A typical Ethernet frame carrying a PPP pay-load therefore would be similar to Figure 6.8.

0 1 2 3 4 5 6 7 8 9 A B C D E F	0 1 2 3 4 5 6 7 8 9 A B C D E F
Access Concentrator's MAC Address
Access Concentrator's MAC Address (cont)	Host MAC Address
Host MAC Address (cont)
ETHER_TYPE = 0 × 8864	Version = 1	Type = 1	Code = 0 × 00
SESSION_ID	Length = 0 × ?????
PPP Protocol = 0 × C021	PPP Payload ……

Figure 6.8: PPPoE data encapsulation.

RADIUS

The Remote Authentication Dial In User Service (RADIUS) was designed to support network access servers (NASs) managing large numbers of PPP sessions for users connected over dial-up modem lines. This support allows the NAS to query a central database to authenticate users against a known profile and receive parameters necessary for connection establishment.

RADIUS is a client-server protocol and is defined in 10, with extensions to RADIUS being defined in Reference 11. A RADIUS client (normally the NAS) must have a preexisting relationship with a RADIUS server, which is achieved through the use of a shared secret. RADIUS is based on UDP, consequently each packet exchanged between the client and server must be authenticated by the originator. The general steps in using RADIUS are as follows:

1. Client determines that user authentication is required and what services are needed. The client generates an Access-Request message which contains the set of attributes identifying what data are known and what data are required in order to establish a data connection. Some common attributes included in Access-Request messages are:

    User-Name User-Password NAS-IP-Address NAS-Identifier NAS-Port NAS-Port-Id NAS-Port-Type Framed-Protocol 

2. The RADIUS server authenticates the NAS using a shared secret password. Assuming that the NAS is authenticated, the RADIUS consults a database of user information and proceeds to validate the user data and assimilate the requested configuration data. The RADIUS server may validate the user based on a number of criteria, such as a username and password, a challenge-response, or the physical port on which the user attaches to the NAS. If the user is not validated, then the RADIUS server sends an Access-Reject message and the NAS takes the necessary actions. If the user is validated, then the requested data is returned to the NAS in an Access-Accept message. One attribute that we will be depending on in later descriptions is the Framed-IP-Address attribute, which is the IP address that the RADIUS server is assigning to the end user.

RADIUS was originally designed for users to dial into a local modem bank and access a local service. The nomadic nature of Internet users however quickly introduced the need for access roaming-that is, a user being able to access their home account while dialed in from a remote service provider. RADIUS accomplishes this through the use of proxies.

A RADIUS proxy resides in the remote network to which a user is physically connected, and is responsible for forwarding NAS RADIUS requests through to the home RADIUS server of the user. For this, two things are needed: first, the RADIUS proxy server must be able to identify the home RADIUS server or the user; and second, the RADIUS proxy server must have a shared secret with the user's home RADIUS server.

The introduction of standard network access identifiers (NAIs) defined in Reference 12, resulted in an expectation that usernames would be provided with a realm leading a fully qualified username, such as [e-mail], where example.com represents the realm. Using this notation, a proxy RADIUS server is now able to easily identify the home RADIUS server or the user. Negotiation of shared secrets between the two organizations is an operational issue and is not described here.

In addition to requesting authentication and configuration services from a server and supporting user roaming, RADIUS supports the generation and supply of accounting attributes. These will be covered in the next section.

RADIUS Accounting

One of the functions supported by the RADIUS protocol is the ability for the NAS to generate accounting records for a specific session that can be used for statistical and/or billing purposes. RADIUS accounting is defined in Reference 13, with extensions provided in Reference 11.

At the start of service delivery, the NAS generates an accounting start record which describes the user and the type of service being provided. This record is sent by the NAS to a RADIUS accounting server in the form of an Accounting-Request message. The RADIUS accounting server will acknowledge the accounting request message with an Accounting-Response message.

Looking at the Accounting-Request message in more detail, the NAS provides an indicator as to what kind of information is included in the accounting message, this will typically be a start, stop, or interim update, though status values exist for failures, L2TP, and tuning accounting on and off. This information is conveyed through the Acct-Status-Type RADIUS attribute. This value is set to 1 to start an accounting session, 2 to stop an accounting session, and 3 to provide interim updates.

The other attribute that is somewhat crucial to RADIUS accounting messages is the Acct-Session-Id attribute, which is allocated by the NAS to allow accounting records to be correlated. Any RADIUS attribute may be sent in a RADIUS accounting message with the exception of the password values. As will be seen in later sections, dependency will often be placed on the User-Name, Framed-IP-Address, NAS-Identifier, and NAS-Port attributes.

At the conclusion of service, the NAS will send an Accounting-Request message with an Acct-Status-Type of stop to the RADIUS accounting server to indicate that the session has concluded. The NAS may include additional parameters that can be used for statistical and accounting purposes.

The Layer 2 Tunneling Protocol (L2TP)

The Layer 2 Tunneling Protocol (L2TP) is defined in 14, and while it is of some interest, the extension required to RADIUS and RADIUS accounting messages to support L2TP are of more interest since these contain the measurements that will be used to determine location in a later section. We shall briefly describe all three here.

L2TP was designed to support tunneling of PPP packets across a network in a manner transparent to end users and applications (see Figure 6.9). The system is comprised of an L2TP access concentrator (LAC) that resides in a local network, and an L2TP network server (LNS) residing in the home network. PPP sessions are initiated against the LAC, which tunnels the requests across to the LNS, where the PPP session is terminated and configuration values assigned.

Figure 6.9: L2TP network architecture.

A tunnel exists between an LAC and an LNS, and each assigns a tunnel identifier to the tunnel when the tunnel is created. The identifiers are different at each end, with the LAC sending messages to the identifier determined by the LNS, and vice versa. Sessions are created within the tunnels to facilitate data flows between two end-points. As with tunnels, session identifiers are assigned independently by the LAC and LNS, and are exchanged during session establishment. This means that the tunnels, and the sessions within the tunnels, can only be lined up between the two entities using internal state data. As we will see shortly, this makes it hard to get the information necessary to determine location.

To make L2TP work efficiently in existing network deployments, changes needed to be made to RADIUS, and subsequent RADIUS accounting messages. To support tunneling identifiers in RADIUS, new attributes were identified and these are documented in Reference 15. The attributes described in Reference 15 are for general tunneling applications; specific use of these attributes in L2TP is documented in Reference 16. To assist servers at either end of the tunnel to reconcile accounting records (see Reference 17), RADIUS accounting for L2TP, recommends that the user-name, account-tunnel-connection, Tunnel-Client-Endpoint, and Tunnel-Server-Endpoint attributes be included. As will be shown, these attributes provide us with the measurements necessary to determine location in DSL networks that deploy L2TP.

Location Determination and Acquisition in DSL Networks

This section will describe how the location of an end-point can be determined in DSL networks and how to subsequently make this location available to nodes that require it. Much of the information presented in this section is based on work that has been done in the U.S. National Emergency Number Association (NENA). This work was conducted to address the location determination and acquisition problems confronting residential broadband providers in the United States and Canada. This work is not definitive, it's descriptive, and deliberately ignores aspects of DSL networks relating to QoS and traffic type separation based on service type. The intention of this work is to show that the network correlators necessary to determine an end-point's location are present in network measurements available today over a variety of possible DSL deployment configurations.

Figure 6.2 illustrates the general DSL connectivity architecture, showing a clear separation between the network (Internet) service provider (ISP) and the region access network provider (RANP). The RANP owns the physical access and is responsible for delivery messages from the router to the ISP. The ISP is responsible for authenticating users, allocating IP addresses, and generally routing user data throughout the Internet. All of these functions are required to provide the DSL IP service. The information from both the ISP and RANP is required in order to determine the physical location of an end-point and associate it with an IP address. Remember that the end-point is essentially unaware of the RANP, and subscribes to the ISP for Internet connectivity. The ISP is able to allocate an IP address, but will likely have little direct information that will allow it to tie the end-point to a physical location. This information resides in the RANP. To provide location services in this environment, two LISes are required, a gateway LIS at the ISP that can serve as a point of contact, and a primary LIS based in the RANP that can provide location information. This is the general model that was derived within NENA and is shown in Figure 6.10. All of the configurations described in the subsequent sections are simply extensions of this model.

Figure 6.10: A generic DSL LIS configuration.

Figure 6.10 illustrates that the RANP LIS must be able to link all of the circuit information together in order to be able to determine the location of the end-point. In reality, the RANP LIS merely needs to be able to associate E with the location, and this may or may not require it to follow the circuit chain back to point A. Examples of how this chain is populated and followed will be shown in subsequent sections.

The connection between the ISP gateway LIS and the RANP primary LIS will likely be a nailed-up secure connection that is authenticated at connect time. The recommendation is that this connection be made on TLS, and the HELD protocol be used with a BEEP binding. The HELD protocol BEEP binding specification is provided in Appendix D.

IP Connectivity over the Service Provider Segment

In this configuration, the A10-interface uses the first protocol stack shown in Figure 6.5, and data are directed from the RANP Aggregator to the ISP NAS using IP routing. Figure 6.11 illustrates the setup and information flow for this configuration using ATM as a transport from the end-point to the ISP.

Figure 6.11: IP routing over the A10-Interface using ATM and RADIUS.

At first glance, Figure 6.11 appears complex. This is because there are several different data flows and operations represented in the diagram, and all are required in order to establish an IP connection from the host to the ISP so that the location of the host can be determined. To simplify things we will describe the system in parts, starting with provisioning.

Connectivity flows from the Location, on the lower right-hand side, to the Aggregator in the lower left-hand side of Figure 6.12. In this configuration, the connectivity is established over ATM using a series of Permanent Virtual Circuits (PVCs) between the various switching stages:

1. PVC-1 extends from the home router to the DSLAM.

2. PVC-A extends from the DSLAM to an ATM switching network.

3. PVC-B extends from the ATM switching networks to the Aggregator.

Figure 6.12: Switch and RANP-LIS provisioning.

 NOTE: Most DSL services use a default set of vpi/vci values for all modems connected to the DSLAM. Values commonly used are 0/35, 8/35, 0/38, and 0/32. Using common vpi/vci values on the DSLAM reduces the amount of per-port provisioning that is required by the DSLAM operator.

These PVCs form a fixed chain that must be provisioned and established between the switching nodes in order to facilitate higher-layer protocol connectivity through the network. Since the PVCs are established through provisioning, an extension of this data can be used to populate the RANP-LIS using an OSS provisioning system. This allows the RANP-LIS to perform PVC-to-physical location associations.

Similarly, the ISP-LIS needs to know how to associate incoming circuit identifiers to a specific RANP-LIS. This is again done through provisioning.

Now, let's look at how the session is established from the end-point to the ISP, and how network measurements can be obtained to aid the LISes in determining the location of the end-point. This is depicted in Figure 6.13 with the session establishment being described in detail in the DSL Forum document (see Reference 18).

1. The end-point initiates a PPP session as defined in Reference 5 with authentication, as defined in Reference 6. For the example, let's assume Password Authentication Protocol (PAP), though CHAP can equally well be used. The end-point sends its fully qualified username, [e-mail], and its password in the session establishment.

2. The Aggregator terminates the PPP session and forwards the session establishment messages, along with the Aggregator identifier (NAS-Identifier) and incoming port information (NAS-Port) to a proxy-RADIUS server running in the RANP's domain. RADIUS is defined in Reference 10.

3. The RANP's RADIUS server uses the domain component of the fully qualified username, domain.com, in the preceding example to determine which ISP RADIUS to proxy the request to. The RANP's RADIUS server forwards the PPP session establishment messages to the ISP RADIUS server for authentication and IP address assignment.

4. Assuming that the user is authenticated by the ISP RADIUS server, an IP address, along with other configuration data are returned to the RANP proxy-RADIUS server. The ISP RADIUS server will also generate a RADIUS accounting message (RADIUS Accounting is defined in Reference 13) that indicates, amongst other things, that a particular user has signed on, is using a specific IP address, and that their connection is coming via a specific BRAS. This information can be processed by an ALE, built to analyze RADIUS accounting messages, and forwarded to the ISP LIS. This provides the ISP LIS with the data necessary to identify the RANP-LIS that has the association between IP address and location for a given end-point.

5. The RANP proxy-RADIUS server will generate a RADIUS accounting record on receipt of the configuration data from the ISP RADIUS server. This accounting record will include the incoming NAS-Identifier (the BRAS), the incoming port, the allocated IP address, and possibly the outbound port from the BRAS to the ISP NAS. Similar to what occurred at the ISP, a RADIUS ALE can process the RADIUS accounting messages and send the data to the RANP-LIS. At this point, the RANP-LIS can associate an IP address with an incoming BRAS (NAS-Identifier) and port on the BRAS (NAS-Port). Earlier in this section, we showed that the NAS-Identifier and NAS-Port information needs to be provisioned into the BRAS and, furthermore, needs to be associated with a dedicated PVC. The RANP-LIS now has the linkages it requires to associate an IP address with a location.

Figure 6.13: A session establishment and measurement collection.

Thus far, we have looked at how to establish a DSL session and how to obtain the parameters and correlators that will permit a LIS to determine the location of an endpoint. Now, it's time to look at a location request (see Figure 6.14).

Figure 6.14: Requesting location.

Let's assume that the HELD client running on a host inside the home network has discovered the ISP LIS using the mechanism described in Chapter 4.

1. The HELD client then launches a location request to the ISP LIS. The NAT inside the home router changes the source IP address of the outbound message to have the IP address of the home router. This is good, since it's the IP address that the ISP-LIS knows about.

2. The ISP-LIS receives the location request and verifies that the source IP address of the message is indeed an IP address that has been allocated by the ISP for use. The ISP-LIS looks up the address of the RANP through which the location request message came. The ISP-LIS is then able to determine the RANP-LIS to query for the location information. The ISP-LIS sends a location request to the RANP-LIS over the Trusted-Party Query Interface, and using the HELD identity extensions defined in Appendix E, it includes the IP address of the host that it wants the location of.

3. The RANP-LIS uses provisioned data and data that it obtained from the RADIUSALE to map the IP address through a chain of PVCs to a physical location. The RANP-LIS constructs a PIDF-LO and returns it to the ISP-LIS.

4. The ISP-LIS receives the PIDF-LO from the RANP-LIS and may cache it before sending it back to the requesting host.

The RADIUS ALE for IP Routing

In the previous subsections, we described how RADIUS accounting messages can be analyzed to provide circuit correlators that a LIS can then use to link an IP address to a circuit chain, and subsequently to a location. In this section, we look specifically at what RADIUS accounting attributes are required from the ISP RADIUS and from the RANP proxy-RADIUS to support this functionality.

Starting from the ISP, we need to know which RANP the end-point's traffic will be coming through. This may be done implicitly-in other words, knowing the identity of the proxy-RADIUS forwarding the PPP session messages. Alternatively, it can be done through the proxy-RADIUS forwarding the NAS-ID information relating to the BRAS that serviced the request. In the latter case, the RADIUS accounting message must contain a NAS-IP-Address attribute, and/or the NAS-Identifier attribute, as defined in Reference 10, and it must be sufficient to allow the ISP-LIS to identify the RANP network. This may be done by provisioning data into the ISP-LIS ahead of time, which is a reasonable approach given that business relationships between the ISP and RANP must exist for connectivity to occur in the first place.

When the ISP RADIUS allocates an IP address for the user, it will send a Framed-IP-Address attribute in the response message. This must also be echoed in a RADIUS accounting message. All the data may be available in the same RADIUS accounting message, or they may span several accounting messages that are linked with a common Acct-Session-Id attribute as described previously. Regardless of how this occurs, ultimately the data must contain:

       NAS-IP-Address (BRAS identifier)       NAS-Identifier (BRAS identifier)       Framed-IP-Address       User-Name [optional] 

The RANP-LIS needs sufficient details to allow it to link the incoming traffic stream into the provisioned circuit chain so that it can link the stream to a source location. The RANP RADIUS server receives information from the BRAS that provides much of this information, namely the NAS-Identifier and/or NAS-IP-Address, and NAS-Port. In some cases, a NAS-Port-Id (defined in Reference 11, RADIUS Extensions) will be provided in place of, or as well as, the NAS-Port. Either is fine, providing it identifies where the data stream enters the BRAS, with sufficient information to allow the RANP-LIS to follow a circuit chain to the location. The response from the ISP RADIUS will include the Framed-IP-Address, and the RANP RADIUS may include this information in a RADIUS accounting message along with the stream identification data.

       NAS-Identifier (BRAS Identifier)       NAS-IP-Address (BRAS Identifier)       NAS-Port (BRAS Identifier)       NAS-Port-Id (BRAS Identifier)       Framed-IP-Address 

This tuple of data will allow the RANP-LIS to directly link the IP address to a provisioned circuit chain and hence to the physical location of the end-point. It may be that the RANP-RADIUS does not include all of this information in a single accounting record. If this is the case, then the RANP RADIUS-ALE will collate the accounting records based on the session identifier and send the complete FLAP message to the RANP-LIS.

To ensure that a solution exists across all of these scenarios, the ISP-LIS should not make assumptions about what information the RANP-LIS may or may not receive from a RADIUS-ALE. Consequently, the recommendation is that the ISP-LIS provide a database tuple capable of holding the following:

       User-Name       Framed-IP-Address       NAS-Identifier (BRAS Identifier)       NAS-IP-Address (BRAS identifier)       NAS-Port (BRAS Identifier)       NAS-Port-Id (BRAS Identifier) 

When the ISP-LIS queries the RANP-LIS, it should provide as much of the following data as possible in the location request to ensure that the RANP-LIS is able to identify the circuit chain, and hence the location of the Target.

       Framed-IP-Address       NAS-Identifier (BRAS Identifier)       NAS-IP-Address (BRAS Identifier)       NAS-Port (BRAS Identifier)       NAS-Port-Id (BRAS Identifier) 

The HELD identity extensions schema is provided in Appendix E. A HELD location request from the ISP-LIS to the RANP-LIS containing the identity extensions previously shown would look similar to the following code fragment. Note that the Framed-IP-Address is the target identifier and is contained in the <ipv4> element. The NAS-IP-Address is self-explanatory. The NAS-Port-ID is broken up into its constituent parts-in this example, ATM is used with the NAS-Port-ID, being composed of Slot/Port VPI:VCI.

 <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held">    <heldDevice       xmlns="http://sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">       <ipV4>192.168.5.9</ipV4>       <nas-ip-address>10.10.10.10</nas-ip-address>       <atm>          <slot>3</slot>          <port>0</port>          <vpi>100</vpi>          <vci>33</vci>       </atm>     </heldDevice> </locationRequest> 

The RANP-LIS should maintain at a database tuple as follows and populate as much data as it can from network measurements that it receives from its RADIUS-ALE.

       Framed-IP-Address       NAS-Identifier (BRAS Identifier)       NAS-IP-Address (BRAS Identifier)       NAS-Port (BRAS Identifier)       NAS-Port-Id (BRAS Identifier) 

The full FLAP specification for a RADIUS ALE is provided in Appendix A. A FLAP notification from a RANP RADIUS ALE to the RANP-LIS would look similar to the following XML fragment.

 <ntfy xsi:type="radius:ntfy">    <radius:terminal>       <radius:user-name>[e-mail]</radius:user-name>       <radius:framed-ip-address>192.168.0.1</radius:framed-ip-address>    </radius:terminal>    <radius:access time="2005-04-14T10:51:23.000+10:00">       <radius:nas-ip-address>10.10.10.10</radius-nas-ip-address>       <radius:nas-port-Id>atm 3/0:100.33</radius:nas-port-id>    </radius:access> </ntfy> 

ATM Layer 2 Over the Service Provider Segment

Figure 6.5 showed the A10-interface protocol stacks, and in the previous section we looked at the first stack which provided IP routing over the A10-interface between the RANP BRAS and the ISP. In this section, we will look at a pure layer-2 connection from the DSL modem at the customer premises, through the RANP BRAS, and on to the ISP. We shall also examine location determination and acquisition where this is performed using ATM. In subsequent sections, we will describe Ethernet-based solutions.

Breaking down Figure 6.15 in a similar fashion to how we broke down Figure 6.11, we can see that the provisioning components are quite comparable. An external provisioning system links ATM PVC identifiers from the end-point location, through the DSLAM, through the ATM network, through the Aggregator, and on to the ISP NAS. This same data are also provisioned into the RANP-LIS so that it can make associations between ATM virtual circuit identifiers and a physical location. The ISP-LIS provisioning in the ATM layer-2 configuration (shown in Figure 6.15) is different from that used in the IP routing configuration (shown in Figure 6.11) in that the ISP NAS-Port information is used this time to identify the RANP-LIS to contact, rather than the RANP BRAS identifier.

Figure 6.15: ATM layer 2 over the service provider segment.

The session establishment in this configuration is simpler than that of the IP routing configuration. Here, the end-point establishes a PPP connection directly with the ISP; the DSLAM, ATM, and aggregation networks pass the data transparently from the end-point to the ISP NAS.

The ISP NAS passes the NAS-IP-Address (or NAS-Identifier), NAS-Port (or NAS-Port-Id), User-Name, and User-Password to the ISP RADIUS for authentication. If authenticated, the end-point is provided with an IP address and other configuration data. The ISP RADIUS then generates a RADIUS accounting record consisting of:

       NAS-IP-Address or NAS-Identifier       NAS-Port or NAS-Port-Id       Framed-IP-Address       User-Name 

The value of the NAS-Port or NAS-Port-Id parameter will be that of the incoming ATM PVC, which consists of a virtual path indicator (vpi) and a virtual circuit indicator (vci). An ALE capable of analyzing the RADIUS accounting messages then passes this information on to the ISP-LIS. The ISP-LIS may use either the NAS indicator (NAS-Identifier or NAS-IP-Address) or the NAS port identifier (NAS-Port or NAS-Port-Id) value to determine which RANP-LIS to send any location requests to. Which indicator is used will depend on ISP-LIS provisioning and network configuration. The ISP-LIS uses the NAS-Port or NAS-Port-Id values as the Target identifier in any location requests made to the RANP-LIS.

As we did in the previous section, let's assume that the end-point has discovered the LIS using the DNS mechanism described in Chapter 4. Let's also assume that the RANP-LIS and switching elements have been suitably provisioned. The data flows for location determination and acquisition are therefore depicted in Figure 6.16, with the further assumption that the ALE resides in, or is tightly coupled with, the ISP RADIUS server.

Figure 6.16: ATM layer-2 service provider segment location acquisition.

Let's step through the flow in Figure 6.16 to be clear about what is going on.

1. The end-point attempts to establish a PPP session with the ISP NAS and includes authentication parameters-in this case, the PAP, User-Name, and User-Password parameters.

2. The ISP NAS sends the messages up to the ISP RADIUS server, including the NAS-Identifier and the NAS-Port. The NAS-Port parameter contains the vpi/vci of the incoming PVC for the end-point's data stream.

3. The ISP RADIUS server validates the end-point and assigns an IP address and other configuration data.

4. The ISP RADIUS server also generates a RADIUS accounting record containing:

    User-Name Framed-IP-Address NAS-Identifier (or NAS-IP-Address) NAS-Port/NAS-Port-Id (vpi/vci) 

   The RADIUS ALE tightly coupled with the RADIUS server creates a FLAP message containing the IP address, NAS-Identifier, and vpi/vci values, and sends this to the ISP-LIS.

5. The end-point makes a location request to the ISP-LIS.

6. The ISP-LIS uses the source IP address of the location request message to establish the identity of the Target. Using the IP address, the ISP-LIS is able to retrieve the corresponding vpi/vci associated with the Target's traffic stream, and the incoming NAS-Identifier. The ISP-LIS uses either the vpi/vci or the NAS identifier to determine the RANP-LIS to send the location request to. The ISP-LIS constructs a location request message to the RANP-LIS using the vpi/vci value for the RANP-LIS to use as the Target identifier.

7. The RANP-LIS uses the vpi/vci values to identify the provisioned circuit chain, and to determine the physical location of the end-point. The RANP-LIS constructs a PIDF-LO with the end-point's location and returns it to the ISP-LIS.

8. The ISP-LIS may cache the PIDF-LO before returning it to the end-point.

By carefully controlling the provisioning at the ISP-LIS and the RANP-LIS, it is possible to obtain measurements that allow an IP address to be associated with circuit identifiers and, hence, a physical location.

The RADIUS ALE for ATM Layer-2 Connectivity

In this configuration, only one RADIUS ALE type is required: the ISP RADIUS ALE. This ALE needs to be able to provide the LIS with an IP address to NAS-Identifier (if the ISP has more than one NAS), and a vpi/vci to identify the RANP-LIS, and then serve as a Target identifier for the RANP-LIS. A FLAP notification message for this ALE looks similar to the code fragment that follows.

 <ntfy xsi:type="radius:ntfy">    <radius:terminal>       <radius:framed-ip-address>192.168.0.1</radius:framed-ip-address>    </radius:terminal>    <radius:access time="2005-04-14T10:51:23.000+10:00">       <radius:nas-ip-address>10.10.10.10</radius-nas-ip-address>       <radius:nas-port-id>atm 3/0:100.33</radius:nas-port-id>    </radius:access> </ntfy> 

The ISP-LIS needs to include all of this information in any location requests made to the RANP-LIS so that the RANP-LIS is able to enter the circuit identifier chain. The full HELD identity extensions schema is provided in Appendix E. The following code fragment provides an indication of what the ISP-LIS location request to the RANP-LIS may look like.

 <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held">    <heldDevice       xmlns="http://sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">       <ipV4>192.168.5.9</ipV4>       <nas-ip-address>10.10.10.10</nas-ip-address>       <atm>          <slot>3</slot>          <port>0</port>          <vpi>100</vpi>          <vci>33</vci>       </atm>     </heldDevice> </locationRequest> 

Note that the Framed-IP-Address is the target identifier and is contained in the <ipv4> element. The NAS-IP-Address is self explanatory. The NAS-Port is broken up into its constituent parts. In this example, ATM is used with the NAS-Port, which is composed of Slot/Port VPI:VCI.

1:1 VLAN Layer-2 Forwarding over the Service Provider Segment

This configuration is similar to the ATM layer-2 forwarding solution described in the previous section. In this configuration, however, instead of data streams being kept orthogonal through discrete ATM PVCs, data are kept orthogonal by uniquely tagging them with VLAN tags. Let's look at the network configuration.

Figure 6.17 shows a network configuration where each customer premises has its data stream tagged with a unique VLAN identifier. There are several variants to this approach described in Reference 3, largely dealing with how the VLAN tags are determined. We shall describe only the most direct one here and assume that they are provisioned ahead of time.

Figure 6.17: 1-1 VLAN forwarding on service provider segment.

A DSLAM will tag each incoming customer data stream with a VLAN tag that is unique within the scope of the DSLAM. This tag is referred to as the C-TAG. Data leaving the DSLAM, toward the core network, are tagged with a second VLAN tag, the S-TAG, which identifies the DSLAM within the broadband network. The combination of the S-TAG and C-TAG uniquely identifies a DSLAM and DSLAM port within the broadband network. The combination of S-TAG and C-TAG can be used to represent in excess of 16 million ports. In reality, a DSLAM may have more than one S-TAG assigned to it, and the selection of which S-TAG to use may be dependent on a number of criteria including the desired QoS, or the value of the C-TAG allocated. These are predominantly provisioning details not directly pertinent to our discussions. What is important is that RANP-LIS knows, or is able to learn, the S-TAG and C-TAG associations to a specific data stream.

As before, let's start with provisioning. The RANP has a provisioning system that provides tagging and routing information to the DSLAM, core network, and BRAS. It also provides a direct association between S-TAG, C-TAG, and the location in the RANP-LIS. The ISP-LIS must be provisioned with sufficient information to be able to identify which RANP-LIS to query for a location when a request comes in. This may be done based on the S-TAG value, the value of the NAS-Identifier/NAS-IP-Address, or some other means.

Going through connection establishment, the end-point initiates a PPP session with the ISP. The data enter the DSLAM and are tagged with a C-TAG of 1. The data leave the DSLAM and are tagged a second time with an S-TAG of 200. The data travel through the core network with two VLAN tags and arrive at the BRAS. The BRAS examines the combination of S-TAG and C-TAG and directs the data to the ISP-NAS.

As with the previous examples, the ISP-NAS sends a RADIUS message to the ISP RADIUS server containing an identifier for the NAS (either NAS-Identifier or NAS-IP-Address), the incoming port information (either NAS-Port or NAS-Port-Id), and the end-point's user credentials. The NAS-Port or NAS-Port-Id contain the S-TAG and C-TAG VLAN identifiers.

Assuming the end-point successfully validates, as with previous examples, an IP address and other configuration data are returned to the end-point and the ISP RADIUS server generates a RADIUS accounting record. The RADIUS accounting record is then analyzed by a RADIUS-ALE. The RADIUS accounting record would contain the following attributes:

       User-Name       Framed-IP-Address       NAS-Identifier or NAS-IP-Address       NAS-Port or NAS-Port-Id (containing the S-TAG and C-TAG values) 

The RADIUS-ALE sends the information to the ISP-LIS in a FLAP message. The ISP-LIS will cache this data for use when a location request is received.

Let's look at a location request in this configuration.

As with the previous examples, let's assume that the end-point has discovered the ISP-LIS using the LIS discovery mechanism described in Chapter 4 using Figure 6.18 as a reference.

Figure 6.18: Dual-tagged VLAN on a service provider segment location acquisition.

1. The end-point attempts to establish a PPP session with the ISP NAS and includes authentication parameters-in this case, the PAP, User-Name, and User-Password parameters.

2. The ISP NAS sends the messages up to the ISP RADIUS server, including the NAS-Identifier and the NAS-Port. The NAS-Port parameter contains the S-TAG and C-TAG of the VLANs for the end-point's data stream.

3. The ISP RADIUS server validates the end-point and assigns an IP address and other configuration data.

4. The ISP RADIUS server also generates a RADIUS accounting record containing:

      User-Name   Framed-IP-Address   NAS-Identifier (or NAS-IP-Address)   NAS-Port/NAS-Port-Id (S-TAG and C-TAG) 

   The RADIUS ALE tightly coupled with the RADIUS server creates a FLAP message containing the IP address, NAS-Identifier, and S-TAG and C-TAG values, and then sends this to the ISP-LIS.

5. The end-point makes a location request to the ISP-LIS.

6. The ISP-LIS uses the source IP address of the location request message to establish the identity of the Target. Using the IP address, the ISP-LIS is able to retrieve the corresponding NAS-Identifier, S-TAG, and C-TAG values associated with the Target's traffic stream. The ISP-LIS uses either the NAS-Identifier or the S-TAG to identify the RANP-LIS to send the location request to. The ISP-LIS constructs a location request message to the RANP-LIS using the S-TAG and C-TAG values to identify the Target at the RANP-LIS.

7. The RANP-LIS uses the S-TAG and C-TAG values to identify the DSLAM and DSLAM port, allowing it to determine the physical location of the end-point. The RANP-LIS constructs a PIDF-LO with the end-point's location and returns it to the ISP-LIS.

8. The ISP-LIS may cache the PIDF-LO before returning it to the end-point.

1:1 VLAN Tag RADIUS-ALE

The RADIUS-ALE in the 1:1 VLAN tag configuration that has been described in this section is in essence the same as the RADIUS-ALE that was described for the ATM layer-2 forwarding configuration described in the previous section. The ALE must provide an IP address that has been assigned by the RADIUS server, username, an identifier for the NAS, and the NAS-Port on which the data arrived. A FLAP notify message for an ALE in this configuration would look similar to the following code fragment.

 <ntfy xsi:type="radius:ntfy">    <radius:terminal>       <radius:user-name>[e-mail]</radius:user-name>       <radius:framed-ip-address>192.168.0.1</radius:framed-ip-address>    </radius:terminal>    <radius:access time="2005-04-14T10:51:23.000+10:00">       <radius:nas-ip-address>10.10.10.10</radius-nas-ip-address>       <radius:nas-port-id>eth 3/0:43.76</radius:nas-port-id>    </radius:access> </ntfy> 

The ISP-LIS caches the data and later uses NAS-Identifier or the S-TAG to map to a RANP-LIS identity in order to service location requests from end-points. The ISP-LIS needs to include the NAS-IP-Address and NAS-Port-id information when requesting location information from the RANP-LIS. Appendix E provides the detailed HELD identity extensions schema. The following code fragment provides an example of what the ISP-LIS location request to the RANP-LIS may look like for this configuration.

 <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held">    <heldDevice       xmlns="http://sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">       <ipV4>192.168.5.9</ipV4>       <nas-ip-address>10.10.10.10</nas-ip-address>       <vlan>          <slot>3</slot>          <port>0</port>          <ctag>100</ctag>          <stag>33</stag>       </vlan>    </heldDevice> </locationRequest> 

Note that the Framed-IP-Address is the target identifier and is contained in the <ipv4> element. The NAS-IP-Address is self-explanatory. The NAS-Port-id is broken up into its constituent parts. In this configuration, Ethernet is used with the NAS-Port-Is, which is composed of Slot/Port S-Tag:C-Tag.

N:1 VLAN Layer-2 Forwarding Using PPP

The previous sections described how layer-2 forwarding through the network can be done when there is a 1:1 ATM PVC or a 1:1 VLAN association for the data stream from the DSLAM, through the core network, to the ISP NAS. This section presents the N:1 VLAN configuration described in detail in Reference 3. In this configuration, multiple data streams share a common VLAN identifier out of the DSLAM, hence the term 1:N. Data are routed through the core using a combination of VLAN- and ARP-based routing tables at the BRAS as shown in Figure 6.19.

Figure 6.19: N-1 VLAN forwarding.

This mechanism poses some major advantages for core and edge network providers over the 1:1 path provisioning approaches because it simplifies routing and provisioning operations in the core. It is attractive from a location determination standpoint because it shortens the length of circuit chains that need to be provisioned in order to determine the location of the end-point. To understand these advantages, we need to look at the network configuration in detail.

The key difference in this configuration is that there is a PPPoE intermediary in the DSLAM itself. When the end-point tries to establish its PPPoE connection, the intermediary in the DSLAM inserts a vendor-specific tag, as described in the section detailing PPPoE. This tag is used to identify the DSLAM and the incoming circuit identifier. The DSLAM tags the data stream with a common VLAN tag (an S-TAG) and sends the PADI with the circuit-id TAG to the aggregator. The Aggregator terminates the PPP session and sends a query to the RAN-P proxy RADIUS. Here is where the difference comes into play. The aggregator puts the circuit-id information contained in the PPPoE tag from the intermediary in the NAS-Port-Id/NAS-Port field in the outbound RADIUS message, instead of the value of the actual aggregator NAS-Port on which the data stream was received. A RADIUS ALE at the RANP is now able to provide the RANP-LIS with the end-point's actual point of ingress to the access network, reducing the level of circuit chaining that needs to be provisioned into the RANP-LIS.

The RANP proxy RADIUS forwards the data to the ISP RADIUS and receives configuration information for the end-point after the end-point has been successfully authenticated. This configuration information is subsequently provided to the end-point and the connection is established. The ISP RADIUS server generates an accounting message with the data, including the circuit information relating to the access node. This information is processed by a RADIUS ALE and passed to the ISP-LIS (see Figure 6.20).

Figure 6.20: N-1 VLAN forwarding message flow.

Much of the message flow in Figure 6.20 is described in the preceding text. The location acquisition flow consists of the end-point having first discovered the identity of the ISP-LIS using the mechanism described in Chapter 4. The end-point sends a HELD location request to the ISP-LIS. The ISP-LIS identifies the end-point based on its IP address, and recovers the NAS-Identifier: Access-Node-Id+Circuit-Id. The ISP-LIS uses this information to determine the RANP-LIS to query. The ISP-LIS queries the RANP-LIS using the Access-Node-Id+Circuit-Id as the Target identifier in the HELD request. The RANP-LIS uses the Target identifier information to recover the location of the end-point, constructs a PIDF-LO and returns it to the ISP-LIS. The ISP may cache the location information before returning it to the end-point.

The RADIUS ALE for the N:1 VLAN Configuration

To understand how to construct this ALE, we need to understand the format of the circuit tag provided by the PPPoE intermediary in the DSLAM, and the subsequent format of the NAS-Port and NAS-Port-Id RADIUS attributes. The format for this circuit tag is defined in Reference 3, but is repeated here for clarity (see Figure 6.21).

Figure 6.21: PPPoE intermediary circuit tag.

The Agent Circuit ID field is used by the intermediary to specify the access node (DSLAM) being used, and the port circuit on which the data stream is entering the access node. Reference 3 makes the following recommendation for the format of this field.

 <Access-Name-Identifier> <L2-Type> <slot>/<port>:[circuit-id] 

For ATM, where the data stream is coming from access node 7692, slot 3, port 0, vpi 100 vci 33, the Agent Circuit ID would be as follows:

 AN-7692 atm 3/0:100.33 

For an Ethernet connection, using access node 7692, slot 3, port 0, and vlan 43, the Agent Circuit ID would be encoded as follows:

 AN-7692 eth 3/0:43 

The agent remote id is used to uniquely identify a client connected to a specific port on the DSLAM. Reference 3 doesn't provide any specific guidance on how to format this field.

The format previously illustrated is the expected format of the NAS-Port or NAS-Port-Id fields where the N:1 VLAN configuration is used. This is the case for both the RANP RADIUS ALE and the ISP RADIUS ALE.

In addition to this data, the ISP RADIUS ALE must provide the Framed-IP-Address to identify the Target, and either NAS-Identifier or NAS-IP-Address to aid in determining the identity of the RANP-LIS to query. The full FLAP schema for the RADIUS ALE is included as part of Appendix A, the following xml stanza is indicative of what an ISP RADIUS ALE notify message looks like for this configuration (ATM as the transport is assumed).

 <ntfy xsi:type="radius:ntfy">    <radius:terminal>       <radius:user-name>[e-mail]</radius:user-name>       <radius:framed-ip-address>192.168.0.1</radius:framed-ip-address>    </radius:terminal>    <radius:access time="2005-04-14T10:51:23.000+10:00">       <radius:nas-ip-address>10.10.10.10</radius-nas-ip-address>       <radius:nas-port-id>AN-7692 atm 3/0:100.33</radius:nas-port-id>    </radius:access> </ntfy> 

The subsequent location request from the ISP-LIS to the RANP-LIS must include the access node identifier and the access node circuit information. Using the preceding example, a HELD location request from the ISP-LIS to the RANP-LIS will look similar to the following code extract.

 <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held">    <heldDevice       xmlns="http://sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">       <access-node-id>AN-7692</access-node-id>       <atm>          <slot>3</slot>          <port>0</port>          <vpi>100</vpi>          <vci>33</vci>       </atm>    </heldDevice> </locationRequest> 

N:1 VLAN Layer-2 Forwarding Using DHCP

Up to now, all the configurations described used PPP for session establishment. In part, this is a reflection of the fact that the majority of DSL services use PPP as a link session layer, largely (but exclusively) because of its tight coupling with RADIUS. As described previously, one of the advantages of RADIUS is that it allows roaming to be easily supported. This function also eases provisioning constraints for core network providers, particularly where IP routing or L2TP is used across the service provider segment. The reason for this is that the connection from the end-point to the service provider can be established dynamically at a connection based on the realm associated with the user-name, rather than requiring per-circuit provisioning end to end, as is required with ATM and dual-VLAN layer-2 pass-through configurations. Reducing provisioning reduces complexity, and therefore reduces the likelihood of errors occurring. Regardless of all this, DHCP is used in DSL deployments. In this section, we shall look at the N:1 VLAN configuration again, but this time using DHCP in place of PPP.

In Figure 6.22, a DHCP relay-agent, as described in Reference 19, resides in the DSLAM. The relay-agent appends circuit information associated with the end-point's point of attachment to the network. Unlike the DHCP relay-agent usage described in Chapter 5, the relay-agent in the DSLAM doesn't specify a return address by setting the giaddr fielding in the DHCP header, nor does it change the discovery message from broadcast to unicast. It simply attaches circuit information. As was pointed out in Chapter 5, the options described in Reference 19 do not provide a clear way for the relay-agent to identify itself to the DHCP server other than by setting giaddr. In a DSL environment, where the access network may be owned by a different provider than the ISP, the DSLAM may not be directly accessible from the ISP DHCP server. If it is not, then the DSLAM cannot set giaddr, since giaddr tells the DHCP server where to send response messages. To overcome this limitation, the circuit-id provided by the relay-agent in the DSLAM must also encode the identity of the relay-agent. Reference 3 provides guidance on how to do this. The format for the circuit-id mandated in Reference 3 is the same as that proposed in the previous section for the RADIUS NAS-Port and NAS-Port-Id attributes. Let's step through Figure 6.22, describing the steps for location determination and acquisition.

Figure 6.22: N-1 VLAN layer-2 forwarding using DHCP.

1. The end-point (usually a DSL modem) sends a DHCPDISCOVER broadcast message to the network.

2. The DHCP relay-agent in the DSLAM intercepts the DHCPDISOVER and appends the circuit-id information described previously. The DHCP relay-agent then rebroadcasts the DHCPDISCOVER message towards the core network using a common VLAN (N:1).

3. The Aggregator sends the DHCPDISCOVER message to a DHCP relay-agent in the RANP.

4. The RANP DHCP relay-agent sets the giaddr with its address, and based on the value of the circuit-id, sends the DHCPDISCOVER as a unicast message to the ISP DHCP server.

5. The ISP DHCP server then allocates an IP address and provides network configuration data back to the RANP DHCP relay-agent, and subsequently back to the requesting end-point. Using a DHCP ALE similar to those described in Chapter 5 for enterprise environments, information can either be pushed from the DHCP server to the ISP-LIS, or requested from the DHCP server using the DHCP lease query mechanism.

6. The end-point then makes a location quest to the ISP-LIS, which uses the giaddr field or circuit-id data to aid it in determining which RANP-LIS to query for location information. The ISP-LIS uses the circuit-id information as the Target identifier in the location request to the RANP-LIS.

7. The RANP-LIS uses the circuit-id as a key in its database to provide the physical location of the end-point, constructs a PIDF-LO, and returns this to the ISP-LIS.

8. The ISP-LIS may cache the location before returning it to the end-point.

The obvious question that comes to mind with this model is, "Why not simply return location to the end-point using Reference 20, or the civic format?" There are several reasons why not. First, providing a location in the DHCP response requires a real-time lookup of the RANP-LIS prior to a response being sent to the end-point. This may not be feasible. Second, it would require all DSL modems to support the DHCP options, something that they might not do. Third, it would necessitate that all hosts inside the home network also support the DHCP options, something that, again, they may not be able to do. All in all, the network and functional constraints imposed by DHCP acquisition as described in previous chapters make it generally unsuitable as a means of dependable location delivery.

L2TP over the Service Provider Segment

L2TP over the service provider segment is the last of the DSL configurations we shall consider, and in many ways it is the most complex-at least from a location determination perspective. The configuration involves PPP over ATM or Ethernet from the DSLAM to the BRAS. A query is made from the BRAS to the RADIUS server for routing information, and the RADIUS server responds with a layer-2 tunnel identifier. The BRAS will either create a new tunnel, or a new session in an existing tunnel. The BRAS then generates a RADIUS accounting message containing all the data, including the tunnel session identifier. Unlike the other DSL configurations described thus far, where the RANP RADIUS ALE is important to some degree, the RANP RADIUS ALE in this configuration is critical. This criticality arises because the tunnel and session identifiers provide the association back to the provisioned circuit chain, but these are dynamically determined as the session is established. They cannot be derived at the RANP-LIS based solely on information provided by the ISP-LIS. Figure 6.23 shows the configuration in more detail.

Figure 6.23: L2TP over the service provider segment.

The first part of this configuration is much the same as the 1:1 VLAN tag, or IP routing over the service provider segment configurations. The RANP-LIS and core network switches need to be provisioned with circuit/switching information to allow a connection from the home location, through the DSLAM, through the core network, and to a known port on the BRAS. PPP AC in the aggregator makes the request for authentication and routing information from the RANP RADIUS server. Based on the realm of the username, the RADIUS determines that the aggregator needs to route the data across a layer-2 tunnel to the ISP. As was described in the section on protocols, the RADIUS server may provide a tunnel identifier, or an IP address representing the remote end of the tunnel. On receiving this information from the RADIUS server, the aggregator will either create a session in an existing tunnel, or create a new tunnel with a new session. In either case, the aggregator will generate a RADIUS accounting message indicating the incoming NAS (NAS-Identifier), the NAS-Port, the tunnel, and the session-id for the session in the tunnel. In this mode, it is critical for a RANP RADIUS ALE to provide an NAS-Identifier, NAS-Port, tunnel, and session-id to the RANP-LIS. This allows the RANP-LIS to provide the association between the tunnel and session-id, the circuit across the service provider segment, and the NAS-Identifier and NAS-Port, which is the start to the provisioned circuit chain.

The ISP NAS needs to report the identity of the tunnel, the session-id, the user-name, and the password. An accounting record associating tunnel, session-id, and Framed-IP-Address needs to be provided to the RADIUS ALE for communication to the ISP-LIS.

The ISP-LIS will use the tunnel, consisting of source and destination IP addresses to identify the RANP-LIS to query, and employs the tunnel and session-id attributes to identify the Target to the RANP-LIS. The RANP-LIS uses the tunnel and session-id parameters to identify the provisioned circuit chain, and hence the physical location of the Target. A PIDF-LO is constructed containing the resulting location and is returned to the ISP-LIS and ultimately to the end-point.

The data flow for the preceding description is provided in Figure 6.24.

Figure 6.24: Data flow for L2TP over the service provider segment.

L2TP RADIUS ALE

The L2TP RADIUS ALE needs to operate at both ends of the tunnel. According to Reference 17, RADIUS accounting records should contain the User-Name, Acct-Tunnel-Connection, Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes. It further indicates that the L2TP Call-Serial-Number, a 32-bit number which is the same at both ends of the tunnel, should be populated into the Acct-Tunnel-Connection field. This provides the RADIUS ALE with the attributes necessary to identify the two ends of the tunnel, and the session in the tunnel. This information is combined with the incoming NAS-Identifier and NAS-Port information for the LAC NAS in order to provide the link to the provisioned circuit chain.

       User-Name       Acct-Tunnel-Connection       Tunnel-Client-Endpoint       Tunnel-Server-Endpoint       NAS-Identifier       NAS-Port 

At the ISP-LIS, the L2TP accounting information is combined with the Framed-IP-Address to provide the linkage from IP address to provisioned circuit chain.

       User-Name       Acct-Tunnel-Connection       Tunnel-Client-Endpoint       Tunnel-Server-Endpoint       Framed-IP-Address 

A L2TP ISP RADIUS ALE FLAP notify message will look similar to the XML stanza shown next. The XML schema for the RADIUS ALE is provided in Appendix A.

 <ntfy xsi:type="radius:ntfy">    <radius:terminal>       <radius:user-name>[e-mail]</radius:user-name>       <radius:framed-ip-address>192.168.0.1</radius:framed-ip-address>    </radius:terminal>    <radius:access time="2005-04-14T10:51:23.000+10:00">       <radius:nas-ip-address>10.10.10.10</radius-nas-ip-address>       <radius:nas-port-id>eth 3/0:100</radius:nas-port-id>       <radius:12tp>          <radius:tunnel-client-endpoint>             47.181.192.205          </radius:tunnel-client-endpoint>          <radius:tunnel-server-endpoint>             47.181.195.222          </radius:tunnel-server-endpoint>          <radius:acct-session-id>15383</radius:acct-session-id>       </radius:12tp>    </radius:access> </ntfy> 

The ISP-LIS uses the Tunnel-Client-Endpoint value to identify the RANP-LIS to query, and it uses the Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Acct-Tunnel-Connection to identify the Target to the RANP-LIS. To do this, the ISP-LIS must use the HELD identity extensions schema provide in Appendix E. The following code fragment illustrates how the next example would translate into a HELD location request for this configuration.

 <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held">    <heldDevice       xmlns="http://sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">       <12tp>          <sourceIP>47.181.192.205</sourceIP>          <destinationIP>47.181.195.222</destinationIP>          <sessionID>15383</sessionID>       </12tp>   </heldDevice> </locationRequest> 

DSL Network Summary

DSL networks provide broadband access to subscribers over existing twisted copper pair cables. In general, several operators need to cooperate in order to provide IP connectivity from the subscriber to an ISP. Data may be transported over a variety of different physical and link layers in order to reach their destination, and mechanisms are needed to provide measurements and mapping between these layers in order to ensure that the ultimate location of the end-point can be determined. LISes and ALEs are required in both the RANP and ISP networks to ensure that measurements and location information can be returned to the end-point when requested.