ON THIS PAGE
An aggregate service comprises a number of individual services. Topics include:
SRC Aggregate Services Overview
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 1 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.
The services that make up 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, assigned IP address, distinguished name (DN), interface name, login name, or associated virtual router.
To use aggregate services requires that the network information collector (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 OnePopDnSharedIp, 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 NIC Configuration Scenarios.
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.
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 (SRC CLI).
While activating an aggregate service session, you can specify different activation attributes. Some of these attributes are propagated to the fragments of the aggregate service session.
An aggregate service becomes active when:
All mandatory services are active.
If a mandatory service does not start, the SAE deactivates any fragment services that are active.
If there are no mandatory services, the aggregate service is still active and trying to activate fragment services.
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.
Depending on your implementation, accounting software could detect that a fragment service session became active even though the associated aggregate service did not become active, resulting in the fragment services being deactivated.
You can configure your accounting software to ignore the activation of the fragment session when an aggregate service session fails. This way, a customer is not billed for an aggregate service that was not received.
Attributes Used to Activate an Aggregate Service Session
The following attributes are propagated from an aggregate service session to its fragments:
When a fragment session is activated from an aggregate service session, the substitutions attribute has the following behaviors:
The substitutions attribute is used when an aggregate session is activated.
The substitutions attribute is defined in the fragment service. You can define a list of substitution names. The values are acquired from an acquisition path.
The following attributes are not propagated from an aggregate service session to its fragments:
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.
The aggregate service session propagates the following modified attributes to the fragments:
The modify service session does not support the modification of substitutions used in the subscriber reference expression, which results in the activation and deactivation of the fragments.
The aggregate service session triggers the modify functionality to its fragments. When you publish an authentication event, you can deny the modification for the fragment. This leads the modify functionality to split into the following steps:
The aggregate service session must receive an approval from all the fragments when you publish the service authentication event.
The specified modify functionality is performed. For example, for a policy service session, provisioning objects are updated. This step occurs only if an aggregate service session received an approval from all the fragments in the previous step.
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 Common Open Policy Service (COPS) client stops on a router running JunosE Software or the configuration database is reset on a router running Junos OS, the SAE associated with the router receives notification that the keepalive message failed.
Aggregate services are activated in a way similar to any other service, but with the additional requirement of activating the associated fragment services. Figure 2 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 2.
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.
The aggregate service initiates accounting, if accounting has been configured.
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.
Before You Configure an Aggregate Service
Before you configure an aggregate service:
Plan the aggregate service:
Plan which fragment services will constitute the aggregate service.
Plan the routers on which the fragment services are to be activated.
Configure the fragment services.
If the aggregate service includes services to be activated remotely, ensure that one or more NIC proxies are configured on each SAE.
Ensure that the NIC is configured to use a scenario that provides the appropriate type of key.
See NIC Configuration Scenarios.
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 Port Settings for SRC Components.
Ensure that the communication between SAEs is secure.
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.
How Parameters Are Passed from Aggregate Service to Fragment Service
There are two ways to set up parameters in aggregate and fragment services:
If you use just a parameter name in the aggregate service, for example user_IpAddress, then the value of user_IpAddress in the aggregate session is bound to the name user_IpAddress in the fragment service.
If you use user_IpAddress as the parameter name and fragSubrIp=user_IpAddress as a substitution in the aggregate service, user_IpAddress is given a different name in the fragment service session. The parameter name fragSubrIps in the fragment service session is bound to the value of user_IpAddress in the aggregate service session.
Use this scheme to configure parameters and substitutions when the parameter in the aggregate service session has a name that is already used in the fragment for something else. A common example is user_IpAddress, which is usually defined in all service sessions. This scheme is also useful when you are aggregating services developed independently. You can call the aggregate service parameters whatever makes sense in that context, and name the fragment service parameters independently.
Configuring Fragment Services for an Aggregate Service (SRC CLI)
Use the following configuration statements to configure an aggregate service in the global service scope:
Use the following configuration statements to configure an aggregate service in a service scope:
To configure fragment services for an aggregate service:
From configuration mode, enter the service aggregate configuration. In this sample procedure, the service called MirrorAggregate is configured in the scope configuration.user@host# edit services scope TM service MirrorAggregate aggregate fragment 0
Configure the subscriber reference expression that identifies the remote subscriber session that will host the fragment.[edit services scope TM service MirrorAggregate aggregate fragment 0]user@host# set expression expression
Configure the name of the service to be included in the aggregate service as a fragment service.[edit services scope TM service MirrorAggregate aggregate fragment 0]user@host# set service service
(Optional) Specify whether the fragment service must be active for the aggregate service to become active.[edit services scope TM service MirrorAggregate aggregate fragment 0]user@host# set mandatory
(Optional) Configure the group name to be applied to each fragment service that is to be part of a redundancy group.[edit services scope TM service MirrorAggregate aggregate fragment 0]user@host# set redundancy-group redundancy-group
(Optional) Specify whether a remote subscriber session is required to subscribe to the fragment service.[edit services scope TM service MirrorAggregate aggregate fragment 0]user@host# set subscription-required
(Optional) Configure the list of substitutions that are used as arguments for the fragment to become active.[edit services scope TM service MirrorAggregate aggregate fragment 0]user@host# set substitution [ substitution... ]
(Optional) Verify your configuration.
[edit services scope TM service MirrorAggregate aggregate fragment 0] user@host# show expression
"vr=\"<- substitution.vrNames ->\", interfaceName=\"FORWARDING_INTERFACE\""; service MirrorFragment; substitution fragSubrIps=subrIps;
Configuring Timers for Aggregate Services (SRC CLI)
You can change the values for several timers to specify the intervals associated with monitoring and activating aggregate sessions. Use the following configuration statements to configure these timers and intervals:
To configure timers used by aggregate services:
From configuration mode, enter the shared sae aggregate service configuration.user@host# edit shared sae configuration aggregate-services
Configure the 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.[edit shared sae configuration aggregate-services]user@host# set keepalive-time keepalive-time
Configure the time to wait for an acknowledgement of a keepalive message before sending a new keepalive message if a response to a keepalive message is not received.[edit shared sae configuration aggregate-services]user@host# set keepalive-retry-time keepalive-retry-time
Configure the length of time to continue to try to activate or deactivate a fragment service session.[edit shared sae configuration aggregate-services]user@host# set activation-deactivation-time activation-deactivation-time
Configure the 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.[edit shared sae configuration aggregate-services]user@host# set failed-notification-retry-time failed-notification-retry-time
(Optional) Verify your configuration.
[edit shared sae configuration aggregate-services] user@host# show keepalive-time 150000; keepalive-retry-time 900; activation-deactivation-time 900; failed-notification-retry-time 9200;
Using Python Expressions in a Subscriber Reference Expression
You can compose Python expressions from one or more of the fields in Table 4 for the definition of a subscriber reference expression of a fragment service. You enter these expressions with the expression option of the services scope name service name aggregate fragment or edit services global service name aggregate fragment statement.
Table 4: Fields Used in Python Expressions for Aggregate Services
Value of the parameter <xyz>.
Substitutions are acquired by means of the regular acquisition path for service sessions.
The names of parameters are restricted to valid Python identifiers, such as ‘ALPHA/” _” *(ALPHA/ DIGIT/” _” )’, with the exception of keywords, such as for, if, while, return, and, or, not, def, class, try, exceptFor the full list of Python keywords, see https://docs.python.org/2/library/.
The type of subscriber session, one of the following:
Login name provided by a subscriber
Username portion of the loginName
Domain name portion of the loginName
Content of the vendor-specific RADIUS attribute for service bundle
RADIUS class used for authorization
Name of virtual router in the format vrname@hostname
Name of the interface
Description of the interface configured on the router
Alternate name for the interface. This is the name used by the Simple Network Management Protocol (SNMP).
On a router running JunosE Software, the format of the description is:
On a router running Junos OS, ifDesc is the same as interfaceName.
Type of the interface. The values could be IP for IPv4; IPV6 for IPv6; IP,IPV6 for dual-stack interface.
Port identifier of an interface, including the interface name and additional layer 2 information (for example, fastEthernet 3/1)
Text representation of the MAC address for the DHCP subscriber (for example. 00:11:22:33:44:55)
Distinguished name of the retailer
Network access server IP address of the router
DHCP options. See Classification Scripts Overview.
PPP or DHCP username. This name does not change when the subscriber logs in through a portal.
Configures a condition that uses the IPv6 address prefix.
framedIpv6Prefix is available for JunosE (COPS-PR), Junos OS (JSRC), as well as AAA (COA).
Delegated IPv6 prefix for the subscriber.
Using the delegatedIpv6Prefix attribute, the NAS can receive a set of IPv6 prefixes that are delegated to subscribers. An IPv6 subscriber can be identified through multiple prefixes by using the delegatedIpv6Prefix attribute with the framedIpv6Prefix attribute.
delegatedIpv6Prefix is available for Junos OS (JSRC), AAA (COA), and DHCPv6 subscribers on the JunosE router.