SDX 6.4.x Services and Policies Guide > Managing Services > Aggregating Services

Aggregating Services

An aggregate service is a type of value-added service that comprises a number of individual services. Combining services lets the SDX 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 SDX 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 routers in the SDX 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 routers in the path between the video server and the subscriber.

Figure 1: Sample Configuration of an Aggregate Service

The services included in an aggregate service manage policies in the usual manner. The aggregate service does not directly manage any policies on the router.

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.

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 VoIP 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 each other.

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.

Aggregate Service Sessions

An aggregate service session coordinates the activation of the services within it. It runs on the same router where it starts. An individual service session for a fragment service can be activated in the same SAE or another SAE on the SDX network.

Understanding how aggregate service sessions are managed can help you troubleshoot service activation or service deactivation issues that might arise. The SDX software provides a set of configurable timers that helps control session management. For information about these timers, see Configuring Timers for Aggregate Services.

Session Activation

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, at least one service is 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. See Configuring Timers for Aggregate Services.

When an aggregate service becomes active, it initiates accounting, if configured, for the aggregate service and monitors the services that are part of the aggregate service.

NOTE: 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.

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.

Before You Configure an Aggregate Service

Before you configure an aggregate service:

• Plan the aggregate services, and configure the individual, or normal, services that you plan to include in an aggregate service. See Adding a Normal Value-Added Service.
• If the aggregate service is to include a fragment service on a remote SAE, to ensure that the remote fragment service can become active, verify that the fragment service is loaded on the remote SAE.

You can check the status of a fragment service from SDX Admin. Select the service in the navigation pane, and review the setting for the Status field in the Main tab in the content pane.

• If the aggregate service includes services to be activated remotely, ensure that:

• The network information collector (NIC) is configured to and running on each SAE that resides in your SDX network. The NIC must be configured to use a scenario that uses the subscriber reference expression of a fragment service as a key. For example, if the subscriber reference expression is a DN, the NIC resolution scenario must use DN as a key. See SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 5, Locating Subscriber Information.
• A NIC proxy is configured. See SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 7, Configuring Applications to Communicate with an SAE.
• The SAEs can communicate with each other. Make sure that firewalls permit communication between the systems hosting the SAEs.
• The communication between SAEs is secure.

Follow the standards for your organization to ensure that communication between SAEs is protected.

Adding an Aggregate Service

To add an aggregate service:

1. Follow the procedure for creating a normal value-added service. See Adding a Normal Value-Added Service.
2. In the Main tab, set the Type to aggregate.
3. Click the Aggregate tab.

The Aggregate tab appears in the content pane.

4. In the Aggregate tab, click New to define a fragment service to be included in the aggregate service.

The Service Fragment dialog box appears.

5. Use the field descriptions in Aggregate Service Fields to fill in the fields in the Fragment Service dialog box, and then click OK.
6. In the Aggregate Service tab, click Add to add the fragment service to the aggregate service.
7. Repeat Steps 4-6 for each fragment service to be added to the aggregate service; then click Save.

Aggregate Service Fields

Use the fields in this section to configure aggregate services 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 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 a substitution or a Python expression that represents any of the literal values listed above. For a substitution or Python expression, type <- before the expression and -> after it; for example, <-ifAlias->.

For information about substitutions, see Configuring Substitutions.

To create Python expressions, use the fields in Table 4. You can specify more than one string in a Python script expression.

 Table 4:  Fields Used in Python Expressions for Aggregate Services  

 Field
 Description

 substitution.<xyz>

 The value of the substitution <xyz>.
 Substitutions are acquired by means of the regular acquisition path for service sessions. 
 The name of substitutions is 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, except. For the full list of Python keywords, see http://docs.python.org/ref/keywords.html. 


 loginType

 The type of subscriber session, one of the following:

  
 ASSIGNEDIP—An assigned IP login is triggered when an application accesses a subscriber object for an assigned IP subscriber that is not currently loaded into memory. (JUNOSe routers)
  
 AUTHINTF—An AUTHINTF login is triggered when an interface responds to authentication, such as authentication for a PPP session. (JUNOSe routers)
  
 INTF—An interface login is triggered when an interface comes up and the interface classifier script determines that the SAE should manage that interface, unless the interface comes up as a result of an authenticated PPP session. (JUNOS routing platforms and JUNOSe routers)
  
 ADDR—An ADDR login is triggered when the DHCP server in the JUNOSe router provides a token IP address. (JUNOSe routers)
  
 AUTHADDR—An AUTHADDR login is triggered when the DHCP server in the JUNOSe router provides a public IP address. (JUNOSe routers)
  
 PORTAL—A portal login is triggered when the portal API is invoked by a JSP Web page to log in a subscriber. (JUNOS routing platforms and JUNOSe routers)



 loginName

 Login name provided by a subscriber


 userName

 Username portion of the loginName


 domainName

 Domain name portion of the loginName


 serviceBundle

 Content of the vendor-specific RADIUS attribute for service bundle


 radiusClass

 RADIUS class used for authorization


 virtualRouterName

 Name of virtual router in the format vrname@hostname


 interfaceName

 Name of the interface


 ifAlias

 Description of the interface configured on the router


 ifDesc

 Alternate name for the interface. This is the name used by the Simple Network Management Protocol (SNMP).
 On a JUNOSe router the format of the description is:
 ip<slot>/<port>.<subinterface>
 On a JUNOS routing platform, ifDesc is the same as interfaceName.


 nasPortId

 Port identifier of an interface, including the interface name and additional layer 2 information (for example, fastEthernet 3/1)


 macAddress

 Text representation of the MAC address for the DHCP subscriber (for example. 00:11:22:33:44:55)


 retailerDn

 Distinguished name of the retailer


 nasIp

 NAS IP address of the router


 dhcp

 DHCP options. See SDX Subscribers and Subscriptions Guide, Chapter 4, Classifying Interfaces and Subscribers.


 primaryUserName

 The PPP or DHCP username. This name does not change when the subscriber logs in through a portal.



 

• Default—No value
• Examples

• 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.

• Default—Mandatory

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.

• Default—False

Substitutions

• List of substitutions, in the correct syntax, that are used as arguments for the fragment to become active. If a substitution does not acquire a value, the associated fragment service does not become active.

For information about substitution value acquisition, see Chapter 7, Defining and Acquiring Values for Parameters.

• Value

• <substitution-name>
• <substitution-name>=<substitution-name>

Use commas to separate multiple plug-ins.

• Guidelines—The substitution name defined on the left side of the equals sign is passed to the fragment service with the value of the substitution on the right side of the equals sign.
• Default—No value

Configuring Timers for Aggregate Services

You can change the values for several timers to specify the intervals associated with monitoring and activating aggregate sessions. You set timer values in SDX Configuration Editor.

To change timers used by aggregate services:

1. In the SDX Configuration Editor navigation pane, select SAE > <POP-ID.xml>, where <POP-ID.xml> identifies a specific SAE server.
2. In the content pane, select the Miscellaneous tab, and expand Aggregate Services.
3. Under Aggregate Services, change the information in any of the following fields.

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