TECHNICAL PRODUCT DESCRIPTION     1/221 02-CRA 119 1170/1 Uen B    

Advanced Services Infrastructure Overview

© Ericsson AB 2009–2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.


The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

SmartEdge is a registered trademark of Telefonaktiebolaget LM Ericsson.
NetOp is a trademark of Telefonaktiebolaget LM Ericsson.


1.2Target Groups


ASE Card
2.1Supported Routers
2.2ASE Card Placement
2.3Service Selection


ASP Pools, ASP Groups, and Service-Enabled Contexts
3.1High Availability
3.2Load Balancing
3.3Configurable Drop/Bypass Behavior


Guidelines for Defining ASP Pools and ASP Groups


High Availability and Load Balancing Deployment Scenarios


Reference List

1   Introduction

This document describes the Advanced Services Engine (ASE) card and the software infrastructure that supports the applications that can be installed and run on this card.

1.1   Scope

The ASE card contains two Advanced Service Processors (ASPs) that provide additional processing power on a SmartEdge® router. This document describes ASE card functionality and placement in a SmartEdge routers, and how to use ASP pools and groups distribute the processing capabilities of the ASPs on the ASE cards installed in the router, provide load balancing when multiple ASPs are installed, and support resiliency when excess ASPs are available.

1.2   Target Groups

This document is intended for network planners responsible for the design of advanced network services that use the SmartEdge router and for operators of the SmartEdge OS responsible for entering the configuration on individual SmartEdge routers.

2   ASE Card

The ASE card provides advanced services that are beyond the scope of the terminating and forwarding capabilities provided by traffic cards. Service security, which provides support for IP Security (IPsec) Virtual Private Network (VPN) and Application Traffic Management is the only ASE-based service available in this release.

Unlike a traffic card, an ASE card does not have any input/output (I/O) interfaces that are used for traffic processing; it receives all traffic it processes through the backplane. The ASE card provides additional processing to specific flows after ingress processing is completed on an incoming traffic card but before the flows are forwarded to an outgoing traffic card for egress processing.

The ASP provides the processing functionality of an ASE card; each ASE card has two ASPs. Each ASP can be configured to provide ASE-based services, support high availability, and support load balancing.

Several ASE cards can be deployed in a SmartEdge chassis, and one or more traffic cards can send traffic to them. Unlike a traffic card, which processes the traffic it receives, an ASP on an ASE card processes specific traffic flows forwarded to it, regardless of the traffic card that received the flow. You use ASP pools and ASP groups to specify the ASE-based service to be provided, balance the processing load, and provide high availability of services by the ASE card. ASP pools and ASP groups allow you to use more than one ASP on more than one ASE card to provide the same set of ASE-based services to specific traffic flows and to provide fail-over support. For more information, see Section 3.

2.1   Supported Routers

The ASE card is supported on the following types of SmartEdge routers running the SmartEdge OS, Release 6.1.5

2.2   ASE Card Placement

The ASE card can be installed in any slot other than the two slots reserved for Cross Connect Route Processor (XCRP) controller cards. The XCRP controller cards manage and monitor packet traffic, provide access to the Command-Line Interface (CLI), provide redundancy protection (one card is designated for this function), and manage general node operations. The number of ASE cards that can be provisioned in a SmartEdge chassis is constrained by the power limitations of the chassis and the power consumption of the XCRP controller and traffic cards that are installed. The ASE card power consumption is rated at 175.20 watts.

For ASE card installation instructions, see Reference [1].

2.3   Service Selection

While the ASE card is designed to be a flexible high performance card that can be used to provide different types of ASE-based services, only one service can be provided on a given ASP at one time. Currently, the only supported ASE-based service is the Security Service. Multiple security applications can map to the Security Service and may run concurrently on the same ASP. In release 6.1.5, IPsec VPN and Application Traffic Management are the two applications supported by the Security Service.

3   ASP Pools, ASP Groups, and Service-Enabled Contexts

ASE-based services are provided at the ASP level. To provide these services at the ASP level, you must define ASP pools. An ASP must be a member of an ASP pool to provide these services.

For all installed ASPs to be configured to provide separate instances of ASE-based services, high availability, and load balancing, three logical concepts are used

For more information, see Reference [2] or Reference [3].

See Figure 1 for an illustration of the relationships between ASPs, pools, groups, and context. It shows the step-by-step sequence how an ASP is assigned to process the traffic on a service-enabled context.

Figure 1   ASP Pools and Groups Mediate Between ASPs and Service-Enabled Contexts

3.1   High Availability

High availability mechanisms enable the handling of runtime fault conditions by switching over to a backup ASP or by rebalancing the traffic load among existing active ASPs. When backup ASPs are available, existing services on an active ASP that fails are reestablished on one of the backup ASPs. Active and backup ASPs both contain the current configuration; however, IPsec tunnels will go down briefly and some traffic loss occurs during the switch from a failed active ASP to a backup ASP, which can take several seconds to complete.

For more information, see Reference [4].

3.2   Load Balancing

Load balancing defines how traffic is distributed across different ASPs in a chassis. Load balancing can be viewed at two levels: a high level that is defined through configuration and a low level that is controlled by the SmartEdge OS.

With the NetOp EMS client or the SmartEdge CLI, you create multiple ASP pools, allocate ASPs to the pools, and map the pools to specific services. You then create ASP groups, assign groups to each pool, and map contexts to ASP groups. After completing all of these tasks, contexts and associated services are mapped to a specific ASP group.

For a given context, IPsec tunnels and subscribers requiring application traffic management services, are load balanced across the available ASPs in the ASP group to which the context is bound.

3.3   Configurable Drop/Bypass Behavior

Drop/bypass configuration handles runtime fault conditions when there is no operational ASP to which to forward traffic requiring advanced services. In release 6.1.5, the only application that supports configurable drop/bypass behavior is Application Traffic Management. For IPsec, if the tunnel is down due to lack of ASP resources, the traffic will be dropped (unless an alternate route is available).

For instance, if a SmartEdge chassis has only one ASE card and the ASE card is physically removed or develops a fault condition, then there will be no operational ASP to which traffic can be forwarded. Application Traffic Management provides two options

Drop/bypass behavior cannot be configured for policy configuration.

4   Guidelines for Defining ASP Pools and ASP Groups

You must define ASP pools and ASP groups to access ASE-based services provided by an ASE card. Together, an ASP pool and ASP group are used to identify the ASE-based service to provide, and, when multiple ASPs are employed, to support high availability and load balancing for all ASE cards. For an introduction to the concepts of ASP pools and ASP groups, see Section 3.

You can configure multiple ASP pools on a SmartEdge router; however, the sum of all ASPs across all ASP pools for each type of SmartEdge router cannot exceed the total shown in the right-most column of Table 1. No more than two ASE cards can be installed in a SmartEdge router due to thermal constraints; we recommend installing ASE cards in slots 3 and 4 only.

Table 1    Maximum Number of ASPs by Type of SmartEdge Router


Total Slots

Subtract Controller Cards

Subtract Minimum Number of Traffic Cards

Number of Available Slots

Multiply by Number of ASPs per ASE Card

Maximum Number of ASPs Possible

SmartEdge 400 router







SmartEdge 800 or 1200 router







An ASP can belong to only one ASP pool. ASPs assigned to an ASP pool must share the same system-level attributes, such as service type.

An ASP pool defines the ASE-based service provided and lists the ASPs that are available to provide the service. Multiple pools may be configured for the same service. An ASP group identifies the pool and the number of ASPs from the pool that must be dynamically assigned to provide the service. The actual number of ASPs assigned to the group depends on the priority of the group relative to other groups in the same pool and the total number of available ASPs in the pool. Although configuration allows you to assign fewer ASPs to a pool than is required by all of the groups referencing the pool, we strongly recommend that you allocate sufficient ASPs to a pool to meet the requirements of all groups referencing the ASP. Ensure that the sum of the ASPs specified in all of the groups referencing the same pool is less than the number of ASPs in the pool. This enables the excess ASPs to function as backup ASPs and provides for a fast switch over to the backup ASPs in the event of an ASP or ASE card failure. More than one ASP group can reference the same ASP pool.

With the ASP pool defining the service and the ASP group referencing the ASP pool and specifying the number of ASPs to provide service, the following functionality is enabled

You create an ASP pool to associate specific ASPs with a particular ASE-based service. Figure 2 illustrates the relationships between ASPs and ASP pools.

Figure 2   ASPs Are Assigned to ASP Pools

  1. Several ASPs can be assigned to the same pool. An ASP pool assigned more than one ASP can support high availability and load balancing, depending on how many ASPs are allotted to ASP groups for traffic processing.
  2. Although an ASP pool assigned only one ASP cannot provide high availability and load balancing, it can provide traffic processing for an ASP group responsible for several low-traffic contexts.
  3. An ASP that is not assigned to an ASP pool cannot process traffic that needs Security services.
  4. An ASP pool that is not assigned any ASPs cannot support the processing of traffic that needs Security services.

You create an ASP group to define the number of ASPs to allocate to an ASE-based service, specify the ASP pool that provides the ASPs and the advanced service, and a priority to use for ASP allocation. Figure 3 illustrates the relationships between ASP pools and ASP groups.

Figure 3   ASP Groups Request ASPs From ASP Pools

The number of active ASPs in an ASP pool is determined by the number of ASPs requested by all the ASP groups associated with the ASP pool. Figure 3 illustrates the following relationships:

  1. When the number of ASPs requested by the ASP groups associated with the ASP pool is less than the number of ASPs in the pool, the excess ASPs function as backup ASPs for the pool. The traffic load is balanced across the active ASPs.
  2. When the number of ASPs requested by the ASP groups is equal to the number of ASPs enrolled in the pool, the traffic load is balanced across the available ASPs, all the ASPs are active, and no backup ASP is available.
  3. When a new ASP group is added to the ASP pool and all available ASPs are already active, no ASPs are assigned to the newly added group regardless of priority. There is no preemption of ASP resources once they have been allocated to an ASP group.

When a new ASP is added to the pool, it is assigned to the ASP group with the highest priority that still needs an active ASP.

Associating service-enabled contexts to ASP groups allows you to flexibly specify the number of active and backup ASPs available to process traffic that needs Security services. Figure 4 illustrates the relationships between ASP groups and contexts.

Figure 4   Service-Enabled Contexts Request ASPs From an ASP Group

For example, you can ensure sufficient processing power and high availability for traffic requiring Security services for a single context by associating that context to an ASP group that is the only member of an ASP pool with several ASPs. Allocate the required number of active ASPs from the ASP pool to the ASP group to provide the processing power while ensuring that there are additional ASPs available to function as backup; the unallocated ASPs provide the backup capability. Alternatively, you can provide basic processing support without any backup capability for several contexts by associating those contexts to one ASP group, which in turn can belong to an ASP pool with no backup ASPs.

Figure 4 illustrates the following relationships:

  1. Traffic requiring Security services from multiple contexts can be directed for processing by the ASPs allocated to a single ASP group.
  2. Traffic requiring Security services from a single context can be directed for processing by the ASPs allocated to a single ASP group.

Traffic requiring Security services from different contexts can be directed to different ASP groups.

5   High Availability and Load Balancing Deployment Scenarios

Support for high availability and load balancing is provided at the ASP level.

In the simplest case, you can create an ASP pool with one ASP and configure an ASP group that specifies a count of one ASP referencing that ASP pool and assign it to only one context, thereby dedicating the ASP to that context. Since no excess ASPs exist in the ASP pool, no backup ASPs are available to provide high availability. Also, because the ASP group specifies a count of one ASP, no load balancing is possible.

Alternatively, you can create an ASP group with multiple ASPs and associate multiple contexts to the ASP group; in this case, the software balances the traffic load belonging to the contexts and across the ASPs in the ASP group. Any excess ASPs in the ASP pool function as backup ASPs.

State synchronization between active and backup ASPs in any scenario is not supported in this release.


Advanced Services Engine
Advanced Service Processors
Command-Line Interface
IP Security
Virtual Private Network

Reference List

[1] Quick Installation Guide for the SmartEdge Advanced Services Engine Card, 1/153-30-CSA 113 038/1.
[2] Advanced Services Configuration and Operation Using the NetOp EMS Software, 1553-CRA 119 1170/1.
[3] Advanced Services Configuration and Operation Using the SmartEdge OS CLI, 1/1543-CRA 119 1170/1.
[4] Advanced Services Startup, Failure and Recovery, 1/1553-CRA 119 1170/1.