Enabling IMS AAA Dynamic Authorization
To add a new router:
- 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.
- Write a new template in the provided XML router templates file,
deviceModels.xml, located in the root directory of the IMS AAA Server.
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
serviceTemplateassociated with them.
There are two common behaviors that trigger dynamic authorization requests:
- The IMS AAA Server sends a request to the policy server notifying it about an event, such as authentication success.
- The policy server requests a service, such as activation, deactivation, or abort session.
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 of services requires that your router support service activation in the access accept message. This capability is called
Access-Acceptmode 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.xmlfile along with the attribute values and parameters. For example, if the policy server requests
content_provider_tieredservice, 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-Acceptmessage to the router.
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 (seeserviceTemplates (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.
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_entranceactivation 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.
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
AbortSessionmode, 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.