Packet Data Interworking Function (PDIF) | Tunnel Terminating Gateway (TTG) | ASR 5000 Small Cell Gateway | Packet Data Gateway (PDG) | User manual | Cisco ASR 5000 Series Enhanced Feature Configuration Guide
Add to my manuals580 Pages
advertisement
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY
OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.
The following information is for FCC compliance of Class B devices: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If the equipment causes interference to radio or television reception, which can be determined by turning the equipment off and on, users are encouraged to try to correct the interference by using one or more of the following measures:
Reorient or relocate the receiving antenna.
Increase the separation between the equipment and receiver.
Connect the equipment into an outlet on a circuit different from that to which the receiver is connected.
Consult the dealer or an experienced radio/TV technician for help.
Modifications to this product not authorized by Cisco could void the FCC approval and negate your authority to operate the product.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB‘s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED ―AS IS‖ WITH ALL
FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE
PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR
ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any u se of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide
© 2010 Cisco Systems, Inc. and/or its affiliated entities. All rights reserved.
C
ONTENTS
Command Line Interface Overview ................................................................. 21
Verifying and Saving Your Configuration ...................................................... 51
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Contents
CoA, RADIUS DM, and Session Redirection (Hotlining) ............................... 91
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Contents ▀
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Contents
HA Redundancy for Dynamic Home Agent Assignment ............................ 179
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Contents ▀
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Contents
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Contents ▀
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Contents
MSID and PCF Zone Based Call Redirection ............................................... 367
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Contents ▀
Multimedia Broadcast and Multicast Service .............................................. 371
MultiProtocol Label Switching (MPLS) Support .......................................... 391
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Contents
Policy-Based Management and EV-DO Rev A ............................................. 411
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Contents ▀
Rejection/Redirection of HA Sessions on Network Failures ..................... 493
Remote Address-based RADIUS Accounting .............................................. 501
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Contents
Subscriber Overcharging Protection ............................................................ 535
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Contents ▀
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
About this Guide
This document pertains to features and functionality that run on and/or that are related to the Cisco® ASR 5000 Chassis, formerly the Starent Networks ST40.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
About this Guide
▀ Conventions Used
Conventions Used
Icon
The following tables describe the conventions used throughout this documentation.
Notice Type
Information Note
Description
Provides information about important features or instructions.
Caution Alerts you of potential damage to a program, device, or system.
Warning Alerts you of potential personal injury or fatality. May also alert you of potential electrical hazards.
Electro-Static Discharge
(ESD)
Typeface Conventions
Text represented as a
Text represented as
Text represented as a
Text represented as menu or submenu names
Alerts you to take proper grounding precautions before handling a product.
Description
This typeface represents displays that appear on your terminal screen, for example:
This typeface represents commands that you enter, for example:
This document always gives the full form of a command in lowercase letters. Commands are not case sensitive.
This typeface represents a variable that is part of a command, for example: slot_number is a variable representing the desired chassis slot number.
This typeface represents menus and sub-menus that you access within a software application, for example:
Click the File menu, then click New
Command Syntax
Conventions
{ or
}
Description
Required keywords and variables are surrounded by grouped brackets.
Required keywords and variables are those components that are required to be entered as part of the command syntax.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
About this Guide
Conventions Used ▀
Command Syntax
Conventions
[ or
]
|
Description
Optional keywords or variables, or those that a user may or may not choose to use, are surrounded by square brackets.
With some commands there may be a group of variables from which the user chooses one. These are called alternative variables and are documented by separating each variable with a vertical bar (also known as a pipe filter).
Pipe filters can be used in conjunction with required or optional keywords or variables. For example:
OR
[ | ]
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
About this Guide
▀ Contacting Customer Support
Contacting Customer Support
Use the information in this section to contact customer support.
For New Customers: Refer to the support area of http://www.cisco.com for up-to-date product documentation or to submit a service request. A valid username and password is required to this site. Please contact your local sales or service representative for additional information.
For Existing Customers with support contracts through Starent Networks: Refer to the support area of https://support.starentnetworks.com/ for up-to-date product documentation or to submit a service request. A valid username and password is required to this site. Please contact your local sales or service representative for additional information.
Important:
For warranty and repair information, please be sure to include the Return Material Authorization
(RMA) tracking number on the outside of the package.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 1
Command Line Interface Overview
This chapter describes the numerous features in the command line interface (CLI). Included is information about the architecture of the CLI, its command modes and user privileges, how to obtain help within the CLI, and other key items.
The operating system provides the software that controls the overall system logic, control processes, and the CLI. The
CLI is a multi-threaded user interface that allows you to manipulate, configure, control, and query the hardware and software components that make up the system and its hosted services. In addition, the CLI can host multiple instances of management and service configuration sessions. This allows multiple users to simultaneously access and manage multiple hosted services.
This section provides the following information about the CLI:
Understanding the CLI Command Prompt
Entering and Viewing CLI Commands
Exiting the CLI and CLI Command Modes
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Command Line Interface Overview
▀ CLI Structure
CLI Structure
CLI commands are strings of commands or keywords and user-specified arguments that set or modify specific parameters of the system. Commands are grouped by function and the various command modes with which they are associated.
The structure of the CLI is hierarchical. All users begin at a specific entry point into the system, called the Exec
(Execute) Mode, and then navigate through the CLI according to their defined user privileges (access level) by using other command modes.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
CLI Command Modes ▀
CLI Command Modes
There are two primary CLI command modes:
Exec (Execute) Mode: The Exec mode is the lowest level in the CLI. The Exec mode is where you execute basic commands such as show, and ping. When you log into the CLI, you are placed in this mode by default.
Config (Configuration) Mode: The Config mode is accessible only by users with administrator and security administrator privileges. If you are an administrative user, in this mode you can add and configure contexts and access the configuration sub-modes to configure protocols, interfaces, ports, services, subscribers, and other service-related items.
As explained above, the entry point into the CLI is called Exec Mode. In the initial CLI login, all users are placed into the default local context, which is the CLI‘s default management context. From this context, administrative users can access the Config Mode and define multiple service contexts.
Refer to the mode entry-path diagrams at the beginning of each mode chapter in the Command Line Interface Reference.
Important:
The commands or keywords/variables that are available are dependent on platform type, product version, and installed license(s).
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Command Line Interface Overview
▀ CLI Administrative Users
CLI Administrative Users
This section contains information on the administrative user types and privileges supported by the system.
Administrative User Types
There are two types of administrative users supported by the system:
Context-level administrative users: This user type is configured at the context-level and relies on the AAA subsystems for validating usernames and passwords during login. This is true for both administrative user accounts configured locally through a configuration file or on an external RADIUS server. Passwords for these user types are assigned once and are accessible in the configuration file.
Local-users: This user type provides support for ANSI T1.276-2003 password security protection. Local-user account information, such as passwords, password history, and lockout states, is maintained in non-volatile memory on the CompactFlash module and in the Shared Configuration Task (SCT). This information is maintained in a separate file, not in configuration files used by the system. As such, the configured local-user accounts are not visible with the rest of the system configuration.
Local-user and context-level administrative accounts can be used in parallel. However, a mechanism is provided to deactivate context-level administrative user accounts thereby providing access only to local-user accounts.
Authenticating Administrative Users with RADIUS
To authorize users via RADIUS, you must include two RADIUS attributes in the RADIUS Access-Accept message:
RFC 2865 standard Service-Type
Starent Vendor-Specific Attribute (VSA) SN1-Admin-Permission.
The default permission is none (0), meaning that service is refused even if properly authenticated via RADIUS.
RADIUS Mapping System
RADIUS server configuration depends on the type of server used and the instructions distributed by the server manufacturer. The following table shows the attribute/value mapping system that is constant, regardless of server manufacturer or model:
Table 1. RADIUS Attribute/Value Mapping System
Attribute Value
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
CLI Administrative Users ▀
Attribute
Login (Operator)
Framed
Callback_Login
Callback_Framed
Outbound
Administrative (Administrator) 6
NAS_Prompt 7
Authenticate_Only 8
Callback_NAS_Prompt
Call_Check
Callback_Administrative
Voice
9
10
11
12
3
4
5
Value
1
2
Fax
Modem_Relay
IAPP_Register
IAPP_AP_Check
Authorize_Only
Inspector
Security_Admin
13
14
15
16
17
19650516
19660618
RADIUS Privileges
There are four RADIUS privilege roles. The following table shows the relationship between the privilege roles in the
CLI configuration and RADIUS Service-Type.
Table 2. CLI Privilege Roles and RADIUS Service Types
CLI Configuration Parameter RADIUS Service Type
administrator config_administrator operator inspector
Security_Admin (19660618)
Administrative (6)
NAS_Prompt (7)
Inspector (19650516)
Show Admin Type
admin cfgadm oper inspect
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Command Line Interface Overview
▀ CLI Administrative Users
Administrative User Privileges
Regardless of the administrative user type, the system supports four user privilege levels:
Inspector: Inspectors are limited to a small number of read-only Exec Mode commands. The bulk of these are show commands for viewing a variety of statistics and conditions. The Inspector cannot execute show configuration commands and does not have the privilege to enter the Config Mode.
Operator: Operators have read-only privileges to a larger subset of the Exec Mode commands. They can execute all commands that are part of the inspector mode, plus some system monitoring, statistic, and fault management functions. Operators do not have the ability to enter the Config Mode.
Administrator: Administrators have read-write privileges and can execute any command in the CLI except for a few security-related commands that can only be configured by Security Administrators. Administrators can configure or modify system settings and can execute all system commands, including those available to the
Operators and Inspectors.
Security Administrator: Security Administrators have read-write privileges and can execute all CLI commands, including those available to Administrators, Operators, and Inspectors.
The following figure represents how user privileges are defined in the CLI configuration modes.
Figure 1. User Privileges
Security Administrators
Administrators
Exec Mode Config Mode
Operators
Inspectors
Though the privilege levels are the same regardless of user type, the corresponding user type names differ slightly. The following table displays the privilege level to administrative user type mappings:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
CLI Administrative Users ▀
Table 3. User Privilege to User Type Mapping
User Type as Defined by T1.276-2003 Local-User Level User Context-Level User
System Security Administrator Security Administrator Administrator
Application Security Administrator Security Administrator Administrator
System Administrator Administrator Config-Administrator
Application Administrator
Application User/Operator
Administrator
Operator
Config-Administrator
Operator not applicable Inspector Inspector
Configure context-level administrative users in the Context Configuration Mode with the
, , and commands.
,
Configure local-user administrative users at the Global Configuration Mode with the command.
You can further refine administrative levels to include access to certain features with the following feature-use administrative user options:
Lawful Intercept (LI) Administrative User: To configure and manage LI-related issues, configure at least one administrative user account with LI functionality privileges.
Important:
This privilege is available only for context-level administrative users. In addition, to ensure security in accordance with the standards, LI administrative users must access the system through the Secure Shell Protocol
(SSH).
Enhanced Charging Service (ECS) Administrative User: To log in and execute ECS-related commands, configure at least one administrative user account with ECS functionality privileges.
All system users can be configured within any context. However, it is recommended that you configure users in the system‘s management context called local. Refer to sections later in this chapter for additional information about contexts.
Allowed Commands per User Type
With the exception of security administrators, all other management users are limited to a subset of the entire command list as described in the Command Line Interface Reference. This section defines the commands allowed for each management user type. As stated previously, inspectors and operators are limited to only a subset of the Exec Mode commands.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Command Line Interface Overview
▀ CLI Administrative Users
Inspector Mode Commands
In the Exec mode, system inspectors can access the following commands: abort autoconfirm context crypto-group default terminal exit help logs checkpoint monitor subscriber no logging active no logging trace no reveal disabled commands no timestamps no autoconfirm ping reveal disabled commands show (except show snmp communities and show snmp transports) sleep start crypto security-association terminal length terminal width timestamps traceroute
Operator Mode Commands
In the Exec mode, system operators can access all inspector mode commands plus the following commands: aaa test alarm cutoff bulkstats force card clear (a subset of all clear command variations)
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
CLI Administrative Users ▀
debug dhcp test gtpc test gtpp interim gtpp test gtpu test gtpv0 test host logging active logging filter logging trace newcall no card no debug no newcall policy port ppp echo-test radius interim accounting radius test rlogin show access-group show access-list show access-flow show access statistics show configuration show snmp transports ssh telnet test alarm
Administrator Mode Commands
Administrators can access all system commands except:
Context Config Mode config-administrator operator
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ CLI Administrative Users
inspector administrator
Global Config Mode snmp community snmp user local-user suspend local-user
Exec Mode show snmp communities clear (all clear command variations) show local-user password change local-user
Security Administrator Mode Commands
Security administrators can access all system commands.
Command Line Interface Overview
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
CLI Contexts ▀
CLI Contexts
A context is a group of configuration parameters that apply to the ports, interfaces, and protocols supported by the system. You can configure multiple contexts on the system, each of which resides as a separate, logically independent instance on the same physical device. The CLI can host multiple contexts within a single physical device. This allows wireless service providers to use the same system to support:
Different levels of service
Multiple wholesale or enterprise customers or customer groups
Different classes of customers based on defined Class of Service (CoS) parameters
IP address pools across multiple contexts, thus saving IP address allocation
Enhanced security
Each defined context operates independently from any other context(s) in the system. Each context contains its own CLI instance, IP routing tables, access filters, compression methods, and other configured data.
By default, a single system-wide context called local, is used exclusively for the management of the system. Think of the local context as the root directory of the system, since you can define and access all other contexts from this point.
You cannot delete the local context. From this location in the CLI, you can:
Create and configure other service contexts that contain different service configurations
Configure system-wide services such as CORBA and SNMP management interfaces, physical management ports, system messages, and others
Important:
The system requires that you define at least one context in addition to the Local context. This isolates system management functions from application or service functions.
Administrative users add contexts through the Global Configuration Mode. A substantial advantage of configuring numerous service contexts is that it allows operators to broadly distribute different subscribers across the system. This greatly enhances the performance of the system and minimizes the loss of sessions should a failure occur.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Command Line Interface Overview
▀ Understanding the CLI Command Prompt
Understanding the CLI Command Prompt
The CLI provides an intuitive command prompt that informs you of:
Exactly where you are located within the CLI
The command mode you are using
Your user privilege level.
The following figure shows the various components of the command prompt.
Figure 2. CLI Command Prompt
Context Pointer:
Shows the context in which the user is currently working.
Command Mode:
Shows the specific command mode or sub-mode in which the user is currently working.
[local]
host_name
(config)
#
System Host Name:
Shows the currently configured host name.
User Privilege Indicator:
Indicates the user mode.
# indicates administrator / config-administrator privileges
> indicates inspector / operator privileges only
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
CLI Command Syntax ▀
CLI Command Syntax
This section describes the components of the CLI command syntax that you should be familiar with prior to using the
CLI. These include:
Commands: Specific words that precede, or initiate, a specific function.
Keywords: Specific words that follow a command to more clearly dictate the command‘s function.
Variables: Alpha, numeric, or alphanumeric values that are user-supplied as part of the command syntax.
Sometimes referred to as arguments, these terms further specify the command function.
Repetitive keywords (+): Specific keyword, that when followed by a plus (+) sign, indicates that more than one of the keywords can be entered within a single command.
Example
In the following example, is the command variable for the keyword:
is a variable representing a particular slot (1 through 48).
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Command Line Interface Overview
▀ Entering and Viewing CLI Commands
Entering and Viewing CLI Commands
This section describes various methods for entering commands into the CLI.
Typing each command keyword, argument, and variable can be time-consuming and increase your chance of making mistakes. The CLI therefore, supports the following features to assist you in entering commands quickly and more accurately. Other features allow you to view the display and review previously entered commands.
Entering Partial CLI Commands
In all of the modes, the CLI recognizes partially-typed commands and keywords, as long as you enter enough characters for the command to be unambiguously recognized by the system. If you do not enter enough characters for the system to recognize a unique command or keyword, it returns a message listing all possible matches for the partial entry.
Example
If you enter the partial command and press <Enter>, you enter the Global Configuration Mode. If you were to enter only , the system would respond with the message:
CLI Command Auto-completion
Use the command auto-completion feature to automatically complete unique CLI commands. Press the <Tab> key after entering enough characters to enable this feature.
Example
If you do not enter enough characters to allow the CLI to determine the appropriate command to use, the CLI displays all commands that match the characters you entered with auto-completion:
Example
Enter a question mark (?) after a partial command to display all of the possible matching commands, and their related help text.
Example
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
Entering and Viewing CLI Commands ▀
Using CLI Auto-Pagination
When you enter commands whose expected results exceed the terminal window‘s vertical display, the auto-pagination function pauses the display each time the terminal window reaches its display limit. Press any key to display the next screen of results.
By default, auto-pagination functionality is disabled. To enable auto-pagination, type the pipe command:
Important:
When auto-pagination is enabled, if a command‘s output exceeds the terminal window‘s vertical display parameters, you can exit by entering ―q‖. This returns you to the CLI prompt.
Using CLI Autoconfirmation
By default, the system is configured to prompt all administrative users with a confirmation prior to executing certain commands. This functionality serves two purposes:
Helps ensure that you do not execute an unwanted configuration change.
Example
Saving a configuration:
Indicates potential misspellings of names during configuration. The first time you configure an element name
(context, subscribers, services, etc.), the prompt is displayed. The prompt is not displayed for subsequent entries of the name. Therefore, if you see the confirmation prompt after entering the name of a previously configured element, it is likely that you misspelled the name.
Examples
You create context named ―newcontext‖:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Command Line Interface Overview
▀ Entering and Viewing CLI Commands
You revisit the context named ―newcontext‖:
On another occasion, you misspell the context named ―newcontext‖:
After aborting the above action, you can again revisit ―newcontext‖:
You can control CLI autoconfirmation at the following levels:
Specific administrative user sessions: To enable or disable autoconfirmation, use the [no] autoconfirm commands while in the Exec mode.
All Future Sessions: To disable or re-enable autoconfirmation for all future sessions, use the [no]autoconfirm commands while in the Global Config mode.
For specific commands: Disable autoconfirmation for various commands that support the -noconfirm keyword, such as the save configuration or card reboot commands.
Regulating the Command Output
For many CLI commands, you can use and/or keywords to regulate or control the command‘s output.
Use the | grep keyword to filter through a command‘s output for certain expressions or patterns. Only those portions of the output that contain or exclude the pattern are displayed. The | grep has the following syntax:
Table 4. grep Keywords
Alternative
Keyword
-i
Description
-v
--ignore-case
Specifies the filtering of the command‘s output for a particular expression while ignoring case. Lower case matches the same as upper case.
Specifies the filtering of the command‘s output for everything excluding a particular expression.
The long form of the -i option.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
Entering and Viewing CLI Commands ▀
Alternative
Keyword
Description
--invert-match
The long form of the -v option.
expression Specifies the character pattern to find in the command‘s output.
Use the keyword to pause the terminal each time the terminal window reaches its display limit. Press any key to display the next screen. The function of this keyword is identical to the command, except that you must manually enter it on a command-by-command basis.
Viewing Command History
To view a history of all commands line by line, simply scroll up or down with the <up arrow> and <down arrow> cursor keys on the keyboard.
The operating system supports EMACS-style text editing commands. This standard UNIX text editor format allows you to use keyboard-based shortcut keys for maneuvering around the CLI. The following table lists these available shortcut keys.
Table 5. EMACS Shortcut Keystrokes
Shortcut Keys Description
<Ctrl + p> and <up arrow> Recalls previous command in the command history
<Ctrl + n> and <down arrow> Recalls next command in the command history
<Ctrl + f> and <right arrow> Moves cursor forward by one character in command line
<Ctrl + b> and <left arrow> Moves cursor backward by one character in command line
<Esc> + <f>
<Esc> + <b>
<Ctrl> + <a>
<Ctrl> + <e>
<Ctrl> + <k>
<Ctrl> + <u>
<Ctrl> + <d>
Moves cursor forward by one word in command line
Moves cursor to the beginning of the command line
Moves cursor to the end of the command line
Moves cursor backward by one word in command line
Deletes a single character in the current command line
Deletes the current command line from the insertion point to the end of the line
Deletes the current command line from the insertion point to the beginning of the line
<Esc> + <d>
<Ctrl> + <c>
<Ctrl> + <l>
<Ctrl> + <t>
Deletes a word in the current command line
Quits editing the current line
Refreshes the display
Transposes (or switches) the two characters surrounding the insertion point
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Command Line Interface Overview
▀ Obtaining CLI Help
Obtaining CLI Help
The CLI provides context-sensitive help for every command token and keyword available to you. To obtain, use one of these methods:
Command Help: Command help provides assistance for a specific command. Type a question mark (?) at the end of the specific command to accesses help.
Example
Keyword Help: Keyword help provides assistance in determining the next keyword, argument, or option to use in the command syntax. Enter the command keyword, enter a space, and then type a question mark (?).
Example
Variable Help: Variable help provides the correct format, value, or information type for each variable that is part of the command syntax. For commands with variables, enter the command keyword, enter a space, and then type a question mark (?).
Example
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
Exiting the CLI and CLI Command Modes ▀
Exiting the CLI and CLI Command Modes
A CLI session is defined as the successful login into the CLI. When you establish a CLI session, you are placed into the system‘s Exec Mode. Depending upon your user privilege level, you can:
Use the local context to perform system management functions
Move to an assigned context and work in Exec Mode
Move to an assigned context as an administrative user and work in Global Configuration Mode or other configuration sub-mode
This section addresses how to properly exit the various modes and the CLI.
Exiting Configuration Sub-modes
To exit a configuration sub-mode and return to the next highest configuration sub-mode or Global Configuration Mode, type the exit command at the system prompt.
Example
Important:
The CLI supports implicit mode-exits when using configuration files. Therefore, configuration files do not have to contain all of the required exit commands for you to leave various sub-config modes.
To exit a sub-mode and return to the Exec Mode, enter the
Example
command.
Exiting Global Configuration Mode
To exit Global Configuration Mode, and return to the Exec Mode prompt, type the command at the prompt.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Command Line Interface Overview
▀ Exiting the CLI and CLI Command Modes
Ending a CLI Session
To end a CLI session and exit the CLI, type the command at the local Exec Mode prompt.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
Accessing the CLI ▀
Accessing the CLI
Access the CLI through the following methods:
Local login through a Console port using the RS-232 serial cable supplied with the card
Remote login using Telnet and Secure Shell (SSH) access to the CLI through any IP interface on the system.
Important:
Even though you can access the CLI remotely through any available IP interface, it is recommended that management traffic be isolated from network traffic by using one of the SPIO card management interfaces. You can use remote login methods only after the system has been configured to support the various access methods.
Important:
Multiple CLI sessions are supported, but the number of sessions is dependent on the amount of available memory. The Resource Manager reserves enough resources so that as a minimum, 15 CLI sessions are assured. One of the CLI sessions is always reserved for use exclusively by a CLI session on an SPIO console interface.
Additional CLI sessions beyond the pre-reserved set are permitted if sufficient SMC resources are available. If the
Resource Manager is unable to reserve additional resources, you are prompted whether to allow the system to create the new CLI session, even without the reserved resources.
Accessing the CLI Locally Using the Console Port
This section provides instructions for accessing the CLI locally through the console port.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Command Line Interface Overview
▀ Accessing the CLI
Figure 3. Console Port
R un
/F ai l
Link
A ct iv e
S ta nd by
1
Activity
Link
SFP
2
Activity
Ethernet
1
2
Console Port
Console
CO Alarms
Switch
Processor
I/O
Access the console port with the RJ-45-to-DB-9 serial (EIA-232) cable that is shipped with the Switch Processor
Input/Output (SPIO)Connect to a workstation that has a communications application that accesses the workstation‘s serial port, such as Minicom for Linux or HyperTerminal® for MicroSoft Windows®.
Each of the two SPIO Line Cards installed in the system provides a console port for accessing the CLI. The CLI is only accessible from the SPIO that is active—typically the SPIO installed in chassis slot 24.
For normal operation, the SMC in chassis slot 8 serves as the active processing card for the system. The SPIO that corresponds to this SMC is installed in slot 24. For the processing card in chassis slot 9, the corresponding SPIO is installed in slot 25.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Command Line Interface Overview
Accessing the CLI ▀
Important:
In the event of aSMC switchover, in which processes are switched from the processing card in slot 8 that was previously active to the redundant processing card in slot 9, the SPIO in slot 24 continues to serve as the active
SPIO. Therefore, the console port is still accessible through that SPIO.
Follow the instructions below to connect to the console port.
1. Connect the RJ-45 end of the cable to the port labeled Console.
2. Connect the DB-9 end of the cable to the serial port on the workstation.
3. Configure the communications application to support the following:
Parameter Setting
Baud Rate 115,200 bps
Data Bits 8
Parity
Stop Bits
None
1
Flow Control None
Important:
To change the configuration defined in the table above, modify the command located in the Global configuration mode.
4. At the terminal window, press Enter.
5. If no configuration file is present (that is, this is the first time the system is powered), the CLI prompts you as to whether or not you want to use the Quick Setup Wizard. If the system was configured previously, you are prompted to enter a username and password.
Remotely Accessing the CLI
To remotely access the CLI through a defined management interface, you must first configure the remote access method
(such as Telnet or SSH).
You can find examples of how to configure this in the Getting Started chapter.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Chapter 2
Enhanced Feature Overview
This reference describes the procedures to enable and configure the enhanced services on your system for core network service subscribers in a wireless carrier network. Procedures to configure and administer core network services are described in detail in the respective product administration guide.
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.
Important:
All features described in this book are license enabled, unless otherwise shown in the table below. If you have not previously purchased a license bundle(s) or a standalone license for any licenseenabled enhanced feature, contact your sales representative for more information.
This chapter provides information on required licenses and network services supported by each feature.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Enhanced Feature Overview
▀ Supported Products and Licensing
Supported Products and Licensing
The following table provides the list of supported products and license name of enhanced features described in this reference.
Table 6. Supported Products and Licenses
Enhanced Feature Name
Always-on
Platform License Name
ST40 3GPP2 Always-On RP Extensions
BCMCS
CoA, RADIUS DM, and Session Redirection (Hotlining)
Content Service Steering
Content Filtering ICAP Interface Support
Direct Tunnel
Dynamic QoS Renegotiation (Traffic Class-based QoS and
Network Controlled QoS)
GRE Protocol Interface Support
Gx Interface Support
HA Proxy DNS Intercept
HA Redundancy for Dynamic Home Agent Assignment
Intelligent Traffic Control
Interchassis Session Recovery
Product
PDSN
HA
PDSN
PDSN
GGSN
IPSG
ASN GW
HA
PDIF
PDSN
GGSN
HA
GGSN
SGSN
GGSN
GGSN
GGSN
IPSG
HSGW
P-GW
HA
HA
ASN GW
PDSN
HA
HSGW
P-GW
S-GW
GGSN
SCM
HA
ST40
ST40
ST40
ST40
ST40
ST40
ST40
ST40
ST40
ST40
ST40
ST40
Broadcast & Multicast Services
Dynamic Radius extensions (CoA and PoD)
External Service Steering
Content Filtering ICAP Interface
SGSN Software License
GGSN Dynamic QoS
Renegotiation
GRE Interface Tunneling
Dynamic Policy Interface
HA DNS Intercept Proxy
--
Intelligent Traffic control
Inter-Chassis Session Recovery
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Enhanced Feature Overview
Enhanced Feature Name
IP Access Control Lists
IP Header Compression
IP Pool Sharing Protocol
IP Security
Lawful Intercept
L2TP Access Concentrator
L2TP Network Server
MIP NAT Traversal
OL-22983-01
Supported Products and Licensing ▀
Product
ASN GW
GGSN
HA
HSGW
IPSG
MME
PDIF
PDSN
P-GW
SCM
S-GW
SGSN
HSGW
PDSN
PDSN
GGSN
ASN GW
GGSN
HA
HSGW
IPSG
MME
PDIF
PDSN
P-GW
SCM
S-GW
PDSN
GGSN
ASN GW
HA
MME
PDIF
LNS
SGSN
PDSN
GGSN
IPSG
ASN GW
PDSN/LNS
GGSN/LNS
HA
Platform License Name
ST40 --
ST40
ST40
ST40
ST40
ST40
ST40
ST40
Robust Header Compression
--
IPSec
Lawful Intercept/
Enhanced Lawful Intercept
L2TP LAC
L2TP LNS
MIP NAT Traversal
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Enhanced Feature Overview
▀ Supported Products and Licensing
Enhanced Feature Name
Multi Protocol Label Switching (MPLS)
Multimedia Broadcast and Multicast Service
MSID and PCF Zone Based Call Redirection
Policy-based Management and EV-DO Rev A
Policy Forwarding
Pre-paid Billing
Proxy-Mobile IP
Mobile IP Registration Revocation
Rejection/Redirection of HA Sessions on Network Failures
Remote Address-based RADIUS Accounting
Product
ASN
GW/FA
GGSN/FA
HA
HSGW
IPSG
PDIF
PDSN/FA
P-GW
SCM
S-GW
GGSN
GGSN
Platform
ST40
ST40
ST40
ST40 HA
PDSN
GGSN
IPSG
ASN GW
SCM
HA
PDSN
GGSN
IPSG
ASN GW
PDIF
HA
PDSN/FA
PDSN
GGSN
ASN GW
IPSG
SCM
PDIF
PDSN
HA
ASN
GW/FA
GGSN/FA
HSGW
IPSG
PDIF
PDSN/FA
P-GW
S-GW
ST40
ST40
ST40
ST40
ST40
ST40
License Name
--
MPLS
Multimedia Broadcast & Multicast
Service
PDSN RAN Optimization, Bundle
1
EV-DO Rev A/PDSN
--
Prepaid Accounting/IS-835C
Prepaid Bundle
Proxy MIP
Combo Phone Bundle
Destination Based Accounting
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Enhanced Feature Overview
Enhanced Feature Name
Routing
Session Recovery
Subscriber Overcharging Protection
Traffic Policing and Shaping
Ty Interface Support
VLANs
OL-22983-01
Supported Products and Licensing ▀
Product
GGSN
SGSN
ASN GW
GGSN
HSGW
HA
PDSN
P-GW
SCM
S-GW
PDSN
HA
ASN GW
GGSN
HA
HSGW
IPSG
MME
PDIF
PDSN
P-GW
SCM
SGSN
S-GW
ASN GW
GGSN
HA
HSGW
IPSG
MME
PDSN
P-GW
SCM
S-GW
ASN GW
GGSN
HA
HSGW
IPSG
MME
PDIF
PDSN
P-GW
SCM
SGSN
S-GW
Platform License Name
ST40 IPv4 Routing Protocols
ST40 Session Recovery
ST40
ST40
UMTS Overcharging Protection
Per Subscriber Traffic
Policing/Shaping
ST40
ST40
Dynamic Policy Interface
--
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 3
Verifying and Saving Your Configuration
This chapter describes how to save the system configuration.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Verifying and Saving Your Configuration
▀ Verifying the Configuration
Verifying the Configuration
You can use a number of command to verify the configuration of your feature, service, or system. Many are hierarchical in their implementation and some are specific to portions of or specific lines in the configuration file.
Feature Configuration
In many configurations, specific features are set and need to be verified. Examples include APN and IP address pool configuration. Using these examples, enter the following commands to verify proper feature configuration:
The output displays the complete configuration for the APN. In this example, an APN called apn1 is configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Verifying and Saving Your Configuration
Verifying the Configuration ▀
Enter the following command to display the IP address pool configuration:
The output from this command should look similar to the sample shown below. In this example, all IP pools were configured in the isp1 context.
Important:
Many features can be configured on the system. There are show commands specifically for these features. Refer to the Command Line Interface Reference for more information.
Service Configuration
Verify that your service was created and configured properly by entering the following command:
< > < >
The output is a concise listing of the service parameter settings similar to the sample displayed below. In this example, a
P-GW service called pgw is configured.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Verifying and Saving Your Configuration
▀ Verifying the Configuration
Context Configuration
Verify that your context was created and configured properly by entering the following command:
The output shows the active context. Its ID is similar to the sample displayed below. In this example, a context named
test1 is configured.
System Configuration
Verify that your entire configuration file was created and configured properly by entering the following command:
This command displays the entire configuration including the context and service configurations defined above.
Finding Configuration Errors
Identify errors in your configuration file by entering the following command:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Verifying and Saving Your Configuration
Verifying the Configuration ▀
This command displays errors it finds within the configuration. For example, if you have created a service named
―service1‖, but entered it as ―srv1‖ in another part of the configuration, the system displays this error.
keyword and You must refine this command to specify particular sections of the configuration. Add the choose a section from the help menu: or
If the configuration contains no errors, an output similar to the following is displayed:
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Verifying and Saving Your Configuration
▀ Saving the Configuration
Saving the Configuration
Save system configuration information to a file locally or to a remote node on the network. You can use this configuration file on any other systems that require the same configuration.
Files saved locally can be stored in the SPC‘s/SMC‘s CompactFlash or on an installed PCMCIA memory card on the
SPC/SMC. Files that are saved to a remote network node can be transmitted using either FTP, or TFTP.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Verifying and Saving Your Configuration
Saving the Configuration on the Chassis ▀
Saving the Configuration on the Chassis
These instructions assume that you are at the root prompt for the Exec mode:
To save your current configuration, enter the following command:
Keyword/Variable Description
Specifies the path and name to which the configuration file is to be stored. remote file. must be entered using one of the following formats:
{ | [ ] } [
may refer to a local or a
]
[ [ ] ] { |
[ [ : ] ] { |
corresponds to the CompactFlash on the SPC/SMC.
corresponds to PCMCIA slot 1.
corresponds to PCMCIA slot 2.
is the IP address of the network server.
is the network server‘s .
is the network server‘s logical port number. Defaults are: tftp: 69 - data ftp: 20 - data, 21 - control
} [
} [
] [
] [ sftp: 115 - data
Note: can only be used if the
DHCP server returns a valid nameserv er.dx
parameter is configured for DHCP and the
is the username required to gain access to the server if necessary. is the password for the specified username if required.
specifies the directory where the file is located if one exists.
specifies the name of the configuration file to be saved.
Note: Configuration files should be named with a .cfg extension.
]
]
-redundant Optional: This keyword directs the system to save the CLI configuration file to the local device, defined by the url variable, and then automatically copy that same file to the like device on the Standby SPC/SMC, if available.
Note: This keyword will only work for like local devices that are located on both the active and standby
SPCs/SMCs. For example, if you save the file to the /pcmcia1 device on the active SPC/SMC, that same type of device (a PC-Card in Slot 1 of the standby SPC/SMC) must be available. Otherwise, a failure message is displayed.
Note: If saving the file to an external network (non-local) device, the system disregards this keyword.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Verifying and Saving Your Configuration
▀ Saving the Configuration on the Chassis
Keyword/Variable Description
-noconfirm showsecrets verbose
Optional: Indicates that no confirmation is to be given prior to saving the configuration information to the specified filename (if one was specified) or to the currently active configuration file (if none was specified).
Optional: This keyword causes the CLI configuration file to be saved with all passwords in plain text, rather than their default encrypted format.
Optional: Specifies that every parameter that is being saved to the new configuration file should be displayed.
Important:
The keyword is only applicable when saving a configuration file to local devices.This command does not synchronize the local file system. If you have added, modified, or deleted other files or directories to or from a local device for the active SPC/SMC, then you must synchronize the local file system on both SPCs/SMCs.
To save a configuration file called system.cfg to a directory that was previously created called cfgfiles on the
SPC‘s/SMC‘s CompactFlash, enter the following command:
To save a configuration file called simple_ip.cfg to a directory called host_name_configs using an FTP server with an IP address of 192.168.34.156 on which you have an account with a username of administrator and a password of secure, use the following command:
To save a configuration file called init_config.cfg to the root directory of a TFTP server with a hostname of config_server, enter the following command:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 4
Access Control Lists
This chapter describes system support for access control lists and explains how they are 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.
Important:
You do not require a license to configure ACLs; however, the number of ACLs configured might impact performance significantly.
Important:
Not all commands and keywords/variables may be available. This is dependent on the platform type.
This chapter contains the following sections:
Configuring ACLs on the System
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Access Control Lists
▀ Overview
Overview
IP access lists, or access control lists (ACLs) as they are commonly referred to, are used to control the flow of packets into and out of the system. They are configured on a per-context basis and consist of ―rules‖ (ACL rules) or filters that control the action taken on packets that match the filter criteria. Once configured, an ACL can be applied to any of the following:
An individual interface
All traffic facilitated by a context (known as a policy ACL)
An individual subscriber
All subscriber sessions facilitated by a specific context
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Understanding ACLs ▀
Understanding ACLs
This section discusses the two main aspects to ACLs on the system:
Rule(s)
Rule Order
Important:
Refer to the ACL Configuration Mode Commands chapter of the Command Line Interface Reference for the full command syntax.
Rule(s)
A single ACL consists of one or more ACL rules. As discussed earlier, the rule is a filter configured to take a specific action on packets matching specific criteria. Up to 128 rules can be configured per ACL.
Important:
Configured ACLs consisting of no rules imply a ―deny any‖ rule. The deny action and any criteria are discussed later in this section. This is the default behavior for an empty ACL.
Each rule specifies the action to take when a packet matches the specifies criteria. This section discusses the rule actions and criteria supported by the system.
Actions
ACLs specify that one of the following actions can be taken on a packet that matches the specified criteria:
Permit: The packet is accepted and processed.
Deny: The packet is rejected.
Redirect: The packet is forwarded to the specified next-hop address through a specific system interface or to the specified context for processing.
Important:
Redirect rules are ignored for ACLs applied to specific subscribers or all subscribers facilitated by a specific context, or APN for UMTS subscribers.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Access Control Lists
▀ Understanding ACLs
Criteria
Each ACL consists of one or more rules specifying the criteria that packets will be compared against.
The following criteria are supported:
Any: Filters all packets
Host: Filters packets based on the source host IP address
ICMP: Filters Internet Control Message Protocol (ICMP) packets
IP: Filters Internet Protocol (IP) packets
Source IP Address: Filter packets based on one or more source IP addresses
TCP: Filters Transport Control Protocol (TCP) packets
UDP: Filters User Datagram Protocol (UDP) packets
Each of the above criteria are described in detail in the sections that follow.
Important:
The following sections contain basic ACL rule syntax information. Refer to the ACL Configuration
Mode Commands chapter of the Command Line Interface Reference for the full command syntax.
Any: The rule applies to all packets.
Host: The rule applies to a specific host as determined by its IP address.
ICMP: The rule applies to specific Internet Control Message Protocol (ICMP) packets, Types, or Codes.
Important:
ICMP type and code definitions can be found at www.iana.org as indicated by
RFC 3232.
IP: The rule applies to specific Internet Protocol (IP) packets or fragments.
IP Packet Size Identification Algorithm: The rule applies to specific Internet Protocol (IP) packets identification for fragmentation during forwarding.
This configuration is related to the ―IP Identification field‖ assignment algorithm used by the system, when subscriber packets are being encapsulated (such as Mobile IP and other tunneling encapsulation). Within the system, subscriber packet encapsulation is done in a distributed way and a 16 bit IP identification space is divided and distributed to each entity which does the encapsulation, so that unique IP identification value can be assigned for IP headers during encapsulation.
Since this distributed IP Identification space is small, a non-zero unique identification will be assigned only for those packets, which may potentially be fragmented during forwarding (since the IP identification field is only used for reassembly of the fragmented packet). The total size of the IP packet is used to determine the possibility of that packet getting fragmented.
Source IP Address: The rule applies to specific packets originating from a specific source address or a group of source addresses.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Understanding ACLs ▀
TCP: The rule applies to any Transport Control Protocol (TCP) traffic and could be filtered on any combination of source/destination IP addresses, a specific port number, or a group of port numbers.
Important:
TCP port numbers definitions can be found at www.iana.org.
UDP: The rule applies to any User Datagram Protocol (UDP) traffic and could be filtered on any combination of source/destination IP addresses, a specific port number, or a group of port numbers.
Important:
UDP port numbers definitions can be found at www.iana.org.
Rule Order
A single ACL can consist of multiple rules. Each packet is compared against each of the ACL rules, in the order in which they were entered, until a match is found. Once a match is identified, all subsequent rules are ignored.
Additional rules can be added to an existing ACL and properly ordered using either of the following options:
Before
After
Using these placement options requires the specification of an existing rule in the ACL and the configuration of the new rule as demonstrated by the following flow:
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Access Control Lists
▀ Configuring ACLs on the System
Configuring ACLs on the System
This section provides information and instructions for configuring ACLs.
Important:
This section provides the minimum instruction set for configuring access control list on the system.
For more information on commands that configure additional parameters and options, refer ACL 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 access control list by applying the example configuration in the Creating ACLs section.
Step 2
Step 3
Optional. The system provides an ―undefined‖ ACL that acts as a default filter for all packets into the context. The default action is to ―permit all‖. Modify default configuration for ―unidentified‖ ACLs for by applying the example
configuration in the Configuring an Undefined ACL section.
Step 4
Verify your ACL configuration by following the steps in the Verifying the ACL Configuration section.
Step 5
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Creating ACLs
To create an ACL, use the following configuration:
Notes:
The maximum number of ACLs that can be configured per context is limited by the amount of available memory in the VPN Manager software task. Typically, the maximum is less than 200.
Configuring Action and Criteria for Subscriber Traffic
To create rules to deny/permit the subscriber traffic and apply the rules after or before action, use the following configuration:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Configuring ACLs on the System ▀
Notes:
comprise the ACL. For more information, refer ACL Configuration Mode Commands in Command Line
Interface Reference.
The maximum number of rules that can be configured per ACL varies depending on how the ACL is to be used.
For more information, refer Engineering Rules in System Administration Guide.
Caution:
Unless configured to do otherwise, the system implicitly adds a ―deny any‖ rule to the end of the ACL resulting in the packet being dropped if it does not match any other configured rule. This behavior can be changed by adding a ―permit any‖ rule as the last rule in the ACL.
Configuring an “Undefined” ACL
As discussed previously in this chapter the system uses an ―undefined‖ ACL mechanism for filtering the packet(s) in the event that an ACL that has been applied is not present. This scenario is likely the result of a mis-configuration such as the ACL name being mis-typed during the configuration process.
For these scenarios, the system provides an ―undefined‖ ACL that acts as a default filter for all packets into the context.
The default action is to ―permit all‖.
To modify the default behavior for unidentified ACLs, use the following configuration:
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Access Control Lists
▀ Configuring ACLs on the System
Context name is the name of the context containing the ―undefined‖ ACL to be modified. For more information, refer Context Configuration Mode Commands in Command Line Interface Reference.
Verifying the ACL Configuration
To verify the ACL configuration:
Step 1
In the Exec Mode, enter the following command:
The following is a sample output of this command. In this example, an ACL named was configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
Applying IP ACLs
Once an ACL is configured, it must be applied to take effect.
As discussed earlier, an ACL can be applied to any of the following:
Applying an ACL to an Individual Interface
Applying an ACL to All Traffic Within a Context (known as a policy ACL)
Applying an ACL to an Individual Subscriber
Applying a Single ACL to Multiple Subscribers
Applying a Single ACL to Multiple Subscribers via APNs (for 3GPP subscribers only)
Important:
ACLs must be configured in the same context in which the subscribers and/or interfaces to which they are to be applied. Similarly, ACLs to be applied to a context must be configured in that context.
If ACLs are applied at multiple levels within a single context (i.e. an ACL is applied to an interface within the context and another ACL is applied to the entire context), they will be processed as shown in the following figure and table.
Figure 4. ACL Processing Order
Source Context
From/To
Mobile
Node
GRE, GTP, or IP-in-IP
Tunnel
Interface
In
ACL
1
4
Out
ACL
3
Context
ACL
Destination Context
Sub.
In
ACL
2
Context
ACL
3
Interface
Out
ACL
4
2
Sub.
Out
ACL
1
In
ACL
To/From
PDN
Table 7. ACL Processing Order Descriptions
3
4
Packet coming from the mobile node to the packet data network (left to right)
Order Description
1
2
An inbound ACL configured for the receiving interface in the Source Context is applied to the tunneled data (i.e. the outer
IP header). The packet is then forwarded to the Destination Context.
An inbound ACL configured for the subscriber (either the specific subscriber or for any subscriber facilitated by the context) is applied.
A context ACL (policy ACL) configured in the Destination Context is applied prior to forwarding.
An outbound ACL configured on the interface in the Destination Context through which the packet is being forwarded is applied.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Access Control Lists
▀ Applying IP ACLs
3
4
1
2
Packet coming from the packet data network to the mobile node (right to left)
Order Description
An inbound ACL configured for the receiving interface configured in the Destination Context is applied.
An outbound ACL configured for the subscriber (either the specific subscriber or for any subscriber facilitated by the context) is applied. The packet is then forwarded to the Source Context.
A context ACL (policy ACL) configured in the Source Context is applied prior to forwarding.
An outbound ACL configured on the interface in the Source Context through which the packet is being forwarded is applied to the tunneled data (i.e. the outer IP header).
In the event that an IP ACL is applied that has not been configured (i.e. the name of the applied ACL was configured incorrectly), the system uses an ―undefined‖ ACL mechanism for filtering the packet(s).
This section provides information and instructions for applying ACLs and for configuring an ―undefined‖ ACL.
Applying an ACL to an Individual Interface
This section provides information and instructions for applying one or more ACLs to an individual interface configured on the system.
Important:
It is recommended that all ACLs be configured and verified according to the instructions in the
Configuring ACLs on the System section of this chapter prior to beginning this procedure.
Important:
This section provides the minimum instruction set for applying the ACL list to an interface on the system. For more information on commands that configure additional parameters and options, refer Ethernet Interface
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide ACL facility to subscribers:
Step 1
section.
Step 2
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Applying ACL to Interface
To apply the ACL to an interface, use the following configuration:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
Notes:
The context name is the name of the ACL context containing the interface to which the ACL is to be applied.
The ACL to be applied must be configured in the context specified by this command.
Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128 rule limit for the interface.
Verifying the ACL Configuration on Interface
This section describes how to verify the ACL configuration.
Step 1
In the Exec Mode, enter the following command:
is the name of the context containing the interface to which the ACL(s) was/were applied.
The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Access Control Lists
▀ Applying IP ACLs
Applying an ACL to All Traffic Within a Context
This section provides information and instructions for applying one or more ACLs to a context configured within a specific context on the system. The applied ACLs, known as policy ACLs, contain rules that apply to all traffic facilitated by the context.
Important:
It is recommended that all ACLs be configured and verified according to the instructions in the
Configuring ACLs on the System section of this chapter prior to beginning this procedure.
Important:
This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Context
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide access control list facility to subscribers:
Step 1
Apply the configured ACL as described in the Applying ACL to Context section.
Step 2
section.
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Applying ACL to Context
To apply the ACLs to a context, use the following configuration:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
Notes:
The context name is the name of the ACL context containing the interface to which the ACL is to be applied.
The context-level ACL are applied only to outgoing packets. The only present for backward compatibility.
and keywords are deprecated and are
The ACL to be applied must be configured in the context specified by this command.
Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128 rule limit for the interface.
Verifying the ACL Configuration in a Context
To verify the ACL configuration:
Step 1
Verify that your ACL lists were applied properly by entering the following command in Exec Mode:
is the name of the context to which the ACL(s) was/were applied.
The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Access Control Lists
▀ Applying IP ACLs
Applying an ACL to an Individual Subscriber
IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.
To apply an ACL to a RADIUS-based subscriber, use the
Administration and Reference for more detail on this attribute.
attribute. Refer to the AAA Interface
This section provides information and instructions for applying an ACL to an individual subscriber whose profile is configured locally on the system.
Important:
It is recommended that all ACLs be configured and verified according to the instructions in the
that the subscribers have been previously configured.
Important:
This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide access control list facility to subscribers:
Step 1
Step 2
Individual Subscriber section.
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Applying ACL to an Individual Subscriber
To apply the ACL to an individual subscriber, use the following configuration:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
Notes:
The context name is the name of the ACL context containing the interface to which the ACL is to be applied.
If neither the nor the keyword is specified, the ACL will be applied to all packets in and out.
The ACL to be applied must be configured in the context specified by this command.
Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128 rule limit for the interface.
Verifying the ACL Configuration to an Individual Subscriber
These instructions are used to verify the ACL configuration.
Step 1
Verify that your ACL lists were applied properly by entering the following command in Exec Mode:
is the name of the context containing the subscriber to which the ACL(s) was/were applied.
The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Access Control Lists
▀ Applying IP ACLs
Applying a Single ACL to Multiple Subscribers
As mentioned in the previous section, IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.
The system provides for the configuration of subscriber functions that serve as default values when specific attributes are not contained in the individual subscriber‘s profile. The following table describes these functions.
Table 8. Functions Used to Provide “Default” Subscriber Attributes
Function
Subscriber Named default
Command
Description
Within each context, the system creates a subscriber called default. The profile for the subscriber named default provides a configuration template of attribute values for subscribers authenticated in that context.
Any subscriber attributes that are not included in a RADIUS-based subscriber profile is configured according to the values for those attributes as defined for the subscriber named default.
NOTE: The profile for the subscriber named default is not used to provide missing information for subscribers configured locally.
This command in the PDSN, FA, and HA service Configuration modes specifies a profile from a subscriber named something other than default to use a configuration template of attribute values for subscribers authenticated in that context.
This command allows multiple services to draw ―default‖ subscriber information from multiple profiles.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
When configured properly, the functions described in the table above could be used to apply an ACL to:
All subscribers facilitated within a specific context by applying the ACL to the profile of the subscriber named
default.
All subscribers facilitated by specific services by applying the ACL to a subscriber profile and then using the default subscriber command to configure the service to use that subscriber as the ―default‖ profile.
Applying an ACL to the Subscriber Named default
This section provides information and instructions for applying an ACL to the subscriber named default.
Important:
It is recommended that all ACLs be configured and verified according to the instructions in the
Configuring ACLs on the System section of this chapter prior to beginning this procedure.
Important:
This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide access control list facility to subscribers:
Step 1
Subscriber Named default section.
Step 2
Subscriber Named default section.
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Applying an ACL to the Subscriber Named default
To example to apply the ACL to the default subscriber, use the following configuration:
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Access Control Lists
▀ Applying IP ACLs
The context name is the name of the ACL context containing the interface to which the ACL is to be applied.
If neither the nor the keyword is specified, the ACL will be applied to all packets in and out.
The ACL to be applied must be configured in the context specified by this command.
Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128 rule limit for the interface.
Verifying the ACL Configuration to the Subscriber Named default
These instructions are used to verify the ACL configuration.
Step 1
Verify that your ACL lists were applied properly by entering the following command in Exec Mode:
is the name of the context containing the subscriber default to which the ACL(s) was/were applied.
The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
Applying an ACL to Service-specified Default Subscribers
This section provides information and instructions for applying an ACL to the subscriber to be used as the ―default‖ profile by various system services.
Important:
It is recommended that all ACLs be configured and verified according to the instructions in the
that the services and subscribers have been previously configured.
Important:
This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide access control list facility to subscribers:
Step 1
Step 2
Service-specified Default Subscriber section.
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Applying an ACL to Service-specified Default Subscriber
To apply the ACL to a service-specified Default subscriber, use the following configuration:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Access Control Lists
▀ Applying IP ACLs
Notes:
The context name is the name of the ACL context containing the interface to which the ACL is to be applied.
If neither the nor the keyword is specified, the ACL will be applied to all packets in and out.
The ACL to be applied must be configured in the context specified by this command.
Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128 rule limit for the interface.
Verifying the ACL Configuration to Service-specified Default Subscriber
To verify the ACL configuration.
Step 1
Verify that your ACL lists were applied properly by entering the following command in Exec Mode:
is the name of the context containing the service
ACL(s) was/were applied.
having default subscriber to which the
The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
Applying a Single ACL to Multiple Subscribers via APNs
As mentioned in the previous section, IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.
To reduce configuration time, ACLs can alternatively be applied to APN templates for GGSN subscriber. When configured, any subscriber packets facilitated by the APN template would then have the associated ACL applied.
This section provides information and instructions for applying an ACL to an APN template.
Important:
It is recommended that all ACLs be configured and verified according to the instructions in the
Configuring ACLs on the System section of this chapter prior to beginning this procedure.
Important:
This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide access control list facility to subscribers:
Step 1
Step 2
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Applying an ACL to Multiple Subscriber via APNs
To apply the ACL to multiple subscribers via APN, use the following configuration:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Access Control Lists
▀ Applying IP ACLs
Notes:
The ACL to be applied must be in the destination context of the APN (which can be different from the context where the APN is configured).
If either the or and once with
keyword is not specified, the command is added to the config file twice, once with
, and the ACL will be applied to all packets inbound and outbound.
Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128 rule limit for the interface.
Verifying the ACL Configuration to APNs
To verify the ACL configuration:
Step 1
Verify that your ACL lists were applied properly by entering the following command in Exec Mode: was/were applied.
is the name of the context containing the APN having default subscriber to which the ACL(s)
The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Access Control Lists
Applying IP ACLs ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 5
Always-on
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.
This chapter contains the following sections:
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Always-on
▀ Overview
Overview
Always-on is enabled for each subscriber individually through a local subscriber profile or a RADIUS profile. Alwayson is disabled for all subscribers by default.
If Always-on is enabled for a subscriber, when the idle time-out limit is reached the subscribers IP/PPP session remains connected as long as the subscriber is reachable. This is true even if the airlink between the mobile device and the RN
(Radio Node) is moved from active to dormant (inactive) status. When the idle timeout limit is reached, the PDSN determines Mobile Node availability using LCP keepalive messages. A response to these messages indicates that the
―always-on‖ status should be maintained. Failure to respond to a predetermined number of LCP keepalive messages causes the PDSN to tear-down (disconnect) the subscriber session.
Caution:
When always-on is enabled, the subscriber must have an idle time-out period configured (default is 0, no time-out). Failure to configure an idle time-out results in the LCP keepalive messages never being sent and the subscriber session stays up indefinitely.
The RADIUS attribute 3GPP2-Always-On defined in a subscriber profile stored remotely on a RADIUS server can be used to enable Always-on for the subscriber. The attribute has two possible values, inactive and active. To enable
Always-on, set the attribute to active.
For more information, refer to AAA Interface Administration and Reference.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Always-on
Configuring Always-on ▀
Configuring Always-on
To configure Always-on for a subscriber:
Step 1
Configure Always-on as described in the Configuring Always-on section.
Step 2
Verify your configuration as described in the Verifying Your Configuration section.
Step 3
Save your configuration as described in the 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 Command Line Interface Reference for complete information regarding all commands.
Configuring Always-on
Use the following example to configure Always-on:
OL-22983-01
Notes:
must be the name of the destination context where the subscriber that you want to enable always-on is configured.
Option: To configure the echo-retransmit-timeout setting to wait before sending a keepalive message to an always-on subscriber, in the Context Configuration Mode, enter the following command:
Option: To configure the echo-max-retransmissions setting to retransmit a Keepalive message to a subscriber, in the Context Configuration Mode use the following command:
The optional echo-retransmit-timeout and echo-max-retransmissions settings apply to all subscriber sessions within the current context that have always-on enabled.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Always-on
▀ Configuring Always-on
Option: To configure the long duration timer for the subscriber, in the Subscriber Configuration Mode, enter the following command:
Option: To configure the long duration timer detection to trigger long duration timer action for the subscriber, in the Subscriber Configuration Mode enter the following command:
Option: To configure the long duration timer action for sessions exceeding the long duration timer timeout or the idle timeout durations for the subscriber, in the Subscriber Configuration Mode enter the following command:
Verifying Your Configuration
To verify your configuration:
Step 1
Change to the context where Always-on was configured by entering the following command:
Step 2
View the subscriber‘s configuration by entering the following command:
Output of the command displays the subscriber‘s configurations. Examine the output for the idle timeout and always-on fields.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 6
Broadcast Multicast Service
This chapter provides information on Broadcast Multicast Service (BCMCS) functionality. 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 a feature license for Broadcast & Multicast Services.
This chapter contains the following sections:
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Broadcast Multicast Service
▀ Overview
Overview
BCMCS eliminates unnecessary replication of data on CDMA2000 wireless networks by transmitting a single stream of data to multiple users. By delivering a single, unidirectional data stream to many subscribers, BCMCS makes more efficient use of wireless network resources than traditional point to point connections.
BCMCS functionality on the system is provided by an existing PDSN service and is enabled by a valid Broadcast &
Multicast Services license. In the absence of a valid license, the system functions as a standard unicast PDSN. When a
PDSN is functioning in a BCMCS environment, it is designated as a Broadcast Serving Node (BSN). The main features supported by the Broadcast & Multicast Services license are:
Multicast proxy-host functionality.
Support for BCMCS-specific A11 messages.
Authentication of BCMCS flow-IDs using a BCMCS controller.
Establishment and teardown of BCMCS bearer paths using the multicast framework.
Support for framing HDLC-like and segment based framing.
Accounting for the BCMCS flows to charge the originator of the content.
Licensing
To enable BCMCS on the system, you must install the Broadcast & Multicast Services license. For more information on installing licenses, refer to Software Maintenance Operations in the System Administration Guide.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Broadcast Multicast Service
Configuring BCMCS ▀
Configuring BCMCS
To configure the system for BCMCS:
Step 1
Configure the system for PDSN functionality as described in the PDSN Administration Guide.
Step 2
section.
Step 3
Step 4
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 Command Line Interface Reference for complete information regarding all commands.
BCMCS Group Configuration
Use the following example to set the BCMCS group user name and password for RADIUS access:
RADIUS Server Configuration
You must create a multicast group profile on your RADIUS server to achieve BCMCS functionality. The group name
and password must be the same as configured in BCMCS Group Configuration section.
For information about the supported BCMCS attributes, refer to the AAA Interface Administration and Reference.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Chapter 7
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 the respective product 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).
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
CoA, RADIUS DM, and Session Redirection (Hotlining)
▀ RADIUS Change of Authorization and Disconnect Message
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.
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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
RADIUS Change of Authorization and Disconnect Message ▀
commands and/or keyword options are available. Refer to the 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:
Notes:
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 AAA Interface Administration Guide.
A number of optional keywords and variables are available for the command. For more information regarding this command please refer to the 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. Use one of the following attributes to identify the system:
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
▀ RADIUS Change of Authorization and Disconnect Message
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 changeauthorize-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 is 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 cause are sent in NAK messages when a CoA or DM request fails:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
RADIUS Change of Authorization and Disconnect Message ▀
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:
The following is a sample output of this command.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ RADIUS Change of Authorization and Disconnect Message
CoA, RADIUS DM, and Session Redirection (Hotlining)
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
RADIUS Change of Authorization and Disconnect Message ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
CoA, RADIUS DM, and Session Redirection (Hotlining)
▀ Session Redirection (Hotlining)
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. For more information on readdress server, refer to the ACL
Configuration Mode Commands chapter of the 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
Session Redirection (Hotlining) ▀
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
▀ Session Redirection (Hotlining)
Viewing the Redirected Session Entries for a Subscriber
View the redirected session entries for a subscriber by entering the following command:
The following command displays debug information for a subscriber with the MSID 0000012345:
The following is a sample output of this command:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
Session Redirection (Hotlining) ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Session Redirection (Hotlining)
CoA, RADIUS DM, and Session Redirection (Hotlining)
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
CoA, RADIUS DM, and Session Redirection (Hotlining)
Session Redirection (Hotlining) ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Session Redirection (Hotlining)
CoA, RADIUS DM, and Session Redirection (Hotlining)
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 8
Congestion Control
This chapter describes the Congestion Control feature.
The following topics are covered in this chapter:
Configuring Congestion Control
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Congestion Control
▀ Overview
Overview
This section provides an overview of the Congestion Control feature.
Congestion Control monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an impact the system‘s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.
Congestion control operation is based on configuring the following:
Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled and establishes limits for defining the state of the system (congested or clear). These thresholds function in a way similar to operation thresholds that are configured for the system as described in the Thresholding
Configuration Guide. The primary difference is that when congestion thresholds are reached, a service congestion policy and an SNMP trap, starCongestion, are generated.
A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered.
Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all ports in the system reaches the specified threshold, congestion control is enabled.
Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific threshold is reached, congestion control is enabled system-wide.
Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how services respond when the system detects that a congestion condition threshold has been crossed.
Important:
This section provides the minimum instruction set for configuring congestion control. Commands that configure additional interface or port properties are provided in the Subscriber Configuration Mode chapters of the
Command Line Interface Reference.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Congestion Control
Configuring Congestion Control ▀
Configuring Congestion Control
To configure Congestion Control functionality:
Step 1
Step 2
Step 3
Step 4
Configure disconnecting subscribers based on call or inactivity time as described in the Disconnecting Subscribers
Based on Call or Inactivity Time section.
Step 5
Save your configuration as described in the Saving and Verifying Your Configuration chapter.
Configuring the Congestion Control Threshold
To configure congestion control threshold, apply the following example configuration:
Notes:
There are several additional threshold parameters. See the ―Global Configuration Mode‖ chapter of the
Command Line Interface Reference for more information.
The tolerance is the percentage under a configured threshold that dictates the point at which the condition is cleared.
Repeat this configuration as needed for additional thresholds.
Configuring Service Congestion Policies
To create a congestion control policy, apply the following example configuration:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Congestion Control
▀ Configuring Congestion Control
Notes:
When the redirect action occurs for PDSN services, the PDSN responds to the PCF with a reply code of 136,
―unknown PDSN address‖ along with the IP address of an alternate PDSN.
Redirect is not available on the PDIF.
The default action for the PDIF is ―none.‖
When the redirect action occurs for HA services, the system responds to the FA with a reply code of 136,
―unknown home agent address‖.
Redirect can not be used in conjunction with GGSN services.
Redirect is not available for the LMA service.
When setting the action to reject, the reply code is 130, ―insufficient resources‖.
For the GGSN, the reply code is 199, ―no resources available‖.
For the MME is not available.
Enabling Congestion Control Redirect Overload Policy
To create a congestion control policy and configure a redirect overload policy for the service, apply the following example configuration:
Important:
Redirect is not available on PDIF for this release.
Notes:
Optional: If the congestion control policy action was configured to redirect, then a redirect overload policy must be configured for the service(s) that are affected.
There are several service configuration modes that you can configure. See the Command Line Interface
Reference for a complete list of modes.
You can set various options for redirection. See the Command Line Interface Reference for more information.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Congestion Control
Configuring Congestion Control ▀
Repeat this configuration example to configure overload policies for additional services configured in the same context.
Verify the Service Overload Policies
To verify that the service overload policies were properly configured, in the Exec Mode, enter the following command:
This command lists the entire service configuration. Ensure that the information displayed for the ―Overload Policy‖ is accurate.
Repeat this configuration example to configure additional services in other contexts.
Verify the Congestion Control Configuration
To verify Congestion Control Configuration, in the Exec Mode, enter the following command:
The following output is a concise listing of all threshold and policy configurations:
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Configuring Congestion Control
Congestion Control
Disconnecting Subscribers Based on Call or Inactivity Time
During periods of heavy system load, it may be necessary to disconnect subscribers in order to maintain an acceptable level of system performance. You can establish thresholds to select subscribers to disconnect based on the length of time that a call has been connected or inactive.
To enable overload disconnect for the currently selected subscriber, use the following configuration example:
To disable the overload disconnect feature for this subscriber, use the following configuration example:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Congestion Control
Notes:
is not supported for the CSCF service.
Configuring Congestion Control ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 9
Content Service Steering
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:
Internal CSS is a generic feature, if an ECSv2 license is installed on your system, internal CSS can be enabled. A separate license is not required to enable internal CSS.
This chapter contains the following topics:
Configuring Internal Content Service Steering
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Content Service Steering
▀ Overview
Overview
Content Service Steering (CSS) directs selective subscriber traffic to In-line services internal to the system based on the content of the data presented by mobile subscribers. CSS is a broad term that includes features such as NAT, HTTP redirection, and DNS redirection.
CSS uses Access Control Lists (ACLs) to redirect selective subscriber traffic flows. ACLs control the flow of packets into and out of the system. ACLs consist of ―rules‖ (ACL rules) or filters that control the action taken on packets matching the filter criteria.
ACLs are configurable on a per-context basis and applies to a subscriber through either a subscriber profile (for PDSN) or an APN profile (for GGSN) in the destination context.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Content Service Steering
Configuring Internal Content Service Steering ▀
Configuring Internal Content Service Steering
To configure and activate a single CSS service for redirecting all of a subscriber‘s IP traffic to an internal in-line service:
Step 1
Define an IP ACL as described in the Defining IP Access Lists for Internal CSS section.
Step 2
Step 3
Step 4
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 Command Line Interface Reference for complete information regarding all commands. Not all commands or keywords/variables may be supported or available. This depends on the platform type and installed license(s).
Defining IP Access Lists for Internal CSS
IP ACLs specify what type of subscriber traffic and which direction (uplink, downlink, or both) traffic is redirected. The
IP ACL must be specified in the context in which subscriber authentication is performed.
Caution:
To minimize the risk of data loss, do not make configuration changes to ACLs while the system is facilitating subscriber sessions.
Use the following configuration example to define an IP ACL for internal CSS:
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Content Service Steering
▀ Configuring Internal Content Service Steering
must be an ACS service name.
For information on the keywords and options available with the
ACL Configuration Mode Commands chapter of the Command Line Interface Reference.
command, see the
For IPv6 ACLs, the same configurations must be done in the IPv6 ACL Configuration Mode. See the IPv6 ACL
Configuration Mode Commands chapter of the Command Line Interface Reference.
Applying an ACL to an Individual Subscriber (Optional)
For information on how to apply an ACL to an individual subscriber, refer to the Applying an ACL to an Individual
Subscriber section of the IP Access Control Lists chapter.
Applying an ACL to Multiple Subscribers (Optional)
IP ACLs are applied to subscribers via attributes in their profiles. The subscriber profile can be configured locally on the system or remotely on a RADIUS server.
The system provides for the configuration of subscriber functions that serve as default values when specific attributes are not contained in the individual subscriber‘s profile. When configured properly, the functions can be used to apply an
ACL to:
All subscribers facilitated within a specific context by applying the ACL to the profile of the subscriber named
default.
All subscribers facilitated by specific services by applying the ACL to a subscriber profile and then using the default subscriber command to configure the service to use that subscriber as the ―default‖ profile.
Applying an ACL to the Subscriber Named default (Optional)
For information on how to apply an ACL to the default subscriber, refer to the Applying an ACL to the Subscriber
Named default section of the IP Access Control Lists chapter.
Applying an ACL to Service-specified Default Subscribers (Optional)
For information on how to apply an ACL to the subscriber to be used as the ―default‖ profile by various system services, refer to the Applying an ACL to Service-specified Default Subscribers section of the IP Access Control Lists chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Content Service Steering
Configuring Internal Content Service Steering ▀
Applying an ACL to Multiple Subscribers via APNs (Optional)
This configuration is only applicable to GGSN.
IP ACLs are applied to subscribers via attributes in their profiles. The subscriber profile can be configured locally on the system or remotely on a RADIUS server.
To reduce configuration time, ACLs can alternatively be applied to APN templates. When configured, any subscriber packets facilitated by the APN template would then have the associated ACL applied.
For information on how to apply an ACL to multiple subscribers via APNs, refer to the Applying a Single ACL to
Multiple Subscribers via APNs section the IP Access Control Lists chapter.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 10
Direct Tunnel
This chapter briefly describes the 3G UMTS direct tunnel feature, indicates how it is implemented on various systems
(for example, the Serving GPRS Support Node (SGSN), the Gateway GPRS Support Node (GGSN), and the Home
NodeB Gateway (HNB-GW), and provides feature configuration procedures. Direct tunnel is an enhanced feature, so some products may require a feature implementation license and all relevant products will require completion of basic service configuration. Refer to your product‘s administration guide for feature licensing and basic service configuration information.
Currently, the SGSN is the only product that enables configuration of this feature. All other products that support direct tunnel do so by default. It is the SGSN that determines if setup of a direct tunnel is to be allowed or disallowed.
After the feature overview description, this chapter provides configuration procedures for the following:
Enabling and Disabling GTP-U Direct Tunnels
Disabling or Enabling DT Access to Specific GGSN(s)
Disabling or Enabling Direct Tunnels to Specific RNC(s)
Important:
This chapter provides a limited instruction set for configuring direct tunnel. Basic service configuration for the SGSN is provided in the SGSN Service Configuration Procedures chapter of the SGSN
Administration Guide. Command details are provided in the Command Line Interface Reference.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Direct Tunnel
▀ Direct Tunnel Feature Overview
Direct Tunnel Feature Overview
The direct tunnel architecture allows the SGSN to establish a direct user plane tunnel between the radio access network
(RAN) and the GGSN. Once a direct tunnel is established the SGSN continues to handle the control plane signaling.
This improves the user experience (e.g., expedites web page delivery, reduces round trip delay for conversational services). Additionally, direct tunnel functionality implements the standard SGSN optimization to improve the usage of user plane resources (and hardware) by removing the requirement from the SGSN to handle the user plane processing.
Typically, the SGSN sets up a direct tunnel at PDP context activation. The SGSN uses an Update PDP Context Request towards the GGSN to establish a GTP user plane (GTP-U) tunnel directly between the RNC and the GGSN. This means a significant increase in control plane load on both the SGSN and GGSN components of the packet core. Hence, deployment requires highly scalable GGSNs since the volume and frequency of Update PDP Context messages to the
GGSN will increase substantially. The SGSN‘s platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.
Figure 5. GTP-U Direct Tunnel
The following figure shows the logic used within the SGSN to determine if a direct tunnel can be used.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Direct Tunnel
Figure 6. Direct Tunnel Activation Logic
Start
Matching Operator
Policy for MS?
YES
DT Permitted by
Operator Policy?
YES
Matching APN
Policy for PDP
Context?
NO
NO
DT Restricted by RNC Config?
NO
Direct Tunnel
NO
YES
NO
DT
Restricted by APN Policy
YES
YES
No Direct Tunnel
Direct Tunnel Feature Overview ▀
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Direct Tunnel
▀ Direct Tunnel Configuration
Direct Tunnel Configuration
There are three aspects to direct tunnel configuration on the SGSN:
enabling or disabling support for direct tunnel functionality on the SGSN enabling or disabling direct tunnel (DT) access to specific GGSN(s) enabling or disabling direct tunnel (DT) access to specific radio network controller(s) (RNCs)
The procedures in the remaining portion of this chapter cover all three of the aspects noted above.
Enabling and Disabling GTP-U Direct Tunnels
By default, direct tunnel support is disallowed on the SGSN and allowed on the GGSN. The SGSN‘s direct tunnel functionality is enabled within the SGSN operator policy configuration.
SGSN operator policies specify the rules governing the services, facilities, and privileges available to subscribers depending on factors such as roaming agreements between operators, the subscription restrictions for visiting or roaming subscribers, provisioning of defaults, over-riding of standard behavior.
One aspect of a policy is to allow or disallow the setup of direct GTP-U tunnels. If no operator policies are configured, the system looks at the settings in the system operator policy named default. If direct tunnel is allowed in the default operator policy, then any incoming call that does not have an applicable operator policy configured will have direct tunnel allowed.
Enabling a Direct Tunnel
To enable a direct tunnel in an SGSN operator policy, use the following procedure:
Step 1
Enter the global configuration mode.
Step 2
Create a new SGSN operator policy or Identify an existing SGSN operator policy.
Step 3
Enable direct tunnel functionality.
Example Configuration
The following is an example of the commands used to enable direct tunneling on the SGSN:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Direct Tunnel
Disabling a Direct Tunnel
To disable a direct tunnel in an SGSN operator policy, use the following procedure:
Step 1
Enter the global configuration mode.
Step 2
Identify the existing SGSN operator policy with the DT enabled.
Step 3
Disable the direct tunnel functionality.
Example Configuration
The following is an example of the commands used to disable direct tunneling on the SGSN:
Direct Tunnel Configuration ▀
Disabling or Enabling DT Access to Specific GGSN(s)
In each SGSN operator policy, SGSN APN policies are configured to connect to a GGSN and to control the direct tunnel (DT) access to that GGSN.
Multiple SGSN APN policies can be configured per SGSN operator policy.
By default, DT functionality is allowed in SGSN APN policies.
Disabling a Direct Tunnel to a GGSN
To disable a direct tunnel access to a GGSN configured in an SGSN APN policy, use the following procedure:
Step 1
Enter the global configuration mode.
Step 2
Identify the existing SGSN operator policy with the SGSN APN policy.
Step 3
Identify the SGSN APN policy with the GGSN supporting DT.
Step 4
Disable the direct tunnel functionality.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Direct Tunnel Configuration
Example Configuration
The following is an example of the commands used to disable direct tunneling with a GGSN:
Direct Tunnel
•
Re-enabling a Direct Tunnel to a GGSN
To re-enable a direct tunnel access to a GGSN configured in an SGSN APN policy, use the following procedure:
•
•
•
Enter the global configuration mode.
Identify the existing SGSN operator policy with the SGSN APN policy.
Identify the SGSN APN policy with the GGSN.
Enable the direct tunnel functionality.
Example Configuration
The following is an example of the commands used to re-enable direct tunneling with a GGSN:
Disabling or Enabling Direct Tunnels to Specific RNC(s)
SGSN access to radio access controllers (RNCs) is configured in the IuPS service.
Each IuPS service can include multiple RNC configurations that determine communications and features depending on the RNC.
By default, direct tunnel functionality is enabled for all RNCs.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Direct Tunnel
Disabling a Direct Tunnel to an RNC
To disable direct tunnel access to an RNC, use the following procedure:
Step 1
Enter the global configuration mode.
Step 2
Identify the context containing the IuPS service configuration for that RNC.
Step 3
Identify the IuPS service configuration.
Step 4
Identify the RNC configuration
Step 5
Disable the direct tunnel access for the RNC.
Example Configuration
The following is an example of the commands used to disable direct tunneling with an RNC:
Direct Tunnel Configuration ▀
Re-enabling a Direct Tunnel to an RNC
To re-enable a direct tunnel access to an RNC configured in an IuPS service configuration, use the following procedure:
Step 1
Enter the global configuration mode.
Step 2
Identify the context containing the IuPS service configuration for that RNC.
Step 3
Identify the IuPS service configuration.
Step 4
Identify the RNC configuration
Step 5
Re-enable the direct tunnel access for the RNC.
Example Configuration
The following is an example of the commands used to re-enable direct tunneling with an RNC:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Direct Tunnel Configuration
Direct Tunnel
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 11
GRE Protocol Interface
This chapter provides information on Generic Routing Encapsulation protocol interface support in GGSN 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.
This chapter discusses following topics for GRE protocol interface support:
Supported Networks and Platforms
Services and Application on GRE Interface
How GRE Interface Support Works
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
GRE Protocol Interface
▀ Introduction
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 noncontiguous 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
GRE Protocol Interface
Figure 7. GRE Interface Deployment Scenario
Mobile
Node
Corporate A gateway
Corporate A network
Introduction ▀
Access
Network
GGSN
GRE Tunnel
IPv4
Network
GRE Tunnel
Corporate B gateway
Corporate B network
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
GRE Protocol Interface
▀ Supported Standards
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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
GRE Protocol Interface
Supported Networks and Platforms ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Licenses
Licenses
This feature support requires following feature license/s installed on the system:
600-00-7861
600-00-7862
GRE Protocol Interface
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
GRE Protocol Interface
Services and Application on GRE Interface ▀
Services and Application on GRE Interface
GRE interface implementation provides following functionality with GRE protocol support.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
GRE Protocol Interface
▀ How GRE Interface Support Works
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
GRE Protocol Interface
How GRE Interface Support Works ▀
Figure 8. Ingress Packet Processing on GRE Interface
Start
End
Lookup based on outer DA-SA and is it
GRE
No
Processing of other type of packets
Yes
Set received tunneled packet flag
Drop packet
Yes
Does received GRE have Sequence
Number, CRC or GRE
Key?
No
Send packet to configured VPN mgr
Yes
Is it a GRE
Keepalive?
No
Get Flow Record.
(Tunnel header and VRF number )
Process the PPB.
1. Remove the outer IPV4 header and GRE header
2. Use the VRF number to further lookups.
Normal flow processing based on inner IP packet, in the VRF indicated by the flow record of previous successful flow record
Send packet to configured session manager
Yes
Lookup
Successful?
No
Forwarding lookup in the VRF
Is the packet destined to our chassis?
Yes
If tunneled packet flag set, re-attach header and send it to kernel
No
Send the packet to the kernel without the tunnel header for further processing
End
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ How GRE Interface Support Works
Egress Packet Processing on GRE Interface
Figure given below provides a flow of process for outgoing packets on GRE interface:
Figure 9. Egress Packet Processing on GRE Interface
Start
Receive IPV4 packet with correct
FLOWID
Do a forwarding lookup.
Lookup
Successful?
Yes
Get Forwarding Record
No
Do a Hash lookup based on SA and
DA to get the
Tunnel to be used
Does it have load balancing enabled
No
Based on Flow record information, prepare the GRE header and outer
IPV4 header
Process the packet as if it was an IPV4 packet received from
Session Manager
End
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
Take default route
GRE Protocol Interface
OL-22983-01
GRE Protocol Interface
How GRE Interface Support Works ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
GRE Protocol Interface
▀ GRE Interface Configuration
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 services.
Important:
This section provides the minimum instruction set to enable the GRE Protocol Interface support functionality on GGSN in UMTS network. Commands that configure additional function for this feature are provided in the Command Line Interface Reference.
These instructions assume that you have already configured the system level configuration as described in 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
Interface Configuration section.
Step 3
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
GRE Protocol Interface
GRE Interface Configuration ▀
Notes:
< > 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.
< > 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 < > command.
GRE Tunnel Interface Configuration
This section provides the configuration example to configure the GRE tunnel interface and associate a VRF with GRE interface:
OL-22983-01
Notes:
< > is the name of the system context you want to use for GRE interface configuration.
For more information, refer 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.
< > is name of the IP interface which is defined as a tunnel type interface and to be used for GRE tunnel interface.
<
< forwarding.
> is the name of the VRF which is preconfigured in context configuration mode.
/mask> is the network IP address with sub-net mask to be used for VRF
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
GRE Protocol Interface
▀ GRE Interface Configuration
< > 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.
< > 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:
Notes:
< > is the name of the system context you want to use for OSPF routing. For more information, refer Routing chapter in System Enhanced Feature Configuration Guide.
< > is the name of the VRF which is preconfigured in context configuration mode.
< > 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:
Notes:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
GRE Protocol Interface
GRE Interface Configuration ▀
< > is the name of the system context you want to use for IP pool and AAA server group.
<
Guide.
> is name of a preconfigured IP pool. For more information refer System Administration
< > is name of a preconfigured AAA server group. For more information refer AAA
Interface Administrtion and Reference.
<
<
> is the name of the VRF which is preconfigured in context configuration mode.
> 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:
Notes:
<
<
Guide.
> is the name of the system context you want to use for APN configuration.
> is name of a preconfigured IP pool. For more information refer System Administration
< > is name of a preconfigured AAA server group. For more information refer AAA
Interface Administrtion and Reference.
< > 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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
GRE Protocol Interface
▀ GRE Interface Configuration
Notes:
<
<
> is the name of the system context you want to use for static route configuration.
> is the network IP address with sub-net mask to be used as static route.
< interface.
<
> is name of a predefined tunnel type IP interface which is to be used for GRE tunnel
> is the name of the VRF which is preconfigured in context configuration mode.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
GRE Protocol Interface
Verifying Your Configuration ▀
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:
The output of this command displays the configuration of the all interfaces configured in a context.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
GRE Protocol Interface
▀ Verifying Your Configuration
Step 2
Verify that GRE keep alive is configured properly by entering the following command in Exec Mode:
The output of this command displays the configuration of the keepalive for GRE interface configured in a context.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 12
Gx Interface Support
This chapter provides information on configuring Gx interface to support policy and charging control for subscribers in
GPRS/UMTS networks.
The IMS service provides application support for transport of voice, video, and data independent of access support.
Roaming IMS subscribers in GPRS/UMTS 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 chapter you select the configuration example that best meets your service model, and configure the required elements for that model as described in the Gateway GPRS Support
Node Administration Guide or the IP Services Gateway Administration Guide.
Important:
The IMS Authorization Service feature described in this chapter is only available if you have purchased and installed a Dynamic Policy Interface feature license on the chassis. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
The following topics are covered in this chapter:
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Gx Interface Support
▀ Rel. 6 Gx Interface
Rel. 6 Gx Interface
Important:
The Rel 6. Gx functionality is supported on StarOS 8.0 and later.
This section describes the following topics:
Supported Networks and Platforms
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).
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 6 Gx Interface ▀
Licensing
This feature requires the following license to be installed on the chassis:
[ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 6 Gx Interface
Figure 10. Rel. 6 Gx IMS Authorization Call Flow
SessMgr
ECSv2
IMSA DPCA
MN/SS
1
2
3
4
5
8
9
10
13
14
Table 9. Rel. 6 Gx IMS Authorization Call flow Description
Step Description
1
2
IMS subscriber (MN) sends request for primary PDP context activation/creation.
Session manager allocates IP address to MN.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
11
12
6
7
CRF/P-CSCF
OCS
OL-22983-01
Gx Interface Support
Rel. 6 Gx Interface ▀
Step Description
3
4
5
Session manager sends IMS authorization request to IMS Authorization service (IMSA).
IMSA creates a session with the CRF on the basis of CRF configuration.
IMSA sends request to DPCA module to issue the authorization request to selected CRF.
6
7
8
9
DPCA sends a CCR-initial message to the selected CRF. This message includes the IP address allocated to MN.
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.
DPCA module calls the callback function registered with it by IMSA.
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 (e.g. APN, QoS etc.).
12 OCS returns a CCA-Initial message to activate the statically configured rulebase and includes pre-emptive 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
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 Command Line Interface Reference for complete information regarding all commands.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 6 Gx Interface
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:
Notes:
must be the name of the context where you want to enable IMS Authorization Service. interface authentication.
must be the name of the IMS Authorization Service to be configured for the Gx
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 Command Line Interface
Reference for more information on the 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 6 Gx Interface ▀
Option: To configure the quality of service (QoS) update timeout for a subscriber, in the IMS Authorization
Service Configuration Mode, enter the following command:
Option: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
Option: 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:
Option: To configure the algorithm to select Diameter host table, in the Policy Control Configuration Mode, enter the following command:
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:
Step 2
Verify the IMS Authorization Service‘s configurations by entering the following command:
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 6 Gx Interface
Notes:
must be the name of the context in which the IMS Authorization service was configured.
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:
must be the name of the IMS Authorization Service configured for IMS authentication.
Saving the Configuration
To save changes made to the system configuration, refer to the Verifying and Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
Rel. 7 Gx Interface
Important:
The Rel 7. Gx functionality is supported only on StarOS 8.1 and StarOS 9.0 and later.
This section describes the following topics:
Supported Networks and Platforms
Configuring Rel. 7 Gx Interface
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, etc., 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 7 Gx Interface
Figure 11. PCC Logical Architecture
Online Charging System (OCS)
CAMEL SCP
Service Data
Flow Based
Credit Control
Subscription
Profile
Repository
(SPR)
Sp
Application
Function
(AF)
Rx
Policy and
Charging Rules
Function
(PCRF)
Gx
Gy
Policy and Charging
Enforcement
Function
(PCEF)
Gateway
Ga
Offline Charging
System
(OFCS)
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
Figure 12. PCC Architecture within Cisco PCEF
Starent GGSN/PCEF
DPCA IMSA ACS DCCA
ECSv2
Rel. 7 Gx Gy
PCRF OCS
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:
[ 600-00-7585 ] Dynamic Policy Interface — for IMS Authorization Service feature
[ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — for ECS functionality
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)
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 7 Gx Interface
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
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 networkcontrolled 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.
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
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, i.e. 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, i.e. 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 7 Gx Interface
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.
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 (i.e., rules which 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, shall cause the PCEF to trigger a PCRF interaction to request PCC rules from the PCRF for an established IP CAN session. The PCEF shall stop the timer once the PCEF triggers a REVALIDATION_TIMEOUT event.
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 (e.g. re-authorization upon QoS change).
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
It is possible to indicate to the PCEF that interactions with the charging systems are not required for a PCC rule, i.e. 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
Important:
In this release, PCEF does not send the default online and offline charging method in the Credit
Control Request - Initial (CCR(I)).
Charging Correlation
For the purpose of charging correlation between SDF level and application level (e.g. 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 7 Gx Interface
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 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), the
Allocation and Retention Priority (ARP), and authorized bitrates for uplink and downlink.
Charging Key (i.e. 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, etc.
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
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.
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.
OL-22983-01
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Gx Interface Support
▀ Rel. 7 Gx Interface
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. 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 (e.g. 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.
Volume Reporting Over Gx
This section describes the Volume Reporting over Gx feature.
License Requirement
The Volume Reporting over Gx feature is license dependant, requiring the following license:
[ 600-00-7822 ] Charging Over Gx
Supported Standards
The Volume Reporting over Gx feature is based on the following standard:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
3GPP TS 29.212 V9.1.0 (2009-12): 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:
Only total data usage reporting is supported. Uplink/Downlink level reporting is not supported in this release.
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:
Usage reporting on Bearer termination is not 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
OL-22983-01
Important:
In this release, the Usage-Monitoring-Informtion AVP is expected to be present without a new threshold to disable the usage monitoring after usage reporting when the threshold is breached. If no Usage-Monitoring-
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Gx Interface Support
▀ Rel. 7 Gx Interface
Informtion AVP is present in the CCA-U, the monitoring will continue with the old threshold value and the reporting happens when the threshold is breached again.
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.
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 flowlevel 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 both predefined rules and dynamic rule definitions.
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
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.
If the non-standard volume reporting flag is set, the 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.
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.
PCRF Requested Usage Report
Important:
PCRF Requested Usage Reporting is not supported in this release.
Revalidation Timeout: 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).
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.
How R7 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 7 Gx Interface
Figure 13. Rel. 7 Gx IMS Authorization Call Flow
UE SessMgr IMSA DPCA PCRF ECSv2 OCS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Table 10. Rel. 7 Gx IMS Authorization Call flow Description
2
3
4
Step Description
1 UE (IMS subscriber) requests for primary PDP context activation/creation.
5
SessMgr allocates an IP address to the UE.
SessMgr requests IMS Authorization, if IMSA is enabled for the APN.
IMSA allocates resources for the IP CAN session and the bearer, and selects the PCRF to contact based on the user's selection key (ex msisdn).
IMSA requests the DPCA module to issue an auth request to the PCRF.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
Step Description
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
8
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.
DPCA passes the charging rule definition, charging rule install, QoS information received from the PCRF, event triggers, etc. 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.
DPCA calls the callback function registered with it by IMSA. 9
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, 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 APN name, 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 APN/AAA) and GPRS specific attributes (e.g. APN, UMTS QoS, etc.).
13 OCS returns a CCA initial message that may activate a statically configured Rulebase and may include pre-emptive 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)).
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 7 Gx Interface
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
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 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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
OL-22983-01
Notes:
must be the name of the context where you want to enable IMS Authorization service. interface authentication.
must be the name of the IMS Authorization service to be configured for Rel. 7 Gx
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
and the starting and ending MSISDNs respectively.
To enable the Gx interface to connect to a specific PCRF for a specific subscriber, configure both
and the same MSISDN.
with
with
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.
Option: To configure the Quality of Service (QoS) update timeout for a subscriber, in the IMS Authorization
Service Configuration Mode, enter the following command:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Gx Interface Support
▀ Rel. 7 Gx Interface
Option: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
Option: 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:
To configure the PCRF host destinations configured in the GGSN/PCEF, use the
CLI commands.
To configure the GGSN/PCEF to use a pre-defined rule when the Gx fails, set the
CLI to . Policies available/in use will continue to be used and there will be no further interaction with the PCRF.
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:
Step 2
Verify the IMS Authorization service‘s configurations by entering the following command:
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.
Notes:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Gx Interface Support
Rel. 7 Gx Interface ▀
must be the name of the context in which the IMS Authorization service was configured.
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.
Provided interpretation of the Gx rulebase is chosen to be ECS group-of-ruledefs, configure the following command available in the Active Charging Service Configuration Mode:
Verifying Subscriber Configuration
Verify the IMS Authorization service configuration for subscriber(s) by entering the following command:
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:
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.
Saving the Configuration
To save changes to the configuration, refer to the Verifying and Saving Your Configuration chapter.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Gx Interface Support
▀ Rel. 7 Gx Interface
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.
Table 11. Gathering Rel. 7 Gx Statistics and Information
Statistics/Information
Information and statistics specific to policy control in IMS Authorization service.
Information and statistics specific to the authorization servers used for
IMS Authorization service.
Information of all IMS Authorization service.
Statistics of IMS Authorization service.
Action to perform
Information, configuration, and statistics of sessions active in IMS
Authorization service.
Complete information, configuration, and statistics of sessions active in
IMS Authorization service.
Summarized information of sessions active in IMS Authorization service. show ims-authorization sessions all show ims-authorization sessions full
Complete statistics for active charging service sessions.
Information for all rule definitions configured in the service.
Information for all rulebases configured in the system.
Information on all group of ruledefs configured in the system.
Information on policy gate counters and status. show active-charging sessions full show active-charging ruledef all show active-charging rulebase all show active-charging group-of-ruledefs all show ims-authorization policy-gate { counters | status
}
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 13
HA Proxy DNS Intercept
This chapter describes the system‘s support for the HA Proxy DNS Intercept feature 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:
HA Proxy DNS Intercept is a license-enabled feature.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
HA Proxy DNS Intercept
▀ Overview
Overview
An inherent problem in many mobile IP scenarios is the placement of the foreign network‘s Domain Name Server
(DNS) behind a firewall. When a mobile user roams into a foreign network and the DNS address is returned to the home network, the home network does not have access to the foreign network‘s DNS. A common solution is to implement IS-
835D, but the majority of legacy mobile handsets and most current handsets do not support this standard.
To address this, a proxy DNS intercept feature is available for the Home Agent (HA). This feature, when configured, looks for DNS packets and compares the DNS IP address in the destination address field to a configured rules list. If the destination address matches an address on a ―pass through‖ rules list, the packets are allowed to continue without modification. If the destination address is on a ―redirect‖ rules list, the packets are intercepted and the visited network‘s
DNS IP address is replaced with the home network‘s DNS IP address while the call is accessing the home network.
When the DNS response is returned to the mobile node, the HA removes the home network‘s DNS address and returns the original visited network‘s address so the mobile node is not aware that a modification has occurred. The flow in the following figure provides an example of what happens when a visited networks DNS address is intercepted by the HA.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
HA Proxy DNS Intercept
Figure 14. HA Proxy DNS Intercept Flow
Visited PDSN Home Agent
Mobile Node
Home DNS
PPP IPCP
Request
PPP IPCP Rsp
(Visited DNS address)
MIP Negotiation
DNS Query (to Visited DNS
Server)
1. Intercept DNS Query
2. DNS IP Address match redirect list?
3. If yes, send proxy request to home
DNS server
DNS Query
DNS Rsp
DNS Rsp (as if from Visited DNS
Server)
Overview ▀
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
HA Proxy DNS Intercept
▀ Configuring Proxy DNS Intercept
Configuring Proxy DNS Intercept
To configure the Proxy DNS Intercept feature:
Step 1
Intercept in the Destination Context section.
Step 2
Proxy DNS Intercept Rules List section.
Step 3
Proxy DNS Intercept Rules List With a Subscriber section.
Step 4
Save your configuration as described in the 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 Command Line Interface Reference for complete information regarding all commands.
Enabling Proxy DNS Intercept in the Destination Context
Use the following example to enable the Proxy DNS Intercept feature in the subscriber destination context:
Notes:
The command must be entered in the destination context for the subscriber. If there are multiple destination contexts for different subscribers, the command must be entered in each context. This feature uses UDP port 53.
must be the interface in the current context where all redirected DNS requests will be sent.
Creating the Proxy DNS Intercept Rules List
Use the following example to create the list of rules in the AAA context, which is used to specify how an intercepted
DNS packet is to be processed:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
HA Proxy DNS Intercept
Configuring Proxy DNS Intercept ▀
Notes:
must be the name of the rules list for later association with a subscriber.
Up to 64 separate rules lists can be configured in a single AAA context.
Use the command to set the DNS IP addresses that should be allowed through the intercept feature.
Use the command to set the DNS IP addresses that should be redirected by the intercept feature to the home DNS. Use the optional and keywords to specify the IP addresses of primary and secondary home DNS servers. Refer to the Command Line Interface Reference for more information regarding these optional keywords.
Important:
If a packet does not match the pass-thru or redirect rule, the packet is dropped. If the optional keywords or are not configured, DNS messages are redirected to the primary-dns-server (or the secondary-dns-server) configured for the subscriber OR inside the context.
Up to 128 rules of any type can be configured per rules list.
Associating a Proxy DNS Intercept Rules List With a Subscriber
Use the following example to associate a system-configured subscriber with a configured Proxy DNS rules list.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 14
HA Redundancy for Dynamic Home Agent Assignment
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.
This chapter includes the following topics:
Configuring HA Redundancy for Dynamic Home Agent Assignment
Verifying RADIUS Server Configurations
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
HA Redundancy for Dynamic Home Agent Assignment
▀ Feature Description
Feature Description
This feature provides a mechanism for a system functioning as a Home Agent (HA) to communicate status information to a properly configured RADIUS server. The status information is used by the RADIUS server to determine the availability and readiness of the HA to accept Mobile IP (MIP) subscriber sessions. The RADIUS server‘s awareness of the HA status allows it to dynamically assign immediately available HAs to subscriber sessions.
When a RADIUS server assigns an HA to a Mobile Node (MN), it is very important that only active, or accessible, HAs are selected for the assignment. Therefore, it is necessary for the RADIUS server to detect the availability of each HA before assigning it to an MN. This feature allows the RADIUS server to gather and maintain a list of available HAs through a detection mechanism that provides frequent updates.
With this feature, bogus authentication messages, called probe authentication messages, are exchanged between the
RADIUS server and the HA. The HA periodically sends Access-Request messages to the RADIUS server. The
RADIUS server distinguishes the probe authentication request from other regular subscriber authentication messages, validates them, and sends proper response.
The probe Access-Request contains the following attributes and expects an Access-Accept from the RADIUS server.
User-Name and User-Password are configurable in the system.
If an Access-Accept message is sent in response to the probe authentication request, the RADIUS server updates the status of the HA as active. If an Access-Reject message is sent, the RADIUS server updates only the statistics without any further action. If the RADIUS server misses receiving a configured number of probe authentication requests, the
HA, and all of its associated IP addresses, is marked as down, or inaccessible. When an HA is marked as down, a backup HA and its associated IP addresses are made active and used for assignment in the place of the inaccessible HA.
Supported Implementations
This feature is supported on system installations that are configured as Home Agents and are configured to communicate with a AAA Service Controller that supports the configuration of Active and Backup HAs. For more information on a compatible AAA Service Controller, contact your designated customer support engineer.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
HA Redundancy for Dynamic Home Agent Assignment
Configuring HA Redundancy for Dynamic Home Agent Assignment ▀
Configuring HA Redundancy for Dynamic Home Agent
Assignment
Important:
The commands or keywords/variables that are available are dependent on platform type, product version, and installed license(s).
Step 1
Configure the AAA Service Controller as described in the AAA Service Controller documentation.
Step 2
Configure RADIUS support on the HA as described in the Configuring RADIUS Support on the HA section.
Step 3
Save the configuration as described in Verifying and Saving Your Configuration.
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 the AAA Service Controller
The AAA Service Controller should be configured with the following parameters. For configuration information refer to the AAA Service Controller documentation.
Authentication-Probe User profile:
Probe Username
Probe Password
HA Client information:
HA Client IPv4 address (NAS-IP-Address attribute)
HA client secret (authenticator)
Whether the HA client is a Primary or Backup HA client
One or more HA Service addresses for each HA client address.
The number of missed probe authentication requests before the HA Client is marked as down.
The number of seconds to wait for a probe authentication request from the HA client (timeout period).
The number of seconds to wait for a backup HA server to be in the active state after a reboot, known as backuphold-timeout.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Configuring HA Redundancy for Dynamic Home Agent Assignment
Configuring RADIUS Support on the HA
Use the following example to configure RADIUS support on the HA:
HA Redundancy for Dynamic Home Agent Assignment
Notes:
<context_name> must be the name of the AAA context that the HA service uses for authentication.
A number of optional keywords and variables are available for the
Command Line Interface Reference for more information regarding this command.
command. Refer to the
Option: To configure HA redundancy with AAA server group, in the Context Configuration Mode, use the following command:
must be the name of the AAA group designated for AAA functionality within the context. A total of 400 server groups can be configured system-wide including the default server-group unless
is enabled. For information on configuring context-level AAA functionality, refer to the AAA Interface Administration and Reference.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
HA Redundancy for Dynamic Home Agent Assignment
Verifying RADIUS Server Configurations ▀
Verifying RADIUS Server Configurations
This section provides information to verify connectivity to the RADIUS server, and information to view counters and statistics that can be useful in troubleshooting issues.
Step 1
Verify connectivity to the RADIUS server by sending a test probe message to the RADIUS server by entering the following command:
Important:
Any response, including considered to mean that the AAA server is alive. and
The following is a sample of the output of a successful probe authentication test.
from the AAA server, is
Step 2
View the RADIUS counters by entering the following command:
The following is a sample output of the command displaying RADIUS Probe counters.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
HA Redundancy for Dynamic Home Agent Assignment
▀ Verifying RADIUS Server Configurations
Step 3
View AAA Manager statistics by entering the following command:
The following is a sample output of the command displaying authentication probe statistics in the output.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 15
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
ICAP Interface Support
▀ Supported Networks and Platforms
Supported Networks and Platforms
This feature supports ST16 and Cisco® ASR 5000 Chassis for the core network services configured on the system.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
ICAP Interface Support
Licensing ▀
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 the following license, along with other required core network and in-line service licenses:
600-00-7578
600-00-8530
For information on additional license requirements for this feature, please contact your local sales representative.
Important:
For information on obtaining and installing licenses, refer to Managing License Keys in the System
Administration Guide.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
ICAP Interface Support
▀ ICAP Interface Support Overview
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:
Figure 15. High-Level View of Streamlined ICAP Interface with external ACF
External Active
Content Filter Server
MN/SS
CSN/PDN/
Internet
System with
ECS/CF
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
ICAP Interface Support
ICAP Interface Support Overview ▀
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
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
ICAP Interface Support
▀ ICAP Interface Support Overview
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
ICAP Interface Support
Configuring ICAP Interface Support ▀
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 CFSG Configuration Mode Commands chapter in 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
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
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:
OL-22983-01
Notes:
< > is local IP address of the CFSG endpoint.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
ICAP Interface Support
▀ Configuring ICAP Interface Support
Configuring ICAP Server and Other Parameters
Use the following example to configure the active content filtering (ICAP server) and other related parameters:
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 keyword is limited to one. Therefore, any other value configured using the keyword will be ignored.
Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
ICAP Interface Support
Configuring ICAP Interface Support ▀
Notes:
In StarOS 8.1, the 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 enabled in Optimized mode.
keyword is obsolete. With or without this keyword ACS is always
In StarOS 8.0 and StarOS 9.0 and later, the 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:
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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Configuring ICAP Interface Support
The following is a sample output. In this example, an ICAP Content Filtering server group named configured.
ICAP Interface Support
was
Step 2
Verify any configuration error in your configuraiont by entering the following command in Exec Mode:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 16
Intelligent Traffic Control
The product administration guides provide examples and procedures to configure 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.
Important:
Intelligent Traffic Control is only available if you have purchased and installed a feature license
Intelligent Traffic Controlon your system. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
This chapter covers the following topics:
Configuring Flow-based Traffic Policing
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Intelligent Traffic Control
▀ Overview
Overview
Intelligent Traffic Control (ITC) enables you to configure a set of customizable policy definitions that enforce and manage service level agreements for a subscriber profile, thus enabling you to provide differentiated levels of services for native and roaming subscribers.
In 3GPP2 service ITC uses a local policy look-up table and permits either static EV-DO Rev 0 or dynamic EV-DO Rev
A policy configuration.
Important:
ITC includes the class-map, policy-map and policy-group commands. Currently ITC does not include an external policy server interface.
ITC provides per-subscriber/per-flow traffic policing to control bandwidth and session quotas. Flow-based traffic policing enables the configuring and enforcing bandwidth limitations on individual subscribers, which can be enforced on a per-flow basis on the downlink and the uplink directions.
Flow-based traffic policies are used to support various policy functions like Quality of Service (QoS), and bandwidth, and admission control. It provides the management facility to allocate network resources based on defined traffic-flow,
QoS, and security policies.
ITC and EV-DO Rev A in 3GPP2 Networks
Important:
The EV-DO Rev A features are only available if you have purchased and installed the session use
EV-DO Rev A PDSN License on your system. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
You can configure your system to support both EV-DO Rev A and ITC. ITC uses flow-based traffic policing to configure and enforce bandwidth limitations per subscriber. Enabling EV-DO Rev A with ITC allows you to control the actual level of bandwidth that is allocated to individual subscriber sessions and the application flows within the sessions.
For more information on EV-DO Rev A, refer to the Policy-Based Management and EV-DO Rev A chapter. For setting the DSCP parameters to control ITC functionality, refer to the Traffic Policy-Map Configuration Mode Commands chapter in the Command Line Reference.
Bandwidth Control and Limiting
Bandwidth control in ITC controls the bandwidth limit, flow action, and charging action for a subscriber, application, and source/destination IP addresses. This is important to help limit bandwidth intensive applications on a network. You can configure ITC to trigger an action to drop, lower-ip-precedence, or allow the flow when the subscriber exceeds the bandwidth usage they have been allotted by their policy.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Intelligent Traffic Control
Overview ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Intelligent Traffic Control
▀ How it Works
How it Works
ITC enables you to configure traffic policing on a per-subscriber/per-flow basis with the potential to manipulate
Differentiated Services Code Points (DSCPs), queue redirection (for example, move traffic to a Best Effort (BE) classification), or drop profile traffic.
In flow-based traffic policies, policy modules interact with the system through a set of well defined entry points, provide access to a stream of system events, and permit the defined policies to implement functions such as access control decisions, QoS enforcement decisions, etc.
Traffic policing can be generally defined as policy: condition >> action
condition: Specifies the flow-parameters like source-address, destination-address, source-port, destination-port, protocol, etc. for ingress and/or egress packet.
action: Specifies a set of treatments for flow/packet when condition matches. Broadly these actions are based on:
Flow Classification: Each flow is classified separately on the basis of source-address, destinationaddress, source-port, destination-port, protocol, etc. for ingress and/or egress packet. After classification access-control allowed or denied by the system.
QoS Processing for individual flow and DSCP marking: Flow-based traffic policing is implemented by each flow separately for the traffic-policing algorithm. Each flow has its own bucket (burst-size) along with committed data rate and peak data rate. A Token Bucket Algorithm (a modified trTCM)
[RFC2698] is used to implement this flow-based QoS traffic policing feature.
Refer to the Traffic Policing and Shaping chapter for more information on Token Bucket Algorithm.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Intelligent Traffic Control
Configuring Flow-based Traffic Policing ▀
Configuring Flow-based Traffic Policing
Traffic Policing is configured on a per-subscriber basis for either locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
Flow-based traffic policy is configured on the system with the following building blocks:
Class Maps: The basic building block of a flow-based traffic policing. It is used to control over the packet classification.
Policy Maps: A more advanced building block for a flow-based traffic policing. It manages admission control based on the Class Maps and the corresponding flow treatment based on QoS traffic-police or QoS DSCP marking.
Policy Group: This is a set of one or more Policy Maps applied to a subscriber. it also resolves the conflict if a flow matches to multiple policies.
This section provides instructions for configuring traffic policies and assigning to local subscriber profiles on the system.
For information on how to configure subscriber profiles on a remote RADIUS server, refer to the StarentVSA and
StarentVSA1 dictionary descriptions in the AAA Interface Administration and Reference.
Important:
This section provides the minimum instruction set for configuring flow-based traffic policing on an
AGW service. Commands that configure additional properties are provided in the Command Line Interface Reference.
These instructions assume that you have already configured the system-level configuration as described in product administration guide.
To configure the flow-based traffic policing on an AGW service:
Step 1
Configure the traffic class maps on the system to support flow-based traffic policing by applying the example
configuration in the Configuring Class Maps section.
Step 2
Configure the policy maps with traffic class maps on the system to support flow-based traffic policing by applying the
example configuration in the Configuring Policy Maps section.
Step 3
Configure the policy group with policy maps on the system to support flow-based traffic policing by applying the
example configuration in the Configuring Policy Groups section.
Step 4
Associate the subscriber profile with policy group to enable flow-based traffic policing for subscriber by applying the
example configuration in the Configuring a Subscriber for Flow-based Traffic Policing section.
Step 5
Policing Configuration section.
Step 6
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Intelligent Traffic Control
▀ Configuring Flow-based Traffic Policing
Configuring Class Maps
This section describes how to configure Class Maps on the system to support Flow-based Traffic Policing.
Important:
In this mode classification match rules added sequentially with match command to form a Class-
Map. To change and/or delete or re-add a particular rule user must delete specific Class-Map and re-define it.
Notes:
is the name of the destination context in which you want to configure the flow-based traffic policing.
is the name of the traffic class to map with the flow for the flow-based traffic policing. A maximum of 32 class-maps can be configured in one context.
For description and variable values of these commands and keywords, refer to the Class-Map Configuration
Mode Commands chapter of the Command Line Interface Reference.
Configuring Policy Maps
This section provides information and instructions for configuring the policy maps on the system to support flow-based traffic policing.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Intelligent Traffic Control
Configuring Flow-based Traffic Policing ▀
Notes:
is the name of the destination context in which is configured during Class-Map configuration for flow-based traffic policing.
is the name of the traffic policy map you want to configure for the flow-based traffic policing. A maximum of 32 policy maps can be configured in one context.
is the name of the traffic class to map that you configured in Configuring Class Maps section for the flow-based traffic policing.
For description and variable values of these commands and keywords, refer to the Traffic Policy-Map
Configuration Mode Commands chapter of the Command Line Interface Reference.
Configuring Policy Groups
This section provides information and instructions for configuring the policy group in a context to support flow-based traffic policing.
OL-22983-01
Notes:
is the name of the destination context which is configured during Class-Map configuration for flow-based traffic policing.
is name of the traffic policy group of policy maps you want to configure for the flow-based traffic policing. A maximum of 32 policy groups can be configured in one context.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Intelligent Traffic Control
▀ Configuring Flow-based Traffic Policing
is name of the traffic policy you configured in Configuring Policy Maps section for the flow-based traffic policing. A maximum of 16 Policy Maps can be assigned in a Policy Group.
For description and variable values of these commands and keywords, refer to the Traffic Policy-Map
Configuration Mode Commands chapter of the Command Line Interface Reference.
Configuring a Subscriber for Flow-based Traffic Policing
This section provides information and instructions for configuring the subscriber for Flow-based Traffic Policing.
Notes:
is the name of the destination context configured during Class-Map configuration for flow-based traffic policing.
is the name of the subscriber profile you want to configure for the flow-based traffic policing.
is name of the traffic policy group you configured in Configuring Policy Groups section for the flow-based traffic policing. A maximum of 16 Policy groups can be assigned to a subscriber profile.
For description and variable values of these commands and keywords, refer to the Traffic Policy-Group
Configuration Mode Commands chapter of the Command Line Interface Reference.
Verifying Flow-based Traffic Policing Configuration
Step 1
Verify that your flow-based traffic policing is configured properly by entering the following command in Exec Mode:
The output of this command displays flow-based information for a subscriber session.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 17
Interchassis Session Recovery
This chapter provides information on configuring interchassis session recovery (ICSR). 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.interchassis session recovery.
This chapter discusses the following:
Configuring Interchassis Session Recovery (ICSR)
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Interchassis Session Recovery
▀ Overview
Overview
The interchassis session recovery feature provides the highest possible availability for continuous call processing without interrupting subscriber services. This is accomplished through the use of redundant chassis. The chassis are configured as primary and backup with one being active and one standby. Both chassis are connected to the same AAA server. A checkpoint duration timer is used to control when subscriber data is sent from the active chassis to the standby chassis. If the active chassis handling the call traffic goes out of service, the standby chassis transitions to the active state and continues processing the call traffic without interrupting the subscriber session. The chassis determines which is active through a propriety TCP-based connection called a redundancy link. This link is used to exchange Hello messages between the primary and backup chassis and must be maintained for proper system operation.
Important:
ICSR is supported on chassis configured for GGSN or HA services only.
Interchassis Communication
Chassis configured to support interchassis session recovery communicate using periodic Hello messages. These messages are sent by each chassis to notify the peer of its current state. The Hello message contains information about the chassis such as its configuration and priority. A dead interval is used to set a time limit for a Hello message to be received from the chassis‘ peer. If the standby chassis does not receive an Hello message from the active chassis within the dead interval, the standby chassis transitions to the active state. In situations where the redundancy link goes out of service, a priority scheme is used to determine which chassis processes the session. The following priority scheme is used: router identifier chassis priority
SPIO MAC address
Checkpoint Messages
Checkpoint messages are sent from the active chassis to the standby chassis. Checkpoint messages are sent at specific intervals and contain all the information needed to recreate the sessions on the standby chassis, if that chassis were to become active. Once a session exceeds the checkpoint duration, checkpoint data is collected on the session. The checkpoint parameter determines the amount of time a session must be active before it is included in the checkpoint message.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
Overview ▀
AAA Monitor
AAA servers are monitored using the authentication probe mechanism. AAA servers are considered up if the authentication-probe receives a valid response. AAA servers are considered down when the max-retries count specified in the configuration of the AAA server has been reached. The service-redundancy protocol will initiate a switchover when none of the configured AAA servers responds to an authentication probe. AAA probing is only be performed on the active chassis.
Important:
A switchover event caused by a AAA monitoring failure is non-revertible. If the newly active chassis fails to monitor the configured AAA servers it remains as the active chassis until either a manual switchover, or another non-AAA failure event causes the system to switchover.
BGP Interaction
The service-redundancy protocol implements non-revertible switchover behavior by using a mechanism to adjust the route modifier value for the advertised loopback/IP Pool routes. The initial value of the route modifier value is determined by the chassis configured role and is initialized to a value that is higher than a normal operational value.
This ensures that in the event of an SRP link failure and a SRP task failure that the correct chassis is still preferred in the routing domain. The Active and Standby chassis share the route modifier values they are currently using. When BGP advertises the loopback and ip pool routes, it converts the route modifier into an autonomous systems (AS) path prepend count. The Active chassis always has a lower route modifier, and thus prepends less to the AS-path attribute. This causes the route to be preferred in the routing domain. In the event that communication on the redundancy link is lost, and both chassis in the redundant pair are claiming to be Active. The previously Active chassis is still preferred since it is advertising a smaller AS-path into the BGP routing domain. The route modifier is incremented as switchover events occur. A threshold will be implemented to determine when the route modifier should be reset to its initial value to avoid rollover.
Requirements
ICSR configurations require the following:
Two chassis configured for the same service types- The services must be bound on an srp activated loopback interface.
Three contexts:
Redundancy - to configure the primary and backup chassis redundancy.
Source - AAA configuration the specified nas-ip-address must be the IP address of an interface bound to an HA or any core network service configured within the same context.
Destination - to configure monitoring and routing to the PDN.
AAA RADIUS server
Border Gateway Protocol (BGP) - ICSR uses the route modifier to determine the chassis priority.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Interchassis Session Recovery
▀ Overview
Important:
ICSR is a licensed feature. Be sure that each chassis has the appropriate license before using the procedures in this chapter. To do this, log in to both chassis and execute a command. Interchassis Session Recovery feature is listed as is not licensed, please contact your local sales representative.
. If the chassis
The following figure shows an ICSR network.
Figure 16. Interchassis Session Recovery Network Diagram
HA (Primary)
Wireless Network
BGP Router
AAA Server
BGP Peer Router
Internet
HA (Backup)
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
ICSR Operation
This section provides an operational flow for ICSR. The following figure shows an ICSR process flow.
ICSR Operation ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Interchassis Session Recovery
▀ ICSR Operation
Figure 17. ICSR Flow Diagram
Chassis #1
(Primary)
This is the current active chassis
State = Active
Chassis #2
(Backup)
This is the current inactive chassis.
State = Inactive
Hello messages passed between chassis
Session checkpoint message after call duration of 60 seconds
This chassis fails and stops sending hello messages
State = Active
Hello Message
State = Inactive
Hello Message
State = Inactive
Hello Message
State = Inactive
Dead Interval
(Default = 60 secs)
Backup chassis detects that the primary has not sent a hello within the dead-interval and initiates switchover from the inactive to the active state.
State = Active
Primary chassis recovers and begins sending hello messages
State = Inactive
Primary chassis receives hello message with backup chassis status of active and transitions to the inactive state.
State = Inactive
Hello Message
State = Inactive
Hello Message
State = Active
Backup chassis begins advertising the srp-activated loopback and pool routes into the routing domain, and AAA services are enabled.
Chassis begins taking calls.
State = Active
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
ICSR Operation ▀
Chassis Initialization
When the chassis are simultaneously initialized, they send Hello messages to their configured peer. The peer sends a response, establishes communication between the chassis, and messages are sent that contain configuration information.
Important:
If the chassis are GGSNs, the messages include the APN tables.
During initialization, if both chassis are misconfigured in the same mode - both active (primary) or both standby
(backup), then the chassis with the highest priority (highest number set with SRP ) becomes active and the other chassis becomes the standby.
If the chassis priorities are the same, the system compares the two MAC addresses and the chassis with the higher SPIO
MAC address becomes active. For example, if the chassis have MAC addresses of and
and
, the last 3 sets of octets (the first 3 sets are the vendor code) are compared. In this example, the
are compared from left to right. The first pair of octets in both MAC addresses are the same, so the next pairs are compared. Since the is lower than the , the chassis with the SPIO MAC address of
becomes active and the other chassis the standby.
Chassis Operation
This section describes how the chassis communicate, maintain subscriber sessions, and perform chassis switchover.
Chassis Communication
There is one chassis in the active state and one in the standby state. They both send Hello messages at each hello interval. Subscriber sessions that exceed the checkpoint session duration are included in checkpoint messages that are sent to the standby chassis. The checkpoint message contains subscriber session information so if the active chassis goes out of service, the backup chassis becomes active and is able to continue processing the subscriber sessions. Additional checkpoint messages occur at various intervals where subscriber session information is updated on the standby chassis.
Chassis Switchover
If the active chassis goes out of service the standby chassis continues to send Hello messages. If the standby chassis does not receive a response to the Hello messages within the dead interval, the standby chassis initiates a switchover.
During the switch over, the standby chassis begins advertising the srp-activated loopback and pool routes into the routing domain. Once the chassis becomes active, it continues to process existing AAA services, subscriber sessions that had checkpoint information, and is able to establish new subscriber sessions as well.
When the primary chassis is back in service it sends Hello messages to the configured peer. The peer sends a response, establishes communication between the chassis, and Hello messages are sent that contain configuration information.
The primary chassis receives an Hello message that shows the backup chassis state as active and the primary chassis becomes standby. The Hello message now continue to be sent to each peer and checkpoint information is now sent from the active chassis to the standby chassis at regular intervals.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Interchassis Session Recovery
▀ ICSR Operation
When chassis switchover occurs, the session timers are recovered. The MIP HA session recovery is recreated with the full lifetime to avoid potential loss of the session and the possibility that a renewal update was lost in the transient checkpoint update process.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
Configuring Interchassis Session Recovery (ICSR) ▀
Configuring Interchassis Session Recovery (ICSR)
Important:
The ICSR configuration must be the same on the primary and backup chassis. If each chassis has a different srp configuration, the session recovery feature does not function and sessions cannot be recovered when the active chassis goes out of service.
Important:
This section provides the minimum instruction set for configuring ICSR on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface
Reference.
Procedures described here assume the following:
The chassis have been installed and configured with core network services.
For more configuration information and instructions on configuring services, refer to the respective product
Administration Guide.
In addition, the IP address pools must be
AAA server is installed and configured.
.
For more configuration information and instructions on configuring the AAA server, refer to the AAA Interface
Administration and Reference.
BGP router installed and configured. See Routing for more information on configuring BGP services.
To configure the Interchassis Session Recovery on a primary and/or backup chassis:
Step 1
Service Redundancy Protocol (SRP) Context section.
Step 2
Step 3
Modify the destination context of core network service for ICSR by applying the example configuration in the
Modifying the Destination Context for ICSR section.
Step 4
Optional. Disable the bulk statistics collection on standby system by applying the example configuration in the
Disabling Bulk Statistics Collection on a Standby System section.
Step 5
Chassis Configuration section.
Step 6
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Interchassis Session Recovery
▀ Configuring Interchassis Session Recovery (ICSR)
Configuring the Service Redundancy Protocol (SRP) Context
To configure the system to work for interchassis session recovery:
Step 1
Create the chassis redundancy context and bind it to primary chassis IP address by applying the example configuration
in the Creating and Binding the SRP Context section.
Step 2
Configure the chassis redundancy context with priority, chassis mode, heart-beat interval, dead-interval and peer IP
address by applying the example configuration in the Configuring the SRP Context Parameters section.
Step 3
Configure the SRP context with interface parameters, like interface name, IP address and port number to communicate
section.
Step 4
Step 5
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Creating and Binding the SRP Context
Use the following example to create the SRP context bind it to primary chassis IP address:
Important:
ICSR is configured using two systems. Be sure to create the redundancy context on both systems.
CLI commands must be executed on both systems. Always make configuration changes on the primary system first. It would be a good idea to log on both chassis before continuing. Before starting this configuration, determine which system to configure as the primary and use that login session.
Notes:
ICSR should be configured and maintained in a separate context.
Be sure to bind the local IP address to the primary chassis. When configuring the backup chassis, be sure to bind the local IP address to the backup chassis.
Configuring the SRP Context Parameters
This configuration assign a chassis mode, priority, and configure the redundancy link between the primary and backup systems:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
Configuring Interchassis Session Recovery (ICSR) ▀
Important:
CLI commands must be executed on both systems. Always make configuration changes on the primary system first. It would be a good idea to log on both chassis before continuing.
Notes:
ICSR should be configured and maintained in a separate context.
When assigning the chassis mode on the backup chassis be sure to enter backup.
The priority is used to determine which chassis becomes active when the redundancy link goes out of service.
The higher priority chassis has the lower number. Be sure to assign different priorities to each chassis.
Be sure to use the backup chassis IP address as the peer to the primary chassis. Use the primary chassis IP address as the peer to the backup chassis.
The dead interval must be a higher value than the hello interval. The dead interval should be at least three times greater than the hello interval. For example, if the hello interval is 10, the dead interval should be at least 30.
System performance is severely impacted if the hello interval and dead interval are not set properly.
Configuring the SRP Context Interface Parameters
This procedure configures communication interface with IP address and port number for the SRP context to communicate with chassis:
Important:
CLI commands must be executed on both systems. Always make configuration changes on the primary system first. It would be a good idea to log on both chassis before continuing.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Interchassis Session Recovery
▀ Configuring Interchassis Session Recovery (ICSR)
Notes:
Verifying SRP Configuration
Step 1
Verify that your SRP contexts were created and configured properly by entering the following command in Exec Mode:
The output of this command given below is the sample output. In this example, a SRP context called configured and you can observe some parameters configured as default.
was
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
Configuring Interchassis Session Recovery (ICSR) ▀
Modifying the Source Context for ICSR
To modify the source context of core service:
Step 1
Add the Border Gateway Protocol (BGP) router AS-path and configure the HA IP address, neighbor IP address, remote
IP address in source context, where the core network service is configured, by applying the example configuration in the
Configuring BGP Router and HA Address section.
Step 2
Configure the service redundancy context with BGP neighbor context and IP address to monitor the BGP link activity
by applying the example configuration in the Configuring SRP Context for BGP section.
Step 3
Step 4
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Configuring BGP Router and HA Address
Use the following example to create the BGP context and network addresses.
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Configuring Interchassis Session Recovery (ICSR)
Source context is the context where core network service is configured.
Configuring SRP Context for BGP
Use the following example to configure the BGP context and IP addresses in SRP context.
Interchassis Session Recovery
Notes:
Verifying BGP Configuration
Step 1
Verify your BGP configuration by entering the following command in Exec Mode:
Modifying the Destination Context for ICSR
To modify the destination context of core service:
Step 1
Add the Border Gateway Protocol (BGP) router and configure the HA IP address, neighbor IP address, remote IP address in destination context, where the core network service is configured, by applying the example configuration in
the Configuring BGP Router and HA Address in Destination Context section.
Step 2
Configure the service redundancy context with BGP neighbor context and IP address to monitor the BGP link activity
Step 3
Step 4
Step 5
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
Configuring BGP Router and HA Address in Destination Context
Use the following example to create the BGP context and network addresses.
Configuring Interchassis Session Recovery (ICSR) ▀
Notes:
AS-path number is the autonomous systems path number for this BGP router.
Configuring SRP Context for BGP for Destination Context
Use the following example to configure the BGP context and IP addresses in SRP context.
Notes:
Setting Subscriber to Default Mode
Use the following example to set the subscriber mode to Default.
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Interchassis Session Recovery
▀ Configuring Interchassis Session Recovery (ICSR)
Verifying BGP Configuration in Destination Context
Step 1
Verify your BGP configuration by entering the following command in Exec Mode:
Disabling Bulk Statistics Collection on a Standby System
You can optionally configure bulk statistics not to be collected from a system when it is in the standby mode of operation.
Important:
When this feature is enabled and a system transitions to standby state any pending accumulated statistics data is transferred at the first opportunity. After that no additional statistics gathering takes place until the system comes out of standby state.
Use the following example to disable the bulk statistics collection on a standby system.
Notes:
Repeat this procedure for both systems.
Verifying the Primary and Backup Chassis Configuration
These instructions are used to compare the ICSR configuration on both chassis.
Step 1
Enter the following command on both chassis at the Exec mode:
Verify that both chassis have the same srp configuration information. The output looks similar to following:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Interchassis Session Recovery
Configuring Interchassis Session Recovery (ICSR) ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 18
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 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
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Header Compression
▀ Overview
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Configuring VJ Header Compression for PPP ▀
Configuring VJ Header Compression for PPP
By default, VJ IP header compression is enabled for subscriber sessions. When VJ header compression is configured all
IP headers are compressed using the VJ compression algorithm.
Note that procedure described in this section is applicable only when VJ header compression is disabled.
Important:
This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to enable VJ header compression to IP headers:
Step 1
Step 2
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:
Notes:
< > is the system context in which you wish to configure the subscriber profile. Typically this is an
AAA context.
< > is the name of the subscriber in the current context that you want to enable VJ IP header compression for.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Header Compression
▀ Configuring VJ Header Compression for PPP
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:
The output of this command is a concise listing of subscriber parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Configuring RoHC Header Compression for PPP ▀
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 Command Line Interface Reference.
To configure the system to enable RoHC header compression to IP headers:
Step 1
Step 2
Step 3
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:
OL-22983-01
Notes:
< > is the system context in which you wish to configure the subscriber profile. Typically this is an
AAA context.
< > is the name of the subscriber in the current context that you want to enable RoHC header compression for.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Header Compression
▀ Configuring RoHC Header Compression for PPP
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:
The output of this command is a concise listing of subscriber parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Configuring Both RoHC and VJ Header Compression ▀
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 Command Line Interface Reference.
To configure the system to enable both RoHC and VJ header compression to IP headers:
Step 1
Header Compression for PPP section.
Step 2
Compression Configuration section.
Step 3
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:
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Header Compression
▀ Configuring Both RoHC and VJ Header Compression
< > is the system context in which you wish to configure the subscriber profile. Typically this is an
AAA context.
< > 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.
Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:
The output of this command is a concise listing of subscriber parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Configuring RoHC for Use with SO67 in PDSN Service ▀
Configuring RoHC for Use with SO67 in PDSN Service
This section explains how to set RoHC settings in the PDSN 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 chapter in Command Line Interface Reference.
To configure the system to disable the RoHC header compression feature at the PDSN Service over SO67:
Step 1
Step 2
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 disable the RoHC header compression with PDSN over SO67:
OL-22983-01
Notes:
< > is the system context in which PDSN service is configured and you wish to configure the service profile.
< > is the name of the PDSN service in which you want to enable RoHC over SO67.
Refer to the PDSN Service RoHC Configuration Mode Commands chapter in Command Line Interface
Reference for more details on this command and its options.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Header Compression
▀ Configuring RoHC for Use with SO67 in PDSN Service
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:
The output of this command is a concise listing of subscriber parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Using an RoHC Profile for Subscriber Sessions ▀
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 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
Step 3
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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Header Compression
▀ Using an RoHC Profile for Subscriber Sessions
Notes:
< apply to a subscriber.
> is the name of the RoHC profile with compression mode which you want to
System configured most of the parameters by default. For more information on other options and parameters and details, refer to the RoHC Profile Compression Configuration Mode Commands chapter in Command Line
Interface Reference.
Creating RoHC Profile for Subscriber using Decompression Mode
Use the following example to create RoHC profile for a subscriber using decompression mode:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Using an RoHC Profile for Subscriber Sessions ▀
Notes:
< to a subscriber.
> is the name of the RoHC profile with decompression mode which you want to apply
System configured most of the parameters by default. For more information on other options and parameters and details, refer to the RoHC Profile Decompression Configuration Mode Commands chapter in Command Line
Interface Reference.
Applying RoHC Profile to a Subscriber
Once an RoHC profile has been created that profile can be specified to be used for a specific subscribers. Use the following example to apply the RoHC profile to a subscriber:
Notes:
< > is the system context in which you wish to configure the subscriber profile. Typically this is an
AAA context.
< > is the name of the subscriber in the current context that you want to enable RoHC header compression for.
< > is the name of the existing RoHC profile (created with compressed or decompressed mode) which you want to apply to a subscriber in the current context.
Refer to the Subscriber Configuration Mode Commands chapter in Command Line Interface Reference for more details on this command and its options.
Verifying the Header Compression Configuration
These instructions are used to verify the header compression configuration.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Header Compression
▀ Using an RoHC Profile for Subscriber Sessions
Step 1
Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:
The output of this command is a concise listing of subscriber parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Disabling VJ Header Compression Over PPP ▀
Disabling VJ Header Compression Over PPP
By default, VJ IP header compression is enabled for subscriber sessions. When VJ header compression is configured all
IP headers are compressed using the VJ compression algorithm.
If you do not want to apply compression to any IP headers for a subscriber session you can disable the IP header compression feature.
Important:
This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber
Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to disable VJ header compression to IP headers:
Step 1
Step 2
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:
Notes:
< > is the system context in which you wish to configure the subscriber profile. Typically this is an
AAA context.
< > is the name of the subscriber in the current context that you want to disable IP header compression for.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Header Compression
▀ Disabling VJ Header Compression Over PPP
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:
The output of this command is a concise listing of subscriber parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Disabling RoHC Header Compression Over SO67 ▀
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 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 chapter in Command Line Interface Reference.
To configure the system to disable the IP header compression feature at the PDSN Service:
Step 1
section.
Step 2
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 PPP:
Notes:
< > is the system context in which PDSN service is configured and you wish to configure the service profile.
< > is the name of the PDSN 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Header Compression
▀ Disabling RoHC Header Compression Over SO67
•
Verify that your header compression configurations for subscriber by entering the following command in Exec Mode in specific context:
The output of this command is a concise listing of subscriber parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Header Compression
Checking IP Header Compression Statistics ▀
Checking IP Header Compression Statistics
This section commands to use to retrieve statistics that include IP header compression information.
The following Exec mode commands can be used to retrieve IP header compression statistics: monitor protocol ppp show ppp show ppp statistics show RoHC statistics show RoHC statistics pdsn-service show subscriber full username
For more information on these commands, refer to the Command Line Interface Reference.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Header Compression
▀ RADIUS Attributes for IP Header Compression
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 19
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:
Configuring IPSP Before the Software Upgrade
Configuring IPSP After the Software Upgrade
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Pool Sharing Protocol
▀ Overview
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 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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Pool Sharing Protocol
Overview ▀
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
command), it notifies the For graceful termination conditions (e.g. an administrative user issues 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Pool Sharing Protocol
▀ How IPSP Works
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 reregistered 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Pool Sharing Protocol
Figure 18. IPSP Operation for New Sessions
How IPSP Works ▀
MN AAA
HA1 HA2
1
2
3
4
5
7
8
Table 12. 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ How IPSP Works
IPSP Operation for Session Handoffs
The following figure and text describe how session handoffs are handled when IPSP is enabled.
Figure 19. IPSP Operation for Session Handoffs
IP Pool Sharing Protocol
MN AAA
HA1 HA2
1
2
3
4
5
7
8
9
Table 13. 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Pool Sharing Protocol
Step Description
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.
How IPSP Works ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Pool Sharing Protocol
▀ Configuring IPSP Before the Software Upgrade
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
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
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
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Pool Sharing Protocol
Configuring IPSP Before the Software Upgrade ▀
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:
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.
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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Pool Sharing Protocol
▀ Configuring IPSP Before the Software Upgrade
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.
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.
Step 1
Verify that IPSP has released all IP addresses by entering the following command in Exec Mode with in specific context:
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Pool Sharing Protocol
Configuring IPSP After the Software Upgrade ▀
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
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
section.
Step 4
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Pool Sharing Protocol
▀ Disabling IPSP
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:
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.
is the name of the interface on which you want to disable IPSP.
IPSP must be disabled on both the HAs.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 20
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.
OL-22983-01
Caution:
IPSec parameter configurations saved using this release may not function properly with older software releases.
This chapter contains the following sections:
Implementing IPSec for PDN Access Applications
Implementing IPSec for Mobile IP Applications
Implementing IPSec for L2TP Applications
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
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Disabling IPSP
APN Template Configuration to Support L2TP
IP Security
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Overview ▀
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.
Figure 20. IPSec Applications
PDN Access
Application
Core service or HA
IPSec Tunnel
Security
Gateway
Packet Data Network
Mobile IP
Application
Core service/FA
IPSec Tunnel
HA
L2TP
Application
IPSec Tunnel
Core service/LAC
HA/LAC
LNS/Security
Gateway
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Overview
Note that: IPSec can be implemented for both attribute-based and compulsory tunneling applications for 3GPP2 services.
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
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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Applicable Product(s) Refer to Sections
GGSN/FA/HA
Implementing IPSec for PDN Access Applications
Implementing IPSec for Mobile IP Applications
Implementing IPSec for L2TP Applications
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
Overview ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Overview
Applicable Product(s) Refer to Sections
ASN GW
Implementing IPSec for PDN Access Applications
Implementing IPSec for Mobile IP Applications
Implementing IPSec for L2TP Applications
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
IP Security
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
IPSec Terminology ▀
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ IPSec Terminology
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
IPSec Terminology ▀
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).
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ Implementing IPSec for PDN Access Applications
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.
Figure 21. IPSec PDN Access Processing
6 7 8
1
IPSec Tunnel
9
Packet Data
Network
Security
Gateway
Core service or
HA
3
Crypto ACL
Transform
Set(s)
Services
ISAKMP
Policy(ies)
4
ISAKMP
Crypto
Map
Source Ctx.
5
2
Destination
Ctx.
Local Ctx.
P
D
N
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
Context
(Ctx.)
Interface
Service or
Configuration
(Cfg.
OL-22983-01
IP Security
Implementing IPSec for PDN Access Applications ▀
Table 14. IPSec PDN Access Processing
Step Description
1. A subscriber session or PDP context Request, in GGSN service, arrives at the system.
2.
3.
4.
5.
The system processes the subscriber session or request as it would typically.
Prior to routing the session packets, the system compares them against configured Access Control Lists (ACLs).
The system determines that the packet matches the criteria of an ACL that is associated with a configured crypto map.
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.
7.
8.
9.
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.
The system and the security gateway negotiate an ISAKMP policy (IKE SA) to use to protect further communications.
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.
Once the IPSec SA has been negotiated, the system protects the data according to the IPSec SAs established during step 8 and sends it over the IPSec tunnel.
Configuring IPSec Support for PDN Access
This section provides a list of the steps required to configure IPSec functionality on the system in support of PDN access. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important:
These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA. In addition, parameters configured using this procedure must be configured in the same destination context on the system.
Step 1
Configure one or more IP access control lists (ACLs) according to the information and instructions located in IP Access
Control Lists chapter of this guide.
Step 2
of this chapter.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Implementing IPSec for PDN Access Applications
Step 3
section of this chapter.
Step 4
section of this chapter.
Step 5
Interface Association section of this chapter.
Step 6
Save your configuration as described in Verifying and Saving Your Configuration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Implementing IPSec for Mobile IP Applications ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Implementing IPSec for Mobile IP Applications
Figure 22. IPSec-based Mobile IP Session Processing
Foreign
AAA Server
3
Proxy AAA
2 5
8
13
14 15
IPSec Tunnel
16
Core service/
FA
4
Home
AAA Server
9 10
HA
IP Security
AAA
AAA Cfg.
AAA Ctx.
7
Transform
Set(s)
ISAKMP
Policy(ies)
Crypto Map
6
Services
FA-
Service
Pi/
R3
1
Source Ctx.
MIP Dest.
Ctx.
Local Ctx.
Table 15. IPSec-based Mobile IP Session Processing
Step Description
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
Pi/
R3
AAA
AAA Cfg.
Transform
Set(s)
ISAKMP
Policy(ies)
Crypto Map
FA-
Service
Source Ctx.
12
P
D
N
11
Destination
Ctx.
Local Ctx.
OL-22983-01
IP Security
Implementing IPSec for Mobile IP Applications ▀
Step Description
1.
2.
3.
FA service receives a Mobile IP registration request from the mobile node.
FA sends an Access-Request to the FAAA server with the 3GPP2-IKE-Secret-Request attribute equal to yes.
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.
6.
7.
The FAAA passes the accept message to the FA with all of the attributes.
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.
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 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)
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Implementing IPSec for Mobile IP Applications
Step Description
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 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
Configuration section of this chapter.
The transform set(s) must be configured in the same context as the FA service.
Step 2
Configuration section of this chapter.
The ISAKMP policy(ies) must be configured in the same context as the FA service.
Step 3
Map Configuration section of this chapter.
The crypto map(s) must be configured in the same context as the FA service.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Implementing IPSec for Mobile IP Applications ▀
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
Support IPSec section of this chapter.
Step 6
Configuration section of this chapter.
The transform set(s) must be configured in the same context as the HA service.
Step 7
Configuration section of this chapter.
The ISAKMP policy(ies) must be configured in the same context as the HA service.
Step 8
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.
Attributes for IPSec-based Mobile IP Applications section of this chapter.
Step 12 Save your configuration as described in Verifying and Saving Your Configuration.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Implementing IPSec for L2TP Applications
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.
IP Security
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Figure 23. Attribute-based L2TP, IPSec-Encrypted Session Processing
AAA Server
Implementing IPSec for L2TP Applications ▀
1
2 3
6 7 8
LNS/Security
Gateway
IPSec Tunnel
9
PDSN or
HA
AAA
AAA Cfg.
Transform
Set(s)
PDSN or HA
Service
5
4
ISAKMP
Policy(ies)
Crypto Map
Source
Ctx.
Local Ctx.
LAC
Service
P
D
N
Destination
Ctx.
Table 16. Attribute-based L2TP, IPSec-Encrypted Session Processing
Step Description
1.
2.
3.
4.
A subscriber session arrives at the system.
The system attempts to authenticate the subscriber with the AAA server.
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.
The system determines that the crypto map name supplied matches a configured crypto map.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Implementing IPSec for L2TP Applications
Step Description
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.
7.
8.
9.
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.
The system and the LNS/security gateway negotiate an ISAKMP (IKE) policy to use to protect further communications.
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.
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 attributebased 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
of this chapter.
Step 2
section of this chapter.
Step 3
section of this chapter.
Step 4
Application IPSec Support section of this chapter.
Step 5
Save your configuration as described in Verifying and Saving Your Configuration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Implementing IPSec for L2TP Applications ▀
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.
Figure 24. PDSN Compulsory L2TP, IPSec-Encrypted Session Processing
5 6 7
LNS/Security
Gateway
1
IPSec Tunnel
8
PDSN
R
P
AAA
AAA Cfg.
Transform
Set(s)
4
ISAKMP
Policy(ies)
PDSN-
Service
3
Crypto Map
Source
Ctx.
2
LAC
Service
P
D
N
Local Ctx.
Destination
Ctx.
Table 17. PDSN Compulsory L2TP, IPSec-Encrypted Session Processing
Step Description
1.
2.
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.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Implementing IPSec for L2TP Applications
Step Description
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.
6.
7.
8.
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.
The system and the LNS/security gateway negotiate an ISAKMP policy (IKE SA) to use to protect further communications.
Once the IKE SA has been negotiated, the system negotiates an IPSec SA with the LNS/security gateway.
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
of this chapter.
Step 2
section of this chapter.
Step 3
section of this chapter.
Step 4
Application IPSec Support section of this chapter.
Step 5
Save your configuration as described in Verifying and Saving Your Configuration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Implementing IPSec for L2TP Applications ▀
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.
Figure 25. GGSN PDP Context Processing with IPSec-Encrypted L2TP
6 7 8
1
IPSec Tunnel
9
GGSN
LNS/Security
Gateway
G a
G n
Source
Ctx.
GTPP
Cfg.
Net. Req.
PDP Ctx.
Cfg.
GGSN-
Service
4
5
2
3
Dest. Ctx.
Auth. Cfg.
AAA
DHCP
Cfg.
DHCP
Crypto Map
Transform
Set(s)
ISAKMP
Policy(ies)
LAC
Service
APN Cfg.
Gi
IP Address
Pool Cfg.
Table 18. GGSN PDP Context Processing with IPSec-Encrypted L2TP
Step Description
1.
2.
3.
A subscriber session/PDP Context Request arrives at the system.
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.
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
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Implementing IPSec for L2TP Applications
Step Description
5.
6.
7.
8.
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.
The system and the LNS/security gateway negotiate an ISAKMP (IKE) policy to use to protect further communications.
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.
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
of this chapter.
Step 2
section of this chapter.
Step 3
section of this chapter.
Step 4
Template Configuration to Support L2TP section of this chapter.
Step 5
Save your configuration as described in Verifying and Saving Your Configuration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Transform Set 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
Step 2
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:
Notes:
< > is the system context in which you wish to create and configure the crypto transform set(s).
< > 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Transform Set Configuration
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:
This command produces an output similar to that displayed below using the configuration of a transform set named test1.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
ISAKMP Policy Configuration ▀
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
Step 2
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:
OL-22983-01
Notes:
<
<
> is the system context in which you wish to create and configure the ISAKMP policy.
> dictates the order in which the ISAKMP policies are proposed when negotiating IKE SAs.
For more information on parameters, refer to the ISAKMP Configuration Mode Commands chapter in the
Command Line Interface Reference.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ ISAKMP Policy Configuration
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:
This command produces an output similar to that displayed below that displays the configuration of an ISAKMP policy with priority 1.
Caution:
Modification(s) to an existing ISAKMP policy configuration will not take effect until the related security association has been cleared. Refer to the command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
ISAKMP Crypto Map Configuration ▀
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
section.
Step 2
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:
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ ISAKMP Crypto Map Configuration
<
<
> is the system context in which you wish to create and configure the ISAKMP crypto maps.
> is name by which the ISAKMP crypto map will be recognized by the system.
< > 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.
< > is name of the Crypto group configured in the same context. It is used for configurations using
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:
This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map2.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
ISAKMP Crypto Map Configuration ▀
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 command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ Dynamic Crypto Map Configuration
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
section.
Step 2
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:
Notes:
<
<
> is the system context in which you wish to create and configure the dynamic crypto maps.
> 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Dynamic Crypto Map Configuration ▀
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:
This command produces an output similar to that displayed below using the configuration of a dynamic crypto map named test_map3.
OL-22983-01
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
command located in the Exec Mode Commands chapter of the Command Line Interface
Reference for more information.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ Manual Crypto Map Configuration
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
Step 2
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:
Notes:
< > is the system context in which you wish to create and configure the manual crypto maps.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Manual Crypto Map Configuration ▀
< > is name by which the manual crypto map will be recognized by the system.
< > 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.
< > 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:
This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ Manual Crypto Map Configuration
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 command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Crypto Map and Interface Association ▀
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
section
Step 3
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:
OL-22983-01
Notes:
<
< be applied.
> is the system context in which the interface is configured to apply crypto map.
> is the name of a specific interface configured in the context to which the crypto map will
< > is name of the preconfigured ISAKMP or a manual crypot map.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ Crypto Map and Interface Association
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:
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
FA Services Configuration to Support IPSec ▀
FA Services Configuration to Support IPSec
This section provides instructions for configuring FA services to support IPSec.
These instructions assume that the FA service was previously configured and system is ready to serve as an FA.
Important:
This section provides the minimum instruction set for configuring an FA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command
Line Interface Reference.
To configure the FA service to support IPSec:
Step 1
Step 2
section.
Step 3
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:
OL-22983-01
Notes:
<
<
> is the system context in which the FA service is configured to support IPSec.
> is name of the FA service for which you are configuring IPSec.
<
<
> is IP address of the HA service to which FA service will communicate on IPSec.
> is name of the preconfigured ISAKMP or a manual crypot 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ FA Services Configuration to Support IPSec
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:
The output of this command is a concise listing of FA service parameter settings configured on the system.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
HA Service Configuration to Support IPSec ▀
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
Step 2
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:
OL-22983-01
Notes:
<
<
> is the system context in which the FA service is configured to support IPSec.
> is name of the HA service for which you are configuring IPSec.
< > is IP address of the FA service to which HA service will communicate on IPSec.
< > name of the context through which the HA service accesses the HAAA server to fetch the
IKE S Key and S Lifetime parameters.
< > is name of the preconfigured ISAKMP or a manual crypot map.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ HA Service Configuration to Support IPSec
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:
The output of this command is a concise listing of HA service parameter settings configured on the system.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
RADIUS Attributes for IPSec-based Mobile IP Applications ▀
RADIUS Attributes for IPSec-based Mobile IP Applications
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
Table 19. Attributes Used for Mobile IP IPSec Support
Attribute
3GPP2-
Security-
Level
3GPP2 -
KeyId
3GPP2-IKE-
Secret
3GPP2-S
3GPP2- S-
Lifetime
Description
This attribute indicates the type of security that the home network mandates on the visited network.
This attribute contains the opaque IKE
Key Identifier for the FA/HA shared IKE secret.
Variable
Integer value:
3 : Enables IPSec for tunnels and registration messages
4 : Disables IPSec
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.
A binary string of 1 to 127 bytes. This attribute contains the FA/HA shared secret for the IKE protocol. This attribute is salt-encrypted.
This attribute contains the 'S' secret parameter used to make the IKE preshared secret.
This attribute contains the lifetime of 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.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ LAC Service Configuration to Support IPSec
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
Step 2
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:
Notes:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
LAC Service Configuration to Support IPSec ▀
<
<
> is the destination context where the LAC service is configured to support IPSec.
> is name of the LAC service for which you are configuring IPSec.
< > is IP address of the LNS node to which LAC service will communicate on IPSec.
< > name of the context through which the HA service accesses the HAAA server to fetch the
IKE S Key and S Lifetime parameters.
< > 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:
The output of this command is a concise listing of LAC service parameter settings configured on the system.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ Subscriber Attributes for L2TP Application IPSec Support
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
Table 20. Subscriber Attributes for IPSec encrypted L2TP Support
RADIUS Attribute Local
SubscriberAttribute
SN1-Tunnel-
ISAKMP-
Crypto-Map
Description
tunnel l2tp crypto-map The name of a crypto map configured on the system.
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.
Variable
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.
A salt-encrypted string specifying the IKE secret. It can be tagged, in which case it is treated as part of a tunnel group.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
PDSN Service Configuration for L2TP Support ▀
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 attributebased 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
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:
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ PDSN Service Configuration for L2TP Support
<
< tunneling.
<
> is the destination context where the PDSN service is configured.
> is name of the PDSN service for which you are configuring attribute-based L2TP
> 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:
Notes:
<
< tunneling.
<
> is the destination context where the PDSN service is configured.
> is name of the PDSN service for which you are configuring attribute-based L2TP
> 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:
The output of this command is a concise listing of PDSN service parameter settings configured on the system.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Redundant IPSec Tunnel Fail-Over ▀
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-tosecondary 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
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Redundant IPSec Tunnel Fail-Over
IP Security
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Redundant IPSec Tunnel Fail-over Configuration ▀
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
section of this chapter.
Step 3
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
Configuration to Match Crypto Group section
Step 6
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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
IP Security
▀ Redundant IPSec Tunnel Fail-over Configuration
Notes:
<
<
> is the destination context where the Crypto Group is to be configured.
> is name of the Crypto group you want to configure for IPSec tunnel failover support.
< > 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:
Notes:
<
<
<
<
> is the system context in which you wish to create and configure the ISAKMP crypto maps.
> is name of the Crypto group configured in the same context for IPSec Tunnel Failover feature.
> is name of the preconfigured ISAKMP crypto map to match with crypto group as primary.
> is name of the preconfigured ISAKMP crypto map to match with crypto group as secondary.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Redundant IPSec Tunnel Fail-over Configuration ▀
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:
The output of this command is a concise listing of crypto group parameter settings configured on the system.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ Dead Peer Detection (DPD) Configuration
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
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
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
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:
Notes:
< > is the destination context where the Crypto Group is to be configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
Dead Peer Detection (DPD) Configuration ▀
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:
The output of this command is a concise listing of crypto group parameter settings configured on the system.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
IP Security
▀ APN Template Configuration to Support L2TP
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
Step 2
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:
Notes:
<
<
<
<
<
<
> is the system context in which the APN template is configured.
> is name of the preconfigured APN template in which you want to configure L2TP support.
> is IP address of the LNS node to which this APN will communicate.
> is the L2TP context in which the L2TP tunnel is configured.
> is the local IP address of the GGSN in which this APN template is configured.
> is the preconfigured crypto map (ISAKMP or manual) which is to use for L2TP.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
IP Security
APN Template Configuration to Support 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:
The output of this command is a concise listing of FA service parameter settings configured on the system.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 21
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Access Concentrator
▀ L2TP Session and Tunnel Capacities
L2TP Session and Tunnel Capacities
The system is capable of supporting L2TP tunnels for all subscriber sessions or on a session-by-session basis.
Each L2TP tunnel can facilitate one or more subscriber sessions. The number of supported L2TP sessions and tunnels corresponds to the number of active Packet Accelerator Cards (PACs) or Packet Services Cards (PSCs)
The following tables lists PDSN Simple IP tunnel and session capacities for the ST16 and ASR 5000 respectively.
Important:
The capacities stated in this section are the maximum supported by the components. Actual capacities are dependent upon hardware and software configurations.
Table 21. L2TP LAC Tunnel and Session Capacity per ST16 for PDSN Simple IP
Capacity/PAC Capacity/Full System1 Minimum # of LAC services Required2
Tunnels
Sessions
Transactions/Second
32,000
40,000
4003
32,000
500,000
40004
1
1
N/A
1. A full system consists of 13 active PACs.
2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
3. Transactions include PPP and LAC
4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.
Table 22. L2TP LAC Tunnel and Session Capacity per ASR 5000 for PDSN Simple IP
Capacity/PSC Capacity/Full System1 Minimum # of LAC services Required2
Tunnels
Sessions
32,000
120,000
32,000
1,500,000
1
1
Transactions/Second 8003
1. A full system consists of 13 active PSCs.
10,0004 N/A
2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
3. Transactions include PPP and LAC
4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.
The following table lists HA tunnel and session capacities for the ST16 and ASR 5000 respectively.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
L2TP Session and Tunnel Capacities ▀
Table 23. L2TP LAC Tunnel and Session Capacity per ST16 for HA
Tunnels
Capacity/PAC
32,000
Capacity/Full System1
32,000
Minimum # of LAC services Required2
1
Sessions
Transactions/Second
25,000
2503
300,000
30004
1
N/A
1. A full system consists of 13 active PACs.
2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
3. Transactions include PPP and LAC
4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.
Table 24. L2TP LAC Tunnel and Session Capacity per ASR 5000 for HA
Tunnels
Capacity/PSC
32,000
Capacity/Full System1
32,000
Minimum # of LAC services Required2
1
Sessions
Transactions/Second
83,000
5003
1,000,000
6,0004
1
N/A
1. A full system consists of 13 active PSCs.
2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
3. Transactions include PPP and LAC
4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
L2TP Access Concentrator
▀ Applicable Products and Relevant Sections
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.
Refer to Sections Applicable
Product(s)
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
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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Supported LAC Service Configurations for PDSN Simple IP ▀
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.
Figure 26. LAC Service Configuration for SIP
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Access Concentrator
▀ Supported LAC Service Configurations for PDSN Simple IP
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.
Figure 27. 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Supported LAC Service Configurations for PDSN Simple IP ▀
6. The encapsulated packets are sent to the peer LNS through the packet data network where they will be unencapsulated.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Supported LAC Service Configurations for PDSN Simple IP
Figure 28. PDSN Service-based Compulsory Tunneling Session Processing
L2TP Access Concentrator
1. A subscriber session from the PCF is received by the PDSN service over the R-P interface.
2. The PDSN service detects its tunnel-type parameter is configured to L2TP and its tunnel-context parameter is configured to the Destination context.
3. 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.
4. The LAC service initiates an L2TP tunnel to one of the LNS peers listed as part of its configuration.
5. Session packets are passed to the LNS over a packet data network for authentication.
6. The LNS authenticates the session and returns an Access-Accept to the PDSN.
7. 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Supported LAC Service Configurations for PDSN Simple IP ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Access Concentrator
▀ Supported LAC Service Configurations for the GGSN
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.
Figure 29. 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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Supported LAC Service Configurations for the GGSN ▀
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.
Figure 30. 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
L2TP Access Concentrator
▀ Supported LAC Service Configurations for the GGSN
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.
Figure 31. Non-transparent IP PDP Context Call Processing with L2TP Tunneling
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Supported LAC Service Configurations for the GGSN ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Supported LAC Service Configurations for the GGSN
Figure 32. PPP PDP Context Call Processing with L2TP Tunneling
L2TP Access Concentrator
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Supported LAC Service Configurations for the GGSN ▀
Important:
These instructions assume that the system was previously configured to support subscriber data sessions as a GGSN.
Step 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.
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Access Concentrator
▀ Supported LAC Service Configuration for Mobile IP
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.
Figure 33. 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Figure 34. Attribute-based L2TP Session Processing for MIP
Supported LAC Service Configuration for Mobile IP ▀
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 unencapsulated.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
L2TP Access Concentrator
▀ Supported LAC Service Configuration for Mobile IP
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Configuring Subscriber Profiles for L2TP Support ▀
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
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.
Table 25. Subscriber Attributes for L2TP Support
RADIUS
Attribute
Local
Subscriber
Attribute
Tunnel-Type tunnel l2tp
Tunnel-
Server-
Endpoint
Tunnel-
Password tunnel l2tp peer-address
Specifies the type of tunnel to be used for the subscriber session
Specifies the IP address of the peer LNS to connect tunnel to.
L2TP
IPv4 address in dotted-decimal format, enclosed in quotation marks tunnel l2tp secret
Description
Specifies the shared secret between the LAC and
LNS.
Variable
Alpha and or numeric string from 1 to 63 characters, enclosed in quotation marks
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
L2TP Access Concentrator
▀ Configuring Subscriber Profiles for L2TP Support
RADIUS
Attribute
Tunnel-
Private-
Group-ID
Local
Subscriber
Attribute
tunnel l2tp tunnel-context
Description
Specifies the name of the destination context configured on the system in which the LAC service(s) to be used are located.
Tunnel-
Preference tunnel l2tp preference
Variable
Alpha and or numeric string from 1 to 63 characters, enclosed in quotation marks
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.
Configures the priority of each peer LNS when multiple LNS nodes are configured.
Integer from 1 to 65535
SN-Tunnel-
Load-
Balancing
Client-
Endpoint loadbalancetunnel- peer
Important:
This attribute is only used when the loadbalance-tunnel-
peers parameter or SN-Tunnel-Load-
Balancing attribute configured to prioritized.
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. 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)
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Configuring Subscriber Profiles for L2TP Support ▀
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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
L2TP Access Concentrator
▀ Configuring Subscriber Profiles for L2TP Support
Notes:
<
<
> is the system context in which you wish to configure the subscriber profile.
> is the IP address of LNS server node and < system which is bound to LAC service.
> is the IP address of
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:
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Configuring LAC Services ▀
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:
OL-22983-01
Notes:
< > is the destination context where you want to configure the LAC service.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Access Concentrator
▀ Configuring LAC Services
Configuring LNS Peer
Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
Notes:
< > 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:
The output given below is a concise listing of LAC service parameter settings as configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Configuring LAC Services ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Access Concentrator
▀ Modifying PDSN Services for L2TP Support
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 attributebased 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:
Notes:
< > is the name of the source context containing the PDSN service, which you want to modify for L2TP support.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Modifying PDSN Services for L2TP Support ▀
<
L2TP support.
<
> is the name of the pre-configured PDSN service, which you want to modify for
> 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:
The output of this command is a concise listing of PDSN service parameter settings as configured.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Access Concentrator
▀ Modifying APN Templates to Support L2TP
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:
Notes:
<
<
> is the name of system destination context in which the APN is configured.
> is the name of the pre-configured APN template which you want to modify for the L2TP support.
< > is the IP address of LNS server node and < system which is bound to LAC service.
> is the IP address of
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Access Concentrator
Modifying APN Templates to Support L2TP ▀
Configuring Outbound Authentication
Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
Notes:
<
<
> is the destination context where APN template is is configured.
> 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:
The output is a concise listing of APN parameter settings as configured.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 22
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
LNS service configuration mode command. Refer to the Command Line Interface Reference for more information on this command.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Network Server
▀ L2TP LNS Session and Tunnel Capacities
L2TP LNS Session and Tunnel Capacities
The system is capable of supporting L2TP tunnels for all subscriber sessions or on a session-by-session basis.
Each L2TP tunnel can facilitate one or more subscriber sessions. The number of supported L2TP sessions and tunnels corresponds to the number of active Packet Accelerator Cards (PACs) or Packet Services Cards (PSCs) available to the system.
The following table lists tunnel and session capacities for the ST16,
Table 26. L2TP LNS Tunnel and Session Capacity per ST16
Tunnels
Capacity/PAC
32,000
Capacity/Full System1
32,000
Minimum # of LNS services Required2
1
Sessions
Transactions/Second
40,000
5003
500,000
6,0004
1
N/A
1. A full system consists of 13 active PACs.
2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
3. Transactions include PPP and LNS.
4. Transactions include PPP and LNS session setup assuming that a tunnel already exists.
Table 27. L2TP LNS Tunnel and Session Capacity per ASR 5000
Tunnels
Capacity/PSC
32,000
Sessions
Transactions/Second
125,000
8003
1. A full system consists of 13 active PSCs.
Capacity/Full System1
32,000
1,500,000
10,0004
Minimum # of LNS services Required2
1
1
N/A
2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
3. Transactions include PPP and LNS.
4. Transactions include PPP and LNS session setup assuming that a tunnel already exists.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Network Server
LNS Service Operation ▀
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.
Figure 35. LNS Configuration Example
AAA Server
Packet Data Network Packet Data Network
LAC
LNS
OL-22983-01
Context (Ctx.)
AAA
AAA Cfg.
IP Address
Pools
P
D
N
LNS-
Service
Def. Sub.
Source
Ctx.
P
D
N
Destination
Ctx.
Local Ctx.
Interface
Service or
Configuration (Cfg.)
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Network Server
▀ LNS Service Operation
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.
Table 28. 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Network Server
LNS Service Operation ▀
Required Information Description
Authentication protocols used
Domain alias for NAIconstruction
Maximum number of sessions per tunnel
Maximum number of tunnels
Peer LAC
Specifies how the system handles authentication: using a protocol (such as CHAP, PAP, or MSCHAP), or not requiring any authentication.
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.
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.
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.
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
Gateway IP address Used when configuring static routes from the AAA interface(s) to a specific network.
RADIUS Server Configuration
RADIUS
Authentication server
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.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
L2TP Network Server
▀ LNS Service Operation
Required Information Description
RADIUS Accounting 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.
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
RADIUS NAS IP address
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.
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.
Table 29. 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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Network Server
LNS Service Operation ▀
Required
Information
PDN interface name
IP address and subnet
Physical port number
Description
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.
These will be assigned to the PDN interface.
Multiple addresses and/or subnets are needed if multiple interfaces will be configured.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
L2TP Network Server
▀ LNS Service Operation
Figure 36. Call Processing Using a Single Source and Destination Context
AAA Server
4 7
1
Packet Data Network
6
Packet Data Network
LAC
LNS
AAA
P
D
N
AAA Cfg.
LNS-
Service
2
3
5
Def. Sub.
Source
Ctx.
IP Address
Pools
P
D
N
Destination
Ctx.
Local Ctx.
Context (Ctx.)
Interface
Service or
Configuration (Cfg.)
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Network Server
LNS Service Operation ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
L2TP Network Server
▀ Configuring the System to Support LNS Functionality
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Network Server
Configuring the System to Support LNS Functionality ▀
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:
Note:
For more information on authentication procedure and priorities, refer
LNS Configuration Mode Commands chapter of Command Line Interface Reference.
command section in
Configuring Tunnel and Session Parameters for LNS Service
Use the following example to configure the tunnel and session parameters for LNS service:
OL-22983-01
Note:
For more information on tunnel and session related parameters, refer LNS Configuration Mode Commands chapter of Command Line Interface Reference.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Configuring the System to Support LNS Functionality
Configuring Peer LAC servers for LNS Service
Use the following example to configure the peer LAC servers for LNS service:
L2TP Network Server
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:
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 command.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
L2TP Network Server
Configuring the System to Support LNS Functionality ▀
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:
The output of this command displays the configuration of the LNS service and should appear similar to that shown below.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Configuring the System to Support LNS Functionality
L2TP Network Server
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 23
MIP NAT Traversal
This chapter describes support for MIP NAT traversal and how to enable it on the system. 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:
MIP NAT traversal functionality is enabled through a feature license key.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
MIP NAT Traversal
▀ Overview
Overview
If a Mobile Node (MN) supports Mobile IP Network Address Translation (MIP NAT) traversal, it can indicate to the
Home Agent (HA) that it is able to use MIP UDP tunneling when the HA sees that the Registration Request (RRQ) has traversed a NAT device.
The HA determines that the RRQ has passed through a NAT device by comparing the care-of-address in the RRQ with the source IP address of the RRQ. If they are different, and the D bit is set in the RRQ, then it indicates that the RRQ has passed through a NAT device.
If NAT is not detected but the Force (F) bit is set in the RRQ along with a UDP Tunnel Request, the HA rejects the call with the code 129 in the Registration Response (RRP). You can configure a parameter to force the HA to accept these types of requests for UDP tunneling in the absence of NAT.
When the D bit is not set and a mismatch occurs between the source address and the care-of-address, this could be a case when a mobile is registering through an FA using different addresses for signaling and data traffic. This registration behavior is allowed by the HA service.
The MN and HA negotiate UDP tunneling support during Mobile IP call setup. The MN includes a UDP Tunnel
Request Extension in the RRQ sent to the HA. This extension optionally specifies the encapsulation type to be used as well (IP, GRE, or Minimal IP). The system only supports IP encapsulation at this time. Note also that the D bit must be set when UDP Tunneling is requested.
If the HA supports the requested form of tunneling, and the registration is successful, it responds with a UDP Tunnel
Reply Extension in the RRP and specifies the keepalive interval the MN should use.
If HA does not accept the requested type of UDP tunneling, it ignores the UDP Tunnel Request extension and does not include the UDP Tunnel Reply extension in the Registration Reply. Error code 142 is used in the RRP to indicate to the
MN that the requested UDP tunnel encapsulation is unavailable.
The UDP Tunnel Request extension is included in all initial, renewal, and handoff RRQ and RRP messages. The UDP
Tunnel Request extension is not included in a Deregistration RRQ from the MN and the HA ignores them if they are included in Dereg RRQs received.
When MIP NAT Traversal is used, normally reverse tunneling is also used. However, this is not required by the HA.
An example of successful MIP UDP Tunneling negotiation is shown below.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MIP NAT Traversal
Overview ▀
Figure 37. MIP UDP Tunneling negotiation between MN and HA
MN HA
6
7
4
5
MIP RRQ to HA
RRQ ('D')
MN-NAI Extn
UDP Tunnel Request Extn
Mobile-Home AE
MN-FAC Extn
MN-AAA Auth Extn
MIP RRP to MN
RRP
MN-NAI Extn
UDP Tunnel Reply Extn
Mobile-Home AE
MN-FAC Extn
MN-AAA Auth Extn
MIP UDP Tunneling Data
The following table lists the various cases possible in UDP Tunneling negotiation during Mobile IP call establishment.
Table 30. MIP UDP Tunneling Negotiation Cases
Case RRQ received at the HA
1
2
3
NAT detected, UDP Tunnel Request sent, NAT Traversal enabled
NAT detected, UDP Tunnel Request sent, NAT Traversal disabled at the HA
NAT not detected, UDP Tunnel Request sent, F bit not set
Action at HA
Accept call with IP-UDP tunneling, UDP Tunnel
Reply included in RRP
Reject with code 129
NAT not detected, UDP Tunnel Request sent, F bit set, forced
UDP tunnel NOT allowed
NAT not detected, UDP Tunnel Request sent, F bit set, forced
UDP tunnel allowed
UDP Tunnel Request sent, D bit not set
NAT detected, UDP Tunnel Request not sent
Accept call with IP-IP tunneling, UDP Tunnel Reply not included
Reject with code 129
Accept call with IP-UDP tunneling, UDP Tunnel
Reply included in RRP
Reject with code 134
Reject with code 129
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
MIP NAT Traversal
▀ Enabling MIP NAT Traversal
Enabling MIP NAT Traversal
MIP NAT traversal must be enabled for the desired HA service on the system.
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 enable MIP NAT traversal, set parameters by applying the following example configuration:
Notes:
Optionally, you can configure the HA to accept requests when NAT is not detected but the Force (F) bit is set in the RRQ with the UDP Tunnel Request by entering the following command: nat-traversal force-accept
Save your configuration as described in the Saving Your Configuration chapter.
Viewing MIP NAT Traversal Statistics
Use the following commands in exec mode to list statistics that include information about MIP NAT Traversal:
- Use the MIP Tunnel option to trace IP-UDP tunneled datagrams.
- Shows the MIP NAT Traversal configuration for the specified HA service.
- Lists IP-UDP tunnel statistics for Home Agent calls specified.
- Displays NAT, UPD, and encapsulation information for Home Agent calls specified.
- Displays NAT, UPD, and encapsulation information for the subscribers specified.
- Show or clear sessions for subscribers that registered a
MIP colocated COA directly with the HA.
- Show or clear sessions for subscribers that negotiated MIP UDP tunneling with the HA.
Refer to Exec Mode Commands chapter in Command Line Interface Reference for details on using these commands.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MIP NAT Traversal
Enabling MIP NAT Traversal ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 24
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 the respective product 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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Mobile IP Registration Revocation
▀ Overview
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Mobile IP Registration Revocation
Overview ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Mobile IP Registration Revocation
▀ Configuring Registration Revocation
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:
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Mobile IP Registration Revocation
Save your configuration as described in Saving Your Configuration.
Configuring Registration Revocation ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Chapter 25
MSID and PCF Zone Based Call Redirection
This chapter describes MSID and PCF zone based call redirection. 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 a feature license for PDSN RAN Optimization, Bundle 1.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
MSID and PCF Zone Based Call Redirection
▀ Overview
Overview
MSID and PCF zone based call redirection allows calls from a specific MSID or a specific PCF zone to be redirected to an alternate PDSN. These features are only applicable to new calls; handoffs are accepted by the PDSN in all cases. If the PDSN is in the process of starting up, the overload policy is applied before the zone/IMSI based call redirection.
Once the PDSN is ready to accept new calls, the zone/IMSI based call redirection policy is applied before the overload policy. Upon receiving an RRQ from a PCF, the PDSN sends an RRP with the code 136 - Unknown PDSN Address.
MSID Based Call Redirection
The PDSN contains a table of MSIDs and the corresponding set of PDSNs to which the call should be redirected. It allows the configuration of up to 16 wildcard MSIDs per PDSN service. The wildcard must be a single-digit match represented by the ―$‖ character. For example, the MSID 847$$$$$$$$12$$ would match all MSIDs starting with 847 followed by any eight digits, followed by 12 and any two additional digits.
When a new call arrives, the PDSN attempts to match the MSID with the configured list of wildcard MSIDs. If a match is found, the call is redirected to one of the PDSNs by IP address using a weighted round-robin algorithm. If more than one match is found, the algorithm selects the match with the longest matching prefix.
PCF Zone Based Call Redirection
Groups of PDSNs maybe configured with a specific numbered zone. When a new call arrives, the PDSN checks the
PCF for a specified zone number. If the PCF matches the specified zone, the call is redirected to a PDSN within the zone using a weighted round-robin algorithm. If the PCF from which the call arrived does not belong to a zone, or if no
PDSNs are configured for the specified zone, the call is not redirected. Similarly, if a zone is configured for a PCF address and the current PDSN-service address is a member of that zone, the call is not redirected. rate.
Caution:
These two features introduce additional lookups in the call setup path and could impact the call setup
Important:
If both MSID and PCF zone based call redirection are configured, MSID based call redirection will have a higher precedence.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MSID and PCF Zone Based Call Redirection
Configuring MSID and PCF Zone Based Call Redirection ▀
Configuring MSID and PCF Zone Based Call Redirection
This section describes the process of setting up MSID and PCF zone based call redirection from the command line interface.
Caution:
Incorrect configuration of the MSID and PCF Zone based Call Redirection features could result in sessions failing to be established. For example, if PDSN1 is configured to redirect sessions to PDSN2 while PDSN2 is configured to redirect sessions to PDSN1, a loop is created in which all sessions would fail to be connected. In addition, sessions will not be established if the PDSN to which the sessions are being redirected is unavailable.
Configuring MSID Based Call Redirection
To configure MSID based call redirection, you must create a new policy that defines a wildcard match list, a list of
PDSNs to redirect to, and their respective weights.
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.
Configure MSID based call redirection by applying the following example configuration:
Notes:
You may repeat the policy msid-match command as needed, to a maximum of 16 wildcard MSIDs per PDSN service.
Save your configuration as described in the Saving Your Configuration chapter.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
MSID and PCF Zone Based Call Redirection
▀ Configuring MSID and PCF Zone Based Call Redirection
Configuring PCF Zone Based Call Redirection
To configure PCF zone based call redirection, you must create a new policy that defines a zone match list, a list of
PDSNs to redirect to, and their respective weights.
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 PCF zone based call redirection:
Step 1
Set parameters by applying the following example configuration:
Notes:
You may repeat the
[ ] [
<pcf_ip_address> necessary. You can configure up to 32 PCF zones per PDSN service.
] command as
You may repeat the
] [ < [ weight ]...<
{
[
} [
] ] command as necessary, up to a maximum of 32 defined PCF zones and 16 defined
PDSNs per PDSN service.
Step 2
Save your configuration as described in the Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 26
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:
Supported Networks and Platforms
Services and Application in MBMS
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Multimedia Broadcast and Multicast Service
▀ Introduction
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 teardown 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
Figure 38. MBMS Reference Architecture in UMTS network
HLR
ASP/
Content Provider
Introduction ▀
Gr
PDN/Internet
GGSN
Iu
UTRAN
Iu/Gb
SGSN
Gn/Gp
Gmb
Gi
Gi
Multicast Broadcast
Service Center
(BM-SC)
GERAN
Multicast
Broadcast
Source
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 teardown 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Multimedia Broadcast and Multicast Service
▀ Supported Standards
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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
Supported Networks and Platforms ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Multimedia Broadcast and Multicast Service
▀ Licenses
Licenses
This feature support requires any one of the following feature licenses installed on the system:
600-00-7581
600-00-7621
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
Services and Application in MBMS ▀
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Multimedia Broadcast and Multicast Service
▀ Services and Application in MBMS
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
How MBMS Works ▀
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.
Figure 39. Basic Procedure of MBMS Broadcast Mode
MBMS capable radio network
(GERAN/UTRAN)
MBMS enabled AGW/
PS Core Network
Multimedia services
MBMS Broadcast service area
Broadcast data
Broadcast data
QoS handling, broadcast area configuration, provisioning control, etc.
Operator’s services
Internet services
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Multimedia Broadcast and Multicast Service
▀ How MBMS Works
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
Figure 40. Basic Procedure of MBMS Multicast Mode
MBMS capable radio network
(GERAN/UTRAN)
SGSN
MBMS enabled GGSN/
PS Core Network
QoS handling, multicast area control, provisioning control, subscription handling, activation etc.
Multimedia services
Operator’s services
IP network
How MBMS Works ▀
Services (news, sport, results, video etc.)
SGSN
- Service Synchronization
- User initiated activation
- Multicast data
MBMS capable radio network
(GERAN/UTRAN)
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Multimedia Broadcast and Multicast Service
▀ How MBMS Works
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
MBMS Configuration ▀
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.
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:
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Multimedia Broadcast and Multicast Service
▀ MBMS Configuration
MBMS GTPP Configuration
This section provides the configuration example to configure the GTPP server parameters in GTPP group configuration mode for MBMS charging:
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:
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
MBMS Configuration ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Multimedia Broadcast and Multicast Service
▀ Save the Configuration
Save the Configuration
To save changes made to the system configuration for this service, refer Verifying and Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
Managing Your Configuration ▀
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.
To do this:
Output descriptions for most of the commands are located in Command Line Interface Reference.
Enter this command:
View Administrative Information
Display Current Administrative User Access
View a list of all administrative users currently logged on to the system
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
View information pertaining to local-user administrative accounts configured for the system
View statistics for local-user administrative accounts
View information pertaining to your CLI session
Determining the System‘s Uptime
View the system‘s uptime (time since last reboot)
View the Status of Configured NTP Servers
View the status of the configured NTP servers
View the Statistics of Broadcast Multicast service
View the full information of all broadcast-multicast service session
View the status of all broadcast multicast-service session
View all session for broadcast-multicast service
View Subscribers Currently Accessing the System
View a listing of subscribers currently accessing the system
View information for a specific subscriber
View the MBMS Related Information
Display Configured MBMS service
View the configuration of a context show subscribers full username
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Managing Your Configuration
To do this:
View configuration errors for GGSN service
Display BM-SC server Information
Multimedia Broadcast and Multicast Service
Enter this command:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Multimedia Broadcast and Multicast Service
Gathering MBMS Statistics ▀
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.
Table 31. Gathering Statistics
Statistics
Wanted
Gmb interface statistics for
APN and BM-
SC profile
Action to Perform
At the Exec Mode prompt, enter the following command:
Detailed MBMS bearer service statistics
At the Exec Mode prompt, enter the following command:
Information to Look For
The output of this command displays the statistics about the Gmb interface session for
MBMS on an APN.
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: The output of this command displays the detailed statistics of
MBMS multicast session running on system.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Chapter 27
MultiProtocol Label Switching (MPLS) Support
This chapter describes the system‘s support for Multi Protocol Label Switching (MPLS) 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 from the GGSN/PDSN to the corporate's network. In this VPN, an APN that terminates on one GGSN/PDSN can change and terminate on another.
MPLS is used to negotiate the routes and segregate the traffic. The GGSN/PDSN learns the default route from the connected Provider Edge (PE), while the PE populates its routing table with the routes provided by the GGSN/PDSN.
This chapter includes following sections:
Configuring MPLS with Static Labels
Configuring MPLS on BGP with Dynamic Labels
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
MultiProtocol Label Switching (MPLS) Support
▀ Overview
Overview
As seen in the following scenario, the chassis can be deployed as a router while supporting MPLS in a network.
Chassis as MPLS-Customer Edge (MPLS-CE) with Provider Edge (PE)
Chassis as MPLS-Customer Edge (MPLS-CE) with Autonomous System Border Router (ASBR)
Chassis as MPLS-CE with PE
Figure 41. Chassis as MPLS-CE with PE
The system in this scenario uses static MPLS labels for ingress and egress traffic. For configuration information on
static label, refer to the Configuring MPLS over BGP with Static Labels section.
The system is in a separate autonomous system (AS) from the Provider Edge (PE). It communicates with the PE and routes for all VPNs supported on the PE that are exchanged with the system. 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, which is in fact an MPLS label.
The Customer Edge (CE) also advertises routes to the PE using NLRIs that include route distinguishers to differentiate
VPNs, and extended community MPLS labels to identify VRFs.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MultiProtocol Label Switching (MPLS) Support
Overview ▀
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 routing protocols. The MPLS label corresponding to the immediate upstream neighbor is 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 as an extended community with the NLRI) and the immediate next hop. When the PE receives a packet it switches the label to an MPLS-labeled packet.
The CE does not run any MPLS routing 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 with ASBR
Figure 42. Chassis as MPLS-CE with ASBR
OL-22983-01
The system in this scenario uses dynamic MPLS labels for ingress and egress traffic. For configuration information on
dynamic label, refer to Configuring MPLS-over-BGP with Dynamic Labels section.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
MultiProtocol Label Switching (MPLS) Support
▀ Overview
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 nexthop 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 uses the dynamic MPLS label and avoids configuration of VRFs on the PE, which have already been configured on the MPLS-
CE.
Engineering Rules
Up to 100 virtual routing tables per context. This allows up to 100 BGP-VPNs per context.
Up to 5k ―host routes‖ spread across multiple VRFs per BGP process. Limited to 6000 pool routes per chassis.
Up to 1024 VRFs per chassis.
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.
Supported RFCs
The following RFCs related to MPLS are partially supported:
IETF RFC 4364 BGP/MPLS IP VPNs
IETF RFC 3032 MPLS Label Stack Encoding
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MultiProtocol Label Switching (MPLS) Support
Configuring MPLS over BGP with Static Labels ▀
Configuring MPLS over BGP 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 of the System Enhanced Feature Configuration Guide, must be completed prior to attempt the configuration procedure described below.
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 MPLS:
Step 1
Create a VRF on the router and assign a VRF-ID 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 with a peer router by applying the example
configuration in the Set Neighbors and Address Family section.
Step 3
Step 4
Step 5
Configure the address family and redistribute the connected routes into BGP by applying the example configuration in
neighbors using the BGP protocol.
Step 6
Pools with MPLS Labels section.
Step 7
Optional. Bind DHCP service to work with MPLS labels for input and output by applying the example configuration in
the Bind DHCP Service with MPLS Labels Bind DHCP Service with MPLS Labels 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-ID. The second route-distinguisher and route-target.
command creates the
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
MultiProtocol Label Switching (MPLS) Support
▀ Configuring MPLS over BGP with Static Labels
Set Neighbors and Address Family
Use this example to set the neighbors and address family to exchange routing information with a peer router.
Redistribute Connected Routes
Use this example to redistribute connected routes between routing domains.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MultiProtocol Label Switching (MPLS) Support
Establish BGP Peering with Peer Router
Use this example to establish BGP peering with peer router.
Configuring MPLS over BGP with Static Labels ▀
Configure Address Family
Use this example to configure the and to the connected routes into BGP. This takes any routes from another protocol and redistributes them to BGP neighbors using the BGP protocol.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Configuring MPLS over BGP with Static Labels
Configure IP Pools with MPLS Labels
Use this example to configure IP Pools with MPLS labels for input and output.
MultiProtocol Label Switching (MPLS) Support
Bind DHCP Service with MPLS Labels
Use this example to bind DHCP service with MPLS labels for input and output.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MultiProtocol Label Switching (MPLS) Support
Configuring MPLS over BGP with Static Labels ▀
Notes:
To ensure proper operation, DHCP functionality should be configured within a destination context.
Optional keyword
applies DHCP over MPLS traffic.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
MultiProtocol Label Switching (MPLS) Support
▀ Configuring MPLS on BGP with Dynamic Labels
Configuring MPLS on BGP with Dynamic Labels
This section describes the procedures required to configure the system as the MPLS-CE to interact with the PE with static MPLS label support.
The base MPLS configuration, as described in the Configuring MPLS over BGP with Static Lables section, must be performed prior to attempting the configuration procedure described below.
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 dynamic MPLS label over BGP:
Step 1
Modify the context, which is configured to support basic MPLS functionality, for MPLS forwarding on BGP router by applying the example configuration in the MPLS Forwarding Configuration section.
Step 2
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 3
Modify the configured loopbakc or tunnel interface, which is configured to support basic MPLS functionality, for IP
VRF forwarding by applying the example configuration in the IP VRF Forwarding on Interface section.
Step 4
Modify AAA server group to support AAA attributes with configured IP VRF, which is configured to support basic
MPLS functionality, by applying the example configuration in the IP VRF and AAA Group Association section.
Step 5
Modify the configured IP VRF, which is configured to support basic MPLS functionality, for import and/or export the target routes into VRF by applying the example configuration in the Route Import and Export Configuration section.
Step 6
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
MPLS Forwarding Configuration
Use this example to modify the Context in which IP VRF is configured in the Configuring MPLS over BGP with Static
Labels section to support MPLS forwarding.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
MultiProtocol Label Switching (MPLS) Support
Configuring MPLS on BGP with Dynamic Labels ▀
DSCP and EXP Bit Mapping
Use this example to modify the configured IP VRF which is configured in the Configuring MPLS over BGP with Static
Labels section to support MPLS forwarding.
IP VRF Forwarding on Interface
Use this example to modify the configured IP VRF interface, which is configured in the Configuring MPLS over BGP
with Static Lables section, to support IP VRF forwarding on that interface.
IP VRF and AAA Group Association
Use this example to modify the configured AAA server group to associate IP VRF, which is configured in the
Configuring MPLS over BGP with Static Lables section, to support AAA attributes.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
MultiProtocol Label Switching (MPLS) Support
▀ Configuring MPLS on BGP with Dynamic Labels
Route Import and Export Configuration
Use this example to modify the BGP router, which is configured in Configuring MPLS over BGP with Static Lables section, and associate it with the IP VRF, which is configured to support import and/or export of route target lists.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 28
PDIF Session Recovery
In the telecommunications industry, over 90 percent of all equipment failures are software-related. With robust hardware failover and redundancy protection, any card-level hardware failures on the system can quickly be corrected.
However, software failures can occur for numerous reasons, many times without prior indication. For this reason, we have introduced a new solution to recover subscriber sessions in the event of failure.
The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.
The PDIF supports a session recovery procedure wherein the system can be configured to store redundant call state information and recover this information after certain types of hardware and software failures.
Important:
Session Recovery can only be enabled through a feature use license key. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
The session recovery feature, even when the feature use key is present, is disabled by default on the system.
This chapter provides information on the following topics:
How Session Recovery Works in PDIF
Hardware Requirements and Configuration
Enabling or Disabling Session Recovery from the CLI
Disabling the Session Recovery Feature
Show Session Recovery Status Command
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
PDIF Session Recovery
▀ Session Recovery
Session Recovery
This section examines how the PDIF recovers from two types of failure: migration failures and task failures.
How Session Recovery Works in PDIF
PDIF call traffic is encrypted by the IPSec protocol. When the encrypted packet arrives on the ASR 5000, it first needs to be decrypted in the data path. The Daughter Card has an IPSec SA to do the decryption. Consequently, it is very important to have the Daughter Card recover before any software recovery in order to continue call traffic processing.
IPSec Controller does not send an IPSec Manager death notification to any subsystem. This allows both the Session
Manager and Daughter Card to continue carrying subscriber traffic using NPU flows and IPSec SAs to transmit the data.
It also allows the Daughter Card to continue to receive and decrypt IPSec tunnel data.
When IPSec Manager recovers, IPSec Controller sends the configured PDIF crypto template to the IPSec Manager.
Upon receiving the template, IPSec Manager initializes the template policy and creates the service entry for this template policy. It also initializes an IKEv2 stack instance. IPSec Manager uses the AAA API to recover calls in bulk.
On receiving a response from the AAA, IPSec Manager repopulates each subscriber policy data structure. It also takes care of information that needs to be generated dynamically, (reprogramming the Datapath, creating skip lists, etc.)
To provide faster Datapath recovery without affecting call traffic, Daughter Card Manager is used to repopulate the
Daughter Cards with the SAs faster and more efficiently; meanwhile IPSec Manager and Session Manager can recover in the background at relatively slower pace without the call data being interrupted.
On restart, IPSec Manager allocates the Datapath instance used to update the Daughter Card with the IPSec SAs and to create an NPU flow mapped to the Daughter Card IPSec SA entry.
When an IPSec tunnel is established, two IPSec SAs are created: one for receiving encrypted data and another for encrypting and transmitting encrypted data. In the interests of speed, a standby Daughter Card Manager on a standby
PSC stores IPSec SAs for the whole system.
Once the PSC becomes active, Daughter Card Manager quickly programs the Daughter Card with available IPSec SAs.
The most active calls are given priority in order to prevent traffic interruption.
Migration vs. Task Failure
Planned migration requires that all the task data be transferred over the new CPU. Task migration time (hence total outage time) depends upon task size. In general, a longer outage can be anticipated since the whole task has to be successfully migrated before it can be executed. Task failure, on the other hand, creates a new task that is operational right away. Thus, it can recover its own session while it services other sessions as they are recovered. So, the perceived outage is shorter in the case of failure recovery than for a migration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
PDIF Session Recovery
Session Recovery ▀
Planned PSC Migration
This is the case when a system administrator decides to migrate an ASR 5000 application card (PSC). When the migration command is issued, all the tasks on affected card are notified to get ready for migration. After task migration is complete, all the tasks are notified and any post-migration adjustments will be done. At the end of the migration process, each IPSec Manager is returned to its previous normal operational state before it started migration.
Unplanned PSC Migration
This is the case when there is a system fault and a card has failed, or when an individual task fails. When tasks are restarted as a result of either card failure or task failure, it is recovered with saved information and put back into its previous state of operation. In either planned or unplanned recovery, only tunnels that are in an already established state can be recovered. Any non-established tunnels may be lost.
Hardware Requirements and Configuration
Because session recovery requires numerous hardware resources, such as memory, control processors, NPU processing capacity, etc., some additional hardware may be required to ensure that enough resources are available to fully support this feature.
Important:
PDIF is designed to run on an ASR 5000 chassis using only SMC controller cards and PSC application cards.
Important:
A minimum of four PSCs (three active and one standby) per individual chassis is required to use this feature.
To allow for complete session recovery in the event of a hardware failure during a PSC migration, a minimum of three active and two standby PSCs should be deployed.
To assist you in your network design and capacity planning, the following list provides information that should be considered.
Subscriber capacity is decreased depending on the hardware configuration.A fully configured chassis (12 active
PSCs and 2 standby PSCs) would experience a smaller decrease in subscriber capacity versus a minimally configured chassis (3 active PSCs and 2 standby PSCs).
The amount by which control transaction processing capacity is reduced.
The reduction in subscriber data throughput.
The recovery time for a failed software task (e.g. session manager).
The recovery time for a failed PSC (hardware failure).
If a PSC migration is being performed, this may temporarily impact the ability to perform session recovery as hardware resources (e.g. memory, processors, etc.) that may be needed are not available during this operation.To avoid this condition, a minimum of two standby PSCs should be configured.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
PDIF Session Recovery
▀ Session Recovery
Enabling or Disabling Session Recovery from the CLI
Enabling or disabling session recovery is done on a chassis-wide basis.
Enabling Session Recovery on an Out-of-Service System
The following procedure is for a system that does not have any contexts configured.
Step 1
At the Exec mode prompt, verify that the session recovery feature is enabled by the session and feature use license on the system by entering the following command:
The output of this command appears similar to the example shown below. Session Recovery is shown in bold. If there were no current license, another would have to be applied before Session Recovery could be enabled.
Enabled Features:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
PDIF Session Recovery
Session Recovery ▀
Step 2
From the Global Config Mode, enter the following:
Step 3
Save your configuration as described in Verifying and Saving Your Configuration.
Enabling Session Recovery on an In-Service System
When enabling session recovery on a system that already has a saved configuration, the session recovery commands are automatically placed before any service configuration commands in the configuration file.
Step 1
Check that the license supports Session Recovery as shown above. If not, replace the license before proceeding.
Step 2
Use the following configuration example to enable Session Recovery.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
PDIF Session Recovery
▀ Session Recovery
Important:
This feature does not take effect until after the system has been restarted.
Step 3
Save your configuration as described in Verifying and Saving Your Configuration.
Step 4
Perform a system restart by entering the following command:
The following prompt appears:
Answer:
More advanced users may opt to simply insert the require session recovery command syntax into an existing configuration file using a text editor or other means, and then applying the configuration file manually. Caution should be taken when doing this to ensure that this command is placed among the first few lines of any existing configuration file to ensure that it appears before the creation of any non-local context.
Disabling the Session Recovery Feature
To disable the session recovery feature on a system, enter the following command from the Global Configuration mode prompt:
Important:
If this command is issued on an in-service system, then the system must be restarted by issuing the
command.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
PDIF Session Recovery
Session Recovery ▀
Preserved Session States
Session state is periodically stored (checkpointed) by using redundant processes to carry the existing call state information.
Preserved session states includes the following:
Per-session idle timer (± one checkpoint interval)
Per-session DPD timer (± one checkpoint interval)
Per-session rekeying timer (± one checkpoint interval)
Accounting packet transmission
STR transmission
Scope of Data Recovery
In addition to maintaining call state information, information is kept in order to:
Recover IPSec Manager policies, all template maps, and all subscriber maps.
Use the policies (including templates) to recover pertinent CHILD SAs, flowIDs and statistics.
Recover or reconfigure NPU flowids and data path handles.
Recover and restore IKEv2 stack state for all tunnels.
Supply the IKEv2 stack with needed data statistics to determine rekey and DPD states.
Recover Diameter session information
Possible Recovery Failures
There are some situations wherein session recovery may not operate properly. These include:
Additional software or hardware failures during the session recovery operation. An example of this would be if the Daughter Card Manager used to repopulate the Daughter Cards with the preserved SAs failed.
A lack of hardware resources (i.e., PSC memory and control processors) to support session recovery.
Some statistics, such as those collected and maintained on a per manager basis (AAA manager, session manager, etc.) are not recovered after the failure.
Show Session Recovery Status Command
Information about the current state of the session recovery subsystem is available from an Exec Mode command.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
PDIF Session Recovery
▀ Session Recovery
The output (below) shows the current state of the session recovery system. It displays all the tasks involved with the recovery process. It can also tell when was the last checkpoint (save) was done and how many sessions are to be recovered on each manager:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 29
Policy-Based Management and EV-DO Rev A
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.
Important:
The EV-DO Rev A features described in this chapter are only available if you have purchased and installed a session use license EV-DO Rev A PDSN License on your system. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
Important:
If the EV-DO Rev A PDSN License is not available or if the number of Rev A sessions exceeds the license limits, the Rev A calls are downgraded to Rev 0 calls.
EV-DO Rev A is an enhanced version of CDMA2000 EV-DO that provides the foundation for next-generation, IPbased, broadband wireless voice and data networks. EV-DO Rev A is backward compatible and interoperable with EV-
DO Rev 0 networks and devices, with continued support for both Simple IP and Mobile IP sessions.
EV-DO Rev A includes higher data rates (3.1 Mbps on the forward link and 1.8Mbps on the reverse link) and improved
Quality of Service (QoS) support.
This chapter describes the following:
Policy-based Management Overview
Quality of Service in EV-DO Rev A
EV-DO Rev A Important Commands
RADIUS Accounting for EV-DO Rev A
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Policy-Based Management and EV-DO Rev A
▀ Policy-based Management Overview
Policy-based Management Overview
Policy-based management provides a way to allocate network resources; primarily network bandwidth, Quality of
Service (QoS), security, and accounting according to defined business policies. These policies can be either static or dynamic. In a static policy the traffic flow is predefined by exact rules. For dynamic policies, the flows are created dynamically by external signaling. The dynamic policies validate the flows and apply the necessary policy actions required for each flow.
In flow-based traffic policies, policy modules interact with the system through a set of well defined entry points, provide access to a stream of system events and permit the defined policies to implement access control decisions, provide QoS enforcement and accounting decisions, etc.
A policy is defined as policy: condition = > action
condition: specifies the flow-parameters such as source-address, destination-address, source-port, destinationport, protocol, etc. for ingress and/or egress packets.
action: specifies a set of treatments for a flow/packet when condition matches. These actions are typically based on flow classification and QoS processing for individual flows and DSCP marking.
Supported Standards
The following standards were referenced for the system‘s EV-DO Rev A implementation:
CDMA2000 Wireless IP Network Standard: Introduction, X.P0011-001-D v 0.5
CDMA2000 Wireless IP Network Standards: Quality of Service and Header Reduction, X.P0011-004-D v 0.5
CDMA2000 Wireless IP Network Standards: Accounting Services and 3GPP2 RADIUS VSAs, X.P0011-005-D v 0.5
Interoperability Specification (IOS) for CDMA2000 Access Network Interfaces - Part 7 (A10 and A11
Interfaces), A.S0017-C v0.4, IOS v5.0, June 2004
Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with
Session Control in the Packet Control Function, V&V Version, A.S0009 v0.3, May 2005
Perkins, IPv4 Mobility, RFC 3344, August 2002
Braden, R.,et al, Resource ReSerVation Protocol (RSVP) -- Version 1, RFC 2205, September 1997, Proposed
Standard.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy-Based Management and EV-DO Rev A
Quality of Service in EV-DO Rev A ▀
Quality of Service in EV-DO Rev A
The QoS feature in Rev A enables a Mobile Node (MN) to negotiate and setup QoS for the air interface with the RAN while using the PDSN for QoS authorization and classifying user traffic flows. Network entities including the PDSN,
PCF, AAA server, RAN and the mobile are all involved in setting up the desired QoS parameters for the MN. QoS may be applied for both Simple IP and Mobile IP calls.
The QoS is created in a subscriber profile on the AAA server. When the subscriber is authenticated, the AAA server passes the subscriber‘s QoS on to the PDSN, which then passes the information on to the PCF. The PCF determines whether or not to grant the subscriber the QoS.
The following graphic shows an EV-DO Rev A network.
Figure 43. EV-DO Rev A Network
The interface between the MN and the RAN can support multiple simultaneous connections of the same or different packet data service options. These connections are referred to as packet data flows or link flows.
The three main entities involved in the QoS procedures for Rev A are the MN, RAN and the PDSN. The PDSN authenticates the MN during call setup and obtains the QoS profile for the subscriber. The PDSN conveys the subscriber's QoS profile to the PCF using A11 messaging. The PDSN and RAN store the QoS profile attributes.
Important:
The RAN can map multiple IP flows to a single A10 connection.
OL-22983-01
When the MN requests QoS parameter setup with the RAN, the RAN verifies the request using a stored QoS profile. If the subscriber is authorized for the requested QoS parameters, the RAN provides the MN with a granted QoS profile and also sends the granted QoS profile to the PDSN via A11 messaging. If QoS was granted, the PCF sets up new auxiliary A10 connections for carrying traffic corresponding to the granted QoS and maps the requested flows over the
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Policy-Based Management and EV-DO Rev A
▀ Quality of Service in EV-DO Rev A
A10 connections. The PCF uses A11 messaging to signal new A10 connection creation and to convey the requested and granted QoS parameters and the mapping of flows to A10 connections.
Important:
If the subscriber is not authorized, the RAN denies the requested QoS profile to the MN and downgrades the flow to best effort traffic.
The MN sends Traffic Flow Templates (TFTs) that identify different IP flows in both the forward and reverse directions to the PDSN. The PDSN stores the TFTs. For traffic towards the mobile network, the PDSN uses the TFTs to identify the traffic flows and to map the flows to different A10 connections and for flow-based accounting. For traffic from the mobile network, the PDSN looks up the flow for per-flow based accounting. The PDSN also tracks accounting per A10 connection in addition to a per-flow basis.
Flow Mapping
Flow mapping includes these basic areas:
Basic TFT processing
Forward Traffic Processing
Basic TFT processing
The MN may be assigned one IP address. This IP address is not associated with any particular A10 connection. The MN may send Traffic Flow Templates (TFTs) for flow mapping to the PDSN carried over RSVP reservation messages. The
TFTs are used to map forward traffic to the main or auxiliary A10 connections and to indicate if a specific flow treatment (such as header compression) should be applied for the matching packets. The TFTs are also used by PDSN to associate packets from forward and reverse traffic to flows for flow-based accounting and QoS enforcement. Since the
MN may be assigned multiple IP addresses, each TFT corresponds to a specific IP address.
The TFTs can contain:
Source and destination ports
Source and destination addresses
Protocol
Type of service (TOS in IPv4)
After the main and auxiliary A10 connections are created, the MN sends TFTs to the PDSN via a reservation message
(RSVP).
Forward Traffic Processing
When a packet arrives at the PDSN from the external IP network, the packet is matched against the set of packet filters stored at the PDSN. The packet is sent down the A10 connection that matches the flow id in the packet filter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy-Based Management and EV-DO Rev A
Quality of Service in EV-DO Rev A ▀
If flow treatment is specified for that matching packet filter, such as ROHC compression, the specified treatment is applied to the packets. Otherwise, the default treatment is applied. If no packet filters match the incoming packet, the
PDSN forwards the packet over the main A10 connection.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Policy-Based Management and EV-DO Rev A
▀ EV-DO Rev A Call Setup
EV-DO Rev A Call Setup
The following figure describes the setup procedures for Rev A calls. Note that Rev A supports both Simple IP and
Mobile IP calls.
Figure 44. EV-DO Rev A Call Setup
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy-Based Management and EV-DO Rev A
EV-DO Rev A Call Setup ▀
Table 32. EV-DO Rev A Call Setup Description
Step Description
1 Main service connection is setup. Here, the PDSN receives an A11 RRQ indicating that this is a request to setup the main service connection for a Rev A call. For main A10s, the A11 RRQ always includes an SR_ID of 1, a forward traffic flow
ID of 255, and a reverse traffic flow ID of 255.
2 The PDSN sends an Access Request message to the AAA to authenticate the subscriber and to retrieve the subscriber‘s
QoS profile. (If no authentication is required, the PDSN uses the QoS profile from the default subscriber template.)
3 The AAA sends the subscriber‘s profile that includes the QoS profile to the PDSN.
4 The PDSN stores the QoS attributes from the subscribers profile and sends a copy to the RAN via A11 Session Update message The RAN also stores the QoS attributes.
5 The AT sends an IP flow reservation message to the RAN that includes the requested levels of QoS for each data flow.
6 The RAN determines if the subscriber is authorized using the QoS attributes it stored from step 4. If the subscriber is authorized, the RAN sends a QoS Granted message to the AT. Otherwise, the RAN denies the QoS requested by the RAN.
7 The AT sends the RAN an Acknowledgment.
8 The RAN sends an A11 RRQ to the PDSN that includes SR_IDs for the auxiliary A10 connections and the QoS granted the
MS.
9 The PDSN verifies the QoS parameters granted to the MS using the attributes it stores in step 4 and returns an A11 RRP.
10 The AT sends the TFTs—which identify the different flows in both the forward and reverse directions—to the PDSN via modified RSVP Reservation message. (RSVP formats the TFTs for the PDSN.)
11 The PDSN sends Reservation Confirm message to the AT and uses the packet filters within the TFTs to map flows to the auxiliary A10 connections.
The PDSN also stores the TFTs for flow look up when mapping flows in the reverse direction and for flow-based accounting.
During intra-PDSN handoff, PDSN will send the subscriber QoS Profile that it received in the Access-Accept during authentication to the new PCF. This includes the list of authorized profile IDs in addition to other QoS attributes, but this does not contain the requested/granted profile IDs. The PDSN may send the profile in the A11 RRP or generates an RP
Session Update message and sends it to the PCF.
The system assumes that the AT uses the same NAI, even if it initiates multiple simultaneous sessions.
Call Flow for Updating QoS for Dynamic Flows
The PDSN and the PCF can perform QoS update procedures to modify the QoS that is granted for an IP flow. The QoS update procedure is applicable to dynamic flows only.
You can configure the system to ensure that the granted QoS is downgraded to best effort (i.e. class x to best effort but not class x to class x-1). The reservation for the downgraded flow is removed at the RNC and PCF and the user detail record for the flow is closed at the PDSN.
In a downgrade scenario, the PDSN downgrades the profile ID for a flow from the Profile ID that was originally granted by the RAN. The profile ID is downgraded to a lower precedence profile ID or to best effort.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Policy-Based Management and EV-DO Rev A
▀ EV-DO Rev A Call Setup
Important:
If the EV-DO Rev A PDSN License is not available or if the number of Rev A sessions exceeds the license limits, the Rev A calls are downgraded to Rev 0 calls. If the profile ID does not match, the flow will be downgraded to best effort.
In an update scenario, the updates may be triggered by one of the following:
TFT validation failure—The MN sent a TFT for a flow/profile id that violates the configured policy for the flow/profile-id.
Traffic Violation: The MN is using the wrong link flow to send reverse data.
Operator triggered: The Operator triggered an update through the CLI.
Traffic Policing: Traffic policing triggered an update.
The following call flow describes a successful flow setup with QoS update from PDSN.
Figure 45. Successful Flow Setup with QoS Update from PDSN
MN PCF PDSN
Main A 11 -Registration Setup
Additional Flow Setup
RSVP Setup
with TFT
RSVP Response
Policy
Decision to
Update
A11 Session Update with new Profile ID
1. The Main A11 registration setup includes the following actions:
•
The High Rate Packet Data (HRPD) connection is established over the radio link between the MN and the PCF.
•
The PCF recognizes that no A10 connection associated with the MN is available and selects a PDSN. The PCF sends an A11-Registration Request message to the PDSN. The PCF also includes the Main Service Option for
HRPD (SO59) in the message to indicate to the PDSN that this is the main service connection. The PCF includes the Connection Setup Airlink record in this message. If the main connection is active, and the PCF has received enough information about the flow, the PCF also includes the Active-Start airlink record for the main A10 connection.
•
The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-
Registration Reply message and acceptance. The A10 connection binding information at the PDSN is updated to point to the PCF.
•
The PDN sends a list of authorized profile ids specified in the Subscriber profile in A11-Session-Update message to the PCF. Then the PCF sends Session Update Ack back to the PDSN.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy-Based Management and EV-DO Rev A
EV-DO Rev A Call Setup ▀
2. The PCF sends an A11 Registration Request message indicating any auxiliary A10 (if it is required), the complete flow mapping information, requested profile ids from the mobile and the granted profile id for each flow.
• The PDSN sends an A11 Registration Reply message including all the auxiliary A10s it has for the session.
• The MN sends the TFT for the flow to be setup with the packet filters that identify the flow.
• The PDSN sends a confirmation back to the MN to accept the valid TFT.
3. The PDSN updates the granted QoS for the flow because of a policy update trigger (QoS policy trigger, Operator trigger etc).
• The PCF sends a Session Update acknowledge message indicating that it accepted the profile id change.
• The PCF sends a new Registration Request message, with the new granted profile id and the flow mappings.
4. The A11 Session updates with the new profile IDs is complete.
The PDSN accepts the Registration Request message, updates the flow mappings, and responds with an RRP.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Policy-Based Management and EV-DO Rev A
▀ EV-DO Rev A Important Commands
EV-DO Rev A Important Commands
Important:
If you are using EV-DO Rev A without Intelligent Traffic Control (ITC), you must define the type of traffic policing as . If you are using EV-DO Rev A with ITC, you can use commands to set flow-based
Rev A and ITC. Refer to the Intelligent Traffic Control chapter or additional information on configuring flow-based traffic policies.
The commands listed in the following table are used to configure and monitor EV-DO Rev A commands. Detailed information, including description, syntax, and usage for each of these commands can be found in the Command Line
Interface Reference.
Table 33. EV-DO Rev A Commands
Mode Description Command
Configuration Commands
PDSN Service
Configuration
Subscriber
Configuration
Subscriber
Configuration
Subscriber
Configuration
Enables or disables the data-over signaling feature for A10 packets.
Sets the QoS Differentiated Services (DiffServ) marking that a subscriber session is allowed.
Configures quality of service options for the current subscriber using the differentiated services code point method.
Sets the quality of service setting to the system default.
Monitor Commands
Exec
Exec
Exec
Exec
Exec
Exec
Exec
Exec
Can be used to verify policy is applied.
Can be used to verify signal and data between the PDSN and
PCF, and between the PDSN and mobile.
Can be used to verify Session Update Send Reason.
Can be used to verify GRE Key associated with A10 instance.
Can be used to verify RSVP related statistics/counters.
Can be used to verify summary rev-A flow and filter information.
Can be used to verify access technology.
Can be used to verify subscriber policy.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy-Based Management and EV-DO Rev A
RADIUS Accounting for EV-DO Rev A ▀
RADIUS Accounting for EV-DO Rev A
RADIUS accounting for EV-DO Rev A traffic can either be session-based or flow-based. By default the system is set to session-based accounting. In session-based accounting, only a single accounting message is generated for the subscriber session, not separate accounting messages for individual A10 connections or flows. When the system is set for flowbased accounting, separate messages are sent for each flow and A10 sessions. Flow-based accounting includes the following options:
all-flows: Generates separate RADIUS accounting messages per access flow. Separate accounting messages are not generated for data path connections. (For example, separate messages are not sent for the main A10 or auxiliary connections.)
auxiliary-flows: Generates RADIUS accounting records for the main data path connection and for access-flows for all auxiliary data connections. (For example, separate RADIUS accounting messages are generated for the main A10 session and for access-flows within auxiliary A10 connections. The main A10 session accounting does not include octets or other accounting information from the auxiliary flows.)
main-a10-only: Configures access-flow-based single accounting messages (for example only single start/interim/stop) are generated for the main A-10 flows only.
none: Separate RADIUS accounting messages are generated for all data path connections (for example, PDSN main or auxiliary A10 connections) but not for individual access-flows. This is essentially A10 connectionbased accounting.
RADIUS Attributes
The RADIUS attributes listed in the following table are used to configure EV-DO Rev A accounting for subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Attribute
Reference.
Attribute
3GPP2-Flow-Id
Description
Displays the 3GPP2-Flow-Id.
3GPP2-Flow-Status Displays the 3GPP2-Flow-Status.
3GPP2-Release-Indicator Displays the 3GPP2-Release-Indicator.
3GPP2-Rev-Pdch-Rc
3GPP2-Subnet
Displays the 3GPP2-Rev-Pdch-Rc.
Displays the 3GPP2-Subnet.
The RADIUS attributes listed in the following table are used to configure RSVP Signaling for subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Attribute Reference.
Attribute Description
ThreeGPP2-Rsvp-Sig-Inbound-count Specifies the RSVP signaling octets sent by the Mobile Node.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Policy-Based Management and EV-DO Rev A
▀ RADIUS Accounting for EV-DO Rev A
Attribute Description
ThreeGPP2-Rsvp-Sig-In-Pkts Specifies the Number of RSVP signaling packets sent by the Mobile Node.
ThreeGPP2-Rsvp-Sig-Outbound-count Specifies the RSVP signaling octets sent to the Mobile Node.
ThreeGPP2-Rsvp-Sig-Out-Pkts Specifies the Number of RSVP signaling packets sent to the Mobile Node.
These attributes can be found in the StarentVSA and the StarentVSA1 dictionaries.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy-Based Management and EV-DO Rev A
EV-DO Rev A with ITC Support ▀
EV-DO Rev A with ITC Support
Important:
The EV-DO Rev A features described in this section are only available if you have purchased and installed session use licenses EV-DO Rev A PDSN License and Intelligent Traffic Control License on your system. The
Intelligent Traffic Control license enables policy related commands which allow DSCP marking, traffic policing, DOS
Marking, etc. If you have not previously purchased these enhanced features, contact your sales representative for more information.
You can configure your system to support both EV-DO Rev A and Intelligent Traffic Controls (ITC). ITC uses flowbased traffic policing to configure and enforce bandwidth limitations per subscriber. Enabling EV-DO Rev A with ITC allows you to control the actual level of bandwidth that is allocated to individual subscriber sessions and the application flows within the sessions.
For more information on Intelligent Traffic Controls (ITC) and configuring flow-based traffic policing on your system, refer to the Flow-based Traffic Policing Configuration section in this manual.
Flow-based Traffic Policy
Flow-based traffic policies and traffic policing are configured on a per-subscriber basis for either locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
Flow-based traffic policy is configured with the following building blocks:
Class Maps: The basic building block of a flow-based traffic policing. Class maps are used to control over the packet classification.
Policy Maps: A more advanced building block for flow-based traffic policing. Policy maps manage admission control based on the Class Maps and the corresponding flow treatment based on QoS traffic policing or QoS
DSCP marking.
Policy Group: This is a set of one or more Policy Maps applied to a subscriber. Policy groups also resolve conflict if a flow matches multiple policies.
Important:
For more information on Intelligent Traffic Controls (ITC) and configuring flowbased traffic policies on your system, to the Flow-based Traffic Policing Configuration section in this manual.
ITC Important Commands
OL-22983-01
Important:
If you are using EV-DO Rev A with ITC, you can use commands to set flow-based policies using
Refer to the Intelligent Traffic Control chapter for additional information on configuring flow-based traffic policies.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Policy-Based Management and EV-DO Rev A
▀ EV-DO Rev A with ITC Support
The commands listed in the following table are used to configure and monitor ITC. Detailed information, including description, syntax, and usage for each of these commands can be found in the Command Line Interface Reference.
Table 34. ITC Commands
Command
Configuration Commands
Mode Description
Class-Map
Configuration
Mode
Class-Map
Configuration
Mode
Class-Map
Configuration
Mode
Class-Map
Configuration
Mode
Class-Map
Configuration
Mode
Specifies a traffic classification rule based on the destination IP address of packets.
Specifies a traffic classification rule based on the destination IP address of packets.
Specifies a traffic classification rule based on the range of destination ports of L4 packets.
Specifies a traffic classification rule based on the IP Type of Service value in ToS field of packet.
Specifies a traffic classification rule based on the size of packet.
Important:
This is only applicable for static policies.
Class-Map
Configuration
Mode
Class-Map
Configuration
Mode
Context
Configuration
Mode
Context
Configuration
Mode
Traffic Policy
Group
Configuration
Traffic Policy-Map
Configuration
Traffic Policy-Map
Configuration
Specifies a traffic classification rule based on the range of source ports of
L4 packets.
Specifies a traffic classification rule based on the source IP address of packets.
Deletes/creates and enters the Class-Map configuration mode within the current destination context to configure the match rules for packet classification to flow-based traffic policing for a subscriber session flow.
Deletes/creates and enters the Policy-Map configuration mode within the current destination context to configure the flow-based traffic policing for a subscriber session flow.
Assigns the traffic policies, pre-configured in Policy-Map configuration mode, to a Policy Group for flow-based traffic policing to a subscriber session flow.
Specifies the DSCP code value marked in IP header of packet/flow to determine the QoS for traffic policing.
Enables and configures QoS policy for the flow-based traffic policing to subscriber session flow on per-flow basis.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy-Based Management and EV-DO Rev A
EV-DO Rev A with ITC Support ▀
Command Mode
Traffic Policy-Map
Configuration
Description
Indicates 3GPP2 related traffic flow for data over signaling channel.
Monitor Commands
Exec
Exec
Exec
Exec
Exec
Exec
Exec
Exec
Exec
Exec
Exec
Can be used to verify policy is applied, A10 is added, flow is added, tft is validated, etc.
Can be used to verify signal and data between the PDSN and PCF, and between the PDSN and mobile.
Can be used to verify Session Update Send Reason.
Can be used to verify GRE Key associated with A10 instance.
Can be used to verify RSVP related statistics/counters.
Can be used to verify summary rev-A flow and filter information.
Can be used to verify summary of flow-mapping, QoS profile, and flowbased policy information.
Can be used to verify details of flow-mapping.
Can be used to verify access technology.
Can be used to verify subscriber policy.
Can be used to verify details of installed traffic flow template.
DSCP Marking Commands
Policy CLI commands are used to configure the policy for the Differentiated Services Code Point (DSCP) marking.
DSCP marking includes configurations to set the DSCP for the inner or outer packet or to copy the inner marking to the outer packet.
DSCP markings are applied to signaling and bearer packets destined for the Radio Network Controller (RNC) (in the forward direction) and to the Application Server (AS) in the reverse direction.
The Command Line Interface Reference includes several chapters with more specific information about commands needed to configure DSCP. Refer to the following chapters:
Class-map Configuration Mode Commands
Traffic Policy-map Configuration Mode Commands
Traffic Policy-group Configuration Mode Commands
PDSN Service Configuration Mode Commands
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Chapter 30
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:
IP Pool-based Next Hop Forwarding
Subscriber-based Next Hop Forwarding
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Policy Forwarding
▀ Overview
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy Forwarding
IP Pool-based Next Hop Forwarding ▀
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 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:
Save the configuration as described in the Saving Your Configuration chapter.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Policy Forwarding
▀ Subscriber-based Next Hop Forwarding
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:
Save the configuration as described in the Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Policy Forwarding
ACL-based Policy Forwarding ▀
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:
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
to the host at 192.168.23.12:
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ ACL-based Policy Forwarding
Applying the ACL to a Destination Context
Step 1
At the context configuration mode prompt, enter the following command:
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:
Policy Forwarding
Step 2
Set parameters for outbound data by applying the following example configuration:
Step 3
Save the configuration as described in the Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 31
Pre-paid Billing
This chapter provides information on configuring an enhanced, or extended, service. The product administration guides provides 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.
This chapter includes the following topics:
Configuring Standard 3GPP2 Pre-paid Billing
Configuring Pre-paid Billing With Custom Behavior
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Pre-paid Billing
▀ Overview
Overview
The system supports pre-paid billing for subscriber accounts that use RADIUS Accounting. 3GPP2 pre-paid billing support is disabled by default and you must obtain and install a license key to enable it.
The system supports two methods of implementing Pre-paid Billing Support; Standard 3GPP2 Pre-paid Billing and
Custom Pre-paid Billing. The 3GPP2 standard is the recommended implementation.
3GPP2 Standard Pre-paid Billing Overview
The prepaid packet data service allows a user to purchase access to the network in advance, based on either volume or duration. When a user connects to a service, the Prepaid Client (PPC) contacts the Prepaid Server (PPS) and verifies that the user has available credits for the service. When a user runs out of credits, service is terminated until the user purchases additional credits.
The Prepaid Data Service implementation is compliant with 3GPP2 IS-835-C. This solution provides a standards based implementation that can effectively interoperate with additional vendors equipment when required. The system primarily uses the PPAC (PrePaid Accounting Capability) and PPAQ (PrePaid Accounting Quota) VSAs to implement
PrePaid service. The PPAC VSA is used to determine the capabilities of the PPC. When the PPC sends the PPAC VSA it specifies if it supports duration, volume or both types of PrePaid service. When the PPS sends a PPAC VSA it specifies the type of PrePaid service to use for the particular session. The PPAQ VSA specifies the characteristics of the
PrePaid accounting service. This includes quota & threshold values for both duration and volume PrePaid service.
Through the use of these VSAs, the PPC and PPS communicate the status of the session and when the user has run out of quota, the service can be terminated.
The PrePaid Client resides on the system and communicates with the PPS through the use of RADIUS messages exchanged with the RADIUS server.
Custom Pre-paid Billing Overview
In the Access-Accept from the RADIUS server the system receives attributes which indicate the number of byte credits available for the subscriber. Byte throughput can be pre-paid for traffic inbound to the system, outbound from the system, or an amount that combines both inbound and outbound traffic. Five attributes are used: one for traffic inbound to the system, one for traffic outbound from the system, one that combines traffic in both directions, one that only indicates that the user should be re-authenticated regardless of the byte counters, and one for the low watermark in percent.
The low watermark value is multiplied by the number of byte credits granted in the Access-Accept to arrive at a threshold. Once the number of byte credits remaining is lower than this number, a new Access-Request is issued. If the
Access-Request is issued because the Low Watermark has been reached, then a new Low Watermark is calculated from the number of byte credits granted in the Access-Accept, but only if the number of byte credits granted is a non-zero value. If the Access-Request is issued for any other reason, then the Low Watermark is not re-calculated.
The system re-authorizes an active subscriber that has used up its byte credits by issuing a RADIUS Access-Request to the RADIUS server. A valid Access-Reject or a RADIUS timeout results in immediate disconnect of the subscriber session. An Access-Accept without attributes that authorize more byte credits allows the subscriber session to continue
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Pre-paid Billing
Overview ▀
with the remaining credits. An Access-Accept with attributes containing byte credits results in the addition of these byte credits to the subscriber session, and the continuation of the session until the subscriber session byte credits have been reduced to the low watermark received in the access accept. If not received, it defaults to 10%.
The system continues to service the subscriber session while the RADIUS request for re-authorization is in process. If the counter reaches zero before the response the subscriber session is terminated immediately.
You can configure Pre-paid Billing support for standard 3GPP2 behavior or custom behavior where you can specify whether or to measure the bye-count on compressed or non-compressed data, set a low-watermark for accounting, and specify a credit renewal interval in the default subscriber configuration for a context or a domain alias.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Pre-paid Billing
▀ Configuring Standard 3GPP2 Pre-paid Billing
Configuring Standard 3GPP2 Pre-paid Billing
This section describes how to enable standard 3GPP2 pre-paid billing support.
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.
Enable pre-paid billing for the default subscriber by applying the following example configuration:
Enable pre-paid billing for the default subscriber of a domain alias by applying the following example configuration:
Notes:
You may add the optional keyword to the command to stop sending the final online access-request on termination of 3GPP2 prepaid sessions.
Optional commands: If both duration and volume attributes are received, default preference is given to the duration attribute. To set the preference to the volume attribute, enter the following command:
Note that this command alone does not enable pre-paid support. The command must be executed as shown to enable pre-paid support.
If you are using duration-based quota usage accounting, use the following command to define what behavior specifies the end of the billing duration. The default behavior is the duration quota algorithm set to currenttime.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Pre-paid Billing
Configuring Standard 3GPP2 Pre-paid Billing ▀
Note that this command alone does not enable pre-paid support. The command must be executed as shown to enable pre-paid support.
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Pre-paid Billing
▀ Configuring Pre-paid Billing With Custom Behavior
Configuring Pre-paid Billing With Custom Behavior
This section describes how to enable Pre-paid billing support with custom behavior.
Important:
If RADIUS attributes are present that conflict with the custom pre-paid settings, the values set by the
RADIUS attributes take precedence.
Important:
Pre-paid billing support is not available for local subscribers. Even though you can set pre-paid parameters for a local subscriber from the CLI, these settings have no effect on a subscriber session.
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.
Enable custom pre-paid billing for the default subscriber by applying the following example configuration:
Enable custom pre-paid billing for the default subscriber of a domain alias by applying the following example configuration:
Notes:
Optional: To have custom pre-paid byte credits based on the flow of compressed traffic, use the following command:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Pre-paid Billing
Configuring Pre-paid Billing With Custom Behavior ▀
Optional: Set the low-watermark for remaining byte credits. This is a percentage of the subscriber session‘s total credits. When the low-watermark is reached a new RADIUS access-request is sent to the RADIUS server to retrieve more credits. To set the low watermark percentage, enter the following command:
Optional: Set the time in seconds to wait before sending a new RADIUS access-request to the RADIUS server to retrieve more credits by entering the following command:
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Pre-paid Billing
▀ 3GPP2 Pre-paid Attributes
3GPP2 Pre-paid Attributes
Attribute
Use the attributes listed in the following table to configure a subscriber for 3GPP2 pre-paid billing;
Sub-attribute Description
This attribute is for setting the prepaid accounting capability. 3GPP2-Pre-Paid-
Acct-Capability
Available-In-
Client
3GPP2-Pre-Paid-
Accounting-
Quota
Selected-For-
Session
Quota-
Identifier
Volume-
Quota
Volume-
Quota-
Overflow
Volume-
Threshold
Volume-
Threshold-
Overflow
Duration-
Quota
The optional Available-In-Client Sub-Type, generated by the PrePaid client, indicates the
PrePaid Accounting capabilities of the client in the PDSN or HA and shall be bitmap encoded.
The optional Selected-For-Session Sub-Type, generated by the PrePaid server, indicates the
PrePaid Accounting capability to be used for a given session.
This attribute specifies the characteristics for PrePaid accounting of the volume and/or duration of a packet data session. It shall be present in all on-line RADIUS Access-Request and on-line RADIUS Access-Accept messages and may be included in other RADIUS
Access-Accept messages. Non-used Sub-Types by the PPC and PPS shall be omitted.
The Quota-Identifier Sub-Type is generated by the PrePaid server at allocation of a Volume and/or Duration Quota. The on-line quota update RADIUS Access-Request message sent from the PPC to the PPS shall include a previously received Quota-Identifier.
The optional Volume-Quota Sub-Type is only present if Volume Based charging is used. In
RADIUS Access-Accept message (PPS to PPC direction), it indicates the Volume (in octets) allocated for the session by the PrePaid server. In on-line RADIUS Access-Request message
(PPC to PPS direction), it indicates the total used volume (in octets) for both forward and reverse traffic applicable to PrePaid accounting13. If a Tariff Switch condition was reached during the session, this Sub-Type contains the complete (before and after) volume used, while the Volume-Used-After-Tariff-Switch attribute contains the volume used after the tariff switch condition.
The optional Volume-Quota-Overflow Sub-Type is used to indicate how many times the
Volume-Quota counter has wrapped around 2^32 over the course of the service being provided.
The Volume-Threshold Sub-Type shall always be present if Volume-Quota is present in a
RADIUS Access-Accept message (PPS to PPC direction). It is generated by the PrePaid server and indicates the volume (in octets) that shall be used before requesting quota update.
This threshold should not be larger than the Volume-Quota.
The optional Volume-Threshold-Overflow Sub-Type is used to indicate how many times the
Volume-Threshold counter has wrapped around 2^32 over the course of the service being provided.
The optional Duration-Quota Sub-Type is only present if Duration Based charging is used.
In RADIUS Access-Accept message (PPS to PPC direction), it indicates the Duration (in seconds) allocated for the session by the PrePaid server. In on-line RADIUS Access-Accept message (PPC to PPS direction), it indicates the total Duration (in seconds) since the start of the accounting session related to the Quota-ID.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Pre-paid Billing
3GPP2 Pre-paid Attributes ▀
Attribute Sub-attribute Description
Duration-
Threshold
Update-
Reason
The Duration-Threshold Sub-Type shall always be present if Duration-Quota is present in a
RADIUS Access-Accept message (PPS to PPC direction). It represents the duration (in seconds) that shall be used by the session before requesting quota update. This threshold should not be larger than the Duration-Quota and shall always be sent with the Duration-
Quota.
The Update-Reason Sub-Type shall be present in the on-line RADIUS Access-Request message (PPC to PPS direction). It indicates the reason for initiating the on-line quota update operation. Update reasons 4, 5, 6, 7 and 8 indicate that the associated resources are released at the client side, and therefore the PPS shall not allocate a new quota in the RADIUS
Access-Accept message.
Pre-Paid-
Server
The optional, multi-value PrePaid-Server indicates the address of the serving PrePaid
System. If present, the Home RADIUS server uses this address to route the message to the serving PrePaid Server. The attribute may be sent by the Home RADIUS server. If present in the incoming RADIUS Access-Accept message, the PDSN shall send this attribute back without modifying it in the subsequent RADIUS Access-Request message, except for the first one. If multiple values are present, the PDSN shall not change the order of the attributes.
These attributes can be found in the following dictionaries:
3gpp2
3gpp2-835 starent starent-835 starent-vsa1 starent-vsa1-835
For more information, refer to the AAA Interface Administration and Reference.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Pre-paid Billing
▀ Pre-paid Attributes
Pre-paid Attributes
Use the attributes listed in the following table to configure a subscriber for pre-paid billing;
Attribute
SN-Prepaid-
Inbound-Octets
SN-Prepaid-
Outbound-Octets
SN-Prepaid-
Total-Octets
SN-Prepaid-
Timeout
Description
If only SN-Prepaid-Inbound-Octets is in the Access-Accept, and the others are not, then the number of outbound credits is infinite.
If only SN-Prepaid-Outbound-Octets is in the Access-Accept, and the others are not, then the number of inbound credits is infinite.
If only SN-Prepaid-Total-Octets is in the Access-Accept, and the others are not, then pre-paid credits is only enforced on the total byte throughput.
SN-Prepaid-Timeout can be used alone or in combination with the other attributes. This integer RADIUS attribute includes a time limit in seconds. Regardless of the values of the Octet counters, the session should send a new authorization request upon timer expiration.
SN-Prepaid-
Watermark
SN-Prepaid-Watermark is optional with any of the attributes. If it is not included it defaults to the CLI default subscriber configuration, which defaults to a value of 10%. This watermark applies to any of the pre-paid attributes being enforced.
These attributes can be found in the following dictionaries:
Starent
Starent-VSA1
Starent-835
Starent-VSA1-835 custom1 through custom9
Refer to the AAA Interface Administration and Reference for more details.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 32
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:
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
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Proxy-Mobile IP
▀ Overview
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.
Table 35. 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 Proxy MIP HA Failover
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 Proxy MIP HA Failover
Configuring Subscriber Profile RADIUS Attributes
RADIUS Attributes Required for Proxy Mobile IP
Configuring Default Subscriber Parameters in Home Agent Context
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Overview ▀
Applicable Product(s) Refer to Sections
ASN GW
Proxy Mobile IP in WiMAX Service
How Proxy Mobile IP Works in WiMAX Network
Configuring Proxy MIP HA Failover
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 Proxy MIP HA Failover
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ Overview
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in 3GPP2 Network ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Proxy-Mobile IP
▀ How Proxy Mobile IP Works in 3GPP2 Network
Figure 46. AAA/PDSN Assigned IP Address Proxy Mobile IP Call Flow
MN
1
BSC/PCF
2
3
4
AAA
5
10
12
7
8
15
17
19
21
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
9
11
14
DATA
16
13
20
HA
Internet or PDN
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in 3GPP2 Network ▀
Table 36. 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
3
4
5
6
The PCF and PDSN/FA establish the R-P interface for the session.
The PDSN/FA and MN negotiate Link Control Protocol (LCP).
Upon successful LCP negotiation, the MN sends a PPP Authentication Request message to the PDSN/FA.
The PDSN/FA sends an Access Request message to the RADIUS AAA server.
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
8
9
The PDSN/FA sends a PPP Authentication Response message to the MN.
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.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ How Proxy Mobile IP Works in 3GPP2 Network
Proxy-Mobile IP
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Figure 47. HA Assigned IP Address Proxy Mobile IP Call Flow
How Proxy Mobile IP Works in 3GPP2 Network ▀
OL-22983-01
MN
BSC/PCF
1
2
3
4
10
12
7
8
15
17
19
5
AAA
9
11
14
DATA
16
13
HA
Internet or PDN
21
20
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Proxy-Mobile IP
▀ How Proxy Mobile IP Works in 3GPP2 Network
Table 37. 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
3
4
5
6
The PCF and PDSN/FA establish the R-P interface for the session.
The PDSN/FA and MN negotiate Link Control Protocol (LCP).
Upon successful LCP negotiation, the MN sends a PPP Authentication Request message to the PDSN/FA.
The PDSN/FA sends an Access Request message to the RADIUS AAA server.
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
8
The PDSN/FA sends a PPP Authentication Response message to the MN.
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-ofaddress), 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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in 3GPP Network ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ How Proxy Mobile IP Works in 3GPP Network
Figure 48. Proxy Mobile IP Call Flow in 3GPP
Proxy-Mobile IP
Table 38. Proxy Mobile IP Call Flow in 3GPP Description
Step Description
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in 3GPP Network ▀
Step Description
1
2
3
The mobile station (MS) goes through the process of attaching itself to the GPRS/UMTS network.
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.
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
5
6
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).
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.
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
8
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)).
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.
The HA sends an RADIUS Accounting Start request to the AAA server which the AAA server responds to. 9
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ How Proxy Mobile IP Works in 3GPP Network
Step Description
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in WiMAX Network ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Proxy-Mobile IP
▀ How Proxy Mobile IP Works in WiMAX Network
Figure 49. AAA/ASN GW Assigned IP Address Proxy Mobile IP Call Flow
MN
1
BSC/PCF
2
3
4
AAA
5
10
12
7
8
15
17
19
21
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
9
11
14
DATA
16
13
20
HA
Internet or PDN
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in WiMAX Network ▀
Table 39. 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
3
4
5
6
The BS and ASN GW/FA establish the R6 interface for the session.
The ASN GW/FA and MN negotiate Link Control Protocol (LCP).
Upon successful LCP negotiation, the MN sends a PPP Authentication Request message to the ASN GW/FA.
The ASN GW/FA sends an Access Request message to the RADIUS AAA server.
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
8
9
The ASN GW/FA sends a EAP Authentication Response message to the MN.
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.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ How Proxy Mobile IP Works in WiMAX Network
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Figure 50. HA Assigned IP Address Proxy Mobile IP Call Flow
How Proxy Mobile IP Works in WiMAX Network ▀
OL-22983-01
MN
BSC/PCF
1
2
3
4
10
12
7
8
15
17
19
5
AAA
9
11
14
DATA
16
13
HA
Internet or PDN
21
20
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Proxy-Mobile IP
▀ How Proxy Mobile IP Works in WiMAX Network
Table 40. 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
3
4
5
6
The BS and ASN GW/FA establish the R6 interface for the session.
The ASN GW/FA and MN negotiate Link Control Protocol (LCP).
Upon successful LCP negotiation, the MN sends an EAP Authentication Request message to the ASN GW/FA.
The ASN GW/FA sends an Access Request message to the RADIUS AAA server.
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
8
The ASN GW/FA sends an EAP Authentication Response message to the MN.
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 careof-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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication
Figure 51. Proxy-MIP Call Setup using CHAP Authentication
Proxy-Mobile IP
Table 41. Proxy-MIP Call Setup using CHAP Authentication
Step Description
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication ▀
Step Description
1
2
3
4
On connecting to WiFi network, MS first send DNS query to get PDIF IP address
MS receives PDIF address from DNS
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.
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
6
7
8
9
10
11
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.
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.
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.
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.
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.
PDIF sends the IKE_AUTH Response back to MS with the EAP payload.
12
13
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.
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
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).
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication
Step Description
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.
19
20
21
16
17
18
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.
PDIF receives Access Accept from RADIUS and sends IKE_AUTH Response with EAP success.
PDIF receives the final IKE_AUTH Request with AUTH payload.
PDIF checks the validity of the AUTH payload and initiates Proxy-MIP setup request to the Home Agent if
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.
22
If is disabled, PDIF assigns the IP address from the local pool.
PDIF received proxy-MIP RRP and gets the IP address and DNS addresses.
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.
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Figure 52. Proxy-MIP Call Setup using PAP Authentication
How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication ▀
Table 42. 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ Configuring Proxy Mobile-IP Support
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Configuring Proxy Mobile-IP Support ▀
Notes:
The 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.
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.
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 command 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 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:
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.
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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ Configuring Proxy Mobile-IP Support
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:
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.
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 and
keywords should only be configured when supporting Proxy Mobile IP.
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Configuring Proxy Mobile-IP Support ▀
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.
Table 43. Required RADIUS Attributes for Proxy Mobile IP
Attribute
SN-Subscriber-
Permission
OR
SN1-Subscriber-
Permission
Description
Indicates the services allowed to be delivered to the subscriber.
For Proxy Mobile IP, this attribute must be set to Simple IP.
Values
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)
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ Configuring Proxy Mobile-IP Support
Attribute
SN-Simultaneous-
SIP-MIP
OR
SN1-
Simultaneous-
SIP-MIP
SN-PDSN-
Handoff- Req-IP-
Addr
OR
SN1-PDSN-
Handoff- Req-IP-
Addr
3GPP2-MIP-HA-
Address
Description
Indicates whether or not a subscriber can simultaneously access both Simple
IP and Mobile IP services.
Values
Disabled (0)
Enabled (1)
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.
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 Interchassis 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 Interchassis handoff.
This attribute is disabled (do not reject) by default.
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.
Disabled - do not reject (0)
Enabled - reject (1)
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.
Verify that your settings for the subscriber(s) just configured are correct.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Configuring Proxy Mobile-IP Support ▀
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
command.
Optional: If you have enabled the Proxy-MIP HA Failover feature, use the
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.
Note case sensitive.
is the name of the subscriber and can be from 1 to 127 alpha and/or numeric characters and is
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:
Save your configuration as described in Verifying and Saving Your Configuration.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Proxy-Mobile IP
▀ Configuring Proxy Mobile-IP Support
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:
Step 1
Enter the configuration mode by entering the following command:
The following prompt appears:
Step 2
Enter context configuration mode by entering the following command:
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:
Step 3
Enter the configuration mode for the desired APN by entering the following command:
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:
Step 4
Enable proxy Mobile IP for the APN by entering the following command:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Proxy-Mobile IP
Configuring Proxy Mobile-IP Support ▀
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:
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:
The following prompt appears:
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:
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Chapter 33
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:
Network Controlled QoS (NCQoS)
Configuring Dynamic QoS Renegotiation
Configuring Network Controlled QoS (NCQoS)
Monitoring Dynamic QoS Renegotiation Operation
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
QoS Management
▀ Introduction
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
QoS Management
Dynamic QoS Renegotiation ▀
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 ST16 and ASR 5000 supports 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
QoS Management
▀ Dynamic QoS Renegotiation
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 ST16 and ASR
5000, 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
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
QoS Management
Dynamic QoS Renegotiation ▀
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 ST16 and ASR 5000 supports 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 the subscriber attaches to the network, following things happen:
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
QoS Management
▀ Dynamic QoS Renegotiation
5.
Dynamic QoS Renegotiation graph
When there is no traffic, traffic class drops to ―Background‖, and the corresponding QoS profile will negotiated as described above.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
QoS Management
Network Controlled QoS (NCQoS) ▀
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.
W
ARNING
:
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.
OL-22983-01
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 chargingactions 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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
QoS Management
▀ Network Controlled QoS (NCQoS)
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
QoS Management
Configuring Dynamic QoS Renegotiation ▀
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
section.
Step 2
Configure an APN for Dynamic QoS Renegotiation as described in the Configuring APNs for Dynamic QoS
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:
OL-22983-01
Notes:
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
QoS Management
▀ Configuring Dynamic QoS Renegotiation
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:
Notes:
A maximum of eight packet filters can be configured per charging action.
Configuring Rulebase for Dynamic QoS Renegotiation
Use the following example to configure rulebase parameters for Dynamic QoS Renegotiation support:
Configuring APNs for Dynamic QoS Renegotiation
Use the following example to configure an APN template‘s QoS profile in support of Dynamic QoS Renegotiation:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
QoS Management
Configuring Dynamic QoS Renegotiation ▀
Notes:
must be the name of the destination context in which you have already configured the
ACL, and want to configure the APN template.
must be the name of the ACL that you have already configured in the context.
If in the command of the APN Configuration Mode, the optional or not specified, the ACL will be applied to all packets, in and out.
keywords are
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
QoS Management
▀ Configuring Network Controlled QoS (NCQoS)
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
Step 3
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:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
QoS Management
Configuring Network Controlled QoS (NCQoS) ▀
Configuring Charging Action for NCQoS
Use the following example to configure charging action parameters for NCQoS support:
Notes:
A number of optional keywords and variable are available for the
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:
Notes:
To enable NCQoS, bearer-control-mode in the APN Configuration Mode must be configured with mode.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
QoS Management
▀ Monitoring Dynamic QoS Renegotiation Operation
Monitoring Dynamic QoS Renegotiation Operation
Use the following steps to verify/monitor Dynamic QoS Renegotiation operations:
Step 1
Verify that your APNs were configured properly by entering the following command:
The output is a listing of APN parameter settings.
Step 2
Verify that the ACLs have been properly applied by entering the following command:
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.
Step 3
Verify that your ACL was configured properly by entering the following command:
The output is a concise listing of IP Access Control List parameter settings.
Step 4
Monitor your QoS renegotiation status for a subscriber by entering the following command:
The output is a concise listing of subscribers‘ settings.
Step 5
For L7 based QoS Renegotiation, view how many time QoS renegotiations have happened for that session by entering the following command:
Step 6
View the statistics of APN related to QoS renegotiation parameters by entering the following command:
The output is a listing of APN statistics related to QoS Renegotiation.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
QoS Management
Monitoring Dynamic QoS Renegotiation Operation ▀
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.
Table 44. Event IDs in Session Manager Pertaining to Dynamic QoS Renegotiation
Event
QoS Renegotiation timer started for subscriber
QoS Renegotiation timer stopped for subscriber
QoS Renegotiation timer expired for subscriber
QoS Renegotiation message sent for subscriber
L4 classification done for subscriber traffic
Event
ID
Type Additional Information
10917 Info ―Indicates that the Dynamic QoS Renegotiation timer was started for the subscriber‖
10918 Info ―Indicates that the Dynamic QoS Renegotiation timer was stopped for the subscriber‖
10919 Info ―Indicates that the Dynamic QoS Renegotiation timer was expired for the subscriber‖
10920 Info ―Indicates that the Dynamic QoS Renegotiation message was sent for the subscriber‖
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 Interface
Administration and Reference.
Table 45. RADIUS Attributes Required for Dynamic QoS Renegotiation Support
Attribute
SN-Enable-QoS-Renegotiation
(or SN1-Enable-QoS-Renegotiation)
SN-QoS-Renegotiation-Timeout
(or SN1-QoS-Renegotiation-
Timeout)
Description
Enables the Dynamic QoS Renegotiation for specific profile application.
This attribute displays ―enable qos renegotiation‖.
Timeout duration for dampening time for QoS renegotiation to specific profile application.
This attribute displays ―qos renegotiation timeout‖.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Chapter 34
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:
Configuring HA Session Redirection
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Rejection/Redirection of HA Sessions on Network Failures
▀ Overview
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.)
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Rejection/Redirection of HA Sessions on Network Failures
Configuring HA Session Redirection ▀
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:
Step 1
Enter the global configuration mode by entering the following command:
The following prompt appears:
Step 2
Enter context configuration mode by entering the following command:
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:
Step 3
Enter the HA service configuration mode by entering the following command: and is case sensitive.
is the name of the HA service. The name must be from 1 to 63 alpha and/or numeric characters
The following prompt appears:
Step 4
Configure the action for the HA service to take when network connectivity is lost by entering the following command:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Rejection/Redirection of HA Sessions on Network Failures
▀ Configuring HA Session Redirection
Keyword/Variable Description
Upon network reachability failure reject all new calls for this context.
When rejecting calls send the specified reject code. If this keyword is not specified the admin-prohibited reject code is sent by default.
Upon network reachability failure redirect all calls to the specified IP address.
< >: This must be an IPv4 address. Up to 16 IP addresses and optional weight values can be entered on one command line.
< >: 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. < > must be an integer from 1 through 10.
Step 5
Enter the following command to return to the context configuration mode:
The following prompt appears:
Step 6
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:
Keyword/Variable Description
A name for the network device that is sent ping packets to test for network reachability.
Default: 60 seconds
Specifies the frequency in seconds for sending ping requests.< from 1 through 3600.
> must be an integer
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Rejection/Redirection of HA Sessions on Network Failures
Configuring HA Session Redirection ▀
Keyword/Variable Description
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. < be an IP v4 address.
> must
Default: 5
Specifies the number of retries before deciding that there is a network-failure. < an integer from 0 through 100.
> must be
Specifies the IP address of a network element to use as the destination to send the ping packets for detecting network failure or reachability. < > must be an IPv4 address.
Default: 3 seconds
Specifies how long to wait, in seconds, before retransmitting a ping request to the remote address. < > must be an integer from 1 through 10.
Step 7
Repeat step 6 to configure additional network reachability servers.
Step 8
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.
Step 9
To bind a network reachability server name to an IP pool, enter the following command:
The name of an existing IP pool in the current context.
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.
< >: 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.
Step 10 Repeat step 9 for additional IP pools in the current context then skip to step 13.
Step 11 Enter the subscriber configuration mode by entering the following command:
OL-22983-01
Where is the default subscriber for the current context and that you want to configure for network reachability.
The following prompt appears:
is the name of the subscriber profile
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Rejection/Redirection of HA Sessions on Network Failures
▀ Configuring HA Session Redirection
Step 12 To bind a network reachability server name to the current subscriber in the current context, enter the following command:
Where is the name of a network reachability server that has been defined in the current context.
Step 13 Return to the executive mode by entering the following command:
The following prompt appears:
Step 14 Enter the executive mode for the destination context for which you configured network reachability by entering the following command:
Where is the name of the destination context for which you configured network reachability.
The following prompt appears:
Step 15 Check the network reachability server configuration by entering the following command
The output of this command appears similar to the following:
Ensure that the remote and local addresses are correct. The state column indicates whether or not the server is reachable
(Up) or unreachable (Down).
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Rejection/Redirection of HA Sessions on Network Failures
Configuring HA Session Redirection ▀
Step 16 Check the HA service policy by entering the following command:
Where < network reachability policy.
> is the name of the HA service in the current context for which you configured a
The output of this command includes information about the network reachability policy that looks similar to the following:
Step 17 Check the network reachability server name bound to an IP pool by entering the following command:
Where < > 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:
Step 18 Check the network reachability server name bound to a local subscriber profile by entering the following command:
Where < name.
> is the name of the local subscriber to which you bound a network reachability server
The output of this command includes information about the network reachability server name that looks similar to the following:
Step 19 Save your configuration as described in Verifying and Saving Your Configuration.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Rejection/Redirection of HA Sessions on Network Failures
▀ RADIUS Attributes
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;
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 attribute is contained in the following dictionaries: starent starent-835
The attribute is contained in the following dictionaries: starent-vsa1 starent-vsa1-835
Refer to the AAA Interface Administration and Reference for more details.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 35
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:
Configuring Remote Address-based Accounting
Subscriber Attribute Configuration
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Remote Address-based RADIUS Accounting
▀ Overview
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Remote Address-based RADIUS Accounting
Configuring Remote Address-based Accounting ▀
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:
Verifying the Remote Address Lists
Use the following command to verify the remote address lists:
Output similar to the following is displayed.
OL-22983-01
Notes:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Remote Address-based RADIUS Accounting
▀ Configuring Remote Address-based Accounting
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Remote Address-based RADIUS Accounting
Subscriber Attribute Configuration ▀
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 AAA 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:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Remote Address-based RADIUS Accounting
▀ Subscriber Attribute Configuration
Notes:
Save your configuration as described in Verifying and Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 36
Routing
This chapter provides information on configuring an enhanced, or extended, service. The product administration guides provide examples and procedures for configuration 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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Routing
▀ Routing Policies
Routing Policies
This section describes how to configure the elements you need to specify routing policies. Routing policies modify and redirect routes to and from the system to satisfy specific routing needs.
Use the following building blocks to configure routing policies:
Route Access Lists - The basic building block of a routing policy. Route access lists filter routes based upon a specified range of IP addresses.
IP Prefix Lists - A more advanced element of a routing policy. An IP Prefix list filters routes based upon IP prefixes.
AS Path Access Lists - A basic building block used for Border Gateway Protocol (BGP) routing. These lists filter Autonomous System (AS) paths.
Route Maps - Route-maps provide detailed control over routes during route selection or route advertisement by a routing protocol, and in route redistribution between routing protocols. For this level of control you use IP
Prefix Lists, Route Access Lists and AS Path Access Lists to specify IP addresses, address ranges, and
Autonomous System Paths.
Creating IP Prefix Lists
Use the following configuration example to create IP Prefix Lists:
Notes:
Set the IP prefix list to deny, permit or match any prefix.
IPv4 and IPv6 addresses are supported.
Save your configuration as described in Saving your Configuration.
Creating Route Access Lists
Use the following procedure to create a Route Access List:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Routing
Routing Policies ▀
Notes:
A maximum of 64 access lists are supported per context.
Save your configuration as described in Verifying and Saving Your Configuration.
Creating AS Path Access Lists
Use the following procedure to create an AS Path Access List:
Notes:
Save your configuration as described in Verifying and Saving Your Configuration.
Creating Route Maps
Use the following configuration example to create a Route Map:
Notes:
Use the match and set commands in Route Map Configuration mode to configure the route map. Refer to the
ASR 5000 Series Command Line Interface Reference for more information on these commands.
Save your configuration as described in Verifying and Saving Your Configuration.
Sample Configuration
The example below shows a configuration that creates two route access lists, applies them to a route map, and uses that route map for a BGP router neighbor.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Routing
▀ Routing Policies
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Routing
Static Routing ▀
Static Routing
The system supports static network route configuration on a per context basis. Define network routes by specifying an
IP address and mask for the route, the name of the interface in the currant context that the route must use, and a next hop
IP address.
Adding Static Routes to a Context
To add static routes to a context configuration, you must know the names of the interfaces that are configured in the current context. Use the following command to list the interfaces in the current context:
Information for all interfaces configured in the current context is displayed as shown in the following example.
OL-22983-01
The first line of information for each interface lists the interface name for the current context as shown in the example output. In this case, there is one interface with the name Egress 1.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Routing
▀ Static Routing
Notes:
You can configure a maximum of 1200 static routes per context. Save your configuration as described in Verifying and
Saving Your Configuration.
Deleting Static Routes From a Context
Use the following configuration example to remove static routes from a contexts configuration:
Notes:
Save your configuration as described in Verifying and Saving Your Configuration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Routing
OSPF Routing ▀
OSPF Routing
This section gives an overview of OSPF (Open Shortest Path First) routing and its implementation in the system. It also provides the procedure for enabling the base OSPF functionality, and lists the commands that are available for more complex configuration.
OSPF routing is included with the IPV4 Routing Protocols feature. You must purchase and install a license key before you can use this feature.
Important:
During system task recovery, it is possible for a dynamically-learned forwarding entry to incorrectly remain in the system forwarding table if that forwarding entry has been removed from the dynamic routing protocol during the recovery.
OSPF Version 2 Overview
OSPF is a link-state routing protocol, an interior gateway protocol (IGP) that routes IP packets using the shortest path first based solely on the destination IP address in the IP packet header. IP packets are routed are not encapsulated in any further protocol headers as they transit the network. An Autonomous System (AS), or Domain, is defined as a group of networks within a common routing infrastructure.
OSPF is a dynamic routing protocol that quickly detects topological changes in the AS (such as router interface failures) and calculates new loop-free routes after a period of convergence. This period of convergence is short and involves a minimum of routing traffic.
In a link-state routing protocol, each router maintains a database, referred to as the link-state database, that describes the
Autonomous System's topology.Each participating router has an identical database. Each individual piece of this database is a particular router's local state (for example, the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the Autonomous System by flooding.
All routers run the same algorithm in parallel. From the link-state database, each router constructs a tree of shortest paths with itself as root to each destination in the Autonomous System. Externally derived routing information appears on the tree as leaves. The cost of a route is described by a single dimensionless metric.
OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of this area is hidden from the rest of the AS, which enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area‘s own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network.
OSPF enables the flexible configuration of IP subnets so that each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (that is, different masks). This is commonly referred to as variable-length subnetting. A packet is routed to the best (longest or most specific) match. Host routes are considered to be subnets whose masks are ―all ones‖ (0xffffffff).
OSPF traffic can be authenticated or non-authenticated, or can use no authentication, simple/clear text passwords, or
MD5-based passwords. This means that only trusted routers can participate in the Autonomous System‘s routing. You can specify a variety of authentication schemes and, in fact, you can configure separate authentication schemes for each
IP subnet.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Routing
▀ OSPF Routing
Externally derived routing data (for example, routes learned from an exterior protocol such as BGP ) is advertised throughout the AS. This externally derived data is kept separate from the OSPF protocol‘ s link state data. Each external route can also be tagged by the advertising router, enabling the passing of additional information between routers on the boundary of the AS.
Link-State Algorithm
OSPF uses a link-state algorithm in order to build and calculate the shortest path to all known destinations. The algorithm by itself is quite complicated. The following is a very high level, simplified way of looking at the various steps of the algorithm:
1. Upon initialization or update in routing information, an OSPF-enabled router generates a link-state advertisement (LSA). This LSA represents the collection of all link-states on that router.
2. All routers exchange link-states by means of flooding. Each router that receives a link-state update stores a copy in its link-state database and then propagates the update to other routers.
3. After the database of each router is completed, the OSPF-enabled router calculates a Shortest Path Tree to all destinations. The router uses the Dijkstra algorithm to calculate the shortest path tree. The algorithm places each router at the root of a tree and calculates the shortest path to each destination based on the cumulative cost required to reach that destination. Each router has its own view of the topology even though all OSPF-enabled routers build a shortest path tree using the same link-state database. The destinations, associated cost, and the next hop to reach those destinations form the IP routing table.
4. If no changes in the OSPF network occur, such as link cost or an added or deleted network, OSPF is quiet. Any changes that occur are communicated via link-state update packets, and the Dijkstra algorithm is recalculated to again find the shortest path.
Basic OSPFv2 Configuration
This section describes how to implement basic OSPF routing functionality.
Enabling OSPF Routing For a Specific Context
Use the following configuration example to enable OSPF Routing for a specific context:
Notes:
Save your configuration as described in Verifying and Saving Your Configuration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Routing
OSPF Routing ▀
Enabling OSPF Over a Specific Interface
After you enable OSPF, specify the networks on which it will run. Use the following command to enable OSPF:
Important:
The default cost for OSPF on the system is 10. To change the cost, refer to the ip ospf cost command in the Ethernet Interface Configuration mode. For detailed information on this command refer to the Cisco ASR 5000
Series Command Line Interface Reference.
Notes:
Save your configuration as described in Verifying and Saving Your Configuration.
Redistributing Routes Into OSPF (Optional)
Redistributing routes into OSPF means any routes from another protocol that meet specified a specified criterion, such as route type, metric, or rule within a route-map, are redistributed using the OSPFv2 protocol to all OSPF areas. This is an optional configuration.
Notes:
Save your configuration as described in Verifying and Saving Your Configuration.
Confirming OSPF Configuration Parameters
To confirm the OSPF router configuration, use the following command and look for the section labeled router ospf in the screen output:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Routing
▀ Viewing Routing Information
Viewing Routing Information
To view routing information for the current context, at the Executive mode level, use one of the following commands; show ip route: Display information for all types of routes in the current contexts routing table. show ip static-route: Display information only for static routes in the current contexts routing table. show ip ospf: Display OSPF process summary information in the current context.
This example shows sample output of the command, show ip route.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Routing
Equal Cost Multiple Path (ECMP) ▀
Equal Cost Multiple Path (ECMP)
The system supports ECMP for routing protocols. ECMP distributes traffic across multiple routes that have the same cost to lessen the burden on any one route.
Notes:
Save your configuration as described in Verifying and Saving Your Configuration.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Routing
▀ BGP-4 Routing
BGP-4 Routing
The Border Gateway Protocol 4 (BGP-4) routing protocol is supported through a BGP router process that is implemented at the context level.
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. An Autonomous System (AS) is a set of routers under a single technical administration that use an interior gateway protocol and common metrics to route packets within the AS. The set of routers uses an exterior gateway protocol to route packets to other ASs.
BGP runs over TCP. This eliminates the need for the BGP protocol to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing information. Any authentication scheme used by TCP may be used in addition to BGP‘s own authentication mechanisms.
BGP routers exchange network reachability information with other BGP routers. This information builds a picture of AS connectivity from which routes are filtered and AS level policy decisions are enforced.
BGP-4 provides classless inter-domain routing. This includes support for advertising an IP prefix and eliminates the concept of network class within BGP. BGP-4 also allows the aggregation of routes, including the aggregation of AS paths.
Overview of BGP Support
When using Mobile IP, mobile devices communicate to the Internet through Home Agents (HAs). HAs assign IP addresses to the mobile node from a configured pool of addresses. These addresses are also advertised to Internet routers through an IP routing protocol to ensure dynamic routing. The BGP-4 protocol is used as a monitoring mechanism between an HA and Internet router with routing to support Interchassis Session Recovery. (Refer to the Interchassis
Session Recovery chapter in this manual for more information.)
The objective of BGP-4 protocol support is to satisfy routing requirements and to monitor communications with Internet routers. BGP-4 may trigger an active to standby switchover to keep subscriber services from being interrupted.
The following BGP-4 features are supported:
Exterior Border Gateway Protocol (EBGP) multi-hop
Route Filtering for inbound and outbound routes
Route redistribution and route-maps
IP pool routes and loopback routes are advertised in the BGP domain in the following ways:
Through BGP configuration mode redistribution commands, all or some of the connected routes are redistributed into the BGP domain. (IP pool and loopback routes are present in the IP routing table as connected routes.) The routemap command provides the flexibility to change many BGP attributes.
Through the BGP configuration mode network commands, connected routes are explicitly configured for advertisement into the BGP domain. The network routemap command provides the flexibility to change many
BGP attributes. Refer to the Cisco Systems ASR 5000 Command Line Interface Reference for details on the
BGP configuration mode commands.
If a BGP task restarts because of a processing card failure, a migration, a crash, or the removal of a processing card, all peering session and route information is lost.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Routing
Configuring BGP
This section describes how to configure and enable basic BGP routing support in the system.
BGP-4 Routing ▀
Notes:
A maximum of 64 BGP peers are supported per context.
Save your configuration as described in Verifying and Saving Your Configuration.
Redistributing Routes Into BGP (Optional)
Redistributing routes into BGP simply means that any routes from another protocol that meet a specified criterion, such as a route type, or a rule within a route-map, are redistributed through the BGP protocol to all BGP areas. This is an optional configuration.
Notes:
The redistribution options are connected, ospf, rip, or static.
A maximum of 64 route-maps are supported per context.
Save your configuration as described in Verifying and Saving Your Configuration.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Chapter 37
Session Recovery
In the telecommunications industry, over 90 percent of all equipment failures are software-related. With robust hardware failover and redundancy protection, any card-level hardware failures on the system can quickly be corrected.
However, software failures can occur for numerous reasons, many times without prior indication. For this reason, we have introduced a new solution to recover subscriber sessions in the event of failure.
The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.
This feature is available for the following functions:
PDSN services supporting simple IP, Mobile IP, and Proxy Mobile IP
GGSN services for IPv4 and PPP PDP contexts
SGSN services (3G and 2.5G services) for IPv4 and PPP PDP contexts
HA services supporting Mobile IP and/or Proxy Mobile IP session types with or without per-user Layer 3 tunnels
LNS session types
IPSG-only systems
Any session needing L2TP LAC support (excluding regenerated PPP on top of an HA/GGSN session)
Session recovery is not supported for the following functions:
Mobile IP sessions with L2TP
Multiple MIP sessions
Destination-based accounting recovery
Any session using IPv6 (PDSN/GGSN/SGSN/LNS)
Any session needing L2TP LAC support (including regenerated PPP on top of an HA/GGSN session)
GGSN network initiated connections
MIP session with multiple concurrent bindings
MIP/L2TP with IPSEC integration
GGSN session using more than 1 service instance
Important:
Session Recovery can only be enabled through a feature use license key. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
OL-22983-01
When session recovery occurs, the system reconstructs the following subscriber information:
Data and control state information required to maintain correct call behavior.
A minimal set of subscriber data statistics; required to ensure that accounting information is maintained.
A best-effort attempt to recover various timer values such as call duration, absolute time, and others.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Session Recovery
▀ BGP-4 Routing
The idle time timer is reset to zero and the re-registration timer is reset to its maximum value for HA sessions to provide a more conservative approach to session recovery.
Session Recovery is also useful for Software Patch Upgrade activities. If session recovery feature is enabled during the software patch upgrading, it helps to permit preservation of existing sessions on the active PAC/PSC/PSC2 during the upgrade process. For more details refer to Software Patch Upgrade in the System Administration Guide.
Important:
Any partially connected calls (e.g., a session where HA authentication was pending but has not yet been acknowledged by the AAA server) are not recovered when a failure occurs.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Session Recovery
How Session Recovery Works ▀
How Session Recovery Works
This section provides an overview of how this feature is implemented and the recovery process.
Session recovery is performed by mirroring key software processes (e.g., session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (e.g., a session manager task aborts). The system spawns new instances of ―standby mode‖ session and AAA managers for each active control processor (CP) being used. Naturally, these mirrored processes require both memory and processing resources, which means that additional hardware may be required to enable this feature (see the Additional Hardware Requirements section).
Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate
Packet Accelerator Card (PAC)/Packet Services Card (PSC/PSC2) to ensure that a double software fault (e.g., session manager and VPN manager fails at same time on same card) cannot occur. The PAC/PSC/PSC2 used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.
There are two modes of session recovery.
Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby PAC/PSC/PSC2. In this mode, recovery is performed by using the mirrored
―standby-mode‖ session manager task(s) running on active PACs/PSCs/PSC2s. The ―standby-mode‖ task is renamed, made active, and is then populated using information from other tasks such as AAA manager. In case of Task failure, limited subscribers will be affected and will suffer outage only until the task starts back up.
Full PAC/PSC/PSC2 recovery mode: Used when a PAC/PSC/PSC2 hardware failure occurs, or when a planned PAC/PSC/PSC2 migration fails. In this mode, the standby PAC/PSC/PSC2 is made active and the
―standby-mode‖ session manager and AAA manager tasks on the newly activated PAC/PSC/PSC2 perform session recovery.
Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different application cards to ensure task recovery.
There are some situations wherein session recovery may not operate properly. These include:
Additional software or hardware failures during the session recovery operation. An example of this would be if an AAA manager were to fail while the state information it contained was being used to populate the newly activated session manager task.
A lack of hardware resources (i.e., PAC/PSC/PSC2 memory and control processors) to support session recovery.
Important:
After a session recovery operation, some statistics, such as those collected and maintained on a per manager basis (AAA Manager, Session Manager, etc.) are in general not recovered, only accounting/billing related information is checkpointed/recovered.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Session Recovery
▀ Additional Hardware Requirements
Additional Hardware Requirements
Because session recovery requires numerous hardware resources, such as memory, control processors, NPU processing capacity, etc., some additional hardware may be required to ensure that enough resources are available to fully support this feature.
Important:
A minimum of four PACs/PSCs/PSC2s (three active and one standby) per individual chassis is required to use this feature.
To allow for complete session recovery in the event of a hardware failure during a PAC/PSC migration, a minimum of three active PACs/PSCs/PSC2s and two standby PACs/PSCs/PSC2s should be deployed.
To assist you in your network design and capacity planning, the following list provides information that should be considered.
Subscriber capacity is decreased depending on the hardware configuration. A fully configured chassis (12 active
PACs/PSCs/PSC2s and 2 standby PACs/PSCs/PSC2s) would experience a smaller decrease in subscriber capacity versus a minimally configured chassis (3 active PACs/PSCs/PSC2s and 2 standby PAC/PSCs/PSC2s).
The amount by which control transaction processing capacity is reduced.
The reduction in subscriber data throughput.
The recovery time for a failed software task (e.g., session manager).
The recovery time for a failed PAC/PSC/PSC2 (hardware failure).
If a PAC/PSC/PSC2 migration is being performed, this may temporarily impact the ability to perform session recovery as hardware resources (e.g., memory, processors, etc.) that may be needed are not available during this operation. To avoid this condition, a minimum of two standby PACs/PSCs/PSC2s should be configured.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Session Recovery
Configuring the System to Support Session Recovery ▀
Configuring the System to Support Session Recovery
The following configuration procedures allow you to configure the session recovery feature for either an operational system that is currently in-service (able to accept incoming calls) or a system that is out-of-service (not part of your production network and therefore not processing any live subscriber/customer data).
Important:
Session recovery can only be enabled through a feature use license key. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
The session recovery feature, even when the feature use key is present, is disabled by default on the system.
Enabling Session Recovery
As noted earlier, session recovery can be enabled on a system that is out-of-service (OoS) and does not yet have any contexts configured, or on an in-service system that is currently capable of processing calls. However, if the system is in-service, it must be restarted before the session recovery feature takes effect. Each procedure is shown below.
Enabling Session Recovery on an Out-of-Service System
The following procedure is for a system that does not have any contexts configured.
To enable the session recovery feature on an out-of-service (OoS) system, follow the procedure below. This procedure assumes that you begin at the Exec mode prompt.
Step 1
At the Exec mode prompt, verify that the session recovery feature is enabled by the session and feature use license on the system by entering the following command:
The output of this command appears similar to the example shown below. Note that the session recovery feature is boldfaced in this example.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Configuring the System to Support Session Recovery
Session Recovery
Important:
If the Session Recovery feature appears as Disabled, then you cannot enable this feature until a new license key is installed in the system.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Session Recovery
Step 2
Use the following configuration example to enable session recovery.
Configuring the System to Support Session Recovery ▀
Step 3
Save your configuration as described in the Saving Your Configuration section in the System Administration Guide.
The system, when started, enables session recovery, creates all mirrored ―standby-mode‖ tasks, and performs
PAC/PSC/PSC2 reservations and other operations automatically.
Step 4
After the system has been configured and placed in-service, you should verify the preparedness of the system to support this feature as described in Viewing Session Recovery Status.
Enabling Session Recovery on an In-Service System
When enabling session recovery on a system that already has a saved configuration, the session recovery commands are automatically placed before any service configuration commands in the configuration file.
To enable the session recovery feature on an in-service system, follow the procedure below. This procedure assumes that you begin at the Exec mode prompt.
Step 1
At the Exec mode prompt, verify that the session recovery feature is enabled by the session and feature use license on the system by entering the following command:
The output of this command appears similar to the example shown below. Note that the session recovery feature is boldfaced in this example.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Configuring the System to Support Session Recovery
Session Recovery
Important:
If the Session Recovery feature for HA appears as Disabled, then you cannot enable this feature until a new license key is installed in the system.
Step 2
Use the following configuration example to enable session recovery.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Session Recovery
Configuring the System to Support Session Recovery ▀
Important:
This feature does not take effect until after the system has been restarted.
Step 3
Save your configuration as described in Saving Your Configuration.
Step 4
Perform a system restart by entering the following command:
The following prompt appears:
Confirm your desire to perform a system restart by entering the following:
The system, when restarted, enables session recovery and creates all mirrored ―standby-mode‖ tasks, performs
PAC/PSC/PSC2 reservations, and other operations automatically.
Step 5
After the system has been restarted, you should verify the preparedness of the system to support this feature as described in the Viewing Session Recovery Status section.
Important:
More advanced users may opt to simply insert the command syntax into an existing configuration file using a text editor or other means, and then applying the configuration file manually. Caution should be taken when doing this to ensure that this command is placed among the first few lines of any existing configuration file to ensure that it appears before the creation of any non-local context.
Disabling the Session Recovery Feature
To disable the session recovery feature on a system, enter the following command from the Global Configuration mode prompt:
Important:
If this command is issued on an in-service system, then the system must be restarted by issuing the
command.
Viewing Session Recovery Status
To determine if the system is capable of performing session recovery, when enabled, enter the following command from the Exec mode prompt.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Configuring the System to Support Session Recovery
The output of this command should be similar to the examples shown below.
Session Recovery
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Session Recovery
Configuring the System to Support Session Recovery ▀
Viewing Recovered Session Information
Per subscriber session information is available to show any changes in session recovery status. A new field has been added to the show subscriber debug-info command that is named ―Redundancy Status‖. This field shows whether or not the session has been recovered or is the original information. There are two valid outputs for this field:
Original - indicating that this is the original session information, containing all event states and time information.
Recreated Session - indicating that this session was reconstructed during a session recovery operation.
This command can be executed before or after a session recovery operation has been performed, and would show information relative to the specific session.
To view session state information and any session recovery status, enter the following command:
Keyword/Variable Description
Displays subscriber information for the call specified by . The call ID must be specified as an 8-byte hexadecimal number.
Displays information for the mobile user identified by . must be from 7 to 16 digits specified as an
IMSI, MIN, or RMI. Wildcard characters $ and * are allowed. The * wildcard matches multiple characters and the $ wildcard matches a single character. If you do not want the wildcard characters interpreted as a wildcard enclose them in single quotes ( ‗ ). For example; ‗$‘.
Displays information for connections for the subscriber identified by previously configured.
. The user must have ben
must be a sequence of characters and/or wildcard characters ('$' and '*') from 1 to 127 characters in length. The * wildcard matches multiple characters and the $ wildcard matches a single character. If you do not want the wildcard characters interpreted as wildcard enclose them in single quotes ( ‗).
For example; ‗$‘.
The following example shows the output of this command both before and after a session recovery operation has been performed. The ―Redundancy Status‖ fields in this example have been bold-faced for clarity.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Configuring the System to Support Session Recovery
Session Recovery
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Session Recovery
Configuring the System to Support Session Recovery ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
▀ Configuring the System to Support Session Recovery
Session Recovery
Notice that is the example above, where the session has been recovered/recreated, that state events (FSM Event State field) no longer exist. This field is re-populated as new state changes occur.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 38
Subscriber Overcharging Protection
This chapter provides information on overcharging protection support for subscribers in UMTS network while loss of radio coverage occurred. 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.
This chapter discusses following topics for feature support of Subscriber Overcharging Protection on loss of radio coverage for UE in UMTS networks:
Supported Networks and Platforms
Overcharging Protection Configuration
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Subscriber Overcharging Protection
▀ Introduction
Introduction
Mobile carriers typically are always looking for the solution for maximizing their network resource and, at the same time, looking for the method to effectively use of their network resource. Some mobile carriers charge their subscribers based on counts in x-CDR.
Consider scenario where a mobile is using streaming services or downloading very large files from external sources and it goes out of coverage. If this download is happening on Background/Interactive traffic class then the GGSN is unaware of such loss of connectivity as SGSN do not the perform Update PDP Context procedure to set QoS to 0kbps (this is done when traffic class is either Streaming or Conversational only). The GGSN still keeps on sending the downlink packets to SGSN, the SGSN does paging and finds out the mobile is not responding. SGSN will then drop the packets.
In such cases, the G-CDR will have increased counts but S-CDR will not have them.
Some operators charge the subscribers based on G-CDR and overcharging can happen in the scenario given above. This feature is provided to avoid the overcharging is such cases.
This feature uses private extension for Loss Of Radio Coverage (LORC) sent by SGSN in Update PDP Context message to set QoS to 0 kbps, on detecting loss of radio coverage of UE. GGSN becomes aware of the LORC status by recognizing the message (from SGSN) and discards the downlink packets if LORC status indicates loss of radio coverage and also stops discarding downlink packets, if LORC status indicates gain of radio coverage of UE.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Subscriber Overcharging Protection
Supported Standards
This is a proprietary feature and implemented on the basis of internal standards.
Supported Standards ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Subscriber Overcharging Protection
▀ Supported Networks and Platforms
Supported Networks and Platforms
This feature supports Cisco® ASR 5000 Chassis with StarOS Release 9.0 or later running GGSN and/or SGSN service for the core network services.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Subscriber Overcharging Protection
Licenses
This feature support requires following feature license installed on the system:
600-00-7820
Licenses ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Subscriber Overcharging Protection
▀ Overcharging Protection Configuration
Overcharging Protection Configuration
This section provides a high-level series of steps and the associated configuration examples for configuring the system with overcharging protection to subscriber on loss of radio coverage for UE in GGSN services.
Important:
This section provides the minimum instruction set to configure the system to avoid the overcharging due to loss of radio coverage at the GGSN in UMTS network. Commands that configure additional function for this feature are provided in the Command Line Interface Reference.
These instructions assume that you have already configured the system-level configuration as described in System
Administration Guide and specific product Administration Guide.
To configure the system to support overcharging protection on LORC in GGSN service:
Step 1
Configure the GTPC private extension in a GGSN service by applying the example configurations presented in the
GTP-C Private Extension Configuration section below.
Step 2
section of this chapter.
Step 3
Verify configuration of overcharging protection on LORC related parameters by applying the commands provided in
the Verifying Your Configuration section of this chapter.
GTP-C Private Extension Configuration
This section provides the configuration example to configure the GTP-C private extensions for GGSN service:
Notes:
is the name of the system context where specific GGSN service is configured. For more information, refer GGSN Service Administration Guide.
is name of the GGSN service where you want to enable the overcharging protection for subscribers due to LORC.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Subscriber Overcharging Protection
Save the Configuration ▀
Save the Configuration
To save changes made to the system configuration for this service, refer Verifying and Saving Your Configuration chapter.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Subscriber Overcharging Protection
▀ Verifying Your Configuration
Verifying Your 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 overcharging protection support configuration.
Step 1
Verify that your overcharging support is configured properly by entering the following command in Exec Mode:
The output of this command displays the configuration for overcharging protection configured in the GGSN service
.
Step 2
Verify that GTP-C private extension is configured properly for GGSN subscribers by entering the following command in Exec Mode:
The output of this command displays the LORC state information and number of out packets dropped due to LORC.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 39
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:
Traffic Policing Configuration
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Traffic Policing and Shaping
▀ Overview
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.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Traffic Policing and Shaping
Overview ▀
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Traffic Policing and Shaping
▀ Traffic Policing Configuration
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):
Step b
To apply the specified limits and actions to the uplink (data from the subscriber):
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Traffic Policing and Shaping
Traffic Policing Configuration ▀
Notes:
There are numerous keyword options associated with the
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
command in the Subscriber Configuration mode is configured to. In addition, the ―lower-ip-precedence‖ option may also override the configuration of the 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:
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.
Table 46. Permitted Values for Committed and Peak Data Rates in GTP Messages
Value (bps)
From 1000 to 63,000
Increment Granularity (bps)
1,000 (e.g 1000, 2000, 3000, ... 63000)
From 64,000 to 568,000
From 576,000 to 8,640,000
8,000 (e.g. 64000, 72000, 80000, ... 568000)
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)
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Traffic Policing Configuration
Step 1
Set parameters by applying the following example configurations:
•To apply the specified limits and actions to the downlink (the Gn direction):
Traffic Policing and Shaping
•To apply the specified limits and actions to the uplink (the Gi direction):
Notes:
There are numerous keyword options associated with 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:
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:
The output is a concise listing of configured APN parameter settings.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Traffic Policing and Shaping
Step 3
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
Traffic Policing Configuration ▀
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Traffic Policing and Shaping
▀ Traffic Shaping Configuration
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):
Step b
To apply the specified limits and actions to the uplink (data to the subscriber):
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Traffic Policing and Shaping
Traffic Shaping Configuration ▀
Notes:
There are numerous keyword options associated with
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
command in the Subscriber Configuration mode is configured to. In addition, the ―lower-ip-precedence‖ option may also override the configuration of the 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:
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.
Table 47. Permitted Values for Committed and Peak Data Rates in GTP Messages
Value (bps)
From 1000 to 63,000
From 64,000 to 568,000
From 576,000 to 8,640,000
Increment Granularity (bps)
1,000 (e.g 1000, 2000, 3000, ... 63000)
8,000 (e.g. 64000, 72000, 80000, ... 568000)
64,000 (e.g. 576000, 640000, 704000, ... 86400000)
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Traffic Policing and Shaping
▀ Traffic Shaping Configuration
Value (bps) Increment Granularity (bps)
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):
Step b
To apply the specified limits and actions to the uplink (data to the subscriber):
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:
Notes:
There are numerous keyword options associated with
command.
For more information on commands, refer Command Line Interface Reference
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Traffic Policing and Shaping
Traffic Shaping Configuration ▀
If the exceed/violate action is set to of the
, this command may override the configuration
command in the GGSN service configuration mode for packets from the GGSN to the
SGSN. In addition, the GGSN service 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:
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.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Traffic Policing and Shaping
▀ RADIUS Attributes
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.
Table 48. RADIUS Attributes Required for Traffic Policing Support for CDMA Subscribers
Attribute
SN-QoS-Tp-Dnlk
(or SN1-QoS-Tp-
Dnlk)
SN-Tp-Dnlk-
Committed-Data-
Rate
(or SN1-Tp-Dnlk-
Committed-Data-
Rate)
SN-Tp-Dnlk-Peak-
Data-Rate
(or SN1-Tp-Dnlk-
Committed-Data-
Rate)
SN-Tp-Dnlk-Burst-
Size
(or SN1-Tp-Dnlk-
Burst-Size)
SN-Tp-Dnlk-Exceed-
Action
(or SN1-Tp-Dnlk-
Exceed-Action)
SN-Tp-Dnlk-Violate-
Action
(or SN1-Tp-Dnlk-
Violate-Action)
SN-QoS-Tp-Uplk
(or SN1-QoS-Tp-
Uplk)
Description
Enable/disable traffic policing in the downlink direction.
Specifies the downlink committed-data-rate in bps.
Specifies the downlink peak-data-rate in bps.
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.
Specifies the downlink exceed action to perform.
Specifies the downlink violate action to perform.
Enable/disable traffic policing in the downlink direction.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Traffic Policing and Shaping
RADIUS Attributes ▀
Attribute
SN-Tp-Uplk-
Committed-Data-
Rate
(or SN1-Tp-Uplk-
Committed-Data-
Rate)
SN-Tp-Uplk-Peak-
Data-Rate
(or SN1-Tp-Uplk-
Committed-Data-
Rate)
SN-Tp-Uplk-Burst-
Size
(or SN1-Tp-Uplk-
Burst-Size)
SN-Tp-Uplk-Exceed-
Action
(or SN1-Tp-Uplk-
Exceed-Action)
SN-Tp-Uplk-Violate-
Action
(or SN1-Tp-Uplk-
Violate-Action)
Description
Specifies the uplink committed-data-rate in bps.
Specifies the uplink peak-data-rate in bps.
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.
Specifies the uplink exceed action to perform.
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.
Table 49. RADIUS Attributes Required for Traffic Policing Support for UMTS Subscribers
Attribute
SN-QoS-
Conversation-Class
(or SN1-QoS-
Conversation-Class)
SN-QoS-Streaming-
Class
(or SN1-QoS-
Streaming-Class)
Description
Specifies the QOS Conversation Traffic Class.
Specifies the QOS Streaming Traffic Class.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Traffic Policing and Shaping
▀ RADIUS Attributes
Attribute
SN-QoS-Interactive1-
Class
(or SN1-QoS-
Interactive1-Class)
SN-QoS-Interactive2-
Class
(or SN1-QoS-
Interactive2-Class)
SN-QoS-Interactive3-
Class
(or SN1-QoS-
Interactive3-Class)
SN-QoS-Background-
Class
(or SN1-QoS-
Background-Class)
SN-QoS-Traffic-
Policy
(or SN1-QoS-Traffic-
Policy)
Description
Specifies the QOS Interactive Traffic Class.
Specifies the QOS Interactive2 Traffic Class.
Specifies the QOS Interactive3 Traffic Class.
Specifies the QOS Background Traffic Class.
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 ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 40
Ty Interface Support
This chapter provides information on configuring the IP Multimedia Subsystem (IMS) Authorization Service support with Ty interface support for IMS subscriber in cdma2000 networks. This chapter also describes the configuration and commands with Diameter attributes 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 Packet Data Serving Node Administration Guide for PDSN/FA service and Home Agent Administration Guide for HA service, before using the procedures in this chapter.
Important:
The IMS Authorization Service feature described in this chapter is only available if you have purchased and installed a Dynamic Policy Interface feature license on chassis. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
This chapter includes the following:
Access Gateway Functionality for IMS Authorization
Configuring IMS Authorization Service
Enabling IMS Authorization and QoS Profile
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Ty Interface Support
▀ Overview
Overview
Important:
The system supports IMS authorization for IMS subscribers with Ty interface in cdma2000 networks.
IMS authorization support is a license enabled feature and you must obtain and install a license key to enable it.
IMS service provides wide application support for transport of voice, video, and data independent of the access support.
The roaming IMS subscriber in cdma2000 networks requires specific interface support for service access in this network.
Apart from other functionality sufficient, uninterrupted, consistent, and seamless user experience is expected by a subscriber during an application session. It is also important that the subscriber gets charged only for the amount of resources consumed by the particular IMS application used.
In view of required flow bandwidth and QoS, the ASR 5000 Series Platforms provide 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.
The system provides Ty interface to implement IMS authorization in cdma2000 networks for Access Gateways (PDSN and HA). The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.
Table 50. Applicable Products and Relevant Sections
Applicable Product(s) Refer to Sections
PDSN
Access Gateway Functionality for IMS Authorization
Configuring IMS Authorization Service
Enabling IMS Authorization and QoS Profile
Configuring IMS Authorization in PDSN Service
Configuring Policy Map and DSCP Marking for PDSNHA Service
Applying IMS Authorization to a Subscriber
HA
Access Gateway Functionality for IMS Authorization
Configuring IMS Authorization Service
Enabling IMS Authorization and QoS Profile
Configuring Policy Map and DSCP Marking for PDSNHA Service
Applying IMS Authorization to a Subscriber
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Ty Interface Support
Overview ▀
Supported Standards
Support for the following standards and requests for comments (RFCs) have been added with the IMS authorization service functionality:
3GPP2 TSG-X (PSN) X.P0013-014-0.8, Service Based Bearer Control – Ty Interface Stage-3
RFC 3588, Diameter Base Protocol
RFC 4006, Diameter Credit-Control Application
Supported Networks and Platforms
This feature supports all ASR 5000 Series Platforms for the core network services configured on the system.
Interfaces for IMS Authorization
For IMS deployment in cdma2000 networks the system uses policy-based admission control support and/or flow based charging. The interfaces supported to perform SBLP and FBC in IMS authorization service described in the following sections.
Ty Interface for PDSN/FA/HA
The Ty reference is an interface between an Access Gateway (AGW) and a Policy and Charging Rules Function (PCRF) in support of Service Based Bearer Control.
The system, acting as an AGW, performs the Traffic Plane Function (TPF) and Policy and Charging Enforcement
Function (PCEF) functionality. PCRF may be co-located with the P-CSCF, but they are different entities.
The Ty interface performs interactions for the purpose of local authorization of bearer level QoS resources on the resources negotiated at the application layer and/or based on local policy. In addition it supports the passing of information that may be used to establish flow based charging policy. The Ty interface also provides the following features:
Co-ordination between the application and the bearer level for per-flow accounting
Notification of loss of bearer from the bearer control entity to the application
Application control of the flow of packets on the bearer including the restriction of flow end-points (flow filtering)
General policy considerations for the allocation of resources on the bearer in the local domain.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Ty Interface Support
▀ Overview
Terminology and Definition
This section provides the descriptions of the terms used in this chapter for IMS authorization service support.
Binding Information: The binding information associates a bearer to the IP flows of a session. The binding information is based on IMS session information for IMS sessions and sent by UE. The system receives the binding information from the UE during bearer activation or modification. The binding information consists of flow identifiers, QoS information, and flow description, if any for the IMS session.
Flow Identifier: In an IMS session an IP flow is indicated uniquely by means of a flow identifier. The flow identifier is created based on the ordinal number of the flow stream and of the IP flow in the session where the
IP flows are arranged based on the ports used.
Binding Mechanism: This mechanism is used to associate a bearer with the IP flow(s) of an IMS session in the
PDF.
Service-based Local Policy (SBLP): This term refers to the instantiation of a policy for use of bearer resources in the access network based on Authorization by a service. In the context of Ty interface this is the combined
QoS given to a set of IP flows for an IMS session.
Service Based Authorization: This term refers to the authorization for use of bearer resources in the access network based on a determination by the application, possibly due to negotiation involving the user. In general, bearer resources are authorized if the resources requested at the bearer do not exceed the resources negotiated or requested at the service level.
Charging Rule: This is a set of information that contains the key to identify the packet flow(s) and defines how the flow(s) is to be charged. The Traffic Plane Function (TPF)/ PCEF installs the charging rules either statically or dynamically.
Dynamic Charging Rule: The charging rules that depend upon real time analysis of the IP flow data being negotiated at the time of the session setup.
Main A10: This is the primary bearer used for all the signaling. The traffic TFTs can be associated with both main A10 and auxiliary A10.
Auxiliary A10: This is the secondary bearer used for data traffic only.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Ty Interface Support
Access Gateway Functionality for IMS Authorization ▀
Access Gateway Functionality for IMS Authorization
This section describes the functionality of AGW service for IMS authorization to an IMS subscriber session in its networks.
The AGW contains and supports the Policy Enforcement Point (PEP)/PCEF function in Service Based Local Policy architecture and the Traffic Plane Function (TPF)/PCEF in the Flow Based charging (FBC) architecture. The individual requirements for each of these models are described in the following sections.
Policy Enforcement Point in SBLP
The Policy Enforcement Point in SBLP controls the quality of service that is provided to a combined set of IP flows.
The basic PEP functionality for SBLP support is identified as:
Support for ―Gate‖ Functionality
Support for Bearer Authorization
Charging Correlation
Support for 'gate' Functionality
The PEP implements ―gate‖ functionality which controls the flow of packets in the user plane based on the status of the gate. The gate operations are controlled on the basis of policy. It controls the allow and discard of IP packets in ―open‖ or ―closed‖ state of the gate. A gate applies to unidirectional flow(s) and consists of packet classifier and the associated gate status. The gate status is updated dynamically (to open/to close) based on policy decisions from PDF. When there are changes to a packet flow associated with an application (e.g. a mobile user puts a session on hold, or introduces a new media flow or terminates another), these changes are communicated to PEPs.
The gating of packet flows allows the operator the ability to control the use of the relevant IP resources, depending on the application being offered. The operator uses this capability to control the destination and source of the bearer. This gating function helps to prevent leakage of service and denial of service attacks in the network.
Support for Bearer Authorization
The system authorizes the use of bearer resources for the IMS media flow transport purpose. To achieve this, the system performs query and/or get unsolicited policy decision messages from the PDF. The decision messages indicate the IP flow(s) and the max value authorized for the resource which in this context is the QoS bandwidth used by the bearer.
The system also enforces this limit on the usage of the bearer for the transport of the IMS application media.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Ty Interface Support
▀ Access Gateway Functionality for IMS Authorization
Charging Correlation
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 AGW provides the co-relation identifiers associated with the bearer along with its address to the PDF. The PDF in turn sends the IMS Charging Identifier (ICID), which is provided by the P-CSCF, to the AGW.
The system generates the charging records including the co-related identifier as well as the ICID if received from PDF, so that the correlation of charging data can be done with the billing system.
The policy authorization transactions are carried over the Ty interface, which is based on the Diameter protocol.
Flow Based Charging with TPF/PCEF
Flow based charging handles differentiated charging of the bearer usage based on real time analysis of the service data flows. Generally charging for the usage of bearer is based on subscriber at the bearer level. Flow based charging provides a more granular charging mechanism where the charging is a dynamic function of the IP flows used by the media for an application.
The Charging Rule Function (CRF) or PCRF is capable of provisioning charging rules to the system where the charging rules are statically or dynamically defined at CRF/PCRF. A charging rule has a name, rating group, service identifier, service data flow filter and other charging related parameters associated with it.
The service data flow filters identify a flow and are unidirectional. These filters are associated with an IP 5 tuple
(protocol, local address, local port, remote address, remote port). In case of static or predefined filters, the IP flow will be inspected by attributes beyond the 5 tuple of port, address and protocol. It is the function of Traffic Plane Function
(TPF)/ Policy and Charging Enforcement Function (PCEF) to analyze the data packet based on the installed flow filters.
If a packet does not match with the filters for the bearer, it is dropped by the TPF/PCEF. TPF/PCEF counts packets based on individual flow for charging purpose.
The charging rules also include the type of charging, (online or offline), the primary and secondary addresses for the offline, and online charging systems as applicable for the credit control of the session.
CRF/PCRF is also capable of generating unsolicited messages for provisioning charging rules for a bearer. The
TPF/PCEF is required to enforce the charging rules from any decision received from CRF/PCRF.
The system supports the following charging rule operations over the Ty interface:
Installation, modification, and removal of dynamic charging rule using Ty interface.
Provide high priority to the dynamic charging rules over the static charging rules configured with the system.
Important:
The system does not need any static configuration knowledge of traffic categories (Rating-Groups) dynamically received by CRF/PCRF and packets dropped due to the closure of ―gate‖ are not counted against the quota for the matching category.
A dynamic charging rule has the following attributes: a charging rule name service data flow filter(s) precedence
―gate‖ status
QoS parameters
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Ty Interface Support
Access Gateway Functionality for IMS Authorization ▀
Policy Mapping between PCRF and PCEF
This section describes the process of policy mapping between PCRF/P-CSCF and PCEF/AGW.
The Operator can associate each subscriber with one static policy-group and one dynamic policy-group. The static policy-group parameters for the subscriber are configured by the operator, and the dynamic policy-group is automatically created from the Charging-Rule-Definition AVP returned by the PCRF for the subscriber. The contents of the dynamic policy-group can be updated on request from the PCRF.
The system applies the following rules to decide the order in which charging rules are applied for a subscriber:
If the AGW service instance is NOT configured for SBBC service any static policy configured for the subscriber will be applied.
If the AGW service instance is configured for SBBC and PCRF disables the charging any static policy configured for the subscriber will be applied.
If the AGW service instance is configured for SBBC and PCRF enables the charging: specific charging rules installed by the PCRF for the subscriber will be applied. default charging rules installed by the PCRF for the subscriber will be applied. any static policy configured for the subscriber will be applied.
The following rules decide the order of evaluation of Charging-Rules associated with the Policy-Group:
The Charging -Rule-Definitions with the highest precedence will be evaluated first.
If there are multiple Charging -Rule-Definitions with the same precedence the newer rule will be evaluated first.
If there are multiple Charging -Rule-Definitions in the same RAR, CCA messages with the same precedence, the charging rules will be evaluated in the order of the occurrence in packet.
The charging rule definitions returned by the PCRF are translated in the policy infrastructure for the AGW. The section
Maintaining the Dynamic Policy-Group defines the mapping of different entities in the policy infrastructure for the dynamic policy-group.
Maintaining the Dynamic Policy-Group
This section defines the mapping of the Charging-Rule-Install AVP to the dynamic policy-group and related policy infrastructure. The rules for creating a dynamic policy group are as follows:
Create a dynamic policy group, if one does not exist, for each Charging-Rule-Install AVP in the packet:
If a charging rule with the same name exists, then replace all the policy-maps and class-maps with new information and update any precedence change in the policy-group.
If charging-rule does not exists; then create class-map, policy-map, and policy-group entries.
Important:
For more information on Class-Map, Policy-Map, and Policy-Group, refer to the Intelligent Traffic
Control chapter.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Access Gateway Functionality for IMS Authorization
Ty Interface Support
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Ty Interface Support
How it Works ▀
How it Works
This section describes the IMS authorization and dynamic policy support in a cdma2000 networks.
The DPCA is the Ty interface to the Policy Control and Charging Rule Function (PCRF). The PCRF contains both PDF
(Policy Decision Function) and CRF (Charging Rule Function). The PCRF may reside in Proxy-Call Session Control
Function (P-CSCF) or on stand-alone system.
The interface between IMSA with PCRF is the Ty interface and between Session Manager and Online Charging Service
(OCS) is the Tx interface.
Important:
Online charging is not supported in this release.
Ty Interface Support with AGW
IMS authorization support performs in following way to provide the IMS authorization service to a subscriber in cdma2000 network.
When an AGW receives a packet in downlink or uplink direction, it matches the packets against all the downlink/uplink
PCC rules that configured by the PCRF for the subscriber. On the basis of matching rules it selects one PCC rule and applies the ‗gating policy‘ as available in selected PCCC rule to the flow. It also applies the traffic policing to the flow on the basis of downlink/uplink bandwidth limit provided in authorized QoS profile available in the PCC rule. To provide the bandwidth limit the AGW uses 3 color 2 bucket in the color blind mode to enforce the bandwidth.
If flow is in uplink direction AGW applies the routing function on the packet or extract the flow-identifier for the downlink flow with the use of Flow-Identifier AVP in PCC rule.
Based on the flow -id the AGW selects the A10 to transport the packet and adds the flow identifier attributes to the GRE header and forwards the packet on the selected A10.
The following figure provides a high-level view of the IMS authorization process between a system and IMS components that is initiated by the MN. The table explains each step in detail.
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.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Ty Interface Support
▀ How it Works
Figure 53. IMS Authorization Call Flow
MN/SS
Session Manager
IMSA DPCA
PCRF/P-CSCF
Policy
Manager/AAA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Table 51. IMS Authorization Call flow Description
Step Description
1 IMS subscriber (MN) sends request for primary bearer(A10) activation/creation.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Ty Interface Support
How it Works ▀
Step Description
2
3
4
Session manager allocates IP address to MN.
Session manager sends IMS authorization request to IMS authorization service (IMSA).
IMSA creates a session with the PCRF on the basis of PCRF configuration.
5
6
7
8
IMSA sends request to DPCA module to issue the authorization request to selected PCRF.
DPCA sends a CCR-initial message to the selected PCRF. This message includes the IP address allocated to MN.
CCA message sent to DPCA. If a preconfigured rule set for the bearer is provided in PCRF, it sends that charging rules to
DPCA in CCA message.
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 the ACS manager.
11 ACS Manager 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 3GPP2 specific attributes (e.g. Subscriber, QoS etc.).
12 OCS returns a CCA-Initial message to activate the statically configured rulebase and includes pre-emptive credit quotas.
13 ACS manager responds to session manager with the response message for dynamic rule configuration.
14 On the basis of response for the bearer authorization, session manager sends the response to the MN and activates/rejects the call.
Note: Step 10 through 13 are not relevant to this release.
Ty Interface Support with HA
IMS authorization support uses Mobile IP to manage session with HA. The Ty interface between HA and PCRF provides following functions:
Local policy based authorization and bearer-level QoS negotiation
Accounting co-ordination on a per flow basis, between bearer-level and application-level
Flow control and filtering on the basis of subscriber profile
Bearer resource allocation to the subscriber
In HA service deployment, the HA matches the packets received against all the downlink/uplink PCC rules that configured by the PCRF for the subscriber, and applies the ‗gating policy‘ and traffic policing to the flow on the basis of applicable PCC rule. It also applies the Authorized-QoS profile available in the PCC rule. After applying the gating policy and QoS profile, the HA tunnels the packet to the AGW for downlink traffic or applies routing function on the packet for uplink traffic flow.
The following figure provides a high-level view of the IMS authorization process between a system and IMS components that is initiated by the MN. The following table explains each step in detail.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Ty Interface Support
▀ How it Works
Figure 54. IMS Authorization HA Call Flow
FA HA PCRF/P-CSCF
Policy
Manager/AAA
1
4
7
3
5
6
8
9
10
11
12
13
Table 52. IMS Authorization HA Call flow Description
Step Description
3
4
1
2
FA forwards the Registration Request MIP_RRQ to the HA.
HA performs AAA authentication for subscriber, if required.
After authentication CCR-Session-Up is initiated by HA with PCRF.
HA sends MIP-RRP message to FA.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
2
OL-22983-01
Ty Interface Support
How it Works ▀
Step Description
5 PCRF with CCA-Session-Up to HA.
If the response is failure the call is rejected.
If the response is succeeded the charging rule, if available for this response, is installed and session established.
6
7
After a request for modification of an existing media flow is requested, the PCRF initiates an RAR request with a modified
Authorized QoS for the specific media flow.
HA updates the existing flows with new QoS, bandwidth, flow description, and gating parameters.
8
9
HA responds to the PCRF with a RAA message.
After the session MN wants to terminate the session and initiates the termination of session procedure. The FA sends an
RRQ to HA initiating the termination of the Mobile IP tunnel.
10 HA responds with an RRP message to the FA indicating successful completion of the termination procedure.
11 HA generates a CC-Request-Session-Terminate message and sends to the PCRF.
12 PCRF clears all the flows corresponding to the session and responds with a CC-Answer-Session-Terminate message to HA.
13 HA clears all the flow information for the subscriber session.
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
Ty Interface Support
▀ Configuring IMS Authorization Service
Configuring IMS Authorization Service
Use the following example to enable IMS authorization service for IMS subscriber in cdma2000 networks:
Notes:
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.
Define the P-CSCF discovery algorithm for either discovery or table options.
Optional. Specify the trigger events to initiate re-authorization for a subscriber in IMS authorization service using the command.
Important:
The trigger events specified are applicable on the events generated by the PCRF only.
Configuring the Policy Control Settings
1. Enter the Policy Control Configuration mode for authorization and policy control parameter in IMS authorization service by entering the following command:
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Ty Interface Support
Configuring IMS Authorization Service ▀
Notes:
specifies the handling of the failure of Enhanced-Policy Decision Function (E-PDF). host table with precedence.
adds or appends rows with primary and/or secondary host name to a Diameter
defines the pacing of the reselection or switching of the Enhanced-Policy
Decision Function (E-PDF) after a change occurs in table configuration for an IMS Authorization Service.
Optional. Define the method or algorithm to select Diameter host table by entering
Repeat as needed to configure more IMS authorization services as required within the specified context.
Important:
A maximum of 16 authorization services can be configured globally in the system. There is also a system limit for maximum number of total configured services.
Verifying your configuration
Step 1
Verify your configured parameters for IMS authorization service by entering the following command:
Important:
For more information on keywords/options of the to the Executive Mode Commands chapter in Command Line Interface Reference.
command, refer
Step 2
Save your configuration as described in Saving Your Configuration chapter.
Step 3
Proceed to Configuring IMS Authorization in cdma2000 Networks section to enable the IMS authorization in a core service and associate the configured IMS Authorization service to a subscriber within that context.
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Ty Interface Support
▀ Enabling IMS Authorization and QoS Profile
Enabling IMS Authorization and QoS Profile
This section describes the procedure to configure the QoS profile identifier for QoS mapping and associates an IMS authorization through Ty interface at the service level.
This section also provides the configuration to associate an IMS authorization service functionality to a previously configured subscriber within the same context in cdma2000 networks.
Configuring IMS Authorization in PDSN Service
This section describes how to associate an IMS authorization service at the service level for all subscriber in that service and to create the QoS profile id for QoS mapping in cdma2000 networks.
This procedure assumes that you are at the Context Configuration mode level in the same context as specified in
Configuring IMS Authorization Service section and following prompt is appearing:
Notes:
You can configure qos-profile parameters to define description, downlink/uplink bandwidth, drop-rate, latency, and the maximum drop percentage.
Repeat this configuration to add additional subscribers for IMS Authorization service.
Verifying your configuration for the PDSN Service
Step 1
Verify the IMS authorization configuration for the PDSN service(s) by entering the following command:
Step 2
Save your configuration as described in Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Ty Interface Support
Enabling IMS Authorization and QoS Profile ▀
Configuring Policy Map and DSCP Marking for PDSN/HA Service
This section describes how to configure the DSCP marking and policy map for subscribers configured in a destination context for IMS authorization.
Notes:
Save your configuration as described in Saving Your Configuration chapter.
Applying IMS Authorization to a Subscriber
This section describes how to associate an IMS authorization service with individual subscriber(s) in cdma2000 networks.
This configuration example assumes that you are at the context configuration mode level of the same context as
specified in the Configuring IMS Authorization Service section
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
Ty Interface Support
▀ Enabling IMS Authorization and QoS Profile
Notes:
Repeat this configuration example to configure additional subscribers for IMS Authorization service.
Verifying the IMS Authorization configuration
Step 1
Verify the IMS authorization configuration for the subscriber(s)
Step 2
Save your configuration as described in Saving Your Configuration chapter.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
Chapter 41
VLANs
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 before using the procedures in this chapter.
Sections in this chapter include:
Configuring Subscriber VLAN Associations
OL-22983-01
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
VLANs
▀ Overview
Overview
Virtual LANs (VLANs) provide greater flexibility in the configuration and use of contexts and services.
They are configured as ―tags‖ on a per-port basis and allow more complex configurations to be implemented. The
VLAN tag allows a single physical port to be bound to multiple logical interfaces that can be configured in different contexts. Therefore, each Ethernet port can be viewed as containing many logical ports when VLAN tags are employed.
Important:
VLANs are supported in conjunction with ports on the Ethernet 10/100 and 1000 line cards. (VLAN tagging is not supported for SPIO ports.) The system supports the configuration of VLANs as follows:
Ethernet 1000 Line Card: 1024 VLANs per port.
Ethernet 10/100 Line Card: Maximum of 256 VLANs per port and a maximum of 1017 tagged VLANs and 8 untagged
VLANs per Line Card. (VLANs including tagged and/or untagged across all the ports of a single 10/100 Line Card can not be more than 1025.)
This chapter includes the following procedures:
Configuring Subscriber VLAN Associations
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
VLANs
Creating VLAN Tags ▀
Creating VLAN Tags
Use the following example to create VLANs on a port and bind them to pre-existing interfaces. For information on creating interfaces, refer to the System Administration Guide.
Notes:
A maximum of 1024 VLANs can be configured per port.
Configure a subscriber-vlan to associate a VLAN with specific subscribers. Refer to the Configuring Subscriber
VLAN Associations section of this chapter for more information.
Repeat this procedure as needed to configure additional VLANs for the port.
Verify the port configuration
Use the following command to verify the port configuration:
An example of this command‘s output is shown below:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
VLANs
▀ Creating VLAN Tags
Notes:
Optional. Repeat this configuration as needed to configure additional ports.
Optional. Configure VLAN-subscriber associations if needed.
Save your configuration as described in Saving Your Configuration.
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
VLANs
Configuring Subscriber VLAN Associations ▀
Configuring Subscriber VLAN Associations
Subscriber traffic can be routed to specific VLANs based on the configuration of their user profile. Using this functionality provides a mechanism for routing all traffic from a subscriber over the specified VLAN. All packets destined for the subscriber must also be sent using only IP addresses valid on the VLAN or they will be dropped.
RADIUS Attributes Used
The following RADIUS attributes can be configured within subscriber profiles on the RADIUS to allow the association of a specific VLAN to the subscriber:
SN-Assigned-VLAN-ID : In the Starent VSA dictionary
SN1-Assigned-VLAN-ID : In the Starent VSA1 dictionary
Important:
Since the instructions for configuring subscriber profiles 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.
Configuring Local Subscriber Profiles
Use the configuration example below to configure VLAN associations within local subscriber profiles on the system.
Important:
These instructions assume that you have already configured subscriber-type VLAN tags according to the instructions provided in the Creating VLAN Tags section of this chapter.
Verify the subscriber profile configuration
Use the following command to view the configuration for a subscriber profile:
Cisco ASR 5000 Series Enhanced Feature Configuration Guide ▄
OL-22983-01
▀ Configuring Subscriber VLAN Associations
Notes:
Repeat this command for each additional subscriber.
Save your configuration as described in Saving Your Configuration.
VLANs
▄ Cisco ASR 5000 Series Enhanced Feature Configuration Guide
OL-22983-01
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project