Device and Service Template Configuration Overview (SRC CLI)
To configure dynamic authorization using the SIC you need to configure:
Device template—Specifies the router make, model and capability.
Service template—Specifies any services that you want to enable for your router. What services are available vary from router to router, so it is important that you understand the properties of your router to successfully implement custom services.
Global service template—Specifies rendering used as part of any mode of any service template. Global service templates are used to control rendering of service-independent requests, such as Abort-Session. A global service template is unique in that its modes, attributes, and variables are available to all services that you define. Global service templates are therefore a mandatory part of any SIC COA configuration.
Device Template Configuration Overview (SRC CLI)
Device templates specify the activation behavior of services and how the router handles multiple requests.
To configure device templates, you specify the capability and its associated value. The associated value is dependent on the specified capability. Table 34 describes the available capabilities and associated values.
Table 34: Device Template Capabilities and Associated Values
Activation—Specify service access/activation behavior.
None (default value)—Indicates that the router is not capable of activating services during initial authorization or activation.
Access-Accept—Indicates that the router supports activating services only in RADIUS Access-Accept messages.
CoA—Indicates that the router supports activating services in COA only.
Both—Enables both Access-Accept and COA requests.
Modification—Specify service modification behavior.
False (default value)—This attribute must be set to false.
Bundle—Indicates whether and how the router handles multiple service activation/deactivations in one COA.
None (default value)—Indicates no bundling.
Single—Indicates the router accepts multiple requests.
Service and Global Service Template Configuration Overview (SRC CLI)
Service templates specify any services that you want to enable for your router. What services are available vary from router to router, so it is important that you understand the properties of your router to successfully implement custom services.
Global service templates specify rendering used as part of any mode of any service template. Global service templates are used to control rendering of service-independent requests, such as Abort-Session. A global service template is unique in that its modes, attributes, and variables are available to all services that you define. Global service templates are therefore a mandatory part of any SIC COA configuration.
You need to configure the following items for both the service and global service template:
Service and global service templates have groups of data called mode that each service must specify. A mode contains attributes and variables, which are explained in the next sections. It is mandatory to configure the mode for each service and global temple. You must use the provided modes; you cannot create new modes.
Table 35 lists the modes and attributes for global service templates.
Table 35: Service Template Modes
Activates services on request from the SAE.
Deactivates services on request from the SAE.
Initial activation of services in the Access-Accept message.
Assigns an ID number when any other mode is initiated. The SRC software uses this identification number internally.
Used for Cisco routers only. See Caveat (Cisco Only).
Table 36 lists the modes and attributes for global service templates.
Table 36: Global Service Template Modes
Use this mode for optional rendering of the request in the case of an Initial-Authorization. Usually this mode is empty, since no additional rendering is required.
Unlike modes in service templates, this mode renders requests to the SRC software and not to the router.
Use this mode to control the rendering of the accounting request sent to the SAE. Accounting is a post-authorization service, and it uses the ID numbers and names from the service activation rendering.
Use this mode for rendering of RADIUS disconnect request (DM) upon abort session request from the SAE.
Caveat (Cisco Only)
Cisco routers require an additional step to complete service activation. When the SIC activates a service on a Cisco router, the router sends an extra Access-Request to the SIC to retrieve the service profile. The SIC then sends back an Access-Accept response with VSAs representing the service profile. In response to the extra Access-Request, the SIC has to send all VSAs generated by the previous rendering process. The router then activates the service. This means that the SIC has to render the activation twice. In the second rendering a special mode, Service-Profile-Download is used.
This activation process is different from the usual scenario. Extra Access-Requests happen prior to the SIC response to an SAE request. Therefore, you can minimize the first rendering and place most of the work on the SAE download mode by doing the following:
The Service-Profile-Download mode in the supplied Cisco router configuration template is used to render the answer to the Cisco Profile Download request. The Initial-Authorization or Activation modes are used to render the first Access-Accept or COA message in the packet. To comply with the Cisco requirement to have only the service name in the first Access-Accept or COA message, the Initial-Authorization or Activation modes should contain the attribute for the service name only, and the rest of parameters should be specified using the shared sic group identifier device-template id service-template name mode service-profile-download statement.
In the activation mode, specify only the service name.
In the service-policy-download mode, specify the rest of the needed parameters.
See your Cisco documentation for more information.
All modes have attributes. Attributes define which RADIUS attributes are generated as a result of rendering. All attributes create data that appears in the RADIUS attributes (such as VSAs) generated by the rendering process. It is important to understand that modes are the very core of the rendering process.
Table 37 lists the attributes, explains their parameters, and describes their behavior.
Table 37: Attributes for All Modes
If the renderer finds the attribute in the downstream AAA server response, it copies the value into the RADIUS message for the router. Otherwise, the rendering fails.Options
Whether or not the renderer finds the attribute in the downstream AAA server response, it creates the attribute name with the specified value.Options
If the renderer finds the attribute in the downstream AAA server response, it copies the value into the RADIUS message. Otherwise, it creates the attribute name with the specified value.Options
If the renderer finds the attribute in the downstream AAA server response, it copies the value into the RADIUS message for the router. Otherwise, no action occurs. Unlike required-attribute, the rendering does not fail in this case.Options
The most powerful and flexible part of the template. It generates attribute values using a format specification, which makes it the most flexible of the attributes.Options
Modes can also have variables, which control the rendering process. Variables are subtags under modes. You can use them to render information that is not part of RADIUS attributes. They provide inner logic for the rendering process. Nothing defined by variables appears in VSAs sent to the router.
Variables have three configuration options, described in Table 38.
Table 38: Variables
The variable name
The value, usually an integer
The data type, integer or string
A rule for processing variables: while rendering, when the SIC encounters a variable with a new value, and that variable already has a different value, the rendering stops and sends the results to the SAE. The SAE generates a RADIUS message and resumes rendering with the new value. Thus, it creates two VSAs, one each for the variable values. This correlates with the Bundle capability.
Overriding the Service Correlation ID
You can also use variables to override the service-correlation-id mode. For example,
variable name= "CreateServiceCorrelationId" value="0"
overrides the service-correlation-id mode, so no identification number is created.
The SIC supports tagged attributes, which are an extension of the RADIUS protocol. Refer to RFC 2868 (http://www.ietf.org/rfc/rfc2868) for a description of this feature.
If you have bundle=single and you want to send a single COA activating two services, these activation requests must have the same RADIUS attributes, but with different values. To discriminate between attributes from two separate activation requests, you must use a unique tag for each.
Specify tagged attributes using the shared sic group identifier device-template id service-template name mode (activation|deactivation|initial-authorization|service-correlation-id|service-profile-download) attributes tagged-group name statement.
Each service template is restricted to have only one tagged group; for attributes configured under the tagged-group, only attributes that support tags are affected. Otherwise, it has no effect if the configured attributes does not support tagging.
The attributes described in Table 37 are also support for tagged attribute configurations.