Packet Data Interworking Function Overview

Packet Data Interworking Function Overview
 
 
This chapter discusses the features and functions of Packet Data Interworking Function (PDIF) software. It includes the following topics:
 
 
Product Description
The goal of the Fixed Mobile Convergence (FMC) application is to enhance the in-building cellular coverage for FMC subscribers, to reduce the cost of the infrastructure required to carry these calls, and to provide secure access to the carrier’s network from a non-secure network. Designed for use exclusively on the Cisco® ASR 5000 Chassis, the Packet Data Interworking Function (PDIF) is a network function based on the 3GPP2 X.S0028-200 standard defining cdma2000 Packet Data Services over an 802.11 WLAN.
A PDIF allows mobile devices to access the Internet over an all-IP WLAN using IKEv2 as the signaling interface. The IKEv2 control path exists between the mobile station (MS) (a dual-mode handset (DMH)) and the PDIF establishing an IPSec tunnel. PDIF also acts as a security gateway protecting CDMA network resources and data (see the Interfaces section). The PDIF is tightly integrated with a collocated Foreign Agent (FA) service, and the PDIF is known throughout this manual as PDIF/FA.
For handsets that do not support mobile IP, PDIF supports proxy mobile IP. If the MS is not suitable for proxy mobile IP registration, it may still be allowed to establish a simple IP session, in which case the traffic is directly routed to the Internet or corporate network from the PDIF. This behavior is controlled through the proxy-mip-required configuration in the domain, local default subscriber, or the corresponding Diameter AVP or RADIUS Access Accept. If this is not present, establishing a simple IP session is permitted. Proxy-MIP is documented in the System Enhanced Features Configuration Guide. Although not required for Proxy-MIP, this manual documents Proxy-MIP with a custom-designed feature called multiple authentication (Multi-Auth). Instead of the more usual subscriber authentication, Multi-Auth requires both the device and the subscriber be authenticated using EAP/AKA authentication for the first stage (the device authentication) and GTC/MD5 for the second stage (the subscriber authentication). For this installation, neither GTC nor MD5 is supported, which means authentication is done using PAP/CHAP instead.
When the subscriber is mobile, the MS operates as a normal mobile phone, sending voice and data over the CDMA network. When the FMC subscriber returns home, or encounters a WiFi hotspot, the MS detects the presence of the WiFi network, and automatically establishes an IPSec session with the PDIF/FA. When the secure connection has been established and mobile IP registration procedures successfully finished, the PDIF/FA works with other network elements to provide the MS with access to packet data services.
From here, all voice and data communication is carried over the IPSec tunnel and the PDIF/FA functions as a pass-through for the authentication and accounting information on a RADIUS and/or Diameter server. The MS continues operating over the IPSec tunnel until such time as it can no longer access the WiFi Access Point (AP). At this point, the MS switches back to the CDMA network for normal mobile operation.
 
Product Specifications
The following information is located in this section:
 
 
Operating System Requirements
The PDIF operates on the ASR 5000 running StarOS Release 8.1 or later.
 
Platforms
The PDIF operates on the ASR 5000.
 
Hardware Requirements
 
System Management Cards (SMCs): SMCs provide full system control and management of all cards within the ASR 5000. Up to two SMCs can be installed; one active, one redundant.
Packet Services Cards (PSCs/PSC2s): PSCs provide high-speed, multi-threaded PDP context processing capability. Up to 14 PSCs can be installed, allowing for multiple active and/or redundant cards.
Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SMCs, SPIOs provide connectivity for local and remote management. Up to 2 SPIOs can be installed: one active, one redundant.
Line Cards: Installed directly behind the PSCs, these cards provide the physical interfaces from the PDIF to various elements in the network. Up to 26 line cards can be installed for a fully loaded system with 13 active PSCs: 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant PSCs do not require line cards. Ethernet 10/100 Fast Ethernet and/or Gigabit Ethernet 1000 and/or four-port Quad Gig-E line cards (QGLCs) all provide redundant IP connections.
Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100 or Ethernet 1000 line cards/QGLCs and every PSC in the system for redundancy. Two RCCs can be installed to provide redundancy for line cards and PSCs.
PDIF Chassis Hardware Configuration Options
For full descriptions, and for more information on installing, populating, and maintaining the ASR 5000 and its hardware, refer to the Hardware Installation and Administration Guide.
 
Licenses
The PDIF is a licensed product with a session counting license, which can be purchased in 1,000 or 10,000 session increments. For information about PDIF licenses, contact your sales representative.
 
Interfaces
 
The figure below shows how the PDIF/FA acts as a security gateway between the Internet and packet data services. All components are located in the home network.
PDIF/FA Mobile IP Interfaces
 
1.
2.
3.
4.
5.
 
Sample Deployments
The following are some sample deployments using a PDIF/FA.
 
Mobile Station using Mobile IP with PDIF/FA
 
Overview
As shown in the figure below, the PDIF/FA supports the Fixed Mobile Convergence (FMC) application, which employs a Dual Mode Handset (DMH) to provide a VoIP solution over an IP-based WiFi broadband network. The DMH can access the traditional CDMA voice and data networks over the Radio Access Network (RAN). Over the RAN, the DMH implements circuit-switched voice and standard mobile IP (MIP) data over EVDO Rev. A, using the services of a PDSN and an HA.
 
PDIF/FA Mobile IP Implementation
Alternately, the DMH can send both voice and data over WiFi when a local AP is available. When the DMH connects to the AP, it establishes an IPSec tunnel over the broadband access network. This tunnel terminates at the PDIF/FA.
The DMH initially gets an IP address, also known as a Tunnel Inner Address (TIA), from the PDIF/FA when the DMH establishes the first IPSec tunnel. The PDIF/FA assigns the TIA from its IP address pool. The DMH then starts mobile IP through this initial TIA-based IPSec tunnel.
When the DMH successfully sets up mobile IP, it receives the home address from the HA. The DMH then establishes a second IPSec tunnel using this HA. Once the DMH successfully establishes the second IPSec tunnel with the PDIF/FA, the PDIF/FA tears down the first TIA-based IPSec tunnel to free the TIA, which then returns to the IP address pool. If required, use the no release-tia command in config-subscriber mode to prevent the TIA from returning to the pool. The DMH sends packetized voice and data through the PDIF/FA to the HA through the second IPSec tunnel.
In this scenario, the PDIF/FA forwards all the packets between the DMH and the HA. From there, voice packets are delivered to the Session Initiation Protocol (SIP) infrastructure, while data is delivered to the Internet or other appropriate destinations.
 
Mobile IP / Native Simple IP Call Minimum Requirements
The following provides the minimum requirements for each call type:
 
Mobile IP Calls
The PDIF/FA assumes MIP tunnel establishment over IPSec tunnel as part of the PDIF call flow as soon as any one of the following three possible conditions is met:
 
1.
2.
3.
 
Native Simple IP Calls
The PDIF/FA assumes a native simple IP session over an IPSec tunnel if:
 
1.
2.
3.
 
Mobile IP Session Setup over IPSec
 
The following diagram and table describe the mobile IP session setup over IPSec.
 
Mobile IP Session Setup over IPSec
Mobile IP over IPSec Call Flow Description
 
Simple IP and Simple IP Fallback
For some simple IP deployments, the PDIF/FA authenticates the MS and provides an IP address for packet data services. In addition, the PDIF/FA supports Simple IP fallback if the MS abandons mobile IP operations due to not being able to successfully finish mobile IP registration after the first TIA-based IPSec tunnel is established. These scenarios are described below.
 
PDIF Simple IP Implementation
As described for mobile IP, during the initial IPSec tunnel establishment the MS gets a publicly routable TIA from a pool specified in the Framed Pool RADIUS attribute. When the IKEv2 negotiation finishes, an IPSec SA with a TIA is established as shown above.
Under normal situations, the MS successfully finishes mobile IP and establishes a new IPSec tunnel. However, if mobile IP fails, and simple IP fallback mode is enabled, the MS can revert to simple IP fallback mode and start using the TIA as the source IP address for all communication.
Important: Simple IP fallback is disabled by default. Use the pdif mobile-ip simple-ip-fallback command in config-subscriber mode to enable simple IP fallback.
Under these circumstances, the PDIF/FA opens the IPSec tunnel to data traffic and forwards any packets from the MS to the Internet directly. Any received packets from the Internet will be forwarded to the MS. A summary of this process from the point the TIA is assigned is given below:
 
Simple IP Fallback Message Sequence
Simple IP Fallback Message Sequence
 
Simple IP Fallback Minimum Requirements
There are certain minimum requirements for simple IP fallback, as follows:
 
 
configuration
  context <pdif-in>
     subscriber default
     pdif mobile-ip simple-ip-fallback
     exit
 
 
Features and Functionality - Base Software
This section describes the features and functions supported by default in the base PDIF software and the benefits they provide.
 
Important: All known restrictions are shown in Appendix B.
The following is a list of the features in this section:
 
 
PSC2 Support
The PDIF supports the Packet Services Card 2 (PSC2). The PSC2 is the next-generation packet forwarding card for the ASR 5000. The PSC2 provides increased aggregate throughput and performance, and a higher number of subscriber sessions.
The PSC2 has been enhanced with a faster network processor unit, featuring two quad-core x86 2.5Ghz CPUs, 32 GB of RAM. These processors run a single copy of the operating system. The operating system running on the PSC2 treats the two dual-core processors as a 4-way multi-processor.
The PSC2 has a 2.5 G/bps-based security processor that provides the highest performance for cryptographic acceleration of next-generation IP Security (IPSec), Secure Sockets Layer (SSL), and wireless LAN/WAN security applications with the latest security algorithms.
For more information about PSC2s, see the Product Overview Guide.
 
Duplicate Session Detection
When an MS sets up a new session, the PDIF automatically checks for any remnants of abandoned calls and if found, clears them.
During a call, the processes of clearing the old session and establishing the new session run in parallel, optimizing processing functions.
With every new session setup, the PDIF supports a mechanism to verify whether there is any old session that is bound with the same International Mobile Subscriber Identity (IMSI) number. This is derived from the Callback-Id AVP in the last DEA message from the HSS after it has verified the subscriber.
For example, if an MS accesses the PDIF and subsequently moves out of the Wi-Fi coverage area, when the MS comes back on line, it could initiate a new session. After authentication, if an old session with the same IMSI is detected, the PDIF starts clearing it by sending a proxy-MIP Deregistration request to the HA. Once a Deregistration request is sent and a Deregistration response is received, the PDIF resumes the new session setup by sending a proxy-MIP Registration request. This setup procedure continues after the PDIF receives a proxy-MIP Deregistration response from the HA.
IMSI-based duplicate session detection is supported per source PDIF context. The PDIF requires only one source context to be configured per PDIF, therefore duplicate session detection across the entire chassis is possible. The feature is designed with the assumption that no more than one call with duplicate identifies are in the setup stage at any time. There is no limit to the number of duplicate session handling iterations.
When an old session is cleared, the PDIF sends Diameter STR messages and Radius Accounting STOP messages to corresponding AAA servers.
The PDIF allows duplicate session detection based on the NAI or IMSI. Note that when detecting based on the NAI, it is the first-phase (Multi-Authentication device authentication phase) NAI that is used.
If NAI-based duplication session handling is enabled, the PDIF sends an INFORMATIONAL (Delete) message to the MS.
Duplicate Session Detection is configured in PDIF-Service mode. The default is NAI-based.
Note that this configuration applies only to calls established after the configuration is made. It is therefore suggested that this selection be made in the boot-time configuration before any calls are established. For example, if NAI-based is used initially and an X number of calls is established, and then the configuration changes to IMSI-based, IMSI-based duplicate session handling does not apply to the calls established before the configuration change.
 
Unsupported Critical Payload Handling
This feature provides a mechanism whereby the PDIF ignores all unsupported critical payloads and continues processing as if those payloads were never received.
For MOBIKE IKEv2 messages, the PDIF returns UNSUPPORTED_CRITICAL_PAYLOAD in the IKEv2 response messages. The PDIF also drops all NAT-T keep-alive messages.
 
Registration Revocation
Registration Revocation is a general mechanism whereby the HA providing mobile IP or proxy mobile IP functionality to a mobile node notifies the PDIF/FA of the termination of a binding. This functionality provides the following benefits:
 
Important: Mobile IP registration revocation is also supported for proxy mobile IP. However, in this implementation, only the HA can initiate the revocation.
Important: For more information, see Mobile-IP Registration Revocation in the System Enhanced Feature Configuration Guide.
 
CHILD SA Rekey Support
During Child SA (Security Association) rekeying, there exists momentarily (500ms or less) two Child SAs. This is to make sure that transient packets for the old Child SA are still processed and not dropped.
PDIF-initiated rekeying is disabled by default. This is the recommended setting, although rekeying can be enabled through the Crypto Configuration Payload mode commands. By default, rekey request messages from the MS are ignored.
 
Denial of Service (DoS) Protection: “Cookie Challenge”
There are several known Denial of Service (DoS) attacks associated with IKEv2. Through a configurable option in the Config Crypto-Template mode, the PDIF can implement the IKEv2 “cookie challenge” payload method as described in [RFC 4306]. This is intended to protect against the PDIF creating too many half-opened sessions or other similar mechanisms. The default is not enabled. If the IKEv2 cookie feature is enabled, when the number of half-opened IPSec sessions exceeds the reasonable limit (or the trigger point with other detection mechanisms), the PDIF invokes the cookie challenge payload mechanism to insure that only legitimate subscribers are initiating the IKEv2 tunnel request, and not a spoofed attack.
 
If the IKEv2 cookie feature is enabled, and the number of half-opened IPSec sessions exceeds the configured limit of any integer between 0 and 100,000, the call setup is as shown in the figure below.
 
DoS Cookie-Challenge-Enabled IKEv2 Message Exchange
DoS Cookie Challenge Enabled IKEv2 Message Exchange
 
Cookie Challenge Statistics
Cookie challenge statistics appear in the outputs for the following commands:
 
 
show crypto managers summary ikev2-stats: Shows the total number of invalid cookies per manager instance.
show crypto managers summary npu-stats: Shows NPU statistics on each IPSec manager.
show crypto statistics: Shows the combined data statistics for the given context name. Includes the number of cookie flows, the number of cookie flow packets, and the total number of cookie errors.
show crypto statistics ikev2: Shows the control statistics for a given context name. Includes the output for show crypto statistics, plus Total IKEv2 Cookie Statistics, Cookie Notify Sent, Cookie Notify Received, Cookie Notify Match, Cookie Notify NOT Match, and Invalid Notify Payload Cookie.
 
MAC Address Validation
The MS embeds the MAC address from the WiFi AP in the NAI when it sends an IKEv2 AUTH request. If MAC address validation is enabled on the PDIF, it sends a Diameter User-Data-Request (UDR) message to the HSS with the NAI from the MS. The HSS returns a User-Data-Answer (UDA) message to the PDIF containing a list of authorized MAC addresses.
If the PDIF finds the MAC address in this list, the MAC address validation succeeds, and the PDIF continues with the IKEv2 call. The MS starts EAP authentication through IKEv2 AUTH procedures. If configured to do so, the PDIF removes the MAC address from the NAI when sending authentication requests to external RADIUS servers. If the embedded MAC address is not removed, the authentication check fails, because the AAA server cannot accommodate embedded MAC addresses.
If the MAC address is not in the list, the MAC address authorization fails, and the IKEv2 session is terminated with a Notify Message Type 16382 - Private User Errors message.
If the HSS interface is not reachable, it is possible that the IKEv2 session setup could continue as if the MAC authorization had succeeded. However, such error behaviors, including various Diameter error codes from the HSS, are configuration options. That means if an HSS returns an error, the action could be either to continue or to terminate the session. This is discussed in Diameter Failure Handling.
Important: See also Diameter Authentication Failure-Handling in the Command Line Interface Reference.
 
RADIUS Accounting
RADIUS Accounting messages are not generated while mobile IP setup is in progress.
 
 
There is no session dormancy in the PDIF. Once the session is active, the session never goes to a dormant state.
Important: RADIUS attributes and customizable dictionary types are described in the AAA Interface Administration and Reference. For the impact of attributes in Request and Reply messages, see also Mobile IP Native Simple IP Call Minimum Requirements. There is additional attribute information in the Session Termination section in Troubleshooting.
 
Special RADIUS Attribute Handling
Certain attributes require special handling on the PDIF with the attribute values either controlled by a RADIUS dictionary entry or a PDIF-service configurable. No configuration has no behavioral effect.
 
 
3GPP2-Serving-PCF. The generation of each new custom dictionary requires a new PDIF image. Configured in the pdif-service mode, the command aaa attribute 3gpp2-serving-pcf <ip-address> specifies the required values for the attribute without building a new software image. If configured, this attribute is sent in RADIUS accounting messages.
The following attributes are in custom dictionaries but have a customer-requested component.
 
Mobile IP and Proxy Mobile IP Attributes
 
Important: The SN-Proxy-MIP attribute is required when PDIF supports proxy mobile IP. The PDIF-Mobile-IP-Required attribute is SN1-PDIF-MIP-Required. These attributes need to be returned in a AAA response message or the mobile IP call fails, although there might be an option for simple IP call setup. See the Sample Deployments section for more information on attribute messaging.
 
IPv6 Support
This section describes the level of IPv6 support. All known restrictions are shown in Engineering Restrictions. Configuration examples are shown in Configuration.
Native IPv6 supports configuration of interfaces and routes with IPv6 (128-bit) addressing. PDIF supports IPv6 for communication with Diameter servers over SCTP. Using the Diameter proxy mechanism, each PSC needs a unique IPv6 address. Multiple IPv6 interfaces per context are supported.
Native IPv6 interfaces communicate with the Diameter servers. PDIF supports the configuration of 32 IPv6 Ethernet interfaces and 32 IPv6 loopback interfaces per context:
 
 
IPv6 Neighbor Discovery
IPv6 Neighbor Discovery protocol is used to dynamically discover the directly attached devices on IPv6 interfaces. It facilitates the mapping of MAC addresses to IPv6 Addresses. PDIF supports a subset of IPv6 Neighbor Discovery as defined by [RFC 2461] as follows:
 
 
IPv6 Static Routing
Native IPv6 routing allows the forwarding of IPv6 packets between IPv6 networks. The forwarding lookup is based on destination IPv6 address longest prefix match.
PDIF supports configuration of static routes including a default route. If a default route is configured, all IPv6 traffic is forwarded to the configured next-hop defined by the default route.
 
Port-Switch-On-L3-Fail for IPv6
IPv4 port failover redundancy if L3 connectivity is lost is extended to support IPv6 addresses.
For more information on configuring port-switch-on-l3-fail, see Ethernet Interface Configuration Commands in the Command Line Interface Reference and Creating and Configuring Ethernet Interfaces and Ports in the System Element Configuration Procedures section of the System Administration Guide.
 
IKEv2 Keep-Alive (Dead Peer Detection (DPD))
PDIF supports DPD protocol messages originating from both the MS and the PDIF/FA. DPD is configured on a per-PDIF-service basis. The administrator can also disable DPD and the PDIF/FA does not initiate DPD exchanges with the MS when disabled. However, the PDIF/FA always responds to DPD availability checks initiated by the MS regardless of the PDIF/FA idle timer configuration.
Important: For a number of failure scenarios involving Dead Peer Detection, refer to the Troubleshooting chapter.
 
Congestion Control and Overload Disconnect
Congestion control is an operator-configurable facility. When the PDIF chassis reaches certain limits (based on CPU utilization, port utilization, and other controls) the system enters a congested state. When in a congested state, existing calls are not impacted but new calls are potentially restricted.There is a separate subscriber-level configuration to enable/disable the feature on a per-subscriber basis. There is also a subscriber-level configurable for inactivity-time and connect-time thresholds to remove some old and abandoned calls from the system.
The disconnection scenario is as follows:
If only idle-time-threshold is configured, sessions exceeding this threshold would be selected for disconnection.
If only connect-time-threshold is configured, sessions exceeding this threshold would be selected for disconnection.
If both idle-time-threshold and connect-time-threshold are configured, sessions with an idle-time greater than the idle-time threshold and a connect-time greater than the connect-time-threshold would be selected for disconnection.
If neither idle-time-threshold nor connect-time-threshold is configured, sessions are sorted based on the idle-timer, and sessions with a longer idle-timer are deleted first.
 
SCTP (Stream Control Transmission Protocol) Support
PDIF provides support for SCTP (Stream Control Transmission Protocol) for use in communicating with Diameter peers over IPv6.
Diameter/SCTP connections are set up for administratively enabled Diameter peers whenever the system configuration is loaded. In the event of certain card or task-level failures, SCTP connections are torn down and re-established (but note that the Diameter state will still be maintained).
SCTP complies with the description in [RFC 2960 Section 5.1.1] for how to handle the case where the peer is incapable of supporting all of the outbound streams that the endpoint wants to configure. Specifically, PDIF does not abort the session but instead adjusts the association's number of outbound streams to match the number of inbound streams advertised by the peer (in the event that the number sent is less).
 
X.509 Digital Trusted Certificate Support
A digital certificate is an electronic credit card that establishes one's credentials when doing business or other transactions on the Web. Some digital certificates conform to ITU-T standard X.509 for a Public Key Infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, among other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.
 
The PDIF generates an SNMP notification when the certificate is within 30 days of expiration and approximately once a day until a new certificate is provided. The operator needs to generate a new certificate and then configure the new certificate using the CLI. The certificate is then used for all new sessions.
Important: For more configuration information, refer to Global Configuration in the Command Line Interface Reference.
 
Custom DNS Handling
By default, the PDIF always returns a DNS address in the CP payload if one is received from the configuration or the HA. A new CLI has been added defining an alternate series of supported behaviors depending on the number of INTERNAL_IP4_DNS. These include, but are not limited to, the following:
 
Important: For more information including full definitions for each of the trigger behaviors, see Configuring Crypto Template in Configuration, and also see the Command Line Interface Reference.
 
Features and Functionality - Licensed Enhanced Feature Support
This section covers any feature not covered by the base PDIF software and is licensed either separately or in a customized bundle of feature licenses.
Important: For detailed information on obtaining and installing licenses, refer to the Managing License Keys section of Software Management Operations in the System Administration Guide.
This section describes the following features:
 
 
PDIF Service
The PDIF service and the processes associated with it define the PDIF itself. The PDIF service enables mobile stations to interface with the PDIF.
The PDIF service configuration includes the following:
The IPv4 address for the service: This is the PDIF IP address to which the MS tries to connect. The MS sends IKEv2 messages to this IP address and this address must be a valid address in the context. PDIF service will not be up and running if this IP address is not configured.
The name of the crypto template for IKEv2: A crypto template is used to configure an IKEv2 PDIF IPSec policy. It includes most of the IPSec parameters and IKEv2 parameters for keep-alive, lifetime, NAT-T and cryptographic and authentication algorithms. There must be one crypto template per PDIF service. The PDIF service will not be up and running without a crypto-template configuration.
The EAP profile name: This profile defines the EAP authentication methods.
Multiple authentication support: The multiple authentication configuration is a part of the crypto template.
IKEv2 and IPSec transform sets: These define the negotiable algorithms for IKE SA and CHILD SA setup to connect calls to the PDIF/FA.
Configure the setup timeout value: The MS connection attempt is terminated if the MS does not establish a successful connection within the configured value.
Mobile IP foreign agent context and foreign agent service: This defines the system context where mobile IP foreign agent functionalities are configured.
Max-sessions: The maximum number of subscriber sessions allowed by this PDIF service.
PDIF supports a domain template for storing domain related configuration: The domain name is taken from the received NAI and searched in the domain template database.
3GPP2 serving PCF address: This configurable specifies what value in the RADIUS attribute when sending authentication and accounting messages.
Duplicate session detection parameters: PDIF supports either NAI (first phase authentication) or IMSI to be used for duplicate session detection. This configuration specifies whether duplicate session detection is based on IMSI or NAI. The default is NAI.
When the PDIF service is configured in the system with the IP address, crypto template, etc., the PDIF is ready to accept IKEv2 control packets for establishing IKEv2 PDIF sessions.
There is a limit to the number of CHILD SAs supported by each PDIF service. Traditionally, other Cisco services limit this to the number of subscriber sessions. The PDIF treats this as the number of CHILD SAs. This means that if each subscriber establishes only a single CHILD SA, the limit will be equal to the number of subscriber sessions. During CHILD SA rekeying, for a small duration of time, there are two CHILD SAs in the system. This is to make sure that transient packets for the old CHILD SA are still processed (not dropped).
 
Multiple PDIF Services
The PDIF supports multiple PDIF services running simultaneously on the same ASR 5000. This feature enables operators to configure PDIF services with different crypto templates to support multiple subscriber handsets and to set per-service maximum session limits. The total number of sessions for all PDIF services running simultaneously on the same ASR 5000 must fall under the PDIF session counting license limit.
 
Lawful Intercept
The PDIF supports the Lawful Interception (LI) of subscriber session information. This functionality provides Telecommunication Service Providers (TSPs) with a mechanism to assist Law Enforcement Agencies (LEAs) in the monitoring of suspicious individuals (referred to as targets) for potential criminal activity.
The following standards were referenced:
LEAs provide one or more TSPs with court orders or warrants requesting the monitoring of a particular target. The target is identified by information such as their Mobile Station Integrated Services Digital Network (MSISDN) number, or their International Mobile Subscriber Identification (IMSI) number.
Once the target has been identified, the system, functioning as either a GGSN or HA, serves as an Access Function (AF) and performs monitoring for both new PDP contexts or PDP contexts that are already in progress. While monitoring, the system intercepts and duplicates Content of Communication (CC) and/or Intercept Related Information (IRI) and forwards it to a Delivery Function (DF) over an extensible, proprietary interface. Note that when a target establishes multiple, simultaneous PDP contexts, the system intercepts CC and IRI for each of them. The DF, in turn, delivers the intercepted content to one or more Collection Functions (CFs).
 
Diameter Authentication Failure Handling
Diameter EAP failure handling defines error handling for both Session Termination Requests and for EAP Requests.
Specific actions (continue, retry-and-terminate, or terminate) can be associated with each possible result-code. EAP failure handling is flexible enough that wide ranges of result codes can be defined with the same action, or actions can be bound on a per-result-code basis.
A failure does not necessarily mean a summary termination of a call.
The following configuration:
diameter authentication <failure-handling> session-termination-request
diameter result-code 5001-5005 action continue
configures result codes 5001, 5002, 5004 and 5005 to mean the session could continue regardless of the error,
and
diameter authentication <failure-handling> session-termination-request
diameter result-code 5003 action terminate
configures result code 5003 to mean terminate the session immediately.
In this scenario, the PDIF receives the DEA from an HSS with the failure code 5003 to terminate the IKE setup for the session. The PDIF sends the IKE_AUTH Response containing a Notify Payload with the type as AUTH_FAILED plus the EAP payload if one was received in the DEA.
When the PDIF received the last DEA message with AVPs that are not in the dictionary, and with the M-bit set to 1, the PDIF disconnects the session.
Important: Refer to Configuring Diameter Authentication Failure Handling in the AAA Interface Administration and Reference and the Command Line Interface Reference for more information.
 
Online Upgrade
The customer has the benefits of upgrading software from a fully redundant device without the expense of maintaining a fully loaded, fully redundant ASR 5000 in a permanent state of standby.
The PDIF supports online software upgrades with a single software version difference between two chassis. For example, upgrading from Release 8.1 to 8.2 is supported. Support for a chassis running greater differences in software versions would be qualified by Cisco on an as-needed basis.
Important: Refer to the Maintenance chapter in this guide for information on how to perform the upgrade.
The online upgrade process calls for a spare ASR 5000 to temporarily perform the services currently being provided by a live networked chassis and upgrade the software with minimal service interruption. This model is called Active-Standby, as one chassis is designated as active and the other as standby. The standby chassis does not handle any new, incoming sessions because the DNS allocating new sessions does not know about the backup chassis. The backup is only required to handle sessions that were already on the primary chassis when it was administratively disconnected from the DNS server. Except for the data loss during the brief chassis switch-over, the session information (accounting and timers) are synchronized so that they are accurate when the backup becomes the active PDIF.
Important: Online upgrade requires miscellaneous internal processing that may result in intensive CPU utilization. Up to 50% CPU utilization overhead should be expected during the upgrade.
 
The Active-Standby Upgrade Model
 
The Active-Standby model is shown below:
 
Active-Standby Online Upgrade Model
The active and standby chassis are connected by an SRP redundancy link to monitor and control the chassis state. Both active and standby chassis have SRP-activated resources defined. Resources could mean loopback interfaces, broadcast interfaces, or IP pools, depending on the installation. For this example, use loopback interfaces.
These resources are the same between the active and standby PDIF. Loopback IP addresses in ingress and egress contexts, and IP pools in egress contexts, are usually SRP-activated resources. The result is that only the currently active chassis enables the SRP-activated resources. The activate command is srp-activate.
Important: Ingress and egress contexts could be the same context. The SRP context must be a separate context.
In the network diagram below, each ingress context has loopback interface A defined, which is SRP-activated. PDIF service A is bound to this interface. The standby chassis has the same interface and PDIF service defined. Both interface and service can only be enabled on the active chassis. Similarly, interface B is defined in the egress context, which can be activated only in the active chassis.
When the active chassis switches over, the standby chassis becomes active and enables all SRP-activated IP interfaces and IP pools so that it can function as a mirror image of the former primary PDIF.
 
Loopback Interface Configuration
 
Operation Over a Common IPv4 Network
The PDIF supports L2 switching to enable carriers not using dynamic routing between the core nodes to perform an online upgrade.
In the example below, the SRP virtual MAC address is configured for the SRP-activated loopback address for the subnet. This allows the standby chassis to seamlessly assume the active role in the network after a switchover. Attached devices continue to send to the same SRP virtual MAC address and the currently active chassis responds to ARP requests for the shared loopback IP address. This scheme allows fast standby-to-active transitions, since the SRP virtual MAC address does not change during the switchover.
When the ASR 5000 transitions from backup to primary, the PDIF sends Gratuitous ARPs to update the port-MAC table of the adjacent switch.
 
Switchover Example for Common IPv4 Subnet
 
Operation Over a Common IPv6 Network
For AAA context with Diameter/SCTP/IPv6 configuration, multiple loopback IPv6 addresses are configured as Diameter endpoints. The customer can SRP-activate these loopback addresses and, upon SRP switchover, the HSS/SLF still sees the same Diameter peer endpoint. No new Diameter peer configuration to the HSS/SLF is required.
With SRP switchover operation in effect, the PDIF shuts down all the SCTP connections to the HSS/SLF. Then the former backup PDIF immediately creates new SCTP connections with the HSS/SLF. In this reestablishment process, the backup chassis sends an Unsolicited Neighbor Advertisement message to the adjacent switch, which is then used to overwrite its port MAC address table as shown in the diagram below.
 
 
Switchover Example for a Common IPv6 Subnet
 
Other Devices
The following table summarizes how other network devices see two ASR 5000s chassis during online upgrade. The table below assumes that a SRP-activated loopback address is configured in the source (toward the MS), the destination (toward the HA), and the AAA contexts (Diameter and RADIUS).
The Chassis as seen from Other Network Devices During Upgrade
 
Session Recovery Support
The session recovery feature provides seamless failover and almost instantaneous reconstruction of subscriber session information in the event of a hardware or software fault within the same chassis, preventing a fully connected user session from being dropped.
Session recovery is performed by mirroring key software processes (the session manager and the AAA manager, for example) within a single PDIF. These mirrored processes remain in an idle state (in standby mode), wherein they perform no processing, until they may be needed in the case of a software failure (a session manager task aborts, for example). The system spawns new instances of standby mode sessions and AAA managers for each active Control Processor (CP) being used.
Additionally, other key system-level software tasks such as VPN manager are performed on a physically separate Packet Services Card (PSC/PSC2) to ensure that a double software fault (the session manager and the VPN manager fail at same time on same card, for example) cannot occur. The PSC used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.
The additional hardware resources required for session recovery include a standby System Management Card (SMC) and a standby PSC.
There are two modes for session recovery.
Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby PSC. In this mode, recovery is performed by using the mirrored standby-mode session manager tasks running on active PSCs. The standby-mode task is renamed, made active, and is then populated using information from other tasks such as AAA manager.
Full PSC recovery mode: Used when a PSC hardware failure occurs, or when a PSC migration failure happens. In this mode, the standby PSC is made active and the standby-mode session manager and AAA manager tasks on the newly-activated PSC perform session recovery.
Session/call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. To ensure task recovery, these pairs are started on physically different PSCs.
Important: For more information on session recovery support, refer to Session Recovery in the System Enhanced Feature Configuration Guide.
 
IPSec/IKEv2
IKEv2 and IPSec transform sets configured in the crypto template define the negotiable algorithms for IKE SA and CHILD SA setup to connect calls to the PDIF/FA by creating two secure tunnels. The first, called the Tunnel Inner Address (TIA) is for signaling traffic, but in some cases it can be used for user traffic which can then use the TIA IP address. The second IPSec SA connects the MS to an HA for a mobile IP call.
Refer to Sample Deployments for a full description of how a variety of calls are successfullyset up (and torn down) in a variety of network scenarios.
At the beginning of IKEv2 session setup, the PDIF and MS exchange capability for multiple authentication. Multiple authentication is configured in the crypto template of the PDIF service. When multiple authentication is enabled in the PDIF service, the PDIF will include MULTIPLE_AUTH_SUPPORTED Notify payload in the initial IKEv2 setup response.
The MS first sends an NAI for the device authentication, in which EAP-AKA is used. After the successful EAP-AKA transaction between the MS and the HSS, the HSS is expected to return the IMSI number for this subscriber. The PDIF uses the authorized IMSI number for session management.
Once the device authentication is successful, the MS notifies the PDIF of its intention to continue subscriber authentication only if the PDIF indicates it has multiple authentication support during the initial IKEv2 exchanges. The MS sends the second NAI that may be different from the first one used during the device authentication. The subscriber authentication is completed either using EAP-MD5 or EAP-GTC. Upon successful authentication, the PDIF continues proxy MIP registration before granting its access to the network.
Even if the PDIF sends the MULTIPLE_AUTH_SUPPORTED capability in the initial IKEv2 setup response, the MS may not support multiple authentication and hence may not include MULTIPLE_AUTH_SUPPORTED Notify payload in the subsequent IKEv2 AUTH exchange. In this case, the MS may only go through the first authentication (which is EAP-AKA authentication). After EAP-AKA authentication, if proxy-mip-required is configured for the session (either through the domain or the default subscriber or the corresponding Diameter AVP), the PDIF will establish a proxy mobile IP session with the HA. The assigned IP address is normally done by the HA and the PDIF receives this address through proxy mobile IP RRP. The PDIF will pass this address back to the MS through the final IKE_AUTH exchange. On the other hand, if proxy-mip-required configuration is not present or disabled, then the PDIF will continue the simple IP session setup by allocating the IP address for the MS from the locally configured pool.
When the MS sends MULTI_AUTH_SUPPORTED Notify payload in subsequent IKE_ AUTH exchanges, the PDIF knows the MS wants to do the second authentication. After the first successful EAP-AKA authentication, the MS will indicate to the PDIF regarding the second authentication (through ANOTHER_AUTH_FOLLOWS Notify payload in the final IKEv2 AUTH request). Please note that the IP address of the MS will not be assigned during the first authentication if the second authentication is to happen. The MS will then initiate the second authentication IKEv2 exchanges. In some networks, this second authentication uses the RADIUS AAA interface. The proxy-mip-required attribute will normally be present in the subscriber profile (or in the domain or default subscriber template) through a RADIUS attribute in the Access Accept message. After successful authentication, if proxy-mip-required is enabled, the PDIF will setup a proxy mobile IP session with the HA, and the HA assigns an IP address to the MS. If proxy-mip-required is disabled (or not present in the subscriber/domain profile), the PDIF establishes a simple IP session and routes traffic using the direct IP interface.
 
Simple IP Fallback
Network operators with handsets that are mobile IP capable may want the MS to be connected to the network and capable of doing data transfer even though the mobile IP registration process might fail under certain situations. If the mobile IP registration failures are due to HA reachability issues or any authentication problems, the MS should still be able to connect to the network using a simple IP connection, assuming that simple IP fallback is enabled in the PDIF configuration. See Simple IP and Simple IP Fallback in this chapter for a full description of this type of network configuration.
 
Simple IP
Simple IP is a solution for network providers whose subscribers fall primarily within a limited set of requirements. It provides the following:
 
 
Proxy Mobile IP
Proxy mobile IP has the following benefits:
 
Proxy mobile IP is configured through the proxy-mip-required configuration, or the corresponding Diameter AVP or RADIUS Access Accept messages. If neither are present, the PDIF establishes a simple IP session and the PDIF routes the call to the Internet or corporate network.
Proxy mobile IP provides a mobility solution for subscribers whose mobile nodes do not support mobile IP protocol. The PDIF sets up the mobile IP tunnel with the HA and the PDIF proxies or acts on behalf of the handset as if it were the handset. The subscriber receives an IP address from either the service provider or from their home network. As the subscriber roams through the network as if it were using a full mobile IP connection, the IP address is maintained providing the subscriber with the opportunity to use IP applications that require seamless mobility such as transferring files.
Important: Refer to Proxy Mobile-IP in the System Administration Guide for more information.
 
Multiple Authentication in a Proxy Mobile IP Network
Multiple authentication requires authenticating both the device and the subscriber.
 
At the beginning of the IKEv2 session setup, the PDIF and the MS exchange capability for multiple authentication. Multiple authentication is configured in the PDIF service as part of the crypto template where it is associated with an EAP profile. The EAP profile defines the authentication mode and method. If multiple authentication is enabled in the crypto template, the PDIF includes a MULTIPLE_AUTH_SUPPORTED Notify payload in the initial IKEv2 setup response.
Important: Even if the PDIF confirms MULTIPLE_AUTH_SUPPORTED capability in the initial IKEv2 setup response, the MS may not support multiple authentication and hence may not include a MULTIPLE_AUTH_SUPPORTED Notify payload in the subsequent IKEv2 AUTH exchange. In this case, the MS may only go through the first-phase (EAP-AKA) of device authentication.
During initial IKEv2/IPSec security setup exchanges, the MS undergoes both device authentication and subscriber authentication. This is because even if the device is fully authenticated, a PDIF may not be able to tell which service profile is applicable for the MS, nor the correct IP address to assign.
Important: First-phase authentication refers to device authentication, and second-phase authentication refers to subscriber authentication.
 
AAA Group Selection
A maximum of 64 AAA groups is allowed on the ASR 5000. This could be spread across multiple contexts or all groups can be configured within a single VPN context.
A maximum of 320 RADIUS servers is allowed on the chassis.
When the aaa-large-configuration command is issued, this number becomes 800 AAA groups and 1600 RADIUS servers configured within the chassis.
The PDIF service allows you to specify a different AAA group for each authentication phase. A given AAA group supports either Diameter or RADIUS authentication, but not both. In deployments where the NAI used in the first-phase authentication is different from the NAI used in the second-phase authentication, each NAI can point to different domain profiles in the PDIF.
 
RADIUS Authentication
Please see the document AAA Interface and Administration for information on AAA, RADIUS, and Diameter groups.
The second authentication uses RADIUS for subscriber authentication. The PDIF supports EAP termination mode during the second half of multiple authentication. In this mode, EAP exchange takes place between the MS and the PDIF, and the PDIF takes the information exchanged in the EAP payload over IKEv2 into RADIUS attributes to support CHAP/PAP authentication with the RADIUS server, and vice versa.
By default, the PDIF initiates EAP-MD5 authentication and sends an EAP payload with an MD5-Challenge to the MS. The MS returns an MD5-Challenge response in the EAP payload. Upon receipt, the PDIF sends an RADIUS Access Request message which includes an NAI, a CHAP-Password, a CHAP-challenge (derived from the EAP payload), and an IMSI number (which is the calling station ID). Once the AAA server returns an Access-Accept message, optional attributes such as Framed-IP-Address and HA address are expected for the subsequent session setup processing. The PDIF translates this Access-Accept message into an EAP Success message, and returns this in an IKE_AUTH Response message.
It is possible that some MSs may not support CHAP authentication. In this case, the MS is expected to return the EAP payload with a legacy-Nak message when the PDIF sends an MD5-Challenge message. Upon receipt of the legacy-Nak message, the PDIF initiates an EAP-GTC procedure. When the MS returns EAP-GTC including its own password, the PDIF sends a RADIUS Access Request message which includes an NAI, a password, and an IMSI number. Once the AAA server returns an Access-Accept message, attributes such as Framed-IP-Address and HA address are expected for the subsequent session setup processing. The PDIF translates the Access-Accept message as EAP success, and returns this in an IKE_AUTH Response message.
If EAP-GTC is configured, then the EAP-GTC method is used instead of the EAP-MD5 method.
The PDIF does the following for IKEv2 and RADIUS authentication:
The PDIF terminates EAP-MD5/GTC authentication. The PDIF understands the values in the EAP payload, and maps them as RADIUS attributes for CHAP/PAP authentication.
Upon request from the MS, the PDIF performs EAP-GTC authentication instead of EAP-MD5.
Each domain profile may be configured with two AAA groups, one for Diameter and the other for RADIUS.
In deployments where both NAI happen to be the same for both authentications, it will point to the same AAA group and thereafter only one protocol (either RADIUS or Diameter) is used.
There are cases where the domain template may not be associated with a given NAI. In such cases, the default AAA groups are used for authentication. Since authentication happens in two phases, and each using Diameter and RADIUS AAA groups respectively, there needs to be two default AAA groups (one for Diameter authentication and one for RADIUS authentication) for multiple authentication. The default AAA groups are configured in the PDIF service.
 
First-Phase Authentication
During first-phase authentication, the HSS authenticates the device. The MS first sends an NAI for device authentication. After the successful EAP-AKA transaction between the MS and the HSS, the HSS is expected to return an IMSI number for this subscriber. The PDIF takes this authorized IMSI number for session management.
This authentication method uses EAP between the MS and the AAA server, and the PDIF acts as a pass-through agent.
Important: First-phase authentication must use the EAP-AKA method.
Depending on the number of HSSs in the network, it is possible that a Subscription Locator Function (SLF) would be introduced into the network as a Diameter proxy or relay agent. If deployed, the SLF would be the first point of contact for the PDIF.
The protocol stack between the PDIF and the HSS/SLF is Diameter over SCTP over IPv6.
 
Second-Phase Authentication
Second-phase authentication uses EAP-MD5 or EAP-GTC authentication with IKEv2 using a legacy RADIUS server, which does not understand or implement EAP. This could be the same AAA server as those deployed in any existing EV-DO network. In this case, EAP authentication happens between the MS and the PDIF.
The protocol stack between the PDIF and the AAA server is RADIUS over UDP over IPv4.
The two algorithms for second-phase authentication are EAP-MD5 (which is the same as CHAP authentication) and EAP-GTC (which is the same as PAP authentication). When the MS sends the NAI to identify the subscriber, the PDIF initiates the EAP-Request with a challenge. Once the MS returns the challenge response, the PDIF maps it to a RADIUS ACCESS_REQUEST message to complete CHAP authentication. There is an internal mechanism to inform each peer if one method is not supported and to renegotiate to use the other supported method.
In general, session attributes during first-phase authentication are overwritten by those from second-phase authentication, unless specified separately. Exceptions to this include session-timeout and idle-timeout, when the lower values are taken.
 
Termination
During session setup, if there are any configuration mismatches or the PDIF cannot get the required information, the session setup process is terminated and appropriate log messages are generated.
If multiple-auth-supported is not enabled on the PDIF, and the MS still sends a MULTIPLE_AUTH_SUPPORTED Notify payload marked with the critical bit set, the PDIF returns UNSUPPORTED_PAYLOAD. Otherwise, the PDIF ignores it and processes the IKE packet as if the payload was never received. This is non-standard MS behavior.
Important: The multiple authentication process in a proxy mobile IP network is described in Proxy-MIP in the System Enhanced Features Guide.
 
Session Recovery
The session recovery feature provides reconstruction of subscriber session information in the event of a hardware or software fault within the system, providing seamless failover andpreventing a fully connected user session from being dropped.
 
In addition to maintaining call state information, information is retained in order to:
 
Recovery requires a complex interaction between IPSec and session subsystems. The IPSec subsystem also interacts with a Datapath that includes daughter cards, daughter card managers, and the NPU. The session recovery feature is disabled by default on the system, even when the feature use key is present.
The IPSec controller does not send an IPSec manager death notification to any subsystem. This allows the daughter card to continue to receive and decrypt IPSec tunnel data. It also allows both the session manager and daughter card to continue carrying subscriber traffic using NPU flows and IPSec SAs to transmit the data.
A session manager is created on a PSC and a corresponding AAA manager is created on a different PSC but is created with the same instance number. A session manager saves (check-points) its Call Recovery Record (CRR) on the AAA manager with an instance ID the same as its own. This pairs up the session manager and the AAA manager and at the same time guarantees session recovery in the event of a single PSC failure.
IPSec manager is also created on a PSC. When a PDIF call request arrives, the IPSec manager picks a session manager for this particular call using a demux library on the same PSC. This means the IPSec manager is associated with the session managers on the PSC.
The session subsystem continues to use the AAA manager as its storage system for the PDIF because AAA needs to provide other subscriber-related information to the session manager. Now that the session manager and the IPSec manager are paired on the same PSC, the IPSec manager is assured of data recovery in case of PSC failure. This is because the session manager saves its data on the AAA manager on a backup PSC.
Important: For more information, refer to the PDIF Session Recovery chapter in the System Enhanced Features Configuration Guide.
 
Intelligent Packet Monitoring System (IPMS)
The IPMS provides a control-packet capture, database, and query facility. It provides the functions to assist operators to analyze and investigate call-related events at a later time.
Important: IPMS is described in the IPMS System Administration Guide.
 
Multiple Traffic Selectors
The PDIF can be configured with multiple IPSec traffic classes, each containing up to 128 traffic selectors, which are used during traffic selector negotiation with UEs. Multiple traffic selectors allow the PDIF to direct outbound traffic to selected IP addresses based on the following protocols: IP, TCP, UDP, and ICMP. The PDIF can also direct TCP and UDP traffic to selected IP addresses and port ranges.
Important: In this software release, the PDIF supports IPv4 traffic selectors only.
Per RFC 4306, when a packet arrives at an IPSec subsystem and matches a 'protect' selector in its Security Policy Database (SPD), the subsystem must protect the packet via IPSec tunneling. Traffic selectors enable an IPSec subsystem to accomplish this by allowing two endpoints to share information from their SPDs. Traffic selectors can be used to assure that both endpoint SPDs are consistent and can aid in the dynamic update of an SPD. Traffic selector payloads contain the selection criteria for packets being sent over IPSec security associations (SAs).
During traffic selector negotiation, each endpoint sends two traffic selector payloads in the messages exchanged during the creation of an IPSec SA. The first traffic selector payload is known as the TSi (Traffic Selector-initiator) and the second is known as the TSr (Traffic Selector-responder). Each traffic selector payload contains one or more traffic selectors, and each traffic selector can contain an IP address range, a port range, and an IP protocol ID. During traffic selector negotiation between the UE and the PDIF, the UE assumes the role of the initiator as it initiates an IPSec SA for its traffic, and the PDIF assumes the role of the responder. The PDIF can use multiple traffic selectors in its role as the responder.
Traffic selectors are applied to calls via an AAA attribute. During call setup, the PDIF's AAA manager selects the traffic class to use for a call based on the Radius vendor-specific attribute (VSA) TrafficSelector-class, which is received from the AAA server. The PDIF's Session Manager passes the selected traffic class configuration from its AAA Manager to its IPSec Manager, which then sends the traffic selectors to the UE in the TSr for all CHILD SAs in the call. If no matching traffic selector classes or traffic selectors have been configured on the PDIF, or if the PDIF does not receive the TrafficSelector-class attribute from the AAA server, or if the value of the received TrafficSelector-class attribute is 0, the PDIF returns the default traffic selector to the UE in the TSr, which allows all inbound traffic.
The PDIF saves the traffic class configuration in each call during call setup. Configuration changes made to the existing traffic class configuration will apply to new calls only. There is no hard limit to the maximum number of allowed traffic classes, but the recommended limit is 50.
When incoming traffic from a UE does not match any of the configured traffic selectors, the PDIF does not reject the traffic. Instead, the PDIF keeps a per-call counter to record the number of packets that do not match the configured traffic selectors. Outgoing traffic from the PDIF to the UE is not subject to traffic selection or checking.
 
Selective Diameter Profile Update Request Control
For mobile IP calls, the Selective Diameter Profile Update Request Control feature allows WiFi data-only sessions to co-exist with VoIP sessions on the PDIF platform.
When the PDIF is accessed by voice-enabled devices, it needs to interact with the HSS in order for a subscriber session to access the IP core network. When the PDIF is accessed by data-only devices, there is no need to interact with the HSS.
This feature is used to identify which subscriber sessions need to have the PDIF and the HSS exchange Diameter Profile Update Request (PUR) and Profile Update Answer (PUA) messages, and allows the PDIF to handle the call setup for a data-only client without having to interact with the HSS.
Selective PUR profiles on the AAA server are mapped to subscribers during AAA authentication via the Radius vendor-specific attribute (VSA) FMC-Type. FMC-Type has these possible values: voice or data. When the AAA server sets the FMC-Type value to voice, the PDIF and the HSS exchange PUR and PUA messages. When the AAA server sets the FMC-Type value to data, the PDIF and the HSS do not exchange PUR and PUA messages.
This feature is enabled by default and requires no configuration.
 
Supported Standards and RFCs
 
3GPP2 References
 
 
 
IETF References
 
 
 
Object Management Group (OMG) Standards
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883