[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


Enabling IMS AAA Dynamic Authorization

To add a new router:

  1. Set up the router as a remote RADIUS network element, as describe in Creating and Naming a Diameter or RADIUS Remote Network Element. Make sure that you set the router's function to WLAN. This chapter assumes the router is enabled.
  2. Write a new template in the provided XML router templates file, deviceModels.xml, located in the root directory of the IMS AAA Server.

    NOTE: We recommend that you write your new template by using the existing Cisco or Juniper Networks templates as examples.


How the Process Works

This section describes the process of creating service templates for dynamic authorization. To understand how service templates interact with service requests, there are three main scenarios that you need to consider:

Each of these have a serviceTemplate associated with them.

Overview

There are two common behaviors that trigger dynamic authorization requests:

In the former case, the policy server replies, and the IMS AAA Server uses this reply as one of the inputs to the rendering process to generate VSAs. In any case, the policy server supplies data that the IMS AAA Server uses as one of the inputs to the rendering process to generate VSAs. The IMS AAA Server than sends the VSAs to the router so that it can activate or deactivate services.

In the process, requests may go not only from the router to the IMS AAA, but also to the downstream AAA server, to the policy server, and, in the case of the initial authorization scenario, from the IMS AAA Server to the downstream AAA Server.

Initial Authorization

Initial authorization of services requires that your router support service activation in the access accept message. This capability is called Access-Accept mode in deviceModels.xml. See controlledDeviceModel. This scenario begins when the router sends an authorization request to the IMS AAA Server. The server in turn sends a RADIUS access request to the downstream AAA that handles authorization requests.

If the downstream AAA approves the request, it sends a RADIUS Access-Accept message to the IMS AAA server. Using the global serviceTemplate (see serviceTemplates (Global)), the IMS AAA formats the authorization request to the policy server. At this point, the policy server replies with service activation data used as input to the rendering process. This data contains the service name as specified in the deviceModels.xml file along with the attribute values and parameters. For example, if the policy server requests content_provider_tiered service, the IMS AAA server renders data using the corresponding mode, as shown in this XML code:

<serviceTemplate name="content_provider_tiered">
<mode name="InitialAuthorization"> 
<attributes> 
<parameterizedAttribute name="Unisphere-Activate-Service" 
format="content_provider_tiered\($(contentProviderAddress),$(contentProvider
Mask),$(subscriberAddress),$(subscriberMask),$(upstreamBandwidth),$(down
streamBandwidth)\)" /> 
<defaultAttribute name="Unisphere-Service-Stats" value="1" /> 
</attributes> 
</mode> 
</serviceTemplate>

The IMS AAA renders the Access-Accept, then informs the policy server about rendering sucess(es) and failure(s) in another request. The policy server sends an acknowledging response back to the IMS AAA, which in turn sends a rendered Access-Accept message to the router.

Accounting

As soon as the requested service is active, the next step is an accounting (start or interim) request from the router to the IMS AAA. Using the rendering process and the information defined in the accounting mode in the global serviceTemplate (see serviceTemplates (Global)), the IMS AAA sends an accounting request to the policy server, which then sends an accounting response. (See Modes for an explanation of modes). After receiving this response, the IMS AAA sends an accounting request to the downstream AAA, which sends an accounting response. Finally, the IMS AAA sends an accounting response back to the router and service accounting is complete.

Figure 118 shows the initial authorization and accounting timing sequence. The rectangles with a folded corner represent pieces of the XML template.


Figure 118: Initial Authorization and Accounting Timing Sequence

Service Activation and Deactivation

This section describes the service activation scenario. The deactivation scenario is identical if you replace "activation" with "deactivation" in the description.

A service activation begins with an activation request from the policy server to the IMS AAA server. Figure 119 uses guided_entrance activation as an example. This activation request includes all the information needed for the IMS AAA server to render the guided_entrance service activation request into RADIUS format for the router. The IMS AAA Server sends the rendered request, along with a service correlation ID number, as a Change of Authorization (CoA). The router responds with an Ack or Nak. The IMS AAA server then sends a service activation response to the policy server.

This completes the service activation. The router then initiates an accounting request, the timing sequence of which is identical to the sequence described in Accounting.

Figure 119 shows the activation and deactivation timing sequence.


Figure 119: Activation and Deactivation Timing Sequence

Abort Session Requests

The policy server may decide at any time to abort the user session, in which case it sends an abort session request to the IMS AAA Server. The IMS AAA, using the global serviceTemplate and the AbortSession mode, renders the request and sends the it, along with a service correlation ID number, as a Disconnect Message (DM) to the router. The router responds with an Ack or Nak. The IMS AAA server then sends a response to the policy server.

In all situations, abort session requests follow the same sequence and use the same global service template.

This completes the abort session scenario. The router then initiates an accounting request, the timing sequence of which is identical to the sequence described in Accounting.

Figure 120 shows the abort session timing.


Figure 120: Abort Session Timing Sequence

[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]