Service Configuration Procedures


Service Configuration Procedures
 
 
This chapter is intended to be used in conjunction with the previous chapters that provide examples for configuring the system to support Simple IP services, Mobile IP services, or both. It provides procedures for configuring the various elements to support these services.
 
It is recommended that you first select the configuration example that best meets your service model, and then use the procedures in this chapter to configure the required elements for that model.
Procedures are provided for the following:
 
 
Creating and Configuring HA Services
HA services are configured within contexts and allow the system to function as an HA in the 3G wireless data network.
To create and configure an HA service:
Step 1
Step 2
Step 3
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. Additionally, when configuring Mobile IP take into account the MIP timing considerations discussed in the MIP Timer Considerations appendix.
 
Creating and Configuring an HA Service
Use the following example to configure HA services:
configure
  context <ha_context_name>
     ha-service <ha_service_name>
        ip local-port <port_number>
        authentication mn-aaa { allow-noauth | always | dereg-noauth | noauth | renew-and-dereg-noauth | renew-reg-noauth }
        fa-ha-spi remote-address <fa_ip_address> spi-number <number> { encrypted secret <enc_secret> | secret <secret> } [ description <string> ] [ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } ]
        mn-ha-spi spi-number <number> [ description <string> ] { encrypted secret <enc_secret> | secret <secret> } [ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } ] [ permit-any-hash-algorithm ] [ replay-protection { nonce | timestamp } [ timestamp-tolerance <tolerance> ]
        reg-lifetime <lifetime>
        simul-bindings <simul_bindings>
        bind address <address> max-subscribers <max_subs>
        end
Notes:
 
<port_number> must be the UDP port for the Pi interfaces’ IP socket.
<lifetime> must the longest registration lifetime that the HA service allows in any Registration Request message from the mobile node. An infinite registration lifetime can be configured using the no reg-lifetime command.
 
Verifying HA Service Configuration
Verify that your HA services were created and configured properly by entering the following command:
show ha-service { name service_name | all }
The output is a concise listing of HA service parameter settings similar to the following sample. In this sample, an HA service named ha1 was configured.
Service name: ha1
Context: ha
Bind: Done Max Subscribers: 500000
Local IP Address: 192.168.4.10 Local IP Port: 434
Lifetime: 00h01m40s Simul Bindings: 3
Reverse Tunnel: Enabled
GRE Encapsulation with-key: Enabled Keyless GRE Encapsulation: Disabled
Optimize Tunnel Reassembly: Enabled Setup Timeout: 60 sec
Allow Priv Addr w/o Rev Tunnel: Disabled
WIMAX-3GPP2 Interworking: Disabled SPI(s): MNHA: Remote Addr: 0.0.0.0 Description: Hash Algorithm: HMAC_MD5 SPI Num: 258 Replay Protection: Nonce Timestamp Tolerance: 100
Permit Any Hash Algorithm: Enabled
FAHA: Remote Addr: 195.20.20.6/32 Description: Hash Algorithm: HMAC_MD5 SPI Num: 258 Replay Protection: Timestamp Timestamp Tolerance: 60
'S' Lifetime Skew: 00h00m10s
IPSEC AAA Context: aaa_context
GRE Sequence Numbers: Disabled GRE Sequence Mode: None
GRE Reorder Timeout: 100 msec
GRE Checksum: Disabled GRE Checksum Verification: Disabled
Registration Revocation: Disabled Reg-Revocation I Bit: Enabled
Reg-Revocation Max Retries: 3 Reg-Revocation Timeout: 3 (secs)
Reg-Rev Handoff old-FA: Enabled Reg-Rev Idle-Timeout: Enabled
Send NAI Extension in Reg-Revocation: Disabled
MIP NAT Traversal: Disabled Force UDP Tunnel: Enabled
Default Subscriber: None
Max Sessions: 500000
Service Status: Started
MN-AAA Auth Policy: Always
MN-HA Auth Policy: Always
IMSI Auth: Disabled
DMU Refresh Key: Disabled
AAA Distributed MIP Keys:Disabled
AAA accounting: Enabled
Idle Timeout Mode: Aggressive
Newcall Policy: None
Overload Policy: Reject (Reject code: Admin Prohibited)
NW-Reachability Policy: Reject (Reject code: Admin Prohibited)
Null-username Policy: Reject
BC Rsp Code for Nw Fail: 0xffff
IP Pool/Group:
Name: n/a
Destination Context: n/a
 
Session Continuity Support
This section describes the procedure to enable the mobility for WiMAX subscriber and other access technology subscribers; i.e. 3GPP2. WiMAX HA implementation differs from 3GPP2 on the keys used to authenticate MN-HA and FA-HA AE in MIP RRQ. WiMAX HA involves using dynamic keys distributed by AAA for authenticating RRQ.
Following WiMAX support is provided for MIP keys management and WiMAX HA support:
 
For MIP registration HA uses the following extensions:
 
The MIP client includes the same NAI in all MIP RRQs it sends for the entire duration of the MIP session regardless of EAP re-authentication, including MIP renewal and de-registration messages. The MN-HA and FA-HA keys based on WiMAX VSA from AAA is used to authenticate the RRQ and compute authenticator in RRP.
Authentication algorithm used to authenticate MN-HA and FA-HA AE is HMAC-MD5. If renew/dereg RRQ is received, authentication with AAA will happen only if SPI value for authentication extension in RRQ changes. If SPI returned by AAA is different from the requested one, the RRQ will be rejected. Both MN-HA and FA-HA AE are expected in MIP RRQ for WiMAX calls.
The following describes the processing of different requests for HA support:
 
All the attributes (HA-RK-KEY, HA-RK-SPI, and HA-RK-Lifetime) must be returned if HA-RK key is requested for the HA-RK info in Access Accept to be valid.
Message Authenticator will be included in Access request and Accept packets for integrity protection of RADIUS packets and is mandatory.
 
Apart from these processing, HA provides following function applicable to WiMAX HA.
 
The MN-HA and FA-HA keys will be used to authenticate the RRQ.
 
Hybrid HA Service Configuration
With this support an HA can work in a “hybrid” mode, meaning the same HA can handle a call from CDMA network, a call from WIMAX network, and a “hybrid call” with RRQ coming from one network and later from another network. This way, the operator can just deploy one HA service to support both types of network, instead of using two separate HA services. The HA is aware of the access technology, and choose the correct authentication method to handle RRQ.
 
This section describes the following configuration procedures:
 
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 WiMAX HA for WiMAX Calls only
 
With this configuration the system will support only WiMAX HA behavior for the particular HA-service, where the system always expects WiMAX MIP keys from AAA and use it to do MN-HA and FA-HA authentication extension. With this configuration HA cannot support calls with static keys for MIP RRQ authentication in the particular HA service.
To configure WiMAX HA for WiMAX calls only:
Step 1
Step 2
Use the following example to configure WiMAX HA services, and enable the usage of AAA provided WiMAX MIP keys for authenticating MIP RRQ with keys mandatory.
 
configure
  context <ha_context_name>
     ha-service <ha_service_name>
        authentication aaa-distributed-mip-keys required
        end
 
Configuring WiMAX HA to Accept 3GPP2/Static MIP Key
 
To configure WiMAX HA to accept 3GPP2/Static MIP key:
Step 1
Step 2
Use the following example to configure HA services to accept 3GPP2 calls and disable usage of AAA provided WiMAX MIP keys for authenticating MIP RRQ.
 
configure
  context <ha_context_name>
     ha-service <ha_service_name>
        authentication aaa-distributed-mip-keys disabled
        end
 
Configuring Hybrid HA for WiMAX and 3GPP2 Calls
 
With this configuration, both WiMAX and 3GPP2 based calls can be made where WiMAX based calls will use WiMAX MIP keys, and 3GPP2 calls can use static or 3GPP2 based dynamic keys. This particular HA service configuration supports calls of both access technologies.
To configure Hybrid HA for WiMAX and 3GPP2 calls:
Step 1
Step 2
Use the following example to configure HA services to accept WiMAX and 3GPP2 calls in the same service, and enable usage of AAA provided WiMAX MIP keys for authenticating MIP RRQ with fallback option to use 3GPP2/static keys:
 
configure
  context <ha_context_name>
     ha-service <ha_service_name>
        authentication aaa-distributed-mip-keys optional
        wimax-3gpp2 interworking
        end
 
WiMAX-3GPP2 Interworking at HA
The session continuity capability enables a dual mode device (a multi radio device) to continue its active data session as it changes its active network attachment from 3GPP2 to Wimax and vice versa with no perceived user impacts from a user experience perspective.
 
This capability provides the following benefits:
 
To provide this capability, the HA supports seamless handoff from 3GPP2 to WIMAX and vice versa.
This section describes the key configuration to enable this capability.
 
Mobile Node Requirement
Following are the mandatory functional requirements on mobile node to support 3GPP2-WIMAX Interworking at HA:
 
 
H-AAA Requirements
H-AAA MUST meets the following requirements to support 3GPP2-WIMAX Interworking at HA:
 
 
FA and HA Function for 3GPP-WiMAX Interworking at HA
The FA and PMIP4 client provides following functionality to support 3GPP2-WIMAX Interworking at HA:
 
 
The HA provides following functionality to support 3GPP2-WIMAX Interworking at HA:
 
Before configuring the 3GPP-WiMAX Interworking the following must be taken into consideration:
 
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 WiMAX FA Service
To configure WiMAX FA service:
Step 1
Step 2
Use the following example to configure WiMAX FA service:
 
configure
  context <context_name>
     fa-service <fa_service_name>
        authentication aaa-distributed-mip-keys override
        revocation negotiate-i-bit
        end
 
Configuring 3GPP2 FA Service
To configure 3GPP2 FA service:
Step 1
Step 2
Use the following example to create and configure 3GPP2 FA service:
 
configure
  context <context_name>
     fa-service <fa_service_name>
        default mn-aaa-removal-indication
        revocation negotiate-i-bit
        end
 
Configuring Common HA Service
To configure common HA service:
Step 1
Step 2
Use the following example to configure common HA service:
 
configure
  context <ha_context_name>
     ha-service <ha_service_name>
        authentication aaa-distributed-mip-keys required
        wimax-3gpp2 interworking
        authentication mn-aaa allow-noauth
        revocation negotiate-i-bit
        end
 
 
 

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