> Engineering Rules
> This section provides engineering rules or guidelines that must be considered prior to configuring the system for your network deployment.
> This appendix describes following engineering rules for GGSN service:

> • | APN Engineering Rules

> • | DHCP Service Engineering Rules

> • | GGSN Engineering Rules

> • | GRE Tunnel Interface and VRF Engineering Rules

> • | GTP Engineering Rules

> • | Interface and Port Engineering Rules

> • | Lawful Intercept Engineering Rules

> • | MBMS Bearer Service Engineering Rules

> • | Service Engineering Rules

> • | Subscriber Engineering Rules

> APN Engineering Rules
> The following engineering rules apply to APNs:

> • | APNs must be configured within the context used for authentication.

> • | A maximum of 1,024 APNs per system can be configured.

> DHCP Service Engineering Rules
> The following engineering rule applies to the DHCP Service:

> • | Up to 8 DHCP servers may be configured per DHCP service.

> • | A maximum of 3 DHCP server can be tried for a call.

> GGSN Engineering Rules
> The following engineering rules apply when the system is configured as a GGSN:

> • | Gn/Gp interfaces can be configured. That is, if a system context is configured with a GGSN service, then all interfaces in that context may be used.

> • | Gi interfaces can be configured. That is, if a system context is configured as a destination context for an APN, then all interfaces in that context may be used.

> • | Ga interfaces. That is, if a system context is configured for GTPP accounting, then all interfaces in that context may be used.

> • | One GSN-MAP node may be configured per system context (in lieu of Gc).

> • | Up to 1000 network requested PDP contexts may be configured.

> • | Up to 8 GTPP groups (excluding the default GTPP group) can be configured per chassis.

> • | Up to 4 GTPP Storage Servers can be configured per GTPP group.

> • | Up to 32 GTPP Storage Servers can be configured per system context.

> • | Up to 511 GRE tunnel interface can be configured per context.

> GRE Tunnel Interface and VRF Engineering Rules
> The following engineering rules apply to GRE tunnel interface and VRF contexts:

> • | A maximum of 511 GRE tunnels are allowed to configure in a context but subject to maximum of 2048 GRE tunnels per chassis.

> • | A maximum of 250 virtual routing and forwarding (VRF) tables are allowed to configure in a context subject to a maximum of 1024 VRFs per chassis.

> • | A maximum of 10000 IP routes in Release 9.0 and 16384 IP routes in Release 10.0 onward are supported in a VRF context configuration mode.

> GTP Engineering Rules
> The following engineering rules apply to GTP on GGSN:

> • | A maximum of 11 primary (no secondary) PDP context per subscriber can be configured.

> • | A maximum of 1 primary and 10 secondary PDP context per subscriber can be configured.

> Interface and Port Engineering Rules
> The rules discussed in this section pertain to both the Ethernet 10/100 and Ethernet 1000 Line Cards and the four-port Quad Gig-E Line Card (QGLC; ASR 5000 only) and the type of interfaces they facilitate.
> Pi Interface Rules
> This section describes the engineering rules for the Pi interface.
> FA to HA Rules
> When supporting Mobile IP, the system can be configured to perform the role of an FA, an HA, or both. This section describes the engineering rules for the Pi interface when using the system as a FA.
> The following engineering rules apply to the Pi interface between the FA and HA:

> • | A Pi interface is created once the IP address of a logical interface is bound to an FA service.

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

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

> • | If the system is configured as a FA is communicating with a system configured as an HA, then it is recommended that the name of the context in which the FA service is configured is identical to the name of the context that the HA service is configured in on the other system.

> • | Each FA service may be configured with the Security Parameter Index (SPI) of the HA that it will be communicating with over the Pi interface.

> • | Multiple SPIs can be configured within the FA service to allow communications with multiple HAs over the Pi 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 Pi interface can be limited.

> HA to FA
> The following engineering rules apply to the Pi interface between the HA and FA:

> • | When supporting Mobile IP, the system can be configured to perform the role of a FA, an HA or both. This section describes the engineering rules for the Pi interface when using the system as an HA.

> • | A Pi interface is created once the IP address of a logical interface is bound to an HA service.

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

> • | HA services must be configured within an ingress context.

> • | If the system configured as an HA is communicating with a system configured as a FA, then it is recommended that the name of the context in which the HA service is configured is identical to the name of the context that the FA service is configured in on the other system.

> • | Each HA service may be configured with the Security Parameter Index (SPI) of the FA that it will be communicating with over the Pi interface.

> • | Multiple SPIs can be configured within the HA service to allow communications with multiple FAs over the Pi 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.

> • | Each HA service must be configured with a Security Parameter Index (SPI) that it will share with mobile nodes.

> • | Depending on the services offered to the subscriber, the number of sessions facilitated by the Pi interface can be limited in order to allow higher bandwidth per subscriber.

> GRE Tunnel Interface Rule
> The following engineering rules apply to the GRE tunnel interface between two GRE tunnel nodes:

> • | A maximum of 512 IP tunnels (511 GRE tunnels + 1 not tunnel interfaces) are allowed to configure in a context but subject to a maximum of 2048 GRE tunnels per chassis.

> Lawful Intercept Engineering Rules
> The following engineering rules apply to Lawful Intercept on supported AGW service:

> • | A maximum of 1000 Lawful Intercepts can be performed simultaneously.

> MBMS Bearer Service Engineering Rules
> The following engineering rules apply to MBMS bearer services:

> • | A maximum 225 downlink SGSNs per MBMS bearer service are supported on ASR 5000.

> • | A maximum of 2 BMSC (1 primary and 1 secondary) supported per MBMS bearer service.

> Service Engineering 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 MN-HA and 2048 FA-HA SPIs can be supported for a single HA service.

> • | Up to 2,048 FA-HA SPIs can be supported for a single FA service.

> • | The system supports unlimited peer FA addresses per HA.

> • | The system maintains statistics for a maximum of 8192 peer FAs per HA service.

> • | If more than 8192 FAs are attached, older statistics are identified and overwritten.

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

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

> • | Up to 10,000 LAC addresses can be configured per LNS service.

> Caution: 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 in troubleshooting the problems, and make it difficult to understand outputs of show commands.
> Subscriber Engineering Rules
> The following engineering rule applies to subscribers configured within the service:

> • | Default subscriber templates may be configured on a per FA service basis.

> Appendix A
> CoA, RADIUS DM, and Session Redirection (Hotlining)
> This chapter describes Change of Authorization (CoA), Disconnect Message (DM), and Session Redirect (Hotlining) support in the system. RADIUS attributes, Access Control Lists (ACLs) and filters that are used to implement these features are discussed. 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: Not all commands and keywords/variables are available or supported. This depends on the platform type and the installed license(s).
> Licensing
> This feature requires the following license to be installed on the chassis:
> Cisco PID [ ASR5K-00-CSXXDYNR ] Dynamic Radius Extensions (CoA and PoD), or Starent Part Number [ 600-00-7518 ] Dynamic Radius Extensions (CoA and PoD).
> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> RADIUS Change of Authorization and Disconnect Message
> This section describes how the system implements CoA and DM RADIUS messages and how to configure the system to use and respond to CoA and DM messages.
> CoA Overview
> The system supports CoA messages from the AAA server to change data filters associated with a subscriber session. The CoA request message from the AAA server must contain attributes to identify NAS and the subscriber session and a data filter ID for the data filter to apply to the subscriber session. The filter-id attribute (attribute ID 11) contains the name of an Access Control List (ACL). For detailed information on configuring ACLs, refer to the IP Access Control Lists chapter in the Cisco ASR 5000 Series System Administration Guide.
> If the system successfully executes a CoA request, a CoA-ACK message is sent back to the RADIUS server and the data filter is applied to the subscriber session. Otherwise, a CoA-NAK message is sent with an error-cause attribute without making any changes to the subscriber session.
> Important: Changing ACL and rulebase together in a single CoA is not supported. For this, two separate CoA requests can be sent through AAA server requesting for one attribute change per request.
> DM Overview
> The DM message is used to disconnect subscriber sessions in the system from a RADIUS server. The DM request message should contain necessary attributes to identify the subscriber session. If the system successfully disconnects the subscriber session, a DM-ACK message is sent back to the RADIUS server, otherwise, a DM-NAK message is sent with proper error reasons.
> Enabling CoA and DM
> To enable RADIUS Change of Authorization and Disconnect Message:

> Step 1 | Enable the system to listen for and respond to CoA and DM messages from the RADIUS server as described in the Enabling CoA and DM section.

> Step 2 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Step 3 | View CoA and DM message statistics as described in the Viewing CoA and DM Statistics section.

> Important: Commands used in the configuration examples 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 Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands. Not all commands and keywords/variables are available or supported. This depends on the platform type and the installed license(s).
> Enabling CoA and DM
> Use the following example to enable the system to listen for and respond to CoA and DM messages from the RADIUS server:
> configure
> context <context_name>
> radius change-authorize-nas-ip <ipv4/ipv6_address>
> end
> Notes:

> • | <context_name> must be the name of the AAA context where you want to enable CoA and DM. The AAA context must have been configured as described in the Configuring Context-Level AAA Functionality section of the Cisco ASR 5000 Series AAA and GTP Interface Administration and Reference.

> • | A number of optional keywords and variables are available for the radius change-authorize-nas-ip command. For more information regarding this command please refer to the Cisco ASR 5000 Series Command Line Interface Reference.

> CoA and DM Attributes
> For CoA and DM messages to be accepted and acted upon, the system and subscriber session to be affected must be identified correctly.
> To identify the system, use any one of the following attributes:

> • | NAS-IP-Address: NAS IP address if present in the CoA/DM request should match with the NAS IP address.

> • | NAS-Identifier: If this attribute is present, its value should match to the nas-identifier generated for the subscriber session

> To identify the subscriber session, use any one of the following attributes.

> • | If 3GPP2 service is configured the following attribute is used for correlation identifier:

> • | 3GPP2-Correlation-ID: The values should exactly match the 3GPP2-correlation-id of the subscriber session. This is one of the preferred methods of subscriber session identification.

> • | If 3GPP service is configured the following attributes are used for different identifiers:

> • | 3GPP-IMSI: International Mobile Subscriber Identification (IMSI) number should be validated and matched with the specified IMSI for specific PDP context.

> • | 3GPP-NSAPI: Network Service Access Point Identifier (NSAPI) should match to the NSAPI specified for specific PDP context.

> • | User-Name: The value should exactly match the subscriber name of the session. This is one of the preferred methods of subscriber session identification.

> • | Framed-IP-Address: The values should exactly match the framed IP address of the session.

> • | Calling-station-id: The value should match the Mobile Station ID.

> To specify the ACL to apply to the subscriber session, use the following attribute:

> • | Filter-ID: CoA only. This must be the name of an existing Access Control List. If this is present in a CoA request, the specified ACL is immediately applied to the specified subscriber session. The Context Configuration mode command, radius attribute filter-id direction, controls in which direction filters are applied.

> The following attributes are also supported:

> • | Event-Timestamp: This attribute is a timestamp of when the event being logged occurred.

> • | If 3GPP2 service is configured following additional attributes are supported:

> • | 3GPP2-Disconnect-Reason: This attribute indicates the reason for disconnecting the user. This attribute may be present in the RADIUS Disconnect-request Message from the Home Radius server to the PDSN.

> • | 3GPP2-Session-Termination-Capability: When CoA and DM are enabled by issuing the radius change-authorize-nas-ip command, this attribute is included in a RADIUS Access-request message to the Home RADIUS server and contains the value 3 to indicate that the system supports both Dynamic authorization with RADIUS and Registration Revocation for Mobile IPv4. The attribute is also included in the RADIUS Access-Accept message and contains the preferred resource management mechanism by the home network, which is used for the session and may include values 1 through 3.

> CoA and DM Error-Cause Attribute
> The Error-Cause attribute is used to convey the results of requests to the system. This attribute is present when a CoA or DM NAK or ACK message is sent back to the RADIUS server.
> The value classes of error causes are as follows:

> • | 0-199, 300-399 reserved

> • | 200-299 - successful completion

> • | 400-499 - errors in RADIUS server

> • | 500-599 - errors in NAS/Proxy

> The following error cause is sent in ACK messages upon successful completion of a CoA or DM request:

> • | 201- Residual Session Context Removed

> The following error causes are sent in NAK messages when a CoA or DM request fails:

> • | 401 - Unsupported Attribute

> • | 402 - Missing Attribute

> • | 403 - NAS Identification Mismatch

> • | 404 - Invalid Request

> • | 405 - Unsupported Service

> • | 406 - Unsupported Extension

> • | 501 - Administratively Prohibited

> • | 503 - Session Context Not Found

> • | 504 - Session Context Not Removable

> • | 506 - Resources Unavailable

> Viewing CoA and DM Statistics
> View CoA and DM message statistics by entering the following command:
> show session subsystem facility aaamgr
> The following is a sample output of this command.
> 1 AAA Managers
> 807 Total aaa requests 0 Current aaa requests
> 379 Total aaa auth requests 0 Current aaa auth requests
> 0 Total aaa auth probes 0 Current aaa auth probes
> 0 Total aaa auth keepalive 0 Current aaa auth keepalive
> 426 Total aaa acct requests 0 Current aaa acct requests
> 0 Total aaa acct keepalive 0 Current aaa acct keepalive
> 379 Total aaa auth success 0 Total aaa auth failure
> 0 Total aaa auth purged 0 Total aaa auth cancelled
> 0 Total auth keepalive success 0 Total auth keepalive failure
> 0 Total auth keepalive purged
> 0 Total aaa auth DMU challenged
> 367 Total radius auth requests 0 Current radius auth requests
> 2 Total radius auth requests retried
> 0 Total radius auth responses dropped
> 0 Total local auth requests 0 Current local auth requests
> 12 Total pseudo auth requests 0 Current pseudo auth requests
> 0 Total null-username auth requests (rejected)
> 0 Total aaa acct completed 0 Total aaa acct purged
> 0 Total acct keepalive success 0 Total acct keepalive timeout
> 0 Total acct keepalive purged
> 0 Total aaa acct cancelled
> 426 Total radius acct requests 0 Current radius acct requests
> 0 Total radius acct requests retried
> 0 Total radius acct responses dropped
> 0 Total gtpp acct requests 0 Current gtpp acct requests
> 0 Total gtpp acct cancelled 0 Total gtpp acct purged
> 0 Total null acct requests 0 Current null acct requests
> 54 Total aaa acct sessions 5 Current aaa acct sessions
> 3 Total aaa acct archived 0 Current aaa acct archived
> 0 Current recovery archives 0 Current valid recovery records
> 2 Total aaa sockets opened 2 Current aaa sockets open
> 0 Total aaa requests pend socket open
> 0 Current aaa requests pend socket open
> 0 Total radius requests pend server max-outstanding
> 0 Current radius requests pend server max-outstanding
> 0 Total aaa radius coa requests 0 Total aaa radius dm requests
> 0 Total aaa radius coa acks 0 Total aaa radius dm acks
> 0 Total aaa radius coa naks 0 Total aaa radius dm naks
> 2 Total radius charg auth 0 Current radius charg auth
> 0 Total radius charg auth succ 0 Total radius charg auth fail
> 0 Total radius charg auth purg 0 Total radius charg auth cancel
> 0 Total radius charg acct 0 Current radius charg acct
> 0 Total radius charg acct succ 0 Total radius charg acct purg
> 0 Total radius charg acct cancel
> 357 Total gtpp charg 0 Current gtpp charg
> 357 Total gtpp charg success 0 Total gtpp charg failure
> 0 Total gtpp charg cancel 0 Total gtpp charg purg
> 0 Total prepaid online requests 0 Current prepaid online requests
> 0 Total prepaid online success 0 Current prepaid online failure
> 0 Total prepaid online retried 0 Total prepaid online cancelled
> 0 Current prepaid online purged
> 0 Total aaamgr purged requests
> 0 SGSN: Total db records
> 0 SGSN: Total sub db records
> 0 SGSN: Total mm records
> 0 SGSN: Total pdp records
> 0 SGSN: Total auth records
> Session Redirection (Hotlining)
> Overview
> Session redirection provides a means to redirect subscriber traffic to an external server by applying ACL rules to the traffic of an existing or a new subscriber session. The destination address and optionally the destination port of TCP/IP or UDP/IP packets from the subscriber are rewritten so the packet is forwarded to the designated redirected address. Return traffic to the subscriber has the source address and port rewritten to the original values. The redirect ACL may be applied dynamically by means of the RADIUS Change of Authorization (CoA) feature.
> Note that the session redirection feature is only intended to redirect a very small subset of subscribers at any given time. The data structures allocated for this feature are kept to the minimum to avoid large memory overhead in the session managers.
> Operation
> ACL Rule
> An ACL rule named readdress server supports redirection of subscriber sessions. The ACL containing this rule must be configured in the destination context of the user. Only TCP and UDP protocol packets are supported. The ACL rule allows specifying the redirected address and an optional port. The source and destination address and ports (with respect to the traffic originating from the subscriber) may be wildcarded. If the redirected port is not specified, the traffic will be redirected to the same port as the original destination port in the datagrams. For detailed information on configuring ACLs, refer to the IP Access Control Lists chapter in the Cisco ASR 5000 Series System Administration Guide. For more information on readdress server, refer to the ACL Configuration Mode Commands chapter of the Cisco ASR 5000 Series Command Line Interface Reference.
> Redirecting Subscriber Sessions
> An ACL with the readdress server rule is applied to an existing subscriber session through CoA messages from the RADIUS server. The CoA message contains the 3GPP2-Correlation-ID, User-Name, Acct-Session-ID, or Framed-IP-Address attributes to identify the subscriber session. The CoA message also contains the Filter-Id attribute which specifies the name of the ACL with the readdress server rule. This enables applying the ACL dynamically to existing subscriber sessions. By default, the ACL is applied as both the input and output filter for the matching subscriber unless the Filter-Id in the CoA message bears the prefix in: or out:.
> For information on CoA messages and how they are implemented in the system, refer to the RADIUS Change of Authorization and Disconnect Message section.
> Important: Changing ACL and rulebase together in a single CoA is not supported. For this, two separate CoA requests can be sent through AAA server requesting for one attribute change per request.
> Session Limits On Redirection
> To limit the amount of memory consumed by a session manager a limit of 2000 redirected session entries per session manager is allocated. This limit is equally shared by the set of subscribers who are currently being redirected. Whenever a redirected session entry is subject to revocation from a subscriber due to an insufficient number of available session entries, the least recently used entry is revoked.
> Stopping Redirection
> The redirected session entries for a subscriber remain active until a CoA message issued from the RADIUS server specifies a filter that does not contain the readdress server ACL rule. When this happens, the redirected session entries for the subscriber are deleted.
> All redirected session entries are also deleted when the subscriber disconnects.
> Handling IP Fragments
> Since TCP/UDP port numbers are part of the redirection mechanism, fragmented IP datagrams must be reassembled before being redirected. Reassembly is particularly necessary when fragments are sent out of order. The session manager performs reassembly of datagrams and reassembly is attempted only when a datagram matches the redirect server ACL rule. To limit memory usage, only up to 10 different datagrams may be concurrently reassembled for a subscriber. Any additional requests cause the oldest datagram being reassembled to be discarded. The reassembly timeout is set to 2 seconds. In addition, the limit on the total number of fragments being reassembled by a session manager is set to 1000. If this limit is reached, the oldest datagram being reassembled in the session manager and its fragment list are discarded. These limits are not configurable.
> Recovery
> When a session manager dies, the ACL rules are recovered. The session redirect entries have to be re-created when the MN initiates new traffic for the session. Therefore when a crash occurs, traffic from the Internet side is not redirected to the MN.
> AAA Accounting
> Where destination-based accounting is implemented, traffic from the subscriber is accounted for using the original destination address and not the redirected address.
> Viewing the Redirected Session Entries for a Subscriber
> View the redirected session entries for a subscriber by entering the following command:
> show subscribers debug-info { callid <id> | msid <id> | username <name> }
> The following command displays debug information for a subscriber with the MSID 0000012345:
> show subscribers debug-info msid 0000012345
> The following is a sample output of this command:
> username: user1 callid: 01ca11b1 msid: 0000100003
> Card/Cpu: 4/2
> Sessmgr Instance: 7
> Primary callline:
> Redundancy Status: Original Session
> Checkpoints Attempts Success Last-Attempt Last-Success
> Full: 27 26 15700ms 15700ms
> Micro: 76 76 4200ms 4200ms
> Current state: SMGR_STATE_CONNECTED
> FSM Event trace:
> State Event
> SMGR_STATE_OPEN SMGR_EVT_NEWCALL SMGR_STATE_NEWCALL_ARRIVED SMGR_EVT_ANSWER_CALL SMGR_STATE_NEWCALL_ANSWERED SMGR_EVT_LINE_CONNECTED SMGR_STATE_LINE_CONNECTED SMGR_EVT_LINK_CONTROL_UP SMGR_STATE_LINE_CONNECTED SMGR_EVT_AUTH_REQ
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_IPADDR_ALLOC_SUCCESS
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_AUTH_SUCCESS
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_UPDATE_SESS_CONFIG
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_LOWER_LAYER_UP
> Data Reorder statistics
> Total timer expiry: 0 Total flush (tmr expiry): 0
> Total no buffers: 0 Total flush (no buffers): 0
> Total flush (queue full): 0 Total flush (out of range):0
> Total flush (svc change): 0 Total out-of-seq pkt drop: 0
> Total out-of-seq arrived: 0
> IPv4 Reassembly Statistics:
> Success: 0 In Progress: 0
> Failure (timeout): 0 Failure (no buffers): 0
> Failure (other reasons): 0
> Redirected Session Entries:
> Allowed: 2000 Current: 0
> Added: 0 Deleted: 0
> Revoked for use by different subscriber: 0
> Peer callline:
> Redundancy Status: Original Session
> Checkpoints Attempts Success Last-Attempt Last-Success
> Full: 0 0 0ms 0ms
> Micro: 0 0 0ms 0ms
> Current state: SMGR_STATE_CONNECTED
> FSM Event trace:
> State Event
> SMGR_STATE_OPEN SMGR_EVT_MAKECALL
> SMGR_STATE_MAKECALL_PENDING SMGR_EVT_LINE_CONNECTED
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_LOWER_LAYER_UP
> SMGR_STATE_CONNECTED SMGR_EVT_AUTH_REQ
> SMGR_STATE_CONNECTED SMGR_EVT_AUTH_SUCCESS
> SMGR_STATE_CONNECTED SMGR_EVT_REQ_SUB_SESSION
> SMGR_STATE_CONNECTED SMGR_EVT_RSP_SUB_SESSION
> username: user1 callid: 01ca11b1 msid: 0000100003
> Card/Cpu: 4/2
> Sessmgr Instance: 7
> Primary callline:
> Redundancy Status: Original Session
> Checkpoints Attempts Success Last-Attempt Last-Success
> Full: 27 26 15700ms 15700ms
> Micro: 76 76 4200ms 4200ms
> Current state: SMGR_STATE_CONNECTED
> FSM Event trace:
> State Event
> SMGR_STATE_OPEN SMGR_EVT_NEWCALL
> SMGR_STATE_NEWCALL_ARRIVED SMGR_EVT_ANSWER_CALL
> SMGR_STATE_NEWCALL_ANSWERED SMGR_EVT_LINE_CONNECTED
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_LINK_CONTROL_UP
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_AUTH_REQ
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_IPADDR_ALLOC_SUCCESS
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_AUTH_SUCCESS
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_UPDATE_SESS_CONFIG
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_LOWER_LAYER_UP
> Data Reorder statistics
> Total timer expiry: 0 Total flush (tmr expiry): 0
> Total no buffers: 0 Total flush (no buffers): 0
> Total flush (queue full): 0 Total flush (out of range):0
> Total flush (svc change): 0 Total out-of-seq pkt drop: 0
> Total out-of-seq arrived: 0
> IPv4 Reassembly Statistics:
> Success: 0 In Progress: 0
> Failure (timeout): 0 Failure (no buffers): 0
> Failure (other reasons): 0
> Redirected Session Entries:
> Allowed: 2000 Current: 0
> Added: 0 Deleted: 0
> Revoked for use by different subscriber: 0
> Peer callline:
> Redundancy Status: Original Session
> Checkpoints Attempts Success Last-Attempt Last-Success
> Full: 0 0 0ms 0ms
> Micro: 0 0 0ms 0ms
> Current state: SMGR_STATE_CONNECTED
> FSM Event trace:
> State Event
> SMGR_STATE_OPEN SMGR_EVT_MAKECALL
> SMGR_STATE_MAKECALL_PENDING SMGR_EVT_LINE_CONNECTED
> SMGR_STATE_LINE_CONNECTED SMGR_EVT_LOWER_LAYER_UP
> SMGR_STATE_CONNECTED SMGR_EVT_AUTH_REQ
> SMGR_STATE_CONNECTED SMGR_EVT_AUTH_SUCCESS
> SMGR_STATE_CONNECTED SMGR_EVT_REQ_SUB_SESSION
> SMGR_STATE_CONNECTED SMGR_EVT_RSP_SUB_SESSION
> SMGR_STATE_CONNECTED SMGR_EVT_ADD_SUB_SESSION
> SMGR_STATE_CONNECTED SMGR_EVT_AUTH_REQ
> SMGR_STATE_CONNECTED SMGR_EVT_AUTH_SUCCESS
> Data Reorder statistics
> Total timer expiry: 0 Total flush (tmr expiry): 0
> Total no buffers: 0 Total flush (no buffers): 0
> Total flush (queue full): 0 Total flush (out of range):0
> Total flush (svc change): 0 Total out-of-seq pkt drop: 0
> Total out-of-seq arrived: 0
> IPv4 Reassembly Statistics:
> Success: 0 In Progress: 0
> Failure (timeout): 0 Failure (no buffers): 0
> Failure (other reasons): 0
> Redirected Session Entries:
> Allowed: 2000 Current: 0
> Added: 0 Deleted: 0
> Revoked for use by different subscriber: 0
> Appendix B
> GRE Protocol Interface
> This chapter provides information on Generic Routing Encapsulation protocol interface support in the GGSN or P-GW service node. 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 features described in this chapter is an enhanced feature and need enhanced feature license. This support is only available if you have purchased and installed particular feature support license on your chassis.
> 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.
> This chapter discusses following topics for GRE protocol interface support:

> • | Introduction

> • | Supported Standards

> • | Supported Networks and Platforms

> • | Services and Application on GRE Interface

> • | How GRE Interface Support Works

> • | GRE Interface Configuration

> • | Verifying Your Configuration

> Introduction
> GRE protocol functionality adds one additional protocol on ST-series Multimedia Core Platforms (ST40 or higher) to support mobile users to connect to their enterprise networks through Generic Routing Encapsulation (GRE).
> GRE tunnels can be used by the enterprise customers of a carrier 1) To transport AAA packets corresponding to an APN over a GRE tunnel to the corporate AAA servers and, 2) To transport the enterprise subscriber packets over the GRE tunnel to the corporation gateway.
> The corporate servers may have private IP addresses and hence the addresses belonging to different enterprises may be overlapping. Each enterprise needs to be in a unique virtual routing domain, known as VRF. To differentiate the tunnels between same set of local and remote ends, GRE Key will be used as a differentiator.
> It is a common technique to enable multi-protocol local networks over a single-protocol backbone, to connect non-contiguous networks and allow virtual private networks across WANs. This mechanism encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. It is important to note that GRE tunneling does not provide security to the encapsulated protocol, as there is no encryption involved (like IPSEC offers, for example).
> GRE Tunneling consists of three main components:

> • | Passenger protocol-protocol being encapsulated. For example: CLNS, IPv4 and IPv6.

> • | Carrier protocol-protocol that does the encapsulating. For example: GRE, IP-in-IP, L2TP, MPLS and IPSEC.

> • | Transport protocol-protocol used to carry the encapsulated protocol. The main transport protocol is IP.

> The most simplified form of the deployment scenario is shown in the following figure, in which GGSN has two APNs talking to two corporate networks over GRE tunnels.
> GRE Interface Deployment Scenario
> Supported Standards
> Support for the following standards and requests for comments (RFCs) have been added with this interface support:

> • | RFC 1701, Generic Routing Encapsulation (GRE)

> • | RFC 1702, Generic Routing Encapsulation over IPv4 networks

> • | RFC 2784, Generic Routing Encapsulation (GRE)

> • | RFC 2890, Key and Sequence Number Extensions to GRE

> Supported Networks and Platforms
> This feature supports all ASR5000 platforms with StarOS Release 9.0 or later running GGSN and/or SGSN service for the core network services. The P-GW service supports this feature with StarOS Release 12.0 or later.
> Licenses
> This feature support requires following feature license/s installed on the system:

> • | Cisco PID [ ASR5K-00-CS01GRET ] GRE Interface Tunneling, 1K Sessions, or Starent Part Number [ 600-00-7862 ] GRE Interface Tunneling, 1K Sessions.

> • | Cisco PID [ ASR5K-00-CS10GRET ] GRE Interface Tunneling, 10K Sessions, or Starent Part Number [ 600-00-7861 ] GRE Interface Tunneling, 10K Sessions.

> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> Services and Application on GRE Interface
> GRE interface implementation provides the following functionality with GRE protocol support.
> How GRE Interface Support Works
> The GRE interface provides two types of data processing; one for ingress packets and another for egress packets.
> Ingress Packet Processing on GRE Interface
> Figure given below provides a flow of process for incoming packets on GRE interface.
> Note that in case the received packet is a GRE keep-alive or a ping packet then the outer IPV4 and GRE header are not stripped off (or get reattached), but instead the packet is forwarded as is to the VPN manager or kernel respectively. In case of all other GRE tunneled packets the IPV4 and GRE header are stripped off before sending the packet for a new flow lookup.
> Ingress Packet Processing on GRE Interface
> Egress Packet Processing on GRE Interface
> Figure given below provides a flow of process for outgoing packets on GRE interface:
> Egress Packet Processing on GRE Interface
> GRE Interface Configuration
> This section provides a high-level series of steps and the associated configuration examples for configuring the system with GRE interface in GGSN or P-GW services.
> Important: This section provides the minimum instruction set to enable the GRE Protocol Interface support functionality on a GGSN or P-GW. Commands that configure additional functions for this feature are provided in the Cisco ASR 5000 Series Command Line Interface Reference.
> These instructions assume that you have already configured the system level configuration as described in Cisco ASR 5000 Series System Administration Guide and specific product Administration Guide.
> To configure the system to support GRE tunnel interface:

> Step 1 | Configure the virtual routing and forwarding (VRF) in a context by applying the example configurations presented in the Virtual Routing And Forwarding (VRF) Configuration section.

> Step 2 | Configure the GRE tunnel interface in a context by applying the example configurations presented in the GRE Tunnel Interface Configuration section.

> Step 3 | Enable OSPF for the VRF and for the given network by applying the example configurations presented in the Enabling OSPF for VRF section.

> Step 4 | Associate IP pool and AAA server group with VRF by applying the example configurations presented in the Associating IP Pool and AAA Group with VRF section.

> Step 5 | Associate APN with VRF through AAA server group and IP pool by applying the example configurations presented in the Associating APN with VRF section.

> Step 6 | Optional. If the route to the server is not learnt from the corporate over OSPFv2, static route can be configured by applying the example configurations presented in the Static Route Configuration section.

> Step 7 | Save the changes to system configuration by applying the example configuration given in Verifying and Saving Your Configuration chapter.

> Step 8 | Verify configuration of GRE and VRF related parameters by applying the commands provided in the Verifying Your Configuration section of this chapter.

> Virtual Routing And Forwarding (VRF) Configuration
> This section provides the configuration example to configure the VRF in a context:
> configure
> context <vpn_context_name> -noconfirm ]
> ip vrf <vrf_name>
> ip maximum-routes <max_routes>
> end
> Notes:

> • | <vpn_context_name> is the name of the system context you want to use for VRF. For more information, refer System Administration Guide.

> • | A maximum of 100 VRFs in one context and up to 1024 VRFs on one chassis can be configured on system.

> • | <vrf_name> is name of the VRF which is to be associated with various interfaces.

> • | A maximum of 10000 routes can be configured through ip maximum-routes <max_routes> command.

> GRE Tunnel Interface Configuration
> This section provides the configuration example to configure the GRE tunnel interface and associate a VRF with GRE interface:
> configure
> context <vpn_context_name>
> ip interface <intfc_name> tunnel
> ip vrf forwarding <vrf_name>
> ip address <internal_ip_address/mask>
> tunnel-mode gre
> source interface <non_tunn_intfc_to_corp>
> destination address <global_ip_address>
> keepalive interval <value> num-retry <retry>
> end
> Notes:

> • | <vpn_context_name> is the name of the system context you want to use for GRE interface configuration. For more information, refer Cisco ASR 5000 Series Command Line Interface Reference.

> • | A maximum of 511 GRE tunnels + 1 non-tunnel interface can be configured in one context. System needs at least 1 non-tunnel interface as a default.

> • | <intfc_name> is name of the IP interface which is defined as a tunnel type interface and to be used for GRE tunnel interface.

> • | <vrf_name> is the name of the VRF which is preconfigured in context configuration mode.

> • | <internal_ip_address/mask> is the network IP address with sub-net mask to be used for VRF forwarding.

> • | <non_tunn_intfc_to_corp> is the name a non-tunnel interface which is required by system as source interface and preconfigured. For more information on interface configuration refer System Administration Guide.

> • | <global_ip_address> is a globally reachable IP address to be used as a destination address.

> Enabling OSPF for VRF
> This section provides the configuration example to enable the OSPF for VRF to support GRE tunnel interface:
> configure
> context <vpn_context_name>
> router ospf
> ip vrf <vrf_name>
> network <internal_ip_address/mask>
> end
> Notes:

> • | <vpn_context_name> is the name of the system context you want to use for OSPF routing. For more information, refer Routing in this guide.

> • | <vrf_name> is the name of the VRF which is preconfigured in context configuration mode.

> • | <internal_ip_address/mask> is the network IP address with sub-net mask to be used for OSPF routing.

> Associating IP Pool and AAA Group with VRF
> This section provides the configuration example for associating IP pool and AAA groups with VRF:
> configure
> context <vpn_context_name>
> ip pool <ip_pool_name> <internal_ip_address/mask> vrf <vrf_name>
> exit
> aaa group <aaa_server_group>
> ip vrf <vrf_name>
> end
> Notes:

> • | <vpn_context_name> is the name of the system context you want to use for IP pool and AAA server group.

> • | <ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.

> • | <aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.

> • | <vrf_name> is the name of the VRF which is preconfigured in context configuration mode.

> • | <internal_ip_address/mask> is the network IP address with sub-net mask to be used for IP pool.

> Associating APN with VRF
> This section provides the configuration example for associating an APN with VRF through AAA group and IP pool:
> configure
> context <vpn_context_name>
> apn <apn_name>
> aaa group <aaa_server_group>
> ip address pool name <ip_pool_name>
> end
> Notes:

> • | <vpn_context_name> is the name of the system context you want to use for APN configuration.

> • | <ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.

> • | <aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.

> • | <vrf_name> is the name of the VRF which is preconfigured in context configuration mode.

> Static Route Configuration
> This section provides the optional configuration example for configuring static routes when the route to the server is not learnt from the corporate over OSPFv2:
> configure
> context <vpn_context_name>
> ip route <internal_ip_address/mask> tunnel <tunnel_intfc_name> vrf <vrf_name>
> end
> Notes:

> • | <vpn_context_name> is the name of the system context you want to use for static route configuration.

> • | <internal_ip_address/mask> is the network IP address with sub-net mask to be used as static route.

> • | <tunnel_intfc_name> is name of a predefined tunnel type IP interface which is to be used for GRE tunnel interface.

> • | <vrf_name> is the name of the VRF which is preconfigured in context configuration mode.

> Verifying Your Configuration
> This section explains how to display and review the configurations after saving them in a .cfg file as described in Saving Your Configuration chapter of this guide and also to retrieve errors and warnings within an active configuration for a service.
> Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
> These instructions are used to verify the GRE interface configuration.

> Step 1 | Verify that your interfaces are configured properly by entering the following command in Exec Mode:

> show ip interface
> The output of this command displays the configuration of the all interfaces configured in a context.
> Intf Name: foo1
> Intf Type: Broadcast
> Description:
> IP State: UP (Bound to 17/2 untagged, ifIndex 285343745)
> IP Address: 1.1.1.1 Subnet Mask: 255.255.255.0
> Bcast Address: 1.1.1.255 MTU: 1500
> Resoln Type: ARP ARP timeout: 60 secs
> L3 monitor LC-port switchover: Disabled
> Number of Secondary Addresses: 0
> Intf Name: foo2
> Intf Type: Tunnel (GRE)
> Description:
> VRF: vrf-tun
> IP State: UP (Bound to local address 1.1.1.1 (foo1), remote address 5.5.5.5)
> IP Address: 10.1.1.1 Subnet Mask: 255.255.255.0
> Intf Name: foo3
> Intf Type: Tunnel (GRE)
> Description:
> IP State: DOWN (<state explaining the reason of being down>)
> IP Address: 20.20.20.1 Subnet Mask: 255.255.255.0

> Step 2 | Verify that GRE keep alive is configured properly by entering the following command in Exec Mode:

> show ip interface gre-keepalive
> The output of this command displays the configuration of the keepalive for GRE interface configured in a context.
> Appendix C
> Gx Interface Support
> This chapter provides information on configuring Gx interface to support policy and charging control for subscribers.
> The IMS service provides application support for transport of voice, video, and data independent of access support. Roaming IMS subscribers require apart from other functionality sufficient, uninterrupted, consistent, and seamless user experience during an application session. It is also important that a subscriber gets charged only for the resources consumed by the particular IMS application used.
> It is recommended that before using the procedures in this chapter 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.
> The following topics are covered in this chapter:

> • | Rel. 6 Gx Interface

> • | Rel. 7 Gx Interface

> • | Rel. 8 Gx Interface

> • | Rel. 9 Interface

> Rel. 6 Gx Interface
> Rel. 6 Gx interface support is available on the Cisco ASR 5000 platform running StarOS 8.0 and later releases for the following products:

> • | GGSN

> • | IPSG

> This section describes the following topics:

> • | Introduction

> • | Licensing

> • | Supported Standards

> • | Supported Networks and Platforms

> • | How it Works

> • | Configuring Rel. 6 Gx Interface

> Introduction
> In GPRS/UMTS networks, the client functionality lies with the GGSN/IPSG, therefore in the IMS authorization scenario it is also called Access Gateway (AGW).
> The provisioning of charging rules that are based on the dynamic analysis of flows used for the IMS session is carried out over the Gx interface. In 3GPP, Rel. 6 the Gx is an interface between Access Gateway functioning as Traffic Plane Function (TPF) and the Charging Rule Function (CRF). It is based on the Diameter Base Protocol (DIABASE) and the Diameter Credit Control Application (DCCA) standard. The GGSN/TPF acts as the client where as the CRF contains the Diameter server functionality.
> The AGW is required to perform query, in reply to which the servers provision certain policy or rules that are enforced at the AGW for that particular subscriber session. The CRF analyzes the IP flow data, which in turn has been retrieved from the Session Description Protocol (SDP) data exchanged during IMS session establishment.
> Important: In addition to standard Gx interface functionality, the Gx interface implemented here provides support of SBLP with additional AVPs in custom DPCA dictionaries. For more information on customer-specific support contact your local technical support representative. In view of required flow bandwidth and QoS, the system provides enhanced support for use of Service Based Local Policy (SBLP) to provision and control the resources used by the IMS subscriber. SBLP is based on the dynamic parameters such as the media/traffic flows for data transport, network conditions and static parameters, such as subscriber configuration and category. It also provides Flow-based Charging (FBC) mechanism to charge the subscriber dynamically based on content usage. With this additional functionality, the Cisco Systems Gateway can act as an Enhanced Policy Decision Function (E-PDF).
> Licensing
> This feature requires the following license to be installed on the chassis:
> Cisco PID [ ASR5K-00-CS01PIF ] Policy Interface, 1K sessions, or Starent Part Number [ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature.
> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> Supported Standards
> The Rel 6. Gx interface support is based on the following standards and request for comments (RFCs):

> • | 3GPP TS 29.210, Charging rule provisioning over Gx interface

> • | RFC 3588, Diameter Base Protocol; September 2003

> • | RFC 4006, Diameter Credit-Control Application; August 2005

> In addition to the above RFCs and standards, IMS Authorization partially supports 3GPP TS 29.212 for Policy and Charging Control over Gx reference point functionality.
> Supported Networks and Platforms
> This feature is supported on all ASR 5000 Series Platforms with StarOS Release 8.0 or later running GGSN service for the core network services.
> How it Works
> This section describes the IMS authorization and dynamic policy support in GPRS/UMTS networks.
> The following figure and table explain the IMS authorization process between a system and IMS components that is initiated by the MN.
> In the case of GGSN, the DPCA is the Gx interface to the Control and Charging Rule Function (CRF). In this context CRF will act as Enhanced Policy Decision Function (E-PDF). The CRF may reside in Proxy-Call Session Control Function (P-CSCF) or on stand-alone system.
> The interface between IMSA with CRF is the Gx interface, and between Session Manager and Online Charging Service (OCS) is the Gy interface.
> Note that the IMS Authorization (IMSA) service and Diameter Policy Control Application (DPCA) are part of Session Manager on the system, and separated in the following figure for illustration purpose only.
> Rel. 6 Gx IMS Authorization Call Flow
> Rel. 6 Gx IMS Authorization Call flow Description

> Step | Description
> 1 | IMS subscriber (MN) sends request for primary PDP context activation/creation.
> 2 | Session manager allocates IP address to MN.
> 3 | Session manager sends IMS authorization request to IMS Authorization service (IMSA).
> 4 | IMSA creates a session with the CRF on the basis of CRF configuration.
> 5 | IMSA sends request to DPCA module to issue the authorization request to selected CRF.
> 6 | DPCA sends a CCR-initial message to the selected CRF. This message includes the IP address allocated to MN.
> 7 | CCA message sent to DPCA. If a preconfigured rule set for the PDP context is provided in CRF, it sends that charging rules to DPCA in CCA message.
> 8 | DPCA module calls the callback function registered with it by IMSA.
> 9 | After processing the charging rules, IMSA sends Policy Authorization Complete message to session manager.
> 10 | The rules received in CCA message are used for dynamic rule configuration structure and session manager sends the message to ECS.
> 11 | ECS installs the rules and performs credit authorization by sending CCR-Initial to Online Charging System (OCS) with CC-Request-Type set to INITIAL_REQUEST to open the credit control session. This request includes the active rule base ID and 3GPP specific attributes (for example, APN, QoS and so on).
> 12 | OCS returns a CCA-Initial message to activate the statically configured rulebase and includes preemptive credit quotas.
> 13 | ECS responds to session manager with the response message for dynamic rule configuration.
> 14 | On the basis of response for the PDP context authorization, Session Manager sends the response to the MN and activates/rejects the call.

> ‌
> Configuring Rel. 6 Gx Interface
> To configure Rel. 6 Gx interface functionality:

> Step 1 | Configure the IMS Authorization Service at the context level for an IMS subscriber in GPRS/UMTS network as described in the Configuring IMS Authorization Service at Context Level section.

> Step 2 | Verify your configuration, as described in the Verifying IMS Authorization Service Configuration section.

> Step 3 | Configure an APN within the same context to use the IMS Authorization service for an IMS subscriber as described in the Applying IMS Authorization Service to an APN section.

> Step 4 | Verify your configuration as described in the Verifying Subscriber Configuration section.

> Step 5 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Important: Commands used in the configuration examples 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 Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands.
> Configuring IMS Authorization Service at Context Level
> Use the following example to configure IMS Authorization Service at context level for IMS subscribers in GPRS/UMTS networks:
> configure
> context <context_name>
> ims-auth-service <imsa_service_name>
> p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> }
> p-cscf discovery { table { 1 | 2 } [ algorithm { ip-address-modulus | msisdn-modulus | round-robin } ] | diameter-configured }
> policy-control
> diameter origin endpoint <endpoint_name>
> diameter dictionary <dictionary>
> failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
> diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <host_name> [ realm <realm_name> ] [ secondary host <host_name> [ realm <realm_name> ] ]
> diameter host-select reselect subscriber-limit <subscriber_limit> time-interval <duration>
> diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
> end
> Notes:

> • | <context_name> must be the name of the context where you want to enable IMS Authorization Service.

> • | <imsa_service_name> must be the name of the IMS Authorization Service to be configured for the Gx interface authentication.

> • | A maximum of 16 authorization services can be configured globally in a system. There is also a system limit for maximum number of total configured services.

> • | Secondary P-CSCF IP address can be configured in the P-CSCF table. Refer to the Cisco ASR 5000 Series Command Line Interface Reference for more information on the p-cscf table command.

> • | To enable Rel. 6 Gx interface support, specific Diameter dictionary must be configured. For information on the Diameter dictionary to use, please contact your local service representative.

> • | Optional: To configure the quality of service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:

> qos-update-timeout <timeout_duration>

> • | Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:

> signaling-flag { deny | permit }
> signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]

> • | Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:

> traffic-policy general-pdp-context no-matching-gates direction { downlink | uplink } { forward | discard }

> • | Optional: To configure the algorithm to select Diameter host table, in the Policy Control Configuration Mode, enter the following command:

> diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
> Verifying IMS Authorization Service Configuration
> To verify the IMS Authorization Service configuration:

> Step 1 | Change to the context where you enabled IMS Authorization Service by entering the following command:

> context <context_name>

> Step 2 | Verify the IMS Authorization Service’s configurations by entering the following command:

> show ims-authorization service name <imsa_service_name>
> Applying IMS Authorization Service to an APN
> After configuring IMS Authorization service at the context-level, an APN within the same context must be configured to use the IMS Authorization service for an IMS subscriber.
> Use the following example to apply IMS Authorization service functionality to a previously configured APN within the context configured in the Configuring IMS Authorization Service section.
> configure
> context <context_name>
> apn <apn_name>
> ims-auth-service <imsa_service_name>
> end
> Notes:

> • | <context_name> must be the name of the context in which the IMS Authorization service was configured.

> • | <imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication in the context.

> Verifying Subscriber Configuration
> Verify the IMS Authorization Service configuration for subscriber(s) by entering the following command:
> show subscribers ims-auth-service <imsa_service_name>
> <imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication.
> Rel. 7 Gx Interface
> Rel. 7 Gx interface support is available on the Cisco ASR 5000 platform running StarOS 8.1 or StarOS 9.0 and later releases for the following products:

> • | GGSN

> • | IPSG

> This section describes the following topics:

> • | Introduction

> • | Supported Networks and Platforms

> • | Licensing

> • | Supported Standards

> • | Terminology and Definitions

> • | How it Works

> • | Configuring Rel. 7 Gx Interface

> • | Gathering Statistics

> Introduction
> For IMS deployment in GPRS/UMTS networks the system uses Rel. 7 Gx interface for policy-based admission control support and flow-based charging. The Rel. 7 Gx interface supports enforcing policy control features like gating, bandwidth limiting, and so on, and also supports flow-based charging. This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify Service Data Flows (SDF) and do charging. Other parameters associated with the rules are used to enforce policy control.
> The PCC architecture allows operators to perform service-based QoS policy, and flow-based charging control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/Cisco Systems GGSN and the Policy and Charging Rules Function (PCRF).
> In GPRS/UMTS networks, the client functionality lies with the GGSN, therefore in the IMS authorization scenario it is also called the Gateway. In the following figure, Gateway is the Cisco Systems GGSN, and the PCEF function is provided by Enhanced Charging Service (ECS). The Rel 7. Gx interface is implemented as a Diameter connection. The Gx messages mostly involve installing/modifying/removing dynamic rules and activating/deactivating predefined rules.
> The Rel. 7 Gx reference point is located between the Gateway and the PCRF. This reference point is used for provisioning and removal of PCC rules from the PCRF to the Gateway, and the transmission of traffic plane events from the Gateway to the PCRF. The Gx reference point can be used for charging control, policy control, or both by applying AVPs relevant to the application. The following figure shows the reference points between various elements involved in the policy and charging architecture.
> PCC Logical Architecture
> Within the Gateway, the IMSA and DPCA modules handle the Gx protocol related functions (at the SessMgr) and the policy enforcement and charging happens at ECS. The Gy protocol related functions are handled within the DCCA module (at the ECS). The following figure shows the interaction between components within the Gateway.
> PCC Architecture within Cisco PCEF
> Supported Networks and Platforms
> This feature is supported on all ASR 5000 Series Platforms with StarOS Release 8.1 and later running GGSN service for the core network services.
> Licensing
> This feature requires the following licenses to be installed on the chassis:

> • | Cisco PID [ ASR5K-00-CS01PIF ] Policy Interface, 1K sessions, or Starent Part Number [ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature.

> • | Cisco PID [ ASR5K-00-CS01ECG2 ] Enhanced Charging Bundle 2 1k Sessions, or Starent Part Number [ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — To enable and configure Diameter and ECS functionality.

> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> Supported Standards
> The Rel 7. Gx interface support is based on the following standards and RFCs:

> • | 3GPP TS 23.203 V7.6.0 (2008-03): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 7)

> • | 3GPP TS 29.212 V7.8.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 7)

> • | 3GPP TS 29.213 V7.4.0 (2008-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control signalling flows and QoS parameter mapping; (Release 7)

> • | RFC 3588, Diameter Base Protocol; September 2003

> • | RFC 4006, Diameter Credit-Control Application; August 2005

> Terminology and Definitions
> This section describes features and terminology pertaining to Rel. 7 Gx functionality.
> Policy Control
> The process whereby the PCRF indicates to the PCEF how to control the IP-CAN bearer.
> Policy control comprises the following functions:

> • | Binding: Binding is the generation of an association between a Service Data Flow (SDF) and the IP CAN bearer (for GPRS a PDP context) transporting that SDF.

> The QoS demand in the PCC rule, as well as the SDF template are input for the bearer binding. The selected bearer will have the same QoS Class as the one indicated by the PCC rule.
> Depending on the type of IP-CAN and bearer control mode, bearer binding can be executed either by the PCRF, or both PCRF and PCEF.

> • | For UE-only IP-CAN bearer establishment mode, the PCRF performs bearer binding. When the PCRF performs bearer binding, it indicates the bearer (PDP context) by means of Bearer ID. The Bearer ID uniquely identifies the bearer within the PDP session.

> • | For UE/NW IP-CAN bearer establishment mode, the PCRF performs the binding of the PCC rules for user controlled services, while the PCEF performs the binding of the PCC rules for the network-controlled services.

> • | Gating Control: Gating control is the blocking or allowing of packets, belonging to an SDF, to pass through to the desired endpoint. A gate is described within a PCC rule and gating control is applied on a per SDF basis. The commands to open or close the gate leads to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed, all packets of the related IP flows are dropped. If the gate is opened, the packets of the related IP flows are allowed to be forwarded.

> • | Event Reporting: Event reporting is the notification of and reaction to application events to trigger new behavior in the user plane as well as the reporting of events related to the resources in the Gateway (PCEF).

> • | Event triggers may be used to determine which IP-CAN session modification or specific event causes the PCEF to re-request PCC rules. Although event trigger reporting from PCEF to PCRF can apply for an IP CAN session or bearer depending on the particular event, provisioning of event triggers will be done at session level.

> Note that in 11.0 and later releases, RAR with unknown event triggers are silently ignored and responded with DIAMETER_SUCCESS. In earlier releases, when unknown event triggers were received in the RAR command from PCRF, invalid AVP result code was set in the RAA command.

> • | The Event Reporting Function (ERF) receives event triggers from PCRF during the Provision of PCC Rules procedure and performs event trigger detection. When an event matching the received event trigger occurs, the ERF reports the occurred event to the PCRF. If the provided event triggers are associated with certain parameter values then the ERF includes those values in the response back to the PCRF. The Event Reporting Function is located in the PCEF.

> Important: In this release, event triggers “IP-CAN_CHANGE” and “MAX_NR_BEARERS_REACHED” are not supported.

> • | QoS Control: QoS control is the authorization and enforcement of the maximum QoS that is authorized for a SDF or an IP-CAN bearer or a QoS Class Identifier (QCI). In case of an aggregation of multiple SDFs (for GPRS a PDP context), the combination of the authorized QoS information of the individual SDFs is provided as the authorized QoS for this aggregate.

> • | QoS control per SDF allows the PCC architecture to provide the PCEF with the authorized QoS to be enforced for each specific SDF.

> • | The enforcement of the authorized QoS of the IP-CAN bearer may lead to a downgrading or upgrading of the requested bearer QoS by the Gateway (PCEF) as part of a UE-initiated IP-CAN bearer establishment or modification. Alternatively, the enforcement of the authorized QoS may, depending on operator policy and network capabilities, lead to network-initiated IP-CAN bearer establishment or modification. If the PCRF provides authorized QoS for both, the IP-CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules takes place first.

> • | QoS authorization information may be dynamically provisioned by the PCRF, or it can be a predefined PCC rule in the PCEF. In case the PCRF provides PCC rules dynamically, authorized QoS information for the IP-CAN bearer (combined QoS) may be provided. For a predefined PCC rule within the PCEF, the authorized QoS information takes affect when the PCC rule is activated. The PCEF combines the different sets of authorized QoS information, that is the information received from the PCRF and the information corresponding to the predefined PCC rules. The PCRF knows the authorized QoS information of the predefined PCC rules and takes this information into account when activating them. This ensures that the combined authorized QoS of a set of PCC rules that are activated by the PCRF is within the limitations given by the subscription and operator policies regardless of whether these PCC rules are dynamically provided, predefined, or both.

> Important: In this release, QoS Resource Reservation is not supported.
> Supported Features:

> • | Provisioning and Policy Enforcement of Authorized QoS: The PCRF may provide authorized QoS to the PCEF. The authorized QoS provides appropriate values for resources to be enforced.

> • | Provisioning of “Authorized QoS” Per IP CAN Bearer: The authorized QoS per IP-CAN bearer is used if the bearer binding is performed by the PCRF.

> • | Policy Enforcement for “Authorized QoS” per IP CAN Bearer: The PCEF is responsible for enforcing the policy-based authorization, that is to ensure that the requested QoS is in-line with the “Authorized QoS” per IP CAN Bearer.

> • | Policy Provisioning for Authorized QoS Per SDF: The provisioning of authorized QoS per SDF is a part of PCC rule provisioning procedure.

> • | Policy Enforcement for Authorized QoS Per SDF: If an authorized QoS is defined for a PCC rule, the PCEF limits the data rate of the SDF corresponding to that PCC rule not to exceed the maximum authorized bandwidth for the PCC rule by discarding packets exceeding the limit.

> • | Upon deactivation or removal of a PCC rule, the PCEF frees the resources reserved for that PCC rule. If the PCRF provides authorized QoS for both the IP-CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules takes place first.

> Important: In this release, coordination of authorized QoS scopes in mixed mode (BCM = UE_NW) is not supported.

> • | Provisioning of Authorized QoS Per QCI: If the PCEF performs the bearer binding, the PCRF may provision an authorized QoS per QCI for non-GBR bearer QCI values. If the PCRF performs the bearer binding the PCRF does not provision an authorized QoS per QCI. The PCRF does not provision an authorized QoS per QCI for GBR bearer QCI values.

> • | Policy Enforcement for Authorized QoS per QCI: The PCEF can receive an authorized QoS per QCI for non GBR-bearer QCI values.

> • | Other Features:

> • | Bearer Control Mode Selection: The PCEF may indicate, via the Gx reference point, a request for Bearer Control Mode (BCM) selection at IP-CAN session establishment or IP-CAN session modification (as a consequence of an SGSN change). It will be done using the “PCC Rule Request” procedure.

> If the Bearer-Control-Mode AVP is not received from PCRF, the IP-CAN session is not terminated. The value negotiated between UE/SGSN/GGSN is considered as the BCM. The following values are considered for each of the service types:

> • | GGSN: The negotiated value between UE/SGSN/GGSN is considered.

> In the following scenarios UE_ONLY is chosen as the BCM:
> Scenario 1:

> • | UE-> UE_ONLY

> • | SGSN-> UE_ONLY

> • | GGSN-> UE_ONLY

> • | PCRF-> NO BCM

> Scenario 2:

> • | UE-> UE_ONLY

> • | SGSN-> UE_ONLY

> • | GGSN-> Mixed

> • | PCRF-> NO BCM

> • | GTP-PGW: BCM of UE_NW is considered.

> • | IPSG: BCM of UE_ONLY is considered.

> • | HSGW/SGW/PDIF/FA/PDSN/HA/MIPV6HA: BCM of NONE is considered.

> • | PCC Rule Error Handling: If the installation/activation of one or more PCC rules fails, the PCEF includes one or more Charging-Rule-Report AVP(s) in either a CCR or an RAA command for the affected PCC rules. Within each Charging-Rule-Report AVP, the PCEF identifies the failed PCC rule(s) by including the Charging-Rule-Name AVP(s) or Charging-Rule-Base-Name AVP(s), identifies the failed reason code by including a Rule-Failure-Code AVP, and includes the PCC-Rule-Status AVP.

> If the installation/activation of one or more new PCC rules (that is, rules that were not previously successfully installed) fails, the PCEF sets the PCC-Rule-Status to INACTIVE for both the PUSH and the PULL modes.
> If a PCC rule was successfully installed/activated, but can no longer be enforced by the PCEF, the PCEF shall send the PCRF a new CCR command and include a Charging-Rule-Report AVP. The PCEF shall include the Rule-Failure-Code AVP within the Charging-Rule-Report AVP and shall set the PCC-Rule-Status to INACTIVE.

> • | Time of the Day Procedures: PCEF performs PCC rule request as instructed by the PCRF. Revalidation-Time when set by the PCRF, causes the PCEF to trigger a PCRF interaction to request PCC rules from the PCRF for an established IP CAN session. The PCEF stops the timer once the PCEF triggers a REVALIDATION_TIMEOUT event.

> Important: In 11.0 and later releases Rule-Activation-Time / Rule-Deactivation-Time / Revalidation-Time AVP is successfully parsed only if its value corresponds to current time or a later time than the current IPSG time, else the AVP and entire message is rejected. In earlier releases the AVP is successfully parsed only if its value corresponds to a later time than the current IPSG time, else the AVP and entire message is rejected.
> Charging Control
> Charging Control is the process of associating packets belonging to a SDF to a charging key, and applying online charging and/or offline charging, as appropriate. Flow-based charging handles differentiated charging of the bearer usage based on real time analysis of the SDFs. In order to allow for charging control, the information in the PCC rule identifies the SDF and specifies the parameters for charging control. The PCC rule information may depend on subscription data.
> In the case of online charging, it is possible to apply an online charging action upon PCEF events (for example, re-authorization upon QoS change).
> It is possible to indicate to the PCEF that interactions with the charging systems are not required for a PCC rule, that is to perform neither accounting nor credit control for this SDF, and then no offline charging information is generated.
> Supported Features:

> • | Provisioning of Charging-related Information for the IP-CAN Session.

> • | Provisioning of Charging Addresses: Primary or secondary event charging function name (Online Charging Server (OCS) addresses).

> Important: In this release, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.

> • | Provisioning of Default Charging Method: In this release, the default charging method is sent in CCR-I message. For this, new AVPs Online/Offline are sent in CCR-I message based on the configuration.

> Charging Correlation
> For the purpose of charging correlation between SDF level and application level (for example, IMS) as well as on-line charging support at the application level, applicable charging identifiers and IP-CAN type identifiers are passed from the PCRF to the AF, if such identifiers are available.
> For IMS bearer charging, the IP Multimedia Core Network (IM CN) subsystem and the Packet Switched (PS) domain entities are required to generate correlated charging data.
> In order to achieve this, the Gateway provides the GGSN Charging Identifier (GCID) associated with the PDP context along with its address to the PCRF. The PCRF in turn sends the IMS Charging Identifier (ICID), which is provided by the P-CSCF, to the Gateway. The Gateway generates the charging records including the GCID as well as the ICID if received from PCRF, so that the correlation of charging data can be done with the billing system.
> PCRF also provides the flow identifier, which uniquely identifies an IP flow in an IMS session.
> Policy and Charging Control (PCC) Rules
> A PCC rule enables the detection of an SDF and provides parameters for policy control and/or charging control. The purpose of the PCC rule is to:

> • | Detect a packet belonging to an SDF.

> • | Select downlink IP CAN bearers based on SDF filters in the PCC rule.

> • | Enforce uplink IP flows are transported in the correct IP CAN bearer using the SDF filters within the PCC rule.

> • | Identify the service that the SDF contributes to.

> • | Provide applicable charging parameters for an SDF.

> • | Provide policy control for an SDF.

> The PCEF selects a PCC rule for each packet received by evaluating received packets against SDF filters of PCC rules in the order of precedence of the PCC rules. When a packet matches a SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied.
> There are two types of PCC rules:

> • | Dynamic PCC Rules: Rules dynamically provisioned by the PCRF to the PCEF via the Gx interface. These PCC rules may be either predefined or dynamically generated in the PCRF. Dynamic PCC rules can be activated, modified, and deactivated at any time.

> • | Predefined PCC Rule: Rules preconfigured in the PCEF by the operators. Predefined PCC rules can be activated or deactivated by the PCRF at any time. Predefined PCC rules within the PCEF may be grouped allowing the PCRF to dynamically activate a set of PCC rules over the Gx reference point.

> Important: A third type of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
> A PCC rule consists of:

> • | Rule Name: The rule name is used to reference a PCC rule in the communication between the PCEF and PCRF.

> • | Service Identifier: The service identifier is used to identify the service or the service component the SDF relates to.

> • | Service Data Flow Filter(s): The service flow filter(s) is used to select the traffic for which the rule applies.

> • | Precedence: For different PCC rules with overlapping SDF filter, the precedence of the rule determines which of these rules is applicable. When a dynamic PCC rule and a predefined PCC rule have the same priority, the dynamic PCC rule takes precedence.

> • | Gate Status: The gate status indicates whether the SDF, detected by the SDF filter(s), may pass (gate is open) or will be discarded (gate is closed) in uplink and/or in downlink direction.

> • | QoS Parameters: The QoS information includes the QoS class identifier (authorized QoS class for the SDF), the Allocation and Retention Priority (ARP), and authorized bitrates for uplink and downlink.

> Important: In earlier releases, ECS used only the Priority-Level part of ARP byte for bearer binding, (along with QCI). Now the entire ARP byte is used for bearer binding (along with QCI). Since the capability and vulnerability bits are optional in a dynamic rule, if a dynamic rule is received without these flags, it is assumed that the capability bit is set to 1 (disabled) and vulnerability bit is set to 0 (enabled). For predefined rules, currently configuring these two flags is not supported, so as of now all predefined rules are assumed to have capability bit set to 1 (disabled) and vulnerability bit set to 0 (enabled).

> • | Charging key (rating group)

> • | Other charging parameters: The charging parameters define whether online and offline charging interfaces are used, what is to be metered in offline charging, on what level the PCEF will report the usage related to the rule, and so on.

> Important: In this release, configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
> PCC rules also include Application Function (AF) record information for enabling charging correlation between the application and bearer layer if the AF has provided this information via the Rx interface. For IMS, this includes the IMS Charging Identifier (ICID) and flow identifiers.
> PCC Procedures over Gx Reference Point
> Request for PCC rules
> The PCEF, via the Gx reference point, requests for PCC rules in the following instances:

> • | At IP-CAN session establishment.

> • | At IP-CAN session modification.

> PCC rules can also be requested as a consequence of a failure in the PCC rule installation/activation or enforcement without requiring an event trigger.
> Provisioning of PCC rules
> The PCRF indicates, via the Rel. 7 Gx reference point, the PCC rules to be applied at the PCEF. This may be using one of the following procedures:

> • | PULL (provisioning solicited by the PCEF): In response to a request for PCC rules being made by the PCEF, the PCRF provisions PCC rules in the CC-Answer.

> • | PUSH (unsolicited provisioning): The PCRF may decide to provision PCC rules without obtaining a request from the PCEF. For example, in response to information provided to the PCRF via the Rx reference point, or in response to an internal trigger within the PCRF. To provision PCC rules without a request from the PCEF, the PCRF includes these PCC rules in an RA-Request message. No CCR/CCA messages are triggered by this RA-Request.

> For each request from the PCEF or upon unsolicited provision the PCRF provisions zero or more PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means:

> • | To activate or deactivate a PCC rule that is predefined at the PCEF, the PCRF provisions a reference to this PCC rule within a Charging-Rule-Name AVP and indicates the required action by choosing either the Charging-Rule-Install AVP or the Charging-Rule-Remove AVP.

> • | To install or modify a PCRF-provisioned PCC rule, the PCRF provisions a corresponding Charging-Rule-Definition AVP within a Charging-Rule-Install AVP.

> • | To remove a PCC rule which has previously been provisioned by the PCRF, the PCRF provisions the name of this rule as value of a Charging-Rule-Name AVP within a Charging-Rule-Remove AVP.

> • | If the PCRF performs the bearer binding, the PCRF may move previously installed or activated PCC rules from one IP CAN bearer to another IP CAN bearer.

> Important: In 11.0 and later releases, the maximum valid length for a charging rule name is 63 bytes. When the length of the charging rule name is greater than 63 bytes, a charging rule report with RESOURCES_LIMITATION as Rule-Failure-Code is sent. This charging rule report is sent only when the length of the rule name is lesser than 128 characters. When the charging rule name length is greater than or equal to 128 characters no charging rule report will be sent. In earlier releases, the length of the charging rule name constructed by PCRF was limited to 32 bytes.
> Selecting a PCC Rule for Uplink IP Packets
> If PCC is enabled, the PCEF selects the applicable PCC rule for each received uplink IP packet within an IP CAN bearer by evaluating the packet against uplink SDF filters of PCRF-provided or predefined active PCC rules of this IP CAN bearer in the order of the precedence of the PCC rules.
> Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
> Important: In 11.0 and later releases, IMSA and ECS allow the PCRF to install two (or more) dynamic rules with the same precedence value. In earlier releases, for two distinct dynamic rules having the same precedence the second rule used to be rejected.
> When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. Uplink IP packets which do not match any PCC rule of the corresponding IP CAN bearer are discarded.
> Selecting a PCC Rule and IP CAN Bearer for Downlink IP Packets
> If PCC is enabled, the PCEF selects a PCC rule for each received downlink IP packet within an IP CAN session by evaluating the packet against downlink SDF filters of PCRF-provided or predefined active PCC rules of all IP CAN bearers of the IP CAN session in the order of the precedence of the PCC rules.
> Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
> When a packet matches a SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. The Downlink IP Packet is transported within the IP CAN bearer where the selected PCC rule is mapped. Downlink IP packets that do not match any PCC rule of the IP CAN session are discarded.
> The following procedures are also supported:

> • | Indication of IP-CAN Bearer Termination Implications

> • | Indication of IP-CAN Session Termination: When the IP-CAN session is being terminated (for example, for GPRS when the last PDP Context within the IP-CAN session is being terminated) the PCEF contacts the PCRF.

> • | Request of IP-CAN Bearer Termination: If the termination of the last IP CAN bearer within an IP CAN session is requested, the PCRF and PCEF apply the “Request of IP-CAN Session Termination” procedure.

> • | Request of IP-CAN Session Termination: If the PCRF decides to terminate an IP CAN session due to an internal trigger or trigger from the SPR, the PCRF informs the PCEF. The PCEF acknowledges to the PCRF and instantly removes/deactivates all the PCC rules that have been previously installed or activated on that IP-CAN session.

> The PCEF applies IP CAN specific procedures to terminate the IP CAN session. For GPRS, the GGSN send a PDP context deactivation request with the teardown indicator set to indicate that the termination of the entire IP-CAN session is requested. Furthermore, the PCEF applies the “Indication of IP CAN Session Termination” procedure.
> In 12.0 and later releases, volume or rule information obtained from PCRF is discarded if the subscriber is going down.
> Volume Reporting Over Gx
> This section describes the 3GPP Rel. 9 Volume Reporting over Gx feature, which is supported by all products supporting Rel. 7 Gx interface.
> License Requirement
> The Volume Reporting over Gx feature requires the following license to be installed on the chassis:
> Cisco PID [ ASR5K-00-CS01CHGX ] Charging Over Gx, 1K sessions, or Starent Part Number [ 600-00-7822 ] Charging Over Gx.
> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> Supported Standards
> The Volume Reporting over Gx feature is based on the following standard:
> 3GPP TS 29.212 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).
> Feature Overview
> The Volume Reporting over Gx feature provides PCRF the capability to make real-time decisions based on the data usage by subscribers.
> Important: Volume Reporting over Gx is applicable only for volume quota.
> Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
> Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
> Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
> Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
> The following steps explain how Volume Reporting over Gx works:

> 1. | PCEF after receiving the message from PCRF parses the usage monitoring related AVPs, and sends the information to IMSA.

> 2. | IMSA updates the information to ECS.

> 3. | Once the ECS is updated with the usage monitoring information from PCRF, the PCEF (ECS) starts tracking the data usage.

> 4. | For session-level monitoring, the ECS maintains the amount of data usage.

> 5. | For PCC rule monitoring, usage is monitored with the monitoring key as the unique identifier. Each node maintains the usage information per monitoring key. When the data traffic is passed, the usage is checked against the usage threshold values and reported as described in the Usage Reporting section.

> 6. | The PCEF continues to track data usage after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session.

> Usage Monitoring

> • | Usage Monitoring at Session Level: PCRF subscribes to the session-level volume reporting over Gx by sending the Usage-Monitoring-Information AVP with the usage threshold level set in Granted-Service-Unit AVP and Usage-Monitoring-Level AVP set to SESSION_LEVEL(0). After the AVPs are parsed by DPCA, IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present. In 11.0 and later releases, Monitoring Key at session level is supported.

> In 12.0 and later releases, enabling and disabling session usage in a single message from PCRF is supported. This is supported only if the monitoring key is associated at session level.
> In 12.0 and later releases, monitoring of usage based on input/output octet threshold levels is supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
> Total threshold level along with UL/DL threshold level in the GSU AVP is treated as an error and only total threshold level is accepted.

> • | Usage Monitoring at Flow Level: PCRF subscribes to the flow-level volume reporting over Gx by sending the Usage-Monitoring-Information AVP with the usage threshold level set in Granted-Service-Unit AVP and Usage-Monitoring-Level AVP set to PCC_RULE_LEVEL(1). Monitoring Key is mandatory in case of a flow-level monitoring since the rules are associated with the monitoring key and enabling/disabling of usage monitoring at flow level can be controlled by PCRF using it. After the AVPs are parsed by DPCA, IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present.

> Usage monitoring is supported for static, predefined rules, and dynamic rule definitions.

> • | Usage Monitoring for Static Rules: In the case of static rules, the usage reporting on last rule removal associated with the monitoring key is not applicable. In this case only the usage monitoring information is received from the PCRF.

> • | Usage Monitoring for Predefined Rules: If the usage monitoring needs to be enabled for the predefined rules, PCRF sends the rule and the usage monitoring information containing the monitoring key and the usage threshold. The Monitoring key should be same as the one pre-configured in PCEF for that predefined rule. There can be multiple rules associated with the same monitoring key. Hence enabling a particular monitoring key would result in the data being tracked for multiple rules having the same monitoring key. After DPCA parses the AVPs IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present.

> • | Usage Monitoring for Dynamic Rules: If the usage monitoring needs to be enabled for dynamic ruledefs, PCRF provides the monitoring key along with a charging rule definition and the usage monitoring information containing the monitoring key and the usage threshold. This would result in the usage monitoring being done for all the rules associated with that monitoring key. After DPCA parses the AVPs, IMSA updates the information to ECS. Once ECS is updated, the usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present. Monitoring key for dynamic ruledef is dynamically assigned by PCRF which is the only difference with predefined rules in case of usage monitoring.

> Usage Reporting
> Usage at subscriber/flow level is reported to PCRF under the following conditions:

> • | Usage Threshold Reached: PCEF records the subscriber data usage and checks if the usage threshold provided by PCRF is reached. This is done for both session and rule level reporting.

> For session-level reporting, the actual usage volume is compared with the usage volume threshold.
> For rule-level reporting the rule that hits the data traffic is used to find out if the monitoring key is associated with it, and based on the monitoring key the data usage is checked. Once the condition is met, it reports the usage information to IMSA and continues monitoring. IMSA then triggers the CCR-U if “USAGE_REPORT” trigger is enabled by the PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the “Used-Service-Unit” set to the amount of data usage by subscriber.
> If PCRF does not provide a new usage threshold in the usage monitoring information as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no usage status is reported.
> In the non-standard Volume Reporting over Gx implementation, usage monitoring will be stopped once the threshold is breached, else the monitoring will continue. There will be no further usage reporting until the CCA is received.

> • | Usage Monitoring Disabled: If the PCRF explicitly disables the usage monitoring with Usage-Monitoring-Support AVP set to USAGE_MONITORING_DISABLED, the PCEF stops monitoring and reports the usage information (when the monitoring was enabled) to PCRF if the usage monitoring is disabled by PCRF as a result of CCR from PCEF which is not related to reporting usage, other external triggers, or a PCRF internal trigger. If the PCRF does not provide a new usage threshold as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no further usage status is reported.

> • | IP CAN Session Termination: When the IP CAN session is terminated, the accumulated subscriber usage information is reported to PCRF in the CCR-T from PCEF. If PCC usage level information is enabled by PCRF, the PCC usage will also be reported.

> • | PCC Rule Removal: When the PCRF deactivates the last PCC rule associated with a usage monitoring key, the PCEF sends a CCR with the data usage for that monitoring key. If the PCEF reports the last PCC rule associated with a usage monitoring key is inactive, the PCEF reports the accumulated usage for that monitoring key within the same CCR command if the Charging-Rule-Report AVP was included in a CCR command; otherwise, if the Charging-Rule-Report AVP was included in an RAA command, the PCEF sends a new CCR command to report accumulated usage for the usage monitoring key. In 12.0 and later releases, usage reporting on last rule deactivation using rule deactivation time set by PCRF is supported.

> • | PCRF Requested Usage Report: In 10.2 and later releases, the accumulated usage since the last report is sent even in case of immediate reporting, the usage is reset after immediate reporting and usage monitoring continued so that the subsequent usage report will have the usage since the current report. In earlier releases the behavior was to accumulate the so far usage in the next report.

> • | Release 12.2 onwards, usage reporting on bearer termination can be added. When a bearer is deleted due to some reason, the rules associated with the bearer will also be removed. So, the usage will be reported on the monitoring key(s) whose associated rule is the last one that is removed because of bearer termination.

> • | Revalidation Timeout: In the non-standard implementation, if usage monitoring and reporting is enabled and a revalidation timeout occurs, the PCEF sends a CCR to request PCC rules and reports all accumulated usage for all enabled monitoring keys since the last report (or since usage reporting was enabled if the usage was not yet reported) with the accumulated usage at IP-CAN session level (if enabled) and at service data flow level (if enabled) This is the default behavior.

> In the case of standard implementation, this must be enabled by CLI configuration.
> Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
> Once the usage is reported, the usage counter is reset to zero. The PCEF continues to track data usage from the zero value after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session and and the usage accumulated between the CCR-CCA will be discarded.
> For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
> How Rel. 7 Gx Works
> This section describes how dynamic policy and charging control for subscribers works with Rel. 7 Gx interface support in GPRS/UMTS networks.
> The following figure and table explain the IMSA process between a system and IMS components that is initiated by the UE.
> In this example, the Diameter Policy Control Application (DPCA) is the Gx interface to the PCRF. The interface between IMSA with PCRF is the Gx interface, and the interface between Session Manager (SessMgr) and Online Charging Service (OCS) is the Gy interface. Note that the IMSA service and DPCA are part of SessMgr on the system and separated in the figure for illustration purpose only.
> Rel. 7 Gx IMS Authorization Call Flow
> Rel. 7 Gx IMS Authorization Call flow Description

> Step | Description
> 1 | UE (IMS subscriber) requests for primary PDP context activation/creation.
> 2 | SessMgr allocates an IP address to the UE.
> 3 | SessMgr requests IMS Authorization, if IMSA is enabled for the APN.
> 4 | IMSA allocates resources for the IP CAN session and the bearer, and selects the PCRF to contact based on the user's selection key (for example, msisdn).
> 5 | IMSA requests the DPCA module to issue an auth request to the PCRF.
> 6 | DPCA sends a CCR initial message to the selected PCRF. This message includes the Context-Type AVP set to PRIMARY and the IP address allocated to the UE. The message may include the Bearer-Usage AVP set to GENERAL. The Bearer-Operation is set to Establishment. The Bearer ID is included if the PCRF does the bearer binding.
> 7 | PCRF may send preconfigured charging rules in CCA, if a preconfigured rule set for general purpose PDP context is provided in PCRF. The dynamic rules and the authorized QoS parameters could also be included by the PCRF.
> 8 | DPCA passes the charging rule definition, charging rule install, QoS information received from the PCRF, event triggers, and so on, along with the Bearer ID that corresponds to the rules received from the PCRF to IMSA. IMSA stores the information. If the Bearer ID is absent, and PCRF does the bearer binding, the rule is skipped. Whereas, if the Bearer ID is absent and the PCEF does the bearer binding, the rule is passed onto the ECS to perform bearer binding.
> 9 | DPCA calls the callback function registered with it by IMSA.
> 10 | IMSA stores the bearer authorized QoS information and notifies the SessMgr. Other PCRF provided information common to the entire PDP session (event trigger, primary/secondary OCS address, and so on) is stored within the IMSA. After processing the information, IMSA notifies the SessMgr about the policy authorization complete.
> 11 | If the validation of the rules fails in IMSA/DPCA, a failure is notified to PCRF containing the Charging-Rule-Report AVP. Else, IMSA initiates creation of ECS session. The APN name, primary/secondary OCS server address, and so on are sent to the ECS from the SessMgr.
> 12 | ECS performs credit authorization by sending CCR(I) to OCS with CC-Request-Type set to INITIAL_REQUEST to open the credit control session. This request includes the active Rulebase-Id (default rulebase ID from the APN/AAA) and GPRS specific attributes (for example, APN, UMTS QoS, and so on).
> 13 | OCS returns a CCA initial message that may activate a statically configured Rulebase and may include preemptive quotas.
> 14 | ECS responds to SessMgr with the response message.
> 15 | SessMgr requests IMSA for the dynamic rules.
> 16 | IMSA sends the dynamic rules to SessMgr. Note that until the primary PDP context is established, all RAR messages from the PCRF are rejected.
> 17 | SessMgr sends the dynamic rule information to the ECS. The gate flow status information and the QoS per flow (charging rule) information are also sent in the message.
> 18 | ECS activates the predefined rules received, and installs the dynamic rules received. Also, the gate flow status and the QoS parameters are updated by ECS as per the dynamic charging rules. The Gx rulebase is treated as an ECS group-of-ruledefs. The response message contains the Charging Rule Report conveying the status of the rule provisioning at the ECS. ECS performs PCEF bearer binding for rules without bearer ID.
> 19 | If the provisioning of rules fails partially, the context setup is accepted, and a new CCR-U is sent to the PCRF with the Charging-Rule-Report containing the PCC rule status for the failed rules. If the provisioning of rules fails completely, the context setup is rejected.
> 20 | Depending on the response for the PDP Context Authorization, SessMgr sends the response to the UE and activates/rejects the call. If the Charging-Rule-Report contains partial failure for any of the rules, the PCRF is notified, and the call is activated. If the Charging-Rule-Report contains complete failure, the call is rejected.
> 21 | Based on the PCEF bearer binding for the PCC rules at Step 18, the outcome could be one or more network-initiated PDP context procedures with the UE (Network Requested Update PDP Context (NRUPC) / Network Requested Secondary PDP Context Activation (NRSPCA)).

> ‌
> Configuring Rel. 7 Gx Interface
> To configure Rel. 7 Gx interface functionality, the IMS Authorization service must be configured at the context level, and then the APN configured to use the IMS Authorization service.
> To configure Rel. 7 Gx interface functionality:

> Step 1 | Configure IMS Authorization service at the context level for IMS subscriber in GPRS/UMTS network as described in the Configuring IMS Authorization Service at Context Level section.

> Step 2 | Verify your configuration as described in the Verifying the Configuration section.

> Step 3 | Configure an APN within the same context to use the IMS Authorization service for IMS subscriber as described in the Applying IMS Authorization Service to an APN section.

> Step 4 | Verify your configuration as described in the Verifying Subscriber Configuration section.

> Step 5 | Optional: Configure the Volume Reporting over Gx feature as described in the Configuring Volume Reporting over Gx section.

> Step 6 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Important: Commands used in the configuration examples 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 Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands.
> Configuring IMS Authorization Service at Context Level
> Use the following example to configure IMS Authorization service at context level for IMS subscribers in GPRS/UMTS networks:
> configure
> context <context_name>
> ims-auth-service <imsa_service_name>
> p-cscf discovery table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
> p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> } [ secondary { address <ip_address> | ipv6-address <ipv6_address> } ]
> policy-control
> diameter origin endpoint <endpoint_name>
> diameter dictionary <dictionary>
> diameter request-timeout <timeout_duration>
> diameter host-select table { { { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin } } | prefix-table { 1 | 2 } }
> diameter host-select row-precedence <precedence_value> table { { { 1 | 2 } host <host_name> [ realm <realm_id> ] [ secondary host <host_name> [ realm <realm_id> ] ] } | { prefix-table { 1 | 2 } msisdn-prefix-from <msisdn_prefix_from> msisdn-prefix-to <msisdn_prefix_to> host <host_name> [ realm <realm_id> ] [ secondary host <sec_host_name> [ realm <sec_realm_id> ] algorithm { active-standby | round-robin } ] } } [ -noconfirm ]
> diameter host-select reselect subscriber-limit <subscriber_limit> time-interval <duration>
> failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
> end
> Notes:

> • | <context_name> must be the name of the context where you want to enable IMS Authorization service.

> • | <imsa_service_name> must be the name of the IMS Authorization service to be configured for Rel. 7 Gx interface authentication.

> • | A maximum of 16 authorization services can be configured globally in a system. There is also a system limit for the maximum number of total configured services.

> • | To enable Rel. 7 Gx interface support, pertinent Diameter dictionary must be configured. For information on the specific Diameter dictionary to use, please contact your local service representative.

> • | When configuring the MSISDN prefix range based PCRF selection mechanism:

> To enable the Gx interface to connect to a specific PCRF for a range of subscribers configure msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the starting and ending MSISDNs respectively.
> To enable the Gx interface to connect to a specific PCRF for a specific subscriber, configure both msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the same MSISDN.
> In StarOS 8.1 and later releases, per MSISDN prefix range table a maximum of 128 rows can be added. In StarOS 8.0 and earlier releases, a maximum of 100 rows can be added.
> The MSISDN ranges must not overlap between rows.

> • | The Round Robin algorithm for PCRF selection is effective only over a large number of PCRF selections, and not at a granular level.

> • | Optional: To configure the Quality of Service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:

> qos-update-timeout <timeout_duration>

> • | Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:

> signaling-flag { deny | permit }
> signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]

> • | Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:

> traffic-policy general-pdp-context no-matching-gates direction { downlink | uplink } { forward | discard }

> • | To configure the PCRF host destinations configured in the GGSN/PCEF, use the diameter host-select CLI commands.

> • | To configure the GGSN/PCEF to use a pre-defined rule when the Gx fails, set the failure-handling cc-request-type CLI to continue. Policies available/in use will continue to be used and there will be no further interaction with the PCRF.

> • | For provisioning of default charging method, use the following configurations. For this, the AVPs Online and Offline will be sent in CCR-I message based on the configuration.

> • | To send Enable Online:

> configure
> active-charging service <ecs_service_name>
> charging-action <charging_action_name>
> cca charging credit
> exit

> • | To send Enable Offline:

> configure
> active-charging service <ecs_service_name>
> rulebase <rulebase_name>
> billing-records rf
> exit
> Verifying the Configuration
> To verify the IMS Authorization service configuration:

> Step 1 | Change to the context where you enabled IMS Authorization service by entering the following command:

> context <context_name>

> Step 2 | Verify the IMS Authorization service’s configurations by entering the following command:

> show ims-authorization service name <imsa_service_name>
> Applying IMS Authorization Service to an APN
> After configuring IMS Authorization service at the context-level, an APN within the same context must be configured to use the IMS Authorization service for an IMS subscriber.
> Use the following example to apply IMS Authorization service functionality to a previously configured APN within the context configured in the Configuring Rel. 7 Gx Interface section.
> configure
> context <context_name>
> apn <apn_name>
> ims-auth-service <imsa_service_name>
> active-charging rulebase <rulebase_name>
> end
> Notes:

> • | <context_name> must be the name of the context in which the IMS Authorization service was configured.

> • | <imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication in the context.

> • | For Rel. 7 Gx, the ECS rulebase must be configured in the APN.

> • | ECS allows change of rulebase via Gx for PCEF binding scenarios. When the old rulebase goes away, all the rules that were installed from that rulebase are removed. This may lead to termination of a few bearers (PDP contexts) if they are left without any rules. If there is a Gx message that changes the rulebase, and also activates some predefined rules, the rulebase change is made first, and the rules are activated from the new rulebase. Also, the rulebase applies to the entire call. All PDP contexts (bearers) in one call use the same ECS rulebase.

> • | For predefined rules configured in the ECS, MBR/GBR of a dynamic/predefined rule is checked before it is used for PCEF binding. All rules (dynamic as well as predefined) have to have an MBR associated with them and all rules with GBR QCI should have GBR also configured. So for predefined rules, one needs to configure appropriate peak-data-rate, committed-data-rate as per the QCI being GBR QCI or non-GBR QCI. For more information, in the ACS Charging Action Configuration Mode, see the flow limit-for-bandwidth CLI command.

> • | Provided interpretation of the Gx rulebase is chosen to be ECS group-of-ruledefs, in the Active Charging Service Configuration Mode configure the following command:

> policy-control charging-rule-base-name active-charging-group-of-ruledefs
> Verifying Subscriber Configuration
> Verify the IMS Authorization service configuration for subscriber(s) by entering the following command:
> show subscribers ims-auth-service <imsa_service_name>
> <imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication.
> Configuring Volume Reporting over Gx
> This section describes the configuration required to enable Volume Reporting over Gx.
> To enable Volume Reporting over Gx, use the following configuration:
> configure
> active-charging service <ecs_service_name>
> rulebase <rulebase_name>
> action priority <priority> dynamic-only ruledef <ruledef_name> charging-action <charging_action_name> monitoring-key <monitoring_key>
> exit
> exit
> context <context_name>
> ims-auth-service <imsa_service_name>
> policy-control
> event-update send-usage-report [ reset-usage ]
> end
> Notes:

> • | The maximum accepted monitoring key value by the PCEF is 4294967295. If the PCEF sends a greater value, the value is converted to an Unsigned Integer value.

> • | The event-update CLI which enables volume usage report to be sent in event updates is available only in 10.2 and later releases. The optional keyword reset-usage enables to support delta reporting wherein the usage is reported and reset at PCEF. If this option is not configured, the behavior is to send the usage information as part of event update but not reset at PCEF.

> Gathering Statistics
> This section explains how to gather Rel. 7 Gx statistics and configuration information.
> In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.
> Gathering Rel. 7 Gx Statistics and Information

> Statistics/Information | Action to perform
> Information and statistics specific to policy control in IMS Authorization service. | show ims-authorization policy-control statistics
> Information and statistics specific to the authorization servers used for IMS Authorization service. | show ims-authorization servers ims-auth-service
> Information of all IMS Authorization service. | show ims-authorization service all
> Statistics of IMS Authorization service. | show ims-authorization service statistics
> Information, configuration, and statistics of sessions active in IMS Authorization service. | show ims-authorization sessions all
> Complete information, configuration, and statistics of sessions active in IMS Authorization service. | show ims-authorization sessions full
> Summarized information of sessions active in IMS Authorization service. | show ims-authorization sessions summary
> Complete statistics for active charging service sessions. | show active-charging sessions full
> Information for all rule definitions configured in the service. | show active-charging ruledef all
> Information for all rulebases configured in the system. | show active-charging rulebase all
> Information on all group of ruledefs configured in the system. | show active-charging group-of-ruledefs all
> Information on policy gate counters and status. | show ims-authorization policy-gate { counters | status }

> ‌
> Rel. 8 Gx Interface
> Rel. 8 Gx interface support is available on the Cisco ASR 5000 platform running StarOS 10.0 or StarOS 11.0 and later releases.
> This section describes the following topics:

> • | HA/PSDSN Rel. 8 Gx Interface Support

> • | P-GW Rel. 8 Gx Interface Support

> HA/PDSN Rel. 8 Gx Interface Support
> This section provides information on configuring Rel. 8 Gx interface for HA and PDSN to support policy and charging control for subscribers in CDMA networks.
> The IMS service provides application support for transport of voice, video, and data independent of access support. Roaming IMS subscribers in CDMA networks require apart from other functionality sufficient, uninterrupted, consistent, and seamless user experience during an application session. It is also important that a subscriber gets charged only for the resources consumed by the particular IMS application used.
> It is recommended that before using the procedures in this section 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.
> This section describes the following topics:

> • | Introduction

> • | Licensing

> • | Supported Standards

> • | Terminology and Definitions

> • | How it Works

> • | Configuring HA/PDSN Rel. 8 Gx Interface Support

> • | Gathering Statistics

> Introduction
> For IMS deployment in CDMA networks the system uses Rel. 8 Gx interface for policy-based admission control support and flow-based charging (FBC). The Rel. 8 Gx interface supports enforcing policy control features like gating, bandwidth limiting, and so on, and also supports FBC. This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify Service Data Flows (SDF) and to do charging. Other parameters associated with the rules are used to enforce policy control.
> The PCC architecture allows operators to perform service-based QoS policy and FBC control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/HA/PDSN and the Policy and Charging Rules Function (PCRF). The client functionality lies with the HA/PDSN, therefore in the IMS Authorization (IMSA) scenario it is also called the Gateway. The PCEF function is provided by the Enhanced Charging Service (ECS). The Gx interface is implemented as a Diameter connection. The Gx messaging mostly involves installing/modifying/removing dynamic rules and activating/deactivating predefined rules.
> The Gx reference point is located between the Gateway/PCEF and the PCRF. This reference point is used for provisioning and removal of PCC rules from the PCRF to the Gateway/PCEF, and the transmission of traffic plane events from the Gateway/PCEF to the PCRF. The Gx reference point can be used for charging control, policy control, or both by applying AVPs relevant to the application.
> The following figure shows the reference points between elements involved in the policy and charging architecture.
> HA/PDSN Rel. 8 Gx PCC Logical Architecture
> Within the Gateway, the IMSA and DPCA modules handle the Gx protocol related functions (at the SessMgr) and the policy enforcement and charging happens at ECS. The Gy protocol related functions are handled within the DCCA module (at the ECS).
> The following figure shows the interaction between components within the Gateway.
> HA/PDSN Rel. 8 Gx PCC Architecture within PCEF
> Licensing
> HA/PDSN Rel. 8 Gx interface requires the following licenses to be installed on the chassis:

> • | Cisco PID [ ASR5K-00-CS01PIF ] Policy Interface, 1K sessions, or Starent Part Number [ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature.

> • | Cisco PID [ ASR5K-00-CS01ECG2 ] Enhanced Charging Bundle 2 1k Sessions, or Starent Part Number [ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — To enable and configure Diameter and ECS functionality.

> Supported Standards
> HA/PDSN Rel 8. Gx interface support is based on the following standards and RFCs:

> • | 3GPP TS 23.203 V8.3.0 (2008-09) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 8)

> • | 3GPP TS 29.212 V8.6.0 (2009-12) 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 8)

> • | 3GPP TS 29.213 V8.1.1 (2008-10) 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control signalling flows and QoS parameter mapping; (Release 8)

> • | RFC 3588, Diameter Base Protocol; September 2003

> • | RFC 4006, Diameter Credit-Control Application; August 2005

> Terminology and Definitions
> This section describes features and terminology pertaining to HA/PDSN Rel. 8 Gx functionality.
> Policy Control
> The process whereby the PCRF indicates to the PCEF how to control the IP-CAN session.
> Policy control comprises the following functions:

> • | Binding

> • | Gating Control

> • | Event Reporting

> • | QoS Control

> • | Other Features

> Binding
> In the HA/PDSN Rel. 8 Gx implementation, since there are no bearers within a MIP session the IP-CAN Bearer concept does not apply. Only authorized IP-CAN session is applicable.
> Gating Control
> Gating control is the blocking or allowing of packets belonging to an SDF, to pass through to the desired endpoint. A gate is described within a PCC rule and gating control is applied on a per SDF basis. The commands to open or close the gate leads to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed, all packets of the related IP flows are dropped. If the gate is open, the packets of the related IP flows are allowed to be forwarded.
> Event Reporting
> Important: Unconditional reporting of event triggers from PCRF to PCEF when PCEF has not requested for is not supported.
> Important: In the HA/PDSN Rel. 8 Gx implementation, only the AN_GW_CHANGE (21) event trigger is supported.
> Event reporting is the notification of and reaction to application events to trigger new behavior in the user plane as well as the reporting of events related to the resources in the Gateway (PCEF). Event triggers may be used to determine which IP-CAN session modification or specific event causes the PCEF to re-request PCC rules. Event trigger reporting from PCEF to PCRF, and provisioning of event triggers happens at IP-CAN session level.
> The Event Reporting Function (ERF) located in the PCEF, receives event triggers from PCRF during the Provision of PCC Rules procedure and performs event trigger detection. When an event matching the received event trigger occurs, the ERF reports the occurred event to the PCRF. If the provided event triggers are associated with certain parameter values then the ERF includes those values in the response to the PCRF.
> QoS Control
> Important: In the HA/PDSN Rel. 8 Gx implementation, only authorized IP-CAN Session is supported. Provisioning of authorized QoS per IP-CAN bearer, policy enforcement for authorized QoS per QCI, and coordination of authorized QoS scopes in mixed mode are not applicable.
> QoS control is the authorization and enforcement of the maximum QoS that is authorized for an SDF. In case of an aggregation of multiple SDFs, the combination of the authorized QoS information of the individual SDFs is provided as the authorized QoS for this aggregate. QoS control per SDF allows the PCC architecture to provide the PCEF with the authorized QoS to be enforced for each specific SDF.
> QoS authorization information may be dynamically provisioned by the PCRF, or it can be a predefined PCC rule in the PCEF. For a predefined PCC rule within the PCEF, the authorized QoS information takes affect when the PCC rule is activated. The PCEF combines the different sets of authorized QoS information, that is the information received from the PCRF and the information corresponding to the predefined PCC rules. The PCRF knows the authorized QoS information of the predefined PCC rules and takes this information into account when activating them. This ensures that the combined authorized QoS of a set of PCC rules that are activated by the PCRF is within the limitations given by the subscription and operator policies regardless of whether these PCC rules are dynamically provided, predefined, or both.
> Supported features include:

> • | Provisioning and Policy Enforcement of Authorized QoS: The PCRF may provide authorized QoS to the PCEF. The authorized QoS provides appropriate values for resources to be enforced.

> • | Policy Provisioning for Authorized QoS Per SDF: The provisioning of authorized QoS per SDF is a part of PCC rule provisioning procedure.

> • | Policy Enforcement for Authorized QoS Per SDF: If an authorized QoS is defined for a PCC rule, the PCEF limits the data rate of the SDF corresponding to that PCC rule not to exceed the maximum authorized bandwidth for the PCC rule by discarding packets exceeding the limit.

> • | Upon deactivation or removal of a PCC rule, the PCEF frees the resources reserved for that PCC rule.

> Other Features
> This section describes some of the other features.
> PCC Rule Error Handling
> If the installation/activation of one or more PCC rules fails, the PCEF communicates the failure to the PCRF by including one or more Charging-Rule-Report AVP(s) in either a CCR or an RAA command for the affected PCC rules. Within each Charging-Rule-Report AVP, the PCEF identifies the failed PCC rule(s) by including the Charging-Rule-Name AVP(s) or Charging-Rule-Base-Name AVP(s), identifies the failed reason code by including a Rule-Failure-Code AVP, and includes the PCC-Rule-Status AVP.
> If the installation/activation of one or more new PCC rules (that is, rules that were not previously successfully installed) fail, the PCEF sets the PCC-Rule-Status to INACTIVE for both the PUSH and the PULL modes.
> If a PCC rule was successfully installed/activated, but can no longer be enforced by the PCEF, the PCEF sends the PCRF a new CCR command and includes the Charging-Rule-Report AVP. The PCEF includes the Rule-Failure-Code AVP within the Charging-Rule-Report AVP and sets the PCC-Rule-Status to INACTIVE.
> In the HA/PDSN Gx implementation, the following rule failure codes are supported:

> • | RATING_GROUP_ERROR (2)

> • | SERVICE_IDENTIFIER_ERROR (3)

> • | GW/PCEF_MALFUNCTION (4)

> • | RESOURCES_LIMITATION (5)

> If the installation/activation of one or more PCC rules fails during RAR procedure, the RAA command is sent with the Experimental-Result-Code AVP set to DIAMETER_PCC_RULE_EVENT (5142).
> Time of the Day Procedures
> PCEF performs PCC rule request as instructed by the PCRF. Revalidation-Time when set by the PCRF, causes the PCEF to trigger a PCRF interaction to request PCC rules from the PCRF for an established IP-CAN session. The PCEF stops the timer once the PCEF triggers a REVALIDATION_TIMEOUT event.
> When installed, the PCC rule is inactive. If Rule-Activation-Time / Rule-Deactivation-Time is specified, then the PCEF sets the rule active / inactive after that time.
> Charging Control
> Important: In the HA/PDSN Rel. 8 Gx implementation, offline charging is not supported.
> Charging Control is the process of associating packets belonging to an SDF to a charging key, and applying online charging as appropriate. FBC handles differentiated charging of the bearer usage based on real-time analysis of the SDFs. In order to allow for charging control, the information in the PCC rule identifies the SDF and specifies the parameters for charging control. The PCC rule information may depend on subscription data.
> Online charging is supported via the Gy interface. In the case of online charging, it is possible to apply an online charging action upon PCEF events (for example, re-authorization upon QoS change).
> It is possible to indicate to the PCEF that interactions with the charging systems are not required for a PCC rule, that is to perform neither accounting nor credit control for this SDF, then neither online nor offline charging is performed.
> Supported Features:

> • | Provisioning of charging-related information for the IP-CAN Session

> • | Provisioning of charging addresses: Primary or secondary event charging function name (Online Charging Server (OCS) addresses)

> Important: In the HA/PDSN Rel. 8 Gx implementation, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.

> • | Provisioning of Default Charging Method

> Charging Correlation
> In the HA/PDSN Rel. 8 Gx implementation, Charging Correlation is not supported. PCRF provides the flow identifier, which uniquely identifies an IP flow in an IMS session.
> Policy and Charging Control (PCC) Rules
> A PCC rule enables the detection of an SDF and provides parameters for policy control and/or charging control. The purpose of the PCC rule is to:

> • | Detect a packet belonging to an SDF in case of both uplink and downlink IP flows based on SDF filters in the PCC rule (packet rule matching).

> If no PCC rule matches the packet, the packet is dropped.

> • | Identify the service that the SDF contributes to.

> • | Provide applicable charging parameters for an SDF.

> • | Provide policy control for an SDF.

> The PCEF selects a PCC rule for each packet received by evaluating received packets against SDF filters of PCC rules in the order of precedence of the PCC rules. When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied.
> There are two types of PCC rules:

> • | Dynamic PCC Rules: Rules dynamically provisioned by the PCRF to the PCEF via the Gx interface. These PCC rules may be either predefined or dynamically generated in the PCRF. Dynamic PCC rules can be activated, modified, and deactivated at any time.

> • | Predefined PCC Rule: Rules preconfigured in the PCEF by the operators. Predefined PCC rules can be activated or deactivated by the PCRF at any time. Predefined PCC rules within the PCEF may be grouped allowing the PCRF to dynamically activate a set of PCC rules over the Gx reference point.

> Important: A third kind of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
> A PCC rule consists of:

> • | Rule Name: The rule name is used to reference a PCC rule in the communication between the PCEF and PCRF.

> • | Service Identifier: The service identifier is used to identify the service or the service component the SDF relates to.

> • | Service Data Flow Filter(s): The service flow filter(s) is used to select the traffic for which the rule applies.

> • | Precedence: For different PCC rules with overlapping SDF filter, the precedence of the rule determines which of these rules is applicable. When a dynamic PCC rule and a predefined PCC rule have the same priority, the dynamic PCC rule takes precedence.

> • | Gate Status: The gate status indicates whether the SDF, detected by the SDF filter(s), may pass (gate is open) or will be discarded (gate is closed) in uplink and/or in downlink direction.

> • | QoS Parameters: The QoS information includes the QoS class identifier (authorized QoS class for the SDF), and authorized bitrates for uplink and downlink.

> • | Charging Key (rating group)

> • | Other charging parameters: The charging parameters define whether online charging interfaces are used, on what level the PCEF will report the usage related to the rule, etc.

> Important: Configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
> PCC rules also include Application Function (AF) record information for enabling charging correlation between the application and bearer layer if the AF has provided this information via the Rx interface. For IMS, this includes the IMS Charging Identifier (ICID) and flow identifiers.
> PCC Procedures over Gx Reference Point
> Request for PCC Rules
> The PCEF, via the Gx reference point, requests for PCC rules in the following instances:

> • | At IP-CAN session establishment

> • | At IP-CAN session modification

> PCC rules can also be requested as a consequence of a failure in the PCC rule installation/activation or enforcement without requiring an event trigger.
> Provisioning of PCC Rules
> The PCRF indicates, via the Rel. 8 Gx reference point, the PCC rules to be applied at the PCEF. This may be using one of the following procedures:

> • | PULL (provisioning solicited by the PCEF): In response to a request for PCC rules being made by the PCEF, the PCRF provisions PCC rules in the CC-Answer.

> • | PUSH (unsolicited provisioning): The PCRF may decide to provision PCC rules without obtaining a request from the PCEF. For example, in response to information provided to the PCRF via the Rx reference point, or in response to an internal trigger within the PCRF. To provision PCC rules without a request from the PCEF, the PCRF includes these PCC rules in an RA-Request message. No CCR/CCA messages are triggered by this RA-Request.

> For each request from the PCEF or upon unsolicited provisioning, the PCRF provisions zero or more PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means:

> • | To activate or deactivate a PCC rule that is predefined at the PCEF, the PCRF provisions a reference to this PCC rule within a Charging-Rule-Name AVP and indicates the required action by choosing either the Charging-Rule-Install AVP or the Charging-Rule-Remove AVP.

> • | To install or modify a PCRF-provisioned PCC rule, the PCRF provisions a corresponding Charging-Rule-Definition AVP within a Charging-Rule-Install AVP.

> • | To remove a PCC rule which has previously been provisioned by the PCRF, the PCRF provisions the name of this rule as value of a Charging-Rule-Name AVP within a Charging-Rule-Remove AVP.

> Selecting a PCC Rule for Uplink IP Packets
> If PCC is enabled, the PCEF selects the applicable PCC rule for each received uplink IP packet within an IP-CAN session by evaluating the packet against uplink SDF filters of PCRF-provided or predefined active PCC rules of this IP-CAN session in the order of the precedence of the PCC rules.
> Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
> When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. Uplink IP packets which do not match any PCC rule of the corresponding IP-CAN session are discarded.
> Selecting a PCC Rule for Downlink IP Packets
> If PCC is enabled, the PCEF selects a PCC rule for each received downlink IP packet within an IP-CAN session by evaluating the packet against downlink SDF filters of PCRF-provided or predefined active PCC rules of the IP-CAN session in the order of precedence of the PCC rules.
> Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
> When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. Downlink IP packets that do not match any PCC rule of the IP-CAN session are discarded.
> The following procedures are also supported:

> • | Indication of IP-CAN Session Termination: When the IP-CAN session is being terminated the PCEF contacts the PCRF.

> • | Request of IP-CAN Session Termination: If the PCRF decides to terminate an IP-CAN session due to an internal trigger or trigger from the SPR, the PCRF informs the PCEF. The PCEF acknowledges to the PCRF and instantly removes/deactivates all the PCC rules that have been previously installed or activated on that IP-CAN session.

> The PCEF applies IP-CAN specific procedures to terminate the IP-CAN session. The HA/PDSN sends a MIP Revocation Request with the teardown indicator set to indicate that the termination of the entire IP-CAN session is requested. Furthermore, the PCEF applies the “Indication of IP-CAN Session Termination” procedure.

> • | Use of the Supported-Features AVP during session establishment to inform the destination host about the required and optional features that the origin host supports.

> How it Works
> This section describes how HA/PDSN Rel. 8 Gx Interface support works.
> The following figure and table explain the IMS Authorization process between a system and IMS components that is initiated by the UE.
> In this example, the Diameter Policy Control Application (DPCA) is the Gx interface to the PCRF. The interface between IMSA with PCRF is the Gx interface, and the interface between Session Manager (SessMgr) and Online Charging Service (OCS) is the Gy interface. Note that the IMSA service and DPCA are part of SessMgr on the system and separated in the figure for illustration purpose only.
> HA/PDSN Rel. 8 Gx IMS Authorization Call Flow
> HA/PDSN Rel. 8 Gx IMS Authorization Call flow Description

> Step | Description
> 1 | UE (IMS subscriber) requests for MIP Registration Request.
> 2 | SessMgr allocates an IP address to the UE.
> 3 | SessMgr requests IMS Authorization, if IMSA is enabled for the subscriber. IMSA service can either be configured in the subscriber template, or can be received from the AAA.
> 4 | IMSA allocates resources for the IP-CAN session, and selects the PCRF to contact based on the user's selection key (for example, round-robin).
> 5 | IMSA requests the DPCA module to issue an auth request to the PCRF.
> 6 | DPCA sends a CCR initial message to the selected PCRF.
> 7 | PCRF may send preconfigured charging rules in CCA. The dynamic rules and the authorized QoS parameters could also be included by the PCRF.
> 8 | DPCA passes the charging rule definition, charging rule install, QoS information received from the PCRF, event triggers, etc. IMSA stores the information.
> 9 | DPCA calls the callback function registered with it by IMSA.
> 10 | PCRF-provided information common to the entire IP-CAN session (event trigger, primary/secondary OCS address, etc.) is stored within the IMSA. After processing the information, IMSA notifies the SessMgr about the policy authorization complete.
> 11 | If the validation of the rules fails in IMSA/DPCA, a failure is notified to PCRF containing the Charging-Rule-Report AVP. Else, IMSA initiates creation of ECS session. The primary/secondary OCS server address, etc. are sent to the ECS from the SessMgr.
> 12 | ECS performs credit authorization by sending CCR(I) to OCS with CC-Request-Type set to INITIAL_REQUEST to open the credit control session. This request includes the active Rulebase-Id (default rulebase ID from the AAA).
> 13 | OCS returns a CCA initial message that may activate a statically configured Rulebase and may include preemptive quotas.
> 14 | ECS responds to SessMgr with the response message.
> 15 | SessMgr requests IMSA for the dynamic rules.
> 16 | IMSA sends the dynamic rules to SessMgr. Note that until the MIP session is established, all RAR messages from the PCRF are rejected.
> 17 | SessMgr sends the dynamic rule information to the ECS. The gate flow status information and the QoS per flow (charging rule) information are also sent in the message.
> 18 | ECS activates the predefined rules received, and installs the dynamic rules received. Also, the gate flow status and the QoS parameters are updated by ECS as per the dynamic charging rules. The Gx rulebase is treated as an ECS group-of-ruledefs. The response message contains the Charging Rule Report conveying the status of the rule provisioning at the ECS.
> 19 | If the provisioning of rules fails partially, the context setup is accepted, and a new CCR-U is sent to the PCRF with the Charging-Rule-Report containing the PCC rule status for the failed rules. If the provisioning of rules fails completely, the context setup is rejected.
> 20 | Depending on the response for the MIP Session Authorization, SessMgr sends the response to the UE and activates/rejects the call. If the Charging-Rule-Report contains partial failure for any of the rules, the PCRF is notified, and the call is activated. If the Charging-Rule-Report contains complete failure, the call is rejected.

> ‌
> Configuring HA/PDSN Rel. 8 Gx Interface Support
> To configure HA/PDSN Rel. 8 Gx Interface functionality:

> 1. | At the context level, configure IMSA service for IMS subscribers as described in the Configuring IMS Authorization Service at Context Level section.

> 2. | Within the same context, configure the subscriber template to use the IMSA service as described in the Applying IMS Authorization Service to Subscriber Template section.

> 3. | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Important: Commands used in the configuration examples 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 Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands.
> Configuring IMS Authorization Service at Context Level
> Use the following example to configure IMSA service at context level for IMS subscribers:
> configure
> context <context_name>
> ims-auth-service <imsa_service_name>
> policy-control
> diameter origin endpoint <endpoint_name>
> diameter dictionary <dictionary>
> diameter request-timeout <timeout_duration>
> diameter host-select table { 1 | 2 } algorithm round-robin
> diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <primary_host_name> [ realm <primary_realm_id> ] [ secondary host <secondary_host_name> [ realm <secondary_realm_id> ] ] [ -noconfirm ]
> failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
> exit
> exit
> diameter endpoint <endpoint_name> [ -noconfirm ]
> origin realm <realm_name>
> use-proxy
> origin host <host_name> address <ip_address>
> no watchdog-timeout
> response-timeout <timeout_duration>
> connection timeout <timeout_duration>
> connection retry-timeout <timeout_duration>
> peer <primary_peer_name> [ realm <primary_realm_name> ] address <ip_address> [ port <port_number> ]
> peer <secondary_peer_name> [ realm <secondary_realm_name> ] address <ip_address> [ port <port_number> ]
> end
> Notes:

> • | <context_name> must be the name of the context where you want to enable IMSA service.

> • | <imsa_service_name> must be the name of the IMSA service to be configured for Rel. 8 Gx interface authentication.

> • | A maximum of 16 authorization services can be configured globally in a system. There is also a system limit for the maximum number of total configured services.

> • | To enable Rel. 8 Gx interface support, pertinent Diameter dictionary must be configured. For information on the specific Diameter dictionary to use, please contact your local service representative.

> • | The Round Robin algorithm for PCRF selection is effective only over a large number of PCRF selections, and not at a granular level.

> • | To configure the PCRF host destinations configured in the PCEF, use the diameter host-select CLI commands.

> • | To configure the PCEF to use a pre-defined rule when the Gx fails, set the failure-handling cc-request-type CLI to continue. Policies available/in use will continue to be used and there will be no further interaction with the PCRF.

> Verifying the IMSA Service Configuration
> To verify the IMSA service configuration:

> • | Change to the context where you enabled IMSA service by entering the following command:

> context <context_name>

> • | Verify the IMSA service’s configuration by entering the following command:

> show ims-authorization service name <imsa_service_name>
> Applying IMS Authorization Service to Subscriber Template
> After configuring IMSA service at the context-level, within the same context subscriber template must be configured to use the IMSA service for IMS subscribers.
> Use the following example to apply IMSA service functionality to subscriber template within the context previously configured in the Configuring IMS Authorization Service at Context Level section.
> configure
> context <context_name>
> subscriber default
> encrypted password <encrypted_password>
> ims-auth-service <imsa_service_name>
> ip access-group <access_group_name> in
> ip access-group <access_group_name> out
> ip context-name <context_name>
> mobile-ip home-agent <ip_address>
> active-charging rulebase <rulebase_name>
> end
> Notes:

> • | <context_name> must be the name of the context in which the IMSA service was configured.

> • | <imsa_service_name> must be the name of the IMSA service configured for IMS authentication in the context.

> • | The ECS rulebase must be configured in the subscriber template.

> • | Provided interpretation of the Gx rulebase (Charging-Rule-Base-Name AVP) from PCRF is chosen to be ECS group-of-ruledefs, configure the following command in the Active Charging Service Configuration Mode:

> policy-control charging-rule-base-name active-charging-group-of- ruledefs
> Verifying the Subscriber Configuration
> Verify the IMSA service configuration for subscriber(s) by entering the following command in the Exec CLI configuration mode:
> show subscribers ims-auth-service <imsa_service_name>
> Notes:
> <imsa_service_name> must be the name of the IMSA service configured for IMS authentication.
> Gathering Statistics
> This section explains how to gather Rel. 8 Gx statistics and configuration information.
> In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.
> Gathering HA/PDSN Rel. 8 Gx Statistics and Information

> Statistics/Information | Action to perform
> Information and statistics specific to policy control in IMS Authorization service. | show ims-authorization policy-control statistics
> Information and statistics specific to the authorization servers used for IMS Authorization service. | show ims-authorization servers ims-auth-service
> Information of all IMS Authorization service. | show ims-authorization service all
> Statistics of IMS Authorization service. | show ims-authorization service statistics
> Information, configuration, and statistics of sessions active in IMS Authorization service. | show ims-authorization sessions all
> Complete information, configuration, and statistics of sessions active in IMS Authorization service. | show ims-authorization sessions full
> Summarized information of sessions active in IMS Authorization service. | show ims-authorization sessions summary
> Complete statistics for active charging service sessions. | show active-charging sessions full
> Information for all rule definitions configured in the service. | show active-charging ruledef all
> Information for all rulebases configured in the system. | show active-charging rulebase all
> Information on all group of ruledefs configured in the system. | show active-charging group-of-ruledefs all
> Information on policy gate counters and status. | show ims-authorization policy-gate { counters | status }

> ‌
> P-GW Rel. 8 Gx Interface Support
> Introduction
> The Gx reference point is located between the Policy and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF) on the Packet Data Network (PDN) Gateway (P-GW). The Gx reference point is used for provisioning and removal of PCC rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control, or both, by applying AVPs relevant to the application.
> The PCEF is the functional element that encompasses policy enforcement and flow based charging functionality. This functional entity is located at the P-GW. The main functions include:

> • | Control over the user plane traffic handling at the gateway and its QoS.

> • | Service data flow detection and counting, as well as online and offline charging interactions.

> • | For a service data flow that is under policy control, the PCEF shall allow the service data flow to pass through the gateway if and only if the corresponding gate is open.

> • | For a service data flow that is under charging control, the PCEF shall allow the service data flow to pass through the gateway if and only if there is a corresponding active PCC rule and, for online charging, the OCS has authorized the applicable credit with that charging key.

> • | If requested by the PCRF, the PCEF shall report to the PCRF when the status of the related service data flow changes.

> • | In case the SDF is tunnelled at the BBERF, the PCEF shall inform the PCRF about the mobility protocol tunnelling header of the service data flows at IP-CAN session establishment.

> Terminology and Definitions
> This section describes features and terminology pertaining to Rel. 8 Gx functionality.
> Volume Reporting Over Gx
> This section describes the 3GPP Rel. 9 Volume Reporting over Gx feature.
> License Requirement
> The Volume Reporting over Gx feature requires the following license to be installed on the chassis:
> Cisco PID [ ASR5K-00-CS01CHGX ] Charging Over Gx, 1K sessions, or Starent Part Number [ 600-00-7822 ] Charging Over Gx.
> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> Supported Standards
> The Volume Reporting over Gx feature is based on the following standard:
> 3GPP TS 29.212 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).
> Feature Overview
> The Volume Reporting over Gx feature provides PCRF the capability to make real-time decisions based on the data usage by subscribers.
> Important: Volume Reporting over Gx is applicable only for volume quota.
> Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
> Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
> Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
> Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
> The following steps explain how Volume Reporting over Gx works:

> 1. | PCEF after receiving the message from PCRF parses the usage monitoring related AVPs, and sends the information to IMSA.

> 2. | IMSA updates the information to ECS.

> 3. | Once the ECS is updated with the usage monitoring information from PCRF, the PCEF (ECS) starts tracking the data usage.

> 4. | For session-level monitoring, the ECS maintains the amount of data usage.

> 5. | For PCC rule monitoring, usage is monitored with the monitoring key as the unique identifier. Each node maintains the usage information per monitoring key. When the data traffic is passed, the usage is checked against the usage threshold values and reported as described in the Usage Reporting section.

> 6. | The PCEF continues to track data usage after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session.

> Usage Monitoring

> • | Usage Monitoring at Session Level: PCRF subscribes to the session-level volume reporting over Gx by sending the Usage-Monitoring-Information AVP with the usage threshold level set in Granted-Service-Unit AVP and Usage-Monitoring-Level AVP set to SESSION_LEVEL(0). After the AVPs are parsed by DPCA, IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present. In 11.0 and later releases, Monitoring Key at session level is supported.

> In 12.0 and later releases, enabling and disabling session usage in a single message from PCRF is supported. This is supported only if the monitoring key is associated at session level.
> In 12.0 and later releases, monitoring of usage based on input/output octet threshold levels is supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
> Total threshold level along with UL/DL threshold level in the GSU AVP is treated as an error and only total threshold level is accepted.

> • | Usage Monitoring at Flow Level: PCRF subscribes to the flow-level volume reporting over Gx by sending the Usage-Monitoring-Information AVP with the usage threshold level set in Granted-Service-Unit AVP and Usage-Monitoring-Level AVP set to PCC_RULE_LEVEL(1). Monitoring Key is mandatory in case of a flow-level monitoring since the rules are associated with the monitoring key and enabling/disabling of usage monitoring at flow level can be controlled by PCRF using it. After the AVPs are parsed by DPCA, IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present.

> Usage monitoring is supported for static, predefined rules, and dynamic rule definitions.

> • | Usage Monitoring for Static Rules: In the case of static rules, the usage reporting on last rule removal associated with the monitoring key is not applicable. In this case only the usage monitoring information is received from the PCRF.

> • | Usage Monitoring for Predefined Rules: If the usage monitoring needs to be enabled for the predefined rules, PCRF sends the rule and the usage monitoring information containing the monitoring key and the usage threshold. The Monitoring key should be same as the one pre-configured in PCEF for that predefined rule. There can be multiple rules associated with the same monitoring key. Hence enabling a particular monitoring key would result in the data being tracked for multiple rules having the same monitoring key. After DPCA parses the AVPs IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present.

> • | Usage Monitoring for Dynamic Rules: If the usage monitoring needs to be enabled for dynamic ruledefs, PCRF provides the monitoring key along with a charging rule definition and the usage monitoring information containing the monitoring key and the usage threshold. This would result in the usage monitoring being done for all the rules associated with that monitoring key. After DPCA parses the AVPs, IMSA updates the information to ECS. Once ECS is updated, the usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present. Monitoring key for dynamic ruledef is dynamically assigned by PCRF which is the only difference with predefined rules in case of usage monitoring.

> Usage Reporting
> Usage at subscriber/flow level is reported to PCRF under the following conditions:

> • | Usage Threshold Reached: PCEF records the subscriber data usage and checks if the usage threshold provided by PCRF is reached. This is done for both session and rule level reporting.

> For session-level reporting, the actual usage volume is compared with the usage volume threshold.
> For rule-level reporting the rule that hits the data traffic is used to find out if the monitoring key is associated with it, and based on the monitoring key the data usage is checked. Once the condition is met, it reports the usage information to IMSA and continues monitoring. IMSA then triggers the CCR-U if “USAGE_REPORT” trigger is enabled by the PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the “Used-Service-Unit” set to the amount of data usage by subscriber.
> If PCRF does not provide a new usage threshold in the usage monitoring information as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no usage status is reported.
> In the non-standard Volume Reporting over Gx implementation, usage monitoring will be stopped once the threshold is breached, else the monitoring will continue. There will be no further usage reporting until the CCA is received.

> • | Usage Monitoring Disabled: If the PCRF explicitly disables the usage monitoring with Usage-Monitoring-Support AVP set to USAGE_MONITORING_DISABLED, the PCEF stops monitoring and reports the usage information (when the monitoring was enabled) to PCRF if the usage monitoring is disabled by PCRF as a result of CCR from PCEF which is not related to reporting usage, other external triggers, or a PCRF internal trigger. If the PCRF does not provide a new usage threshold as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no further usage status is reported.

> • | IP CAN Session Termination: When the IP CAN session is terminated, the accumulated subscriber usage information is reported to PCRF in the CCR-T from PCEF. If PCC usage level information is enabled by PCRF, the PCC usage will also be reported.

> • | PCC Rule Removal: When the PCRF deactivates the last PCC rule associated with a usage monitoring key, the PCEF sends a CCR with the data usage for that monitoring key. If the PCEF reports the last PCC rule associated with a usage monitoring key is inactive, the PCEF reports the accumulated usage for that monitoring key within the same CCR command if the Charging-Rule-Report AVP was included in a CCR command; otherwise, if the Charging-Rule-Report AVP was included in an RAA command, the PCEF sends a new CCR command to report accumulated usage for the usage monitoring key. In 12.0 and later releases, usage reporting on last rule deactivation using rule deactivation time set by PCRF is supported.

> • | PCRF Requested Usage Report: In 10.2 and later releases, the accumulated usage since the last report is sent even in case of immediate reporting, the usage is reset after immediate reporting and usage monitoring continued so that the subsequent usage report will have the usage since the current report. In earlier releases the behavior was to accumulate the so far usage in the next report.

> • | Release 12.2 onwards, usage reporting on bearer termination can be added. When a bearer is deleted due to some reason, the rules associated with the bearer will also be removed. So, the usage will be reported on the monitoring key(s) whose associated rule is the last one that is removed because of bearer termination.

> • | Revalidation Timeout: In the non-standard implementation, if usage monitoring and reporting is enabled and a revalidation timeout occurs, the PCEF sends a CCR to request PCC rules and reports all accumulated usage for all enabled monitoring keys since the last report (or since usage reporting was enabled if the usage was not yet reported) with the accumulated usage at IP-CAN session level (if enabled) and at service data flow level (if enabled) This is the default behavior.

> In the case of standard implementation, this must be enabled by CLI configuration.
> Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
> Once the usage is reported, the usage counter is reset to zero. The PCEF continues to track data usage from the zero value after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session and and the usage accumulated between the CCR-CCA will be discarded.
> For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
> Rel. 9 Interface
> Rel. 9 Gx interface support is available on the Cisco ASR 5000 platform running StarOS 12.2 and later releases.
> P-GW Rel. 9 Gx Interface Support
> Introduction
> The Gx reference point is located between the Policy and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF) on the Packet Data Network (PDN) Gateway (P-GW). The Gx reference point is used for provisioning and removal of PCC rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control, or both, by applying AVPs relevant to the application.
> The PCEF is the functional element that encompasses policy enforcement and flow based charging functionality. This functional entity is located at the P-GW. The main functions include:

> • | Control over the user plane traffic handling at the gateway and its QoS.

> • | Service data flow detection and counting, as well as online and offline charging interactions.

> • | For a service data flow that is under policy control, the PCEF shall allow the service data flow to pass through the gateway if and only if the corresponding gate is open.

> • | For a service data flow that is under charging control, the PCEF shall allow the service data flow to pass through the gateway if and only if there is a corresponding active PCC rule and, for online charging, the OCS has authorized the applicable credit with that charging key.

> • | If requested by the PCRF, the PCEF shall report to the PCRF when the status of the related service data flow changes.

> • | In case the SDF is tunnelled at the BBERF, the PCEF shall inform the PCRF about the mobility protocol tunnelling header of the service data flows at IP-CAN session establishment.

> Terminology and Definitions
> This section describes features and terminology pertaining to Rel. 9 Gx functionality.
> Volume Reporting Over Gx
> This section describes the 3GPP Rel. 9 Volume Reporting over Gx feature.
> License Requirement
> The Volume Reporting over Gx feature requires the following license to be installed on the chassis:
> Cisco PID [ ASR5K-00-CS01CHGX ] Charging Over Gx, 1K sessions, or Starent Part Number [ 600-00-7822 ] Charging Over Gx.
> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> Supported Standards
> The Volume Reporting over Gx feature is based on the following standard:
> 3GPP TS 29.212 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).
> Feature Overview
> The Volume Reporting over Gx feature provides PCRF the capability to make real-time decisions based on the data usage by subscribers.
> Important: Volume Reporting over Gx is applicable only for volume quota.
> Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
> Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
> Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
> Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
> The following steps explain how Volume Reporting over Gx works:

> 1. | PCEF after receiving the message from PCRF parses the usage monitoring related AVPs, and sends the information to IMSA.

> 2. | IMSA updates the information to ECS.

> 3. | Once the ECS is updated with the usage monitoring information from PCRF, the PCEF (ECS) starts tracking the data usage.

> 4. | For session-level monitoring, the ECS maintains the amount of data usage.

> 5. | For PCC rule monitoring, usage is monitored with the monitoring key as the unique identifier. Each node maintains the usage information per monitoring key. When the data traffic is passed, the usage is checked against the usage threshold values and reported as described in the Usage Reporting section.

> 6. | The PCEF continues to track data usage after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session.

> Usage Monitoring

> • | Usage Monitoring at Session Level: PCRF subscribes to the session-level volume reporting over Gx by sending the Usage-Monitoring-Information AVP with the usage threshold level set in Granted-Service-Unit AVP and Usage-Monitoring-Level AVP set to SESSION_LEVEL(0). After the AVPs are parsed by DPCA, IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present. In 11.0 and later releases, Monitoring Key at session level is supported.

> In 12.0 and later releases, enabling and disabling session usage in a single message from PCRF is supported. This is supported only if the monitoring key is associated at session level.
> In 12.0 and later releases, monitoring of usage based on input/output octet threshold levels is supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
> Total threshold level along with UL/DL threshold level in the GSU AVP is treated as an error and only total threshold level is accepted.

> • | Usage Monitoring at Flow Level: PCRF subscribes to the flow-level volume reporting over Gx by sending the Usage-Monitoring-Information AVP with the usage threshold level set in Granted-Service-Unit AVP and Usage-Monitoring-Level AVP set to PCC_RULE_LEVEL(1). Monitoring Key is mandatory in case of a flow-level monitoring since the rules are associated with the monitoring key and enabling/disabling of usage monitoring at flow level can be controlled by PCRF using it. After the AVPs are parsed by DPCA, IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present.

> Usage monitoring is supported for static, predefined rules, and dynamic rule definitions.

> • | Usage Monitoring for Static Rules: In the case of static rules, the usage reporting on last rule removal associated with the monitoring key is not applicable. In this case only the usage monitoring information is received from the PCRF.

> • | Usage Monitoring for Predefined Rules: If the usage monitoring needs to be enabled for the predefined rules, PCRF sends the rule and the usage monitoring information containing the monitoring key and the usage threshold. The Monitoring key should be same as the one pre-configured in PCEF for that predefined rule. There can be multiple rules associated with the same monitoring key. Hence enabling a particular monitoring key would result in the data being tracked for multiple rules having the same monitoring key. After DPCA parses the AVPs IMSA updates the information to ECS. Once ECS is updated usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present.

> • | Usage Monitoring for Dynamic Rules: If the usage monitoring needs to be enabled for dynamic ruledefs, PCRF provides the monitoring key along with a charging rule definition and the usage monitoring information containing the monitoring key and the usage threshold. This would result in the usage monitoring being done for all the rules associated with that monitoring key. After DPCA parses the AVPs, IMSA updates the information to ECS. Once ECS is updated, the usage monitoring is started and constantly checked with the usage threshold whenever the data traffic is present. Monitoring key for dynamic ruledef is dynamically assigned by PCRF which is the only difference with predefined rules in case of usage monitoring.

> Usage Reporting
> Usage at subscriber/flow level is reported to PCRF under the following conditions:

> • | Usage Threshold Reached: PCEF records the subscriber data usage and checks if the usage threshold provided by PCRF is reached. This is done for both session and rule level reporting.

> For session-level reporting, the actual usage volume is compared with the usage volume threshold.
> For rule-level reporting the rule that hits the data traffic is used to find out if the monitoring key is associated with it, and based on the monitoring key the data usage is checked. Once the condition is met, it reports the usage information to IMSA and continues monitoring. IMSA then triggers the CCR-U if “USAGE_REPORT” trigger is enabled by the PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the “Used-Service-Unit” set to the amount of data usage by subscriber.
> If PCRF does not provide a new usage threshold in the usage monitoring information as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no usage status is reported.
> In the non-standard Volume Reporting over Gx implementation, usage monitoring will be stopped once the threshold is breached, else the monitoring will continue. There will be no further usage reporting until the CCA is received.

> • | Usage Monitoring Disabled: If the PCRF explicitly disables the usage monitoring with Usage-Monitoring-Support AVP set to USAGE_MONITORING_DISABLED, the PCEF stops monitoring and reports the usage information (when the monitoring was enabled) to PCRF if the usage monitoring is disabled by PCRF as a result of CCR from PCEF which is not related to reporting usage, other external triggers, or a PCRF internal trigger. If the PCRF does not provide a new usage threshold as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no further usage status is reported.

> • | IP CAN Session Termination: When the IP CAN session is terminated, the accumulated subscriber usage information is reported to PCRF in the CCR-T from PCEF. If PCC usage level information is enabled by PCRF, the PCC usage will also be reported.

> • | PCC Rule Removal: When the PCRF deactivates the last PCC rule associated with a usage monitoring key, the PCEF sends a CCR with the data usage for that monitoring key. If the PCEF reports the last PCC rule associated with a usage monitoring key is inactive, the PCEF reports the accumulated usage for that monitoring key within the same CCR command if the Charging-Rule-Report AVP was included in a CCR command; otherwise, if the Charging-Rule-Report AVP was included in an RAA command, the PCEF sends a new CCR command to report accumulated usage for the usage monitoring key. In 12.0 and later releases, usage reporting on last rule deactivation using rule deactivation time set by PCRF is supported.

> • | PCRF Requested Usage Report: In 10.2 and later releases, the accumulated usage since the last report is sent even in case of immediate reporting, the usage is reset after immediate reporting and usage monitoring continued so that the subsequent usage report will have the usage since the current report. In earlier releases the behavior was to accumulate the so far usage in the next report.

> • | Release 12.2 onwards, usage reporting on bearer termination can be added. When a bearer is deleted due to some reason, the rules associated with the bearer will also be removed. So, the usage will be reported on the monitoring key(s) whose associated rule is the last one that is removed because of bearer termination.

> • | Revalidation Timeout: In the non-standard implementation, if usage monitoring and reporting is enabled and a revalidation timeout occurs, the PCEF sends a CCR to request PCC rules and reports all accumulated usage for all enabled monitoring keys since the last report (or since usage reporting was enabled if the usage was not yet reported) with the accumulated usage at IP-CAN session level (if enabled) and at service data flow level (if enabled) This is the default behavior.

> In the case of standard implementation, this must be enabled by CLI configuration.
> Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
> Once the usage is reported, the usage counter is reset to zero. The PCEF continues to track data usage from the zero value after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session and and the usage accumulated between the CCR-CCA will be discarded.
> For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
> Appendix D
> Gy Interface Support
> This chapter provides an overview of the Gy interface and describes how to configure the Gy interface.
> Gy interface support is available on the Cisco ASR 5000 platform running StarOS 9.0 or later releases for the following products:

> • | GGSN

> • | HA

> • | IPSG

> • | PDSN

> • | P-GW

> It is recommended that before using the procedures in this chapter 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.
> This chapter describes the following topics:

> • | Introduction

> • | Licensing

> • | Supported Standards

> • | Terminology and Definitions

> • | Configuring Gy Interface Support

> Introduction
> The Gy interface is the online charging interface between the PCEF/GW (Charging Trigger Function (CTF)) and the Online Charging System (Charging-Data-Function (CDF)).
> The Gy interface makes use of the Active Charging Service (ACS) / Enhanced Charging Service (ECS) for real-time content-based charging of data services. It is based on the 3GPP standards and relies on quota allocation. The Online Charging System (OCS) is the Diameter Credit Control server, which provides the online charging data to the PCEF/GW. With Gy, customer traffic can be gated and billed in an online or prepaid style. Both time- and volume-based charging models are supported. In these models differentiated rates can be applied to different services based on ECS shallow- or deep-packet inspection.
> In the simplest possible installation, the system will exchange Gy Diameter messages over Diameter TCP links between itself and one prepay server. For a more robust installation, multiple servers would be used. These servers may optionally share or mirror a single quota database so as to support Gy session failover from one server to the other. For a more scalable installation, a layer of proxies or other Diameter agents can be introduced to provide features such as multi-path message routing or message and session redirection features.
> The following figure shows the Gy reference point in the policy and charging architecture.
> PCC Logical Architecture
> The following figure shows the Gy interface between CTF/Gateway/PCEF/Client running ECS and OCS (CDF/Server). Within the PCEF/GW, the Gy protocol functionality is handled in the DCCA module (at the ECS).
> Gy Architecture
> Licensing
> Gy interface support requires the following license to be installed on the chassis:
> Cisco PID [ ASR5K-00-CS01ECG2 ] Enhanced Charging Bundle 2, 1K Sessions, or Starent Part Number [ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — To enable and configure Diameter and DCCA/Gy functionality with ECS.
> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> Supported Standards
> Gy interface support is based on the following standards:

> • | IETF RFC 4006: Diameter Credit Control Application; August 2005

> • | 3GPP TS 32.299 V9.6.0 (2010-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Diameter charging applications (Release 9)

> Features and Terminology
> This section describes features and terminology pertaining to Gy functionality.
> Charging Scenarios
> Important: Online charging for events (“Immediate Event Charging” and “Event Charging with Reservation”) is not supported. Only “Session Charging with Reservation” is supported.
> Session Charging with Reservation
> Session Charging with Unit Reservation is used for credit control of sessions.
> Decentralized Unit Determination and Centralized Rating
> In this scenario, the CTF requests the reservation of units prior to session supervision. An account debit operation is carried out following the conclusion of session termination.
> Centralized Unit Determination and Centralized Rating
> In this scenario, the CTF requests the OCS to reserve units based on the session identifiers specified by the CTF. An account debit operation is carried out following the conclusion of session.
> Decentralized Unit Determination and Decentralized Rating
> Important: Decentralized Rating is not supported in this release. Decentralized Unit determination is done using CLI configuration.
> In this scenario, the CTF requests the OCS to assure the reservation of an amount of the specified number of monetary units from the subscriber's account. An account debit operation that triggers the deduction of the amount from the subscriber's account is carried out following the conclusion of session establishment.
> Basic Operations
> Important: Immediate Event Charging is not supported in this release. “Reserve Units Request” and “Reserve Units Response” are done for Session Charging and not for Event Charging.
> Online credit control uses the basic logical operations “Debit Units” and “Reserve Units”.

> • | Debit Units Request; sent from CTF to OCS: After receiving a service request from the subscriber, the CTF sends a Debit Units Request to the OCS. The CTF may either specify a service identifier (centralised unit determination) or the number of units requested (decentralised unit determination). For refund purpose, the CTF sends a Debit Units Request to the OCS as well.

> • | Debit Units Response; sent from OCS to CTF: The OCS replies with a Debit Units Response, which informs the CTF of the number of units granted as a result of the Debit Units Request. This includes the case where the number of units granted indicates the permission to render the requested service. For refund purpose, the OCS replies with a Debit Units Response.

> • | Reserve Units Request; sent from CTF to OCS: Request to reserve a number of units for the service to be provided by an CTF. In case of centralised unit determination, the CTF specifies a service identifier in the Reserve Unit Request, and the OCS determines the number of units requested. In case of decentralised unit determination, the number of units requested is specified by the CTF.

> • | Reserve Units Response; sent from OCS to CTF: Response from the OCS which informs the CTF of the number of units that were reserved as a result of the “Reserve Units Request”.

> Session Charging with Unit Reservation (SCUR) use both the “Debit Units” and “Reserve Units” operations. SCUR uses the Session Based Credit Control procedure specified in RFC 4006. In session charging with unit reservation, when the “Debit Units” and “Reserve Units” operations are both needed, they are combined in one message.
> Important: Cost-Information, Remaining-Balance, and Low-Balance-Indication AVPs are not supported.
> The consumed units are deducted from the subscriber's account after service delivery. Thus, the reserved and consumed units are not necessarily the same. Using this operation, it is also possible for the CTF to modify the current reservation, including the return of previously reserved units.
> Re-authorization
> The server may specify an idle timeout associated with a granted quota. Alternatively, the client may have a configurable default value. The expiry of that timer triggers a re-authorization request.
> Mid-session service events (re-authorisation triggers) may affect the rating of the current service usage. The server may instruct the credit control client to re-authorize the quota upon a number of different session related triggers that can affect the rating conditions.
> When a re-authorization is trigger, the client reports quota usage. The reason for the quota being reported is notified to the server.
> Threshold based Re-authorization Triggers
> The server may optionally include an indication to the client of the remaining quota threshold that triggers a quota re-authorization.
> Termination Action
> The server may specify to the client the behavior on consumption of the final granted units; this is known as termination action.
> Diameter Base Protocol
> The Diameter Base Protocol maintains the underlying connection between the Diameter Client and the Diameter Server. The connection between the client and server is TCP based. There are a series of message exchanges to check the status of the connection and the capabilities.

> • | Capabilities Exchange Messages: Capabilities Exchange Messages are exchanged between the diameter peers to know the capabilities of each other and identity of each other.

> • | Capabilities Exchange Request (CER): This message is sent from the client to the server to know the capabilities of the server.

> • | Capabilities Exchange Answer (CEA): This message is sent from the server to the client in response to the CER message.

> Important: Acct-Application-Id is not parsed and if sent will be ignored by the PCEF/GW. In case the Result-Code is not DIAMETER_SUCCESS, the connection to the peer is closed.

> • | Device Watchdog Request (DWR): After the CER/CEA messages are exchanged, if there is no more traffic between peers for a while, to monitor the health of the connection, DWR message is sent from the client. The Device Watchdog timer (Tw) is configurable in PCEF/GW and can vary from 6 through 30 seconds. A very low value will result in duplication of messages. The default value is 30 seconds. On two consecutive expiries of Tw without a DWA, the peer is taken to be down.

> Important: DWR is sent only after Tw expiry after the last message that came from the server. Say if there is continuous exchange of messages between the peers, DWR might not be sent if (Current Time - Last message received time from server) is less than Tw.

> • | Device Watchdog Answer (DWA): This is the response to the DWR message from the server. This is used to monitor the connection state.

> • | Disconnect Peer Request (DPR): This message is sent to the peer to inform to shutdown the connection. PCEF/GW only receives this message. There is no capability currently to send the message to the diameter server.

> • | Disconnect Peer Answer (DPA): This message is the response to the DPR request from the peer. On receiving the DPR, the peer sends DPA and puts the connection state to “DO NOT WANT TO TALK TO YOU” state and there is no way to get the connection back except for reconfiguring the peer again.

> A timeout value for retrying the disconnected peer must be provided.

> • | Tw Timer Expiry Behavior: The connection between the client and the server is taken care by the DIABASE application. When two consecutive Tw timers are expired, the peer state is set to idle and the connection is retried to be established. All the active sessions on the connection are then transferred to the secondary connection if one is configured. All new session activations are also tried on the secondary connection.

> There is a connection timeout interval, which is also equivalent to Tw timer, wherein after a CER has been sent to the server, if there is no response received while trying to reestablish connection, the connection is closed and the state set to idle.
> Diameter Credit Control Application
> The Diameter Credit Control Application (DCCA) is a part of the ECS subsystem. For every prepaid customer with Diameter Credit Control enabled, whenever a session comes up, the Diameter server is contacted and quota for the subscriber is fetched.
> Quota Behavior
> Various forms of quotas are present that can be used to charge the subscriber in an efficient way. Various quota mechanisms provide the end user with a variety of options to choose from and better handling of quotas for the service provider.
> Time Quotas
> The Credit-Control server can send the CC-Time quota for the subscriber during any of the interrogation of client with it. There are also various mechanisms as discussed below which can be used in conjunction with time quota to derive variety of methods for customer satisfaction.

> • | Quota Consumption Time: The server can optionally indicate to the client that the quota consumption must be stopped after a period equal to the “Quota Consumption Time” in which no packets are received or at session termination, whichever is sooner. The idle period equal to the Quota Consumption Time is included in the reported usage. The quota is consumed normally during gaps in traffic of duration less than or equal to the Quota-Consumption-Time. Quota consumption resumes on receipt of a further packet belonging to the service data flow.

> If packets are allowed to flow during a CCR (Update)/CCA exchange, and the Quota-Consumption-Time AVP value in the provided quota is the same as in the previously provided quota, then the Quota-Consumption-Time runs normally through this procedure. For example, if 5 seconds of a 10 second QCT timer have passed when a CCR(U) is triggered, and the CCA(U) returns 2 seconds later, then the QCT timer will expire 3 seconds after the receipt of the CCA and the remaining unaccounted 5 seconds of usage will be recorded against the new quota even though no packets were transmitted with the new quota.
> A locally configurable default value in the client can be used if the server doesn't send the QCT in the CCA.

> • | Combinational Quota: Discrete-Time-Period (DTP) and Continuous-Time-Period (CTP) defines mechanisms that extends and generalize the Quota-Consumption-Time for consuming time-quota.

> • | Both DTP and CTP uses a “base-time-interval” that is used to create time-envelopes of quota used.

> • | Instead of consuming the quota linearly, DTP and CTP consumes the granted quota discretely in chunks of base-time-interval at the start of the each base-time-interval.

> • | Selection of one of this algorithm is based on the “Time-Quota-Mechanism” AVP sent by the server in CCA.

> • | Reporting usage can also be controlled by Envelope-Reporting AVP sent by the server in CCA during the quota grant. Based on the value of this AVP, the usage can be reported either as the usage per envelope or as usual cumulative usage for that grant.

> • | Discrete-Time-Period: The base-time-interval defines the length of the Discrete-Time-Period. So each time-envelope corresponds to exactly one Discrete-Time-Period. So when a traffic is detected, an envelope of size equal to Base-Time-Interval is created. The traffic is allowed to pass through the time-envelope. Once the traffic exceeds the base-time-interval another new envelope equal to the base-time-interval is created. This continues till the quota used exceeds the quota grant or reaches the threshold limit for that quota.

> • | Continuous-Time-Period: Continuous time period mechanism constructs time envelope out of consecutive base-time intervals in which the traffic occurred up to and including a base time interval which contains no traffic. Therefore the quota consumption continues within the time envelope, if there was traffic in the previous base time interval. After an envelope has closed, then the quota consumption resumes only on the first traffic following the closure of the envelope. The envelope for CTP includes the last base time interval which contains no traffic.

> The size of the envelope is not constant as it was in Parking meter. The end of the envelope can only be determined retrospectively.

> • | Quota Hold Time: The server can specify an idle timeout associated with a granted quota using the Quota-Holding-Time AVP. If no traffic associated with the quota is observed for this time, the client understands that the traffic has stopped and the quota is returned to the server. The client starts the quota holding timer when quota consumption ceases. This is always when traffic ceases, i.e. the timer is re-started at the end of each packet. It applies equally to the granted time quota and to the granted volume quota. The timer is stopped on sending a CCR and re-initialized on receiving a CCA with the previous used value or a new value of Quota-Holding-Time if received.

> Alternatively, if this AVP is not present, a locally configurable default value in the client is used. A Quota-Holding-Time value of zero indicates that this mechanism is not used.

> • | Quota Validity Time: The server can optionally send the validity time for the quota during the interrogation with the client. The Validity-Time AVP is present at the MSCC level and applies equally to the entire quota that is present in that category. The quota gets invalidated at the end of the validity time and a CCR-Update is sent to the server with the Used-Service-Units AVP and the reporting reason as VALIDITY_TIME. The entire quota present in that category will be invalidated upon Quota-Validity-Time expiry and traffic in that category will be passed or dropped depending on the configuration, till a CCA-Update is received with quota for that category.

> Validity-Time of zero is invalid. Validity-Time is relative and not absolute.
> Volume Quota
> The server sends the CC-Total-Octets AVP to provide volume quota to the subscriber. DCCA currently supports only CC-Total-Octets AVP, which applies equally to uplink and downlink packets. If the total of uplink and downlink packets exceeds the CC-Total-Octets granted, the quota is assumed to be exhausted.
> If CC-Input-Octets and/or CC-Output-Octets is provided, the quota is counted against CC-Input-Octets and/or CC-Output-Octets respectively.
> Important: Restricting usages based on CC-Input-Octets and CC_Output-Octets is not supported in this release.
> Units Quota
> The server can also send a CC-Service-Specific-Units quota which is used to have packets counted as units. The number of units per packet is a configurable option.
> Granting Quota
> Gy implementation assumes that whenever the CC-Total-Octets AVP is present, volume quota has been granted for both uplink and downlink.
> If the Granted-Service-Unit contains no data, Gy treats it as an invalid CCA.
> If the values are zero, it is assumed that no quota was granted.
> If the AVP contains the sub AVPs without any data, it is assumed to be infinite quota.
> Additional parameters relating to a category like QHT, QCT is set for the category after receiving a valid volume or time grant.
> If a default quota is configured for the subscriber, and subscriber traffic is received it is counted against the default quota. The default quota is applicable only to the initial request and is not regranted during the course of the session. If subscriber disconnects and reconnects, the default quota will be applied again for the initial request.
> Requesting Quota
> Quotas for a particular category type can be requested using the Requested-Service-Unit AVP in the CCR. The MSCC is filled with the Rating-Group AVP which corresponds to the category of the traffic and Requested-Service-Unit AVP without any data.
> The Requested-Service-Unit can contain the CC AVPs used for requesting specific quantity of time or volume grant. Gy CLI can be used to request quota for a category type.
> Alternatively quota can also be requested from the server preemptively for a particular category in CCR- I. When the server grants preemptive quota through the Credit control answer response, the quota will be used only when traffic is hit for that category. Quota can be preemptively requested from the Credit Control server from the CLI.
> Reporting Quota
> Quotas are reported to the server for number of reasons including:

> • | Threshold

> • | QHT Expiry

> • | Quota Exhaustion

> • | Rating Condition Change

> • | Forced Reauthorization

> • | Validity Time Expiry

> • | Final during Termination of Category Instance from Server

> For the above cases except for QHT and Final, the Requested-Service-Unit AVP is present in the CCR.
> Reporting Reason is present in CCR to let the server know the reason for the reporting of Quota. The Reporting-Reason AVP can be present either in MSCC level or at Used Service Unit (USU) level depending on whether the reason applies to all quotas or to single quota.
> When one of these conditions is met, a CCR Update is sent to the server containing a Multiple-Services-Credit-Control AVP(s) indicating the reason for reporting usage in the Reporting-Reason and the appropriate value(s) for Trigger, where appropriate. Where a threshold was reached, the DCCA still has the amount of quota available to it defined by the threshold.
> For all other reporting reasons the client discards any remaining quota and either discards future user traffic matching this category or allows user traffic to pass, or buffers traffic according to configuration.
> For Reporting-Reason of Rating Condition Change, Gy requires the Trigger Type AVP to be present as part of the CCR to indicate which trigger event caused the reporting and re-authorization request.
> For Reporting-Reason of end user service denied, this happens when a category is blacklisted by the credit control server, in this case a CCR-U is sent with used service unit even if the values as zero. When more quota is received from the server for that particular category, the blacklisting is removed.
> If a default quota has been set for the subscriber then the usage from the default quota is deducted from the initial GSU received for the subscriber for the Rating Group or Rating Group and Service ID combination.
> Default Quota Handling

> • | If default quota is set to 0, no data is passed/reported.

> • | If default quota is configured and default quota is not exhausted before OCS responds with quota, trafic is passed. Initial default quota used is counted against initial quota allocated. If quota allocated is less than the actual usage then actual usage is reported and additional quota requested. If no additional quota is available then traffic is denied.

> • | If default quota is not exhausted before OCS responds with denial of quota, gateway blocks traffic after OCS response. Gateway will report usage on default quota even in this case in CCR-U (FINAL) or CCR-T.

> • | if default quota is consumed before OCS responds, if OCS is not declared dead (see definition in use case 1 above) then traffic is blocked until OCS responds.

> Thresholds
> The Gy client supports the following threshold types:

> • | Volume-Quota-Threshold

> • | Time-Quota-Threshold

> • | Units-Quota-Threshold

> A threshold is always associated with a particular quota and a particular quota type. in the Multiple-Services-Credit-Control AVP, the Time-Quota-Threshold, Volume-Quota-Threshold, and Unit-Quota-Threshold are optional AVPs.
> They are expressed as unsigned numbers and the units are seconds for time quota, octets for volume quota and units for service specific quota. Once the quota has reached its threshold, a request for more quotas is triggered toward the server. User traffic is still allowed to flow. There is no disruption of traffic as the user still has valid quota.
> The Gy sends a CCR Update with a Multiple-Services-Credit-Control AVP containing usage reported in one or more User-Service-Unit AVPs, the Reporting-Reason set to THRESHOLD and the Requested-Service-Unit AVP without data.
> When quota of more than one type has been assigned to a category, each with its own threshold, then the threshold is considered to be reached once one of the unit types has reached its threshold even if the other unit type has not been consumed.
> When reporting volume quota, the DCCA always reports uplink and downlink separately using the CC-Input-Octets AVP and the CC-Output-Octets AVP, respectively.
> On receipt of more quotas in the CCA the Gy discard any quota not yet consumed since sending the CCR. Thus the amount of quota now available for consumption is the new amount received less any quota that may have been consumed since last sending the CCR.
> Conditions for Reauthorization of Quota
> Quota is re-authorized/requested from the server in case of the following scenarios:

> • | Threshold is hit

> • | Quota is exhausted

> • | Validity time expiry

> • | Rating condition change:

> • | Cellid change: Applicable only to GGSN and P-GW implementations.

> • | LAC change: Applicable only to GGSN and P-GW implementations.

> • | QoS change

> • | RAT change

> • | SGSN/Serving-Node change: Applicable only to GGSN and P-GW implementations.

> Discarding or Allowing or Buffering Traffic to Flow
> Whenever Gy is waiting for CCA from the server, there is a possibility of traffic for that particular traffic type to be encountered in the Gy. The behavior of what needs to be done to the packet is determined by the configuration. Based on the configuration, the traffic is either allowed to pass or discarded or buffered while waiting for CCA from the server.
> This behavior applies to all interrogation of client with server in the following cases:

> • | No quota present for that particular category

> • | Validity timer expiry for that category

> • | Quota exhausted for that category

> • | Forced Reauthorization from the server

> In addition to allowing or discarding user traffic, there is an option available in case of quota exhausted or no quota circumstances to buffer the traffic. This typically happens when the server has been requested for more quota, but a valid quota response has not been received from the server, in this case the user traffic is buffered and on reception of valid quota response from the server the buffered traffic is allowed to pass through.
> Procedures for Consumption of Time Quota

> • | QCT is zero: When QCT is deactivated, the consumption is on a wall-clock basis. The consumption is continuous even if there is no packet flow.

> • | QCT is active: When QCT is present in the CCA or locally configured for the session, then the consumption of quota is started only at the time of first packet arrival. The quota is consumed normally till last packet arrival plus QCT time and is passed till the next packet arrival.

> If the QCT value is changed during intermediate interrogations, then the new QCT comes into effect from the time the CCA is received. For instance, if the QCT is deactivated in the CCA, then quota consumptions resume normally even without any packet flow. Or if the QCT is activated from deactivation, then the quota consumption resume only after receiving the first packet after CCA.

> • | QHT is zero: When QHT is deactivated, the user holds the quota indefinitely in case there is no further usage (for volume quota and with QCT for time quota). QHT is active between the CCA and the next CCR.

> • | QHT is non-zero: When QHT is present in CCA or locally configured for the session, then after a idle time of QHT, the quota is returned to the server by sending a CCR-Update and reporting usage of the quota. On receipt of CCR-U, the server does not grant quota. QHT timer is stopped on sending the CCR and is restarted only if QHT is present in the CCA.

> QHT timer is reset every time a packet arrives.
> Envelope Reporting
> The server may determine the need for additional detailed reports identifying start time and end times of specific activity in addition to the standard quota management. The server controls this by sending a CCA with Envelope-Reporting AVP with the appropriate values. The DCCA client, on receiving the command, will monitor for traffic for a period of time controlled by the Quota-Consumption-Time AVP and report each period as a single envelope for each Quota-Consumption-Time expiry where there was traffic. The server may request envelope reports for just time or time and volume. Reporting the quota back to the server, is controlled by Envelope AVP with Envelope-Start-Time and Envelope-End-Time along with usage information.
> Credit Control Request
> Credit Control Request (CCR) is the message that is sent from the client to the server to request quota and authorization. CCR is sent before the establishment of MIP session, and at the termination of the MIP session. It can be sent during service delivery to request more quotas.

> • | Credit Control Request - Initial (CCR-I)

> • | Credit Control Request - Update (CCR-U)

> • | Credit Control Request - Terminate (CCR-T)

> • | Credit Control Answer (CCA)

> • | Credit Control Answer - Initial (CCA-I)

> • | Credit Control Answer - Update (CCA-U)

> If the MSCC AVP is missing in CCA-Update it is treated as invalid CCA and the session is terminated.

> • | Credit Control Answer - Terminate (CCA-T)

> The following figure depicts the call flow for a simple call request in the GGSN / P-GW /IPSG Gy implementation.
> Gy Call Flow for Simple Call Request
> The following figure depicts the call flow for a simple call request in the HA Gy implementation.
> Gy Call Flow for Simple Call Request
> Tx Timer Expiry Behavior
> A timer is started each time a CCR is sent out from the system, and the response has to arrive within Tx time. The timeout value is configurable in the Diameter Credit Control Configuration mode.
> In case there is no response from the Diameter server for a particular CCR, within Tx time period, and if there is an alternate server configured, the CCR is sent to the alternate server after Tw expiry as described in “Tw Timer expiry behavior” section.
> It also depends on the Credit-Control-Session-Failover AVP value for the earlier requests. If this AVP is present and is coded to FAILOVER_SUPPORTED then the credit-control message stream is moved to the secondary server, in case it is configured. If the AVP value is FAILOVER_NOT SUPPORTED, then the call is dropped in case of failures, even if a secondary server is configured.
> Redirection
> In the Final-Unit-Indication AVP, if the Final-Action is REDIRECT or Redirect-Server AVP is present at command level, redirection is performed.
> The redirection takes place at the end of consumption of quota of the specified category. The GY sends a CCR-Update without any RSU or Rating-Group AVP so that the server does not give any more quotas.
> If the Final-Action AVP is RESTRICT_ACCESS, then according to the settings in Restriction-Filter-Rule AVP or Filter-Id AVP. GY sends CCR-Update to the server with used quota.
> Triggers
> The Diameter server can provide with the triggers for which the client should reauthorize a particular category. The triggers can be configured locally as well but whatever trigger is present in the CCA from the server will have precedence.
> Important: In this release, Gy triggers are not supported for HA.
> The trigger types that are supported are:

> • | SGSN/Serving-Node Change

> • | QoS Change - Any

> • | RAT Change

> • | LAC Change

> • | CellID Change

> On any event as described in the Trigger type happens, the client reauthorizes quota with the server. The reporting reason is set as RATING_CONDITION_CHANGE.
> Tariff Time Change
> The tariff change mechanism applies to each category instance active at the time of the tariff change whenever the server indicated it should apply for this category.
> The concept of dual coupon is supported. Here the server grants two quotas, which is accompanied by a Tariff-Time-Change, in this case the first granted service unit is used until the tariff change time, once the tariff change time is reached the usage is reported up to the point and any additional usage is not accumulated, and then the second granted service unit is used.
> If the server expects a tariff change to occur within the validity time of the quota it is granting, then it includes the Tariff-Time-Change AVP in the CCA. The DCCA report usage, which straddles the change time by sending two instances of the Used-Service-Unit AVP, one with Tariff-Change-Usage set to UNIT_BEFORE_TARIFF_CHANGE, and one with Tariff-Change-Usage set to UNIT_AFTER_TARIFF_CHANGE, and this independently of the type of units used by application. Both Volume and Time quota are reported in this way.
> The Tariff time change functionality can as well be done using Validity-Time AVP, where in the Validity-Time is set to Tariff Time change and the client will reauthorize and get quota at Validity-Time expiry. This will trigger a lot of reauthorize request to the server at a particular time and hence is not advised.
> Tariff-Time-Usage AVP along with the Tariff-Time-Change AVP in the answer message to the client indicates that the quotas defined in Multiple-Services-Credit-Control are to be used before or after the Tariff Time change. Two separate quotas are allocated one for before Tariff-Time-Change and one for after Tariff-Time-Change. This gives the flexibility to the operators to allocate different quotas to the users for different periods of time. In this case, the DCCA should not send the Before-Usage and After-Usage counts in the update messages to the server. When Tariff-Time-Change AVP is present without Tariff-Time-Usage AVP in the answer message, then the quota is used as in single quota mechanism and the client has to send before usage and after usage quotas in the updates to the server.
> Important: In this release, Gy does not support UNIT_INDETERMINATE value.
> Final Unit Indication
> The Final-Unit-Indication AVP can be present in the CCA from the server to indicate that the given quota is the final quota from the server and the corresponding action as specified in the AVP needs to be taken.
> Final Unit Indication at Command Level
> Gy currently does not support FUI AVP at command level. If this AVP is present at command level it is ignored. If the FUI AVP is present at command level and the Final-Unit-Action AVP set to TERMINATE, Gy sends a CCR-Terminate at the expiry of the quota, with all quotas in the USU AVP.
> Important: FUI AVP at command level is only supported for Terminate action.
> Final Unit Indication at MSCC Level
> If the Final-Unit-Indication AVP is present at MSCC level, and if the Final-Unit-Action AVP is set to TERMINATE, a CCR-Update is sent at the expiry of the allotted quota and report the usage of the category that is terminated.
> For information on redirection cases refer to Redirection section.
> Credit Control Failure Handling
> CCFH AVP defines what needs to be done in case of failure of any type between the client and the server. The CCFH functionality can be defined in configuration but if the CCFH AVP is present in the CCA, it takes precedence. CCFH AVP gives flexibility to have different failure handling.
> Gy supports the following Failure Handling options:

> • | TERMINATE

> • | CONTINUE

> • | RETRY AND TERMINATE

> CCFH with Failover Supported
> In case there is a secondary server is configured and if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the following behavior takes place:

> • | Terminate: On any Tx expiry for the CCR-I the message is discarded and the session is torn down. In case of CCR-Updates and Terminates the message is sent to the secondary server after response timeout and the session is proceeded with the secondary server. In case there is a failure with the secondary server too, the session is torn down.

> • | Continue: On any Tx expiry, the message is sent to the secondary server after response timeout and the session is proceeded with the secondary server. In case there is a failure with the secondary server too, the session is still established, but without quota management.

> • | Retry and Terminate: On any Tx expiry, the message is sent to the secondary server after the response timeout. In case there is a failure with secondary server too, the session is taken down.

> CCFH with Failover Not Supported
> In case there is a secondary server configured and if the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the following behavior takes place as listed below. Same is the case if there is no secondary server configured on the system.

> • | Terminate: On any Tx expiry, the session is taken down.

> • | Continue: On any Tx expiry, the session is still established, but without quota management.

> • | Retry and Terminate: On any Tx expiry, the session is taken down.

> Failover Support
> The CC-Session-Failover AVP and the Credit-Control-Failure-Handling (CCFH) AVP may be returned by the CC server in the CCA-I, and are used by the DCCA to manage the failover procedure. If they are present in the CCA they override the default values that are locally configured in the system.
> If the CC-Session-Failover is set to FAILOVER_NOT_SUPPORTED, a CC session will never be moved to an alternative Diameter Server.
> If the value of CC-Session-Failover is set to FAILOVER_SUPPORTED, then the Gy attempts to move the CC session to the alternative server when it considers a request to have failed, i.e:

> • | On receipt of result code “DIAMETER_UNABLE_TO_DELIVER”, “DIAMETER_TOO_BUSY”, or “DIAMETER_LOOP_DETECTED”.

> • | On expiry of the request timeout.

> • | On expiry of Tw without receipt of DWA, if the server is connected directly to the client.

> The CCFH determines the behavior of the client in fault situations. If the Tx timer expires then based on the CCFH value the following actions are taken:

> • | CONTINUE: Allow the MIP session and user traffic for the relevant category or categories to continue, regardless of the interruption (delayed answer). Note that quota management of other categories is not affected.

> • | TERMINATE: Terminate the MIP session, which affects all categories.

> • | RETRY_AND_TERMINATE: Allow the MIP session and user traffic for the relevant category or categories to continue, regardless of the interruption (delayed answer). The client retries to send the CCR when it determines a failure-to-send condition and if this also fails, the MIP session is then terminated.

> After the failover action has been attempted, and if there is still a failure to send or temporary error, depending on the CCFH action, the following action is taken:

> • | CONTINUE: Allow the MIP session to continue.

> • | TERMINATE: Terminate the MIP session.

> • | RETRY_AND_TERMINATE: Terminate the MIP session.

> Recovery Mechanisms
> DCCA supports a recovery mechanism that is used to recover sessions without much loss of data in case of Session Manager failures. There is a constant check pointing of Gy data at regular intervals and at important events like update, etc.
> For more information on recovery mechanisms, please refer to the Cisco ASR 5000 Series System Administration Guide.
> Error Mechanisms
> Unsupported AVPs
> All unsupported AVPs from the server with “M” bit set are ignored.
> Invalid Answer from Server
> If there is an invalid answer from the server, Gy action is dependent on the CCFH setting:

> • | In case of continue, the MIP session context is continued without further control from Gy.

> • | In case of terminate and retry-and-terminate, the MIP session is terminated and a CCR-T is sent to the diameter server.

> Result Code Behavior

> • | DIAMETER_RATING_FAILED: On reception of this code, Gy discards all traffic for that category and does not request any more quota from the server. This is supported at the MSCC level and not at the command level.

> • | DIAMETER_END_USER_SERVICE_DENIED: On reception of this code, Gy temporarily blacklists the category and further traffic results in requesting new quota from the server. This is supported at the MSCC level and not at the command level.

> • | DIAMETER_CREDIT_LIMIT_REACHED: On reception of this code, Gy discards all traffic for that category and waits for a configured time, after which if there is traffic for the same category requests quota from the server. This is supported at the MSCC level and not at the command level.

> • | DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE: On reception of this code, Gy allows the session to establish, but without quota management. This is supported only at the command level and not at the MSCC level.

> • | DIAMETER_USER_UNKNOWN: On reception of this code, DCCA does not allow the credit control session to get established, the session is terminated. This result code is supported only at the command level and not at the MSCC level.

> For all other permanent/transient failures, Gy action is dependent on the CCFH setting.
> Supported AVPs
> The Gy functionality supports the following AVPs:

> • | Supported Diameter Credit Control AVPs specified in RFC 4006:

> • | CC-Input-Octets (AVP Code: 412):

> Gy supports this AVP only in USU.

> • | CC-Output-Octets (AVP Code: 414):

> Gy supports this AVP only in USU.

> • | CC-Request-Number (AVP Code: 415)

> • | CC-Request-Type (AVP Code: 416):

> Gy currently does not support EVENT_REQUEST value.

> • | CC-Service-Specific-Units (AVP Code: 417)

> • | CC-Session-Failover (AVP Code: 418)

> • | CC-Time (AVP Code: 420):

> Gy does not support this AVP in RSU.

> • | CC-Total-Octets (AVP Code: 421):

> Gy does not support this AVP in RSU.

> • | Credit-Control-Failure-Handling (AVP Code: 427)

> • | Final-Unit-Action (AVP Code: 449):

> Supported at Multiple-Services-Credit-Control grouped AVP level and not at command level.

> • | Final-Unit-Indication (AVP Code: 430):

> Fully supported at Multiple-Services-Credit-Control grouped AVP level and partially supported (TERMINATE) at command level.

> • | Granted-Service-Unit (AVP Code: 431)

> • | Multiple-Services-Credit-Control (AVP Code: 456)

> • | Multiple-Services-Indicator (AVP Code: 455)

> • | Rating-Group (AVP Code: 432)

> • | Redirect-Address-Type (AVP Code: 433):

> Gy currently supports only URL (2) value.

> • | Redirect-Server (AVP Code: 434)

> • | Redirect-Server-Address (AVP Code: 435)

> • | Requested-Service-Unit (AVP Code: 437)

> • | Result-Code (AVP Code: 268)

> • | Service-Context-Id (AVP Code: 461)

> • | Service-Identifier (AVP Code: 439)

> • | Subscription-Id (AVP Code: 443)

> • | Subscription-Id-Data (AVP Code: 444)

> • | Subscription-Id-Type (AVP Code: 450)

> • | Tariff-Change-Usage (AVP Code: 452):

> Gy does NOT support UNIT_INDETERMINATE (2) value.

> • | Tariff-Time-Change (AVP Code: 451)

> • | Used-Service-Unit (AVP Code: 446):

> Gy sends only incremental counts for all the AVPs from the last CCA-U.

> • | User-Equipment-Info (AVP Code: 458)

> • | User-Equipment-Info-Type (AVP Code: 459):

> Gy currently supports only IMEISV value.
> Cisco GGSN and P-GW support IMEISV by default.

> • | User-Equipment-Info-Value (AVP Code: 460)

> • | Validity-Time (AVP Code: 448)

> • | Supported 3GPP specific AVPs specified in 3GPP TS 32.299:

> • | 3GPP-Charging-Characteristics (AVP Code: 13)

> • | 3GPP-Charging-Id (AVP Code: 2)

> • | 3GPP-GGSN-MCC-MNC (AVP Code: 9)

> • | 3GPP-GPRS-QoS-Negotiated-Profile (AVP Code: 5)

> • | 3GPP-IMSI-MCC-MNC (AVP Code: 8)

> • | 3GPP-NSAPI (AVP Code: 10)

> • | 3GPP-PDP-Type (AVP Code: 3)

> • | 3GPP-RAT-Type (AVP Code: 21)

> • | 3GPP-Selection-Mode (AVP Code: 12)

> • | 3GPP-Session-Stop-Indicator (AVP Code: 11)

> • | 3GPP-SGSN-MCC-MNC (AVP Code: 18)

> • | 3GPP-User-Location-Info (AVP Code: 22)

> • | Base-Time-Interval (AVP Code: 1265)

> • | Charging-Rule-Base-Name (AVP Code: 1004)

> • | Envelope (AVP Code: 1266)

> • | Envelope-End-Time (AVP Code: 1267)

> • | Envelope-Reporting (AVP Code: 1268)

> • | Envelope-Start-Time (AVP Code: 1269)

> • | GGSN-Address (AVP Code: 847)

> • | Offline-Charging (AVP Code: 1278)

> • | PDP-Address (AVP Code: 1227)

> • | PDP-Context-Type (AVP Code: 1247)

> This AVP is present only in CCR-I.

> • | PS-Information (AVP Code: 874)

> • | Quota-Consumption-Time (AVP Code: 881):

> This optional AVP is present only in CCA.

> • | Quota-Holding-Time (AVP Code: 871):

> This optional AVP is present only in the CCA command. It is contained in the Multiple-Services-Credit-Control AVP. It applies equally to the granted time quota and to the granted volume quota.

> • | Reporting-Reason (AVP Code: 872):

> Gy currently does not support the POOL_EXHAUSTED (8) value. It is used in case of credit-pooling which is currently not supported.

> • | Service-Information (AVP Code: 873):

> Only PS-Information is supported.

> • | SGSN-Address (AVP Code: 1228)

> • | Time-Quota-Mechanism (AVP Code: 1270):

> The Gy server may include this AVP in an Multiple-Services-Credit-Control AVP when granting time quota.

> • | Time-Quota-Threshold (AVP Code: 868)

> • | Time-Quota-Type (AVP Code: 1271)

> • | Trigger (AVP Code: 1264)

> • | Trigger-Type (AVP Code: 870)

> • | Unit-Quota-Threshold (AVP Code: 1226)

> • | Volume-Quota-Threshold (AVP Code: 869)

> • | Supported Diameter AVPs specified in 3GPP TS 32.299 V8.1.0:

> • | Auth-Application-Id (AVP Code: 258)

> • | Destination-Host (AVP Code: 293)

> • | Destination-Realm (AVP Code: 283)

> • | Disconnect-Cause (AVP Code: 273)

> • | Error-Message (AVP Code: 281)

> • | Event-Timestamp (AVP Code: 55)

> • | Failed-AVP (AVP Code: 279)

> • | Multiple-Services-Credit-Control (AVP Code: 456)

> • | Origin-Host (AVP Code: 264)

> • | Origin-Realm (AVP Code: 296)

> • | Origin-State-Id (AVP Code: 278)

> • | Redirect-Host (AVP Code: 292)

> • | Redirect-Host-Usage (AVP Code: 261)

> • | Redirect-Max-Cache-Time (AVP Code: 262)

> • | Rating-Group (AVP Code: 432)

> • | Result-Code (AVP Code: 268)

> • | Route-Record (AVP Code: 282)

> • | Session-Id (AVP Code: 263)

> • | Service-Context-Id (AVP Code: 461)

> • | Service-Identifier (AVP Code: 439)

> • | Supported-Vendor-Id (AVP Code: 265)

> • | Termination-Cause (AVP Code: 295)

> • | Used-Service-Unit (AVP Code: 446)

> • | User-Name (AVP Code: 1)

> Unsupported AVPs
> This section lists the AVPs that are NOT supported.

> • | NOT Supported Credit Control AVPs specified in RFC 4006:

> • | CC-Correlation-Id

> • | CC-Money

> • | CC-Sub-Session-Id

> • | CC-Unit-Type (AVP Code: 454)

> • | Check-Balance-Result

> • | Cost-Information (AVP Code: 423)

> • | Cost-Unit (AVP Code: 445)

> • | Credit-Control

> • | Currency-Code (AVP Code: 425)

> • | Direct-Debiting-Failure-Handling (AVP Code: 428)

> • | Exponent (AVP Code: 429)

> • | G-S-U-Pool-Identifier (AVP Code: 453)

> • | G-S-U-Pool-Reference (AVP Code: 457)

> • | Requested-Action (AVP Code: 436)

> • | Service-Parameter-Info (AVP Code: 440)

> • | Service-Parameter-Type (AVP Code: 441)

> • | Service-Parameter-Value (AVP Code: 442)

> • | Unit-Value (AVP Code: 424)

> • | Value-Digits (AVP Code: 447)

> • | NOT supported Diameter AVPs specified in 3GPP TS 32.299 V8.1.0:

> • | Acct-Application-Id (AVP Code: 259)

> • | Error-Reporting-Host (AVP Code: 294)

> • | Experimental-Result (AVP Code: 297)

> • | Experimental-Result-Code (AVP Code: 298)

> • | Proxy-Host

> • | Proxy-Info

> • | Proxy-State

> • | NOT supported 3GPP-specific AVPs specified in 3GPP TS 32.299 V8.1.0:

> • | 3GPP-CAMEL-Charging-Info (AVP Code: 24)

> • | 3GPP-MS-TimeZone (AVP Code: 23)

> • | 3GPP-PDSN-MCC-MNC

> • | Authorised-QoS

> • | Access-Network-Information

> • | Adaptations

> • | Additional-Content-Information

> • | Additional-Type-Information

> • | Address-Data

> • | Address-Domain

> • | Addressee-Type

> • | Address-Type

> • | AF-Correlation-Information

> • | Alternate-Charged-Party-Address

> • | Application-provided-Called-Party-Address

> • | Application-Server

> • | Application-Server-Information

> • | Applic-ID

> • | Associated-URI

> • | Aux-Applic-Info

> • | Bearer-Service

> • | Called-Asserted-Identity

> • | Called-Party-Address

> • | Calling-Party-Address

> • | Cause-Code

> • | Charged-Party

> • | Class-Identifier

> • | Content-Class

> • | Content-Disposition

> • | Content-Length

> • | Content-Size

> • | Content-Type

> • | Data-Coding-Scheme

> • | Deferred-Location-Event-Type

> • | Delivery-Report-Requested

> • | Destination-Interface

> • | Domain-Name

> • | DRM-Content

> • | Early-Media-Description

> • | Event

> • | Event-Type

> • | Expires

> • | File-Repair-Supported

> • | IM-Information

> • | IMS-Charging-Identifier (ICID)

> • | IMS-Communication-Service-Identifier

> • | IMS-Information

> • | Incoming-Trunk-Group-ID

> • | Interface-Id

> • | Interface-Port

> • | Interface-Text

> • | Interface-Type

> • | Inter-Operator-Identifier

> • | LCS-APN

> • | LCS-Client-Dialed-By-MS

> • | LCS-Client-External-ID

> • | LCS-Client-ID

> • | LCS-Client-Name

> • | LCS-Client-Type

> • | LCS-Data-Coding-Scheme

> • | LCS-Format-Indicator

> • | LCS-Information

> • | LCS-Name-String

> • | LCS-Requestor-ID

> • | LCS-Requestor-ID-String

> • | Location-Estimate

> • | Location-Estimate-Type

> • | Location-Type

> • | Low-Balance-Indication

> • | MBMS-Information

> • | MBMS-User-Service-Type

> • | Media-Initiator-Flag

> • | Media-Initiator-Party

> • | Message-Body

> • | Message-Class

> • | Message-ID

> • | Message-Size

> • | Message-Type

> • | MMBox-Storage-Requested

> • | MM-Content-Type

> • | MMS-Information

> • | Node-Functionality

> • | Number-Of-Participants

> • | Number-Of-Received-Talk-Bursts

> • | Number-Of-Talk-Bursts

> • | Originating-IOI

> • | Originator

> • | Originator-Address

> • | Originator-Interface

> • | Originator-SCCP-Address

> • | Outgoing-Trunk-Group-ID

> • | Participant-Access-Priority

> • | Participants-Group

> • | Participants-Involved

> • | PDG-Address

> • | PDG-Charging-Id

> • | PoC-Change-Condition

> • | PoC-Change-Time

> • | PoC-Controlling-Address

> • | PoC-Group-Name

> • | PoC-Information

> • | PoC-Server-Role

> • | PoC-Session-Id

> • | PoC-Session-Initialtion-Type

> • | PoC-Session-Type

> • | PoC-User-Role

> • | PoC-User-Role-IDs

> • | PoC-User-Role-info-Units

> • | Positioning-Data

> • | Priority

> • | PS-Append-Free-Format-Data (AVP Code: 867):

> The PCEF/GW ignores this AVP if no PS free format data is stored for the online charging session.

> • | PS-Free-Format-Data (AVP Code: 866)

> • | PS-Furnish-Charging-Information (AVP Code: 865)

> • | RAI (AVP Code: 909)

> • | Read-Reply-Report-Requested

> • | Received-Talk-Burst-Time

> • | Received-Talk-Burst-Volume

> • | Recipient-Address

> • | Recipient-SCCP-Address

> • | Refund-Information

> • | Remaining-Balance

> • | Reply-Applic-ID

> • | Reply-Path-Requested

> • | Requested-Party-Address

> • | Role-of-node

> • | SDP-Answer-Timestamp

> • | SDP-Media-Component

> • | SDP-Media-Description

> • | SDP-Media-Name

> • | SDP-Offer-Timestamp

> • | SDP-Session-Description

> • | SDP-TimeStamp

> • | Served-Party-IP-Address

> • | Service-Generic-Information

> • | Service-ID

> • | Service-Specific-Data

> • | Service-Specific-Info

> • | Service-Specific-Type

> • | SIP-Method

> • | SIP-Request-Timestamp

> • | SIP-Response-Timestamp

> • | SM-Discharge-Time

> • | SM-Message-Type

> • | SM-Protocol-Id

> • | SMSC-Address

> • | SMS-Information

> • | SMS-Node

> • | SM-Status

> • | SM-User-Data-Header

> • | Submission-Time

> • | Talk-Burst-Exchange

> • | Talk-Burst-Time

> • | Talk-Burst-Volume

> • | Terminating-IOI

> • | Time-Stamps

> • | Token-Text

> • | Trunk-Group-ID

> • | Type-Number

> • | User-Participating-Type

> • | User-Session-ID

> • | WAG-Address

> • | WAG-PLMN-Id

> • | WLAN-Information

> • | WLAN-Radio-Container

> • | WLAN-Session-Id

> • | WLAN-Technology

> • | WLAN-UE-Local-IPAddress

> Configuring Gy Interface Support
> To configure Gy interface support:

> 1. | Configure the core network service as described in this Administration Guide.

> 2. | Configure Gy interface support as described in the relevant section:

> • | Configuring GGSN / P-GW / IPSG Gy Interface Support

> • | Configuring HA / PDSN Gy Interface Support

> 3. | Verify and save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Important: Commands used in the configuration examples 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 Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands.
> Configuring GGSN / P-GW / IPSG Gy Interface Support
> To configure the standard Gy interface support for GGSN/P-GW/IPSG, use the following configuration:
> configure
> context <context_name>
> diameter endpoint <endpoint_name>
> origin realm <realm>
> origin host <diameter_host> address <ip_address>
> peer <peer> realm <realm> address <ip_address>
> exit
> exit
> active-charging service <ecs_service_name>
> credit-control [ group <cc_group_name> ]
> diameter origin endpoint <endpoint_name>
> diameter peer-select peer <peer> realm <realm>
> diameter pending-timeout <timeout_period>
> diameter session failover
> diameter dictionary <dictionary>
> failure-handling initial-request continue
> failure-handling update-request continue
> failure-handling terminate-request continue
> exit
> exit
> context <context_name>
> apn <apn_name>
> selection-mode sent-by-ms
> ims-auth-service <service>
> ip access-group <access_list_name> in
> ip access-group <access_list_name> out
> ip context-name <context_name>
> active-charging rulebase <rulebase_name>
> credit-control-group <cc_group_name>
> end
> Notes:

> • | For information on configuring IP access lists, refer to the Access Control Lists chapter in the Cisco ASR 5000 Series System Administration Guide.

> • | For more information on configuring ECS ruledefs, refer to the ACS Ruledef Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

> • | For more information on configuring ECS charging actions, refer to the ACS Charging Action Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

> • | For more information on configuring ECS rulebases, refer to the ACS Rulebase Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

> Configuring HA / PDSN Gy Interface Support
> To configure HA / PDSN Gy interface support, use the following configuration:
> configure
> context <context_name>
> diameter endpoint <endpoint_name>
> origin realm <realm>
> origin host <diameter_host> address <ip_address>
> peer <peer> realm <realm> address <ip_address>
> exit
> exit
> active-charging service <ecs_service_name>
> ruledef <ruledef_name>
> ip any-match = TRUE
> exit
> charging-action <charging_action_name>
> content-id <content_id>
> cca charging credit rating-group <rating_group>
> exit
> rulebase <rulebase_name>
> action priority <action_priority> ruledef <ruledef_name> charging-action <charging_action_name>
> exit
> credit-control [ group <cc_group_name> ]
> diameter origin endpoint <endpoint_name>
> diameter peer-select peer <peer> realm <realm>
> diameter pending-timeout <timeout>
> diameter session failover
> diameter dictionary <dictionary>
> failure-handling initial-request continue
> failure-handling update-request continue
> failure-handling terminate-request continue
> pending-traffic-treatment noquota buffer
> pending-traffic-treatment quota-exhausted buffer
> exit
> exit
> context <context_name>
> subscriber default
> ip access-group <acl_name> in
> ip access-group <acl_name> out
> ip context-name <context_name>
> active-charging rulebase <rulebase_name>
> credit-control-group <cc_group_name>
> end
> Notes:

> • | For information on configuring IP access lists, refer to the Access Control Lists chapter in the Cisco ASR 5000 Series Systems Administration Guide.

> • | For more information on configuring ECS ruledefs, refer to the ACS Ruledef Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

> • | For more information on configuring ECS charging actions, refer to the ACS Charging Action Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

> • | For more information on configuring ECS rulebases, refer to the ACS Rulebase Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.

> Gathering Statistics
> This section explains how to gather Gy and related statistics and configuration information.
> In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.

> Statistics/Information | Action to perform
> Complete statistics for ECS sessions. | show active-charging sessions full
> Information on all rule definitions configured in the service. | show active-charging ruledef all
> Information on all charging actions configured in the service. | show active-charging charging-action all
> Information on all rulebases configured in the service. | show active-charging rulebase all
> Statistics of the Credit Control application, DCCA. | show active-charging credit-control statistics
> States of the Credit Control application's sessions, DCCA. | show active-charging credit-control session-states [ rulebase <rulebase_name> ] [ content-id <content_id> ]

> ‌
> Appendix E
> ICAP Interface Support
> This chapter provides information on configuring the external Active Content Filtering servers for a core network service subscriber. This chapter also describes the configuration and commands that are used to implement this feature.
> 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 respective product Administration Guide, before using the procedures in this chapter.
> Supported Networks and Platforms
> This feature supports ST16 and Cisco® ASR 5000 Chassis for the core network services configured on the system.
> Licensing
> External Content Filtering Server support through Internet Content Adaptation Protocol (ICAP) interface is a licensed feature.
> To enable this feature on your chassis you must install one of the following licenses, along with other required core network and in-line service licenses:

> • | Cisco PID [ ASR5K-00-CS01ICAP ] Content Filtering ICAP Interface, 1K sessions, or Starent Part Number [ 600-00-7578 ] Content Filtering ICAP Interface, 1K sessions.

> • | Cisco PID [ ASR5K-00-CS10ICAP ] Content Filtering ICAP Interface, 10K Sessions, or Starent Part Number [ 600-00-8530 ] Content Filtering ICAP Interface, 10K Sessions.

> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> ICAP Interface Support Overview
> This feature supports streamlined ICAP interface to leverage Deep Packet Inspection (DPI) to enable external application servers to provide their services without performing DPI, and without being inserted in the data flow. For example with an external Active Content Filtering (ACF) Platform.
> A high-level view of the streamlined ICAP interface support for external ACF is shown in the following figure:
> High-Level View of Streamlined ICAP Interface with external ACF
> The system with ECS is configured to support DPI and the system uses this capability for content charging as well.
> If a subscriber initiates a WAP (WAP1.x or WAP2.0) or Web session, the subsequent GET/POST request is detected by the DPI function. The URL of the GET/POST request is extracted and passed, along with subscriber identification information and the subscriber request, in an ICAP message to the application server. The application server checks the URL on the basis of its category and other classifications like, type, access level, content category and decides if the request should be authorized, blocked, or redirected by answering to the GET/POST with:

> • | A 200 OK message if the request is accepted

> • | A 302 Redirect message in case of redirection. This redirect message includes the URL to which the subscriber should be redirected

> • | A 403 Denied message is the request should be blocked

> Depending on the response received, the system with ECS will either pass the request unmodified, or discard the message and respond to the subscriber with the appropriate redirection or block message.
> Content charging is performed by the Active Charging Service (ACS) only after the request has been controlled by the application server. This guarantees the appropriate interworking between the external application and content-based billing. In particular, this guarantees that charging will be applied to the appropriate request in case of redirection, and that potential charging-based redirections (i.e. Advice of Charge, Top Up page, etc.) will not interfere with the decisions taken by the application server.
> Functions of the ACF include:

> • | Retrieval of subscriber policies based on the subscriber identity passed in the ICAP message

> • | Determining the appropriate action (permit, deny, redirect) to take for the type of content based on subscriber profile

> • | Communication of the action (permit, deny, or redirect) decision for the URL back to the ACS module

> Failure Action on Retransmitted Packets
> ICAP rating is enabled for retransmitted packet when default ICAP failure action was taken on an ICAP request for that flow. ICAP default failure action is taken on the pending ICAP request for a connection when the connection needs to be reset and there is no other redundant connection available. For example, in the ICAP request timeout and ICAP connection timeout scenarios. In these cases the retransmitted packet in the uplink direction is sent for ICAP rating again.
> In case of WAP CO, uplink retransmitted packet for the WAP transactions for which ICAP failure action was taken will be sent for ICAP rating. WSP header of the retransmitted packet is not parsed by the WSP analyzer. The URL received in the previous packet for that transaction is used for ICAP rating. If failure action was taken on multiple WTP transactions for the same flow (case: WTP concatenated GET request) then uplink retransmitted packet for each of the transaction is sent for rating again.
> In case of HTTP, uplink retransmitted packets for the HTTP flow on which ICAP failure action is taken is sent for ICAP rating. The URL present in the current secondary session (last uplink request) is used for ICAP rating. However, if there were multiple outstanding ICAP request for the same flow (pipelined request) then for the retransmitted packet the URL that will be sent for rating will be that of the last GET request.
> Retransmission in various cases of failure-action taken on re-transmitted packets when the ICAP response is not received for the original request and the retransmitted request comes in:

> • | WSP CO:

> • | Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked. It is possible that the WAP gateway sends the response for the permitted GET request. Hence, there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.

> • | Content Insert: The retransmitted packet is not sent for ICAP rating.

> • | Redirect: The retransmitted packet is not sent for ICAP rating.

> • | Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked.

> • | Terminate flow: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed or blocked. The WAP gateway may send an Abort transaction for this GET request if the WSP disconnect packet sent while terminating the flow is received by the WAP gateway.

> • | HTTP:

> • | Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the last HTTP GET request. It is possible that the HTTP server sends the response for the permitted GET request. Hence there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.

> • | Content Insert: Retransmitted packets are dropped and not charged.

> • | Redirect: Retransmitted packets are dropped and not charged.

> • | Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction allowed/blocked.

> • | Terminate flow: Retransmitted packets are dropped and not charged.

> Configuring ICAP Interface Support
> This section describes how to configure the Content Filtering Server Group (CFSG) through Internet Content Adaptation Protocol (ICAP) interface between ICAP client and ACF server (ICAP server).
> Important: This section provides the minimum instruction set for configuring external content filtering servers on ICAP interface on the system. For more information on commands that configure additional parameters and options, refer to CFSG Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.
> To configure the system to provide ICAP interface support for external content filtering servers:

> Step 1 | Create the Content Filtering Server Group and create ICAP interface with origin (local) IP address of chassis by applying the example configuration in the Creating ICAP Server Group and Address Binding section.

> Step 2 | Specify the active content filtering server (ICAP sever) IP addresses and configure other parameters for ICAP server group by applying the example configuration in the Configuring ICAP Server and Other Parameters section.

> Step 3 | Configure the content filtering mode to external content filtering server group mode in ECS rule base by applying the example configuration in the Configuring ECS Rulebase for ICAP Server Group section.

> Step 4 | Optional. Configure the charging action to forward HTTP/WAP GET request to external content filtering servers on ICAP interface in Active Charging Configuration mode by applying the example configuration in the Configuring Charging Action for ICAP Server Group section.

> Step 5 | Verify your ICAP interface and external content filtering server group configuration by following the steps in the Verifying the ICAP Server Group Configuration section.

> Step 6 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Creating ICAP Server Group and Address Binding
> Use the following example to create the ICAP server group and bind the IP addresses:
> configure
> context <icap_ctxt_name> [ -noconfirm ]
> content-filtering server-group <icap_svr_grp_name> [ -noconfirm ]
> origin address <ip_address>
> end
> Notes:

> • | <ip_address> is local IP address of the CFSG endpoint.

> Configuring ICAP Server and Other Parameters
> Use the following example to configure the active content filtering (ICAP server) and other related parameters:
> configure
> context <icap_context_name>
> content-filtering server-group <icap_server_grp_name>
> icap server <ip_address> [port <port_number>][max <max_msgs>][priority <priority>]
> deny-message <msg_string>
> response-timeout <timeout>
> connection retry-timeout <retry_timeout>
> failure-action {allow | content-insertion <content_string> | discard | redirect-url <url> | terminate-flow}
> dictionary {custom1 | custom2 | standard}
> end
> Notes:

> • | In StarOS 8.1 and later, a maximum of five ICAP servers can be configured per Content Filtering Server Group. In StarOS 8.0, only one ICAP Server can be configured per Content Filtering Server Group.

> • | The maximum outstanding request per ICAP connection configured using the optional max <max_msgs> keyword is limited to one. Therefore, any other value configured using the max keyword will be ignored.

> • | Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:

> url-extraction { after-parsing | raw }
> By default, percent-encoded hex characters in URLs sent from the ACF client to the ICAP server will be converted to corresponding ASCII characters and sent.
> Configuring ECS Rulebase for ICAP Server Group
> Use the following example to configure the content filtering mode to ICAP server mode in the ECS rulebase for content filtering:
> configure
> require active-charging [optimized-mode]
> active-charging service <acs_svc_name> [-noconfirm]
> rulebase <rulebase_name> [-noconfirm]
> content-filtering mode server-group <cf_server_group>
> end
> Notes:

> • | In StarOS 8.1, the optimized-mode keyword enables ACS in the Optimized mode, wherein ACS functionality is managed by SessMgrs. In StarOS 8.1, ACS must be enabled in the Optimized mode.

> • | In StarOS 8.3, the optimized-mode keyword is obsolete. With or without this keyword ACS is always enabled in Optimized mode.

> • | In StarOS 8.0 and StarOS 9.0 and later, the optimized-mode keyword is not available.

> Configuring Charging Action for ICAP Server Group
> Use the following example to configure the charging action to forward HTTP/WAP GET request to ICAP server for content processing:
> configure
> active-charging service <acs_svc_name>
> charging-action <charging_action_name> [ -noconfirm ]
> content-filtering processing server-group
> end
> Verifying the ICAP Server Group Configuration
> This section explains how to display and review the configurations after saving them in a .cfg file as described in Verifying and Saving Your Configuration chapter of this guide and also to retrieve errors and warnings within an active configuration for a service.
> Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
> These instructions are used to verify the configuration for this feature.

> Step 1 | Verify your ICAP Content Filtering Server Group configuration by entering the following command in Exec Mode:

> show content-filtering server-group
> The following is a sample output. In this example, an ICAP Content Filtering server group named icap_cfsg1 was configured.
> Content Filtering Group: icap_cfsg1
> Context: icap1
> Origin Address: 1.2.3.4
> ICAP Address(Port): 1.2.3.4(1344)
> Max Outstanding: 256
> Priority: 1
> Response Timeout: 30(secs) Connection Retry Timeout: 30(secs)
> Dictionary: standard
> Timeout Action: terminate-flow
> Deny Message: "Service Not Subscribed"
> URL-extraction: after-parsing
> Content Filtering Group Connections: NONE
> Total content filtering groups matching specified criteria: 1

> Step 2 | Verify any configuration error in your configuration by entering the following command in Exec Mode:

> show configuration errors
> Appendix F
> IP Pool Sharing Protocol
> 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 before using the procedures in this chapter.
> Sections in this chapter include:

> • | Overview

> • | How IPSP Works

> • | Configuring IPSP Before the Software Upgrade

> • | Configuring IPSP After the Software Upgrade

> • | Disabling IPSP

> Overview
> The IP Pool Sharing Protocol (IPSP) is a protocol that system-based HA services can use during an offline-software upgrade to avoid the assignment of duplicate IP addresses to sessions while allowing them to maintain the same address, and to preserve network capacity.
> In order for IPSP to be used, at least two system-based HAs with identical configurations must be present on the same LAN. IPSP uses a primary & secondary model to manage the IP pools between the HAs. When used, this protocol ensures the following:

> • | In-progress sessions can be handed-off to the secondary HA when an offline-software upgrade is being performed on the primary and receive the same IP address that it was originally assigned.

> • | New sessions can be redirected to the secondary HA when an offline-software upgrade is being performed on the primary and receive a non-duplicate IP address.

> The protocol is enabled at the interface level. Each system-based HA must have an IPSP-enabled interface configured in the same context as the HA service for this protocol to function properly.
> Primary HA Functionality
> The primary HA is the system that is to be upgraded. It performs the following functions for IPSP:

> • | Queries the pool information from the secondary HA; the pool configurations on both HAs must be identical

> • | Assigns an IP address or address block to the secondary HA when requested by the secondary HA; the primary HA releases sessions if they have an IP address requested by the secondary

> • | For graceful termination conditions (e.g. an administrative user issues the reload command), sends a termination message to the secondary HA causing it to assume the responsibilities of the primary HA until the primary is available again.

> • | Sends a trap when the number of calls drops to zero after starting IPSP

> Secondary HA Functionality
> The secondary HA is the system that takes over Mobile IP sessions from the primary HA that is being upgraded. It performs the following functions for IPSP:

> • | Locks the IP pools until it receives an address or address block assignment from the primary HA; it unlocks the IP pools after busying out the addresses that are not assigned to it

> • | Processes address requests for sessions that are within the address block assigned to it

> • | Communicates with the primary HA, as needed, to request IP addresses that are not currently assigned to it; it does not assign the address until the primary HA approves it

> • | For graceful termination conditions (e.g. an administrative user issues the reload command), it notifies the primary HA that it is going out of service

> • | Assumes the responsibility of the primary HA when requested to

> • | In the event that it determines that primary HA is not available, it assumes the responsibility of the primary HA if there is at least one address allocated to verify that the AAA server is re-configured to direct the calls

> Requirements, Limitations, & Behavior

> • | One IPSP interface can be configured per system context.

> • | The IPSP interfaces for both the primary and secondary HAs must be configured to communicate on the same network.

> • | If IP pool busyout is enabled on any configured address pool, IPSP can not be configured.

> • | The IP pool configuration (pool name, addresses, priority, pool group, etc.) on both the HAs must be identical.

> • | IP pools cannot be modified on either the primary or the secondary HAs once IPSP is enabled.

> • | Sessions are dropped during the IPSP setup process if:

> • | the primary HA has not yet approved an IP address or address block.

> • | the primary HA is not known to the secondary HA.

> • | Once an address is assigned to the secondary HA, all the information about that address is erased on the primary HA and that address becomes unusable by the primary HA.

> • | LRU is not supported across the systems. Although, LRU continues to be supported within the system.

> • | If the IPSP configuration is not disabled before removing the HA from the IPSP network link, sessions may be rejected if the system’s VPN Manager is rebooted or restarts.

> • | IPSP does not control static IP pools. An external application (AAA, etc.) must be responsible for ensuring that duplicate addresses are not assigned.

> • | IPSP ignores interface failures allowing the configured dead-interval timer to determine when the HA should become the primary and control the pool addresses. Before the dead-interval timer starts, the secondary HA maintains its state and any busied out addresses remain busied out. After the dead-interval timer starts, IPSP marks the neighboring peer HA as down, becomes primary, and will unbusy out all pool addresses.

> How IPSP Works
> IPSP operation requires special configuration in both the primary and secondary HAs. As mentioned previously, both HAs must have identical configurations. This allows the secondary HA to process sessions identically to the primary when the primary is taken offline for upgrade.
> Configuration must also be performed on the AAA server. Whereas subscriber profiles on the AAA server originally directed sessions to the primary HA, prior to using IPSP, subscriber profiles must be re-configured to direct sessions to the secondary HA.
> There are two scenarios in which IPSP takes effect:

> • | New sessions: Once IPSP is configured, new sessions are directed to a secondary HA (HA2) allowing the primary HA to go through a software upgrade without degrading network capacity. The secondary HA requests addresses from the primary HA’s (HA1) pools as needed. As the addresses are allocated, they are busied out on the primary HA. This procedure is displayed below.

> • | Session handoffs: Once IPSP is configured, sessions originally registered with the primary HA (HA1) are re-registered with the secondary HA (HA2). To ensure the session is assigned the same IP address, the secondary HA requests the address from the primary HA. The primary HA verifies the binding and releases it to the secondary HA which, in turn, re-assigns it to the session. As the addresses are allocated, they are busied out on the primary HA. This procedure is displayed below.

> IPSP Operation for New Sessions
> The following figure and text describe how new sessions are handled when IPSP is enabled.
> IPSP Operation for New Sessions
> IPSP Operation for New Sessions Description

> Step | Description
> 1 | A mobile node (MN) attempting to establish a data session is connected to PDSN/FA 2.
> 2 | PDSNFA 2 authenticates the subscriber with the AAA server. One of the attributes returned by the AAA server as part of a successful authentication is the IP address of the secondary HA.
> 3 | PDSN/FA 2 forwards the session request to HA2 for processing. HA2 processes the session as it would for any Mobile IP session.
> 4 | With IPSP enabled, prior to assigning an IP address, HA2 sends a request to HA1 for an IP address.
> 5 | HA1 allocates the address to HA2 and busies it out so it can not be re-assigned.
> 6 | HA1 responds to HA2 with the IP address for the session.
> 7 | HA2 proceeds with session processing and provides PDSN/FA 2 with the IP address for the MN.
> 8 | The MN and PDSN/FA 2 complete session processing.

> ‌
> IPSP Operation for Session Handoffs
> The following figure and text describe how session handoffs are handled when IPSP is enabled.
> IPSP Operation for Session Handoffs
> IPSP Operation for Session Handoffs Description

> Step | Description
> 1 | A mobile node (MN) is connected to PDSN/FA 1.
> 2 | The MN’s session is handed-off to PDSN/FA2 and goes through the re-registration process.
> 3 | PDSN/FA 2 authenticates the subscriber with the AAA server as part of the re-registration process. One of the attributes returned by the AAA server as part of a successful authentication is the IP address of the secondary HA.
> 4 | PDSN/FA 2 forwards the session request to HA2 for processing. Included in the request is the MN’s current IP address.
> 5 | With IPSP enabled, prior to assigning an IP address, HA2 sends a request to HA1 for an IP address.
> 6 | HA1 verifies the MN’s information and releases the binding. It then busies out the address so it can not be re-assigned.
> 7 | HA1 allocates the original IP address to HA2 for the session.
> 8 | HA2 proceeds with session processing and provides PDSN/FA 2 with the IP address for the mobile node.
> 9 | The mobile node and PDSN/FA 2 complete session processing.

> ‌
> Configuring IPSP Before the Software Upgrade
> Configuring IPSP requires changes to the primary HA (the HA on which the software upgrade is to occur), the secondary HA (the HA to which subscribers sessions are to be directed), and the AAA server.
> This section provides information and instructions for configuring IPSP before the software upgrade.
> Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer to the IPSP Configuration Mode Commands chapter in the Command Line Interface Reference.
> To enable the IP pool sharing during software upgrade:

> Step 1 | Configure the AAA servers by applying the example configuration in the Configuring the AAA Server for IPSP section.

> Step 2 | Configure an interface on the system for use by IPSP according to the instructions found in the Creating and Configuring Ethernet Interfaces and Ports section of the System Administration Guide.

> Step 3 | Enable the IPSP on secondary HA by applying the example configuration in the Enabling IPSP on the Secondary HA section.

> Step 4 | Perform the boot system priority and SPC/SMC card synchronization as described in Off-line Software Upgrade section in the System Administration Guide.

> Step 5 | Enable the IPSP on primary HA by applying the example configuration in the Enabling IPSP on the Primary HA section.

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

> Step 7 | Proceed for software upgrade as described in Off-line Software Upgrade section in the System Administration Guide.

> Step 8 | Save your configuration as described in the Saving Your Configuration chapter.

> Configuring the AAA Server for IPSP
> For subscriber session establishment, the AAA server provides the IP address of the HA that is to service the session. This information exists in the 3GPP2_MIP_HA_Address RADIUS attribute configured for the subscriber.
> Because the primary HA has been responsible for facilitating subscriber sessions, its IP address is the one configured via this attribute. For IPSP however, the attribute configuration must change in order to direct sessions to the secondary HA.
> To do this, reconfigure the 3GPP2_MIP_HA_Address RADIUS attribute for each subscriber on the AAA server with the IP address of the secondary HA.
> The precise instructions for performing this operation vary depending on the AAA server vendor. Refer to the documentation for your AAA server for more information.
> Enabling IPSP on the Secondary HA
> The secondary HA is the alternate HA that is to take responsibility while the primary HA is upgraded.
> Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer to the IPSP Configuration Mode Commands chapter in Command Line Interface Reference.
> Use the following example to enable the IPSP on secondary HA:
> configure
> context <ipsp_ctxt_name> [ -noconfirm ]
> interface <ipsp_if_name>
> pool-share-protocol primary <pri_ha_address> [ mode {active | inactive | check-config } ]
> dead-interval <dur_sec>
> end
> Notes:

> • | The interface must be configured in the same context as the HA service and must be on the same network as the primary HA’s IPSP interface.

> • | ipsp_if_name is the name of the interface on which you want to enable IPSP.

> • | dead-interval is an optional command to configure time to wait before retrying the primary HA for the IP Pool Sharing Protocol.

> Enabling IPSP on the Primary HA
> The primary HA is the HA that is to be upgraded.
> Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer to the IPSP Configuration Mode Commands chapter in the Command Line Interface Reference.
> Use the following example to enable the IPSP on primary HA:
> configure
> context <ipsp_ctxt_name> [ -noconfirm ]
> interface <ipsp_if_name>
> pool-share-protocol secondary <sec_ha_address> [ mode {active | inactive | check-config } ]
> dead-interval <dur_sec>
> end
> Notes:

> • | The interface must be configured in the same context as the HA service and must be on the same network as the secondary HA’s IPSP interface.

> • | ipsp_if_name is the name of the interface on which you want to enable IPSP.

> • | dead-interval is an optional command to configure time to wait before retrying the secondary HA for the IP Pool Sharing Protocol.

> Important: Once this configuration is done, the primary HA begins to hand responsibility for sessions and release IP addresses to the secondary HA. Prior to performing the software upgrade, all IP addresses must be released. When IPSP has released all IP pool addresses from the primary HA an SNMP trap (starIPSPAllAddrsFree) is triggered.
> Verifying the IPSP Configuration
> These instructions are used to verify the IPSP configuration.
> Verify that IPSP has released all IP addresses by entering the following command in Exec Mode with in specific context:
> show ip ipsp
> The output of this command provides the list of used addresses and released addresses. The system will send the starIPSPAllAddrsFree trap once all IP addresses are released. When the value in the Used Addresses column reaches 0 for all IP pools listed, then the primary HA sends the SNMP trap and notifies the secondary HA to take over as the primary HA.
> Configuring IPSP After the Software Upgrade
> If desired, IP pool addresses can be migrated from the original secondary HA back to the original primary HA once the upgrade process is complete.
> Important: It is important to note that the HA that was originally designated as the secondary is now functioning as the primary HA. Conversely, the HA that was originally designated as the primary is now functioning as the secondary.
> In order to migrate the addresses, both HAs and the AAA server must be configured according to the instructions in this section.
> This section provides information and instructions for configuring IPSP after the software upgrade.
> Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer IPSP Configuration Mode Commands chapter in Command Line Interface Reference.
> To enable the IP pool sharing after software upgrade:

> Step 1 | Configure the AAA servers by applying the example configuration in the Configuring the AAA Server for IPSP section.

> Step 2 | Configure an interface on the system for use by IPSP according to the instructions found in the Creating and Configuring Ethernet Interfaces and Ports section of System Administration Guide.

> Step 3 | Enable the IPSP on secondary HA by applying the example configuration in the Enabling IPSP on the Secondary HA section.

> Step 4 | Enable the IPSP on primary HA by applying the example configuration in the Enabling IPSP on the Primary HA section.

> Step 5 | Verify your ACL configuration by following the steps in the Verifying the IPSP Configuration section.

> Step 6 | Save your configuration as described in the Saving Your Configuration chapter.

> Disabling IPSP
> Once all IP addresses on the primary HA have been released, IPSP must be disabled on both the primary and secondary HAs.
> Caution: Prior to disabling IPSP, ensure that the primary HA has released all IP addresses to secondary HA.
> Follow the instructions in this section to disable IPSP on primary and secondary HA after migration of all IP addresses.
> Important: This section provides the minimum instruction set for disabling IPSP on the HAs. For more information on commands, refer to the IPSP Configuration Mode Commands chapter in the Command Line Interface Reference.
> Use the following example to enable the IPSP on primary/secondary HA:
> configure
> context <ipsp_ctxt_name> [ -noconfirm ]
> interface <ipsp_if_name>
> no pool-share-protocol
> end
> Notes:

> • | The interface must be configured in the same context as the primary/secondary HA service and must be on the same network as the primary/secondary HA’s IPSP interface.

> • | ipsp_if_name is the name of the interface on which you want to disable IPSP.

> • | IPSP must be disabled on both the HAs.

> Appendix G
> 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: Use of RoHC requires that a valid RoHC license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> 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 Cisco ASR 5000 Series 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 as described in the Saving Your Configuration chapter.

> 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: Use of RoHC requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> 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 Cisco ASR 5000 Series 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 as described in the Saving Your Configuration chapter.

> 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 Cisco ASR 5000 Series 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: Use of RoHC requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> 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 Cisco ASR 5000 Series 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 as described in the Saving Your Configuration chapter.

> 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 Cisco ASR 5000 Series 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 as described in the Saving Your Configuration chapter.

> 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 Cisco ASR 5000 Series 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 Cisco ASR 5000 Series 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: Use of RoHC requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
> 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 Cisco ASR 5000 Series 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 as described in the Saving Your Configuration chapter.

> 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 Cisco ASR 5000 Series 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 Cisco ASR 5000 Series 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 Cisco ASR 5000 Series 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 Cisco ASR 5000 Series 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 as described in the Saving Your Configuration chapter.

> 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 Cisco ASR 5000 Series 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 as described in the Saving Your Configuration chapter.

> 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 Cisco ASR 5000 Series 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 H
> 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.
> IP Security is a license enabled feature. You must purchase and install a license key before you can use this feature.
> 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.

> • | 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.

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

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

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

> • | 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.

> • | Save your configuration as described in Verifying and Saving Your Configuration.

> 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 as described in Verifying and Saving Your Configuration.

> 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 as described in Verifying and Saving Your Configuration.

> 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 as described in Verifying and Saving Your Configuration.

> How IPSec is Used for L2TP Configurations on the GGSN
> 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 as described in Verifying and Saving Your Configuration.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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:

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

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

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 as described in the Verifying and Saving Your Configuration chapter.

> 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 ASR 5000 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 GTP-C signaling traffic and GTP-U 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 GTP-C signaling traffic and GTP-U 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 and management 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-C signaling traffic and GTP-U data traffic are 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 I
> L2TP Access Concentrator
> This chapter describes the Layer 2 Tunneling Protocol (L2TP) Access Concentrator (LAC) functionality support on ST16 and Cisco® ASR 5000 Chassis 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 the respective product Administration Guide, before using the procedures in this chapter.
> Important: This product requires the purchase of a separate session licence and feature key in order to function as described.
> When enabled though the session license and feature use key, the system supports L2TP for encapsulation of data packets between it and one or more L2TP Network Server (LNS) nodes. In the system, this optional packet encapsulation, or tunneling, is performed by configuring L2TP Access Concentrator (LAC) services within contexts.
> Important: The LAC service uses UDP ports 13660 through 13668 as the source port for sending packets to the LNS.
> Applicable Products and Relevant Sections
> The LAC 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 |
> • | Supported LAC Service Configurations for PDSN Simple IP
> • | Supported LAC Service Configuration for Mobile IP
> • | Configuring Subscriber Profiles for L2TP Support
> • | RADIUS and Subscriber Profile Attributes Used
> • | Configuring Local Subscriber Profiles for L2TP Support
> • | Tunneling All Subscribers in a Specific Context Without Using RADIUS Attributes
> • | Configuring LAC Services
> • | Modifying PDSN Services for L2TP Support
> GGSN/SGSN/FA/P-GW |
> • | Supported LAC Service Configurations for the GGSN
> • | Supported LAC Service Configuration for Mobile IP
> • | Configuring Subscriber Profiles for L2TP Support
> • | RADIUS and Subscriber Profile Attributes Used
> • | Configuring Local Subscriber Profiles for L2TP Support
> • | Configuring LAC Services
> • | Modifying APN Templates to Support L2TP
> ASN GW |
> • | Supported LAC Service Configuration for Mobile IP
> • | Configuring Subscriber Profiles for L2TP Support
> • | RADIUS and Subscriber Profile Attributes Used
> • | Configuring Local Subscriber Profiles for L2TP Support
> • | Tunneling All Subscribers in a Specific Context Without Using RADIUS Attributes
> • | Configuring LAC Services

> ‌
> Supported LAC Service Configurations for PDSN Simple IP
> LAC services can be applied to incoming PPP sessions using one of the following methods:

> • | Attribute-based tunneling: This method is used to encapsulate PPP packets for only specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.

> • | PDSN Service-based compulsory tunneling: This method of tunneling is used to encapsulate all incoming PPP traffic from the R-P interface coming into a PDSN service, and tunnel it to an LNS peer for authentication. It should be noted that this method does not consider subscriber configurations, since all authentication is performed by the peer LNS.

> Each LAC service is bound to a single system interface configured within the same system context. It is recommended that this context be a destination context as displayed in the following figure.
> LAC Service Configuration for SIP
> Attribute-based Tunneling
> This section describes the working of attribute-based tunneling and its configuration.
> How The Attribute-based L2TP Configuration Works
> The following figure and the text that follows describe how Attribute-based tunneling is performed using the system.
> Attribute-based L2TP Session Processing for SIP

> 1. | A subscriber session from the PCF is received by the PDSN service over the R-P interface.

> 2. | The PDSN service attempts to authenticate the subscriber. The subscriber could be configured either locally or remotely on a RADIUS server. Figure above shows subscriber authentication using a RADIUS AAA server.

> 3. | The RADIUS server returns an Access-Accept message, which includes attributes indicating that session data is to be tunneled using L2TP, and the name and location of the LAC service to use. An attribute could also be provided indicating the LNS peer to connect to.

> 4. | The PDSN service receives the information and then forwards the packets to the LAC service, configured within the Destination context.

> 5. | The LAC service, upon receiving the packets, encapsulates the information and forwards it to the appropriate PDN interface for delivery to the LNS.

> 6. | The encapsulated packets are sent to the peer LNS through the packet data network where they will be un-encapsulated.

> Configuring Attribute-based L2TP Support for PDSN Simple IP
> This section provides a list of the steps required to configure attribute-based L2TP support for use with PDSN Simple IP applications. 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 as a PDSN.

> Step 1 | Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.

> Step 2 | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> Step 3 | Configure the PDSN service(s) with the tunnel context location according to the instructions located in the Modifying PDSN Services for L2TP Support section of this chapter.

> Step 4 | Save your configuration as described in Verifying and Saving Your Configuration.

> PDSN Service-based Compulsory Tunneling
> This section describes the working of service-based compulsory tunneling and its configuration.
> How PDSN Service-based Compulsory Tunneling Works
> PDSN Service-based compulsory tunneling enables wireless operators to send all PPP traffic to remote LNS peers over an L2TP tunnel for authentication. This means that no PPP authentication is performed by the system.
> Accounting start and interim accounting records are still sent to the local RADIUS server configured in the system’s AAA Service configuration. When the L2TP session setup is complete, the system starts its call counters and signals the RADIUS server to begin accounting. The subscriber name for accounting records is based on the NAI-constructed name created for each session.
> PDSN service-based compulsory tunneling requires the modification of one or more PDSN services and the configuration of one or more LAC services.
> The following figure and the text that follows describe how PDSN service-based compulsory tunneling is performed using the system.
> PDSN Service-based Compulsory Tunneling Session Processing

> Step 3 | A subscriber session from the PCF is received by the PDSN service over the R-P interface.

> Step 4 | The PDSN service detects its tunnel-type parameter is configured to L2TP and its tunnel-context parameter is configured to the Destination context.

> Step 5 | The PDSN forwards all packets for the session to a LAC service configured in the Destination context. If multiple LAC services are configured, session traffic will be routed to each using a round-robin algorithm.

> Step 6 | The LAC service initiates an L2TP tunnel to one of the LNS peers listed as part of its configuration.

> Step 7 | Session packets are passed to the LNS over a packet data network for authentication.

> Step 8 | The LNS authenticates the session and returns an Access-Accept to the PDSN.

> Step 9 | The PDSN service initiates accounting for the session using a constructed NAI.

> Session data traffic is passed over the L2TP tunnel established in step 4.
> Configuring L2TP Compulsory Tunneling Support for PDSN Simple IP
> This section provides a list of the steps required to configure L2TP compulsory tunneling support for use with PDSN Simple IP applications. 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 as a PDSN.

> Step 1 | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> Step 2 | Configure the PDSN service(s) according to the instructions located in the Modifying PDSN Services for L2TP Support section of this chapter.

> Step 3 | Save your configuration as described in Verifying and Saving Your Configuration.

> Supported LAC Service Configurations for the GGSN
> As mentioned previously, L2TP is supported through the configuration of LAC services on the system. Each LAC service is bound to a single system interface configured within the same system destination context as displayed in following figure.
> LAC Service Configuration
> LAC services are applied to incoming subscriber PDP contexts based on the configuration of attributes either in the GGSN’s Access Point Name (APN) templates or in the subscriber’s profile. Subscriber profiles can be configured locally on the system or remotely on a RADIUS server.
> LAC service also supports domain-based L2TP tunneling with LNS. This method is used to create multiple tunnels between LAC and LNS on the basis of values received in “Tunnel-Server-Auth-ID” attribute received from AAA Server in Access-Accept as a key for tunnel selection and creation. When the LAC needs to establish a new L2TP session, it first checks if there is any existing L2TP tunnel with the peer LNS based on the value of key “Tunnel-Server-Auth-ID” attribute. If no such tunnel exists for the key, it will create a new Tunnel with the LNS.
> If LAC service needs to establish a new tunnel for new L2TP session with LNS and the tunnel create request fails because maximum tunnel creation limit is reached, LAC will try other LNS addresses received from AAA server in Access-Accept message. If all available peer-LNS are exhausted, LAC service will reject the call
> L2TP tunnel parameters are configured within the APN template and are applied to all subscribers accessing the APN. However, L2TP operation will differ depending on the subscriber’s PDP context type as described below:

> • | Transparent IP: The APN template’s L2TP parameter settings will be applied to the session.

> • | Non-transparent IP: Since authentication is required, L2TP parameter attributes in the subscriber profile (if configured) will take precedence over the settings in the APN template.

> • | PPP: The APN template’s L2TP parameter settings will be applied and all of the subscriber’s PPP packets will be forwarded to the specified LNS.

> More detailed information is located in the sections that follow.
> Transparent IP PDP Context Processing with L2TP Support
> The following figure and the text that follows describe how transparent IP PDP contexts are processed when L2TP tunneling is enabled.
> Transparent IP PDP Context Call Processing with L2TP Tunneling

> 1. | A Create PDP Context Request message for a subscriber session is sent from the SGSN to the GGSN service over the Gn interface. The message contains information such as the PDP Type, APN, and charging characteristics.

> 2. | The GGSN determines whether or not it is configured with an APN identical to the one specified in the message. If so, it determines how to process the session based on the configuration of the APN.

> The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured, and the outbound username and password that will be used by the LNS to authenticate incoming sessions. If no outbound information is configured, the subscriber’s International Mobile Subscriber Identity (IMSI) is used as the username at the peer LNS.

> 1. | The GGSN returns an affirmative Create PDP Context Response to the SGSN over the Gn interface.

> 2. | The GGSN passes data received from the MS to a LAC service.

> 3. | The LAC service encapsulates the IP packets and forwards it to the appropriate Gi interface for delivery to the LNS.

> 4. | The LNS un-encapsulates the packets and processes them as needed. The processing includes IP address allocation.

> Non-transparent IP PDP Context Processing with L2TP Support
> The following figure and the text that follows describe how non-transparent IP PDP contexts are processed when L2TP tunneling is enabled.
> Non-transparent IP PDP Context Call Processing with L2TP Tunneling

> 1. | A Create PDP Context Request message for a subscriber session is sent from the SGSN to the GGSN service over the Gn interface. The message contains information such as the PDP Type, APN, and charging characteristics.

> 2. | The GGSN determines whether or not it is configured with an APN identical to the one specified in the message. If so, it determines how to process the session based on the configuration of the APN.

> The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured, and the outbound username and password that will be used by the LNS to authenticate incoming sessions. If no outbound information is configured, the subscriber’s username is sent to the peer LNS.

> 3. | The GGSN service authenticates the subscriber. The subscriber could be configured either locally or remotely on a RADIUS server. Figure above shows subscriber authentication using a RADIUS AAA server.

> As part of the authentication, the RADIUS server returns an Access-Accept message.
> The message may include attributes indicating that session data is to be tunneled using L2TP, and the name and location of the LAC service to use. An attribute could also be provided indicating the LNS peer to connect to.
> If these attributes are supplied, they take precedence over those specified in the APN template.

> 4. | The GGSN returns an affirmative Create PDP Context Response to the SGSN over the Gn interface.

> 5. | The GGSN passes data received from the MS to a LAC service.

> 6. | The LAC service encapsulates the IP packets and forwards it to the appropriate Gi interface for delivery to the LNS.

> 7. | The LNS un-encapsulates the packets and processes them as needed.The processing includes authentication and IP address allocation.

> PPP PDP Context Processing with L2TP Support
> The following figure and the text that follows describe how non-transparent IP PDP contexts are processed when L2TP tunneling is enabled.
> PPP PDP Context Call Processing with L2TP Tunneling

> 1. | A Create PDP Context Request message for a subscriber session is sent from the SGSN to the GGSN service over the Gn interface. The message contains information such as the PDP Type, APN, and charging characteristics.

> 2. | The GGSN determines whether or not it is configured with an APN identical to the one specified in the message. If so, it determines how to process the session based on the configuration of the APN.

> The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured.
> Note that L2TP support could also be configured in the subscriber’s profile. If the APN is not configured for L2TP tunneling, the system will attempt to authenticate the subscriber.The tunneling parameters in the subscriber’s profile would then be used to determine the peer LNS.

> 3. | The GGSN returns an affirmative Create PDP Context Response to the SGSN over the Gn interface.

> 4. | The GGSN passes the PPP packets received from the MS to a LAC service.

> 5. | The LAC service encapsulates the PPP packets and forwards it to the appropriate Gi interface for delivery to the LNS.

> 6. | The LNS un-encapsulates the packets and processes them as needed. The processing includes PPP termination, authentication (using the username/password provided by the subscriber), and IP address allocation.

> Configuring the GGSN to Support L2TP
> This section provides a list of the steps required to configure the GGSN to support L2TP. 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 as a GGSN.

> 1. | Configure the APN template to support L2TP tunneling according to the information and instructions located in the Modifying APN Templates to Support L2TP section of this chapter.

> Important: L2TP tunneling can be configured within individual subscriber profiles as opposed/or in addition to configuring support with an APN template. Subscriber profile configuration is described in the Configuring Subscriber Profiles for L2TP Support section of this chapter.

> 2. | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> 3. | Save your configuration as described in Verifying and Saving Your Configuration chapter.

> Supported LAC Service Configuration for Mobile IP
> LAC services can be applied to incoming MIP sessions using attribute-based tunneling. Attribute-based tunneling is used to encapsulate PPP packets for specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.
> Each LAC service is bound to a single system interface within the same system context. It is recommended that this context be a destination context as displayed in figure below.
> LAC Service Configuration for MIP
> How The Attribute-based L2TP Configuration for MIP Works
> The following figure and the text that follows describe how Attribute-based tunneling for MIP is performed using the system.
> Attribute-based L2TP Session Processing for MIP

> 1. | A subscriber session from the FA is received by the HA service over the Pi interface.

> 2. | The HA service attempts to authenticate the subscriber. The subscriber could be configured either locally or remotely on a RADIUS server. Figure above shows subscriber authentication using a RADIUS AAA server.

> 3. | The RADIUS server returns an Access-Accept message, which includes attributes indicating that session data is to be tunneled using L2TP, and the name and location of the LAC service to use. An attribute could also be provided indicating the LNS peer to connect to.

> 4. | The HA service receives the information and then forwards the packets to the LAC service, configured within the Destination context.

> 5. | The LAC service, upon receiving the packets, encapsulates the information and forwards it to the appropriate PDN interface for delivery to the LNS.

> 6. | The encapsulated packets are sent to the peer LNS through the packet data network where they will be un-encapsulated.

> Configuring Attribute-based L2TP Support for HA Mobile IP
> This section provides a list of the steps required to configure attribute-based L2TP support for use with HA Mobile IP applications. 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 as an HA.

> Step 1 | Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.

> Step 2 | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> Step 3 | Save your configuration as described in Verifying and Saving Your Configuration chapter.

> Configuring Subscriber Profiles for L2TP Support
> This section provides information and instructions on the following procedures:

> • | RADIUS and Subscriber Profile Attributes Used

> • | Configuring Local Subscriber Profiles for L2TP Support

> • | Configuring Local Subscriber

> • | Verifying the L2TP Configuration

> Important: Since the instructions for configuring subscribers differ between RADIUS server applications, this section only provides the individual attributes that can be added to the subscriber profile. Refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.
> RADIUS and Subscriber Profile Attributes Used
> Attribute-based L2TP tunneling is supported through the use of attributes configured in subscriber profiles stored either locally on the system or remotely on a RADIUS server. The following table describes the attributes used in support of LAC services. These attributes are contained in the standard and VSA dictionaries.
> Subscriber Attributes for L2TP Support

> RADIUS Attribute | Local Subscriber Attribute | Description | Variable
> Tunnel-Type | tunnel l2tp | Specifies the type of tunnel to be used for the subscriber session | L2TP
> Tunnel-Server-Endpoint | tunnel l2tp peer-address | Specifies the IP address of the peer LNS to connect tunnel to. | IPv4 address in dotted-decimal format, enclosed in quotation marks
> Tunnel-Password | tunnel l2tp secret | Specifies the shared secret between the LAC and LNS. | Alpha and or numeric string from 1 to 63 characters, enclosed in quotation marks
> Tunnel-Private- Group-ID | tunnel l2tp tunnel-context | Specifies the name of the destination context configured on the system in which the LAC service(s) to be used are located. Important: If the LAC service and egress interface are configured in the same context as the core service or HA service, this attribute is not needed. | Alpha and or numeric string from 1 to 63 characters, enclosed in quotation marks
> Tunnel-Preference | tunnel l2tp preference | Configures the priority of each peer LNS when multiple LNS nodes are configured. Important: This attribute is only used when the loadbalance-tunnel-peers parameter or SN-Tunnel-Load-Balancing attribute configured to prioritized. | Integer from 1 to 65535
> SN-Tunnel-Load- Balancing | loadbalance-tunnel- peer | A vendor-specific attribute (VSA) used to provides a selection algorithm defining how an LNS node is selected by the RADIUS server when multiple LNS peers are configured within the subscriber profile. |
> • | Random - Random LNS selection order, the Tunnel-Preference attribute is not used in determining which LNS to select.
> • | Balanced - LNS selection is sequential balancing the load across all configured LNS nodes, the Tunnel-Preference attribute is not used in determining which LNS to select.
> • | Prioritized - LNS selection is made based on the priority assigned in the Tunnel-Preference attribute.
> Client-Endpoint | local-address | Specifies the IP address of a specific LAC service configured on the system that to use to facilitate the subscriber’s L2TP session. This attribute is used when multiple LAC services are configured. | IPv4 address in dotted decimal notation. (xxx.xxx.xxx.xxx)

> ‌
> RADIUS Tagging Support
> The system supports RADIUS attribute tagging for tunnel attributes. These “tags” organize together multiple attributes into different groups when multiple LNS nodes are defined in the user profile. Tagging is useful to ensure that the system groups all the attributes used for a specific server. If attribute tagging is not supported by your specific RADIUS server, the system implicitly organizes the attributes in the order that they are listed in the access accept packet.
> Configuring Local Subscriber Profiles for L2TP Support
> This section provides information and instructions for configuring local subscriber profiles on the system to support L2TP.
> Important: The configuration of RADIUS-based subscriber profiles is not discussed in this document. Please refer to the documentation supplied with your RADIUS server for further information.
> Important: This section provides the minimum instruction set for configuring local subscriber profile for L2TP support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide L2TP support to subscribers:

> Step 1 | Configure the “Local” subscriber with L2TP tunnel parameters and the load balancing parameters with action by applying the example configuration in the Configuring Local Subscriber section.

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

> Step 3 | Save your configuration as described in Verifying and Saving Your Configuration chapter.

> Configuring Local Subscriber
> Use the following example to configure the Local subscriber with L2TP tunnel parameters. Optionally you can configure load balancing between multiple LNS servers:
> configure
> context <ctxt_name> [-noconfirm]
> subscriber name <subs_name>
> tunnel l2tp peer-address <lns_ip_address> [ preference <integer> | [ encrypted ] secret <secret_string> | tunnel-context <context_name> | local-address <local_ip_address> }
> load-balancing { random | balanced | prioritized }
> end
> Notes:

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

> • | <lns_ip_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.

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

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

> show subscriber configuration username user_name
> The output of this command is a concise listing of subscriber parameter settings as configured.
> Tunneling All Subscribers in a Specific Context Without Using RADIUS Attributes
> As with other services supported by the system, values for subscriber profile attributes not returned as part of a RADIUS Access-Accept message can be obtained using the locally configured profile for the subscriber named default. The subscriber profile for default must be configured in the AAA context (i.e. the context in which AAA functionality is configured).
> As a time saving feature, L2TP support can be configured for the subscriber named default with no additional configuration for RADIUS-based subscribers. This is especially useful when you have separate source/AAA contexts for specific subscribers.
> To configure the profile for the subscriber named default, follow the instructions above for configuring a local subscriber and enter the name default.
> Configuring LAC Services
> Important: Not all commands, keywords and functions may be available. Functionality is dependent on platform and license(s).
> This section provides information and instructions for configuring LAC services on the system allowing it to communicate with peer LNS nodes.
> Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the LAC services on system:

> Step 1 | Configure the LAC service on system and bind it to an IP address by applying the example configuration in the Configuring LAC Service section.

> Step 2 | Optional. Configure LNS peer information if the Tunnel-Service-Endpoint attribute is not configured in the subscriber profile or PDSN compulsory tunneling is supported by applying the example configuration in the Configuring LNS Peer section.

> Step 3 | Verify your LAC configuration by following the steps in the Verifying the LAC Service Configuration section.

> Step 4 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Configuring LAC Service
> Use the following example to create the LAC service and bind the service to an IP address:
> configure
> context <dst_ctxt_name> [-noconfirm]
> lac-service <service_name>
> bind address <ip_address>
> end
> Notes:

> • | <dst_ctxt_name> is the destination context where you want to configure the LAC service.

> Configuring LNS Peer
> Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
> configure
> context <dst_ctxt_name> [ -noconfirm ]
> lac-service <service_name>
> tunnel selection-key tunnel-server-auth-id
> peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> {[encrypted] isakmp-secret <secret> }] [description <text>] [ preference <integer>]
> load-balancing { random | balanced | prioritized }
> end
> Notes:

> • | <dst_ctxt_name> is the destination context where the LAC service is configured.

> Verifying the LAC Service Configuration
> These instructions are used to verify the LAC service configuration.

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

> show lac-service name service_name
> The output given below is a concise listing of LAC service parameter settings as configured.
> Service name: vpn1
> Context: isp1
> Bind: Done
> Local IP Address: 192.168.2.1
> First Retransmission Timeout: 1 (secs)
> Max Retransmission Timeout: 8 (secs)
> Max Retransmissions: 5
> Max Sessions: 500000 Max Tunnels: 32000
> Max Sessions Per Tunnel: 512
> Data Sequence Numbers: Enabled Tunnel Authentication: Enabled
> Keep-alive interval: 60 Control receive window: 16
> Max Tunnel Challenge Length: 16
> Proxy LCP Authentication: Enabled
> Load Balancing: Random
> Service Status: Started
> Newcall Policy: None
> Modifying PDSN Services for L2TP Support
> PDSN service modification 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.
> Important: This section provides the minimum instruction set for modifying PDSN service for L2TP support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the LAC services on system:

> Step 1 | Modify the PDSN service to support L2TP by associating LAC context and defining tunnel type by applying the example configuration in the Modifying PDSN Service section.

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

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Modifying PDSN Service
> Use the following example to modify the PDSN service to support L2TP by associating LAC context and defining tunnel type:
> configure
> context <source_ctxt_name> [ -noconfirm ]
> pdsn-service <pdsn_service_name>
> ppp tunnel-context <lac_context_name>
> ppp tunnel-type { l2tp | none }
> end
> Notes:

> • | <source_ctxt_name> is the name of the source context containing the PDSN service, which you want to modify for L2TP support.

> • | <pdsn_service_name> is the name of the pre-configured PDSN service, which you want to modify for L2TP support.

> • | <lac_context_name> is typically the destination context where the LAC service is configured.

> Verifying the PDSN Service for L2TP Support
> These instructions are used to verify the PDSN service configuration.

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

> show pdsn-service name pdsn_service_name
> The output of this command is a concise listing of PDSN service parameter settings as configured.
> Modifying APN Templates to Support L2TP
> This section provides instructions for adding L2TP support for APN templates configured on the system.
> Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the LAC services on system:

> Step 1 | Modify the APN template to support L2TP with LNS server address and other parameters by applying the example configuration in the Assigning LNS Peer Address in APN Template section.

> Step 2 | Optional. If L2TP will be used to tunnel transparent IP PDP contexts, configure the APN’s outbound username and password by applying the example configuration in the Configuring Outbound Authentication section.

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

> Step 4 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Assigning LNS Peer Address in APN Template
> Use following example to assign LNS server address with APN template:
> configure
> context <dst_ctxt_name> [-noconfirm]
> apn <apn_name>
> tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <integer> ] [ tunnel-context <l2tp_context_name> ] [ local-address <local_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
> end
> Notes:

> • | <dst_ctxt_name> is the name of system destination context in which the APN is configured.

> • | <apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.

> • | <lns_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.

> Configuring Outbound Authentication
> Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
> configure
> context <dst_ctxt_name> [ -noconfirm ]
> apn <apn_name>
> outbound { [ encrypted ] password <pwd> | username <name> }
> end
> Notes:

> • | <dst_ctxt_name> is the destination context where APN template is is configured.

> • | <apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.

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

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

> show apn name apn_name
> The output is a concise listing of APN parameter settings as configured.
> Appendix J
> L2TP Network Server
> This chapter describes the support for Layer 2 Tunneling Protocol (L2TP) Network Server (LNS) functionality on ST16 and Cisco® ASR 5000 Chassis 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 the respective product Administration Guide, before using the procedures in this chapter.
> Important: This product requires that you buy a license and feature use key. Not all features and functions may be functioning on all platforms.
> When enabled though the session license and feature use key, LNS functionality is configured as context-level services on the system. LNS services support the termination of L2TP encapsulated tunnels from L2TP Access Concentrators (LACs) in accordance with RFC 2661.
> Important: The LNS service uses UDP ports 13660 through 13668 as the source port for receiving packets from the LAC. You can force the LNS to only use the standard L2TP port (UDP Port 1701) with the single-port-mode LNS service configuration mode command. Refer to the Command Line Interface Reference for more information on this command.
> LNS Service Operation
> As mentioned previously, LNS functionality on the system is configured via context-level services. LNS services can be configured in the same context as other services supported on the system or in its own context. Each context can support multiple LNS services.
> One of the most simple configuration that can be implemented on the system to support Simple IP data applications requires that two contexts (one source and one destination) be configured on the system as shown in the following figure.
> LNS Configuration Example
> The source context facilitates the LNS service(s) and the PDN and AAA interfaces. The PDN interface is bound to the LNS service and connects L2TP tunnels and sessions from one or more peer LACs. The source context is also be configured to provide AAA functionality for subscriber sessions. The destination context facilitates the packet data network interface(s) and can optionally be configured with pools of IP addresses for assignment to subscriber sessions.
> In this configuration, the LNS service in the source context terminates L2TP tunnels from peer LACs and routes the subscriber session data through the destination context to and from a packet data network such as the Internet or a home network.
> Information Required
> Prior to configuring the system as shown in figure above, a minimum amount of information is required. The following sections describe the information required to configure the source and destination contexts.
> Source Context Configuration
> The following table lists the information that is required to configure the source context.
> Required Information for Source Context Configuration

> Required Information | Description
> Source context name | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the source context will be recognized by the system.
> PDN Interface Configuration
> PDN interface name | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the interface will be recognized by the system. Multiple names are needed if multiple interfaces will be configured. These PDN interfaces facilitates the L2TP tunnels/sessions from the LAC and are configured in the source context.
> IP address and subnet | These will be assigned to the PDN interface. Multiple addresses and/or subnets are needed if multiple interfaces will be configured.
> Physical port number | This specifies the physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides in, followed by the number of the physical connector on the line card. For example, port 17/1 identifies connector number 1 on the card in slot 17. A single physical port can facilitate multiple interfaces.
> Physical port description | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the physical port will be recognized by the system. Multiple descriptions are needed if multiple ports will be used. Physical ports are configured within the source context and are used to bind logical PDN interfaces.
> Gateway IP address | Used when configuring static routes from the PDN interface(s) to a specific network.
> LNS service Configuration
> LNS service name | This is an identification string between 1 and 63 characters (alpha and/or numeric) by which the LNS service will be recognized by the system. Multiple names are needed if multiple LNS services will be used. LNS services are configured in the source context.
> Authentication protocols used | Specifies how the system handles authentication: using a protocol (such as CHAP, PAP, or MSCHAP), or not requiring any authentication.
> Domain alias for NAI-construction | Specifies a context name for the system to use to provide accounting functionality for a subscriber session. This parameter is needed only if the system is configured to support no authentication.
> Maximum number of sessions per tunnel | This defines the maximum number of sessions supported by each tunnel facilitated by the LNS service. The number can be configured to any integer value from 1 to 65535. The default is 65535.
> Maximum number of tunnels | This defines the maximum number of tunnels supported by the LNS service. The number can be configured to any integer value from 1 to 32000. The default is 32000.
> Peer LAC | IP address or network prefix and mask: The IP address of a specific peer LAC for which the LNS service terminates L2TP tunnels. The IP address must be expressed in dotted decimal notation. Multiple peer LACs can be configured. Alternately, to simplify configuration, a group of peer LACs can be specified by entering a network prefix and a mask.
> Secret: The shared secret used by the LNS to authenticate the peer LAC. The secret can be from 1 to 256 alpha and/or numeric characters and is case sensitive.
> AAA Interface Configuration
> AAA interface name | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the interface will be recognized by the system. Multiple names are needed if multiple interfaces will be configured. AAA interfaces will be configured in the source context.
> IP address and subnet | These will be assigned to the AAA interface. Multiple addresses and/or subnets are needed if multiple interfaces will be configured.
> Physical port number | A single physical port can facilitate multiple interfaces.
> Physical port description | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the physical port will be recognized by the system. Multiple descriptions are needed if multiple ports will be used. Physical ports are configured within the source context and are used to bind logical AAA interfaces.
> Gateway IP address | Used when configuring static routes from the AAA interface(s) to a specific network.
> RADIUS Server Configuration
> RADIUS Authentication server | IP Address: Specifies the IP address of the RADIUS authentication server the source context will communicate with to provide subscriber authentication functions. Multiple addresses are needed if multiple RADIUS servers will be configured. RADIUS authentication servers are configured within the source context. Multiple servers can be configured and each assigned a priority.
> Shared Secret: The shared secret is a string between 1 and 15 characters (alpha and/or numeric) that specifies the key that is exchanged between the RADIUS authentication server and the source context. A shared secret is needed for each configured RADIUS server.
> UDP Port Number: Specifies the port used by the source context and the RADIUS authentication server for communications. The UDP port number can be any integer value between 1 and 65535. The default value is 1812.
> RADIUS Accounting server | IP Address: Specifies the IP address of the RADIUS accounting server that the source context will communicate with to provide subscriber accounting functions. Multiple addresses are needed if multiple RADIUS servers will be configured. RADIUS accounting servers are configured within the source context. Multiple servers can be configured and each assigned a priority.
> Shared Secret: The shared secret is a string between 1 and 15 characters (alpha and/or numeric) that specifies the key that is exchanged between the RADIUS accounting server and the source context. A shared secret is needed for each configured RADIUS server.
> UDP Port Number: Specifies the port used by the source context and the RADIUS Accounting server for communications. The UDP port number can be any integer value between 1 and 65535. The default value is 1813.
> RADIUS attribute NAS Identifier | Specifies the name by which the source context will be identified in the Access-Request message(s) it sends to the RADIUS server. The name must be between 1 and 32 alpha and/or numeric characters and is case sensitive.
> RADIUS NAS IP address | Specifies the IP address of the source context’s AAA interface. A secondary IP address interface can optionally be configured.
> Default Subscriber Configuration
> “Default” subscriber’s IP context name | Specifies the name of the egress context on the system that facilitates the PDN ports. NOTE: For this configuration, the IP context name should be identical to the name of the destination context.

> ‌
> Destination Context Configuration
> The following table lists the information that is required to configure the destination context.
> Required Information for Destination Context Configuration

> Required Information | Description
> Destination context name | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the destination context will be recognized by the system. NOTE: For this configuration, the destination context name should not match the domain name of a specific domain.
> PDN Interface Configuration
> PDN interface name | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the interface will be recognized by the system. Multiple names are needed if multiple interfaces will be configured. PDN interfaces are used to connect to a packet network and are configured in the destination context.
> IP address and subnet | These will be assigned to the PDN interface. Multiple addresses and/or subnets are needed if multiple interfaces will be configured.
> Physical port number | A single physical port can facilitate multiple interfaces.
> Physical port description(s) | This is an identification string between 1 and 79 characters (alpha and/or numeric) by which the physical port will be recognized by the system. Multiple descriptions will be needed if multiple ports will be used. Physical ports are configured within the destination context and are used to bind logical PDN interfaces.
> Gateway IP address(es) | Used when configuring static routes from the PDN interface(s) to a specific network.
> IP Address Pool Configuration (optional)
> IP address pool name(s) | If IP address pools will be configured in the destination context(s), names or identifiers will be needed for them. The pool name can be between 1 and 31 alpha and/or numeric characters and is case sensitive.
> IP pool addresses | An initial address and a subnet, or a starting address and an ending address, are required for each configured pool. The pool will then consist of every possible address within the subnet, or all addresses from the starting address to the ending address. The pool can be configured as public, private, or static.

> ‌
> How This Configuration Works
> The following figure and the text that follows describe how this LNS service configuration with a single source and destination context would be used by the system to terminate an L2TP tunnel.
> Call Processing Using a Single Source and Destination Context

> 1. | An L2TP tunnel request from a peer LAC is received by the LNS service. The tunnel is to facilitate a subscriber session.

> 2. | The LAC and LNS establish the L2TP tunnel according to the procedures defined in RFC 2661.

> Once the L2TP tunnel is established, subscriber L2TP sessions can be established.

> 3. | The LNS service determines which context to use in providing AAA functionality for the subscriber session if authentication is enabled for the LNS service. For more information on this process, refer How the System Selects Contexts in System Administration Guide.

> For this example, the result of this process is that LNS service determined that AAA functionality should be provided by the Source context.

> 4. | The system communicates with the AAA server specified in the Source context’s AAA configuration to authenticate the subscriber.

> 5. | Upon successful authentication, the LNS service terminates the subscriber’s PPP datagrams from the L2TP session and the system determines which egress context to use for the subscriber session. For more information on egress context selection process, refer How the System Selects Contexts in System Administration Guide.

> The system determines that the egress context is the destination context based on the configuration of either the Default subscriber’s ip-context name or from the SN-VPN-NAME or SN1-VPN-NAME attributes that is configured in the subscriber’s RADIUS profile.

> 6. | Data traffic for the subscriber session is routed through the PDN interface in the Destination context.

> 7. | Accounting information for the session is sent to the AAA server over the AAA interface.

> Configuring the System to Support LNS Functionality
> Many of the procedures required to configure the system to support LNS functionality are provided in the System Administration Guide. The System Administration Guide provides information and procedures for configuring contexts, interfaces and ports, AAA functionality, and IP address pools on the system.
> This section provides information and instructions for configuring LNS services on the system allowing it to communicate with peer LAC nodes.
> Important: This section provides the minimum instruction set for configuring an LNS service allowing the system to terminate L2TP tunnels and process data sessions. For more information on commands that configure additional LNS service properties, refer LNS Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide access control list facility to subscribers:

> Step 1 | Create the LNS service and bind it to an interface IP address by applying the example configuration in the Creating and Binding LNS Service section.

> Step 2 | Specify the authentication parameters for LNS service by applying the example configuration in the Configuring Authentication Parameters for LNS Service section.

> Step 3 | Configure the maximum number of tunnels supported by the LNS service and maximum number of sessions supported per tunnel by applying the example configuration in the Configuring Tunnel and Session Parameters for LNS Service section.

> Step 4 | Configure peer LACs for the LNS service by applying the example configuration in the Configuring Tunnel and Session Parameters for LNS Service section.

> Step 5 | Optional. Specify the domain alias designated for the context which the LNS service uses for AAA functionality by applying the example configuration in the Configuring Domain Alias for AAA Subscribers section.

> Step 6 | Verify your LNS service configuration by following the steps in the Verifying the LNS Service Configuration section.

> Step 7 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Creating and Binding LNS Service
> Use the following example to create the LNS service and bind the IP address to it:
> configure
> context <dest_ctxt_name> -noconfirm
> lns-service <lns_svc_name> -noconfirm
> bind address <ip_address> [ max-subscribers <max_subscriber> ]
> end
> Notes:

> • | LNS service has to be configured in destination context.

> • | Bind address is the interface address that is to serve as an L2TP PDN interface.

> • | Multiple addresses on the same IP interface can be bound to different LNS services. However, each address can be bound to only one LNS service. In addition, the LNS service can not be bound to the same interface as other services such as a LAC service.

> Configuring Authentication Parameters for LNS Service
> Use the following example to authentication parameters for LNS service:
> configure
> context <dest_ctxt_name>
> lns-service <lns_svc_name>
> authentication { { [ allow-noauth | chap <pref> | mschap <pref> | | pap <pref> ] } | msid-auth }
> end
> Note:

> • | For more information on authentication procedure and priorities, refer authentication command section in LNS Configuration Mode Commands chapter of Command Line Interface Reference.

> Configuring Tunnel and Session Parameters for LNS Service
> Use the following example to configure the tunnel and session parameters for LNS service:
> configure
> context <dest_ctxt_name>
> lns-service <lns_svc_name>
> max-tunnel <max_tunnels>
> max-session-per-tunnel <max_sessions>
> end
> Note:

> • | For more information on tunnel and session related parameters, refer LNS Configuration Mode Commands chapter of Command Line Interface Reference.

> Configuring Peer LAC servers for LNS Service
> Use the following example to configure the peer LAC servers for LNS service:
> configure
> context <dest_ctxt_name>
> lns-service <lns_svc_name>
> peer-lac { <lac_ip_address> | <ip_address>/<mask> } [ encrypted ] secret <secret_string> [ description <desc_text> ]
> end
> Note:

> • | Multiple LACs can be configured with this command. For more information, refer LNS Configuration Mode Commands chapter of Command Line Interface Reference.

> Configuring Domain Alias for AAA Subscribers
> Use the following example to create the LNS service and bind the IP address to it:
> configure
> context <dest_ctxt_name> -noconfirm
> lns-service <lns_svc_name> -noconfirm
> nai-construct domain <domain_alias>
> end
> Note:

> • | If this command is enabled, an NAI is constructed for the subscriber in the event that their mobile node does not negotiate CHAP, PAP, or MSCHAP.

> • | If this option is selected, no further attempts are made to authenticate the user. Instead, the constructed NAI is used for accounting purposes.

> Important: This command should only be used if the LNS service is configured to allow “no authentication” using the authentication allow-noauth command.
> Verifying the LNS Service Configuration
> These instructions are used to verify the LNS service configuration.

> Step 1 | Verify that your LNS service configuration by entering the following command in Exec Mode:

> show lns-service name service_name
> The output of this command displays the configuration of the LNS service and should appear similar to that shown below.
> Service name: testlns
> Context: test
> Bind: Not Done
> Local IP Address: 0.0.0.0
> First Retransmission Timeout: 1 (secs)
> Max Retransmission Timeout: 8 (secs)
> Max Retransmissions: 5
> Setup Timeout: 60 (secs)
> Max Sessions: 500000 Max Tunnels: 32000
> Max Sessions Per Tunnel: 65535
> Keep-alive Interval: 60 Control Receive Window: 16
> Data Sequence Numbers: Enabled
> Tunnel Authentication: Enabled
> Tunnel Switching: Enabled
> Max Tunnel Challenge Length: 16
> PPP Authentication: CHAP 1 PAP 2
> Allow Noauthentication: Disabled MSID Authentication: Disabled
> No NAI Construct Domain defined
> No Default Subscriber defined
> IP Src Violation Reneg Limit: 5
> IP Src Violation Drop Limit: 10
> IP Src Violation Period: 120 (secs)
> Service Status: Not started
> Newcall Policy: None
> Appendix K
> 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 as described in Saving Your Configuration.
> 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 as described in Saving Your Configuration.
> Appendix L
> Multimedia Broadcast and Multicast Service
> This chapter provides information on Multimedia Broadcast and Multicast Service (MBMS) functionality on GGSN. 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 features described in this chapter are only available if you have purchased and installed MBMS feature support license on your chassis.
> This chapter discusses following topics for MBMS support:

> • | Introduction

> • | Supported Standards

> • | Supported Networks and Platforms

> • | Licenses

> • | Services and Application in MBMS

> • | How MBMS Works

> • | MBMS Configuration

> • | Save the Configuration

> • | Managing Your Configuration

> • | Gathering MBMS Statistics

> Introduction
> MBMS is an IP datacast type of service in GSM and UMTS cellular network. It eliminates unnecessary replication of data on UMTS wireless networks by transmitting a single stream of data to multiple users. By delivering a single, unidirectional data stream to many subscribers, MBMS makes more efficient use of wireless network resources than traditional point to point connections.
> MBMS is a solution for transferring light video and audio clips with a suitable method for mass communications.
> MBMS functionality on the system is provided by an existing GGSN service and is enabled by a valid services license.
> The main features supported by the Multimedia Broadcast & Multicast Services are:

> • | Individual user network control functions and provide forward MBMS user data to SGSN

> Important: The ASR 5000 platform supports 225 downlink SGSNs per MBMS Bearer Service through NPU assisted data flow processing. NPU assisted data processing is available on ASR 5000 platforms with release 8.1 or later only.

> • | Support for intra-GGSN and inter-GGSN mobility procedures

> • | Generate charging data per multicast service for each user for both prepaid and post paid subscribers.

> • | Multicast proxy-host functionality

> • | Support for MBMS-specific Gmb messages

> • | Authentication of MBMS flow-ids using a MBMS controller

> • | Establishment and tear-down of MBMS bearer paths using the multicast framework

> • | Support for framing HDLC-like and segment based framing

> • | Accounting for the MBMS flows to charge the originator of the content

> This service provides two mode of operations:

> • | MBMS Broadcast Mode

> • | MBMS Multicast Mode

> A broadcast mode is a unidirectional point-to-multipoint service in which data is transmitted from a single source to multiple terminals (UE/MS) in the associated broadcast service area/cell area. The transmitted data can be text to light multimedia services (Audio, Video etc). On the other hand multicast mode is a unidirectional point-to-multipoint service in which data is transmitted from a single source to a pre-defined multicast group of users that are subscribed to the specific multicast service and have joined the multicast group in the associated multicast service area.
> The following figure shows the reference architecture of MBMS service in UMTS network.
> MBMS Reference Architecture in UMTS network
> The GGSN provides the following functionality to perform MBMS services:

> • | serves as an entry point for IP multicast traffic as MBMS data. It provides establishment of bearer plan and tear-down of the established bearer plan upon notification from the BM-SC.

> • | provides functionality to receive MBMS specific IP multicast traffic and to route this data to the proper GTP tunnels set-up as part of the MBMS bearer service.

> • | provides features, that are not exclusive to MBMS, for the MBMS bearer service, like charging data collection, flow-based charging, optional message screening etc.

> MBMS is able to use NPU assisted MBMS data flow processing on ASR 5000 platforms so that system can relieve the Session Manager to provide better performance and processing. Currently with NPU assisted data processing, ASR 5000 can support 225 SGSNs per MBMS Bearer Service for downlink of MBMS data.
> Supported Standards
> Support for the following standards and requests for comments (Rafts) have been added with the MBMS functionality:

> • | 3GPP TS 22.146: Multimedia Broadcast/Multicast Service; Stage 1 (Release 6)

> • | 3GPP TS 22.246: MBMS user services; Stage 1 (Release 6)

> • | 3GPP TS 23.246: MBMS; Architecture and functional description (Release 6)

> • | 3GPP TS 26.346: MBMS; Protocols and codecs (Release 6)

> • | 3GPP TS 33.246: Security of Multimedia Broadcast/Multicast Service

> • | 3GPP TS 32.251: Telecommunication management; Charging management; Packet Switched (PS) domain charging

> • | 3GPP TS 32.273: Telecommunication management; Charging management; Multimedia Broadcast and Multicast Service (MBMS) charging

> • | RFC 3588, Diameter Base Protocol

> Supported Networks and Platforms
> This feature supports all ASR 5000 platforms running StarOS Release 8.0 or later with GGSN service for the core network services.
> Licenses
> This feature support requires any one of the following feature licenses installed on the system:

> • | Cisco PID [ASR5K-00-GNXXMBMS] Multimedia Broadcast Multicast Service per GGSN node, or Starent Part Number [600-00-7581] Multimedia Broadcast Multicast Service

> • | Cisco PID [ASR5K-00-SN01MBMS] Multimedia Broadcast Multicast Service SGSN License, per 1K Node B / RNC, or Starent Part Number [600-00-76211] Multimedia Broadcast Multicast Service

> Services and Application in MBMS
> MBMS service can be used as an enabler for various data streaming services. Compared to traditional broadcast services like cell broadcast, MBMS provides multimedia capabilities with relatively high data rates and considerably greater multimedia capabilities.
> Some of the applications for MBMS are:

> • | News clips

> • | Audio streams

> • | Combined audio and picture/video clips

> • | Video distribution services, either via streaming, carousel, or download methods

> • | Localized services like tourist information, weather alerts etc.

> • | Content distribution

> • | Game delivery

> The charging of the MBMS bearer service can be done based on events, content, or flows.
> MBMS provides the authentication, key distribution, and data protection for the multicast service users.
> MBMS References and Entities
> Following are the major components and entities required for MBMS service.
> Gmb Reference
> The Gmb reference point handles the broadcast multicast service center (BM-SC) related signaling, which includes the user specific and bearer service messages.
> MBMS bearer service specific Gmb signaling includes:

> • | MBMS bearer context establishment by GGSN and registering of GGSN at BM-SC.

> • | Release of MBMS bearer context at GGSN and de-registration of GGSN from the BM-SC.

> • | Session start/stop indication from BM-SC to GGSN including session attributes like QoS or MBMS service area.

> User specific Gmb signaling includes:

> • | BM-SC authorization of user specific MBMS multicast service activation at the GGSN.

> • | Reporting of successful user specific MBMS multicast service activation by GGSN to BM-SC to synchronize the BM-SC UE MBMS context and charging with the MBMS UE contexts in GGSN.

> • | Reporting of release or deactivation of user specific MBMS multicast service activation by GGSN to BM-SC to synchronize the BM-SC UE MBMS context and charging with the MBMS UE contexts in GGSN.

> • | BM-SC initiated deactivation of user specific MBMS bearer service when the MBMS user service is terminated.

> MBMS UE Context
> A MBMS UE context is defined per UE. Session Manager assign a separate context structure for a MBMS UE Context.
> Session Manager maintains the following information as part of MBMS UE Context:

> • | IP multicast address: IP multicast address identifying an MBMS bearer that the UE has joined.

> • | APN: Access Point Name on which this IP multicast address is defined.

> • | SGSN address: The IP address of SGSN

> • | IMSI: IMSI identifying the user.

> • | TEID for Control Plane: The Tunnel Endpoint Identifier for the control plane between SGSN and GGSN.

> • | MBMS NSAPI: Network layer Service Access Point Identifier which identifies an MBMS UE Context.

> Important: For capacity and resource purpose one MBMS UE context is equal to one PDP context.
> MBMS Bearer Context
> The MBMS bearer context is created in the SGSN and GGSN for each provisioned MBMS service. This is created when the first MS requests for this service or when a downstream node requests it. Once created, an MBMS context can be in two states:

> • | Active - is the state in which network resources are required for the transfer of MBMS data.

> • | Standby - is the state in which no network resources are required.

> The MBMS Bearer Context contains all information describing a particular MBMS bearer service and is created in each node involved in the delivery of the MBMS data.
> Broadcast Multicast Service Center (BM-SC)
> The BM-SC includes functions for MBMS user service provisioning and delivery. It serves as an entry point for content provider MBMS transmissions, used to authorize and initiate MBMS Bearer Services within the PLMN. It can also be used to schedule and deliver MBMS transmissions.
> The BM-SC consists of five sub-functions:

> • | Membership function

> • | Session and Transmission function

> • | Proxy and Transport function

> • | Service Announcement function

> • | Security function.

> BM-SC is a functional entity and must exist for each MBMS User Service.
> How MBMS Works
> The Multimedia Broadcast Multicast System provides two types of service provisioning; broadcast and multicast modes. This section describes the procedure of these modes.
> MBMS Broadcast Mode
> The broadcast mode provides unidirectional point-to-multipoint type transmission of multimedia data from a single source to all users that found in a defined broadcast service area. This mode uses radio resources efficiently, since the data is transmitted over a common channel.
> MBMS data transmission adapts to the suitable RAN capabilities, depending on the availability of radio resources too. If needed, the bit rate of MBMS data may be varied in order to optimized radio resources.
> The following figure shows the basic outline of broadcast mode procedure of an MBMS service in order to broadcast MBMS data within the defined broadcast service area via a packet switched core network.
> Basic Procedure of MBMS Broadcast Mode
> The broadcast service may include one or more successive broadcast sessions. The user can control the enabling or disabling of the MBMS broadcast mode service.
> MBMS Broadcast Mode Procedure
> The MBMS performs following steps for broadcast mode user service:

> Step 1 | Service Announcement: Through the service announcement mechanisms, like SMS, WAP, users informed about the available MBMS services.

> Step 2 | Session Start: This is the phase where BM-SC has data to send and this triggers establishment of network resources for data transfer irrespective of whether a given user has activated the service or not.

> Step 3 | MBMS Notification: Notifies the MS of a impending MBMS data transfer.

> Step 4 | Data Transfer: It is the phase when MBMS data are transferred to the UEs.

> Step 5 | Session Stop: In this phase, the BM-SC determines that it has no more data to send for a time period and so the network resources can be released.

> MBMS Multicast Mode
> The multicast mode provides unidirectional point-to-multipoint type transmission of multimedia data from a single content source to a group of subscribers that subscribed to specific multicast service separately. The basic difference between broadcast and multicast modes is that the user does not need to subscribe in each broadcast service separately, whereas in multicast mode the services cab be order separately. The subscription and group joining for the multicast mode service can be done by the operator, user, or a separate service provider.
> Like broadcast mode the multicast mode allows the unidirectional point-to-multipoint transmission of multimedia data within the multicast service area. The multicast mode uses radio resources in efficient way by using common radio channel as in broadcast mode. Data is transmitted over the multicast service area as defined by the network operator.
> The multicast mode provides the flexibility for the network to selectively transmit to those cells within the multicast service area that contains members of a multicast group.
> The following figure shows the basic outline of multicast mode procedure of an MBMS service in order to multicast MBMS data within the defined multicast service area via a packet switched core network.
> Basic Procedure of MBMS Multicast Mode
> A multicast service might consist of a single on-going session or may include several simultaneous multicast sessions over and extended period of time.
> Some example of multicast mode service are:

> • | transmission of sports video clips to subscribers on charging basis

> • | transmission of news, movie, song, and audio clips to subscribed users on charging basis

> MBMS Multicast Mode Procedure
> The MBMS performs following steps for multicast mode user service:

> Step 1 | Subscription: Establishes the relationship between the user and the service provider, which allows the user to receive the related MBMS multicast service.

> Step 2 | Service Announcement: Through the service announcement mechanisms like, SMS, WAP, users shall be informed about the available MBMS services.

> Step 3 | Joining: This is the process by which a subscriber joins a multicast group, i.e. the user indicates to the network that he/she wants to receive Multicast mode data of a specific MBMS bearer service.

> Step 4 | Session Start: This is the phase where BM-SC is ready to send data and this triggers establishment of network resources for data transfer irrespective of whether a given user has activated the service or not.

> Step 5 | MBMS Notification: Notifies the MS of a impending MBMS data transfer.

> Step 6 | Data Transfer: It is the phase when MBMS data are transferred to the UEs.

> Step 7 | Session Stop: In this phase, the BM-SC determines that it has no more data to send for a time period and so the network resources can be released.

> Step 8 | Leaving: In this phase, the user leaves a MBMS group through an Internet Group Management Protocol (IGMP) Leave message.

> MBMS Configuration
> This section provides a high-level series of steps and the associated configuration examples for configuring the system with MBMS user service in GGSN services.
> Important: These instructions assume that you have already configured the GGSN/SGSN system level configuration as described in network function Administration Guide.
> To configure the system to perform Multimedia Broadcast and Multicast service:

> Step 1 | Configure the BM-SC profile in a context by applying the example configurations presented in the BMSC Profile Configuration section.

> Step 2 | Configure the MBMS charging parameters in GTPP Server Group Configuration mode by applying the example configurations presented in the MBMS GTPP Configuration section.

> Step 3 | Configure the MBMS accounting, supported contexts, timeout parameters, and BMSC profile association with APN in APN configuration mode by applying the example configurations presented in the MBMS APN Configuration section.

> Step 4 | Enable the MBMS user service provisioning mode in GGSN and configure the number of MBMS UE and MBMS bearer context in GGSN configuration mode by applying the example configurations presented in the MBMS Provisioning section.

> Step 5 | Save the changes to system configuration by applying the example configuration found in Verifying and Saving Your Configuration chapter.

> Step 6 | Verify configuration of MBMS service related parameters by applying the commands provided in the Managing Your Configuration section of this chapter.

> BMSC Profile Configuration
> This section provides the configuration example to configure the BM-SC profile in a context:
> configure
> context <vpn_context_name> [ -noconfirm ]
> bmsc-profile name <profile_name> [ -noconfirm ]
> default gmb diameter dictionary
> gmb diameter endpoint <endpoint_name>
> gmb diameter peer-select peer < peer_name> [ realm <realm_name> ] [ secondary-peer <sec_peer_name> [ realm <sec_realm_name> ]]
> default gmb user-data mode-preference
> end
> MBMS GTPP Configuration
> This section provides the configuration example to configure the GTPP server parameters in GTPP group configuration mode for MBMS charging:
> configure
> context <vpn_context_name> [ -noconfirm ]
> gtpp group default
> gtpp mbms buckets <cc_bucket>
> gtpp mbms interval <duration_sec>
> gtpp mbms tariff time1 <mins> <hours> [ time2 <mins> <hours> ]
> gtpp mbms volume <download_bytes>
> end
> MBMS APN Configuration
> This section provides the configuration example to enable the BM-SC profile for an APN and to configure the MBMS accounting, supported contexts, and timeout parameters in APN configuration mode:
> configure
> context <vpn_context_name>
> apn <apn_name> [ -noconfirm ]
> mbms bmsc-profile name <profile_name>
> default max-contexts
> accounting mode gtpp
> default mbms bearer timeout { absolute | idle }
> default mbms ue timeout absolute
> end
> MBMS Provisioning
> This section provides the configuration example for provisioning of MBMS service mode for a GGSN service and associating the MBMS policy for multcast broadcast within the GGSN service in GGSN service configuration mode:
> configure
> context <vpn_context_name>
> ggsn-service <ggsn_service_name>
> mbms policy multicast broadcast
> end
> Save the Configuration
> To save changes made to the system configuration for this service, refer Verifying and Saving Your Configuration chapter.
> Managing Your Configuration
> This section explains how to display and review the configurations after saving them in a .cfg file as described in Saving Your Configuration chapter of this guide and also to retrieve errors and warnings within an active configuration for a service.
> Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
> Output descriptions for most of the commands are located in Command Line Interface Reference.

> To do this: | Enter this command:
> View Administrative Information
> Display Current Administrative User Access
> View a list of all administrative users currently logged on to the system | show administrators
> View the context in which the administrative user is working, the IP address from which the administrative user is accessing the CLI, and a system generated ID number | show administrators session id
> View information pertaining to local-user administrative accounts configured for the system | show local-user verbose
> View statistics for local-user administrative accounts | show local-user statistics verbose
> View information pertaining to your CLI session | show cli
> Determining the System’s Uptime
> View the system’s uptime (time since last reboot) | show system uptime
> View the Status of Configured NTP Servers
> View the status of the configured NTP servers | show ntp status
> View the Statistics of Broadcast Multicast service
> View the full information of all broadcast-multicast service session | show multicast-sessions full all
> View the status of all broadcast multicast-service session | show session in-progress
> View all session for broadcast-multicast service | show multicast-sessions all
> View Subscribers Currently Accessing the System
> View a listing of subscribers currently accessing the system | show subscribers all
> View information for a specific subscriber | show subscribers full username <user_name>
> View the MBMS Related Information
> Display Configured MBMS service
> View the configuration of a context | show configuration context <vpn_ctxt_name>
> View configuration errors for GGSN service | show configuration errors section ggsn-service [ verbose ] [ | {grep <grep_options> | more } ]
> Display BM-SC server Information | show bmsc servers

> ‌
> Gathering MBMS Statistics
> The following table lists the commands that can be used to gather the statistics for MBMS.
> Important: All commands listed here are under Exec mode. For more information on these commands, refer Executive Mode Commands chapter in Command Line Interface Reference.
> Gathering Statistics

> Statistics Wanted | Action to Perform | Information to Look For
> Gmb interface statistics for APN and BM-SC profile | At the Exec Mode prompt, enter the following command: show gmb statistics [ apn <apn_name> | bmsc-profile <bmsc_profile_name> ] [ verbose ] | The output of this command displays the statistics about the Gmb interface session for MBMS on an APN.
> Detailed MBMS bearer service statistics | At the Exec Mode prompt, enter the following command: show mbms bearer-service [ mcast-address <mcast_address> ] [ apn <apn_name> ] [ bmsc-profile <bmsc_profile_name> ] [ service-type { multicast | broadcast } ] [ summary | full ] [ all ] | The output of this command displays the MBMS bearer service statistics.
> Detailed statistics of MBMS multicast sessions | At the Exec Mode prompt, enter the following command: show multicast-sessions | The output of this command displays the detailed statistics of MBMS multicast session running on system.

> ‌
> Appendix M
> Multi-Protocol Label Switching (MPLS) Support
> This chapter describes the system’s support for BGP/MPLS VPN and explains how it is configured. The product administration guides provide examples and procedures for configuration of basic services on specific systems. 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.
> When enabled through a feature license key, the system supports MPLS to provide a VPN connectivity from the system to the corporate’s network.
> Important: This release provides BGP/MPLS VPN for directly connected PE routers only.
> MP-BGP is used to negotiate the routes and segregate the traffic for the VPNs. The network node learns the VPN routes from the connected Provider Edge (PE), while the PE populates its routing table with the routes provided by the network functions.
> This chapter includes following sections:

> • | Overview

> • | Supported Standards

> • | Supported Networks and Platforms

> • | Licenses

> • | Benefits

> • | Configuring BGP/MPLS VPN with Static Labels

> • | Configuring BGP/MPLS VPN with Dynamic Labels

> Overview
> As seen in the following scenario, the chassis can be deployed as a router while supporting BGP/MPLS-VPN in a network.

> • | Chassis as MPLS-Customer Edge (MPLS-CE) connecting to Provider Edge (PE)

> • | Chassis as MPLS-Customer Edge (MPLS-CE) connecting to Autonomous System Border Router (ASBR)

> Chassis as MPLS-CE Connecting to PE
> Chassis as MPLS-CE Connected to PE
> The system in this scenario uses static/dynamic MPLS labels for ingress and egress traffic. For configuration information on static label, refer to the Configuring BGP/MPLS VPN with Static Labels section and refer Configuring BGPMPLS VPN with Dynamic Labels for dynamic lable configuration.
> The system is in a separate autonomous system (AS) from the Provider Edge (PE). It communicates with the PE and all VPN routes are exchanged over MP-BGP. Routes belonging to different VPNs are logically separated, using separate virtual route forwarding tables (VRFs).
> Routes for each VPN are advertised as VPN-IPv4 routes, where route distinguishers are prepended to regular IPv4 routes to allow them to be unique within the routing table. Route targets added to the BGP extended community attributes identify different VPN address spaces. The particular upstream BGP peer routing domain (VPN), from which a route is to be imported by the downstream peer into an appropriate VRF, is identified with an extended community in the advertised NLRI.
> A unique label is also received or advertised for every VPN route.
> The Customer Edge (CE) also advertises routes to the PE using NLRIs that include route distinguishers to differentiate VPNs, an extended community to identify VRFs, and a MPLS-lable, which will later be used to foward data traffic.
> There is a single MPLS-capable link between the CE and the PE. MP-BGP communicates across this link as a TCP session over IP. Data packets are sent bidirectionally as MPLS encapsulated packets.
> This solution does not use any MPLS protocols. The MPLS label corresponding to the immediate upstream neighbor can be statically configured on the downstream router, and similarly in the reverse direction.
> When forwarding subscriber packets in the upstream direction to the PE, the CE encapsulates packets with MPLS headers that identify the upstream VRF (the label sent with the NLRI) and the immediate next hop. When the PE receives a packet it swaps the label and forward.
> The CE does not run any MPLS protocol (LDP or RSVP-TE).
> When receiving data packets in the downstream direction from the PE, the label is checked to identify the destination VRF. Then the packet is de-encapsulated into an IP packet and sent to the session subsystem for processing.
> Important: MPLS ping/trace route debugging facilities are not supported.
> Chassis as MPLS-CE Connected to ASBR
> Chassis as MPLS-CE Connected to ASBR
> The system in this scenario uses static/dynamic MPLS labels for ingress and egress traffic. For configuration information on static label, refer to the Configuring BGP/MPLS VPN with Static Labels section and refer Configuring BGPMPLS VPN with Dynamic Labels for dynamic lable configuration.
> This scenario differs from the MPLS-CE with PE scenario in terms of peer functionality even though MPLS-CE functionality does not change. Like the MPLS-CE with PE scenario, MPLS-CE system maintains VRF routes in various VRFs and exchanges route information with peer over MP-eBGP session.
> The peer in this scenario is not a PE router but an Autonomous System Border Router (ASBR). The ASBR does not need to maintain any VRF configuration. The PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an ASBR or to a route reflector (of which the ASBR is a client). The ASBR then uses the eBGP to redistribute those labeled VPN-IPv4 routes to an MPLS-CE in another AS. Because of the eBGP connection, the ASBR changes the next-hop and labels the routes learned from the iBGP peers before advertising to the MPLS-CE. The MPLS-CE is directly connected to the eBGP peering and uses only the the MP-eBGP to advertise and learn routes. The MPLS-CE pushes/pops a single label to/from the ASBR, which is learned over the MP-eBGP connection. This scenario avoids the configuration of VRFs on the PE, which have already been configured on the MPLS-CE.
> Engineering Rules

> • | Up to 250 virtual routing tables per context.

> • | Up to 5000 “host routes” spread across multiple VRFs per BGP process. Limited to 6000 pool routes per chassis.

> • | Up to 1024 VRFs per chassis.

> Supported Standards
> Support for the following standards and requests for comments (RFCs) have been added with this interface support:

> • | RFC 4364, BGP/MPLS IP VPNs

> • | RFC 3032, MPLS Label Stack Encoding

> Important: One or mor esections of above mentioned IETF are partially supported for this feature. For more information on Statement of Compliance, contact local represntative.
> Supported Networks and Platforms
> This feature supports all ASR5000 platforms with StarOS Release 9.0 or later running with network function services.
> Licenses
> This feature support requires following feature license/s installed on the system:

> • | Cisco PID [ ASR5K-00-CS01MPLS ] MPLS License, 1K Sessions, or Starent Part Number [ 600-00-7579 ] MPLS License, 1K Sessions.

> • | Cisco PID [ ASR5K-00-CS10MPLS ] MPLS License, 10K Sessions, or Starent Part Number [ 600-20-0041 ] MPLS License, 10K Sessions.

> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
> Benefits
> MPLS provides networks with a more efficient way to manage applications and move information between locations. MPLS prioritizes network traffic, so administrators can specify which applications should move across the network ahead of others.
> Configuring BGP/MPLS VPN with Static Labels
> This section describes the procedures required to configure the system as an MPLS-CE to interact with a PE with static MPLS label support.
> The base configuration, as described in the Routing chapter in this guide, must be completed prior to attempt the configuration procedure described below.
> Important: The features described in this chapter is an enhanced feature and need enhanced feature license. This support is only available if you have purchased and installed particular feature support license on your chassis.
> 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.
> To configure the system for BGP/MPLS VPN:

> Step 1 | Create a VRF on the router and assign a VRF name by applying the example configuration in the Create VRF with Route-distinguisher and Route-target section.

> Step 2 | Set the neighbors and address family to exchange routing information and establish BGP peering with a peer router by applying the example configuration in the Set Neighbors and Enable VPNv4 Route Exchange section.

> Step 3 | Configure the address family and redistribute the connected routes domains into BGP by applying the example configuration in the Configure Address Family and Redistribute Connected Routes section. This takes any routes from another protocol and redistributes them to BGP neighbors using the BGP protocol.

> Step 4 | Configure IP Pools with MPLS labels for input and output by applying the example configuration in the Configure IP Pools with MPLS Labels section.

> Step 5 | Optional. Bind DHCP service to work with MPLS labels for input and output in corporate networks by applying the example configuration in the Bind DHCP Service for Corporate Servers section.

> Step 6 | Optional. Bind AAA/RADIUS server group in corporate network to work with MPLS labels for input and output by applying the example configuration in the Bind AAA Group for Corporate Servers section.

> Step 7 | Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

> Create VRF with Route-distinguisher and Route-target
> Use this example to first create a VRF on the router and assign a VRF name. The second ip vrf command creates the route-distinguisher and route-target.
> configure
> context <context_name> -noconfirm
> ip vrf <vrf_name>
> router bgp <as_number>
> ip vrf <vrf_name>
> route-distinguisher {<as_value> | <ip_address>} <rt_value>
> route-target export {<as_value> | <ip_address>} <rt_value>
> end
> Set Neighbors and Enable VPNv4 Route Exchange
> Use this example to set the neighbors and address family to exchange VPNv4 routing information with a peer router.
> configure
> context <context_name>
> router bgp <as_number>
> neighbor <ip_address> remote-as <AS_num>
> address-family vpnv4
> neighbor <ip_address> activate
> neighbor <ip_address> send-community both
> exit
> interface <bind_intfc_name>
> ip address <ip_addr_mask_combo>
> end
> Configure Address Family and Redistributed Connected Routes
> Use this example to configure the address-family and to redistribute the connected routes or IP pools into BGP. This takes any routes from another protocol and redistributes them using the BGP protocol.
> configure
> context <context_name>
> router bgp <as_number>
> address-family ipv4 <type> vrf <vrf_name>
> redistribute connected
> end
> Configure IP Pools with MPLS Labels
> Use this example to configure IP Pools with MPLS labels for input and output.
> configure
> context <context_name> -noconfirm
> ip pool <name> <ip_addr_mask_combo> private vrf <vrf_name> mpls-label input <in_label_value> output <out_label_value1> nexthop-forwarding-address <ip_addr_bgp_neighbor>
> end
> Bind DHCP Service for Corporate Servers
> Use this example to bind DHCP service with MPLS labels for input and output in Corporate network.
> configure
> context <dest_ctxt_name>
> interface <intfc_name> loopback
> ip vrf forwarding <vrf_name>
> ip address <bind_ip_address subnet_mask>
> exit
> dhcp-service <dhcp_svc_name>
> dhcp ip vrf <vrf_name>
> bind address <bind_ip_address> [ nexthop-forwarding-address <nexthop_ip_address> [ mpls-label input <in_mpls_label_value> output <out_mpls_label_value1> [ <out_mpls_label_value2> ]]]
> dhcp server <ip_address>
> end
> Notes:

> • | To ensure proper operation, DHCP functionality should be configured within a destination context.

> • | Optional keyword nexthop-forwarding-address <ip_address> mpls-label input <in_mpls_label_value> output < <out_mpls_label_value1> applies DHCP over MPLS traffic.

> Bind AAA Group for Corporate Servers
> Use this example to bind AAA server groups with MPLS labels for input and output in Corporate network.
> configure
> context <dest_ctxt_name>
> aaa group <aaa_grp_name>
> radius ip vrf <vrf_name>
> radius attribute nas-ip-address address <nas_address> nexthop-forwarding-address <ip_address> mpls-label input <in_mpls_label_value> output < <out_mpls_label_value1>
> radius server <ip_address> encrypted key <encrypt_string> port <iport_num>
> end
> Notes:

> • | aaa_grp_name is a pre-configured AAA server group configured in Context Configuration mode. Refer AAA Interface Administration Reference for more information on AAA group configuration.

> • | Optional keyword nexthop-forwarding-address <ip_address> mpls-label input <in_mpls_label_value> output < <out_mpls_label_value1> associates AAA group for MPLS traffic.

> Configuring BGP/MPLS VPN with Dynamic Labels
> This section describes the procedures required to configure the system as an MPLS-CE to interact with a PE with dynamic MPLS label support.
> The base configuration, as described in the Routing chapter in this guide, must be completed prior to attempt the configuration procedure described below.
> Important: The features described in this chapter is an enhanced feature and need enhanced feature license. This support is only available if you have purchased and installed particular feature support license on your chassis.
> 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.
> To configure the system for BGP/MPLS VPN:

> Step 1 | Create a VRF on the router and assign a VRF name by applying the example configuration in the Create VRF with Route-distinguisher and Route-target section.

> Step 2 | Set the neighbors and address family to exchange routing information and establish BGP peering with a peer router by applying the example configuration in the Set Neighbors and Enable VPNv4 Route Exchange section.

> Step 3 | Configure the address family and redistribute the connected routes domains into BGP by applying the example configuration in the Configure Address Family and Redistribute Connected Routes section. This takes any routes from another protocol and redistributes them to BGP neighbors using the BGP protocol.

> Step 4 | Configure IP Pools with dynamic MPLS labels by applying the example configuration in the Configure IP Pools with MPLS Labels section.

> Step 5 | Optional. Bind DHCP service to work with dynamic MPLS labels in corporate networks by applying the example configuration in the Bind DHCP Service for Corporate Servers section.

> Step 6 | Optional. Bind AAA/RADIUS server group in corporate network to work with dynamic MPLS labels by applying the example configuration in the Bind AAA Group for Corporate Servers section.

> Step 7 | Optional. Modify the configured IP VRF, which is configured to support basic MPLS functionality, for mapping between DSCP bit value and experimental (EXP) bit value in MPLS header for ingress and egress traffic by applying the example configuration in the DSCP and EXP Bit Mapping section.

> Step 8 | Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

> Create VRF with Route-distinguisher and Route-target
> Use this example to first create a VRF on the router and assign a VRF name. The second ip vrf command creates the route-distinguisher and route-target.
> configure
> context <context_name> -noconfirm
> ip vrf <vrf_name>
> router bgp <as_number>
> ip vrf <vrf_name>
> route-distinguisher {<as_value> | <ip_address>} <rt_value>
> route-target export {<as_value> | <ip_address>} <rt_value>
> route-target import {<as_value> | <ip_address>} <rt_value>
> end
> Notes:

> • | If export and improt route targets are the same, alternate command route-target both {<as_value> | <ip_address> } <rt_value> can be used in place of route-target import and route-target export commands.

> Set Neighbors and Enable VPNv4 Route Exchange
> Use this example to set the neighbors and address family to exchange VPNv4 routing information with a peer router.
> configure
> context <context_name>
> mpls bgp forwarding
> router bgp <as_number>
> neighbor <ip_address> remote-as <AS_num>
> address-family vpnv4
> neighbor <ip_address> activate
> neighbor <ip_address> send-community both
> exit
> interface <bind_intfc_name>
> ip address <ip_addr_mask_combo>
> end
> Configure Address Family and Redistributed Connected Routes
> Use this example to configure the address-family and to redistribute the connected routes or IP pools into BGP. This takes any routes from another protocol and redistributes them using the BGP protocol.
> configure
> context <context_name>
> router bgp <as_number>
> address-family ipv4 <type> vrf <vrf_name>
> redistribute connected
> end
> Configure IP Pools with MPLS Labels
> Use this example to configure IP Pools with dynamic MPLS labels.
> configure
> context <context_name> -noconfirm
> ip pool <name> <ip_addr_mask_combo> private vrf <vrf_name>
> end
> Bind DHCP Service for Corporate Servers
> Use this example to bind DHCP service with dynamic MPLS labels in Corporate network.
> configure
> context <dest_ctxt_name>
> interface <intfc_name> loopback
> ip vrf forwarding <vrf_name>
> ip address <bind_ip_address subnet_mask>
> exit
> dhcp-service <dhcp_svc_name>
> dhcp ip vrf <vrf_name>
> bind address <bind_ip_address>
> dhcp server <ip_address>
> end
> Notes:

> • | To ensure proper operation, DHCP functionality should be configured within a destination context.

> Bind AAA Group for Corporate Servers
> Use this example to bind AAA server groups with dynamic MPLS labels in Corporate network.
> configure
> context <dest_ctxt_name>
> aaa group <aaa_grp_name>
> radius ip vrf <vrf_name>
> radius attribute nas-ip-address address <nas_address>
> radius server <ip_address> encrypted key <encrypt_string> port <iport_num>
> end
> Notes:

> • | aaa_grp_name is a pre-configured AAA server group configured in Context Configuration mode. Refer AAA Interface Administration Reference for more information on AAA group configuration.

> DSCP and EXP Bit Mapping
> Use this example to modify the configured IP VRF to support QoS mapping.
> configure
> context <context_name>
> ip vrf <vrf_name>
> mpls map-dscp-to-exp dscp <dscp_bit_value> exp <exp_bit_value>
> mpls map-exp-to-dscp exp <exp_bit_value> dscp <dscp_bit_value>
> end
> Appendix N
> Rejection/Redirection of HA Sessions on Network Failures
> 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.
> The following sctions are included in this chapter:

> • | Overview

> • | Configuring HA Session Redirection

> • | RADIUS Attributes

> Overview
> This feature enables the HA service to either reject new calls or redirect them to another HA when a destination network connection failure is detected. When network connectivity is re-established, the HA service begins to accept calls again in the normal manner.
> The way this is implemented in the system is as follows:

> • | A policy is configured in the HA service that tells the service what action to take when network connectivity is lost. New calls are either directed to one of up to 16 different IP addresses or all new calls are rejected until network connectivity is restored.

> • | In the destination context, a network reachability server is configured. This is a device on the destination network to which ping packets are periodically sent to determine if the network is reachable. As soon as a network reachability server is configured, pinging of the server commences whether or not the server name is bound to a subscriber or an IP pool.

> • | The name of the network reachability server configured in the destination context is bound to either a local subscriber profile or an IP pool. If the subscriber is authenticated by an AAA server, RADIUS attributes may specify the network reachability server for the subscriber. (If an IP pool has a network reachability server name bound to it, that takes precedence over both the RADIUS attributes and the local subscriber configuration.)

> Configuring HA Session Redirection
> This section provides instructions for configuring rejection or redirection of HA sessions on the event of a network failure. These instructions assume that there is a destination context. and HA service, an IP pool, and a subscriber already configured and that you are at the root prompt for the Exec mode:
> [local]host_name#

> • | Enter the global configuration mode by entering the following command:

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

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

> context <context_name>
> context_name is the name of the destination context where the HA service is configured. The name must be from 1 to 63 alpha and/or numeric characters and is case sensitive.The following prompt appears:
> [<context_name>]host_name(config-ctx)#

> • | Enter the HA service configuration mode by entering the following command:

> ha-service <ha_service_name>
> ha_service_name is the name of the HA service. The name must be from 1 to 63 alpha and/or numeric characters and is case sensitive.The following prompt appears:
> [<context_name>]host_name(config-ha-service)#

> • | Configure the action for the HA service to take when network connectivity is lost by entering the following command:

> policy nw-reachability-fail { reject [ use-reject-code { admin-prohibited | insufficient-resources } ] | redirect <ip_addr1> [ weight <value> ] [ <ip_addr2> [ weight <value> ] ] ... [ <ip_addr16> [ weight <value> ] ] }

> Keyword/Variable | Description
> reject | Upon network reachability failure reject all new calls for this context.
> use-reject-code { admin-prohibited | insufficient-resources } | When rejecting calls send the specified reject code. If this keyword is not specified the admin-prohibited reject code is sent by default.
> redirect <ip_addr1> [ weight <value> ] [ <ip_addr2> [ weight <value> ] ] ... [ <ip_addr16> [ weight <value> ] ] | Upon network reachability failure redirect all calls to the specified IP address. <ip_addr>: This must be an IPv4 address. Up to 16 IP addresses and optional weight values can be entered on one command line. weight <value>: When multiple addresses are specified, they are selected in a weighted round-robin scheme. If a weight is not specified, the entry is automatically assigned a weight of 1. <value> must be an integer from 1 through 10.

> ‌

> • | Enter the following command to return to the context configuration mode:

> exit
> The following prompt appears:
> [<context_name>]host_name(config-ctx)#

> • | Specify the network device on the destination network to which ping packets should be sent to test for network reachability, by entering the following command:

> nw-reachability server <server_name> [ interval <seconds> ] [ local-addr <ip_addr> ] [ num-retry <num> ] [ remote-addr <ip_addr> ] [ timeout < seconds> ]

> Keyword/Variable | Description
> server_name | A name for the network device that is sent ping packets to test for network reachability.
> interval <seconds> | Default: 60 seconds Specifies the frequency in seconds for sending ping requests.<seconds> must be an integer from 1 through 3600.
> local-addr <ip_addr> | Specifies the IP address to be used as the source address of the ping packets; If this is unspecified, an arbitrary IP address that is configured in the context is used. <ip_addr> must be an IP v4 address.
> num-retry <num> | Default: 5 Specifies the number of retries before deciding that there is a network-failure. <num> must be an integer from 0 through 100.
> remote-addr <ip_addr> | Specifies the IP address of a network element to use as the destination to send the ping packets for detecting network failure or reachability. <ip_addr> must be an IPv4 address.
> timeout < seconds> | Default: 3 seconds Specifies how long to wait, in seconds, before retransmitting a ping request to the remote address. <seconds> must be an integer from 1 through 10.

> ‌

> • | Repeat step 6 to configure additional network reachability servers.

> • | To bind a network reachability server to an IP pool, continue with step 9. To bind a network reachability server to a local subscriber profile, skip to step 11.

> • | To bind a network reachability server name to an IP pool, enter the following command:

> ip pool <pool_name> nw-reachability server <server_name>

> <pool_name> | The name of an existing IP pool in the current context.
> nw-reachability server <server_name> | Bind the name of a configured network reachability server to the IP pool and enable network reachability detection for the IP pool. This takes precedence over any network reachability server settings in a subscriber configuration or RADIUS attribute. <server_name>: The name of a network reachability server that has been defined in the current context. This is a string of from 1 through 16 characters.

> ‌

> • | Repeat step 9 for additional IP pools in the current context then skip to step 13.

> • | Enter the subscriber configuration mode by entering the following command:

> subscriber { default | name <subs_name> }
> Where default is the default subscriber for the current context and subs_name is the name of the subscriber profile that you want to configure for network reachability.The following prompt appears:
> [<context_name>]host_name(config-subscriber)#

> • | To bind a network reachability server name to the current subscriber in the current context, enter the following command:

> nw-reachability server <server_name>
> Where server_name is the name of a network reachability server that has been defined in the current context.

> • | Return to the executive mode by entering the following command:

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

> • | Enter the executive mode for the destination context for which you configured network reachability by entering the following command:

> context <context_name>
> Where context_name is the name of the destination context for which you configured network reachability.The following prompt appears:
> [context_name]host_name#

> • | Check the network reachability server configuration by entering the following command

> show nw-reachability server all
> The output of this command appears similar to the following:
> Server remote-addr local-addr state
> --------------- --------------- --------------- ---------------
> nw-server1 192.168.100.20 192.168.1.10 Down
> Total Network Reachability Servers: 1 Up: 0
> Ensure that the remote and local addresses are correct. The state column indicates whether or not the server is reachable (Up) or unreachable (Down).

> • | Check the HA service policy by entering the following command:

> show ha-service name <ha_service_name>
> Where <ha_service_name> is the name of the HA service in the current context for which you configured a network reachability policy.The output of this command includes information about the network reachability policy that looks similar to the following:
> NW-Reachability Policy: Reject (Reject code: Admin Prohibited)

> • | Check the network reachability server name bound to an IP pool by entering the following command:

> show ip pool pool-name <pool_name>
> Where <pool_name> is the name of the IP pool to which you bound a network reachability server name.The output of this command includes information about the network reachability server name that looks similar to the following:
> Network Reachability Detection Server: nw-server1

> • | Check the network reachability server name bound to a local subscriber profile by entering the following command:

> show subscribers configuration username <subscriber_name>
> Where <subscriber_name> is the name of the local subscriber to which you bound a network reachability server name.The output of this command includes information about the network reachability server name that looks similar to the following:
> network reachability detection server name: nw-server1

> • | Save your configuration as described in Verifying and Saving Your Configuration.

> RADIUS Attributes
> Attributes defined in a subscriber profile stored remotely on a RADIUS server can be used to bind the network reachability server to a subscriber session. Use the following attributes to bind a network reachability server to a subscriber session;

> • | SN-Nw-Reachability-Server-Name

> • | SN1-Nw-Reachability-Server-Name

> The attributes have one possible value, which is a variable that is a string of from 1 to 15 characters in length. This should be the name of the configured network reachability server.
> The SN-Nw-Reachability-Server-Name attribute is contained in the following dictionaries:

> • | starent

> • | starent-835

> The SN1-Nw-Reachability-Server-Name attribute is contained in the following dictionaries:

> • | starent-vsa1

> • | starent-vsa1-835

> Refer to the AAA Interface Administration and Reference for more details.
> Appendix O
> Policy Forwarding
> 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 before using the procedures in this chapter.
> Sections in this chapter include:

> • | Overview

> • | IP Pool-based Next Hop Forwarding

> • | Subscriber-based Next Hop Forwarding

> • | ACL-based Policy Forwarding

> Overview
> The system can be configured to automatically forward data packets to a predetermined network destination. This can be done in one of three ways:

> • | IP Pool-based Next Hop Forwarding - Forwards data packets based on the IP pool from which a subscriber obtains an IP address.

> • | ACL-based Policy Forwarding - Forwards data packets based on policies defined in Access Control Lists (ACLs) and applied to contexts or interfaces.

> • | Subscriber specific Next Hop Forwarding - Forwards all packets for a specific subscriber.

> The simplest way to forward subscriber data is to use IP Pool-based Next Hop Forwarding. An IP pool is configured with the address of a next hop gateway and data packets from all subscribers using the IP pool are forward to that gateway.
> Subscriber Next Hop forwarding is also very simple. In the subscriber configuration a nexthop forwarding address is specified and all data packets for that subscriber are forwarded to the specified nexthop destination.
> ACL-based Policy Forwarding gives you more control on redirecting data packets. By configuring an Access Control List (ACL) you can forward data packets from a context or an interface by different criteria, such as; source or destination IP address, ICMP type, or TCP/UDP port numbers.
> ACLs are applied first. If ACL-based Policy Forwarding and Pool-based Next Hop Forwarding or Subscriber are configured, data packets are first redirected as defined in the ACL, then all remaining data packets are redirected to the next hop gateway defined by the IP pool or subscriber profile.
> IP Pool-based Next Hop Forwarding
> When an IP pool in a destination context has a Next Hop Forwarding address specified, any subscriber that obtains an IP address from that IP pool has all data coming from the mobile node automatically forwarded to the specified Next Hop Forwarding address.
> For more information on creating IP pools, refer to the System Administration Guide and for additional information on the ip pool command, refer to the Command Line Interface Reference.
> Configuring IP Pool-based Next Hop Forwarding
> Configure Next Hop Forwarding on an existing IP Pool in a destination context by applying the following example configuration:
> configure
> context <context_name>
> ip pool <pool_name> nexthop-forwarding-address <forwarding_ip_address>
> end
> Save the configuration as described in the Saving Your Configuration chapter.
> Subscriber-based Next Hop Forwarding
> When a subscriber configuration has a Next Hop Forwarding address specified, any sessions authenticated as that subscriber have all data coming from the mobile node automatically forwarded to the specified Next Hop Forwarding address.
> Configuring Subscriber-based Next Hop Forwarding
> Configure Next Hop Forwarding for a specific subscriber by applying the following example configuration:
> configure
> context <context_name>
> subscriber name <subs_name>
> nexthop-forwarding-address <forwarding_ip_address>
> end
> Save the configuration as described in the Saving Your Configuration chapter.
> ACL-based Policy Forwarding
> ACL-based Policy Forwarding is a feature in the system that forwards subscriber data based on policies defined in Access Control Lists (ACLs). When ACLs are applied to access groups, priorities are given to the ACLS. The ACL applied with the highest priority is used to define the policy that is used for forwarding the subscriber data.
> Important: Refer to Access Control Lists for additional information on creating and using ACLs.
> Configuring ACL-based Policy Forwarding
> Configure ACL-based Policy Forwarding by applying the following example configuration:
> configure
> context <context_name>
> ip access-list <acl_name>
> redirect <interface_name> <next_hop_address> <criteria>
> exit
> The following example specifies that any IP packet coming from any system on the 192.168.55.0 network that has a destination host address of 192.168.80.1 is to be redirected, or forwarded, through the system interface named interface2 to the host at 192.168.23.12:
> redirect interface2 192.168.23.12 ip 192.168.55.0 255.255.255.0 host 192.168.80.1
> Save the configuration as described in the Saving Your Configuration chapter.
> Applying the ACL to an IP Access Group
> To apply the ACL to the IP access group for the current destination context, go to Applying the ACL to a Destination Context.
> To apply the ACL to the IP access group for an interface in the current destination context, go to Applying the ACL to an Interface in a Destination Context .
> Applying the ACL to a Destination Context

> Step 1 | At the context configuration mode prompt, enter the following command:

> ip access-group <acl_name> {in | out} <priority-value>

> Step 2 | Save the configuration as described in the Saving Your Configuration chapter.

> Applying the ACL to an Interface in a Destination Context

> Step 1 | Set parameters for inbound data by applying the following example configuration:

> configure
> context <context_name>
> interface <interface_name>
> ip access-group <acl_name> in <priority-value>
> end

> Step 2 | Set parameters for outbound data by applying the following example configuration:

> configure
> context <context_name>
> interface <interface_name>
> ip access-group <acl_name> out <priority-value>
> end

> Step 3 | Save the configuration as described in the Saving Your Configuration chapter.

> Appendix P
> 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: This feature is enabled as part of a license bundle or with the purchase of a standalone Proxy-MIP license. Other licenses might be required to enable all the features described in this chapter. If you do not have the appropriate license(s), please contact your sales advisor.
> 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 as described in Verifying and Saving Your Configuration.

> 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 as described in Verifying and Saving Your Configuration.

> 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 as described in Verifying and Saving Your Configuration.

> 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 as described in Verifying and Saving Your Configuration.

> 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 as described in Verifying and Saving Your Configuration.
> 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 as described in Verifying and Saving Your Configuration.

> Appendix Q
> QoS Management
> This chapter describes the Quality of Service (QoS) management on ST16 and Cisco® ASR 5000 chassis 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 the respective product Administration Guide, before using the procedures in this chapter.
> This chapter describes the following topics:

> • | Introduction

> • | Dynamic QoS Renegotiation

> • | Network Controlled QoS (NCQoS)

> • | Configuring Dynamic QoS Renegotiation

> • | Configuring Network Controlled QoS (NCQoS)

> • | Monitoring Dynamic QoS Renegotiation Operation

> Introduction
> The QoS Traffic Policing functionality supported by the GGSN implements QoS for subscribers based on the configuration of the APN template used as described in Traffic Policing and Shaping in this guide. As a result, all subscriber PDP contexts using the APN receive the same QoS level. This could lead to unused or under-utilized bandwidth by some subscribers and thus reducing the amount of resources available to others.
> Dynamic QoS Renegotiation
> Dynamic QoS Renegotiation minimizes the risk of bandwidth mis-appropriation. This feature allows the GGSN to analyze application traffic, and trigger QoS renegotiation with the SGSN to optimize service performance.
> In Dynamic QoS Renegotiation, the GGSN performs packet inspection of application traffic to detect the type of service being utilized and automatically renegotiates the QoS to the appropriate level with a maximum QoS level corresponding to the level granted by the HLR. QoS renegotiation is performed by sending an update PDP context request to the SGSN. This solution is optimal since the appropriate QoS level is always granted to the subscriber without any requirement on the handset or on the core network. The only prerequisite is QoS renegotiation support on the SGSN. In this model, over reservation of radio resources is avoided, while maintaining the appropriate bandwidth for subscribers with real requirements.
> The ASR 5000 and ST16 support L7 stateful analysis and QoS Renegotiation. Combining these functionalities results in Dynamic QoS Renegotiation. The system also generates CDRs (or real time charging information) that includes the current QoS information and the service accessed. This enables intelligent application-based charging of services, taking into account the granted QoS. It also enables rebates when it was not possible to provide the QoS level required by an application.
> Important: For L7 traffic analysis ECSv2 license is required.
> How Dynamic QoS Renegotiation Works
> Implementation of Dynamic QoS Renegotiation involves the following:

> • | Initial QoS

> • | Service Detection

> • | Classification of Application Traffic

> • | Quality of Service Renegotiation

> Initial QoS
> When the session is established, an initial level of QoS must be assigned to the subscriber. The GGSN may either grant the requested QoS, or grant a lower QoS level (minimum or intermediate level). The initial QoS remains in effect until the SGSN or GGSN requests a change. When Dynamic QoS Renegotiation is enabled, there are several conditions when the system would request a QoS change.

> • | Services detected that do not need high QoS: After a configurable time period of a subscriber having terminated services that require high QoS, the system could lower the QoS to a value more appropriate to the services actually being used.

> • | Services detected that require higher QoS: As soon as a subscriber begins using a service that needs a high QoS, the system immediately attempts to raise the QoS through its service detection capability.

> Service Detection
> The Application analysis approach to service detection uses application level (L7) information. In the ASR 5000 and ST16 chassis, application analysis is stateful—keeping track of the application state.
> Important: For L7 traffic analysis ECSv2 license is required.
> Classification of Application Traffic
> Application traffic can be classified into the following: Conversational, Streaming, Interactive 1, Interactive 2, Interactive 3, or Background. For more information refer to the Traffic Policing and Shaping chapter. Traffic class can be configured in the charging-action, but it does not take direction as a parameter. However, a rule matching only uplink or only downlink packets associated that with the charging-action can be configured.
> For QoS renegotiation a way is needed to find out what kind of data packets are flowing through for a particular user to associate a given traffic class with the user's current usage pattern. It can be done through packet inspection as for a subscriber profile, Access Control List (ACL) does the inspection. Limits for each traffic class can be configured in the APN. The same infrastructure is reused to perform Dynamic QoS Renegotiation.
> After classification of traffic, if required by subscriber profile, Dynamic QoS Renegotiation takes place.
> L4 Packet Inspection
> The advantages of L4 packet analysis is no or low impact on the system performance, and enables QoS adaptation with very limited impact on the system capacity. L4 packet inspection is fully supported by the system.
> L7 Packet Inspection
> The advantages of L7 packet analysis is higher impact on the system performance, and QoS adaptation with very limited impact on the system capacity. L7 packet inspection involves complete application layer analysis and copes with customized applications.
> Dynamic QoS Renegotiation
> Dynamic QoS Renegotiation minimizes the risk of bandwidth mis-appropriation. This feature allows the GGSN to analyze application traffic, and trigger QoS renegotiation with the SGSN to optimize service performance.
> In Dynamic QoS Renegotiation, the GGSN performs packet inspection of application traffic to detect the type of service being utilized and automatically renegotiates the QoS to the appropriate level with a maximum QoS level corresponding to the level granted by the HLR. QoS renegotiation is performed by sending an update PDP context request to the SGSN. This solution is optimal since the appropriate QoS level is always granted to the subscriber without any requirement on the handset or on the core network. The only prerequisite is QoS renegotiation support on the SGSN. In this model, over reservation of radio resources is avoided, while maintaining the appropriate bandwidth for subscribers with real requirements.
> The ASR 5000 and ST16 support L7 stateful analysis and QoS Renegotiation. Combining these functionalities results in Dynamic QoS Renegotiation. The system also generates CDRs (or real time charging information) that includes the current QoS information and the service accessed. This enables intelligent application-based charging of services, taking into account the granted QoS. It also enables rebates when it was not possible to provide the QoS level required by an application.
> Important: For L7 traffic analysis ECSv2 license is required.
> QoS Renegotiation for a Subscriber QoS Profile
> The following is the overall Dynamic QoS Renegotiation process.

> 1. | When a subscriber attaches to the network, the following happens:

> • | Dampening timer is started for the subscriber.

> • | QoSI is assigned to subscriber. This becomes the QoSC till a re-negotiation occurs, as shown in the following figure.

> • | The traffic class bit-field is cleared.

> 2. | As the subscriber starts using some applications, the traffic gets classified on the basis of type of data packets or traffic as mentioned in section Classification of Application Traffic and accordingly the corresponding bit in Traffic-class-bitfield get set.

> 3. | Following is the mechanics of QoS renegotiation:

> • | Examine traffic-class-bitfield to find out the highest bit that is set. This gives the desired QoS Traffic Class (QoSD). The associated uplink/downlink peak-data-rate and guaranteed-data-rate values will be taken from the configured parameters for this traffic class in the subscriber APN. For more information refer to the Traffic Policing and Shaping chapter.

> • | If QoSC matches QoSD, no QoS renegotiation is required. Otherwise, it sends an Update PDP Context Request to the SGSN with the QoSD values and QoS renegotiation starts.

> • | Reset the dampening timer.

> • | The traffic-class-bitfield is cleared.

> 4. | Following are the conditions under which QoS renegotiation happens:

> • | When a higher priority traffic is detected, QoS is renegotiated immediately, without waiting the dampening times to expire. Thus for example, if the current traffic has a QoS of interactive class and it detects streaming traffic, it will upgrade the QoS at once to Streaming.

> • | When system detects lower priority traffic, it waits for the expiry of the dampening timer before lowering the QoS.

> • | During “silence” or no-traffic, QoS renegotiation requests will not be initiated.

> As seen in the following figure, the QoS profile for the subscriber goes through three renegotiations to match the QoS profile of the (highest priority) application currently being used.
> Dynamic QoS Renegotiation Graph
> When there is no traffic, traffic class drops to “Background”, and the corresponding QoS profile is negotiated as described above.
> Network Controlled QoS (NCQoS)
> Network-controlled QoS is the method by which the QoS for a PDP context (primary or secondary) is updated on the request of the GGSN through Network Requested Update PDP Context (NRUPC) message. It can also activate a new secondary PDP context on Network Requested Secondary PDP Context Activation (NRSPCA) message from the GGSN.
> How Network Controlled QoS (NCQoS) Works
> The GGSN activates or modifies a bearer in case of a service flow matching a statically provisioned Policy and Charging Control (PCC) rules. The network, based on QoS requirements of the application/service determines what bearers are needed and either modifies an existing bearer or activates a new one.
> Statically provisioned PCC rules, called Network Requested Operation (NRO) rules, are configured as charging rules in Active Charging Service (ACS). As a part of charging action for such rules, QoS-needed and corresponding Traffic Flow Template (TFT) packet filter is configured. QoS-needed mainly consists of QoS Class Identifier (QCI) and data rates. Whereas, TFT mainly consists of uplink and downlink packet filter information.
> Warning: This feature does not work in conjunction with IMS-Authorization service.
> When a packet arrives, Active Charging Service (ACS) analyzes it and proceeds for rule matching based on the priority in the rulebase. If an NRO rule bound to the context on which the packet arrived matches, ACS applies the bandwidth limit and gating. If an NRO rule bound to some other context matches, ACS discards the packet.
> If an unbound NRO rule matches, ACS finds a context with the same QCI as the NRO rule, where context’s Maximum Bit Rate (MBR) and matched rule’s MBR (context's MBR + matched rule's MBR) is less than the MBR for that QCI in the APN. If such a context is found, NRUPC for that context is triggered. If the request succeeds, the rule will be bound to that context.
> Important: The packet that triggers the NRUPC request is discarded.
> If no context satisfying the MBR limit is found, or if there is no context with the same QCI as the NRO rule, the system triggers NRSPCA. If the request succeeds, the rule will be bound to that context.
> Important: The packet that triggers the NRSPCA request is discarded.
> TFTs from the charging-action associated with the NRO rule are also sent as part of the NRUPC/NRSPCA request, and sent back as part of Create PDP Context response.
> Finally, if a non-NRO rule matches, ACS proceeds with the normal processing of that packet. Non-NRO charging-actions can still do “flow action” or ITC (limit-for-flow-type and limit-for-bandwidth).
> ACS also takes care of following:

> • | Before ACS makes an NRUPC/NRSPCA request, it checks if there is any outstanding request for the same QCI for the same subscriber. If there is any, it will not make the new request, and it discards the packet.

> • | After a context is terminated, ACS unbinds all the rules bound to that context. Such a rule can later be bound to some other context when a packet matches that rule.

> Important: The packet that triggers the NRUPC/NRSPCA request is discarded.
> Configuring Dynamic QoS Renegotiation
> This section describes how to configure per-APN based Dynamic QoS Renegotiation.
> Caution: For Dynamic QoS Renegotiation, two RADIUS attributes are required for remote subscriber configuration. For a particular subscriber, these attributes can be overridden without considering the timeout for Dynamic QoS Renegotiation and whether Dynamic QoS Renegotiation is enabled or not.
> To configure Dynamic QoS Renegotiation:

> Step 1 | Configure an Access Control List (ACL), as described in the Configuring ACL for Dynamic QoS Renegotiation section.

> Step 2 | Configure an APN for Dynamic QoS Renegotiation as described in the Configuring APNs for Dynamic QoS Renegotiation section.

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Step 4 | Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.

> Important: Commands used in the configuration examples 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 ACL for Dynamic QoS Renegotiation
> Configuring an ACL and applying it to an APN template are required to specify permission and treatment levels for Dynamic QoS Renegotiation.
> Use the following example to configure an ACL for Dynamic QoS Renegotiation:
> configure
> context <context_name>
> ip access-list <acl_name>
> permit { tcp | udp } ........ treatment { background | conversational | interactive-1 | interactive-2 | interactive-3 | streaming }
> end
> Notes:

> • | <context_name> must be the name of the destination context in which you want to configure the ACL. The same context must be used for APN configuration.

> • | For information on configuring the rules that comprise the ACL, in the IP Access Control Lists chapter, see the Configuring ACLs on the System section.

> Configuring Charging Action for Dynamic QoS Renegotiation
> Use the following example to configure charging action parameters for Dynamic QoS Renegotiation support:
> configure
> active-charging service <service_name>
> charging-action <charging_action_name> -noconfirm
> qos-renegotiate traffic-class streaming
> flow action discard
> flow limit-for-bandwidth direction downlink peak-data-rate <bps> peak-burst-size <bytes> violate-action lower-ip-precedence
> end
> Notes:

> • | A maximum of eight packet filters can be configured per charging action.

> • | The flow limit-for-bandwidth command contains other option than the example shown here. Refer ti the ACS Charging Action Configuration Mode Commands chapter in the Command Line Interface Reference for more information on this command.

> Configuring Rulebase for Dynamic QoS Renegotiation
> Use the following example to configure rulebase parameters for Dynamic QoS Renegotiation support:
> configure
> active-charging service <service_name>
> rulebase <rulebase_name> [ -noconfirm ]
> qos-renegotiate timeout <timeout>
> end
> Configuring APNs for Dynamic QoS Renegotiation
> Use the following example to configure an APN template’s QoS profile in support of Dynamic QoS Renegotiation:
> configure
> context <context_name>
> apn <apn_name>
> ip access-group <acl_name> [ in | out ]
> end
> Notes:

> • | <context_name> must be the name of the destination context in which you have already configured the ACL, and want to configure the APN template.

> • | <acl_name> must be the name of the ACL that you have already configured in the context.

> • | If in the ip access-group command of the APN Configuration Mode, the optional in or out keywords are not specified, the ACL will be applied to all packets, in and out.

> Configuring Network Controlled QoS (NCQoS)
> To configure NCQoS:

> Step 1 | Configure packet filter parameters as described in the Configuring Packet Filter for NCQoS section.

> Step 2 | Configure charging rules and actions as described in the Configuring Charging Action for NCQoS section.

> Step 3 | Configure APN template and enable bearer control mode for NCQoS as described in the Configuring APN for NCQoS section.

> Step 4 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Step 5 | Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.

> Important: Commands used in the configuration examples 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 Packet Filter for NCQoS
> Use the following example to configure packet filter parameters for NCQoS support:
> configure
> active-charging service <service_name>
> packet-filter <filter_name> [ -noconfirm ]
> ip local-port { = <port_num> | range <start_port_num> to <end_port_num> }
> ip protocol { = <proto_num> | range <start_proto_num> to <end_proto_num> }
> ip remote-address { = { <ip_address> | <ip_address/mask> } | { range { <ip_address> | <ip_address/mask> } to { <ip_address> | <ip_address/mask> } }
> ip remote-port { = <port_num> | range <start_port_num> to <end_port_num> }
> direction { bi-directional | download | upload }
> priority <priority>
> end
> Configuring Charging Action for NCQoS
> Use the following example to configure charging action parameters for NCQoS support:
> configure
> active-charging service <service_name>
> charging-action <charging_action_name> [ -noconfirm ]
> qos-class-identifier <identifier>
> flow action discard [ downlink | uplink ]
> tft packet-filter <filter_name>
> flow limit-for-bandwidth direction { downlink | uplink } peak-data-rate <bps> peak-burst-size <bytes> violate-action { discard | lower-ip-precedence }
> end
> Notes:

> • | A number of optional keywords and variable are available for the flow limit-for-bandwidth direction command. Refer to the Command Line Interface Reference for more information regarding this command.

> Configuring APN for NCQoS
> Use the following example to enable Bearer Control Mode (BCM) for NCQoS support:
> configure
> context <context_name>
> apn <apn_name>
> bearer-control-mode [ mixed | ms-only | none ]
> end
> Notes:

> • | To enable NCQoS, bearer-control-mode in the APN Configuration Mode must be configured with mixed mode.

> Monitoring Dynamic QoS Renegotiation Operation
> Use the following steps to verify/monitor Dynamic QoS Renegotiation operations:

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

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

> • | Verify that the ACLs have been properly applied by entering the following command:

> show apn name <apn_name>
> apn_name must be the name of the APN configured in the Configuring APNs for Dynamic QoS Renegotiation section.The output of this command displays the APN’s configuration. Examine the output for the ip output access-group and ip input access-group fields. For more details refer to the Applying a Single ACL to Multiple Subscribers section in this guide.

> • | Verify that your ACL was configured properly by entering the following command:

> show ip access-list <acl_name>
> The output is a concise listing of IP Access Control List parameter settings.

> • | Monitor your QoS renegotiation status for a subscriber by entering the following command:

> show subscriber ggsn-only full
> The output is a concise listing of subscribers’ settings.

> • | For L7 based QoS Renegotiation, view how many time QoS renegotiations have happened for that session by entering the following command:

> show active-charging sessions full all

> • | View the statistics of APN related to QoS renegotiation parameters by entering the following command:

> show apn statistics { all | name <apn_name> }
> The output is a listing of APN statistics related to QoS Renegotiation.
> Event IDs Pertaining to Dynamic QoS Renegotiation
> The Session Manager facility provides several events that can be useful for diagnosing errors that could occur with implementation of Dynamic QoS Renegotiation feature.
> The following table displays information pertaining to these events.
> Event IDs in Session Manager Pertaining to Dynamic QoS Renegotiation

> Event | Event ID | Type | Additional Information
> QoS Renegotiation timer started for subscriber | 10917 | Info | “Indicates that the Dynamic QoS Renegotiation timer was started for the subscriber”
> QoS Renegotiation timer stopped for subscriber | 10918 | Info | “Indicates that the Dynamic QoS Renegotiation timer was stopped for the subscriber”
> QoS Renegotiation timer expired for subscriber | 10919 | Info | “Indicates that the Dynamic QoS Renegotiation timer was expired for the subscriber”
> QoS Renegotiation message sent for subscriber | 10920 | Info | “Indicates that the Dynamic QoS Renegotiation message was sent for the subscriber”
> L4 classification done for subscriber traffic | 10921 | Info | “Indicates the kind of L4 classification that was done for the subscriber traffic.”

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

> Attribute | Description
> SN-Enable-QoS-Renegotiation (or SN1-Enable-QoS-Renegotiation) | Enables the Dynamic QoS Renegotiation for specific profile application. This attribute displays “enable qos renegotiation”.
> SN-QoS-Renegotiation-Timeout (or SN1-QoS-Renegotiation-Timeout) | Timeout duration for dampening time for QoS renegotiation to specific profile application. This attribute displays “qos renegotiation timeout”.

> ‌
> Appendix R
> Remote Address-based RADIUS Accounting
> This chapter provides information on configuring an enhanced, or extended, service. The product administration guides provide examples and procedures for the 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 before using the procedures in this chapter.
> This chapter includes the following sections:

> • | Overview

> • | Configuring Remote Address-based Accounting

> • | Subscriber Attribute Configuration

> Overview
> Remote address-based RADIUS accounting counts the number of octets exchanged between individual subscribers and specific remote IP addresses, or networks, during a packet data session. Data from the subscriber to the remote addresses, and data from the remote addresses to the subscriber are accounted for separately.
> The remote addresses for which to collect RADIUS accounting data are configured in lists on a per-context basis. Individual subscribers are associated with particular address lists through the configuration or specification of an attribute in their locally configured or RADIUS server-based profiles. Once the lists and subscriber profiles are configured, accounting data collection can be enabled on the system.
> Remote address-based RADIUS accounting is implemented in the system according to the specifications described in TIA/EIA/IS-835-B, CDMA2000 Wireless IP Network Standard, October 2002 and 3GPP2 X.S0011-005-D.
> Licensing
> This feature requires the following license to be installed on the chassis:
> Cisco PID [ ASR5K-00-CS01DBAC ] Destination Based Accounting,1K sessions, or Starent Part Number [ 600-00-7510 ] Destination Based Accounting.
> For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
> Configuring Remote Address-based Accounting
> To configure this functionality, a list of up to ten remote addresses or networks is configured in the authentication context, the list is assigned to a subscriber, and remote address collection is enabled.
> Use the following configuration example to configure remote address-based accounting:
> configure
> context <context_name>
> radius group <group_name>
> radius accounting ip remote-address list <list_id>
> address <ipv4_address/ipv6_address> netmask <netmask>
> end
> Verifying the Remote Address Lists
> Use the following command to verify the remote address lists:
> show configuration context <context_name>
> Output similar to the following is displayed.
> [local] host_name # show configuration context <context_name>
> configure
> context <context_name>
> subscriber default
> exit
> radius accounting ip remote-address list 1
> address <ipv4_address/ipv6_address> netmask <netmask>
> address <ipv4_address/ipv6_address> netmask <netmask>
> address <ipv4_address/ipv6_address> netmask <netmask>
> end
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Subscriber Attribute Configuration
> Subscriber attributes are configured as part of their profile. Subscriber profiles can be configured either remotely on a RADIUS server or locally on the system.
> This section provides information and procedures on the attributes used to support this functionality.
> Important: Since the instructions for configuring subscribers differ between RADIUS server applications, this section only provides the individual attributes that can be added to the subscriber profile. Please refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.
> Supported RADIUS Attributes
> The following RADIUS attributes are used to configure remote address-based RADIUS accounting for a subscriber session. For specific information on each attribute, see the Cisco ASR 5000 Series AAA and GTP Interface Administration and Reference.

> • | 3GPP2-Remote-Addr-Table-Index

> • | 3GPP2-Remote-IPv4-Address

> • | 3GPP2-Remote-IPv4-Addr-Octets

> Configuring Local Subscriber Profiles
> Use the following example to configure local subscriber profiles to support the Remote Address-based RADIUS Accounting feature:
> configure
> context <context_name>
> subscriber name <name>
> radius accounting ip remote-address list-id <list_id>
> end
> configure
> context <context_name>
> radius accounting ip remote-address collection
> end
> Notes:

> • | Save your configuration as described in Verifying and Saving Your Configuration chapter.

> Appendix S
> Subscriber Overcharging Protection
> Subscriber Overcharging Protection is a proprietary, enhanced feature that prevents subscribers in UMTS networks from being overcharged when a loss of radio coverage (LORC) occurs. This chapter indicates how the feature is implemented on various systems and provides feature configuration procedures. Products supporting subscriber overcharging protection include the Cisco ASR 5000 Gateway GPRS Support Node (GGSN) and the Cisco ASR 5000 Serving GPRS Support Node (SGSN).
> The individual product administration guides provide examples and procedures for configuration of basic services. Before using the procedures in this chapter, we recommend 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 guide.
> Important: The feature described in this chapter is an enhanced feature and implementation may require a feature license. Refer to your product’s administration guide or ask your Cisco account representative for more information about feature licensing.
> This chapter covers the following topics in support of the Subscriber Overcharging Protection feature:

> • | Feature Overview

> • | Overcharging Protection - GGSN Configuration

> • | Overcharging Protection - SGSN Configuration

> Feature Overview
> Subscriber Overcharging Protection enables the SGSN to avoid overcharging the subscriber if/when a loss of radio coverage (LORC) occurs.
> When a mobile is streaming or downloading files from external sources (for example, via a background or interactive traffic class) and the mobile goes out of radio coverage, the GGSN is unaware of such loss of connectivity and continues to forward the downlink packets to the SGSN.
> Previously, upon loss of radio coverage (LORC), the SGSN did not perform the UPC procedure to set QoS to 0kbps, as it does when the traffic class is either streaming or conversational. Therefore, when the SGSN did a Paging Request, if the mobile did not respond the SGSN would simply drop the packets without notifying the GGSN; the G-CDR would have increased counts but the S-CDR would not, causing overcharges when operators charged the subscribers based on the G-CDR.
> Now operators can accommodate this situation, they can configure the SGSN to set QoS to 0kbps, or to a negotiated value, upon detecting the loss of radio coverage. The overcharging protection feature relies upon the SGSN adding a proprietary private extension to GTP LORC Intimation IE to messages. This LORC Intimation IE is included in UPCQ, DPCQ, DPCR, and SGSN Context Response GTP messages. One of the functions of these messages is to notify the GGSN to prevent overcharging.
> The GGSN becomes aware of the LORC status by recognizing the message from the SGSN and discards the downlink packets if LORC status indicates loss of radio coverage or stops discarding downlink packets if LORC status indicates gain of radio coverage for the UE.
> The following table summarizes the SGSN's actions when radio coverage is lost or regained and LORC overcharging protection is enabled.
> LORC Conditions and Overcharging Protection

> Condition | Triggered by | SGSN Action | LORC Intimation IE - private extension payload
> Loss of radio coverage (LORC) | RNC sends Iu release request with cause code matching configured value | Send UPCQ to GGSN Start counting unsent packets/bytes Stop forwarding packets in downlink direction | No payload
> Mobile regains coverage in same SGSN area | MS/SGSN | Send UPCQ to GGSN Stop counting unsent packets/bytes Stop discarding downlink packets | New loss-of-radio-coverage state and unsent packet/byte counts
> Mobile regains coverage in different SGSN area | MS/SGSN | Send SGSN Context Response message to new SGSN Stop counting unsent packets/bytes | Unsent packet/byte counts
> PDP deactivated during LORC | MS/SGSN | Send DPCQ to GGSN Stop counting unsent packets/bytes | Unsent packet/byte counts
> PDP deactivated during LORC | GGSN | Send DPCR to GGSN Stop counting unsent packets/bytes | Unsent packet/byte counts

> ‌
> Overcharging Protection - GGSN Configuration
> This section provides a high-level series of steps and the associated configuration examples for configuring the GGSN to support subscriber overcharging protection.
> Important: This section provides the minimum instruction set to configure the GGSN to avoid the overcharging due to loss of radio coverage in UMTS network. For this feature to be operational, you must also implement the configuration indicated in the section Overcharging Protection - SGSN Configuration also in this chapter. Commands that configure additional function for this feature are provided in the Cisco ASR 5000 Series Command Line Interface Reference.
> These instructions assume that you have already configured the system-level configuration as described in Cisco ASR 5000 Series System Administration Guide and the Cisco ASR 5000 Gateway GPRS Support Node Administration Guide.
> To configure the system to support overcharging protection on LORC in the GGSN service:

> Step 1 | Configure the GTP-C private extension in a GGSN service by applying the example configurations presented in the GTP-C Private Extension Configuration section below.

> Step 2 | Save the changes to a configuration .cfg file by applying the example configuration found in Saving the Configuration section of the Verifying and Saving Your Configuration chapter in this book.

> Step 3 | Verify configuration of overcharging protection on LORC related parameters by applying the commands provided in the Verifying Your GGSN Configuration section in this chapter.

> GTP-C Private Extension Configuration
> This section provides the configuration example to configure the GTP-C private extensions for GGSN service:
> configure
> context <vpn_context_name>
> ggsn-service <ggsn_svc_name>
> gtpc private-extension loss-of-radio-coverage
> end
> Notes:

> • | <vpn_context_name> is the name of the system context where specific GGSN service is configured. For more information, refer Cisco ASR 5000 Gateway GPRS Support Node Administration Guide.

> • | <ggsn_svc_name> is name of the GGSN service where you want to enable the overcharging protection for subscribers due to LORC.

> Verifying Your GGSN Configuration
> This section explains how to display and review the configurations after saving them in a .cfg file (as described in the Verifying and Saving Your Configuration chapter in this book) and how to retrieve errors and warnings within an active configuration for a service.
> Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
> These instructions are used to verify the overcharging protection support configuration.

> • | Verify that your overcharging support is configured properly by entering the following command in Exec Mode:

> show ggsn-service name ggsn_svc_name
> The output of this command displays the configuration for overcharging protection configured in the GGSN service ggsn_svc_name.
> Service name: ggsn_svc1
> Context: service
> Accounting Context Name:service
> Bind: Done
> Local IP Address: 192.169.1.1 Local IP Port: 2123
> ...
> ...
> GTP Private Extensions:
> Preservation Mode
> LORC State

> • | Verify that GTP-C private extension is configured properly for GGSN subscribers by entering the following command in Exec Mode:

> show subscribers ggsn-only full
> The output of this command displays the LORC state information and number of out packets dropped due to LORC.
> Overcharging Protection - SGSN Configuration
> This section provides a high-level series of steps and the associated configuration examples for configuring the SGSN to support subscriber overcharging protection.
> Important: This section provides a minimum instruction set to configure the SGSN to implement this feature. For this feature to be operational, you must also implement the configuration indicated in the section Overcharging Protection - GGSN Configuration also in this chapter.
> Command details can be found in the Cisco ASR 5000 Series Command Line Interface Reference.
> These instructions assume that you have already completed:

> • | the system-level configuration as described in the Cisco ASR 5000 Series System Administration Guide,

> • | the SGSN service configuration as described in the Cisco ASR 5000 Serving GPRS Support Node Administration Guide, and

> • | the configuration of an APN profile as described in the Operator Policy chapter in this guide.

> To configure the SGSN to support subscriber overcharging protection:

> Step 1 | Configure the private extension IE with LORC in an APN profile by applying the example configurations presented in the Private Extension IE Configuration section.

> Important: An APN profile is a component of the Operator Policy feature implementation. To implement this feature, an APN profile must be created and associated with an operator policy. For details, refer to the Operator Policy chapter in this book.

> Step 2 | Configure the RANAP cause that should trigger this UPCQ message by applying the example configurations presented in the RANAP Cause Trigger Configuration section.

> Step 3 | Save the changes to a configuration .cfg file by applying the example configuration found in the Saving the Configuration section of the Verifying and Saving Your Configuration chapter in this book.

> Step 4 | Verify the SGSN portion of the configuration for overcharging protection on LORC related parameters by applying the commands provided in the Verifying the Feature Configuration section.

> Private Extension IE Configuration
> This section provides the configuration example to enable adding the private extension IE that will be included in the messages sent by the SGSN when a loss of radio coverage occurs in the UMTS network:
> configure
> apn-profile <apn_profile_name>
> gtp private-extension loss-of-radio-coverage send-to-ggsn
> end
> Note:

> • | <apn_profile_name> is the name of a previously configured APN profile. For more information, refer to the Operator Policy chapter, also in this book.

> RANAP Cause Trigger Configuration
> This section provides the configuration example to enable the RANAP cause trigger and define the trigger message value:
> configure
> context <context_name>
> iups-service <iups_service_name>
> loss-of-radio-coverage ranap-cause <cause> end
> Note:

> • | <context_name> is the name of the previously configured context in which the IuPS service has been configured.

> • | <cause> is an integer from 1 to 512 (the range of reasons is a part of the set defined by 3GPP TS 25.413) that allows configuration of the RANAP Iu release cause code to be included in messages. Default is 46 (MS/UE radio connection lost).

> Verifying the Feature Configuration
> This section explains how to display the configurations after saving them in a .cfg file as described in the Verifying and Saving Your Configuration chapter elsewhere in this guide.
> Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
> These instructions are used to verify the overcharging protection support configuration.

> Step 1 | Verify that your overcharging support is configured properly by entering the following command in Exec Mode:

> show apn-profile full name apn_profile_name
> The output of this command displays the entire configuration for the APN profile configuration. Only the portion related to overcharging protection configuration in the SGSN is displayed below. Note that the profile name is an example:
> APN Profile name: : apnprofile1
> Resolution Priority: : dns-fallback
> ...
> ...
> Sending Private Extension Loss of Radio Coverage IE
> To GGSN : Enabled
> To SGSN : Enabled

> Step 2 | Verify the RANAP Iu release cause configuration by entering the following command in the Exec Mode:

> show iups-service name <iups_service_name>
> The output of this command displays the entire configuration for the IuPS service configuration. Only the portion related to overcharging protection configuration (at the end of the display) is displayed below. Note that the IuPS service name is an example:
> Service name: : iups1
> Service-ID: : 1
> ...
> ...
> Loss of Radio Coverage
> Detection Cause in Iu Release: 46
> Appendix T
> Traffic Policing and Shaping
> This chapter describes the support of per subscriber Traffic Policing and Shaping feature on ST16 and Cisco® ASR 5000 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.
> 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 the configuration as described in the Verifying and Saving Your Configuration chapter.

> 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 the configuration as described in the Verifying and Saving Your Configuration chapter.

> 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 the configuration as described in the Verifying and Saving Your Configuration chapter.

> 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 the configuration as described in the Verifying and Saving Your Configuration chapter.

> 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.

> ‌

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