Aggregating Services
An aggregate service is a type of value-added service that comprises a number of individual services. Combining services lets the SRC software treat the services within an aggregate service as a unit. When an aggregate service becomes active, it tries to activate all the services within it.
An aggregate service can distribute the activation of a number of services within the aggregate across one or more SAEs in an SRC network. This specialized service is ideal for supporting voice over IP (VoIP) and video on demand. To deliver these types of features to subscribers, you can configure bidirectional or unidirectional quality of service (QoS) services based on policies provisioned across a number of interfaces on one or more SAE-managed network devices in an SRC network. Figure 3 shows a sample aggregate service that provides end-to-end QoS for video on demand, with QoS Service 1 and QoS service 2 activated on Juniper Networks routers in the path between the video server and the subscriber.
![]()
The services included in an aggregate service manage policies in the usual manner. The aggregate service does not directly manage any policies on a network device.
Fragment Services
The services that comprise an aggregate service are referred to as fragment services. This term provides a way to distinguish between services that are included in an aggregate service and those that are not. The fragment services can be any type of service that the SAE supports, except another aggregate service.
Subscriber Reference Expressions for Fragment Services
The configuration for each fragment service includes a subscriber reference expression, a phrase that identifies the subscriber sessions that activate the fragment service. The subscriber reference expression defines the subscriber session by subscriber IP address, DN, object path, login name, or associated virtual router.
To use aggregate services requires that the NIC be configured. Use a configuration scenario that provides a key for the type of subscriber reference expression defined for the fragment service. For example, if the subscriber reference expression is a DN, the NIC key is also a DN. In this case, you could use the NIC configuration scenario OnPopDnSharedIp, which uses a DN as a key.
For more information about the NIC configuration scenarios and the types of resolutions performed by these scenarios, see SRC-PE Network Guide, Chapter 21, NIC Configuration Scenarios.
Mandatory Services
A fragment service that must be active for an aggregate service to become active is called a mandatory service. When you configure an aggregate service, you specify which services, if any, are mandatory. For example, you could specify that rate-limiting services for a video-on-demand connection be mandatory to ensure call quality.
Redundant Services
When you configure an aggregate service, you can configure fragment services to provide redundancy for each other. Fragment services that share the same redundancy group name provide redundancy.
For an aggregate service to become active, at least one fragment service from each redundancy group must become active. For example, if you configure two services, S1 and S2, and assign the same redundancy group name to each of these services, S1 and S2 provide redundancy for each other if one becomes disabled.
While an aggregate service is active, the SAE tries to keep all fragment services within it active. An aggregate service and any of its active fragment services become inactive if a mandatory fragment service or an entire redundancy group becomes inactive.
Aggregate Service Sessions
An aggregate service session coordinates the activation of the services within it. It runs on the same SAE where it starts. The aggregate service session is created in the router driver that hosts the subscriber session that starts the service. An individual service session for a fragment service can be activated in the same SAE or another SAE on the SRC network.
Understanding how aggregate service sessions are managed can help you troubleshoot service activation or service deactivation issues that might arise. The SRC software provides a set of configurable timers that helps control session management.
For information about the timers that you can use to troubleshoot aggregate services, see Configuring Timers for Aggregate Services.
Session Activation
An aggregate service becomes active when:
If a mandatory service does not start, the SAE deactivates any fragment services that are active.
If any fragment services that are not mandatory services do not become active, the aggregate service continues to try to start them. How long the aggregate service tries to activate fragment services depends on the settings for activation-deactivation time.
When an aggregate service becomes active, it monitors the services that are part of the aggregate service.
Session Deactivation
When the SAE deactivates an aggregate service, the aggregate service session tries to deactivate the services within it. The SAE deactivates an aggregate service when all fragment services stop. If one of these services remains active, the aggregate service stays in memory until the service session ends. The SAE periodically tries to stop the active fragment session until the maximum retry time is reached, at which time it deactivates the aggregate service. As a result, the aggregate service session can remain in memory after the associated subscriber session ends.
Session Monitoring
An aggregate service session exchanges keepalive messages with a session management process for remote fragment services. This way, if a service session is removed from a router while the SAE is not managing the router, such as when the COPS client stops on a JUNOSe router or the configuration database is reset on a JUNOS routing platform, the SAE associated with the router receives notification that the keepalive message failed.
Service Activation
Aggregate services are activated in a similar way as any other value-added service, but with the additional requirement of activating the associated fragment services. Figure 4 shows a sample service activation for a video-on-demand service.
![]()
The following process describes the service activation for a video-on-demand service, with Steps 1-4 illustrated in Figure 4.
- A subscriber requests a video-on-demand service through a residential portal.
- The residential portal requests the service through the SAE.
- The SAE activates a subscription for the associated aggregate service, and a session for the aggregate service becomes active.
- The aggregate service coordinates with the SAE, and the SAE tries to activate the fragment services that have been configured for the aggregate service.
- The aggregate service becomes active when:
- All mandatory services are active.
- If there are no mandatory services, at least one fragment service is active.
- For redundant fragment services, at least one fragment service configured for a redundancy group becomes active.
After the aggregate service becomes active, it monitors fragment services to ensure that they are still active. When the subscriber or the video server ends the video-on-demand session, the aggregate service tries to terminate active fragment services.
For detailed information about service activation, see SRC-PE Subscribers and Subscriptions Guide, Chapter 3, Subscriber Logins and Service Activation.
Before You Configure an Aggregate Service
Before you configure an aggregate service:
- Plan which fragment services will constitute the aggregate service.
- Plan the routers on which the fragment services are to be activated.
See Adding a Normal Value-Added Service.
- If the aggregate service includes services to be activated remotely, ensure that the NIC is configured and running on each SAE that resides in your SRC network.
- Ensure that the NIC is configured to use a scenario that provides the appropriate type of key.
See Subscriber Reference Expressions for Fragment Services.
- Ensure that the SAEs can communicate with each other and the NIC host(s). Make sure that firewalls permit TCP and CORBA communication between the systems hosting the SAEs, and communication between the NIC host(s) and the SAE.
See SRC-PE Getting Started Guide, Chapter 29, Defining an Initial Configuration on a Solaris Platform.
Follow the standards for your organization to ensure that communication between SAEs is protected.
- If the aggregate service is to include a fragment service on a remote SAE, ensure that the remote fragment service can become active by verifying that the fragment service is loaded on the remote SAE.
Adding an Aggregate Service
To use SDX Admin to add an aggregate service:
The New SSP Service dialog box appears.
An object for the new service appears in the navigation pane, and basic information about the new service appears in the Main tab of the SSP Service pane.
![]()
If you want to specify values for other fields in the Main tab, see Value-Added Service Fields.
The Aggregate tab appears in the content pane.
![]()
- In the Aggregate tab, click New to define a fragment service to be included in the aggregate service.
The Service Fragment dialog box appears.
![]()
- In the Aggregate Service tab, click Add to add the fragment service to the aggregate service.
- Repeat Steps 5-7 for each fragment service to be added to the aggregate service.
- Click Save.
Configuration Examples for Aggregate Services
For configuration examples for aggregate services see the following chapters:
- SRC Application Library Guide, Chapter 9, Configuring Services and Subscriptions to Integrate IDP
- SRC Application Library Guide, Chapter 5, Mirroring Subscriber Traffic in the SRC Network
Service Fragment Fields
In SDX Admin, you can modify the fields in this section to configure a fragment service for an aggregate service in the Service Fragment dialog box.
Expression
- Subscriber reference expression that identifies the remote subscriber session that will host the fragment. The remote subscriber session is an assigned IP subscriber. If the remote SAE manages the specified interface, the SAE creates an assigned IP subscriber session if necessary.
- Value—Use one of the following values to identify the remote subscriber session. The items in the list show the syntax to use.
- current—The remote subscriber session is the same as the current subscriber session
- address = "<IP address>"
- vr = "<virtual-router name>", interfaceName = "<interface name>"
- vr = "<virtual-router name>", ifIndex = "<interface index>"
- dn = "<DN of the subscriber profile>"
- vr = "<virtual router name>", interfaceName = "<interface name>", address = "<IP address>"
- login_name = "<login-name>"
- vr = "<virtual-router name>", login_name = "<login-name>"
- primary_user_name = "<PPP login name | authenticated DHCP login name>"
- vr = "<virtual-router name>", primary_user_name = "<PPP login name | authenticated DHCP login name>"
- ref= "<path>"
The <path> identifies the hierarchy of directory objects below the LDAP object o=aggregateService. The final object contains the attribute subscriberRefExpr to identify the subscriber session. A forward slash (/) separates the objects in the path.
- Guidelines—You can also use Python expressions to specify literal values listed above. Python expressions access and manipulate data in a subscriber session and a service session, including substitutions. For example, to use a Python expression for a substitution, type <- before the expression and -> after it; for example, <-ifAlias->.
For information about substitutions, see Configuring Substitutions.
For information about using Python expressions to represent values in a subscriber reference expression, see Using Python Expressions in a Subscriber Reference Expression.
To create Python expressions, use the fields in Table 6. You can specify more than one string in a Python script expression.
current
address="10.10.10.1"
vr="<-substitution.serviceVr->",interfaceName=
"<-substitution.serviceInterface->"dn = "uniqueId=<-ifAlias->,<-userDn->"
vr=<-["vr1","vr2"]->,loginName=<-["joe","jane"]->
Service
- Value-added service to be included in the aggregate service as a fragment service.
- Value—Menu of value-added services that have already been configured
- Default—No value
Mandatory
- Specifies whether the fragment service must be active for the aggregate service to become active.
- Value
- mandatory—Fragment service must be active for the aggregate service to become active.
- optional—Fragment service does not need to be active for the aggregate service to become active.
Redundancy Group
- Group name to be applied to each fragment service that is to be part of a redundancy group. The fragment services that have the same group name provide redundancy for each other.
- Value—Text
- Default—No value
Subscription
- Specifies whether a remote subscriber session is required to subscribe to the fragment service.
- Value
- true—Remote subscriber session must be subscribed to the fragment service for it to become active.
- false—Remote subscriber session does not need to be subscribed to the fragment service for it to become active.
- Guidelines—Enabling subscription can be used to limit the services that can be activated as fragments.
Setting this field to true lets you control which services can be used as fragments. For example, for an aggregate service that supports VoIP to push a policy to the caller and the callee, you can require that both subscribers sign up for VoIP services. If you set the field to false, only one party needs to subscribe to the aggregate service; the policy service sessions are created automatically.
Substitutions
- List of substitutions, in the correct syntax, that are used as arguments for the fragment to become active. If a parameter does not acquire a value, the associated fragment service does not become active.
For information about acquiring substitution values, see Chapter 15, Defining and Acquiring Values for Parameters.
Use commas to separate multiple substitutions.
- Guidelines—If you specify <parameter-name> for the value, the parameter name is defined to have the same value in the fragment service session as in the aggregate service session.
- If you specify <parameter-name>=<substitution-expression> for the value, the parameter name on the left side of the equals sign is defined for the fragment service session. This parameter name is the result of the evaluation of the expression (in the aggregate service session) on the right side of the equals sign.
- Default—No value
Using Python Expressions in a Subscriber Reference Expression
You can compose Python expressions from one or more of the fields in Table 6 for the definition of a subscriber reference expression of a fragment service. You enter these expressions in the Expression field of the Fragment Service dialog box in which you define a fragment service for an aggregate service.
For information about configuring fragment services for an aggregate service, see Adding an Aggregate Service.
Configuring Timers for Aggregate Services
You can change the values for several timers to specify the intervals associated with monitoring and activating aggregate sessions.
To use SDX Configuration Editor to change timers used by aggregate services:
- In the navigation pane, select an SAE configuration file.
- Select the Miscellaneous tab, and expand the Aggregate Services section.
![]()
- In the Aggregate Services section, edit or accept the default values for the fields.
See Aggregate Services Fields.
- Select File > Save.
- Right-click the configuration file, and select SDX System Configuration > Export to LDAP Directory.
Aggregate Services Fields
In SDX Configuration Editor, you can modify the following fields in the Aggregate Services section of the Miscellaneous pane in an SAE configuration file.
Keepalive time [s]
- Interval at which keepalive messages are sent between an aggregate service session and an associated remote service management session to verify that an aggregate service is active.
- Value—Number of seconds in the range 1-2147483647
- Default—86400
- Property name—Service.aggregate.keepalive_time
Keepalive retry time [s]
- Length of time to continue sending keepalive messages if a response to a keepalive message is not received.
- Value—Number of seconds in the range 1-2147483647
- Default—900
- Property name—Service.aggregate.retry_time
Activation-Deactivation time [s]
- Length of time to continue to try to activate or deactivate a fragment service session.
- Value—Number of seconds in the range 1-2147483647
- Default—900
- Property name—Service.aggregate.reactivation_time
Failed notification retry time [s]
- Length of time to continue sending failure notifications if an aggregate service cannot reach a fragment service, or a fragment service cannot reach an aggregate service during shutdown of the aggregate service.
- Value—Number of seconds in the range 1-2147483647
- Default—86400
- Property name—Service.aggregate.max_notification_time