How the Dynamic Authorization Process Works in the SIC

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

• Initial Authorization
• Activation and Deactivation
• Abort Session

Each of these has a service template associated with it.

Note: In the following discussion and illustrations, the NAS communicates with the SIC through the router.

Introduction

There are two common behaviors that trigger dynamic authorization requests:

• The SIC sends a request to the SAE notifying it about an event, such as authentication success.
• The SAE requests a service, such as activation, deactivation, or abort session.

In the former case, the SAE replies, and the SIC uses this reply as one of the inputs to the rendering process to generate VSAs. In any case, the SAE supplies data that the SIC uses as one of the inputs to the rendering process to generate VSAs. The SIC then sends the VSAs to the NAS so that it can activate or deactivate services.

In the process, requests may go not only from the NAS to the SIC, but also to the downstream AAA server, to the SAE, and, in the case of the initial authorization scenario, from the SIC to the downstream AAA server.

Initial Authorization

Initial authorization of services requires that your NAS support service activation in the Access-Accept message. This capability is called Initial-Authorization mode in the service template. This scenario begins when the NAS sends an authorization request to the SIC. The SIC in turn sends a RADIUS access request to the downstream AAA server that handles authorization requests.

If the downstream AAA server approves the request, it sends a RADIUS Access-Accept message to the SIC. Using the global service template configuration, the SIC formats the authorization request to the SAE. At this point, the SAE replies with service activation data used as input to the rendering process. This data contains the service name as specified in the service template along with the attribute values and parameters. For example, if the SAE requests content_provider_tiered service, the SIC renders data by using the corresponding mode, as shown in the following example service template configuration:

service-template content_provider-tiered {
  mode Initial-Authorization {
    attributes {
      item attr1 {
        parameterized-attribute {
          format content_provider_tiered($(contentProviderAddress),$(contentProviderMask),
$(subscriberAddress),$(subscriberMask),
$(upstreamBandwidth),$(downstreamBandwidth));
          name Unisphere-Activate-Service;
        }
      }
      item attr2 {
        default-attribute {
          name Unisphere-Service-Stats;
          value 1;
        }
      }
    }
  }
}

The SIC renders the Access-Accept message, then informs the SAE about rendering successes and failures in another request. The SAE sends an acknowledgement back to the SIC, which in turn sends a rendered Access-Accept message to the NAS.

Accounting

As soon as the requested service is active, the next step is sending an accounting (start or interim) request from the NAS to the SIC. Using the rendering process and the information defined in accounting mode in the global service template, the SIC sends an accounting request to the SAE, which then sends an accounting response. After receiving this response, the SIC sends an accounting request to the downstream AAA server, which sends an accounting response. Finally, the SIC sends an accounting response back to the NAS and service accounting is complete.

Figure 1 shows the initial authorization and accounting timing sequence. The rectangles with a folded corner represent pieces of the service or global service templates. For purposes of this illustration, the SIC and SRC are shown in two distinct rectangles.

Figure 1: Initial Authorization and Accounting Timing Sequence

Service Activation and Deactivation

This section describes the service activation and deactivation scenarios. The sequences for activation and deactivation are identical except that the activation sequence uses activation requests and the deactivation sequence uses deactivation requests.

A service activation begins with an activation request from the SAE to the SIC. Figure 2 uses the guided_entrance service activation request as an example. This activation request includes all the information needed for the SIC to render the guided_entrance service activation request into RADIUS format for the NAS. The SIC sends the rendered request, along with a service correlation ID, as a COA to the NAS. The NAS responds with an acknowledgement packet (ack) or negative acknowledgement (NAK). The SIC then sends a service activation response to the SAE.

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

Figure 2 shows the activation and deactivation timing sequences. For purposes of this illustration, the SIC and SRC are shown in two distinct rectangles.

Figure 2: Activation and Deactivation Timing Sequences

Abort Session Requests

If the SAE receives an abort session request, it sends it to the SIC. The SIC, using the global service template and Abort-Session mode, renders the request and sends it, along with a service correlation ID, as a Disconnect Message (DM) to the NAS. The NAS responds with an ack or NAK. The SIC then sends a response to the SAE.

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

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

Figure 3 shows the abort session timing sequence. For purposes of this illustration, the SIC and SRC are shown in two distinct rectangles.

Figure 3: Abort Session Timing Sequence