Intelligent Wireless Access Gateway

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Intelligent Services Gateway (ISG) is a structured framework in which edge access devices deliver flexible and scalable services to subscribers. ISG handles the following key aspects of subscriber management:

• Subscriber identification
• Service and policy determination
• Session policy enforcement
• Session life-cycle management
• Accounting for access and service usage
• Session state monitoring

In addition, ISG introduces a dynamic element to the provisioning and activation of services through control policies and Change of Authorization (CoA) extensions to the RADIUS protocol.

An ISG-enabled device may be deployed at the access edge and service edge of a network and is applicable to a range of subscriber network environments, such as digital subscriber line (DSL), public wireless LAN (PWLAN), and mobile wireless network. Moreover, ISG has been designed to accommodate a flexible distribution of subscriber and service information within a given solution. The figure below illustrates a typical DSL deployment for which service profile data may be stored in an authentication, authorization, and accounting (AAA) database and retrieved and cached on demand.

Figure 1

Sample Topology for a DSL Deployment

It is also possible to define services directly on an ISG. In all cases, service activation may be triggered as a result of a locally defined control policy, user profile associations, or CoA commands from an external policy server or portal application.

Proxy Mobile IPv6 (PMIPv6) provides network-based IP Mobility management to a mobile node (MN), without requiring the participation of the MN in any IP mobility-related signaling. The mobility entities in the network track the movements of the MN, initiate the mobility signaling, and set up the required routing state.

The major functional entities of PMIPv6 are Mobile Access Gateways (MAGs), Local Mobility Anchors (LMAs), and MNs.

A Mobile Access Gateway (MAG) performs mobility-related signaling on behalf of the mobile nodes (MN) attached to its access links. MAG is the access router for the MN; that is, the MAG is the first-hop router in the localized mobility management infrastructure.

A MAG performs the following functions:

• Obtains an IP address from a Local Mobility Anchor (LMA) and assigns it to an MN
• Retains the IP address of an MN when the MN roams across MAGs
• Tunnels traffic from an MN to LMA

Local Mobility Anchor (LMA) is the home agent for a mobile node (MN) in a Proxy Mobile IPv6 (PMIPv6) domain. It is the topological anchor point for MN home network prefixes and manages the binding state of an MN. An LMA has the functional capabilities of a home agent as defined in the Mobile IPv6 base specification (RFC 3775) along with the capabilities required for supporting the PMIPv6 protocol.

Note	Use an dynamic mag learning command to enable an LMA to accept Proxy Mobile IPv6 (PMIPv6) signaling messages from any Mobile Access Gateway (MAG) that is not locally configured.

A mobile node (MN) is an IP host whose mobility is managed by the network. An MN can be an IPv4-only node, an IPv6-only node, or a dual-stack node, which is a node with IPv4 and IPv6 protocol stacks. An MN is not required to participate in any IP mobility-related signaling for achieving mobility for an IP address or a prefix that is obtained in the Proxy Mobile IPv6 (PMIPv6) domain.

If an authentication, authorization, and accounting (AAA) server is available, a Mobile Access Gateway (MAG) obtains the profile information of the Proxy Mobile IPv6 (PMIPv6) domain and the mobile node (MN) from the server during the configuration and call-flow time, respectively.

The following are the AAA attributes required for configuring the PMIPv6 domain and the MN are:

• PMIPv6 domain-specific AAA attributes:
  • cisco-mpc-protocol-interface
  • lma-identifier
  • mag-identifier
  • mag-v4-address
  • mag-v6-address
  • pmip6-domain-identifier
  • pmip6-fixed-l1-address
  • pmip6-fixed-l2-address
  • pmip6-timestamp-window
  • pmip6-replay-protection
  • pmip6-spi-key
  • pmip6-spi-value
• MN-specific AAA attributes:
  • home-lma
  • home-lma-ipv6-address
  • mn-apn
  • mn-nai
  • mn-network
  • mn-service
  • multihomed

Mobile Client Service Abstraction (MCSA) is a uniform mechanism that detects the MNs network events that avoid being detected by mobility protocols. MCSA provides interfaces through which the MAG, General Packet Radio Service (GPRS) Tunneling Protocol (GTP) and ISG receive or send event notifications. MCSA delivers discovery event notifications and service event notifications from mobile nodes (MNs) to the appropriate protocol module. When the Intelligent Services Gateway (ISG) is not available, MCSA performs authentication, authorization, and accounting (AAA). MCSA consists of the following three interfaces through which the protocol modules interact:

• MCSA Client Interface
• MCSA Service Interface
• LMA Interface

An Intelligent Services Gateway (ISG) device creates IP sessions for IP traffic on subscriber-side interfaces. The tasks in the following sections enable IP sessions and indicate how sessions are identified:

• Creating ISG IP Interface Sessions
• Creating ISG Static Sessions
• Creating ISG IP Subnet Sessions
• Configuring IP Session Recovery for DHCP-Initiated IP Sessions
• Verifying ISG IP Subscriber Sessions
• Clearing ISG IP Subscriber Sessions
• Troubleshooting ISG IP Subscriber Sessions

Configure DHCP support in your network before performing the tasks in this section.

• Configuring an ISG Interface for Dynamic DHCP Class Association
• Configuring DHCP Server User Authentication
• Configuring a DHCP Class in a Service Policy Map
• Configuring a DHCP Class in a Service Profile or User Profile on the AAA Server
• Configuring a DHCP Server IP Address

• Configuring a Multiservice Interface
• Specifying a VRF in a Service Policy Map
• Verifying VRF Transfer for IP Sessions
• Troubleshooting VRF Transfer for IP Sessions

1.    enable

2.    configure terminal

3.    ipv6 mobile pmipv6-domain domain-name

4.    lma lma-id

5.    ipv6-address ipv6-address

6.    exit

7.    Repeat Steps 5 to 8 to configure the second LMA.

8.    nai [user]@realm

9.    lma lma-id

10.    service {dual | ipv4 | ipv6}

11.    exit

12.    Repeat Steps 10 to 11 to configure the second MN.

13.    end

1.    enable

2.    configure terminal

3.    ipv6 mobile pmipv6-domain domain-name

4.    replay-protection timestamp [window seconds]

5.    auth-option spi {spi-hex-value | decimal spi-decimal-value} key {ascii ascii-string | hex hex-string}

6.    encap {gre-ipv4 | ipv6-in-ipv6}

7.    local-routing-mag

8.    lma lma-id

9.    ipv6-address ipv6-address

10.    exit

11.    Repeat Steps 10 to 12 to configure each LMA.

12.    mag mag-id

13.    ipv6-address ipv6-address

14.    exit

15.    mn-profile-load-aaa

16.    nai [user]@realm

17.    lma lma-id

18.    int att interface-access-type l2-addr mac-address

19.    gre-encap-key [down | up] key-value

20.    service {dual | ipv4 | ipv6}

21.    apn apn-name

22.    exit

23.    Repeat Steps 20 to 24 to configure each MN.

24.    end

1.    enable

2.    configure terminal

3.    mcsa

4.    enable sessionmgr

5.    end

6.    show mcsa statistics

1.    enable

2.    configure terminal

3.    ipv6 mobile pmipv6-mag mag-id domain domain-name

4.    address ipv6 ipv6-address

5.    sessionmgr

6.    generate grekey

7.    interface type number

8.    role {3gpp | lte | wimax | wlan}

9.    apn apn-name

10.    end

1.    enable

2.    configure terminal

3.    vrf definition vrf-name

4.    exit

5.    ipv6 mobile pmipv6-mag mag-id domain domain-name

6.    role {3gpp | wlan}

7.    apn apn-name

8.    local-routing-mag

9.    discover-mn-detach poll interval seconds timeout seconds retries retry-count

10.    address ipv4 ipv4-address

11.    address ipv6 ipv6-address

12.    sessionmgr

13.    interface type number

14.    binding maximum number

15.    binding lifetime seconds

16.    binding refresh-time seconds

17.    binding init-retx-time milliseconds

18.    binding max-retx-time milliseconds

19.    replay-protection timestamp [window seconds]

20.    bri delay min milliseconds

21.    bri delay max milliseconds

22.    bri retry number

23.    lma lma-id domain-name

24.    auth-option spi {spi-hex-value | decimal spi-decimal-value} key {ascii | hex} hex-string

25.    ipv4-address ipv4-address

26.    vrfid vrf-name

27.    encap {gre-ipv4 | ipv6-in-ipv6}

28.    end

29.    show ipv6 mobile pmipv6 mag mag-id globals

• Example
• Troubleshooting Tips

You can determine the DHCP authentication by using the debug ip dhcp server events, debug ip dhcp server packets, and debug subscriber policy dpm event commands. The following is sample output from the debug subscriber policy dpm event command:

*Apr 20 20:20:03.510: SG-DPM: DHCP Discover notification from client, mac_address = 001a.7014.c03e
*Apr 20 20:20:03.510: SG-DPM: getting the context for mac_address = 001a.7014.c03e
*Apr 20 20:20:03.510: SG-DPM: Could not find a dhcp_context for 001a.7014.c03e:
*Apr 20 20:20:03.510: SG-DPM: Sending an ID manager request with key as 001a.7014.c03e
*Apr 20 20:20:03.510: SG-DPM: Received reply from Id manager
*Apr 20 20:20:03.510: SG-DPM: Session Initiation notification on Active
*Apr 20 20:20:03.510: SG-DPM: Allocated SHDB Handle (0xB6000252) for Mac address 001a.7014.c03e
*Apr 20 20:20:03.510: SG-DPM: Client is able to perform DHCP Authentication.Setting the SSS_INFOTYPE_DHCP_AUTH_KEY
*Apr 20 20:20:03.510: SG-DPM: Sending Session start to PM, mac_address = 001a.7014.c03e
*Apr 20 20:20:03.514: SG-DPM: Request for Classname from client, mac_address = 001a.7014.c03e
*Apr 20 20:20:03.514: SG-DPM: getting the context for mac_address = 001a.7014.c03e
*Apr 20 20:20:03.514: SG-DPM: Sending an ID manager request with key as 001a.7014.c03e
*Apr 20 20:20:03.514: SG-DPM: Received reply from Id manager
*Apr 20 20:20:03.514: SG-DPM: No session found in ID manager
*Apr 20 20:20:03.514: SG-DPM: Processing sg_dpm_get_more_keys from SSS hdl 56000E52
*Apr 20 20:20:03.514: SG-DPM: DPM is providing Auth-User

You can also use the show subscriber session detailed and show ip dhcp binding commands to display subscriber information and DHCP pool information. The following is sample output from the show ip dhcp binding command:

Device# show ip dhcp binding

Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
                    Hardware address/
                    User name
10.0.0.1            0100.1a70.1530.38       Nov 18 2008 03:43 PM    Automatic