Intelligent Wireless Access Gateway Configuration Guide
Call Flows for Dual-Stack PMIPv6 and GTP
Downloads: This chapterpdf (PDF - 1.65MB) The complete bookPDF (PDF - 6.18MB) | The complete bookePub (ePub - 1.55MB) | Feedback

Call Flows for Dual-Stack PMIPv6 and GTP

Call Flows for Dual-Stack PMIPv6 and GTP

This chapter provides call flows for dual-stack Proxy Mobile IPv6 (PMIPv6) and GPRS Tunnel Protocol (GTP), and contains the following sections:

Finding Feature Information

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.

Dual-Stack Mobile IPoE Session with DHCPv4 as FSOL for PMIPv6 Call Flow

The following figure and steps describe the call flow pertaining to a Dual-Stack Mobile IP over Ethernet (IPoE) session with Dynamic Host Configuration Protocol version 4 (DHCPv4) as first sign of life (FSOL) for PMIPv6.

Figure 1. Dual-Stack Mobile IPoE Session with DHCPv4 as FSOL for PMIPv6 Call Flow

  1. A mobile device is automatically associated to the service set identifier (SSID) broadcast by the access points to establish and maintain wireless connectivity.
  2. The access point (AP) or Wireless LAN controller (WLC) starts the authentication process using Extensible Authentication Protocol (EAP) by sending an EAP Request ID to the mobile device.
  3. The mobile device sends a response for the EAP Request ID back to the AP or WLC.
  4. Upon successful authentication, the mobile device sends a DHCPv4 Discover message to the iWAG.
  5. The iWAG sends a RADIUS Access Request to the AAA server asking it to authenticate the subscriber.
  6. The iWAG creates a MAC-based ISG session and pulls the subscriber profile from the AAA server. If the profile has the AAA attribute value as "Cisco-AVPair=mn-service=dual", then the subscriber is authorized for both IPv4 and IPv6 data transfer. Similarly, the AAA attribute value of "Cisco-AVPair=mn-service=ipv4" or "Cisco-AVPair=mn-service=ipv6" represents the IPv4 or IPv6 protocol, using which the subscriber is authorized to send data.
  7. The iWAG checks whether the ISG session for the MAC address is initiated or created.
  8. The AAA server sends the RADIUS Access Accept message to the iWAG.
  9. If the received profile has "cisco-mpc-protocol-interface" attribute with value as pmipv6, then iWAG initiates PMIPv6 tunneling by sending a Proxy Binding Update (PBU) message to the local mobility anchor (LMA).
  10. The LMA responds with a Proxy Binding Acknowledgment (PBA) message that includes IP address, gateway, and mask.
  11. The PMIPv6 tunnel is established between the iWAG and the LMA.
  12. The iWAG sends the IPv4 address through a DHCP Offer message to the mobile device. The iWAG provisions the IPv4 stack.
  13. The IPv4 traffic can flow through the PMIPv6 tunnel.
  14. The mobile device sends an IPv6 FSOL that could be router solicit, neighbor solicit, or neighbor advertisement, to the iWAG.
  15. In response to the IPv6 (RS) FSOL sent, the iWAG sends a router advertisement (RA) packet using SLAAC that includes the IPv6 prefix, to the mobile device. The mobile device appends the IPv6 prefix to it's 64-bit (EUI or MAC address appended with FFFE) to form a unique 128 bit address.
  16. Both the IPv4 and IPv6 traffic can flow through the PMIPv6 tunnel.

Dual-Stack Mobile IPoE Session with IPv6 ND as FSOL for PMIPv6 Call Flow

The following figure and steps describe the call flow pertaining to a Dual-Stack Mobile IP over Ethernet (IPoE) session with IPv6 Neighbor Discovery (ND) as first sign of life (FSOL) for PMIPv6 Call Flow.

Figure 2. Dual-Stack Mobile IPoE Session with IPv6 ND as FSOL for PMIPv6 Call Flow

  1. A mobile device is automatically associated to the service set identifier (SSID) broadcast by the access points to establish and maintain wireless connectivity.
  2. The access point (AP) or Wireless LAN controller (WLC) starts the authentication process using Extensible Authentication Protocol (EAP) by sending an EAP Request ID to the mobile device.
  3. The mobile device sends a response for the EAP Request ID back to the AP or WLC.
  4. Upon successful authentication, the mobile device sends an IPv6 FSOL that could be router solicit, neighbor solicit, or neighbor advertisement, to the iWAG.
  5. The iWAG sends a RADIUS Access Request to the AAA server asking it to authenticate the subscriber.
  6. The iWAG creates a MAC-based ISG session and pulls the subscriber profile from the AAA server. If the profile has the AAA attribute value as "Cisco-AVPair=mn-service=dual", then the subscriber is authorized for both IPv4 and IPv6 data transfer. Similarly, the AAA attribute value of "Cisco-AVPair=mn-service=ipv4" or "Cisco-AVPair=mn-service=ipv6" represents the IPv4 or IPv6 protocol, using which the subscriber is authorized to send data.
  7. The iWAG checks whether the ISG session for the MAC address is initiated or created.
  8. The AAA server sends the RADIUS Access Accept message to the iWAG.
  9. If the received profile has "cisco-mpc-protocol-interface" attribute with value as pmipv6, then iWAG initiates PMIPv6 tunneling by sending a Proxy Binding Update (PBU) message to the local mobility anchor (LMA).
  10. The LMA responds with a Proxy Binding Acknowledgment (PBA) message that includes IP address, gateway, and mask.
  11. The PMIPv6 tunnel is established between the iWAG and the LMA.
  12. In response to the IPv6 (RS) FSOL sent, the iWAG sends a router advertisement (RA) packet using SLAAC that includes the IPv6 prefix, to the mobile device. The mobile device appends the IPv6 prefix to it's 64-bit (EUI or MAC address appended with FFFE) to form a unique 128 bit address.
  13. The IPv6 traffic can flow through the PMIPv6 tunnel.
  14. The mobile device sends a DHCPv4 Discover message to the iWAG.
  15. The iWAG sends the IPv4 address through a DHCP Offer message to the mobile device. The iWAG provisions the IPv4 stack.
  16. Both the IPv4 and IPv6 traffic can flow through the PMIPv6 tunnel.

Dual-Stack Mobile IPoE Session with DHCPv4 as FSOL for GTP Call Flow

The following figure and steps describe the call flow pertaining to a Dual-Stack Mobile IP over Ethernet (IPoE) session with Dynamic Host Configuration Protocol version 4 (DHCPv4) as first sign of life (FSOL) for GTP.

Figure 3. Dual-Stack Mobile IPoE Session with DHCPv4 as FSOL for GTP Call Flow

  1. A mobile device is automatically associated to the service set identifier (SSID) broadcast by the access points to establish and maintain wireless connectivity.
  2. The access point (AP) or Wireless LAN controller (WLC) starts the authentication process using Extensible Authentication Protocol (EAP) by sending an EAP Request ID to the mobile device.
  3. The mobile device sends a response for the EAP Request ID back to the AP or WLC.
  4. Upon successful authentication, the mobile device sends a DHCPv4 Discover message to the iWAG.
  5. The iWAG sends a RADIUS Access Request to the AAA server asking it to authenticate the subscriber.
  6. The iWAG creates a MAC-based ISG session and pulls the subscriber profile from the AAA server. If the profile has the AAA attribute value as "Cisco-AVPair=mn-service=dual", then the subscriber is authorized for both IPv4 and IPv6 data transfer. Similarly, the AAA attribute value of "Cisco-AVPair=mn-service=ipv4" or "Cisco-AVPair=mn-service=ipv6" represents the IPv4 or IPv6 protocol, using which the subscriber is authorized to send data.
  7. The iWAG checks whether the ISG session for the MAC address is initiated or created.
  8. The AAA server sends the RADIUS Access Accept message to the iWAG.
  9. If the received profile has "cisco-mpc-protocol-interface" attribute with value as GTP, then iWAG initiates GTP tunneling by sending a Create PDP Context Request to the GGSN.
  10. The GGSN sends a RADIUS Access Request to the AAA server.
  11. The AAA server replies with a RADIUS Access Accept message to the GGSN.
  12. The GGSN sends a Create PDP Context Response.
  13. The GTP-U tunnel is established between the iWAG and the GGSN.
  14. The iWAG sends the IPv4 address through a DHCP Offer message to the mobile device. The iWAG provisions the IPv4 stack.
  15. The IPv4 traffic can flow through the GTP-U tunnel.
  16. The mobile device sends an IPv6 FSOL that could be router solicit, neighbor solicit, or neighbor advertisement, to the iWAG.
  17. In response to the IPv6 (RS) FSOL sent, the iWAG sends a router advertisement (RA) packet using SLAAC that includes the IPv6 prefix, to the mobile device. The mobile device appends the IPv6 prefix to it's 64-bit (EUI or MAC address appended with FFFE) to form a unique 128 bit address.
  18. Both the IPv4 and IPv6 traffic can flow through the GTP-U tunnel.

Note


The DHCPv4 Discover initiator may come at any point later in the call flow, that is, even after tunnels are created. Though, the subscriber has requested only for a single ipv6 address, the iWAG requests both ipv4 and ipv6 addresses from GGSN and the tunnel is a dual-stack tunnel while the session is a single stack session until the second initiator is received from the mobile device.

Dual-Stack Mobile IPoE Session with IPv6 ND as FSOL for GTP Call Flow

The following figure and steps describe the call flow pertaining to a Dual-Stack Mobile IP over Ethernet (IPoE) session with IPv6 Neighbor Discovery (ND) as first sign of life (FSOL) for GTP.

Figure 4. Dual-Stack Mobile IPoE Session with IPv6 ND as FSOL for GTP Call Flow

  1. A mobile device is automatically associated to the service set identifier (SSID) broadcast by the access points to establish and maintain wireless connectivity.
  2. The access point (AP) or Wireless LAN controller (WLC) starts the authentication process using Extensible Authentication Protocol (EAP) by sending an EAP Request ID to the mobile device.
  3. The mobile device sends a response for the EAP Request ID back to the AP or WLC.
  4. Upon successful authentication, the mobile device sends an IPv6 FSOL that could be router solicit, neighbor solicit, or neighbor advertisement, to the iWAG.
  5. The iWAG sends a RADIUS Access Request to the AAA server asking it to authenticate the subscriber.
  6. The iWAG creates a MAC-based ISG session and pulls the subscriber profile from the AAA server. If the profile has the AAA attribute value as "Cisco-AVPair=mn-service=dual", then the subscriber is authorized for both IPv4 and IPv6 data transfer. Similarly, the AAA attribute value of "Cisco-AVPair=mn-service=ipv4" or "Cisco-AVPair=mn-service=ipv6" represents the IPv4 or IPv6 protocol, using which the subscriber is authorized to send data.
  7. The iWAG checks whether the ISG session for the MAC address is initiated or created.
  8. The AAA server sends the RADIUS Access Accept message to the iWAG.
  9. If the received profile has "cisco-mpc-protocol-interface" attribute with value as GTP, then iWAG initiates GTP tunneling by sending a Create PDP Context Request to the GGSN.
  10. The GGSN sends a RADIUS Access Request to the AAA server.
  11. The AAA server replies with a RADIUS Access Accept message to the GGSN.
  12. The GGSN sends a Create PDP Context Response.
  13. The GTP-U tunnel is established between the iWAG and the GGSN.
  14. In response to the IPv6 (RS) FSOL sent, the iWAG sends a router advertisement (RA) packet using SLAAC that includes the IPv6 prefix, to the mobile device. The mobile device appends the IPv6 prefix to it's 64-bit (EUI or MAC address appended with FFFE) to form a unique 128 bit address.
  15. The IPv6 traffic can flow through the GTP-U tunnel.
  16. The mobile device sends a DHCPv4 Discover message to the iWAG.
  17. The iWAG sends the IPv4 address through a DHCP Offer message to the mobile device. The iWAG provisions the IPv4 stack.
  18. Both the IPv4 and IPv6 traffic can flow through the GTP tunnel.

Additional References

Related Documents

MIBs

MIB

MIBs Link

No new or modified MIBs are supported by this feature.

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http:/​/​www.cisco.com/​go/​mibs

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http:/​/​www.cisco.com/​cisco/​web/​support/​index.html

Feature Information for Call Flows for Dual-Stack PMIPv6 and GTP

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

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.

Table 1 Feature Information for Call Flows for Dual-Stack PMIPv6 and GTP

Feature Name

Releases

Feature Information

Call Flows for Dual-Stack PMIPv6 and GTP

Cisco IOS XE Release 3.11

In Cisco IOS XE Release 3.11S, this feature was implemented on the Cisco ASR 1000 Series Aggregation Services Routers.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http:/​/​www.cisco.com/​go/​trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)