> Monitoring the Service
> This chapter provides information for monitoring service status and performance using the show commands found in the Command Line Interface (CLI). These command have many related keywords that allow them to provide useful information on all aspects of the system ranging from current software configuration through call activity and status.
> The selection of keywords described in this chapter is intended to provided the most useful and in-depth information for monitoring the system. For additional information on these and other show command keywords, refer to the Command Line Interface Reference.
> In addition to the CLI, the system supports the sending of Simple Network Management Protocol (SNMP) traps that indicate status and alarm conditions. Refer to the SNMP MIB Reference Guide for a detailed listing of these traps.
> Monitoring System Status and Performance
> This section contains commands used to monitor the status of tasks, managers, applications and other software components in the system. Output descriptions for most of the commands are located in the Counters and Statistics Reference.

> To do this: | Enter this command:
> View Congestion-Control Information
> View Congestion-Control Statistics
> View Congestion-Control Statistics | show congestion-control statistics { a11mgr | ipsecmgr }
> View Subscriber Information
> Display Session Resource Status
> View session resource status | show resources session
> Display Subscriber Configuration Information
> View locally configured subscriber profile settings (must be in context where subscriber resides) | show subscribers configuration username subscriber_name
> View remotely configured subscriber profile settings | show subscribers aaa-configuration username subscriber_name
> View Subscribers Currently Accessing the System
> View a listing of subscribers currently accessing the system | show subscribers all
> View Statistics for Subscribers using HSGW Services on the System
> View statistics for subscribers using any HSGW service on the system | show subscribers hsgw-only full
> View statistics for subscribers using a specific HSGW service on the system | show subscribers hsgw-service service_name
> View Statistics for Subscribers using MAG Services on the System
> View statistics for subscribers using any MAG service on the system | show subscribers mag-only full
> View statistics for subscribers using a specific MAG service on the system | show subscribers mag-service service_name
> View Session Subsystem and Task Information
> Display Session Subsystem and Task StatisticsRefer to the System Software Task and Subsystem Descriptions appendix in the System Administration Guide for additional information on the Session subsystem and its various manager tasks.
> View AAA Manager statistics | show session subsystem facility aaamgr all
> View AAA Proxy statistics | show session subsystem facility aaaproxy all
> View Session Manager statistics | show session subsystem facility sessmgr all
> View MAG Manager statistics | show session subsystem facility magmgr all
> View Session Recovery Information
> View session recovery status | show session recovery status [ verbose ]
> View Session Disconnect Reasons
> View session disconnect reasons with verbose output | show session disconnect-reasons
> View HSGW Service Information
> View HSGW service statistics | show hsgw-service statistics all
> View MAG Service Information
> View MAG service statistics for a specific service | show mag-service statistics name service_name
> View Robust Header Compression Information
> View RoHC statistics | show rohc statistics
> View QoS/QCI Information
> View RAN Profile ID to QoS Class Index mapping tables | show profile-id-qci-mapping table all
> View QoS Class Index to QoS mapping tables | show qci-qos-mapping table all

> ‌
> Clearing Statistics and Counters
> It may be necessary to periodically clear statistics and counters in order to gather new information. The system provides the ability to clear statistics and counters based on their grouping (PPP, MIPHA, MIPFA, etc.).
> Statistics and counters can be cleared using the CLI clear command. Refer to Command Line Reference for detailed information on using this command.
> Appendix A
> Intelligent Traffic Control
> Before using the procedures in this chapter, it is recommended that you select the configuration example that best meets your service model, and configure the required elements as per that model.
> This chapter covers the following topics:

> • | Overview

> • | How it Works

> • | Configuring Flow-based Traffic Policing

> Overview
> Intelligent Traffic Control (ITC) enables you to configure a set of customizable policy definitions that enforce and manage service level agreements for a subscriber profile, thus enabling you to provide differentiated levels of services for native and roaming subscribers.
> In 3GPP2 service ITC uses a local policy look-up table and permits either static EV-DO Rev 0 or dynamic EV-DO Rev A policy configuration.
> Important: ITC includes the class-map, policy-map and policy-group commands. Currently ITC does not include an external policy server interface.
> ITC provides per-subscriber/per-flow traffic policing to control bandwidth and session quotas. Flow-based traffic policing enables the configuring and enforcing bandwidth limitations on individual subscribers, which can be enforced on a per-flow basis on the downlink and the uplink directions.
> Flow-based traffic policies are used to support various policy functions like Quality of Service (QoS), and bandwidth, and admission control. It provides the management facility to allocate network resources based on defined traffic-flow, QoS, and security policies.
> ITC and EV-DO Rev A in 3GPP2 Networks
> Important: The Ev-Do Rev is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> You can configure your system to support both EV-DO Rev A and ITC. ITC uses flow-based traffic policing to configure and enforce bandwidth limitations per subscriber. Enabling EV-DO Rev A with ITC allows you to control the actual level of bandwidth that is allocated to individual subscriber sessions and the application flows within the sessions.
> For more information on EV-DO Rev A, refer to the Policy-Based Management and EV-DO Rev A chapter. For setting the DSCP parameters to control ITC functionality, refer to the Traffic Policy-Map Configuration Mode Commands chapter in the Command Line Reference.
> Bandwidth Control and Limiting
> Bandwidth control in ITC controls the bandwidth limit, flow action, and charging action for a subscriber, application, and source/destination IP addresses. This is important to help limit bandwidth intensive applications on a network. You can configure ITC to trigger an action to drop, lower-ip-precedence, or allow the flow when the subscriber exceeds the bandwidth usage they have been allotted by their policy.
> Licensing
> The Intelligent Traffic Control is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> How it Works
> ITC enables you to configure traffic policing on a per-subscriber/per-flow basis with the potential to manipulate Differentiated Services Code Points (DSCPs), queue redirection (for example, move traffic to a Best Effort (BE) classification), or drop profile traffic.
> In flow-based traffic policies, policy modules interact with the system through a set of well defined entry points, provide access to a stream of system events, and permit the defined policies to implement functions such as access control decisions, QoS enforcement decisions, etc.
> Traffic policing can be generally defined as
> policy: condition >> action

> • | condition: Specifies the flow-parameters like source-address, destination-address, source-port, destination-port, protocol, etc. for ingress and/or egress packet.

> • | action: Specifies a set of treatments for flow/packet when condition matches. Broadly these actions are based on:

> • | Flow Classification: Each flow is classified separately on the basis of source-address, destination-address, source-port, destination-port, protocol, etc. for ingress and/or egress packet. After classification access-control allowed or denied by the system.

> • | QoS Processing for individual flow and DSCP marking: Flow-based traffic policing is implemented by each flow separately for the traffic-policing algorithm. Each flow has its own bucket (burst-size) along with committed data rate and peak data rate. A Token Bucket Algorithm (a modified trTCM) [RFC2698] is used to implement this flow-based QoS traffic policing feature.

> Refer to the Traffic Policing and Shaping chapter for more information on Token Bucket Algorithm.
> Configuring Flow-based Traffic Policing
> Traffic Policing is configured on a per-subscriber basis for either locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
> Flow-based traffic policy is configured on the system with the following building blocks:

> • | Class Maps: The basic building block of a flow-based traffic policing. It is used to control over the packet classification.

> • | Policy Maps: A more advanced building block for a flow-based traffic policing. It manages admission control based on the Class Maps and the corresponding flow treatment based on QoS traffic-police or QoS DSCP marking.

> • | Policy Group: This is a set of one or more Policy Maps applied to a subscriber. it also resolves the conflict if a flow matches to multiple policies.

> This section provides instructions for configuring traffic policies and assigning to local subscriber profiles on the system.
> For information on how to configure subscriber profiles on a remote RADIUS server, refer to the StarentVSA and StarentVSA1 dictionary descriptions in the AAA and GTP Interface Administration and Reference.
> Important: This section provides the minimum instruction set for configuring flow-based traffic policing on an AGW service. Commands that configure additional properties are provided in the Command Line Interface Reference.
> These instructions assume that you have already configured the system-level configuration as described in product administration guide.
> To configure the flow-based traffic policing on an AGW service:

> 1. | Configure the traffic class maps on the system to support flow-based traffic policing by applying the example configuration in the Configuring Class Maps section.

> 2. | Configure the policy maps with traffic class maps on the system to support flow-based traffic policing by applying the example configuration in the Configuring Configuring Policy Maps section.

> 3. | Configure the policy group with policy maps on the system to support flow-based traffic policing by applying the example configuration in the Configuring Policy Groups section.

> 4. | Associate the subscriber profile with policy group to enable flow-based traffic policing for subscriber by applying the example configuration in the Configuring a Subscriber for Flow-based Traffic Policing section.

> 5. | Verify your flow-based traffic policing configuration by following the steps in the Verifying Flow-based Traffic Policing Configuration section.

> 6. | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Class Maps
> This section describes how to configure Class Maps on the system to support Flow-based Traffic Policing.
> Important: In this mode classification match rules added sequentially with match command to form a Class-Map. To change and/or delete or re-add a particular rule user must delete specific Class-Map and re-define it.
> configure
> context <vpn_context_name> [ -noconfirm ]
> class-map name <class_name> [ match-all | match-any ]
> match src-ip-address <src_ip_address> [ <subnet_mask> ]
> match dst-ip-address <dst_ip_address> [ <subnet_mask> ]
> match source-port-range <initial_port_number> [ to <last_port_number> ]
> match dst-port-range <initial_port_number> [ to <last_port_number> ]
> match protocol [ tcp | udp | gre | ip-in-ip ]
> match ip-tos <service_value>
> match ipsec-spi <index_value>
> match packet-size [ gt | lt ] <size>
> end
> Notes:

> • | <vpn_context_name> is the name of the destination context in which you want to configure the flow-based traffic policing.

> • | <class_name> is the name of the traffic class to map with the flow for the flow-based traffic policing. A maximum of 32 class-maps can be configured in one context.

> • | For description and variable values of these commands and keywords, refer to the Class-Map Configuration Mode Commands chapter of the Command Line Interface Reference.

> Configuring Policy Maps
> This section provides information and instructions for configuring the policy maps on the system to support flow-based traffic policing.
> configure
> context <vpn_context_name>
> policy-map name <policy_name>
> class <class_name>
> type { static | dynamic }
> access-control { allow | discard }
> qos traffic-police committed <bps> peak <bps> burst-size <byte> exceed-action { drop | lower-ip-precedence | allow } violate-action { drop | lower-ip-precedence | allow }
> qos encaps-header dscp-marking [ copy-from-user-datagram | <dscp_code> ]
> end
> Notes:

> • | <vpn_context_name> is the name of the destination context in which is configured during Class-Map configuration for flow-based traffic policing.

> • | <policy_name> is the name of the traffic policy map you want to configure for the flow-based traffic policing. A maximum of 32 policy maps can be configured in one context.

> • | <class_name> is the name of the traffic class to map that you configured in Configuring Class Maps section for the flow-based traffic policing.

> • | For description and variable values of these commands and keywords, refer to the Traffic Policy-Map Configuration Mode Commands chapter of the Command Line Interface Reference.

> Configuring Policy Groups
> This section provides information and instructions for configuring the policy group in a context to support flow-based traffic policing.
> configure
> context <vpn_context_name>
> policy-group name <policy_group>
> policy <policy_map_name> precedence <value>
> end
> Notes:

> • | <vpn_context_name> is the name of the destination context which is configured during Class-Map configuration for flow-based traffic policing.

> • | <policy_group> is name of the traffic policy group of policy maps you want to configure for the flow-based traffic policing. A maximum of 32 policy groups can be configured in one context.

> • | <policy_map_name> is name of the traffic policy you configured in Configuring Policy Maps section for the flow-based traffic policing. A maximum of 16 Policy Maps can be assigned in a Policy Group.

> • | For description and variable values of these commands and keywords, refer to the Traffic Policy-Map Configuration Mode Commands chapter of the Command Line Interface Reference.

> Configuring a Subscriber for Flow-based Traffic Policing
> This section provides information and instructions for configuring the subscriber for Flow-based Traffic Policing.
> configure
> context <vpn_context_name>
> subscriber name <user_name>
> policy-group <policy_group> direction [ in | out ]
> end
> Notes:

> • | <vpn_context_name> is the name of the destination context configured during Class-Map configuration for flow-based traffic policing.

> • | <user_name> is the name of the subscriber profile you want to configure for the flow-based traffic policing.

> • | <policy_group> is name of the traffic policy group you configured in Configuring Policy Groups section for the flow-based traffic policing. A maximum of 16 Policy groups can be assigned to a subscriber profile.

> • | For description and variable values of these commands and keywords, refer to the Traffic Policy-Group Configuration Mode Commands chapter of the Command Line Interface Reference.

> Verifying Flow-based Traffic Policing Configuration

> Step 1 | Verify that your flow-based traffic policing is configured properly by entering the following command in Exec Mode: show subscribers access-flows full

> The output of this command displays flow-based information for a subscriber session.
> Appendix B
> IP Header Compression
> This chapter provides information on configuring an enhanced, or extended, service. The product administration guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product administration guide, before using the procedures in this chapter.
> Important: RoHC header compression is not applicable for SGSN and GGSN services.
> This chapter includes the following procedures:

> • | Configuring VJ Header Compression for PPP

> • | Configuring RoHC Header Compression for PPP

> • | Configuring Both RoHC and VJ Header Compression

> • | Configuring RoHC for Use with SO67 in PDSN or HSGW Service

> • | Using an RoHC Profile for Subscriber Sessions

> • | Disabling VJ Header Compression Over PPP

> • | Disabling RoHC Header Compression Over SO67

> • | Checking IP Header Compression Statistics

> • | RADIUS Attributes for IP Header Compression

> Overview
> The system supports IP header compression on the PPP tunnels established over the EVDO-RevA A10 links and also over the GRE tunnel that is connected to the PCF to support EVDO-RevA Service Option 67 (SO67).
> By default IP header compression using the VJ algorithm is enabled for subscribers using PPP.
> Note that you can use the default VJ header compression algorithm alone, configure the use of RoHC header compression only, or use both VJ and RoHC IP header compression.

> • | Van Jacobsen (VJ) - The RFC 1144 (CTCP) header compression standard was developed by V. Jacobson in 1990. It is commonly known as VJ compression. It describes a basic method for compressing the headers of IPv4/TCP packets to improve performance over low speed serial links.

> • | RObust Header Compression (RoHC) - The RFC 3095 (RoHC) standard was developed in 2001. This standard can compress IP/UDP/RTP headers to just over one byte, even in the presence of severe channel impairments. This compression scheme can also compress IP/UDP and IP/ESP packet flows. RoHC is intended for use in wireless radio network equipment and mobile terminals to decrease header overhead, reduce packet loss, improve interactive response, and increase security over low-speed, noisy wireless links.

> Important: The RoHC is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> In addition, you can configure RoHC profiles that define RoHC Compressor and Decompressor parameters. These RoHC profiles can be applied to subscribers.
> You can also turn off all IP header compression for a subscriber.
> The procedures in this chapter describe how to configure the IP header compression methods used, but for RoHC over PPP the Internet Protocol Control Protocol (IPCP) negotiations determine when they are used.
> Implementing IP header compression provides the following benefits:

> • | Improves interactive response time

> • | Allows the use of small packets for bulk data with good line efficiency

> • | Allows the use of small packets for delay sensitive low data-rate traffic

> • | Decreases header overhead.

> • | Reduces packet loss rate over lossy links.

> Configuring VJ Header Compression for PPP
> By default, VJ IP header compression is enabled for subscriber sessions. When VJ header compression is configured all IP headers are compressed using the VJ compression algorithm.
> Note that procedure described in this section is applicable only when VJ header compression is disabled.
> Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Command Line Interface Reference .
> To configure the system to enable VJ header compression to IP headers:

> Step 1 | Enable VJ header compression by applying the example configuration in the Enabling VJ Header Compression section.

> Step 2 | Verify your VJ header compression configuration by following the steps in the Verifying the VJ Header Compression Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Enabling VJ Header Compression
> Use the following example to enable the VJ header compression over PPP:
> configure
> context <ctxt_name>
> subscriber name <subs_name>
> ip header-compression vj
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.

> • | <subs_name> is the name of the subscriber in the current context that you want to enable VJ IP header compression for.

> Verifying the VJ Header Compression Configuration
> These instructions are used to verify the VJ header compression configuration.

> Step 1 | Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:

> show subscriber configuration username subs_name
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Configuring RoHC Header Compression for PPP
> RoHC IP header compression can be configured for all IP traffic, uplink traffic only, or downlink traffic only. When RoHC is configured for all traffic, you can specify the mode in which RoHC is applied.
> Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in the Command Line Interface Reference.
> To configure the system to enable RoHC header compression to IP headers:

> • | Enable RoHC header compression by applying the example configuration in the Enabling RoHC Header Compression for PPP section.

> • | Verify your RoHC header compression configuration by following the steps in the Verifying the Header Compression Configuration section.

> • | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Enabling RoHC Header Compression for PPP
> Use the following example to enable the RoHC over PPP:
> configure
> context <ctxt_name>
> subscriber name <subs_name>
> ip header-compression RoHC [ any [ mode { optimistic | reliable | unidirectional } ] | cid-mode { { large | small } [ marked-flows-only | max-cid | max-hdr <value> | mrru <value> ] } | marked flows-only | max-hdr <value> | mrru <value> | downlink | uplink ] }+
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.

> • | <subs_name> is the name of the subscriber in the current context that you want to enable RoHC header compression for.

> • | Refer to the Subscriber Configuration Mode Commands chapter in Command Line Interface Reference for more details on this command and its options.

> Verifying the Header Compression Configuration
> These instructions are used to verify the header compression configuration.

> Step 1 | Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:

> show subscriber configuration username subs_name
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Configuring Both RoHC and VJ Header Compression
> You can configure the system to use both VJ and RoHC IP header compression. When both VJ and RoHC are specified, the optimum header compression algorithm for the type of data being transferred is used for data in the downlink direction.
> Important: If both RoHC and VJ header compression are specified, the optimum header compression algorithm for the type of data being transferred is used for data in the downlink direction.
> Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in th Command Line Interface Reference.
> To configure the system to enable both RoHC and VJ header compression to IP headers:

> • | Enable the RoHC and VJ header compression by applying the example configuration in the Enabling RoHC and VJ Header Compression for PPP section.

> • | Verify your RoHC and VJ header compression configuration by following the steps in the Verifying the Header Compression Configuration section.

> • | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Enabling RoHC and VJ Header Compression for PPP
> Use the following example to enable the header compression over PPP:
> configure
> context <ctxt_name>
> subscriber name <subs_name>
> ip header-compression vj RoHC [ any [ mode { optimistic | reliable | unidirectional } ] | cid-mode { { large | small } [ marked-flows-only | max-cid | max-hdr <value> | mrru <value> ] } | marked flows-only | max-hdr <value> | mrru <value> | downlink | uplink ] }+
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.

> • | <subs_name> is the name of the subscriber in the current context that you want to enable RoHC header compression for.

> • | Refer to the Subscriber Configuration Mode Commands chapter in Command Line Interface Reference for more details on this command and its options.

> Verifying the Header Compression Configuration
> These instructions are used to verify the header compression configuration.

> Step 1 | Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:

> show subscriber configuration username subs_name
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Configuring RoHC for Use with SO67 in PDSN or HSGW Service
> This section explains how to set RoHC settings in the PDSN or HSGW Service configuration mode. These settings are transferred to the PCF during the initial A11 setup and are used for the GRE tunnel that is connected to the PCF to support EVDO-RevA Service Option 67 (SO67). RoHC is enabled through an auxiliary SO67 A10 connection and the PCF signals this information when the auxiliary A10 is connected.
> Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer PDSN Service Configuration Mode Commands or HSGW Service Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to enable the RoHC header compression feature at the PDSN or HSGW Service over SO67:

> Step 1 | Enable header compression by applying the example configuration in the Enabling ROHC Header Compression with PDSN or Enabling ROHC Header Compression with HSGW section.

> Step 2 | Verify your RoHC configuration by following the steps in the Verifying the Header Compression Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Enabling RoHC Header Compression with PDSN
> Use the following example to enable the RoHC header compression with PDSN over SO67:
> configure
> context <ctxt_name>
> pdsn-service <svc_name>
> ip header-compression rohc
> cid-mode {large | small} max-cid integer
> mrru <num_octets>
> profile { [esp-ip] [rtp-udp] [udp-ip] [uncompressed-ip] } end
> Notes:

> • | <ctxt_name> is the system context in which PDSN service is configured and you wish to configure the service profile.

> • | <svc_name> is the name of the PDSN service in which you want to enable RoHC over SO67.

> • | Refer to the PDSN Service RoHC Configuration Mode Commands chapter in Command Line Interface Reference for more details on this command and its options.

> Enabling RoHC Header Compression with HSGW
> Use the following example to enable the RoHC header compression with HSGW over SO67:
> configure
> context <ctxt_name>
> hsgw-service <svc_name>
> ip header-compression rohc
> cid-mode {large | small} max-cid integer
> mrru <num_octets>
> profile { [esp-ip] [rtp-udp] [udp-ip] [uncompressed-ip] }
> end
> Notes:

> • | <ctxt_name> is the system context in which HSGW service is configured and you wish to configure the service profile.

> • | <svc_name> is the name of the HSGW service in which you want to enable RoHC over SO67.

> • | Refer to the HSGW Service RoHC Configuration Mode Commands chapter in Command Line Interface Reference for more details on this command and its options.

> Verifying the Header Compression Configuration
> These instructions are used to verify the header compression configuration.

> Step 1 | Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:

> show configuration context ctxt_name
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Using an RoHC Profile for Subscriber Sessions
> You can configure RoHC profiles that specify numerous compressor and decompressor settings. These profiles can in turn be applied to a specific subscriber or the default subscriber. RoHC profiles are used for both RoHC over PPP and for RoHC over SO67.
> Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to apply RoHC profile to a subscriber session:

> Step 1 | Create RoHC profile using decompression mode or decompression mode. If you want to use compression mode go to step a else follow step b:

> Step a | Configure RoHC profile by applying the example configuration in the Creating ROHC Profile for Subscriber using Compression Mode section using compression mode.

> Step b | Alternatively configure RoHC profile by applying the example configuration in the Creating ROHC Profile for Subscriber using Decompression Mode section using compression mode.

> Step 2 | Apply existing RoHC profile to a subscriber by applying the example configuration in the Applying ROHC Profile to a Subscriber section.

> Step 3 | Verify your RoHC header compression configuration by following the steps in the Verifying the Header Compression Configuration section.

> Step 4 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Creating RoHC Profile for Subscriber using Compression Mode
> Use the following example to create RoHC profile for a subscriber using compression mode:
> configure
> RoHC-profile profile-name <RoHC_comp_profile_name>
> decompression-options
> [no] multiple-ts-stride
> rtp-sn-p <p_value>
> [no] use-ipid-override
> [no] use-optimized-talkspurt
> [no] use-optimized-transience
> [no] use-timer-based-compression
> end
> Notes:

> • | <RoHC_comp_profile_name> is the name of the RoHC profile with compression mode which you want to apply to a subscriber.

> • | System configured most of the parameters by default. For more information on other options and parameters and details, refer to the RoHC Profile Compression Configuration Mode Commands chapter in Command Line Interface Reference.

> Creating RoHC Profile for Subscriber using Decompression Mode
> Use the following example to create RoHC profile for a subscriber using decompression mode:
> configure
> RoHC-profile profile-name <RoHC_decomp_profile_name>
> decompression-options
> context-timeout <dur>
> max-jitter-cd <dur_ms>
> nak-limit <limit>
> optimistic-mode-ack
> optimistic-mode-ack-limit <num_pkts>
> piggyback-wait-time <dur_ms>
> preferred-feedback-mode { bidirectional-optimistic | bidirectional-reliable | unidirectional }
> rtp-sn-p <p_value>
> [no] rtp-sn-p-override
> [no] use-clock-option
> [no] use-crc-option
> [no] use-feedback
> [no] use-jitter-option
> [no] use-reject-option
> [no] use-sn-option
> end
> Notes:

> • | <RoHC_profile_name> is the name of the RoHC profile with decompression mode which you want to apply to a subscriber.

> • | System configured most of the parameters by default. For more information on other options and parameters and details, refer to the RoHC Profile Decompression Configuration Mode Commands chapter in Command Line Interface Reference.

> Applying RoHC Profile to a Subscriber
> Once an RoHC profile has been created that profile can be specified to be used for a specific subscribers. Use the following example to apply the RoHC profile to a subscriber:
> configure
> context <ctxt_name>
> subscriber name <subs_name>
> RoHC-profile-name <RoHC_profile_name>
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.

> • | <subs_name> is the name of the subscriber in the current context that you want to enable RoHC header compression for.

> • | <RoHC_profile_name> is the name of the existing RoHC profile (created with compressed or decompressed mode) which you want to apply to a subscriber in the current context.

> • | Refer to the Subscriber Configuration Mode Commands chapter in Command Line Interface Reference for more details on this command and its options.

> Verifying the Header Compression Configuration
> These instructions are used to verify the header compression configuration.

> Step 1 | Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:

> show subscriber configuration username subs_name
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Disabling VJ Header Compression Over PPP
> By default, VJ IP header compression is enabled for subscriber sessions. When VJ header compression is configured all IP headers are compressed using the VJ compression algorithm.
> If you do not want to apply compression to any IP headers for a subscriber session you can disable the IP header compression feature.
> Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to disable VJ header compression to IP headers:

> Step 1 | Disable header compression by appling the example configuration in the Disabling VJ Header Compression section.

> Step 2 | Verify your VJ header compression configuration by following the steps in the Verifying the VJ Header Compression Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Disabling VJ Header Compression
> Use the following example to disable the VJ header compression over PPP:
> configure
> context <ctxt_name>
> subscriber name <subs_name>
> no ip header-compression
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.

> • | <subs_name> is the name of the subscriber in the current context that you want to disable IP header compression for.

> Verifying the VJ Header Compression Configuration
> These instructions are used to verify the VJ header compression configuration.

> Step 1 | Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:

> show subscriber configuration username <subs_name>
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Disabling RoHC Header Compression Over SO67
> If you do not want to apply compression to any IP headers for a subscriber sessions using the EVDO-RevA SO67 feature, you can disable the IP header compression feature at the PDSN or HSGW Service.
> Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer PDSN Service Configuration Mode Commands or HSGW Service Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to disable the IP header compression feature at the PDSN or HSGW Service:

> Step 1 | Disable header compression by applying the example configuration in the Disabling ROHC Header Compression section.

> Step 2 | Verify your RoHC configuration by following the steps in the Verifying the Header Compression Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Disabling RoHC Header Compression
> Use the following example to disable the header compression over SO67:
> configure
> context <ctxt_name>
> pdsn/hsgw-service <svc_name>
> no ip header-compression RoHC
> end
> Notes:

> • | <ctxt_name> is the system context in which PDSN or HSGW service is configured and you wish to configure the service profile.

> • | <svc_name> is the name of the PDSN or HSGW service in which you want to disable RoHC over SO67.

> Verifying the Header Compression Configuration
> These instructions are used to verify the header compression configuration.

> Step 1 | Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:

> show configuration context <ctxt_name>
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Checking IP Header Compression Statistics
> This section commands to use to retrieve statistics that include IP header compression information.
> The following Exec mode commands can be used to retrieve IP header compression statistics:

> • | monitor protocol ppp

> • | show ppp

> • | show ppp statistics

> • | show RoHC statistics

> • | show RoHC statistics pdsn-service

> • | show subscriber full username

> For more information on these commands, refer to the Command Line Interface Reference.
> RADIUS Attributes for IP Header Compression
> This section lists the names of the RADIUS attributes to use for RoHC header compression. For more information on these attributes, refer to the AAA Interface Administration and Reference.
> One of the following attributes can be used to specify the name of the RoHC profile to use for the subscriber session:

> • | SN-RoHC-Profile-Name

> • | SN1-RoHC-Profile-Name

> Any RoHC parameters not specified in the RoHC profile are set to their default values.
> Appendix C
> IP Security
> This chapter provides information on configuring an enhanced or extended service. The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
> Important: The IP Security is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> Caution: IPSec parameter configurations saved using this release may not function properly with older software releases.
> This chapter contains the following sections:

> • | Overview

> • | IPSec Terminology

> • | Implementing IPSec for PDN Access Applications

> • | Implementing IPSec for Mobile IP Applications

> • | Implementing IPSec for L2TP Applications

> • | Transform Set Configuration

> • | ISAKMP Policy Configuration

> • | ISAKMP Crypto Map Configuration

> • | Dynamic Crypto Map Configuration

> • | Manual Crypto Map Configuration

> • | Crypto Map and Interface Association

> • | FA Services Configuration to Support IPSec

> • | HA Service Configuration to Support IPSec

> • | RADIUS Attributes for IPSec-based Mobile IP Applications

> • | LAC Service Configuration to Support IPSec

> • | Subscriber Attributes for L2TP Application IPSec Support

> • | PDSN Service Configuration for L2TP Support

> • | Redundant IPSec Tunnel Fail-Over

> • | Redundant IPSec Tunnel Fail-over Configuration

> • | Dead Peer Detection (DPD) Configuration

> • | APN Template Configuration to Support L2TP

> • | IPSec for LTE/SAE Networks

> Overview
> IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways. IPSec can be implemented on the system for the following applications:

> • | PDN Access: Subscriber IP traffic is routed over an IPSec tunnel from the system to a secure gateway on the packet data network (PDN) as determined by access control list (ACL) criteria. This application can be implemented for both core network service and HA-based systems. The following figure shows IPSec configurations.

> IPSec Applications

> • | Mobile IP: Mobile IP control signals and subscriber data is encapsulated in IPSec tunnels that are established between foreign agents (FAs) and home agents (HAs) over the Pi interfaces.

> Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.

> • | L2TP: L2TP-encapsulated packets are routed from the system to an LNS/secure gateway over an IPSec tunnel.

> Note that: IPSec can be implemented for both attribute-based and compulsory tunneling applications for 3GPP2 services.
> Applicable Products and Relevant Sections
> The IPSec feature is supported for various products. The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.

> Applicable Product(s) | Refer to Sections
> PDSN/FA/HA |
> • | Implementing IPSec for PDN Access Applications
> • | Implementing IPSec for Mobile IP Applications
> • | Transform Set Configuration
> • | ISAKMP Policy Configuration
> • | ISAKMP Crypto Map Configuration
> • | Dynamic Crypto Map Configuration
> • | Manual Crypto Map Configuration
> • | Crypto Map and Interface Association
> • | FA Services Configuration to Support IPSec
> • | HA Service Configuration to Support IPSec
> • | RADIUS Attributes for IPSec-based Mobile IP Applications
> • | LAC Service Configuration to Support IPSec
> • | Subscriber Attributes for L2TP Application IPSec Support
> • | PDSN Service Configuration for L2TP Support
> • | Redundant IPSec Tunnel Fail-Over
> • | Dead Peer Detection (DPD) Configuration
> GGSN/FA/HA |
> • | Implementing IPSec for PDN Access Applications
> • | Implementing IPSec for Mobile IP Applications
> • | Implementing IPSec for L2TP Applications
> • | Transform Set Configuration
> • | ISAKMP Policy Configuration
> • | ISAKMP Crypto Map Configuration
> • | Dynamic Crypto Map Configuration
> • | Manual Crypto Map Configuration
> • | Crypto Map and Interface Association
> • | FA Services Configuration to Support IPSec
> • | HA Service Configuration to Support IPSec
> • | RADIUS Attributes for IPSec-based Mobile IP Applications
> • | LAC Service Configuration to Support IPSec
> • | Redundant IPSec Tunnel Fail-Over
> • | Dead Peer Detection (DPD) Configuration
> • | TAPN Template Configuration to Support L2TP
> ASN GW |
> • | Implementing IPSec for PDN Access Applications
> • | Implementing IPSec for Mobile IP Applications
> • | Implementing IPSec for L2TP Applications
> • | Transform Set Configuration
> • | ISAKMP Policy Configuration
> • | ISAKMP Crypto Map Configuration
> • | Dynamic Crypto Map Configuration
> • | Manual Crypto Map Configuration
> • | Crypto Map and Interface Association
> • | FA Services Configuration to Support IPSec
> • | HA Service Configuration to Support IPSec
> • | RADIUS Attributes for IPSec-based Mobile IP Applications
> • | LAC Service Configuration to Support IPSec
> • | Subscriber Attributes for L2TP Application IPSec Support
> • | Redundant IPSec Tunnel Fail-Over
> • | Dead Peer Detection (DPD) Configuration

> ‌
> IPSec Terminology
> There are four items related to IPSec support on the system that must be understood prior to beginning configuration. They are:

> • | Crypto Access Control List (ACL)

> • | Transform Set

> • | ISAKMP Policy

> • | Crypto Map

> Crypto Access Control List (ACL)
> As described in the IP Access Control Lists chapter of this guide, ACLs on the system define rules, usually permissions, for handling subscriber data packets that meet certain criteria. Crypto ACLs, however, define the criteria that must be met in order for a subscriber data packet to be routed over an IPSec tunnel.
> Unlike other ACLs that are applied to interfaces, contexts, or one or more subscribers, crypto ACLs are matched with crypto maps. In addition, crypto ACLs contain only a single rule while other ACL types can consist of multiple rules.
> Prior to routing, the system examines the properties of each subscriber data packet. If the packet properties match the criteria specified in the crypto ACL, the system will initiate the IPSec policy dictated by the crypto map.
> Transform Set
> Transform Sets are used to define IPSec security associations (SAs). IPSec SAs specify the IPSec protocols to use to protect packets.
> Transform sets are used during Phase 2 of IPSec establishment. In this phase, the system and a peer security gateway negotiate one or more transform sets (IPSec SAs) containing the rules for protecting packets. This negotiation ensures that both peers can properly protect and process the packets.
> ISAKMP Policy
> Internet Security Association Key Management Protocol (ISAKMP) policies are used to define Internet Key Exchange (IKE) SAs. The IKE SAs dictate the shared security parameters (i.e. which encryption parameters to use, how to authenticate the remote peer, etc.) between the system and a peer security gateway.
> During Phase 1 of IPSec establishment, the system and a peer security gateway negotiate IKE SAs. These SAs are used to protect subsequent communications between the peers including the IPSec SA negotiation process.
> Crypto Map
> Crypto Maps define the tunnel policies that determine how IPSec is implemented for subscriber data packets.
> There are three types of crypto maps supported by the system. They are:

> • | Manual crypto maps

> • | ISAKMP crypto maps

> • | Dynamic crypto maps

> Manual Crypto Maps
> These are static tunnels that use pre-configured information (including security keys) for establishment. Because they rely on statically configured information, once created, the tunnels never expire; they exist until their configuration is deleted.
> Manual crypto maps define the peer security gateway to establish a tunnel with, the security keys to use to establish the tunnel, and the IPSec SA to be used to protect data sent/received over the tunnel. Additionally, manual crypto maps are applied to specific system interfaces.
> Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
> ISAKMP Crypto Maps
> These tunnels are similar to manual crypto maps in that they require some statically configured information such as the IP address of a peer security gateway and that they are applied to specific system interfaces.
> However, ISAKMP crypto maps offer greater security because they rely on dynamically generated security associations through the use of the Internet Key Exchange (IKE) protocol.
> When ISAKMP crypto maps are used, the system uses the pre-shared key configured for map as part of the Diffie-Hellman (D-H) exchange with the peer security gateway to initiate Phase 1 of the establishment process. Once the exchange is complete, the system and the security gateway dynamically negotiate IKE SAs to complete Phase 1. In Phase 2, the two peers dynamically negotiate the IPSec SAs used to determine how data traversing the tunnel will be protected.
> Dynamic Crypto Maps
> These tunnels are used for protecting L2TP-encapsulated data between the system and an LNS/security gateway or Mobile IP data between an FA service configured on one system and an HA service configured on another.
> The system determines when to implement IPSec for L2TP-encapsulated data either through attributes returned upon successful authentication for attribute based tunneling, or through the configuration of the LAC service used for compulsory tunneling.
> The system determines when to implement IPSec for Mobile IP based on RADIUS attribute values as well as the configurations of the FA and HA service(s).
> Implementing IPSec for PDN Access Applications
> This section provides information on the following topics:

> • | How the IPSec-based PDN Access Configuration Works

> • | Configuring IPSec Support for PDN Access

> In covering these topics, this section assumes that ISAKMP crypto maps are configured/used as opposed to manual crypto maps.
> How the IPSec-based PDN Access Configuration Works
> The following figure and the text that follows describe how sessions accessing a PDN using IPSec are processed by the system.
> IPSec PDN Access Processing
> IPSec PDN Access Processing

> Step | Description
> 1. | A subscriber session or PDP context Request, in GGSN service, arrives at the system.
> 2. | The system processes the subscriber session or request as it would typically.
> 3. | Prior to routing the session packets, the system compares them against configured Access Control Lists (ACLs).
> 4. | The system determines that the packet matches the criteria of an ACL that is associated with a configured crypto map.
> 5. | From the crypto map, the system determines the following:
> • | The map type, in this case ISAKMP
> • | The pre-shared key used to initiate the Internet Key Exchange (IKE) and the IKE negotiation mode
> • | The IP address of the security gateway
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of a configured transform set defining the IPSec SA
> 6. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the pre-shared key specified in the crypto map with the specified peer security gateway.
> 7. | The system and the security gateway negotiate an ISAKMP policy (IKE SA) to use to protect further communications.
> 8. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the security gateway using the transform method specified in the transform sets.
> 9. | Once the IPSec SA has been negotiated, the system protects the data according to the IPSec SAs established during step 8 and sends it over the IPSec tunnel.

> ‌
> Configuring IPSec Support for PDN Access
> This section provides a list of the steps required to configure IPSec functionality on the system in support of PDN access. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA. In addition, parameters configured using this procedure must be configured in the same destination context on the system.

> Step 1 | Configure one or more IP access control lists (ACLs) according to the information and instructions located in IP Access Control Lists chapter of this guide.

> Step 2 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 3 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 4 | Configure an ipsec-isakmp crypto map according to the instructions located in the ISAKMP Crypto Map Configuration section of this chapter.

> Step 5 | Apply the crypto map to an interface on the system according to the instructions located in the Crypto Map and Interface Association section of this chapter.

> Step 6 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Implementing IPSec for Mobile IP Applications
> This section provides information on the following topics:

> • | How the IPSec-based Mobile IP Configuration Works

> • | Configuring IPSec Support for Mobile IP

> How the IPSec-based Mobile IP Configuration Works
> The following figure and the text that follows describe how Mobile IP sessions using IPSec are processed by the system.
> IPSec-based Mobile IP Session Processing
> IPSec-based Mobile IP Session Processing

> Step | Description
> 1. | FA service receives a Mobile IP registration request from the mobile node.
> 2. | FA sends an Access-Request to the FAAA server with the 3GPP2-IKE-Secret-Request attribute equal to yes.
> 3. | The FAAA proxies the request to the HAAA.
> 4. | The HAAA returns an Access-Accept message including the following attributes:
> • | 3GPP2-Security-Level set to 3 for IPSec tunnels and registration messages
> • | 3GPP2-MIP-HA-Address indicating the IP address of the HA that the FA is to communicate with.
> • | 3GPP2-KeyId providing an identification number for the IKE secret (alternatively, the keys may be statically configured for the FA and/or HA)
> • | 3GPP2-IKE-Secret indicating the pre-shared secret to use to negotiate the IKE SA
> 5. | The FAAA passes the accept message to the FA with all of the attributes.
> 6. | The FA determines if an IPSec SA already exists based on the HA address supplied. If so, that SA will be used. If not, a new IPSec SA will be negotiated.
> 7. | The FA determines the appropriate crypto map to use for IPSec protection based on the HA address attribute. It does this by comparing the address received to those configured using the isakmp peer-ha command. From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 8. | To initiate the IKE SA negotiation, the FA performs a Diffie-Hellman (D-H) exchange of the ISAKMP secret specified in the IKE secret attribute with the peer HA dictated by the HA address attribute. Included in the exchange is the Key ID received from the HAAA.
> 9. | Upon receiving the exchange, the HA sends an access request to the HAAA with the following attributes:
> • | 3GPP2-S-Request (note that this attribute is not used if the IPSec keys are statically configured)
> • | 3GPP2-User-name (the username specified is the IP addresses of the FA and HA).
> The password used in the access request is the RADIUS shared secret.
> 10. | The HAAA returns an Access-Accept message to the HA with the following attributes:
> • | 3GPP2-S indicating the “S” secret used to generate the HA’s response to the D-H exchange
> • | 3GPP2-S-Lifetime indicating the length of time that the “S” secret is valid
> • | 3GPP2-Security-Level set to 3 for IPSec tunnels and registration messages (optional)
> 11. | The HA determines the appropriate crypto map to use for IPSec protection based on the FA’s address. It does this by comparing the address received to those configured using the isakmp peer-fa command. From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 12. | The HA creates a response to the D-H exchange using the “S” secret and the Key ID sent by the FA.
> 13. | The HA sends IKE SA negotiation D-H exchange response to the FA.
> 14. | The FA and the HA negotiate an ISAKMP (IKE) policy to use to protect further communications.
> 15. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the security gateway using the transform method specified in the transform sets.
> 16. | Once the IPSec SA has been negotiated, the system protects the data according to the IPSec SAs established during step 15 and sends it over the IPSec tunnel.

> ‌
> Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
> Configuring IPSec Support for Mobile IP
> This section provides a list of the steps required to configure IPSec functionality on the system in support of Mobile IP. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the systems were previously configured to support subscriber data sessions either as an FA or an HA.

> Step 1 | Configure one or more transform sets for the FA system according to the instructions located in the Transform Set Configuration section of this chapter.

> The transform set(s) must be configured in the same context as the FA service.

> Step 2 | Configure one or more ISAKMP policies or the FA system according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> The ISAKMP policy(ies) must be configured in the same context as the FA service.

> Step 3 | Configure an ipsec-isakmp crypto map or the FA system according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> The crypto map(s) must be configured in the same context as the FA service.

> Step 4 | Optional. Configure DPD for the FA to help prevent IPSec tunnel state mismatches between the FA and HA according to the instructions located in the Dead Peer Detection (DPD) Configuration section of this chapter.

> Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.

> Step 5 | Configure the FA Service or the FA system according to the instructions located in the FA Services Configuration to Support IPSec section of this chapter.

> Step 6 | Configure one or more transform sets for the HA system according to the instructions located in the Transform Set Configuration section of this chapter.

> The transform set(s) must be configured in the same context as the HA service.

> Step 7 | Configure one or more ISAKMP policies or the HA system according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> The ISAKMP policy(ies) must be configured in the same context as the HA service.

> Step 8 | Configure an ipsec-isakmp crypto map or the HA system according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> The crypto map(s) must be configured in the same context as the HA service.

> Step 9 | Optional. Configure DPD for the HA to help prevent IPSec tunnel state mismatches between the FA and HA according to the instructions located in the Dead Peer Detection (DPD) Configuration section of this chapter.

> Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.

> Step 10 | Configure the HA Service or the HA system according to the instructions located in the section of this chapter.

> Step 11 | Configure the required attributes for RADIUS-based subscribers according to the information located in the RADIUS Attributes for IPSec-based Mobile IP Applications section of this chapter.

> Step 12 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Implementing IPSec for L2TP Applications
> This section provides information on the following topics:

> • | How IPSec is Used for Attribute-based L2TP Configurations

> • | Configuring Support for L2TP Attribute-based Tunneling with IPSec

> • | How IPSec is Used for PDSN Compulsory L2TP Configurations

> • | Configuring Support for L2TP PDSN Compulsory Tunneling with IPSec

> • | How IPSec is Used for L2TP Configurations on the GGSN

> • | Configuring GGSN Support for L2TP Tunneling with IPSec

> How IPSec is Used for Attribute-based L2TP Configurations
> The following figure and the text that follows describe how IPSec-encrypted attribute-based L2TP sessions are processed by the system.
> Attribute-based L2TP, IPSec-Encrypted Session Processing
> Attribute-based L2TP, IPSec-Encrypted Session Processing

> Step | Description
> 1. | A subscriber session arrives at the system.
> 2. | The system attempts to authenticate the subscriber with the AAA server.
> 3. | The profile attributes returned upon successful authentication by the AAA server indicate that session data is to be tunneled using L2TP. In addition, attributes specifying a crypto map name and ISAKMP secret are also supplied indicating that IP security is also required.
> 4. | The system determines that the crypto map name supplied matches a configured crypto map.
> 5. | From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 6. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the ISAKMP secret specified in the profile attribute with the specified peer LNS/security gateway.
> 7. | The system and the LNS/security gateway negotiate an ISAKMP (IKE) policy to use to protect further communications.
> 8. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the LNS/security gateway using the transform method specified in the transform sets.
> 9. | Once the IPSec SA has been negotiated, the system protects the L2TP encapsulated data according to the IPSec SAs established during step 9 and sends it over the IPSec tunnel.

> ‌
> Configuring Support for L2TP Attribute-based Tunneling with IPSec
> This section provides a list of the steps required to configure IPSec functionality on the system in support of attribute-based L2TP tunneling. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support subscriber data sessions and L2TP tunneling either as a PDSN or an HA. In addition, with the exception of subscriber attributes, all other parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.

> Step 1 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 2 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure an ipsec-isakmp crypto map according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> Step 4 | Configure the subscriber profile attributes according to the instructions located in the Subscriber Attributes for L2TP Application IPSec Support section of this chapter.

> Step 5 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> How IPSec is Used for PDSN Compulsory L2TP Configurations
> The following figure and the text that follows describe how IPSec-encrypted PDSN compulsory L2TP sessions are processed by the system.
> PDSN Compulsory L2TP, IPSec-Encrypted Session Processing
> PDSN Compulsory L2TP, IPSec-Encrypted Session Processing

> Step | Description
> 1. | A subscriber session arrives at a PDSN service on the system that is configured to perform compulsory tunneling. The system uses the LAC service specified in the PDSN service’s configuration.
> 2. | The LAC service dictates the peer LNS to use and also specifies the following parameters indicating that IP security is also required:
> • | Crypto map name
> • | ISAKMP secret
> 3. | The system determines that the crypto map name supplied matches a configured crypto map.
> 4. | From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 5. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the ISAKMP secret specified by the attribute with the specified peer LNS/security gateway.
> 6. | The system and the LNS/security gateway negotiate an ISAKMP policy (IKE SA) to use to protect further communications.
> 7. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the LNS/security gateway.
> 8. | Once the IPSec SA has been negotiated, the system protects the L2TP encapsulated data according to the rules specified in the transform set and sends it over the IPSec tunnel.

> ‌
> Configuring Support for L2TP PDSN Compulsory Tunneling with IPSec
> This section provides a list of the steps required to configure IPSec functionality on the system in support of PDSN compulsory L2TP tunneling. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support PDSN compulsory tunneling subscriber data sessions. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.

> Step 1 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 2 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure an ipsec-isakmp crypto map according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> Step 4 | Configure the subscriber profile attributes according to the instructions located in the Subscriber Attributes for L2TP Application IPSec Support section of this chapter.

> Step 5 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> How IPSec is Used for L2TP Configurations on the GGSN
> The following figure and the text that follows describe how IPSec-encrypted attribute-based L2TP sessions are processed by the system.
> GGSN PDP Context Processing with IPSec-Encrypted L2TP
> GGSN PDP Context Processing with IPSec-Encrypted L2TP

> Step | Description
> 1. | A subscriber session/PDP Context Request arrives at the system.
> 2. | The configuration of the APN accessed by the subscriber indicates that session data is to be tunneled using L2TP. In addition, attributes specifying a crypto map name and ISAKMP secret are also supplied indicating that IP security is also required.
> 3. | The system determines that the crypto map name supplied matches a configured crypto map.
> 4. | From the crypto map, the system determines the following:
> • | The map type, in this case dynamic
> • | Whether perfect forward secrecy (PFS) should be enabled for the IPSec SA and if so, what group should be used
> • | IPSec SA lifetime parameters
> • | The name of one or more configured transform set defining the IPSec SA
> 5. | To initiate the IKE SA negotiation, the system performs a Diffie-Hellman exchange of the ISAKMP secret specified in the profile attribute with the specified peer LNS/security gateway.
> 6. | The system and the LNS/security gateway negotiate an ISAKMP (IKE) policy to use to protect further communications.
> 7. | Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the LNS/security gateway using the transform method specified in the transform sets.
> 8. | Once the IPSec SA has been negotiated, the system protects the L2TP encapsulated data according to the IPSec SAs established during step 9 and sends it over the IPSec tunnel.

> ‌
> Configuring GGSN Support for L2TP Tunneling with IPSec
> This section provides a list of the steps required to configure the GGSN to encrypt L2TP tunnels using IPSEC. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
> Important: These instructions assume that the system was previously configured to support subscriber PDP contexts and L2TP tunneling either as a GGSN. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.

> Step 1 | Configure one or more transform sets according to the instructions located in the Transform Set Configuration section of this chapter.

> Step 2 | Configure one or more ISAKMP policies according to the instructions located in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure an ipsec-isakmp crypto map according to the instructions located in the Dynamic Crypto Map Configuration section of this chapter.

> Step 4 | Configure APN support for encrypting L2TP tunnels using IPSec according to the instructions located in the APN Template Configuration to Support L2TP section of this chapter.

> Step 5 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Transform Set Configuration
> This section provides instructions for configuring transform sets on the system.
> Important: This section provides the minimum instruction set for configuring transform set on your system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Transform Configuration Mode chapters in the Command Line Interface Reference.
> To configure the crypto transform set for IPSec:

> Step 1 | Configure crypto transform set by applying the example configuration in the Configuring Transform Set section.

> Step 2 | Verify your Crypto Transform Set configuration by following the steps in the Verifying the Crypto Transform Set Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Transform Set
> Use the following example to create the crypto transform set on your system:
> configure
> context <ctxt_name>
> crypto ipsec transform-set <transform_name> ah hmac { md5-96 | none |sha1-96 } esp hmac { { md5-96 | none | sha1-96 } { cipher {des-cbc | 3des-cbc | aes-cbc } | none }
> mode { transport | tunnel }
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the crypto transform set(s).

> • | <transform_name> is the name of the crypto transform set in the current context that you want to configure for IPSec configuration.

> • | For more information on parameters, refer to the IPSec Transform Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the Crypto Transform Set Configuration
> These instructions are used to verify the crypto transform set(s) was/were configured.

> Step 1 | Verify that your header crypto transform set configurations by entering the following command in Exec Mode in specific context:

> show crypto transform-set transform_name
> This command produces an output similar to that displayed below using the configuration of a transform set named test1.
> Transform-Set test1 :
> AH : none
> ESP :hmac md5-96, 3des-cbc
> Encaps Mode: TUNNEL
> ISAKMP Policy Configuration
> This section provides instructions for configuring ISAKMP policies on the system. ISAKMP policy configuration is only required if the crypto map type is either ISAKMP or Dynamic.
> Important: This section provides the minimum instruction set for configuring ISAKMP policies on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and ISAKMP Configuration Mode Commands chapters in the Command Line Interface Reference.
> To configure the ISAKMP policy for IPSec:

> Step 1 | Configure crypto transform set by applying the example configuration in the Configuring ISAKMP Policy section.

> Step 2 | Verify your ISAKMP policy configuration by following the steps in the Verifying the ISAKMP Policy Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring ISAKMP Policy
> Use the following example to create the ISAKMP policy on your system:
> configure
> context <ctxt_name>
> ikev1 policy <priority>
> encryption { 3des-cbc | des-cbc }
> hash { md5 | sha1 }
> group { 1 | 2 | 3 | 4 | 5 }
> lifetime <time>
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the ISAKMP policy.

> • | <priority> dictates the order in which the ISAKMP policies are proposed when negotiating IKE SAs.

> • | For more information on parameters, refer to the I SAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the ISAKMP Policy Configuration
> These instructions are used to verify the ISAKMP policy configuration.

> Step 1 | Verify that your ISAKMP policy configuration by entering the following command in Exec Mode in specific context:

> show crypto isakmp policy priority
> This command produces an output similar to that displayed below that displays the configuration of an ISAKMP policy with priority 1.
> 1 ISAKMP Policies are configured
> Priority : 1
> Authentication Method : preshared-key
> Lifetime : 120 seconds
> IKE group : 5
> hash : md5
> encryption : 3des-cbc
> Caution: Modification(s) to an existing ISAKMP policy configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> ISAKMP Crypto Map Configuration
> This section provides instructions for configuring ISAKMP crypto maps.
> Important: This section provides the minimum instruction set for configuring ISAKMP crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map ISAKMP Configuration Mode chapters in the Command Line Interface Reference.
> To configure the ISAKMP crypto maps for IPSec:

> Step 1 | Configure ISAKMP crypto map by applying the example configuration in the Configuring ISAKMP Crypto Maps section.

> Step 2 | Verify your ISAKMP crypto map configuration by following the steps in the Verifying the ISAKMP Crypto Map Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring ISAKMP Crypto Maps
> Use the following example to create the ISAKMP crypto map on your system:
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-isakmp
> set peer <agw_address>
> set isakmp preshared-key <isakmp_key>
> set mode { aggressive | main }
> set pfs { group1 | group2 | group5 }
> set transform-set <transform_name>
> match address <acl_name> [ preference ]
> match crypto-group <group_name> { primary | secondary }
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.

> • | <map_name> is name by which the ISAKMP crypto map will be recognized by the system.

> • | <acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.

> • | <group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter. For more information, refer to the Redundant IPSec Tunnel Fail-Over section of this chapter.

> • | For more information on parameters, refer to the Crypto Map ISAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the ISAKMP Crypto Map Configuration
> These instructions are used to verify the ISAKMP crypto map configuration.

> Step 1 | Verify that your ISAKMP crypto map configurations by entering the following command in Exec Mode in specific context:

> show crypto map [ tag map_name | type ipsec-isakmp ]
> This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map2.
> Map Name : test_map2
> ========================================
> Payload :
> crypto_acl2: permit tcp host 10.10.2.12 neq 35 any
> Crypto map Type : ISAKMP
> IKE Mode : MAIN
> IKE pre-shared key : 3fd32rf09svc
> Perfect Forward Secrecy : Group2
> Hard Lifetime :
> 28800 seconds
> 4608000 kilobytes
> Number of Transforms: 1
> Transform : test1
> AH : none
> ESP: md5 3des-cbc
> Encaps mode: TUNNEL
> Local Gateway: Not Set
> Remote Gateway: 192.168.1.1
> Caution: Modification(s) to an existing ISAKMP crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> Dynamic Crypto Map Configuration
> This section provides instructions for configuring dynamic crypto maps. Dynamic crypto maps should only be configured in support of L2TP or Mobile IP applications.
> Important: This section provides the minimum instruction set for configuring dynamic crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Dynamic Configuration Mode chapters in the Command Line Interface Reference.
> To configure the dynamic crypto maps for IPSec:

> Step 1 | Configure dynamic crypto maps by applying the example configuration in the Configuring Dynamic Crypto Maps section.

> Step 2 | Verify your dynamic crypto map configuration by following the steps in the Verifying the Dynamic Crypto Map Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Dynamic Crypto Maps
> Use the following example to create the crypto transform set on your system:
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-dynamic
> set pfs { group1 | group2 | group5 }
> set transform-set <transform_name>
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the dynamic crypto maps.

> • | <map_name> is name by which the dynamic crypto map will be recognized by the system.

> • | For more information on parameters, refer to the Crypto Map Dynamic Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the Dynamic Crypto Map Configuration
> These instructions are used to verify the dynamic crypto map configuration.

> Step 1 | Verify that your dynamic crypto map configurations by entering the following command in Exec Mode in specific context:

> show crypto map [ tag map_name | type ipsec-dynamic ]
> This command produces an output similar to that displayed below using the configuration of a dynamic crypto map named test_map3.
> Map Name : test_map3
> ========================================
> Crypto map Type : ISAKMP (Dynamic)
> IKE Mode : MAIN
> IKE pre-shared key :
> Perfect Forward Secrecy : Group2
> Hard Lifetime :
> 28800 seconds
> 4608000 kilobytes
> Number of Transforms: 1
> Transform : test1
> AH : none
> ESP: md5 3des-cbc
> Encaps mode: TUNNEL
> Local Gateway: Not Set
> Remote Gateway: Not Set
> Caution: Modification(s) to an existing dynamic crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> Manual Crypto Map Configuration
> This section provides instructions for configuring manual crypto maps on the system.
> Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
> Important: This section provides the minimum instruction set for configuring manual crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Manual Configuration Mode chapters in the Command Line Interface Reference.
> To configure the manual crypto maps for IPSec:

> Step 1 | Configure manual crypto map by applying the example configuration in the Configuring Manual Crypto Maps section.

> Step 2 | Verify your manual crypto map configuration by following the steps in the Verifying the Manual Crypto Map Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Manual Crypto Maps
> Use the following example to create the manual crypto map on your system:
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-manual
> set peer <agw_address>
> match address <acl_name> [ preference ]
> set transform-set <transform_name>
> set session-key { inbound | outbound } { ah <ah_spi> [ encrypted ] key <ah_key> | esp <esp_spi> [ encrypted ] cipher <encryption_key> [ encrypted ] authenticator <auth_key> }
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the manual crypto maps.

> • | <map_name> is name by which the manual crypto map will be recognized by the system.

> • | <acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.

> • | The length of the configured key must match the configured algorithm.

> • | <group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter.

> • | For more information on parameters, refer to the Crypto Map Manual Configuration Mode Commands chapter in the Command Line Interface Reference.

> Verifying the Manual Crypto Map Configuration
> These instructions are used to verify the manual crypto map configuration.

> Step 1 | Verify that your manual crypto map configurations by entering the following command in Exec Mode in specific context:

> show crypto map [ tag map_name | type ipsec-manual ]
> This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map.
> Map Name : test_map
> ========================================
> Payload :
> crypto_acl1: permit tcp host 1.2.3.4 gt 30 any
> Crypto map Type : manual(static)
> Transform : test1
> Encaps mode: TUNNEL
> Transmit Flow
> Protocol : ESP
> SPI : 0x102 (258)
> Hmac : md5, key: 23d32d23cs89
> Cipher : 3des-cbc, key: 1234asd3c3d
> Receive Flow
> Protocol : ESP
> SPI : 0x101 (257) Hmac : md5, key: 008j90u3rjp
> Cipher : 3des-cbc, key: sdfsdfasdf342d32
> Local Gateway: Not Set
> Remote Gateway: 192.168.1.40
> Caution: Modification(s) to an existing manual crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
> Crypto Map and Interface Association
> This section provides instructions for applying manual or ISAKMP crypto maps to interfaces configured on the system. Dynamic crypto maps should not be applied to interfaces.
> Important: This section provides the minimum instruction set for applying manual or ISAKMP crypto maps to an interface on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To apply the crypto maps to an interface:

> Step 1 | Configure a manual or ISAKMP crypto map by applying the example configuration in any of the following sections:

> Step 2 | Apply desired crypto map to system interface by following the steps in the Applying Crypto Map to an Interface section

> Step 3 | Verify your manual crypto map configuration by following the steps in the Verifying the Interface Configuration with Crypto Map section.

> Step 4 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Applying Crypto Map to an Interface
> Use the following example to apply an existing crypto map to an interface on your system:
> configure
> context <ctxt_name>
> interface <interface_name>
> crypto-map <map_name>
> end
> Notes:

> • | <ctxt_name> is the system context in which the interface is configured to apply crypto map.

> • | <interface_name> is the name of a specific interface configured in the context to which the crypto map will be applied.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypto map.

> Verifying the Interface Configuration with Crypto Map
> These instructions are used to verify the interface configuration with crypto map.

> Step 1 | Verify that your interface is configured properly with crypto map by entering the following command in Exec Mode in specific context:

> show configuration context ctxt_name | grep interface
> The interface configuration aspect of the display should look similar to that shown below. In this example an interface named 20/6 was configured with a crypto map called isakmp_map1.
> interface 20/6
> ip address 192.168.4.10 255.255.255.0
> crypto-map isakmp_map1
> FA Services Configuration to Support IPSec
> This section provides instructions for configuring FA services to support IPSec.
> These instructions assume that the FA service was previously configured and system is ready to serve as an FA.
> Important: This section provides the minimum instruction set for configuring an FA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the FA service to support IPSec:

> Step 1 | Modify FA service configuration by following the steps in the Modifying FA service to Support IPSec section

> Step 2 | Verify your FA service configuration by following the steps in the Verifying the FA Service Configuration with IPSec section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying FA service to Support IPSec
> Use the following example to modify FA service to support IPSec on your system:
> configure
> context <ctxt_name>
> fa-service <fa_svc_name>
> isakmp peer-ha <ha_address> crypto-map <map_name> [ secret <preshared_secret> ]
> isakmp default crypto-map <map_name> [ secret <preshared_secret> ]
> end
> Notes:

> • | <ctxt_name> is the system context in which the FA service is configured to support IPSec.

> • | <fa_svc_name> is name of the FA service for which you are configuring IPSec.

> • | <ha_address> is IP address of the HA service to which FA service will communicate on IPSec.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypto map.

> • | A default crypto map for the FA service to be used in the event that the AAA server returns an HA address that is not configured as an ISAKMP peer HA.

> • | For maximum security, the default crypto map should be configured in addition to peer-ha crypto maps instead of being used to provide IPSec SAs to all HAs. Note that once an IPSec tunnel is established between the FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.

> Verifying the FA Service Configuration with IPSec
> These instructions are used to verify the FA service to support IPSec.

> Step 1 | Verify that your FA service is configured properly with IPSec by entering the following command in Exec Mode in specific context:

> show fa-service { name service_name | all }
> The output of this command is a concise listing of FA service parameter settings configured on the system.
> HA Service Configuration to Support IPSec
> This section provides instructions for configuring HA services to support IPSec.
> These instructions assume that the HA service was previously configured and system is ready to serve as an HA.
> Important: This section provides the minimum instruction set for configuring an HA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the HA service to support IPSec:

> Step 1 | Modify HA service configuration by following the steps in the Modifying HA service to Support IPSec section

> Step 2 | Verify your HA service configuration by following the steps in the Verifying the HA Service Configuration with IPSec section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying HA service to Support IPSec
> Use the following example to modify an existing HA service to support IPSec on your system:
> configure
> context <ctxt_name>
> ha-service <ha_svc_name>
> isakmp aaa-context <aaa_ctxt_name>
> isakmp peer-fa <fa_address> crypto-map <map_name> [ secret <preshared_secret> ]
> end
> Notes:

> • | <ctxt_name> is the system context in which the FA service is configured to support IPSec.

> • | <ha_svc_name> is name of the HA service for which you are configuring IPSec.

> • | <fa_address> is IP address of the FA service to which HA service will communicate on IPSec.

> • | <aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypot map.

> Verifying the HA Service Configuration with IPSec
> These instructions are used to verify the HA service to support IPSec.

> Step 1 | Verify that your HA service is configured properly with IPSec by entering the following command in Exec Mode in specific context:

> show ha-service { name service_name | all }
> The output of this command is a concise listing of HA service parameter settings configured on the system.
> RADIUS Attributes for IPSec-based Mobile IP Applications
> As described in the How the IPSec-based Mobile IP Configuration Works section of this chapter, the system uses attributes stored in a subscriber’s RADIUS profile to determine how IPSec should be implemented.
> The table below lists the attributes that must be configured in the subscriber’s RADIUS attributes to support IPSec for Mobile IP. These attributes are contained in the following dictionaries:

> • | 3GPP2

> • | 3GPP2-835

> • | Starent

> • | Starent-835

> • | Starent-VSA1

> • | Starent-VSA1-835

> Attributes Used for Mobile IP IPSec Support

> Attribute | Description | Variable
> 3GPP2-Security-Level | This attribute indicates the type of security that the home network mandates on the visited network. | Integer value: 3 : Enables IPSec for tunnels and registration messages 4 : Disables IPSec
> 3GPP2 -KeyId | This attribute contains the opaque IKE Key Identifier for the FA/HA shared IKE secret. | Supported value for the first eight bytes is the network-order FA IP address in hexadecimal characters. Supported value for the next eight bytes is the network-order HA IP address in hexadecimal characters. Supported value for the final four bytes is a timestamp in network order, indicating when the key was created, and is the number of seconds since January 1, 1970, UTC.
> 3GPP2-IKE-Secret | This attribute contains the FA/HA shared secret for the IKE protocol. This attribute is salt-encrypted. | A binary string of 1 to 127 bytes.
> 3GPP2-S | This attribute contains the 'S' secret parameter used to make the IKE pre-shared secret. | A binary string of the value of 'S' consisting of 1 to 127 characters.
> 3GPP2- S-Lifetime | This attribute contains the lifetime of the 'S' secret parameter used to make the IKE pre-shared secret. | An integer in network order, indicating the time in seconds since January 1, 1970 00:00 UTC. Note that this is equivalent to the Unix operating system expression of time.

> ‌
> LAC Service Configuration to Support IPSec
> This section provides instructions for configuring LAC services to support IPSec.
> Important: These instructions are required for compulsory tunneling. They should only be performed for attribute-based tunneling if the Tunnel-Service-Endpoint, the SN1-Tunnel-ISAKMP-Crypto-Map, or the SN1 -Tunnel-ISAKMP-Secret are not configured in the subscriber profile.
> These instructions assume that the LAC service was previously configured and system is ready to serve as an LAC server.
> Important: This section provides the minimum instruction set for configuring an LAC service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the LAC service to support IPSec:

> Step 1 | Modify LAC service configuration by following the steps in the Modifying LAC service to Support IPSec section.

> Step 2 | Verify your LAC service configuration by following the steps in the Verifying the LAC Service Configuration with IPSec section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying LAC service to Support IPSec
> Use the following example to modify an existing LAC service to support IPSec on your system:
> configure
> context <ctxt_name>
> lac-service <lac_svc_name>
> peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> { [encrypted] isakmp-secret <secret> } ] [ description <text> ] [ preference <integer>]
> isakmp aaa-context <aaa_ctxt_name>
> isakmp peer-fa <fa_address> crypto-map <map_name> [ secret <preshared_secret> ]
> end
> Notes:

> • | <ctxt_name> is the destination context where the LAC service is configured to support IPSec.

> • | <lac_svc_name> is name of the LAC service for which you are configuring IPSec.

> • | <lns_address> is IP address of the LNS node to which LAC service will communicate on IPSec.

> • | <aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.

> • | <map_name> is name of the preconfigured ISAKMP or a manual crypot map.

> Verifying the LAC Service Configuration with IPSec
> These instructions are used to verify the LAC service to support IPSec.

> Step 1 | Verify that your LAC service is configured properly with IPSec by entering the following command in Exec Mode in specific context:

> show lac-service name service_name
> The output of this command is a concise listing of LAC service parameter settings configured on the system.
> Subscriber Attributes for L2TP Application IPSec Support
> In addition to the subscriber profile attributes listed in the RADIUS and Subscriber Profile Attributes Used section of the L2TP Access Concentrator chapter in this guide, the table below lists the attributes required to support IPSec for use with attribute-based L2TP tunneling.
> These attributes are contained in the following dictionaries:

> • | Starent

> • | Starent-835

> Subscriber Attributes for IPSec encrypted L2TP Support

> RADIUS Attribute | Local SubscriberAttribute | Description | Variable
> SN1-Tunnel-ISAKMP- Crypto-Map | tunnel l2tp crypto-map | The name of a crypto map configured on the system. | A salt-encrypted ascii string specifying the crypto-map to use for this subscriber. It can be tagged, in which case it is treated as part of a tunnel group.
> SN1 -Tunnel-ISAKMP- Secret | tunnel l2tp crypto-map isakmp-secret | The pre-shared secret that will be used as part of the D-H exchange to negotiate an IKE SA. | A salt-encrypted string specifying the IKE secret. It can be tagged, in which case it is treated as part of a tunnel group.

> ‌
> PDSN Service Configuration for L2TP Support
> PDSN service configuration is required for compulsory tunneling and optional for attribute-based tunneling.
> For attribute-based tunneling, a configuration error could occur such that upon successful authentication, the system determines that the subscriber session requires L2TP but can not determine the name of the context in which the appropriate LAC service is configured from the attributes supplied. As a precautionary, a parameter has been added to the PDSN service configuration options that will dictate the name of the context to use. It is strongly recommended that this parameter be configured.
> This section contains instructions for modifying the PDSN service configuration for either compulsory or attribute-based tunneling.
> These instructions assume that the PDSN service was previously configured and system is ready to serve as a PDSN.
> This section provides the minimum instruction set for configuring an L2TP service on the PDSN system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
> To configure the PDSN service to support L2TP:

> Step 1 | Modify PDSN service to configure compulsory tunneling or attribute-based tunneling by applying the example configuration in any of the following sections:

> • | Modifying PDSN service to Support Attribute-based L2TP Tunneling

> • | Modifying PDSN service to Support Compulsory L2TP Tunneling

> Step 2 | Verify your LAC service configuration by following the steps in the Verifying the PDSN Service Configuration for L2TP section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying PDSN service to Support Attribute-based L2TP Tunneling
> Use the following example to modify an existing PDSN service to support attribute-based L2TP tunneling on your system:
> configure
> context <ctxt_name>
> pdsn-service <pdsn_svc_name>
> ppp tunnel-context <lac_ctxt_name>
> end
> Notes:

> • | <ctxt_name> is the destination context where the PDSN service is configured.

> • | <pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.

> • | <lac_ctxt_name> is the name of the destination context where the LAC service is located.

> Modifying PDSN service to Support Compulsory L2TP Tunneling
> Use the following example to modify an existing PDSN service to support compulsory L2TP tunneling on your system:
> configure
> context <ctxt_name>
> pdsn-service <pdsn_svc_name>
> ppp tunnel-context <lac_ctxt_name>
> ppp tunnel-type l2tp
> end
> Notes:

> • | <ctxt_name> is the destination context where the PDSN service is configured.

> • | <pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.

> • | <lac_ctxt_name> is name of the destination context where the LAC service is located.

> Verifying the PDSN Service Configuration for L2TP
> These instructions are used to verify the PDSN service to support L2TP.

> Step 1 | Verify that your PDSN service is configured properly with L2TP by entering the following command in Exec Mode in specific context:

> show pdsn-service name service_name
> The output of this command is a concise listing of PDSN service parameter settings configured on the system.
> Redundant IPSec Tunnel Fail-Over
> The Redundant IPSec Tunnel Fail-Over functionality is included with the IPSec feature license and allows the configuration of a secondary ISAKMP crypto map-based IPSec tunnel over which traffic is routed in the event that the primary ISAKMP crypto map-based tunnel cannot be used.
> This feature introduces the concept of crypto (tunnel) groups when using IPSec tunnels for access to packet data networks (PDNs). A crypto group consists of two configured ISAKMP crypto maps. Each crypto map defines the IPSec policy for a tunnel. In the crypto group, one tunnel serves as the primary, the other as the secondary (redundant). Note that the method in which the system determines to encrypt user data in an IPSec tunnel remains unchanged.
> Group tunnels are perpetually maintained with IPSec Dead Peer Detection (DPD) packets exchanged with the peer security gateway.
> Important: The peer security gateway must support RFC 3706 in order for this functionality to function properly.
> When the system determines that incoming user data traffic must be routed over one of the tunnels in a group, the system automatically uses the primary tunnel until either the peer is unreachable (the IPSec DPD packets cease), or the IPSec tunnel fails to re-key. If the primary peer becomes unreachable, the system automatically begins to switch user traffic to the secondary tunnel. The system can be configured to either automatically switch user traffic back to the primary tunnel once the corresponding peer security gateway is reachable and the tunnel is configured, or require manual intervention to do so.
> This functionality also supports the generation of Simple network Management Protocol (SNMP) notifications indicating the following conditions:

> • | Primary Tunnel is down: A primary tunnel that was previously "up" is now "down" representing an error condition.

> • | Primary Tunnel is up: A primary tunnel that was previously "down" is now "up".

> • | Secondary tunnel is down: A secondary tunnel that was previously "up" is now "down" representing an error condition.

> • | Secondary Tunnel is up: A secondary tunnel that was previously "down" is now "up".

> • | Fail-over successful: The switchover of user traffic was successful. This is generated for both primary-to-secondary and secondary-to-primary switchovers.

> • | Unsuccessful fail-over: An error occurred when switching user traffic from either the primary to secondary tunnel or the secondary to primary tunnel.

> Supported Standards
> Support for the following standards and requests for comments (RFCs) has been added with the Redundant IPSec Tunnel Fail-over functionality:

> • | RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, February 2004

> Redundant IPSec Tunnel Fail-over Configuration
> This section provides information and instructions for configuring the Redundant IPSec Tunnel Fail-over feature. These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA.
> Important: Parameters configured using this procedure must be configured in the same context on the system.
> Important: The system supports a maximum of 32 crypto groups per context. However, configuring crypto groups to use the same loopback interface for secondary IPSec tunnels is not recommended and may compromise redundancy on the chassis.
> Important: This section provides the minimum instruction set for configuring crypto groups on the system. For more information on commands that configure additional parameters and options, refer Command Line Interface Reference.
> To configure the Crypto group to support IPSec:

> Step 1 | Configure a crypto group by following the steps in the Configuring Crypto Group section

> Step 2 | Configure one or more ISAKMP policies according to the instructions provided in the ISAKMP Policy Configuration section of this chapter.

> Step 3 | Configure IPSec DPD settings using the instructions provided in the Dead Peer Detection (DPD) Configuration section of this chapter.

> Step 4 | Configure an ISAKMP crypto map for the primary and secondary tunnel according to the instructions provided in the ISAKMP Crypto Map Configuration section of this chapter.

> Step 5 | Match the existing ISAKMP crypto map to Crypto group by following the steps in the Modify ISAKMP Crypto Map Configuration to Match Crypto Group section

> Step 6 | Verify your Crypto Group configuration by following the steps in the Verifying the Crypto Group Configuration section.

> Step 7 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Crypto Group
> Use the following example to configure a crypto group on your system for redundant IPSec tunnel fail-over support:
> configure
> context <ctxt_name>
> ikev1 keepalive dpd interval <dur> timeout <dur> num-retry <retries>
> crypto-group <group_name>
> match address <acl_name> [ <preference> ]
> switchover auto [ do-not-revert ]
> end
> Notes:

> • | <ctxt_name> is the destination context where the Crypto Group is to be configured.

> • | <group_name> is name of the Crypto group you want to configure for IPSec tunnel failover support.

> • | <acl_name> is name of the pre-configured crypto ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. For more information on crypto ACL, refer Crypto Access Control List (ACL) section of this chapter.

> Modify ISAKMP Crypto Map Configuration to Match Crypto Group
> Use the following example to match the crypto group with ISAKMP crypto map on your system:
> configure
> context <ctxt_name>
> crypto map <map_name1> ipsec-isakmp
> match crypto-group <group_name> primary
> end
> configure
> context <ctxt_name>
> crypto map <map_name> ipsec-isakmp
> match crypto-group <group_name> secondary
> end
> Notes:

> • | <ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.

> • | <group_name> is name of the Crypto group configured in the same context for IPSec Tunnel Failover feature.

> • | <map_name1> is name of the preconfigured ISAKMP crypto map to match with crypto group as primary.

> • | <map_name2> is name of the preconfigured ISAKMP crypto map to match with crypto group as secondary.

> Verifying the Crypto Group Configuration
> These instructions are used to verify the crypto group configuration.

> Step 1 | Verify that your system is configured properly with crypto group by entering the following command in Exec Mode in specific context:

> show crypto group [ summary | name group_name ]
> The output of this command is a concise listing of crypto group parameter settings configured on the system.
> Dead Peer Detection (DPD) Configuration
> This section provides instructions for configuring the Dead Peer Detection (DPD).
> Defined by RFC 3706, Dead Peer Detection (DPD) is used to simplify the messaging required to verify communication between peers and tunnel availability.
> DPD is configured at the context level and is used in support of the IPSec Tunnel Failover feature (refer to the Redundant IPSec Tunnel Fail-Over section) and/or to help prevent tunnel state mismatches between an FA and HA when IPSec is used for Mobile IP applications. When used with Mobile IP applications, DPD ensures the availability of tunnels between the FA and HA. (Note that the starIPSECDynTunUp and starIPSECDynTunDown SNMP traps are triggered to indicate tunnel state for the Mobile IP scenario.)
> Regardless of the application, DPD must be supported/configured on both security peers. If the system is configured with DPD but it is communicating with a peer that does not have DPD configured, IPSec tunnels still come up. However, the only indication that the remote peer does not support DPD exists in the output of the show crypto isakmp security-associations summary command.
> Important: If DPD is enabled while IPSec tunnels are up, it will not take affect until all of the tunnels are cleared.
> Important: DPD must be configured in the same context on the system as other IPSec Parameters.
> To configure the Crypto group to support IPSec:

> Step 1 | Enable dead peer detection on system in support of the IPSec Tunnel Failover feature by following the steps in the Configuring Crypto Group section

> Step 2 | Verify your Crypto Group configuration by following the steps in the Verifying the DPD Configuration section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Crypto Group
> Use the following example to configure a crypto group on your system for redundant IPSec tunnel fail-over support:
> configure
> context <ctxt_name>
> ikev1 keepalive dpd interval <dur> timeout <dur> num-retry <retries>
> end
> Notes:

> • | <ctxt_name> is the destination context where the Crypto Group is to be configured.

> Verifying the DPD Configuration
> These instructions are used to verify the dead peer detection configuration.

> Step 1 | Verify that your system is configured properly with crypto group with DPD by entering the following command in Exec Mode in specific context:

> sshow crypto group [ summary | name group_name ]
> The output of this command is a concise listing of crypto group parameter settings configured on the system.
> APN Template Configuration to Support L2TP
> This section provides instructions for adding L2TP support for APN templates configured on the system.
> These instructions assume that the APN template was previously configured on this system.
> Important: This section provides the minimum instruction set for configuring an APN template to support L2TP for APN. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference. To configure the APN to support L2TP:

> Step 1 | Modify preconfigured APN template by following the steps in the Modifying APN Template to Support L2TP section

> Step 2 | Verify your APN configuration by following the steps in the Verifying the APN Configuration for L2TP section.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Modifying APN Template to Support L2TP
> Use the following example to modify APN template to support L2TP:
> configure
> context <ctxt_name>
> apn <apn_name>
> tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <num> ] [ tunnel-context <tunnel_ctxt_name> ] [ local-address <agw_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
> end
> Notes:

> • | <ctxt_name> is the system context in which the APN template is configured.

> • | <apn_name> is name of the preconfigured APN template in which you want to configure L2TP support.

> • | <lns_address> is IP address of the LNS node to which this APN will communicate.

> • | <tunnel_ctxt_name> is the L2TP context in which the L2TP tunnel is configured.

> • | <agw_ip_address> is the local IP address of the GGSN in which this APN template is configured.

> • | <map_name> is the preconfigured crypto map (ISAKMP or manual) which is to use for L2TP.

> Verifying the APN Configuration for L2TP
> These instructions are used to verify the APN template configuration for L2TP.

> Step 1 | Verify that your APN is configured properly with L2TP by entering the following command in Exec Mode in specific context:

> show apn { all | name apn_name }
> The output of this command is a concise listing of FA service parameter settings configured on the system.
> IPSec for LTE/SAE Networks
> The Cisco MME (Mobility Management Entity), S-GW (Serving Gateway), and P-GW (Packet Data Network Gateway) support IPSec and IKEv2 encryption using IPv4 and IPv6 addressing in LTE/SAE (Long Term Evolution/System Architecture Evolution) networks. IPSec and IKEv2 encryption enables network domain security for all IP packet-switched networks, providing confidentiality, integrity, authentication, and anti-replay protection via secure IPSec tunnels.
> Encryption Algorithms
> IPSec for LTE/SAE supports the following control and data path encryption algorithms:

> • | AES-CBC-128 (Advanced Encryption Standard-Cipher Block Chaining-128)

> • | AES-CBC-256 (Advanced Encryption Standard-Cipher Block Chaining-256)

> • | DES-CBC (Data Encryption Standard-Cipher Block Chaining)

> • | 3DES-CBC (Triple Data Encryption Standard-Cipher Bock Chaining)

> HMAC Functions
> IPSec for LTE/SAE supports the following data path HMAC (Hash-based Message Authentication Code) functions:

> • | AES-XCBC-MAC-96 (Advanced Encryption Standard-X Cipher Block Chaining-Message Authentication Code-96)

> • | MD5-96 (Message Digest 5-96)

> • | SHA1-96 (Secure Hash Algorithm 1-96)

> IPSec for LTE/SAE supports the following control path HMAC (Hash-based Message Authentication Code) functions:

> • | AES-XCBC-MAC-96 (Advanced Encryption Standard-X Cipher Block Chaining-Message Authentication Code-96)

> • | MD5-96 (Message Digest 5-96)

> • | SHA1-96 (Secure Hash Algorithm 1-96)

> • | SHA2-256-128 (Secure Hash Algorithm 2-256-128)

> • | SHA2-384-192 (Secure Hash Algorithm 2-384-192)

> • | SHA2-512-256 (Secure Hash Algorithm 2-512-256)

> Diffie-Hellman Groups
> IPSec for LTE/SAE supports the following Diffie-Hellman groups for IKE and Child SAs (Security Associations):

> • | Diffie-Hellman Group 1: 768-bit MODP (Modular Exponential) Group

> • | Diffie-Hellman Group 2: 1024-bit MODP Group

> • | Diffie-Hellman Group 5: 1536-bit MODP Group

> • | Diffie-Hellman Group 14: 2048-bit MODP Group

> • | None: No Diffie-Hellman Group (no perfect forward secrecy)

> Dynamic Node-to-Node IPSec Tunnels
> IPSec for LTE/SAE enables network nodes to initiate an IPSec tunnel with another node for secure signaling and data traffic between the nodes, enabling up to 64K dynamic, service-integrated IPSec tunnels per chassis. Once established, a dynamic node-to-node IPSec tunnel continues to carry all of the signaling and/or bearer traffic between the nodes. Dynamic node-to-node IPSec for LTE/SAE is supported on the S1-MME interface for signaling traffic between the eNodeB and the MME, on the S1-U interface for data traffic between the eNodeB and the S-GW, and on the S5 interface for data traffic between the S-GW and the P-GW.
> Dynamic node-to-node IPSec gets configured using dynamic IKEv2 crypto templates, which are used to specify common cryptographic parameters for the IPSec tunnels such as the encryption algorithm, HMAC function, and Diffie-Hellman group. Additional information necessary for creating node-to-node IPSec tunnels such as revocation lists are fetched dynamically from the IPSec tunnel requests.
> For configuration instructions for dynamic node-to-node IPSec, see the configuration chapter in the administration guides for the MME, S-GW, and P-GW.
> ACL-based Node-to-Node IPSec Tunnels
> Node-to-node IPSec for LTE/SAE can also be configured using crypto ACLs (Access Control Lists), which define the matching criteria used for routing subscriber data packets over an IPSec tunnel. ACL-based node-to-node IPSec tunnels are supported on the S1-MME interface for signaling traffic between the eNodeB and the MME, on the S1-U interface for data traffic between the eNodeB and the S-GW, and on the S5 interface for data traffic between the S-GW and the P-GW.
> Unlike other ACLs that are applied to interfaces, contexts, or to one or more subscribers, crypto ACLs are applied via matching criteria to crypto maps, which define tunnel policies that determine how IPSec is implemented for subscriber data packets. Prior to routing, the system examines the properties of each subscriber data packet. If the packet properties match the criteria specified in the crypto ACL, the system initiates the IPSec policy dictated by the crypto map. ACL-based node-to-node IPSec tunnels are configured using either IKEv2-IPv4 or IKEv2-IPv6 crypto maps for IPv4 or IPv6 addressing.
> Up to 150 ACL-based node-to-node IPSec tunnels are supported on the system, each with one SA bundle that includes one Tx and one Rx endpoint. However, to avoid significant performance degradation, dynamic node-to-node IPSec tunnels are recommended. If ACL-based node-to-node IPSec tunnels are used, a limit of about ten ACL-based node-to-node IPSec tunnels per system is recommended.
> For configuration instructions for ACL-based node-to-node IPSec, see the configuration chapter in the administration guides for the MME, S-GW, and P-GW.
> For more information on ACLs, see the System Administration Guide.
> Traffic Selectors
> 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 selector payloads contain the selection criteria for packets being sent over IPSec security associations (SAs). Traffic selectors can be created on the P-GW, S-GW, and MME for dynamic node-to-node IPSec tunnels during crypto template configuration by specifying a range of peer IPv4 or IPV6 addresses from which to carry traffic over IPSec tunnels.
> For example, consider an eNodeB with an IP address of 1.1.1.1 and an S-GW with a service address of 2.2.2.2. The S-GW is registered to listen for IKE requests from the eNodeBs in the network using the following information:

> • | Local Address: 2.2.2.2

> • | Peer Address Network: 1.1.0.0 Mask: 255.255.0.0

> • | Payload ACL (Access Control List): udp host 2.2.2.2 eq 2123 1.1.0.0 0.0.255.255

> When an IKE request arrives the S-GW from eNodeB address 1.1.1.1, the IPSec subsystem converts the payload ACL to: udp host 2.2.2.2 eq 2123 host 1.1.1.1, and this payload becomes the traffic selector for the IPSec tunnel being negotiated.
> To properly accommodate control traffic between IPSec nodes, each child SA must include at least two traffic selectors: one with a well-known port in the source address, and one with a well-known port in the destination address. Continuing the example above, the final traffic selectors would be:

> • | Destination port as well-known port: udp host 2.2.2.2 1.1.0.0 0.0.255.255 eq 2123

> • | Source port as well-known port: udp host 2.2.2.2 eq 2123 1.1.0.0 0.0.255.255

> Note that for ACL-based node-to-node IPSec tunnels, the configured crypto ACL becomes the traffic selector with no modification.
> Authentication Methods
> IPSec for LTE/SAE includes the following authentication methods:

> • | PSK (Pre-Shared Key) Authentication: A pre-shared key is a shared secret that was previously shared between two network nodes. IPSec for LTE/SAE supports PSK such that both IPSec nodes must be configured to use the same shared secret.

> • | X.509 Certificate-based Peer Authentication: IPSec for LTE/SAE supports X.509 certificate-based peer authentication and CA (Certificate Authority) certificate authentication as described below.

> X.509 Certificate-based Peer Authentication
> X.509 specifies standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. X.509 certificates are configured on each IPSec node so that it can send the certificate as part of its IKE_AUTH_REQ for the remote node to authenticate it. These certificates can be in PEM (Privacy Enhanced Mail) or DER (Distinguished Encoding Rules) format, and can be fetched from a repository via HTTP or FTP.
> CA certificate authentication is used to validate the certificate that the local node receives from a remote node during an IKE_AUTH exchange.
> A maximum of sixteen certificates and sixteen CA certificates are supported per system. One certificate is supported per service, and a maximum of four CA certificates can be bound to one crypto template.
> For configuration instructions for X.509 certificate-based peer authentication, see the configuration chapter in the administration guides for the MME, S-GW, and P-GW.
> The figure below shows the message flow during X.509 certificate-based peer authentication. The table that follows the figure describes each step in the message flow.
> X.509 Certificate-based Peer Authentication
> X.509 Certificate-based Peer Authentication

> Step | Description
> 1. | The peer node initiates an IKEv2 exchange with the local node, known as the IKE_SA_INIT exchange, by issuing an IKE_SA_INIT Request to negotiate cryptographic algorithms, exchange nonces, and perform a Diffie-Hellman exchange with the local node.
> 2. | The local node responds with an IKE_SA_INIT Response by choosing a cryptographic suite from the initiator’s offered choices, completing the Diffie-Hellman and nonce exchanges with the peer node. In addition, the local node includes the list of CA certificates that it will accept in its CERTREQ payload. For successful peer authentication, the CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate. At this point in the negotiation, the IKE_SA_INIT exchange is complete and all but the headers of all the messages that follow are encrypted and integrity-protected.
> 3. | The peer node initiates an IKE_AUTH exchange with the local node by including the IDi payload, setting the CERT payload to the peer certificate, and including the AUTH payload containing the signature of the previous IKE_SA_INIT Request message (in step 1) generated using the private key of the peer certificate. The authentication algorithm used to generate the AUTH payload is also included in the AUTH payload. The peer node also includes the CERTREQ payload containing the list of SHA-1 hash algorithms for local node authentication. For successful server authentication, the CERTREQ payload must contain at least one CA certificate that is in the trust chain of the peer certificate.
> 4. | Using the CA certificate corresponding to the peer certificate, the local node first verifies that the peer certificate in the CERT payload has not been modified and the identity included in the IDi corresponds to the identity in the peer certificate. If the verification is successful, using the public key of the peer certificate, the local node generates the expected AUTH payload and compares it with the received AUTH payload. If they match, the authentication of the peer node is successful. Otherwise, the local node sends an IKEv2 Notification message indicating authentication failure.
> 5. | The local node responds with the IKE_AUTH Response, including the IDr payload, setting the CERT payload to the local node certificate, and including the AUTH payload containing the signature of the IKE_SA_INIT Response message (in step 2) generated using the private key of the local node certificate. The authentication algorithm used to generate the AUTH payload is also included in the AUTH payload.
> 6. | Using the CA certificate corresponding to the local node certificate, the peer node first verifies that the local node certificate in the CERT payload has not been modified. If the verification is successful, using the public key of the local node certificate, the peer generates the expected AUTH payload and compares it with the received AUTH payload. If they match, the local node authentication is successful. This completes the IKE_AUTH exchange.
> 7. | An IPSec SA gets established between the peer node and the local node. If more IPSec SAs are needed, either the peer or local node can initiate the creation of additional Child SAs using a CREATE_CHILD_SA exchange.

> ‌
> Certificate Revocation Lists
> Certificate revocation lists track certificates that have been revoked by the CA (Certificate Authority) and are no longer valid. Per RFC 3280, during certificate validation, IPSec for LTE/SAE checks the certificate revocation list to verify that the certificate the local node receives from the remote node has not expired and hence is still valid.
> During configuration via the system CLI, one certificate revocation list is bound to each crypto template and can be fetched from its repository via HTTP or FTP.
> Child SA Rekey Support
> Rekeying of an IKEv2 Child Security Association (SA) occurs for an already established Child SA whose lifetime (either time-based or data-based) is about to exceed a maximum limit. The IPSec subsystem initiates rekeying to replace the existing Child SA. During rekeying, two Child SAs exist momentarily (500ms or less) to ensure that transient packets from the original Child SA are processed by the IPSec node and not dropped.
> Child SA rekeying is disabled by default, and rekey requests are ignored. This feature gets enabled in the Crypto Configuration Payload Mode of the system’s CLI.
> IKEv2 Keep-Alive Messages (Dead Peer Detection)
> IPSec for LTE/SAE supports IKEv2 keep-alive messages, also known as Dead Peer Detection (DPD), originating from both ends of an IPSec tunnel. Per RFC 3706, DPD is used to simplify the messaging required to verify communication between peers and tunnel availability. You configure DPD on each IPSec node. You can also disable DPD, and the node will not initiate DPD exchanges with other nodes. However, the node always responds to DPD availability checks initiated by another node regardless of its DPD configuration.
> E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels
> The figure below shows the logical network interfaces over which secure IPSec tunnels can be created in an E-UTRAN/EPC (Evolved UMTS Terrestrial Radio Access Network/Evolved Packet Core) network. The table that follows the figure provides a description of each logical network interface.
> E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels
> E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels

> Interface | Description
> S1-MME Interface | This interface is the reference point for the control plane protocol between the eNodeB and the MME. The S1-MME interface uses S1-AP (S1- Application Protocol) over SCTP (Stream Control Transmission Protocol) as the transport layer protocol for guaranteed delivery of signaling messages between the MME and the eNodeB (S1). When configured, the S1-AP over SCTP signaling traffic gets carried over an IPSec tunnel. When a subscriber UE initiates a connection with the eNodeB, the eNodeB initiates an IPSec tunnel with the MME, and SCTP signaling for all subsequent subscriber UEs served by this MME gets carried over the same IPSec tunnel. The MME can also initiate an IPSec tunnel with the eNodeB when the following conditions exist:
> • | The first tunnel setup is always triggered by the eNodeB. This is the tunnel over which initial SCTP exchanges occur.
> • | The MME initiates additional tunnels to the eNodeB after an SCTP connection is set up if the MME is multi-homed: a tunnel is initiated from MME's second address to the eNodeB.
> • | The eNodeB is multi-homed: tunnels are initiated from the MME's primary address to each secondary address of the eNodeB.
> • | Both of the prior two conditions: a tunnel is initiated from each of MME's addresses to each address of the eNodeB.
> S1-U Interface | This interface is the reference point for bearer channel tunneling between the eNodeB and the S-GW. Typically, the eNodeB initiates an IPSec tunnel with the S-GW over this interface for subscriber data traffic. But the S-GW may also initiate an IPSec tunnel with the eNodeB, if required.
> S5 Interface | This interface is the reference point for tunneling between the S-GW and the P-GW. Based on the requested APN from a subscriber UE, the MME selects both the S-GW and the P-GW that the S-GW connects to. GTP-U data traffic is carried over the IPSec tunnel between the S-GW and P-GW for the current and all subsequent subscriber UEs.

> ‌
> IPSec Tunnel Termination
> IPSec tunnel termination occurs during the following scenarios:

> • | Idle Tunnel Termination: When a session manager for a service detects that all subscriber sessions using a given IPSec tunnel have terminated, the IPSec tunnel also gets terminated after a timeout period.

> • | Service Termination: When a service running on a network node is brought down for any reason, all corresponding IPSec tunnels get terminated. This may be caused by the interface for a service going down, a service being stopped manually, or a task handling an IPSec tunnel restarting.

> • | Unreachable Peer: If a network node detects an unreachable peer via Dead Peer Detection (DPD), the IPSec tunnel between the nodes gets terminated. DPD can be enabled per P-GW, S-GW, and MME service via the system CLI during crypto template configuration.

> • | E-UTRAN Handover Handling: Any IPSec tunnel that becomes unusable due to an E-UTRAN network handover gets terminated, while the network node to which the session is handed initiates a new IPSec tunnel for the session.

> Appendix D
> Mobile IP Registration Revocation
> This chapter describes Registration Revocation for Mobile-IP and Proxy Mobile-IP and explains how it is configured. The product administration guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model and configure the required elements for that model, as described in this administration guide before using the procedures in this chapter.
> Important: This license is enabled by default; however, not all features are supported on all platforms and other licenses may be required for full functionality as described in this chapter.
> Overview
> Registration Revocation is a general mechanism whereby either the HA or the FA providing Mobile IP functionality to the same mobile node can notify the other mobility agent of the termination of a binding. This functionality provides the following benefits:

> • | Timely release of Mobile IP resources at the FA and/or HA

> • | Accurate accounting

> • | Timely notification to mobile node of change in service

> Mobile IP Registration Revocation can be triggered at the FA by any of the following:

> • | Session terminated with mobile node for whatever reason

> • | Session renegotiation

> • | Administrative clearing of calls

> • | Session Manager software task outage resulting in the loss of FA sessions (sessions that could not be recovered)

> Important: Registration Revocation functionality is also supported for Proxy Mobile IP. However, only the HA can initiate the revocation for Proxy-MIP calls.
> Mobile IP Registration Revocation can be triggered at the HA by any of the following:

> • | Administrative clearing of calls

> • | Inter-Access Gateway handoff. This releases the binding at the previous access gateway/FA

> • | Session Manager software task outage resulting in the loss of FA sessions (for sessions that could not be recovered)

> • | Session Idle timer expiry (when configured to send Revocation)

> • | Any other condition under which a binding is terminated due to local policy (duplicate IMSI detected, duplicate home address requested, etc.)

> The FA and the HA negotiate Registration Revocation support when establishing a Mobile IP call. Revocation support is indicated to the Mobile Node (MN) from the FA by setting the 'X' bit in the Agent Advertisement to MN. However the MN is not involved in negotiating the Revocation for a call or in the Revocation process. It only gets notified about it. The X bit in the Agent Advertisements is just a hint to the MN that revocation is supported at the FA but is not a guarantee that it can be negotiated with the HA
> At the FA, if revocation is enabled and a FA-HA SPI is configured, the Revocation Support extension is appended to the RRQ received from the MN and protected by the FA-HA Authentication Extension. At the HA, if the RRQ is accepted, and the HA supports revocation, the HA responds with an RRP that includes the Revocation Support extension. Revocation support is considered to be negotiated for a binding when both sides have included a Revocation Support Extension during a successful registration exchange.
> Important: The Revocation Support Extension in the RRQ or RRP must be protected by the FA-HA Authentication Extension. Therefore, an FA-HA SPI must be configured at the FA and the HA for this to succeed.
> If revocation is enabled at the FA, but an FA-HA SPI is not configured at the FA for a certain HA, then FA does not send Revocation Support Extension for a call to that HA. Therefore, the call may come up without Revocation support negotiated.
> If the HA receives an RRQ with Revocation Support Extension, but not protected by FA-HA Auth Extension, it will be rejected with “FA Failed Authentication” error.
> If the FA receives a RRP with Revocation Support Extension, but not protected by FA-HA Auth Extension, it will be rejected with “HA Failed Authentication” error.
> Also note that Revocation support extension is included in the initial, renewal or handoff RRQ/RRP messages. The Revocation extension is not included in a Deregistration RRQ from the FA and the HA will ignore them in any Deregistration RRQs received.
> Configuring Registration Revocation
> Support for MIP Registration Revocation requires the following configurations:

> • | FA service(s): Registration Revocation must be enabled and operational parameters optionally configured.

> • | HA service(s): Registration Revocation must be enabled and operational parameters optionally configured.

> Important: These instructions assume that the system was previously configured to support subscriber data sessions for a core network service with FA and/or an HA according to the instructions described in the respective product Administration Guide.
> Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Configuring FA Services
> Configure FA services to support MIP Registration Revocation by applying the following example configuration:
> configure
> context <context_name>
> fa-service <fa_service_name>
> revocation enable
> revocation max-retransmission <number>
> revocation retransmission-timeout <time>
> end
> Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
> Configuring HA Services
> Configure HA services to support MIP Registration Revocation by applying the following example configuration:
> configure
> context <context_name>
> ha-service <ha_service_name>
> revocation enable
> revocation max-retransmission <number>
> revocation retransmission-timeout <time>
> end
> Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
> Appendix E
> Proxy-Mobile IP
> This chapter describes system support for Proxy Mobile IP and explains how it is configured. The product administration guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model before using the procedures in this chapter.
> Proxy Mobile IP provides a mobility solution for subscribers with mobile nodes (MNs) capable of supporting only Simple IP.
> This chapter includes the following sections:

> • | Overview

> • | How Proxy Mobile IP Works in 3GPP2 Network

> • | How Proxy Mobile IP Works in 3GPP Network

> • | How Proxy Mobile IP Works in WiMAX Network

> • | How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication

> • | Configuring Proxy Mobile-IP Support

> Overview
> Proxy Mobile IP provides mobility for subscribers with MNs that do not support the Mobile IP protocol stack.
> Important: Proxy Mobile IP is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> The Proxy Mobile IP feature is supported for various products. The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.
> Applicable Products and Relevant Sections

> Applicable Product(s) | Refer to Sections
> PDSN |
> • | Proxy Mobile IP in 3GPP2 Service
> • | How Proxy Mobile IP Works in 3GPP2 Network
> • | Configuring FA Services
> • | Configuring Proxy MIP HA Failover
> • | Configuring HA Services
> • | Configuring Subscriber Profile RADIUS Attributes
> • | RADIUS Attributes Required for Proxy Mobile IP
> • | Configuring Local Subscriber Profiles for Proxy-MIP on a PDSN
> • | Configuring Default Subscriber Parameters in Home Agent Context
> GGSN |
> • | Proxy Mobile IP in 3GPP Service
> • | How Proxy Mobile IP Works in 3GPP Network
> • | Configuring FA Services
> • | Configuring Proxy MIP HA Failover
> • | Configuring HA Services
> • | Configuring Subscriber Profile RADIUS Attributes
> • | RADIUS Attributes Required for Proxy Mobile IP
> • | Configuring Default Subscriber Parameters in Home Agent Context
> • | Configuring APN Parameters
> ASN GW |
> • | Proxy Mobile IP in WiMAX Service
> • | How Proxy Mobile IP Works in WiMAX Network
> • | Configuring FA Services
> • | Configuring Proxy MIP HA Failover
> • | Configuring HA Services
> • | Configuring Subscriber Profile RADIUS Attributes
> • | RADIUS Attributes Required for Proxy Mobile IP
> • | Configuring Default Subscriber Parameters in Home Agent Context
> PDIF |
> • | How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication
> • | Configuring FA Services
> • | Configuring Proxy MIP HA Failover
> • | Configuring HA Services
> • | Configuring Subscriber Profile RADIUS Attributes
> • | RADIUS Attributes Required for Proxy Mobile IP
> • | Configuring Default Subscriber Parameters in Home Agent Context

> ‌
> Proxy Mobile IP in 3GPP2 Service
> For subscriber sessions using Proxy Mobile IP, R-P and PPP sessions get established between the MN and the PDSN as they would for a Simple IP session. However, the PDSN/FA performs Mobile IP operations with an HA (identified by information stored in the subscriber’s profile) on behalf of the MN (i.e. the MN is only responsible for maintaining the Simple IP PPP session with PDSN).
> The MN is assigned an IP address by either the PDSN/FA or the HA. Regardless of its source, the address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
> Note that unlike Mobile IP-capable MNs that can perform multiple sessions over a single PPP link, Proxy Mobile IP allows only a single session over the PPP link. In addition, simultaneous Mobile and Simple IP sessions will not be supported for an MN by the FA that is currently facilitating a Proxy Mobile IP session for the MN.
> The MN is assigned an IP address by either the HA, a AAA server, or on a static-basis. The address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
> Proxy Mobile IP in 3GPP Service
> For IP PDP contexts using Proxy Mobile IP, the MN establishes a session with the GGSN as it normally would. However, the GGSN/FA performs Mobile IP operations with an HA (identified by information stored in the subscriber’s profile) on behalf of the MN (i.e. the MN is only responsible for maintaining the IP PDP context with the GGSN, no Agent Advertisement messages are communicated with the MN).
> The MN is assigned an IP address by either the HA, a AAA server, or on a static-basis. The address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
> Proxy Mobile IP can be performed on a per-subscriber basis based on information contained in their user profile, or for all subscribers facilitated by a specific APN. In the case of non-transparent IP PDP contexts, attributes returned from the subscriber’s profile take precedence over the configuration of the APN.
> Proxy Mobile IP in WiMAX Service
> For subscriber sessions using Proxy Mobile subscriber sessions get established between the MN and the ASN GW as they would for a Simple IP session. However, the ASN GW/FA performs Mobile IP operations with an HA (identified by information stored in the subscriber’s profile) on behalf of the MN (i.e. the MN is only responsible for maintaining the Simple IP subscriber session with ASN GW).
> The MN is assigned an IP address by either the ASN GW/FA or the HA. Regardless of its source, the address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
> Note that unlike Mobile IP-capable MNs that can perform multiple sessions over a single session link, Proxy Mobile IP allows only a single session over the session link. In addition, simultaneous Mobile and Simple IP sessions will not be supported for an MN by the FA that is currently facilitating a Proxy Mobile IP session for the MN.
> How Proxy Mobile IP Works in 3GPP2 Network
> This section contains call flows displaying successful Proxy Mobile IP session setup scenarios. There are multiple scenarios that are dependant on how the MN receives an IP address. The following scenarios are described:

> • | Scenario 1: The AAA server that authenticates the MN at the PDSN allocates an IP address to the MN. Note that the PDSN does not allocate an address from its IP pools.

> • | Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.

> Scenario 1: AAA server and PDSN/FA Allocate IP Address
> The following figure and table display and describe a call flow in which the MN receives its IP address from the AAA server and PDSN/FA.
> AAA/PDSN Assigned IP Address Proxy Mobile IP Call Flow
> AAA/PDSN Assigned IP Address Proxy Mobile IP Call Flow Description

> Step | Description
> 1 | Mobile Node (MN) secures a traffic channel over the airlink with the RAN through the BSC/PCF.
> 2 | The PCF and PDSN/FA establish the R-P interface for the session.
> 3 | The PDSN/FA and MN negotiate Link Control Protocol (LCP).
> 4 | Upon successful LCP negotiation, the MN sends a PPP Authentication Request message to the PDSN/FA.
> 5 | The PDSN/FA sends an Access Request message to the RADIUS AAA server.
> 6 | The RADIUS AAA server successfully authenticates the subscriber and returns an Access Accept message to the PDSN/FA. The Accept message may contain various attributes to be assigned to the MN including the MN’s Home Address (IP address) and the IP address of the HA to use.
> 7 | The PDSN/FA sends a PPP Authentication Response message to the MN.
> 8 | The MN sends an Internet Protocol Control Protocol (IPCP) Configuration Request message to the PDSN/FA with an MN address of 0.0.0.0.
> 9 | The PDSN/FA forwards a Proxy Mobile IP Registration Request message to the HA. The message includes fields such as the MN’s home address, the IP address of the FA (the care-of-address), and the FA-HA extension (security parameter index (SPI)).
> 10 | While the FA is communicating with the HA, the MN may send additional IPCP Configuration Request messages.
> 11 | The HA responds with a Proxy Mobile IP Registration Response after validating the home address against it’s pool. The HA also creates a mobile binding record (MBR) for the subscriber session.
> 12 | The MN and the PDSN/FA negotiate IPCP. The result is that the MN is assigned the home address originally specified by the AAA server.
> 13 | While the MN and PDSN/FA are negotiating IPCP, the HA and AAA server initiate accounting.
> 14 | Upon completion of the IPCP negotiation, the PDSN/FA and AAA server initiate accounting fully establishing the session allowing the MN to send/receive data to/from the PDN.
> 15 | Upon completion of the session, the MN sends an LCP Terminate Request message to the PDSN to end the PPP session.
> 16 | The PDSN/FA sends a Proxy Mobile IP De-registration Request message to the HA.
> 17 | The PDSN/FA send an LCP Terminate Acknowledge message to the MN ending the PPP session.
> 18 | The HA sends a Proxy Mobile IP De-Registration Response message to the FA terminating the Pi interface
> 19 | The PDSN/FA and the PCF terminate the R-P session.
> 20 | The HA and the AAA server stop accounting for the session.
> 21 | The PDSN and the AAA server stop accounting for the session.

> ‌
> Scenario 2: HA Allocates IP Address
> The following figure and table display and describe a call flow in which the MN receives its IP address from the HA.
> HA Assigned IP Address Proxy Mobile IP Call Flow
> HA Assigned IP Address Proxy Mobile IP Call Flow Description

> Step | Description
> 1 | Mobile Node (MN) secures a traffic channel over the airlink with the RAN through the BSC/PCF.
> 2 | The PCF and PDSN/FA establish the R-P interface for the session.
> 3 | The PDSN/FA and MN negotiate Link Control Protocol (LCP).
> 4 | Upon successful LCP negotiation, the MN sends a PPP Authentication Request message to the PDSN/FA.
> 5 | The PDSN/FA sends an Access Request message to the RADIUS AAA server.
> 6 | The RADIUS AAA server successfully authenticates the subscriber and returns an Access Accept message to the PDSN/FA. The Accept message may contain various attributes to be assigned to the MN including the IP address of the HA to use.
> 7 | The PDSN/FA sends a PPP Authentication Response message to the MN.
> 8 | The MN sends an Internet Protocol Control Protocol (IPCP) Configuration Request message to the PDSN/FA with an MN address of 0.0.0.0.
> 9 | The PDSN/FA forwards a Proxy Mobile IP Registration Request message to the HA. The message includes fields such as a Home Address indicator of 0.0.0.0, the IP address of the FA (the care-of-address), the IP address of the FA (the care-of-address), and the FA-HA extension (security parameter index (SPI)).
> 10 | While the FA is communicating with the HA, the MN may send additional IPCP Configuration Request messages.
> 11 | The HA responds with a Proxy Mobile IP Registration Response. The response includes an IP address from one of its locally configured pools to assign to the MN (its Home Address). The HA also creates a mobile binding record (MBR) for the subscriber session.
> 12 | The MN and the PDSN/FA negotiate IPCP. The result is that the MN is assigned the home address originally specified by the AAA server.
> 13 | While the MN and PDSN/FA are negotiating IPCP, the HA and AAA server initiate accounting.
> 14 | Upon completion of the IPCP negotiation, the PDSN/FA and AAA server initiate accounting fully establishing the session allowing the MN to send/receive data to/from the PDN.
> 15 | Upon completion of the session, the MN sends an LCP Terminate Request message to the PDSN to end the PPP session.
> 16 | The PDSN/FA sends a Proxy Mobile IP De-registration Request message to the HA.
> 17 | The PDSN/FA send an LCP Terminate Acknowledge message to the MN ending the PPP session.
> 18 | The HA sends a Proxy Mobile IP De-Registration Response message to the FA terminating the Pi interface
> 19 | The PDSN/FA and the PCF terminate the R-P session.
> 20 | The HA and the AAA server stop accounting for the session.
> 21 | The PDSN and the AAA server stop accounting for the session.

> ‌
> How Proxy Mobile IP Works in 3GPP Network
> This section contains call flows displaying successful Proxy Mobile IP session setup scenarios in 3GPP network.
> The following figure and the text that follows describe a a sample successful Proxy Mobile IP session setup call flow in 3GGP service.
> Proxy Mobile IP Call Flow in 3GPP
> Proxy Mobile IP Call Flow in 3GPP Description

> Step | Description
> 1 | The mobile station (MS) goes through the process of attaching itself to the GPRS/UMTS network.
> 2 | The terminal equipment (TE) aspect of the MS sends AT commands to the mobile terminal (MT) aspect of the MS to place it into PPP mode. The Link Control Protocol (LCP is then used to configure the Maximum-Receive Unit size and the authentication protocol (Challenge-Handshake Authentication Protocol (CHAP), Password Authentication Protocol (PAP), or none). If CHAP or PAP is used, the TE will authenticate itself to the MT, which, in turn, stores the authentication information. Upon successful authentication, the TE sends an Internet Protocol Control Protocol (IPCP) Configure-Request message to the MT. The message will either contain a static IP address to use or request that one be dynamically assigned.
> 3 | The MS sends an Activate PDP Context Request message that is received by an SGSN. The message contains information about the subscriber such as the Network layer Service Access Point Identifier (NSAPI), PDP Type, PDP Address, Access Point Name (APN), quality of service (QoS) requested, and PDP configuration options.
> 4 | The SGSN authenticates the request message and sends a Create PDP Context Request message to a GGSN using the GPRS Tunneling Protocol (GTPC, “C” indicates the control signalling aspect of the protocol). The recipient GGSN is selected based on either the request of the MS or is automatically selected by the SGSN. The message consists of various information elements including: PDP Type, PDP Address, APN, charging characteristics, and tunnel endpoint identifier (TEID, if the PDP Address was static).
> 5 | The GGSN determines if it can facilitate the session (in terms of memory or CPU resources, configuration, etc.) and creates a new entry in its PDP context list and provides a Charging ID for the session. From the APN specified in the message, the GGSN determines whether or not the subscriber is to be authenticated, if Proxy Mobile IP is to be supported for the subscriber, and if so, the IP address of the HA to contact. Note that Proxy Mobile IP support can also be determined by attributes in the user’s profile. Attributes in the user’s profile supersede APN settings. If authentication is required, the GGSN attempts to authenticate the subscriber locally against profiles stored in memory or send a RADIUS Access-Request message to a AAA server.
> 6 | If the GGSN authenticated the subscriber to a AAA server, the AAA server responds with a RADIUS Access-Accept message indicating successful authentication and any attributes for handling the subscriber PDP context.
> 7 | If Proxy Mobile IP support was either enabled in the APN or in the subscriber’s profile, the GGSN/FA forwards a Proxy Mobile IP Registration Request message to the specified HA. The message includes such things as the MS’s home address, the IP address of the FA (the care-of-address), and the FA-HA extension (security parameter index (SPI)).
> 8 | The HA responds with a Proxy Mobile IP Registration Response. The response includes an IP address from one of its locally configured pools to assign to the MS (its Home Address). The HA also creates a mobile binding record (MBR) for the subscriber session.
> 9 | The HA sends an RADIUS Accounting Start request to the AAA server which the AAA server responds to.
> 10 | The GGSN replies with an affirmative Create PDP Context Response using GTPC. The response will contain information elements such as the PDP Address representing either the static address requested by the MS or the address assigned by the GGSN, the TEID used to reference PDP Address, and PDP configuration options specified by the GGSN.
> 11 | The SGSN returns an Activate PDP Context Accept message to the MS. The message includes response to the configuration parameters sent in the initial request.
> 12 | The MT, will respond to the TE’s IPCP Config-request with an IPCP Config-Ack message. The MS can now send and receive data to or from the PDN until the session is closed or times out. Note that for Mobile IP, only one PDP context is supported for the MS.
> 13 | The FA periodically sends Proxy Mobile IP Registration Request Renewal messages to the HA. The HA sends responses for each request.
> 14 | The MS can terminate the data session at any time. To terminate the session, the MS sends a Deactivate PDP Context Request message that is received by the SGSN.
> 15 | The SGSN sends a Delete PDP Context Request message to the GGSN facilitating the data session. The message includes the information elements necessary to identify the PDP context (i.e., TEID, and NSAPI).
> 16 | The GGSN removes the PDP context from memory and the FA sends a Proxy Mobile IP Deregistration Request message to the HA.
> 17 | The GGSN returns a Delete PDP Context Response message to the SGSN.
> 18 | The HA replies to the FA with a Proxy Mobile IP Deregistration Request Response.
> 19 | The HA sends an RADIUS Accounting Stop request to the AAA server which the AAA server responds to.
> 20 | The SGSN returns a Deactivate PDP Context Accept message to the MS.
> 21 | The GGSN delivers the GGSN Charging Detail Records (G-CDRs) to a charging gateway (CG) using GTP Prime (GTPP). Note that, though not shown in this example, the GGSN could optionally be configured to send partial CDRs while the PDP context is active.
> 22 | For each accounting message received from the GGSN, the CG responds with an acknowledgement.

> ‌
> How Proxy Mobile IP Works in WiMAX Network
> This section contains call flows displaying successful Proxy Mobile IP session setup scenarios. There are multiple scenarios that are dependant on how the MN receives an IP address. The following scenarios are described:

> • | Scenario 1: The AAA server that authenticates the MN at the ASN GW allocates an IP address to the MN. Note that the ASN GW does not allocate an address from its IP pools.

> • | Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.

> Scenario 1: AAA server and ASN GW/FA Allocate IP Address
> The following figure and table display and describe a call flow in which the MN receives its IP address from the AAA server and ASN GW/FA.
> AAA/ASN GW Assigned IP Address Proxy Mobile IP Call Flow
> AAA/ASN GW Assigned IP Address Proxy Mobile IP Call Flow Description

> Step | Description
> 1 | Mobile Node (MN) secures a traffic channel over the airlink with the BS.
> 2 | The BS and ASN GW/FA establish the R6 interface for the session.
> 3 | The ASN GW/FA and MN negotiate Link Control Protocol (LCP).
> 4 | Upon successful LCP negotiation, the MN sends a PPP Authentication Request message to the ASN GW/FA.
> 5 | The ASN GW/FA sends an Access Request message to the RADIUS AAA server.
> 6 | The RADIUS AAA server successfully authenticates the subscriber and returns an Access Accept message to the ASN GW/FA. The Accept message may contain various attributes to be assigned to the MN including the MN’s Home Address (IP address) and the IP address of the HA to use.
> 7 | The ASN GW/FA sends a EAP Authentication Response message to the MN.
> 8 | The MN sends an Internet Protocol Control Protocol (IPCP) Configuration Request message to the ASN GW/FA with an MN address of 0.0.0.0.
> 9 | The ASN GW/FA forwards a Proxy Mobile IP Registration Request message to the HA. The message includes fields such as the MN’s home address, the IP address of the FA (the care-of-address), and the FA-HA extension (security parameter index (SPI)).
> 10 | While the FA is communicating with the HA, the MN may send additional IPCP Configuration Request messages.
> 11 | The HA responds with a Proxy Mobile IP Registration Response after validating the home address against it’s pool. The HA also creates a mobile binding record (MBR) for the subscriber session.
> 12 | The MN and the ASN GW/FA negotiate IPCP. The result is that the MN is assigned the home address originally specified by the AAA server.
> 13 | While the MN and ASN GW/FA are negotiating IPCP, the HA and AAA server initiate accounting.
> 14 | Upon completion of the IPCP negotiation, the ASN GW/FA and AAA server initiate accounting fully establishing the session allowing the MN to send/receive data to/from the PDN.
> 15 | Upon completion of the session, the MN sends an LCP Terminate Request message to the ASN GW to end the subscriber session.
> 16 | The PDSN/FA sends a Proxy Mobile IP De-registration Request message to the HA.
> 17 | The ASN GW/FA send an LCP Terminate Acknowledge message to the MN ending the subscriber session.
> 18 | The HA sends a Proxy Mobile IP De-Registration Response message to the FA terminating the R3 interface
> 19 | The ASN GW/FA and the BS terminate the R6 session.
> 20 | The HA and the AAA server stop accounting for the session.
> 21 | The ASN GW and the AAA server stop accounting for the session.

> ‌
> Scenario 2: HA Allocates IP Address
> The following figure and table display and describe a call flow in which the MN receives its IP address from the HA.
> HA Assigned IP Address Proxy Mobile IP Call Flow
> HA Assigned IP Address Proxy Mobile IP Call Flow Description

> Step | Description
> 1 | Mobile Node (MN) secures a traffic channel over the airlink with the BS.
> 2 | The BS and ASN GW/FA establish the R6 interface for the session.
> 3 | The ASN GW/FA and MN negotiate Link Control Protocol (LCP).
> 4 | Upon successful LCP negotiation, the MN sends an EAP Authentication Request message to the ASN GW/FA.
> 5 | The ASN GW/FA sends an Access Request message to the RADIUS AAA server.
> 6 | The RADIUS AAA server successfully authenticates the subscriber and returns an Access Accept message to the ASN GW/FA. The Accept message may contain various attributes to be assigned to the MN including the IP address of the HA to use.
> 7 | The ASN GW/FA sends an EAP Authentication Response message to the MN.
> 8 | The MN sends an Internet Protocol Control Protocol (IPCP) Configuration Request message to the ASN GW/FA with an MN address of 0.0.0.0.
> 9 | The ASN GW/FA forwards a Proxy Mobile IP Registration Request message to the HA. The message includes fields such as a Home Address indicator of 0.0.0.0, the IP address of the FA (the care-of-address), the IP address of the FA (the care-of-address), and the FA-HA extension (security parameter index (SPI)).
> 10 | While the FA is communicating with the HA, the MN may send additional IPCP Configuration Request messages.
> 11 | The HA responds with a Proxy Mobile IP Registration Response. The response includes an IP address from one of its locally configured pools to assign to the MN (its Home Address). The HA also creates a mobile binding record (MBR) for the subscriber session.
> 12 | The MN and the ASN GW/FA negotiate IPCP. The result is that the MN is assigned the home address originally specified by the AAA server.
> 13 | While the MN and ASN GW/FA are negotiating IPCP, the HA and AAA server initiate accounting.
> 14 | Upon completion of the IPCP negotiation, the ASN GW/FA and AAA server initiate accounting fully establishing the session allowing the MN to send/receive data to/from the PDN.
> 15 | Upon completion of the session, the MN sends an LCP Terminate Request message to the ASN GW to end the subscriber session.
> 16 | The ASN GW/FA sends a Proxy Mobile IP De-registration Request message to the HA.
> 17 | The ASN GW/FA send an LCP Terminate Acknowledge message to the MN ending the PPP session.
> 18 | The HA sends a Proxy Mobile IP De-Registration Response message to the FA terminating the R3 interface
> 19 | The ASN GW/FA and the BS terminate the R6 session.
> 20 | The HA and the AAA server stop accounting for the session.
> 21 | The ASN GW and the AAA server stop accounting for the session.

> ‌
> How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication
> Proxy-Mobile IP was developed as a result of networks of Mobile Subscribers (MS) that are not capable of Mobile IP operation. In this scenario a PDIF acts a mobile IP client and thus implements Proxy-MIP support.
> Although not required or necessary in a Proxy-MIP network, this implementation uses a technique called Multiple Authentication. In Multi-Auth arrangements, the device is authenticated first using HSS servers. Once the device is authenticated, then the subscriber is authenticated over a RADIUS interface to AAA servers. This supports existing EV-DO servers in the network.
> The MS first tries to establish an IKEv2 session with the PDIF. The MS uses the EAP-AKA authentication method for the initial device authentication using Diameter over SCTP over IPv6 to communicate with HSS servers. After the initial Diameter EAP authentication, the MS continues with EAP MD5/GTC authentication.
> After successful device authentication, PDIF then uses RADIUS to communicate with AAA servers for the subscriber authentication. It is assumed that RADIUS AAA servers do not use EAP methods and hence RADIUS messages do not contain any EAP attributes.
> Assuming a successful RADIUS authentication, PDIF then sets up the IPSec Child SA tunnel using a Tunnel Inner Address (TIA) for passing control traffic only. PDIF receives the MS address from the Home Agent, and passes it on to the MS through the final AUTH response in the IKEv2 exchange.
> When IPSec negotiation finishes, the PDIF assigns a home address to the MS and establishes a CHILD SA to pass data. The initial TIA tunnel is torn down and the IP address returned to the address pool.The PDIF then generates a RADIUS accounting START message.
> When the session is disconnected, the PDIF generates a RADIUS accounting STOP message.
> The following figures describe a Proxy-MIP session setup using CHAP authentication (EAP-MD5), but also addresses a PAP authentication setup using EAP-GTC when EAP-MD5 is not supported by either PDIF or MS.
> Proxy-MIP Call Setup using CHAP Authentication
> Proxy-MIP Call Setup using CHAP Authentication

> Step | Description
> 1 | On connecting to WiFi network, MS first send DNS query to get PDIF IP address
> 2 | MS receives PDIF address from DNS
> 3 | MS sets up IKEv2/IPSec tunnel by sending IKE_SA_INIT Request to PDIF. MS includes SA, KE, Ni, NAT-DETECTION Notify payloads in the IKEv2 exchange.
> 4 | PDIF processes the IKE_SA_INIT Request for the appropriate PDIF service (bound by the destination IP address in the IKEv2 INIT request). PDIF responds with IKE_SA_INIT Response with SA, KE, Nr payloads and NAT-Detection Notify payloads. If multiple-authentication support is configured to be enabled in the PDIF service, PDIF will include MULTIPLE_AUTH_SUPPORTED Notify payload in the IKE_SA_INIT Response. PDIF will start the IKEv2 setup timer after sending the IKE_SA_INIT Response.
> 5 | On receiving successful IKE_SA_INIT Response from PDIF, MS sends IKE_ AUTH Request for the first EAP-AKA authentication. If the MS is capable of doing multiple-authentication, it will include MULTI_AUTH_SUPPORTED Notify payload in the IKE_AUTH Request. MS also includes IDi payload which contains the NAI, SA, TSi, TSr, CP (requesting IP address and DNS address) payloads. MS will not include AUTH payload to indicate that it will use EAP methods.
> 6 | On receiving IKE_AUTH Request from MS, PDIF sends DER message to Diameter AAA server. AAA servers are selected based on domain profile, default subscriber template or default domain configurations. PDIF includes Multiple-Auth-Support AVP, EAP-Payload AVP with EAP-Response/Identity in the DER. Exact details are explained in the Diameter message sections. PDIF starts the session setup timer on receiving IKE_AUTH Request from MS.
> 7 | PDIF receives DEA with Result-Code AVP specifying to continue EAP authentication. PDIF takes EAP-Payload AVP contents and sends IKE_ AUTH Response back to MS in the EAP payload. PDIF allows IDr and CERT configurations in the PDIF service and optionally includes IDr and CERT payloads (depending upon the configuration). PDIF optionally includes AUTH payload in IKE_AUTH Response if PDIF service is configured to do so.
> 8 | MS receives the IKE_AUTH Response from PDIF. MS processes the exchange and sends a new IKE_AUTH Request with EAP payload. PDIF receives the new IKE_AUTH Request from MS and sends DER to AAA server. This DER message contains the EAP-Payload AVP with EAP-AKA challenge response and challenge received from MS.
> 9 | The AAA server sends the DEA back to the PDIF with Result-Code AVP as “success.” The EAP-Payload AVP message also contains the EAP result code with “success.” The DEA also contains the IMSI for the user, which is included in the Callback-Id AVP. PDIF uses this IMSI for all subsequent session management functions such as duplicate session detection etc. PDIF also receives the MSK from AAA, which is used for further key computation.
> 10 | PDIF sends the IKE_AUTH Response back to MS with the EAP payload.
> 11 | MS sends the final IKE_AUTH Request for the first authentication with the AUTH payload computed from the keys. If the MS plans to do the second authentication, it will include ANOTHER_AUTH_FOLLOWS Notify payload also.
> 12 | PDIF processes the AUTH request and responds with the IKE_AUTH Response with the AUTH payload computed from the MSK. PDIF does not assign any IP address for the MS pending second authentication. Nor will the PDIF include any configuration payloads. a. If PDIF service does not support Multiple-Authentication and ANOTHER_AUTH_FOLLOWS Notify payload is received, then PDIF sends IKE_AUTH Response with appropriate error and terminate the IKEv2 session by sending INFORMATIONAL (Delete) Request.b. If ANOTHER_AUTH_FOLLOWS Notify payload is not present in the IKE_AUTH Request, PDIF allocates the IP address from the locally configured pools. However, if proxy-mip-required is enabled, then PDIF initiates Proxy-MIP setup to HA by sending P-MIP RRQ. When PDIF receives the Proxy-MIP RRP, it takes the Home Address (and DNS addresses if any) and sends the IKE_AUTH Response back to MS by including CP payload with Home Address and DNS addresses. In either case, IKEv2 setup will finish at this stage and IPSec tunnel gets established with a Tunnel Inner Address (TIA).
> 13 | MS does the second authentication by sending the IKE_AUTH Request with IDi payload to include the NAI. This NAI may be completely different from the NAI used in the first authentication.
> 14 | On receiving the second authentication IKE_AUTH Request, PDIF checks the configured second authentication methods. The second authentication may be either EAP-MD5 (default) or EAP-GTC. The EAP methods may be either EAP-Passthru or EAP-Terminated. a. If the configured method is EAP-MD5, PDIF sends the IKE_AUTH Response with EAP payload including challenge.b. If the configured method is EAP-GTC, PDIF sends the IKE_AUTH Response with EAP-GTC.c. MS processes the IKE_AUTH Response:
> • | If the MS supports EAP-MD5, and the received method is EAP-MD5, then the MS will take the challenge, compute the response and send IKE_AUTH Request with EAP payload including Challenge and Response.
> • | If the MS does not support EAP-MD5, but EAP-GTC, and the received method is EAP-MD5, the MS sends legacy-Nak with EAP-GTC.
> 15(a) | PDIF receives the new IKE_AUTH Request from MS. If the original method was EAP-MD5 and MD5 challenge and response is received, PDIF sends RADIUS Access Request with corresponding attributes (Challenge, Challenge Response, NAI, IMSI etc.).
> 15(b) | If the original method was EAP-MD5 and legacy-Nak was received with GTC, the PDIF sends IKE_AUTH Response with EAP-GTC.
> 16 | PDIF receives Access Accept from RADIUS and sends IKE_AUTH Response with EAP success.
> 17 | PDIF receives the final IKE_AUTH Request with AUTH payload.
> 18 | PDIF checks the validity of the AUTH payload and initiates Proxy-MIP setup request to the Home Agent if proxy-mip-required is enabled. The HA address may be received from the RADIUS server in the Access Accept (Step 16) or may be locally configured. PDIF may also remember the HA address from the first authentication received in the final DEA message.
> 19 | If proxy-mip-required is disabled, PDIF assigns the IP address from the local pool.
> 20 | PDIF received proxy-MIP RRP and gets the IP address and DNS addresses.
> 21 | PDIF sets up the IPSec tunnel with the home address. On receiving the IKE_AUTH Response MS also sets up the IPSec tunnel using the received IP address. PDIF sends the IKE_AUTH Response back to MS by including the CP payload with the IP address and optionally the DNS addresses. This completes the setup.
> 22 | PDIF sends a RADIUS Accounting start message.

> ‌
> Important: For Proxy-MIP call setup using PAP, the first 14 steps are the same as for CHAP authentication. However, here they deviate because the MS does not support EAP-MD5 authentication, but EAP-GTC. In response to the EAP-MD5 challenge, the MS instead responds with legacy-Nak with EAP-GTC. The diagram below picks up at this point.
> Proxy-MIP Call Setup using PAP Authentication
> Proxy-MIP Call Setup using PAP Authentication

> Step | Description
> 15 | MS is not capable of CHAP authentication but PAP authentication, and the MS returns the EAP payload to indicate that it needs EAP-GTC authentication.
> 16 | PDIF then initiates EAP-GTC procedure, and requests a password from MS.
> 17 | MS includes an authentication password in the EAP payload to PDIF.
> 18 | Upon receipt of the password, PDIF sends a RADIUS Access Request which includes NAI in the User-Name attribute and PAP-password.
> 19 | Upon successful authentication, the AAA server returns a RADIUS Access Accept message, which may include Framed-IP-Address attribute.
> 20 | The attribute content in the Access Accept message is encoded as EAP payload with EAP success when PDIF sends the IKE_AUTH Response to the MS.
> 21 | The MS and PDIF now have a secure IPSec tunnel for communication.
> 22 | Pdif sends an Accounting START message.

> ‌
> Configuring Proxy Mobile-IP Support
> Support for Proxy Mobile-IP requires that the following configurations be made:
> Important: Not all commands and keywords/variables may be supported. This depends on the platform type and the installed license(s).

> • | FA service(s): Proxy Mobile IP must be enabled, operation parameters must be configured, and FA-HA security associations must be specified.

> • | HA service(s): FA-HA security associations must be specified.

> • | Subscriber profile(s): Attributes must be configured to allow the subscriber(s) to use Proxy Mobile IP. These attributes can be configured in subscriber profiles stored locally on the system or remotely on a RADIUS AAA server.

> • | APN template(s): Proxy Mobile IP can be supported for every subscriber IP PDP context facilitated by a specific APN template based on the configuration of the APN.

> Important: These instructions assume that the system was previously configured to support subscriber data sessions as a core network service and/or an HA according to the instructions described in the respective product administration guide.
> Configuring FA Services
> Use this example to configure an FA service to support Proxy Mobile IP:
> configure
> context <context_name>
> fa-service <fa_service_name>
> proxy-mip allow
> proxy-mip max-retransmissions <integer>
> proxy-mip retransmission-timeout <seconds>
> proxy-mip renew-percent-time percentage
> fa-ha-spi remote-address { ha_ip_address | ip_addr_mask_combo } spi-number number { encrypted secret enc_secret | secret secret } [ description string ][ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } | replay-protection { timestamp | nonce } | timestamp-tolerance tolerance ]
> authentication mn-ha allow-noauth
> end
> Notes:

> • | The proxy-mip max-retransmissions command configures the maximum number re-try attempts that the FA service is allowed to make when sending Proxy Mobile IP Registration Requests to the HA.

> • | proxy-mip retransmission-timeout configures the maximum amount of time allowed by the FA for a response from the HA before re-sending a Proxy Mobile IP Registration Request message.

> • | proxy-mip renew-percent-time configures the amount of time that must pass prior to the FA sending a Proxy Mobile IP Registration Renewal Request.

> Example
> If the advertisement registration lifetime configured for the FA service is 900 seconds and the renew-time is configured to 50%, then the FA requests a lifetime of 900 seconds in the Proxy MIP registration request. If the HA grants a lifetime of 600 seconds, then the FA sends the Proxy Mobile IP Registration Renewal Request message after 300 seconds have passed.

> • | Use the fa-ha-spi remote-addresscommand to modify configured FA-HA SPIs to support Proxy Mobile IP. Refer to the Command Line Interface Reference for the full command syntax.

> Important: Note that FA-HA SPIs must be configured for the Proxy-MIP feature to work, while it is optional for regular MIP.

> • | Use the authentication mn-ha allow-noauth command to configure the FA service to allow communications from the HA without authenticating the HA.

> Verify the FA Service Configuration
> Use the following command to verify the configuration of the FA service:
> show fa-service name <fa_service_name>
> Notes:

> • | Repeat this example as needed to configure additional FA services to support Proxy-MIP.

> • | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Proceed to the optional Configuring Proxy MIP HA Failover section to configure Proxy MIP HA Failover support or skip to the Configuring HA Services section to configure HA service support for Proxy Mobile IP.
> Configuring Proxy MIP HA Failover
> Use this example to configure Proxy Mobile IP HA Failover:
> Important: This configuration in this section is optional.
> When configured, Proxy MIP HA Failover provides a mechanism to use a specified alternate Home Agent for the subscriber session when the primary HA is not available. Use the following configuration example to configure the Proxy MIP HA Failover:
> configure
> context <context_name>
> fa-service <fa_service_name>
> proxy-mip ha-failover [ max-attempts <max_attempts> | num-attempts-before-switching <num_attempts> | timeout <seconds> ]
> Notes:

> • | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring HA Services
> Use the following configuration example to configure HA services to support Proxy Mobile IP.
> configure
> context <context_name>
> ha-service <ha_service_name>
> Important: Note that FA-HA SPIs must be configured for the Proxy MIP feature to work while it is optional for regular MIP. Also note that the above syntax assumes that FA-HA SPIs were previously configured as part of the HA service as described in respective product Administration Guide. The replay-protection and timestamp- tolerance keywords should only be configured when supporting Proxy Mobile IP.
> fa-ha-spi remote-address <fa_ip_address> spi-number <number> { encrypted secret <enc_secret> | secret <secret> } [ description <string> ] [ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } ] replay-protection { timestamp | nonce } | timestamp-tolerance <tolerance> ]
> authentication mn-ha allow-noauth
> authentication mn-aaa allow-noauth
> end
> Notes:

> • | Repeat this example as needed to configure additional HA services to support Proxy-MIP.

> • | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> To verify the configuration of the HA service:
> context <context_name>
> show ha-service name <ha_service_name>
> Configuring Subscriber Profile RADIUS Attributes
> In order for subscribers to use Proxy Mobile IP, attributes must be configured in their user profile or in an APN for 3GPP service. As mentioned previously, the subscriber profiles can be located either locally on the system or remotely on a RADIUS AAA server.
> This section provides information on the RADIUS attributes that must be used and instructions for configuring locally stored profiles/APNs in support of Proxy Mobile IP.
> Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.
> RADIUS Attributes Required for Proxy Mobile IP
> The following table describes the attributes that must be configured in profiles stored on RADIUS AAA servers in order for the subscriber to use Proxy Mobile IP.
> Required RADIUS Attributes for Proxy Mobile IP

> Attribute | Description | Values
> SN-Subscriber- Permission OR SN1-Subscriber- Permission | Indicates the services allowed to be delivered to the subscriber. For Proxy Mobile IP, this attribute must be set to Simple IP. |
> • | None (0)
> • | Simple IP (0x01)
> • | Mobile IP (0x02)
> • | Home Agent Terminated Mobile IP (0x04)
> SN-Proxy-MIP OR SN1-Proxy-MIP | Specifies if the configured service will perform compulsory Proxy-MIP tunneling for a Simple-IP subscriber. This attribute must be enabled to support Proxy Mobile IP. |
> • | Disabled - do not perform compulsory Proxy-MIP (0)
> • | Enabled - perform compulsory Proxy-MIP (1)
> SN-Simultaneous- SIP-MIP OR SN1-Simultaneous- SIP-MIP | Indicates whether or not a subscriber can simultaneously access both Simple IP and Mobile IP services. Important: Regardless of the configuration of this attribute, the FA facilitating the Proxy Mobile IP session will not allow simultaneous Simple IP and Mobile IP sessions for the MN. |
> • | Disabled (0)
> • | Enabled (1)
> SN-PDSN-Handoff- Req-IP-Addr OR SN1-PDSN-Handoff- Req-IP-Addr | Specifies whether or not the system should reject and terminate the subscriber session when the proposed address in IPCP by the mobile does not match the existing address that was granted by the chassis during an Inter-chassis handoff. This can be used to disable the acceptance of 0.0.0.0 as the IP address proposed by the MN during the IPCP negotiation that occurs during an Inter-chassis handoff. This attribute is disabled (do not reject) by default. |
> • | Disabled - do not reject (0)
> • | Enabled - reject (1)
> 3GPP2-MIP-HA-Address | This attribute sent in an Access-Accept message specifies the IP Address of the HA. Multiple attributes can be sent in Access Accept. However, only the first two are considered for processing. The first one is the primary HA and the second one is the secondary (alternate) HA used for HA Failover. | IPv4 Address

> ‌
> Configuring Local Subscriber Profiles for Proxy-MIP on a PDSN
> This section provides information and instructions for configuring local subscriber profiles on the system to support Proxy Mobile IP on a PDSN.
> configure
> context <context_name>
> subscriber name <subscriber_name>
> permission pdsn-simple-ip
> proxy-mip allow
> inter-pdsn-handoff require ip-address
> mobile-ip home-agent <ha_address>
> <optional> mobile-ip home-agent <ha_address> alternate
> ip context-name <context_name>
> end
> Verify that your settings for the subscriber(s) just configured are correct.
> show subscribers configuration username <subscriber_name>
> Notes:

> • | Configure the system to enforce the MN’s use of its assigned IP address during IPCP negotiations resulting from inter-PDSN handoffs. Sessions re-negotiating IPCP will be rejected if they contain an address other than that which was granted by the PDSN (i.e. 0.0.0.0). This rule can be enabled by entering the inter-pdsn-handoff require ip-address command.

> • | Optional: If you have enabled the Proxy-MIP HA Failover feature, use the mobile-ip home-agent ha_address alternate command to specify the secondary, or alternate HA.

> • | Repeat this example as needed to configure additional FA services to support Proxy-MIP.

> • | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring Local Subscriber Profiles for Proxy-MIP on a PDIF
> This section provides instructions for configuring local subscriber profiles on the system to support Proxy Mobile IP on a PDIF.
> configure
> context <context-name>
> subscriber name <subscriber_name>
> proxy-mip require
> Note
> subscriber_name is the name of the subscriber and can be from 1 to 127 alpha and/or numeric characters and is case sensitive.
> Configuring Default Subscriber Parameters in Home Agent Context
> It is very important that the subscriber default, configured in the same context as the HA service, has the name of the destination context configured. Use the configuration example below:
> configure
> context <context_name>
> ip context-name <context_name>
> end
> Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
> Configuring APN Parameters
> This section provides instructions for configuring the APN templates to support Proxy Mobile IP for all IP PDP contexts they facilitate.
> Important: This is an optional configuration. In addition, attributes returned from the subscriber’s profile for non-transparent IP PDP contexts take precedence over the configuration of the APN.
> These instructions assume that you are at the root prompt for the Exec mode:
> [local]host_name#

> Step 1 | Enter the configuration mode by entering the following command:

> configure
> The following prompt appears:
> [local]host_name(config)#

> Step 2 | Enter context configuration mode by entering the following command:

> context <context_name>
> context_name is the name of the system destination context designated for APN configuration. The name must be from 1 to 79 alpha and/or numeric characters and is case sensitive.The following prompt appears:
> [<context_name>]host_name(config-ctx)#

> Step 3 | Enter the configuration mode for the desired APN by entering the following command:

> apn <apn_name>
> apn_name is the name of the APN that is being configured. The name must be from 1 to 62 alpha and/or numeric characters and is not case sensitive. It may also contain dots (.) and/or dashes (-).The following prompt appears:
> [<context_name>]host_name(config-apn)#

> Step 4 | Enable proxy Mobile IP for the APN by entering the following command:

> proxy-mip required
> This command causes proxy Mobile IP to be supported for all IP PDP contexts facilitated by the APN.

> Step 5 | Optional. GGSN/FA MN-NAI extension can be skipped in MIP Registration Request by entering following command:

> proxy-mip null-username static-homeaddr
> This command will enables the accepting of MIP Registration Request without NAI extensions in this APN.

> Step 6 | Return to the root prompt by entering the following command:

> end
> The following prompt appears:
> [local]host_name#

> Step 7 | Repeat step 1 through step 6 as needed to configure additional APNs.

> Step 8 | Verify that your APNs were configured properly by entering the following command:

> show apn { all | name <apn_name> }

> Keyword | Description
> | Displays configuration information for all configured APN.
> | Displays configuration information for the APN with the specified name. apn_name is the name of the APN.

> ‌
> The output is a detailed listing of configured APN parameter settings.

> Step 9 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Appendix F
> Traffic Policing and Shaping
> This chapter describes the support of per subscriber Traffic Policing and Shaping feature on Cisco’s Chassis and explains the commands and RADIUS attributes that are used to implement this feature. The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
> Important: Traffic Policing and Shaping is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> This chapter included following procedures:

> • | Overview

> • | Traffic Policing Configuration

> • | Traffic Shaping Configuration

> • | RADIUS Attributes

> Overview
> This section describes the traffic policing and shaping feature for individual subscriber. This feature is comprises of two functions:

> • | Traffic Policing

> • | Traffic Shaping

> Traffic Policing
> Traffic policing enables the configuring and enforcing of bandwidth limitations on individual subscribers and/or APN of a particular traffic class in 3GPP/3GPP2 service.
> Bandwidth enforcement is configured and enforced independently on the downlink and the uplink directions.
> A Token Bucket Algorithm (a modified trTCM) [RFC2698] is used to implement the Traffic-Policing feature. The algorithm used measures the following criteria when determining how to mark a packet:

> • | Committed Data Rate (CDR): The guaranteed rate (in bits per second) at which packets can be transmitted/received for the subscriber during the sampling interval.

> • | Peak Data Rate (PDR): The maximum rate (in bits per second) that subscriber packets can be transmitted/received for the subscriber during the sampling interval.

> • | Burst-size: The maximum number of bytes that can be transmitted/received for the subscriber during the sampling interval for both committed (CBS) and peak (PBS) rate conditions. This represents the maximum number of tokens that can be placed in the subscriber’s “bucket”. Note that the committed burst size (CBS) equals the peak burst size (PBS) for each subscriber.

> The system can be configured to take any of the following actions on packets that are determined to be in excess or in violation:

> • | Drop: The offending packet is discarded.

> • | Transmit: The offending packet is passed.

> • | Lower the IP Precedence: The packet’s ToS bit is set to “0”, thus downgrading it to Best Effort, prior to passing the packet. Note that if the packet’s ToS bit was already set to “0”, this action is equivalent to “Transmit”.

> Traffic Shaping
> Traffic Shaping is a rate limiting method similar to the Traffic Policing, but provides a buffer facility for packets exceeded the configured limit. Once the packet exceeds the data-rate, the packet queued inside the buffer to be delivered at a later time.
> The bandwidth enforcement can be done in the downlink and the uplink direction independently. If there is no more buffer space available for subscriber data system can be configured to either drop the packets or kept for the next scheduled traffic session.
> Traffic Policing Configuration
> Traffic Policing is configured on a per-subscriber basis. The subscribers can either be locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
> In 3GPP service Traffic policing can be configured for subscribers through APN configuration as well.
> Important: In 3GPP service attributes received from the RADIUS server supersede the settings in the APN.
> Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Configuring Subscribers for Traffic Policing
> Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.

> Step 1 | Configure local subscriber profiles on the system to support Traffic Policing by applying the following example configurations:

> Step a | To apply the specified limits and actions to the downlink (data to the subscriber):

> configure
> context <context_name>
> subscriber name <user_name>
> qos traffic-police direction downlink
> end

> Step b | To apply the specified limits and actions to the uplink (data from the subscriber):

> configure
> context <context_name>
> subscriber name <user_name>
> qos traffic-police direction uplink
> end
> Notes:

> • | There are numerous keyword options associated with the qos traffic-police direction { downlink | uplink } command.

> • | Repeat for each additional subscriber to be configured.

> Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.

> Step 2 | Verify the subscriber profile configuration by applying the following example configuration:

> context <context_name>
> show subscriber configuration username <user_name>

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring APN for Traffic Policing in 3GPP Networks
> This section provides information and instructions for configuring APN template’s QoS profile in support of Traffic Policing.
> The profile information is sent to the SGSN(s) in response to GTP Create/Update PDP Context Request messages. If the QoS profile requested by the SGSN is lower than the configured QoS profile configured, the profile requested by the SGSN is used. If the QoS profile requested by the SGSN is higher, the configured rates are used.
> Note that values for the committed-data-rate and peak-data-rate parameters are exchanged in the GTP messages between the GGSN and the SGSN. Therefore, the values used may be lower than the configured values. When negotiating the rate with the SGSN(s), the system convert this to a value that is permitted by GTP as shown in the table below.
> Permitted Values for Committed and Peak Data Rates in GTP Messages

> Value (bps) | Increment Granularity (bps)
> From 1000 to 63,000 | 1,000 (e.g 1000, 2000, 3000, ... 63000)
> From 64,000 to 568,000 | 8,000 (e.g. 64000, 72000, 80000, ... 568000)
> From 576,000 to 8,640,000 | 64,000 (e.g. 576000, 640000, 704000, ... 86400000)
> From 8,700,000 to 16,000,000 | 100,000 bps (e.g. 8700000, 8800000, 8900000, ... 16000000)

> ‌

> Step 1 | Set parameters by applying the following example configurations:

> Step a | To apply the specified limits and actions to the downlink (the Gn direction):

> configure
> context <context_name>
> apn <apn_name>
> qos rate-limit downlink
> end

> Step b | To apply the specified limits and actions to the uplink (the Gi direction):

> configure
> context <context_name>
> apn <apn_name>
> qos rate-limit uplink
> end
> Notes:

> • | There are numerous keyword options associated with qos rate-limit { downlink | uplink } command.

> • | Optionally, configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:

> max-contents primary <number> total <total_number>

> • | Repeat as needed to configure additional Qos Traffic Policing profiles.

> Important: If a “subscribed” traffic class is received, the system changes the class to background and sets the following: The uplink and downlink guaranteed data rates are set to 0. If the received uplink or downlink data rates are 0 and traffic policing is disabled, the default of 64 kbps is used. When enabled, the APN configured values are used. If the configured value for downlink max data rate is larger than can fit in an R4 QoS profile, the default of 64 kbps is used. If either the received uplink or downlink max data rates is non-zero, traffic policing is employed if enabled for the background class. The received values are used for responses when traffic policing is disabled.

> Step 2 | Verify that your APNs were configured properly by entering the following command:

> show apn { all | name <apn_name> }
> The output is a concise listing of configured APN parameter settings.

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Traffic Shaping Configuration
> Traffic Shaping is configured on a per-subscriber basis. The subscribers can either be locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
> In 3GPP service Traffic policing can be configured for subscribers through APN configuration as well.
> Important: In 3GPP, service attributes received from the RADIUS server supersede the settings in the APN.
> Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Configuring Subscribers for Traffic Shaping
> This section provides information and instructions for configuring local subscriber profiles on the system to support Traffic Shaping.
> Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.

> Step 1 | Set parameters by applying the following example configurations:

> Step a | To apply the specified limits and actions to the downlink (data to the subscriber):

> configure
> context <context_name>
> subscriber name <user_name>
> qos traffic-shape direction downlink
> end

> Step b | To apply the specified limits and actions to the uplink (data to the subscriber):

> configure
> context <context_name>
> subscriber name <user_name>
> qos traffic-shape direction uplink
> end
> Notes:

> • | There are numerous keyword options associated with qos traffic-shape direction { downlink | uplink } command.

> • | Repeat for each additional subscriber to be configured.

> Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.

> Step 2 | Verify the subscriber profile configuration by applying the following example configuration:

> context <context_name>
> show subscriber configuration username <user_name>

> Step 3 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> Configuring APN for Traffic Shaping in 3GPP Networks
> This section provides information and instructions for configuring APN template’s QoS profile in support of Traffic Shaping.
> The profile information is sent to the SGSN(s) in response to GTP Create/Update PDP Context Request messages. If the QoS profile requested by the SGSN is lower than the configured QoS profile configured, the profile requested by the SGSN is used. If the QoS profile requested by the SGSN is higher, the configured rates are used.
> Note that values for the committed-data-rate and peak-data-rate parameters are exchanged in the GTP messages between the GGSN and the SGSN. Therefore, the values used may be lower than the configured values. When negotiating the rate with the SGSN(s), the system convert this to a value that is permitted by GTP as shown in the following table.
> Permitted Values for Committed and Peak Data Rates in GTP Messages

> Value (bps) | Increment Granularity (bps)
> From 1000 to 63,000 | 1,000 (e.g 1000, 2000, 3000, ... 63000)
> From 64,000 to 568,000 | 8,000 (e.g. 64000, 72000, 80000, ... 568000)
> From 576,000 to 8,640,000 | 64,000 (e.g. 576000, 640000, 704000, ... 86400000)
> From 8,700,000 to 16,000,000 | 100,000 bps (e.g. 8700000, 8800000, 8900000, ... 16000000)

> ‌

> Step 1 | Set parameters by applying the following example configurations.

> Step a | To apply the specified limits and actions to the downlink (data to the subscriber):

> configure
> context <context_name>
> subscriber name <user_name>
> qos rate-limit downlink
> end

> Step b | To apply the specified limits and actions to the uplink (data to the subscriber):

> configure
> context <context_name>
> apn <apn_name>
> qos rate-limit uplink
> end

> Step 2 | Optional. Configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:

> configure
> context <context_name>
> apn <apn_name>
> max-contexts primary <number> total <total_number>
> end
> Notes:

> • | There are numerous keyword options associated with qos rate-limit direction { downlink | uplink } command.

> For more information on commands, refer Command Line Interface Reference

> • | If the exceed/violate action is set to lower-ip-precedence, this command may override the configuration of the ip qos-dscp command in the GGSN service configuration mode for packets from the GGSN to the SGSN. In addition, the GGSN service ip qos-dscp command configuration can override the APN setting for packets from the GGSN to the Internet. Therefore, it is recommended that command not be used in conjunction with this action.

> • | Repeat as needed to configure additional Qos Traffic Policing profiles.

> • | Note that, if a “subscribed” traffic class is received, the system changes the class to background and sets the following:

> • | The uplink and downlink guaranteed data rates are set to 0.

> • | If the received uplink or downlink data rates are 0 and traffic policing is disabled, the default of 64 kbps is used. When enabled, the APN configured values are used.

> • | If the configured value for downlink max data rate is larger than can fit in an R4 QoS profile, the default of 64 kbps is used.

> • | If either the received uplink or downlink max data rates is non-zero, traffic policing is employed if enabled for the background class. The received values are used for responses when traffic policing is disabled.

> Step 3 | Verify that your APNs were configured properly by entering the following command:

> show apn { all | name <apn_name> }
> The output is a concise listing of configured APN parameter settings.

> Step 4 | Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

> RADIUS Attributes
> Traffic Policing for CDMA Subscribers
> The RADIUS attributes listed in the following table are used to configure Traffic Policing for CDMA subscribers (PDSN, HA) configured on remote RADIUS servers. More information on these attributes can be found in the AAA Interface Administration and Reference.
> RADIUS Attributes Required for Traffic Policing Support for CDMA Subscribers

> Attribute | Description
> SN-QoS-Tp-Dnlk (or SN1-QoS-Tp-Dnlk) | Enable/disable traffic policing in the downlink direction.
> SN-Tp-Dnlk-Committed-Data-Rate (or SN1-Tp-Dnlk-Committed-Data-Rate) | Specifies the downlink committed-data-rate in bps.
> SN-Tp-Dnlk-Peak-Data-Rate (or SN1-Tp-Dnlk-Committed-Data-Rate) | Specifies the downlink peak-data-rate in bps.
> SN-Tp-Dnlk-Burst-Size (or SN1-Tp-Dnlk-Burst-Size) | Specifies the downlink-burst-size in bytes. NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
> SN-Tp-Dnlk-Exceed-Action (or SN1-Tp-Dnlk-Exceed-Action) | Specifies the downlink exceed action to perform.
> SN-Tp-Dnlk-Violate-Action (or SN1-Tp-Dnlk-Violate-Action) | Specifies the downlink violate action to perform.
> SN-QoS-Tp-Uplk (or SN1-QoS-Tp-Uplk) | Enable/disable traffic policing in the downlink direction.
> SN-Tp-Uplk-Committed-Data-Rate (or SN1-Tp-Uplk-Committed-Data-Rate) | Specifies the uplink committed-data-rate in bps.
> SN-Tp-Uplk-Peak-Data-Rate (or SN1-Tp-Uplk-Committed-Data-Rate) | Specifies the uplink peak-data-rate in bps.
> SN-Tp-Uplk-Burst-Size (or SN1-Tp-Uplk-Burst-Size) | Specifies the uplink-burst-size in bytes. NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
> SN-Tp-Uplk-Exceed-Action (or SN1-Tp-Uplk-Exceed-Action) | Specifies the uplink exceed action to perform.
> SN-Tp-Uplk-Violate-Action (or SN1-Tp-Uplk-Violate-Action) | Specifies the uplink violate action to perform.

> ‌
> Traffic Policing for UMTS Subscribers
> The RADIUS attributes listed in the following table are used to configure Traffic Policing for UMTS subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Interface Administration and Reference.
> RADIUS Attributes Required for Traffic Policing Support for UMTS Subscribers

> Attribute | Description
> SN-QoS-Conversation-Class (or SN1-QoS-Conversation-Class) | Specifies the QOS Conversation Traffic Class.
> SN-QoS-Streaming-Class (or SN1-QoS-Streaming-Class) | Specifies the QOS Streaming Traffic Class.
> SN-QoS-Interactive1-Class (or SN1-QoS-Interactive1-Class) | Specifies the QOS Interactive Traffic Class.
> SN-QoS-Interactive2-Class (or SN1-QoS-Interactive2-Class) | Specifies the QOS Interactive2 Traffic Class.
> SN-QoS-Interactive3-Class (or SN1-QoS-Interactive3-Class) | Specifies the QOS Interactive3 Traffic Class.
> SN-QoS-Background-Class (or SN1-QoS-Background-Class) | Specifies the QOS Background Traffic Class.
> SN-QoS-Traffic-Policy (or SN1-QoS-Traffic-Policy) | This compound attribute simplifies sending QoS values for Traffic Class (the above attributes), Direction, Burst-Size, Committed-Data-Rate, Peak-Data-Rate, Exceed-Action, and Violate-Action from the RADIUS server. This attribute can be sent multiple times for different traffic classes. If Class is set to 0, it applies across all traffic classes.

> ‌
> Appendix G
> Sample Configuration Files
> This appendix contains sample configuration files for the HSGW. The following configurations are supported:

> • | Standalone eHRPD Serving Gateway

> In each configuration example, commented lines are labeled with the number symbol (#) and variables are identified using italics within brackets (<variable>).
> Standalone eHRPD Serving Gateway
> The configuration sample contained in this section contains example configurations described in the System Administration Guide and the eHRPD Serving Gateway Administration Guide. Descriptions of all commands contained herein can be found in the Command Line Interface Reference.
> Configuration Sample
> # Configuration file for ST40 in HSGW role
> #
> # Send HSGW licenses
> configure /flash/flashconfig/<hsgw_license_name>.cfg
> end
> #
> # Set system to not require confirmation when creating new contexts and/or services. Config file must end with “no autoconfirm” to return the CLI to its default setting.
> #
> configure
> autoconfirm
> #
> # Configure ST40 cards
> #
> # Activate the PSCs
> card <slot_number>
> mode active psc
> exit
> card <slot_number>
> mode active psc
> exit
> # Repeat for the number of PSCs in the system
> end
> #
> # Modify the local context for local system management
> config
> context local
> interface <name>
> ip address <address> <mask>
> exit
> server ftpd
> exit
> ssh key <key> length <bytes>
> server sshd
> subsystem sftp
> exit
> server telnetd
> exit
> subscriber default
> exit
> administrator <name> encrypted password <password> ftp
> aaa group default
> exit
> administrator <name> encrypted password <password> ftp
> ip route <ip_addr/ip_mask> <next_hop_addr> <lcl_cntxt_intrfc_name>
> exit
> port ethernet <slot#/port#>
> no shutdown
> bind interface <lcl_cntxt_intrfc_name> local
> exit
> ntp
> enable
> server 10.2.10.2
> exit
> snmp engine-id local <id>
> snmp notif-threshold <count> low <low_count> period <seconds>
> snmp authentication-failure-trap
> snmp heartbeat interval <minutes>
> snmp community <string> read-write
> snmp target <name> <ip_address>
> system contact <string>
> system location <string>
> rohc-profile profile-name <name>
> common-options
> delay-release-hc-context-timer <seconds>
> inactive-traffic-release-hc-context-timer <seconds>
> exit
> exit
> # HSGW context
> context <hsgw_context_name>
> interface <a10-a11_interface_name>
> ip address <ip_address>
> exit
> ip domain-lookup
> ip name-servers <ipv4_or_ipv6_address>
> dns-client <name>
> policy accounting <rf_acct_policy_name>
> accounting-level {type}
> operator-string <string>
> exit
> hsgw-service <hsgw_service_name>
> associate accounting-policy <acct_policy_name>
> spi remote-address <ip_address> spi-number <num> encrypted secret <secret>
> plmn id mcc <number> mnc <number>
> fqdn <domain_name>
> gre sequence-mode recorder
> gre flow-control action resume-session timeout <msecs>
> gre segmentation
> unauthorized-flows qos-update wait-timeout <seconds>
> ip header-compression rohc
> bind address <a10-a11_interface_address>
> exit
> exit
> # MAG context
> context <hsgw_context_name>
> interface <s2a_interface_name>
> ip address <ipv6_address>
> exit
> mag-servics <mag_service_name> -noconfirm
> information-element-set custom1
> bind address <s2a_interface_address>
> exit
> exit
> # AAA and policy
> context <aaa_context_name>
> interface <aaa_sta_ipv4_interface_name>
> ip address <ipv4_address>
> exit
> interface <pcrf_gxa_ipv6_interface_name>
> ip address <ipv6_address>
> exit
> interface <ocs_rf_ipv4_interface_name>
> ip address <ipv4_address>
> exit
> subscriber default
> ims-auth-service <gxa_ims_service_name>
> rohc-profile-name <name>
> exit
> aaa group default
> radius accounting interim interval <seconds>
> diameter accounting dictionary <name>
> diameter authentication dictionary <name>
> diameter accounting endpoint <rf_ofcs_server>
> diameter authentication endpoint <sta_cfg_name>
> diameter accounting server <rf_ofcs_server> priority <num>
> diameter authentication server <sta_cfg_name> priority <num>
> exit
> ims-auth-service <gxa_ims_service_name>
> policy-control
> diameter origin endpoint <gxa_cfg_name>
> diameter dictionary <gxa_dictionry_name>
> diameter host-select table <#> algorithm round-robin
> diameter host-select row-precedence <#> table <#> host <gxa_cfg_name>
> exit
> exit
> diameter endpoint <sta_cfg_name>
> origin realm <realm_name>
> origin host <name> address <aaa_ctx_ipv4_address>
> peer <sta_cfg_name> realm <name> address <aaa_ipv4_address>
> route-entry peer <sta_cfg_name>
> exit
> diameter endpoint <gxa_cfg_name>
> origin realm <realm_name>
> origin host <name> address <aaa_ctx_ipv6_address>
> peer <gxa_cfg_name> realm <name> address <pcrf_ip_addr> port <#>
> route-entry peer <gxa_cfg_name>
> end
> diameter endpoint <rf_cfg_name>
> origin realm <realm_name>
> origin host <name> address <aaa_ctx_ipv4_address>
> peer <rf_cfg_name> realm <name> address <ocs_ip_addr> port <#>
> route-entry peer <rf_cfg_name>
> exit
> exit
> # QCI-QoS mapping
> qci-qos-mapping <name>
> qci 1 user-datagram dscp-marking <hex>
> qci 3 user-datagram dscp-marking <hex>
> qci 9 user-datagram dscp-marking <hex>
> end
> Appendix H
> HSGW Engineering Rules
> This appendix provides HRPD Serving Gateway-specific engineering rules or guidelines that must be considered prior to configuring the system for your network deployment. General and network-specific rules are located in the appendix of the System Administration Guide for the specific network type.
> The following rules are covered in this appendix:

> • | Interface and Port Rules

> • | HSGW Service Rules

> • | HSGW Subscriber Rules

> Interface and Port Rules
> The rules discussed in this section pertain to the Ethernet 10/100 line card, the Ethernet 1000 line card and the four-port Quad Gig-E line card and the type of interfaces they facilitate, regardless of the application.
> A10/A11 Interface Rules
> The following engineering rules apply to the A10/A11 interface:

> • | An A10/A11 interface is created once the IP address of a logical interface is bound to an HSGW service.

> • | The logical interface(s) that will be used to facilitate the A10/A11 interface(s) must be configured within an “ingress” context.

> • | HSGW services must be configured within an “ingress” context.

> • | At least one HSGW service must be bound to each interface; however, multiple HSGW services can be bound to a single interface if secondary addresses are assigned to the interface.

> • | Each HSGW service must be configured with the Security Parameter Index (SPI) of the Evolved Packet Control Function (ePCF) that it will be communicating with over the A10/A11 interface.

> • | Multiple SPIs can be configured within the HSGW service to allow communications with multiple ePCFs over the A10/A11 interface. It is best to define SPIs using a netmask to specify a range of addresses rather than entering separate SPIs. This assumes that the network is physically designed to allow this communication.

> • | Depending on the services offered to the subscriber, the number of sessions facilitated by the A10/A11 interface can be limited.

> S2a Interface Rules
> This section describes the engineering rules for the S2a interface for communications between the Mobility Access Gateway (MAG) service residing on the HSGW and the Local Mobility Anchor (LMA) service residing on the P-GW.
> MAG to LMA Rules
> The following engineering rules apply to the S2a interface from the MAG service to the LMA service residing on the P-GW:

> • | An S2a interface is created once the IP address of a logical interface is bound to an MAG service.

> • | The logical interface(s) that will be used to facilitate the S2a interface(s) must be configured within the egress context.

> • | MAG services must be configured within the egress context.

> • | MAG services must be associated with an HSGW service.

> • | Depending on the services offered to the subscriber, the number of sessions facilitated by the S2a interface can be limited.

> HSGW Service Rules
> The following engineering rules apply to services configured within the system:

> • | A maximum of 256 services (regardless of type) can be configured per system.

> Caution: Large numbers of services greatly increase the complexity of management and may impact overall system performance (i.e. resulting from such things as system handoffs). Therefore, it is recommended that a large number of services only be configured if your application absolutely requires it. Please contact your local service representative for more information.

> • | Up to 2,048 Security Parameter Indices (SPIs) can be configured for a single HSGW service.

> • | Up to 2,048 MAG-LMA SPIs can be supported for a single HSGW service.

> • | The system maintains statistics for a maximum of 4096 peer LMAs per MAG service.

> • | The total number of entries per table and per chassis is limited to 256.

> • | Even though service names can be identical to those configured in different contexts on the same system, this is not a good practice. Having services with the same name can lead to confusion, difficulty troubleshooting problems, and make it difficulty understanding outputs of show commands.

> HSGW Subscriber Rules
> The following engineering rule applies to subscribers configured within the system:

> • | A maximum of 2,048 local subscribers can be configured per context.

> • | Default subscriber templates may be configured on a per HSGW or MAG service.

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