Overview of GDM

This chapter provides a brief introduction to the GTP Director Module (GDM) and its implementation in the Cisco IOS software.

This chapter includes the following sections:

•Feature Description

•Request Processing by GDM

•Load Balancing Processing by GDM

•Benefits

Feature Description

GGSN Release 3.0 and later adds GDM as part of the GGSN feature set in the Cisco IOS software. GDM extends some of the benefits that are available on a Cisco Systems GGSN, to GPRS/UMTS environments where non-Cisco GGSNs are implemented.

These benefits include reducing APN provisioning requirements in the GPRS/UMTS PLMN, while also providing simple, round-robin load balancing for the GGSNs. A network using GDM has the added benefit of the Cisco Systems Hot Standby Router Protocol (HSRP) to support increased network availability using a backup GDM router.

Like the Cisco Systems' GGSN, GDM provides access to multiple destination networks through a virtual APN that is provisioned at the Home Location Register (HLR). GDM's virtual APN support simplifies the maintenance and provisioning issues in the GPRS/UMTS PLMN significantly. In this one-to-many model, one APN can be provisioned for multiple subscribers, and that one APN can provide access to many real destination networks. By implementing virtual APN support, service providers can add new access points without having to provision the HLR.

Using DNS, GDM also provides round-robin load balancing for those GGSNs that support access to the same destination networks.

To provide increased network availability, a backup GDM router can be configured to automatically switch over and become the primary GDM router using HSRP. The backup GDM router can provide access to the GGSNs if the primary GDM router, or even a critical interface on the primary GDM router, becomes unavailable.

Although GDM is part of the GGSN feature set, it cannot coexist on a router that is also configured as a Cisco Systems GGSN. However, GDM can be used in a mixed environment of Cisco and non-Cisco GGSNs.

GDM does not add any value to an environment that includes only Cisco Systems GGSNs, considering that Cisco Systems GGSNs have alternative and enhanced load balancing solutions, and can natively provide virtual APN support. For more information about load balancing options for a Cisco Systems GGSN, see the "Configuring Load Balancing on the GGSN" chapter. For information about virtual APN support, see the "Configuring Virtual APN Access on the GGSN" section.

Request Processing by GDM

This section describes how GDM processes create PDP context requests and retries of those requests, and describes several different request processing scenarios. This section includes the following topics:

•Overview of Request Processing by GDM

•Request Processing Using a Virtual APN

•Request Processing Scenarios

Overview of Request Processing by GDM

GDM's role in the GPRS/UMTS PLMN is to facilitate the processing of create PDP context requests between an SGSN and one or more GGSNs. GDM processes create PDP context requests sent by an SGSN, and forwards them to the appropriate destination GGSN. GDM does not monitor whether or not a create PDP context request has been successful, or if a path has been established between an SGSN and GGSN for a particular tunnel ID (TID).

In the case of an unsuccessful session establishment, GDM continues to receive retry requests from an SGSN. GDM processes the retries of a create PDP context request for a particular TID and forwards those retries to the GGSN to which the original request was sent. However, GDM only processes those retries for a configurable period of time. GDM forwards retries of a create PDP context request to a GGSN for 30 seconds (default), or for the amount of time that you have configured in the gprs gtp-director retry-timeout command.

Once GDM has sent create PDP context requests to a GGSN and has processed any retries, GDM is no longer involved in any other forms of request processing for that PDP context. User authentication for a PDP context request is handled as usual between the GGSN and the authentication, authorization, and accounting (AAA) server.

All of the other signaling request processing occurs directly between the SGSN and the GGSN, over the GTP path established between them. GDM is never part of the GTP path, and data does not flow through GDM. The GTP path remains as usual between the SGSN and a GGSN for a PDP context. For troubleshooting purposes, it is important to note that GDM is never even aware of whether a PDP context has been successfully established with a GGSN.

GDM is not involved in the processing of the following types of requests:

•Echo Requests

•Delete PDP Context Requests

•Update Requests

Request Processing Using a Virtual APN

In the GDM environment using virtual APN support, a virtual APN is used to select the Cisco Systems GDM router. GDM facilitates the processing of the create PDP context request to the real APNs through the appropriate GGSNs. The GGSNs always provide the physical connectivity to the real target network.

To implement virtual APN support using GDM, you need to determine the name(s) of the virtual access point(s) that you want subscribers to use for access to one or more real APNs that are configured on your GGSNs.

Figure 13-1 shows how GDM supports a create PDP context request from an MS processed through a virtual APN using GDM in its intended router environment where non-Cisco GGSNs are in use.

Note Recall that you can also use GDM in a mixed environment of Cisco and non-Cisco GGSNs, or in an all Cisco GGSN environment. However, for an environment using only Cisco GGSNs, there are alternative and enhanced load balancing solutions and virtual APN support is already available, which makes GDM less worthwhile for that environment.

Figure 13-1 Virtual APN PDP Context Activation Using GDM and non-Cisco GGSNs

1.

At the MS, the subscriber connects to the network with a username in the form of login@domain, such as ciscouser@real and specifies the name of the virtual APN.

2.

The SGSN contacts the HLR to acquire subscription information for the MS. The HLR has a list of the APNs for which the MS is a valid subscriber. The HLR returns to the SGSN the list of subscribed APNs for the MS. The SGSN verifies that the APN called virtual is part of the user's subscribed list of APNs.

3.

After the SGSN verifies that the virtual APN is valid for the MS user, the SGSN performs a DNS query for the APN named virtual, and DNS returns the IP address of GDM.

The SGSN sends a create PDP context request to GDM using the APN of virtual. The create PDP context also includes the username and password in the form of login@domain (which is ciscouser@real in our example) in the protocol configuration option (PCO) information element (IE).

4.

GDM reads the create PDP context request and extracts the APN of virtual from the APN IE. GDM extracts the tunnel ID (TID) and verifies whether it already has a pending PDP context request for that TID. GDM extracts the username from the PCO IE.

5.

If no pending request is found, GDM performs a DNS query for the domain that was extracted from the PCO (in this case, real). The domain from the information in the PCO, corresponds to the real target network on the GGSN.

The DNS server returns up to 8 addresses of the GGSNs that can provide connectivity to the real target network to GDM. When multiple addresses are returned by DNS, GDM uses the first address that is provided in the list.

6.

GDM forwards a create PDP context request from the SGSN to the target GGSN. In the APN IE of the request, GDM replaces the original APN of virtual with the domain name found of real. The username field now contains only the username, which is ciscouser in this example.

7.

The real GGSN processes the create PDP context request using the real APN of real, which corresponds to the original domain name requested by the MS. The address of GDM is replaced by the address of the GGSN, and the response to the create PDP context request is sent by the real GGSN to the SGSN. GDM is no longer involved in the processing of the PDP context.

8.

If successful, the SGSN sends an activate PDP context message to the MS and the GTP path is established between the SGSN and the GGSN.

If unsuccessful, the SGSN sends a retry of the create PDP context request to GDM. If the retry timeout period for that TID has not expired, GDM forwards the create PDP context request to the GGSN to which the original request was sent. GDM continues to process any retry requests it receives for that TID until the retry timeout period is reached.


Request Processing Scenarios

GDM processes a PDP context according to the content found in the APN Information Element (IE) and the Protocol Configuration Option (PCO) of the create PDP context request, according to the following scenarios:

•CreatePDPContext (APN=virtual, PCO=ciscouser@real)

In this format the APN IE exists, and the PCO specifies a username@domain (see Figure 13-1). This format is used to implement virtual APN support through a virtual APN. In this scenario the APN IE designates a virtual access point. The APN IE is used to direct the request to GDM (the SGSN's DNS query for the virtual APN should return the IP address of GDM). GDM uses the domain as the real APN, and performs a DNS query on the domain name to locate the appropriate destination GGSN.

•CreatePDPContext (APN=real, PCO=ciscouser)

In this format the APN IE exists, and the PCO only specifies a username (no domain). In this scenario the APN IE must designate a real access point. The APN IE is used to direct the request to GDM (the SGSN's DNS query for the real APN should return the IP address of GDM). GDM also uses the APN IE (the real APN) to perform a DNS query to locate the appropriate destination GGSN.

•CreatePDPContext (APN=real, PCO=)

In this format, the APN IE exists, and the PCO is null. This format is found when anonymous access is being used. In this scenario the APN IE must designate a real access point. The APN IE is used to direct the request to GDM (the SGSN's DNS query for the real APN should return the IP address of GDM). GDM also uses the APN IE (the real APN) to perform a DNS query to locate the appropriate destination GGSN.

Load Balancing Processing by GDM

GDM supports basic load balancing using the DNS server's ability to return to GDM a list of IP addresses in round-robin fashion for a particular domain name. The DNS server can return a list of up to 8 addresses to GDM for each domain name. GDM always uses the first IP address returned by the DNS server. The IP addresses correspond to the GGSNs available to support the requested real APN.

The name for which GDM performs a DNS query is based upon the content of the APN IE and the PCO IE of the create PDP context request. If the create PDP context request specifies a domain, then GDM queries the DNS server for that domain name. The username and password that the MS requests in the form of "login@domain" is provided in the PCO IE of the create PDP context request. The domain name in the MS request, and for which GDM queries the DNS server, should correspond to the name of the real APNs that are configured on the GGSNs. Those GGSNs provide connectivity to the physical network for that APN.

If the MS does not specify a domain, or the PCO is null, then GDM queries the DNS server for the real APN found in the APN IE.

For load balancing support, you must configure the DNS server for GDM with the IP addresses of all of the GGSNs (up to 8) that support connectivity to the physical network for the domain. You also should verify that the round-robin mechanism is enabled for the DNS server when it returns a list of IP addresses for a domain.

Benefits

GDM provides the following benefits:

•Reduction in HLR provisioning through virtual APN support.

•Sharing of GGSN resources using round-robin load balancing.

•Backup router support for GDM functions using HSRP.