|
|
This chapter provides a detailed description of the Cisco Mobile Exchange (CMX) framework and contains the following sections:
Cisco's CMX solution for mobile wireless networks combines multiple network elements into a single solution framework. As shown in Figure 3-1, the core of the CMX solution framework is the Cisco 7600 series switch/router. Descriptions of the CMX network elements shown in Figure 3-1 are listed in Table 3-1.
| CMX Element | Description |
|---|---|
|
|
Authentication, Authorization, and Accounting (AAA) server (Cisco Access Registrar or equivalent third-party AAA server) |
|
Remote Console Access (not shown in Figure 3-1) |
|
Table 3-2 lists the CMX hardware and software components required for CMX.
 |
Note Cisco partner can provide AAA server, prepaid server, or BMA components. |
This section describes the supported features for Cisco Mobile Exchange components.
The CMX features supported for SSG are listed in Table 3-3.
Table 3-3 SSG Supported Features
The CMX supports interworking between the SESM and the Web portal provider. The Web portal uses the application programming interface (API) provided by the SESM to interact with the SSGs and the AAA server.
The SESM and AAA server use the RADIUS protocol and vendor-specific attributes (VSAs) to interwork. Each of these VSAs requires the SESM to know the target SSG IP address.
The CMX supports the high availability features listed in Table 3-4.
Table 3-4 High Availability Features
The CMX supports the billing features listed in Table 3-5.
The CMX network elements are connected using Ethernet segments. Each element of the solution uses one or two physical fast Ethernet (FE) interfaces as shown in Figure 3-2. The interfaces run network time protocol (NTP) to maintain timing between the network elements.
To increase efficiency and redundancy, the CMX also uses logical Ethernet interfaces. Logical Ethernet interfaces are created by configuring virtual local area networks (VLAN)s. With VLAN configuration, each physical Ethernet interface is separated into 802.1q VLAN interfaces using the 802.1q encapsulation provided by the Cisco IOS.
The CMX interconnections are organized into multiple VLANs that cover three major areas:
The CMX VLAN organization is illustrated in Figure 3-3.
A basic understanding of how data traffic flows through the CMX network elements and interconnecting VLANs is beneficial to personnel who are responsible for configuring and maintaining the CMX network elements. The following sequence of events is also illustrated in Figure 3-4 (the numbers in Figure 3-4 correspond to steps below).
|
Note The following sequence of events describes only data traffic flows. Traffic flows for RADIUS messages are described in "Detailed RADIUS Interactions" section. |
1. The GGSN sends user IP packets to a Multilayer Switch Feature Card (MSFC) in the RLB platform using the open shortest path first (OSPF) algorithm.
2. The MSFC uses policy routing to send the user packet to CSG1.
3. CSG1 directs all traffic on VLAN 17 to the RLB and creates accounting records for the user traffic.
4. RADIUS server load balancing (SLB) software directs the user traffic to the correct SSG.
5. The SSG performs service control and selection by sending the user packets to the selected service. The SSG can also generate RADIUS accounting records and send RADIUS authorization to the prepaid server (via the AAA server) for prepaid sessions.
6. The next hop for all service-bound packets from the SSG is the FWLB. The FWLB registers the downlink path with the correct SSG for downlink IP traffic flow.
7. The next hop is CSG2, which generates billing records for content-based billing. Encrypted AAA or tunneled traffic passes through this CSG unaltered.
8. CSG2 routes the user traffic to a next-hop router or border gateway toward the services network.
9. The downstream user traffic is received on CSG2.
10. The CSG2 generates billing records for content-based billing and sends the user packets to the FWLB.
11. The FWLB forwards the user packet to the same SSG that was used for the uplink traffic flow.
12. The SSG routes the user traffic toward the MSFC in the RLB (downstream traffic is transparent to the RLB).
13. The RLB uses policy routing to send the user traffic to CSG1.
14. CSG1 creates accounting records for the user traffic and generates content-based CDRs to send to the BMA. The user traffic is sent to the MSFC.
15. The MSFC uses the OSPF algorithm to route the user packet to the correct GGSN.
16. The GGSN receives the user packet and encapsulates it in a tunnel (using GTP) toward the mobile station.
The CMX solution for mobile wireless networks supports the following services (Figure 3-5):
Pass-through service is typically used to provide standard Internet access to mobile wireless subscribers. This type of service allows subscribers to pass through the service provider's network to access the external PDN. Pass-through service can be configured to authenticate subscribers automatically based on a profile or to provide transparent (unauthenticated) service.
The events that occur to activate authenticated pass-through service are described in the steps below (steps also shown in Figure 3-6).
1. The GGSN sends an access request to the RADIUS Load Balancer (RLB) with the username, MSISDN, and IMSI of the subscriber.
2. The RLB receives the access request, selects an SSG, and forwards the request to the SSG.
3. The SSG receives the request and forwards it to the AAA server.
4. The AAA server authenticates the user and allocates an IP address for the user session. The AAA server sends the IP address and a user profile to the SSG.
5. The SSG forwards this information to the RLB, creates a host object for the user session, and queries the AAA server for the service profile to enable pass-through service.
6. The RLB retrieves the user IP address and sends it to the GGSN.
7. The GGSN sends the IP address to the mobile handset. It also sends a message to the RLB to start accounting records and forwards the message to the SSG.
8. The SSG generates a message to the AAA server to start accounting records.
9. The pass-through is enabled and the user session is active.
10. The SSG periodically sends interim update messages to the AAA server for accounting purposes.
11. The GGSN generates a message to stop RADIUS accounting records when the subscriber terminates access. The RLB clears the user IP address. The SSG sends out messages to each service the subscriber accessed and terminates the host object for the user session.
Transparent pass-through service allows unauthenticated subscriber traffic to be routed through the SSG in either direction. Filters can be specified to control transparent passthrough traffic. Some of the applications for this feature include:
When a subscriber requests access to a proxy service, the SSG proxies the Access-Request packet to the remote AAA server. On receiving an Access-Accept packet from the remote RADIUS server, the SSG logs the subscriber in. To the remote AAA server, the SSG appears as a client.
If the RADIUS server assigns an IP address to the subscriber during remote authentication, the SSG performs network address translation (NAT) between the assigned IP address and the real IP address of the subscriber. If the remote RADIUS server does not assign an IP address, NAT is not performed.
When a user selects a proxy service, there is another prompt for username and password. After authentication, the service is accessible until the user logs out from the service, logs out from the SESM, or times out.
The events that occur to enable proxy service are described in the steps below (steps also shown in Figure 3-7).
1. The GGSN sends an access request to the RADIUS Load Balancer (RLB).
2. The RLB receives the access request, selects an SSG, and forwards the request to the SSG.
3. The SSG receives the request and performs a full, transparent proxy of the request to the AAA server (to ensure propagation of all RADIUS attributes).
4. The AAA server authenticates the user and allocates an IP address for the user session. The AAA server sends the IP address and a user profile to the SSG.
5. The SSG forwards this information to the RLB and creates a host object for the user session.
6. The RLB retrieves the user IP address and sends it to the GGSN.
7. The GGSN sends the IP address to the mobile handset. It also sends a message to the RLB to start accounting records and forwards the message to the SSG.
8. The SSG proxies the message to the AAA server to start accounting records.
9. The proxy service is enabled and the user session is active.
10. The SSG periodically proxies interim update messages to the AAA server for accounting purposes.
11. The GGSN generates a message to stop RADIUS accounting records when the subscriber terminates access. The RLB clears the user IP address. The SSG sends out messages to each service the subscriber accessed and terminates the host object for the user session.
Layer 2 Tunneling Protocol (L2TP) enables mobile wireless subscribers to access a tunnel to an L2TP network server (LNS) for virtual private networking (VPN) applications. The typical application for tunnel service is employee access to corporate networks from remote locations. Tunnel services are targeted to enterprises and generate high revenues for service providers.
In this configuration, it is assumed that the CMX is connected to a GGSN through any IP connection.
The events that occur to enable tunnel service are described in the steps below (steps also shown in Figure 3-8).
1. The user is already connected, and a host object is created in the SSG. The user starts a user session on the provider's Web portal.
2. The Web portal (via the SESM) queries the SSG to verify that a host object exists; if no host object exists, the user is redirected (via the TCP redirect feature) to a login page.
3. The user selects the tunnel service on the Web portal; the Web portal sends an access request to the SSG to enable the creation of the tunnel service.
4. The SSG proxies the access request to the AAA server and queries the AAA server for a service profile.
5. The SSG sets up the tunnel service. The SSG can receive an IP address from the remote network server and create a network address translation (NAT) entry between the user's address domain and the address received from the network server.
6. Data traffic flows on the tunnel (see note) established between the user and the remote network server.
The Service Selection Gateway (SSG) supports the tunnel service with the following configurable features:
|
Note |
The SSG auto-logon feature allows the SSG to automatically create a host object for a user session and retrieve the user profile from the RADIUS messages sent by the GGSN. With the auto-logon feature, the SSG acts as a RADIUS proxy. The following steps describe the sequence of events that occur when the auto-logon feature is configured on the SSG.
|
Note Load balancing interactions are excluded from the following sequence to clarify auto-logon interactions between the GGSN, SSG, AAA server, and SESM. |
1. When the GGSN receives a request for access from the mobile wireless subscriber, it sends a RADIUS access request to the SSG.
2. The SSG, configured with the auto-logon feature, forwards the request to the AAA server.
3. The AAA server authenticates the user, allocates an IP address, and sends vendor-specific attributes (VSAs) related to the user services.
4. The SSG strips off the SSG VSAs, creates a host object for the user session, and sends this information to the GGSN.
5. The PDP context is created (i.e., the user has an IP connection and can access the SESM with a Web browser). The GGSN sends a message to start accounting records for the session. The message is proxied by the SSG to the AAA server.
6. The SESM receives the HTTP request and queries the SSG.
7. The SSG responds with the username, IP address, service list, and SESM attributes.
8. The SESM uses the RADIUS interface to access a database and retrieve the user service attributes.
9. The service attributes are sent using the RADIUS interface.
10. The user home page is sent in the HTTP response to the subscriber.
Figure 3-9 illustrates these auto-logon interactions:
The SSG TCP redirect feature transmits certain packets, which would otherwise be dropped, to captive portals that can handle the packets. Examples of packet redirection include the following:
The following steps describe the sequence of events that occur when the TCP redirect feature is configured on the SSG.
|
Note Load balancing interactions are excluded from the following sequence to clarify TCP redirect interactions between the SSG, AAA server, and SESM. |
1. An IP-enabled PC accesses the SESM using a Web client. User ID and password fields are presented in HTML format.
2. The SESM translates the user ID and password received via HTML into a RADIUS authentication packet and sends it to the SSG.
3. The SSG forwards the RADIUS request to the AAA server.
4. The AAA server responds to the SSG.
5. The SSG forwards the response to the SESM and creates a host object to establish the user session.
6. The SESM requests service profiles from the AAA server.
7. The AAA server responds to the SESM request with the service profiles.
8. The SESM provides a new HTML page to the user with service selection links.
Figure 3-10 illustrates these TCP redirect interactions:
The TCP redirect feature also ensures availability of user sessions in the event that a single SSG fails. The following events occur when an SSG fails:
1. The RADIUS Load Balancer (RLB) detects the failure of the SSG and load balances the user traffic to an alternate SSG.
2. The alternate SSG receives the user data but does not have a host object for the user. The SSG redirects the user traffic to the Web portal.
3. The user establishes an HTTP session with the Web portal using a browser. The user logs in, and the new SSG receives an access request from the Web portal. The user host object is created and pass-through service is established.
4. The user traffic passes through the new SSG.
RADIUS messages originate from one of the following network elements:
The following sequence of events describes the flow of RADIUS messages that originate from the GGSN during a request for access:
1. The GGSN forwards an Access Request message to the RLB (see Figure 3-11).
2. The RLB selects an SSG from the SSG farm.
3. The selected SSG proxies the request to the AAA-RLB.
4. The AAA-RLB selects the AAA1 server.
5. The AAA1 server is in a failure mode and does not respond to the request.
6. The GGSN retransmits the request.
7. The RLB detects the retransmission and resends the request to the same SSG that was originally selected.
8. The SSG proxies the request to the AAA-RLB.
9. The AAA-RLB selects the AAA2 server and marks the AAA1 server as failed.
10. The AAA2 server returns the Access Accept message to the SSG and then back to the GGSN.
The GGSN-initiated RADIUS message flow is shown in Figure 3-11.
The RLB uses the RADIUS request identifier to detect retransmissions and mark the AAA server as failed.
The sequence is slightly altered for an Accounting Request message. In this case, the RLB does not detect retransmissions from the GGSN. The RLB marks the SSG as failed. To avoid having the SSG marked as failed because of Accounting Request retranmissions, you can configure a probe on the RLB to periodically verify that one SSG is still operational.
The following sequence of events describes the flow of RADIUS messages that originate from the SSG during a request for access:
1. The SSG forwards an Access Request message to the AAA-RLB (see Figure 3-12).
2. The AAA-RLB selects the AAA1 server.
3. The AAA1 server is in a failure mode and does not respond to the request.
4. The SSG retransmits the request.
5. The AAA-RLB selects the AAA2 server and marks the AAA1 server as failed.
6. The AAA2 server returns the Access Accept message to the SSG.
SSG-initiated RADIUS message flows are shown in Figure 3-12.
The same limitations for GGSN-initiated accounting requests apply to SSG-initiated accounting requests. You can configure a probe on the RLB to periodically verify that one AAA server is still operational.
The CMX framework enables a billing solution for mobile wireless operators that is flexible and facilates transition to next-generation networks. In legacy networks, operators charge users based on the duration of the call. In next-generation networks, the user is always on; therefore, charging based on time is not appropriate.
The CMX framework allows per-service billing based on volume (number of packets), type of content, and the applications accessed. The CMX generates the billing and accounting information, which is then used by the billing agent to bill the subscriber.
Cisco enables solutions for prepaid and postpaid billing using two components. The Service Selection Gateway (SSG) provides service volume and time accounting information. The CSG provides information based on content (Layer 4 and Layer 7).
The two CMX components that play key roles in providing prepaid billing are the SSG and the CSG.
The SSG prepaid features allow the SSG to check a subscriber's available credit to determine whether to connect the subscriber to a service and how long the connection can last. The subscriber's credit is administered by the prepaid billing server as a series of quotas representing either a duration of use (in seconds) or an allowable data volume (in bytes). A quota is an allotment of available credit for a service.
To obtain the first quota for a connection, the SSG submits an authorization request to the AAA server. The AAA server contacts the prepaid billing server, which forwards the quota values to the SSG. The SSG monitors the connection to track the quota usage. When the quota runs out, the SSG performs reauthorization. During reauthorization, the billing server can provide the SSG with an additional quota if credit is available. If no further quota is provided, the SSG logs the user off the service. The user can be redirected to a Web server to refill accounts.
A prepaid idle timeout feature allows remaining quota to be returned to the billing server if the connection remains inactive (idle) for a specified period of time. Also, if a disconnect occurs before quota depletion, the SSG returns the unused amount to the billing server.
Figure 3-13 shows the prepaid billing solution provided by the SSG (see note).
|
Note The configuration shown in Figure 3-13 integrates the MIND CTI Real-Time Server, which provides the AAA, rating, and billing capabilites for the overall solution. |
As shown in Figure 3-13, the SSG sends an access/authorization request to the billing mediation agent (BMA) to retrieve quotas and accounting records.
The CSG occupies two positions in the CMX configuration. The first CSG in the CMX configuration, represented in Figure 3-13 as CSG1, generates call detail records (CDRs) of statistics and sends them to the BMA. These CDRs are used to restore the user's balance in the event of an SSG failure. This CSG provides an important backup function for the SSG prepaid billing features.
The second CSG in the CMX configuration is configured to provide content-based billing. Web pages are identified by their URLs and charged on a fixed-fare basis, also known as per-page billing. The subscriber incurs billing in real time as the Web page is requested.
The service provider can also configure this CSG to perform per-event billing from within a Web page to charge subscribers for downloading files. These events, also known as stats, must be structured in a keyed directory tree to distinguish them from events for which no billing occurs. Also, subscribers are billed only for files that are completely transferred (i.e., failed downloads are not billed). Files to be downloaded must reside on a dedicated server (i.e., the IP destination address of the downloading server must be different than the IP destination address of the Web server).
Per-page billing (URL-based) and per-event billing (stats) are provided by CSG2 shown in Figure 3-14. The BMA connects to a database and a billing server to verify user balances and perform rating and billing functions (see note).
|
Note The configuration shown in Figure 3-14 integrates the MIND CTI Real-Time Server, which provides the AAA, rating, and billing capabilites for the overall solution. |
Postpaid billing based on time and volume usage is implemented by the SSG. The accounting start message sent to the AAA server initiates accounting records for the session. When the user disconnects from a service, the SSG sends an accounting stop message to the AAA server. During the user session, the SSG periodically sends interim-update messages to update the time and volume used. The RADIUS accounting records record the service volume and session duration for billing purposes.
The CSG allows service providers to bill subscribers based on service content instead of time and volume used. The CSG records user traffic based on the URL entered by the end user. Web pages that are billed can be structured as previously described (see CSG Role).
The CSG sends the content-based call detail records to a billing mediation agent (BMA) over a GTP' interface. The BMA uses the subscriber's IP address to retrieve the MSISDN, which is required to properly identify and charge the subscriber for the content accessed.
The CMX configuration handles any single point of failure by using redundant load-balancing platforms, redundant physical interfaces, and the Hot Standby Router Protocol (HSRP). Each routing element is connected to a standby element through a virtual LAN (VLAN) interface. The links between the RLB and multiple SSGs are maintained on a single VLAN using bridged virtual interfaces (BVIs) on the SSGs. This configuration uses the spanning tree protocol for quick recovery if an interface fails. This solution is based on the following:
Figure 3-15 illustrates the high-reliability solution for the CMX. The RLB1 and FWLB1 are configured to be active, and their peers, RLB2 and FWLB2, are in standby mode. If an active network element fails, the standby element becomes active. Also, both RLB1 and FWLB1 are configured to preempt their peers. For example, if RLB1 fails and RLB2 becomes active, RLB1 resumes activity when its failure condition clears.
The CSGs in the CMX framework are not configured for preemption. For example, if a failure occurs in CSG1, user traffic from the GGSN sequentially traverses RLB1, CSG2, back to RLB1, then to the SSGs. Even if the failure in CSG1 clears, user traffic continues to traverse the path through CSG2.
The numbers shown in Figure 3-15 correspond to the failure scenarios listed below:
1. Failure of an SSG—When an SSG fails, user sessions supported by the SSG are lost. Incoming RADIUS requests for new user sessions are redirected to available SSGs. The RLB detects the SSG failure (using probes) and sends the user traffic to another SSG. The new SSG redirects users to the Web portal to authenticate them and restore user sessions. When the failed SSG restarts, it sends messages to the AAA server to stop accounting.
|
Note The redundant CSGs in the RLB are used for backing up SSG-based prepaid billing records (if an SSG fails). The redundant CSGs in the FWLB provide content billing. |
2. Failure of one RLB—HSRP runs between the two RLBs to maintain RADIUS load-balancing. When one RLB fails, the other RLB takes over the RADIUS load-balancing function.
3. Failure of the RLB-to-FWLB link—Messages are redirected via the links between the two RLBs to the peer FWLB. Spanning Tree Protocol is used to determine the alternate path.
4. Failure of an FWLB—HSRP runs between the FWLBs to maintain load-balancing of sticky objects between them. When one FWLB fails, the other FWLB takes over the load-balancing function.
5. Failure of the link between FWLBs—User traffic is redirected via the link between the RLBs.
6. Failure of a CSG—A fault-tolerance mechanism runs between the CSGs to maintain RLB sticky objects. When one CSG fails, the other CSG takes over.
7. Failure of an SSG link—The SSG supports redundant links to each RLB and FWLB. If one link fails, the other link is used.
8. Failure of the link to the services network—The FWLBs support redundant links to the services network. If one link fails, the other link is used.
9. Failure of the default network link—The RLBs support redundant links to the default network. If one link fails, the other link is used.
The configuration redundancies provided by bridged virtual interfaces (BVIs) in the SSG are illustrated in Figure 3-16. The SSG avoids any single point of failure by its connection to the two CMX VLANs. The failure of a physical interface or port adapter does not impact service.
As shown in Figure 3-16, the FE 0/0 and FE 1/0 ports are used to connect to the access VLAN, which interconnects the RLB for incoming RADIUS and user packets. The FE 0/1 and FE 1/1 ports are used to connect to the services VLAN, which interconnects the FWLB toward the services network. On each VLAN, the SSG is addressed with a single IP address; bridging is used between the interfaces and the IP addresses are configured on the BVIs.
The Spanning Tree Protocol (STP) is used to find a Layer 2 path between all the components when a physical interface fails. The RLB 1, which has the highest HSRP priority (active), is configured as the primary bridge root on the access and services VLANs. The RLB 2, which has the lowest HSRP priority (standby), is configured as the secondary bridge root on the access and services VLAN.
Posted: Tue Dec 31 04:25:59 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
