Using Mutex Groups to Activate and Deactivate Subscriber Services

Service Manager supports two methods that use RADIUS CoA-Request messages to activate and deactivate subscriber services and that can also dynamically change a service that is currently provided to a subscriber.

In the first method, you use a CoA message with the Activate-Service VSA to activate the new service; you can optionally include the Deactivate-Service VSA to deactivate the subscriber’s existing service. This method is described in Using RADIUS to Activate Subscriber Service Sessions .

The second method uses mutual exclusion (mutex) groups to create mutex services. With this method, you group services together in a mutex group. When you use a CoA message to activate a service that is in a mutex group, Service Manager activates the new service and implicitly deactivates any existing service that it is a member of the same mutex group as the newly activated service. Service Manager does not deactivate an existing service that is a member of a different mutex group or is not a member of a mutex group.

Using mutex services results in an more reliable activation and deactivation process than the original CoA-Request method. With mutex services, Service Manager always activates the new service before deactivating the existing service. This ensures that the subscriber is never without an active service. In the original CoA-Request method, the order of activation and deactivation is random—in some cases the existing service might be deactivated before the new service is activated, or the new activation might fail. In these cases, the subscriber might be without an active service.

If statistics are enabled when you activate a mutex service, Service Manager sends a RADIUS Acct-Stop message for the deactivated service.

Activating and Deactivating Multiple Services

The Service Manager mutex service feature enables you to activate and deactivate multiple services with a single CoA-Request message. A CoA-Request message can have more than one service activation request—the multiple service requests might be from the same mutex group or from different groups. The following examples describe how you might use mutex groups to activate and deactivate multiple services.

• Example 1—Multiple mutex services of the same mutex group

  Service Manager activates the multiple mutex services, which are in the same group, then deactivates all previously existing services that are also members of that mutex group. Active services that are members of different mutex groups are unaffected.

• Example 2—Multiple mutex services of different mutex groups

  Service Manager activates the mutex services, which are members of different mutex groups. Service Manager then deactivates all previously existing services that are members of the same mutex groups as any of the newly activated services. Active services that are members of different mutex groups are unaffected.

Configuring a Mutex Service

To configure and enable a mutex service, you complete the following steps:

1. Create the new service definition and configure the service as a member of a mutex group.

   When you create the service definition, include the following service attribute in the service definition, where groupIndex identifies the mutex group for this service. The groupIndex can be a number in the range -1 to - 2147483647 or 1 to 2147483646. If the groupIndex is outside of the acceptable ranges, or if you do not include the mutex-group statement, the service is not included in a mutex group.

   <# env.setResult("mutex-group", “groupIndex” ) #>

   For example (the mutex group attribute is highlighted in bold text):

   !parameterizes input and output bandwidth
   <# tiered(inputBW, outputBW) #>

   <# uid := app.servicemanager.getUniqueId #>
   <# name := "SM-tiered-" $ uid #>
   <# oname := "SM-O-tiered-" $ uid #>

   classifier-list matchAll ip any any
   rate-limit-profile <# name #> one-rate
   committed-rate <# inputBW; '\n' #>

   policy-list <# name; '\n' #>
   classifier-group matchAll precedence 10000
   rate-limit-profile <# name; '\n' #>
   traffic-class best-effort

   policy-list <# oname; '\n' #>
   classifier-group matchAll precedence 10000
   traffic-class best-effort

   profile <# name; '\n' #> 
   ip policy secondary-input <# name #> statistics enabled merge
   ip policy output <# oname #> statistics enabled merge
   qos-profile triplePlayIP
   qos-parameter maxSubscBW <# outputBW; '\n' #>

   <# env.setResult("mutex-group", “12” ) #> 
   <# env.setResult("activate-profile", name) #>
   <# env.setResult("secondary-input-stat-clacl", "matchAll") #>
   <# env.setResult("output-stat-clacl", "matchAll") #>

   <# endtmpl #>

2. Activate the mutex service

   Use a RADIUS CoA-Request message and the new service definition to create the mutex service. The new service is considered a mutex service because it belongs to a mutex group.

   Service Manager activates the new service and deactivates any existing active service that is a member of the same mutex group as the new service.

3. (Optional) Verify the status of the new service.

   host1# show service-management subscriber-session client1@isp.com interface ip 192.168.0.1
   User Name: CLIENT1@ISP.COM, Interface: ip 192.168.0.1
    Id: 1
    Owner: AAA 4194326
    Non-volatile: False
    State: Active
    ServiceSessions:
          Name             mutex  Owner/Id     State              Operation
   ----------------------- -----  ----------- ------------------  ---------
   tiered(2000000,3000000)  12   AAA 4194326  ConfigApplySuccess  Activate
          Name             Non-volatile
   ----------------------- ------------
   tiered(2000000,3000000)   False