TNPM/5620SAM/Pack sizing

Alcatel 5620 SAM Application Pack Sizing

From IBM Developerworks forum

The Alcatel 5620 SAM Application Pack makes use of the Netcool/Proviso framework to gather and display in reports information specific to target network devices and technologies that operate in the Alcatel 5620 SAM environment. It is designed to provide performance reports on the services and devices managed by 5620 SAM.

Depending on what type of nodes is deployed, the particular characteristics and distribution of the inventory and metrics can vary widely. For example,Alcatel-Lucent 7750 Service Router and Alcatel-Lucent 7450 Ethernet Service Switch may have many more interfaces than Alcatel-Lucent 7705 Service Aggregation Router, and the number of services per machine would vary based on the size of the machine and the type of usage.

The following are the main factors associated with SAM pack.

1.1 Services

Alcatel-Lucent 5620 SAM users can configure such services as VPRN, VPLS, and customer or subscriber sites to the core network at the SAPs. A user might also configure a set of policies to manage different classes of traffic at the SAPs. A SAP can have one policy applied for ingress traffic, and another for egress (to the customer site). The Alcatel-Lucent 5620 SAM has a predefined set of 8 traffic classes: be, l2, af, l1, h2, ef, h1, and nc. In addition, the Alcatel-Lucent 5620 SAM supports unicast, multicast, and broadcast IP traffic. A user can define a policy to manage each combination of traffic classes and cast types uniquely. With eight classes and four types, 32 different combinations are possible. On a SAP, each unique combination is supported by a separate queue, which means up to 32 queues to be managed. On ingress, the SAPs support separate queues for the different casts of traffic. However, on egress, the SAPs do not support separate queues. Therefore, on egress, there is a maximum of eight queues. The Alcatel-Lucent 5620 SAM represents these entities in the following objects:

• SAPs: A SAP object represents a SAP. The SAP object has a PolicyId property.
• Policies: The Policy object represents the policy.
• ForwardingClasses: A ForwardingClass object represents one of the eight possible classes of traffic. This object has a PolicyId property that indicates the policy to which it belongs. If the object is ingress ForwardingClass, it has four queue IDs, one each for Unicast, Multicast, Broadcast, and Other. If the object is an egress ForwardingClass, it has one queue ID.
• Service queues: An Egress Service Queue object or an Ingress Service Queue object represents a service queue on a SAP.

1.2 Service Access Ports (SAP) Queues

In earlier releases, the SAPs themselves were not inventoried into the TNPM (Proviso) database, as the application did not report any metrics at the SAP level (the pack did report the aggregate totals based on the values reported per the SAP queues, but this is really reporting a group of queues where they are on the same SAP.) In the new releases, availability metrics will be reported on the SAPs. On each SAP there are potentially inbound and outbound queues for each Forwarding Class, up to 8 FC in all. In fact for the inbound direction there can be up to 4 queues per FC for each type: multicast, unicast, broadcast and other. Typically a subset is used, and FC might be mixed on a single interface. The Tech discovers these queues using a variety of SAM resources. These include the policies and forwarding classes from the aingr and aengr packages as well as the SAPs from a variety of packages. The queue information is constructed from this information.

Note: This also means the JMS driven inventory is a bit more complex as multiple events might need to be processed before one or more queue resources can be updated. If a policy changes, or a SAP or a FC definition, it can change a number of queue resources in the Proviso data model.

1.3 Inventory Estimation:

Estimates of the SAM pack inventory size can be made by looking at the inventory on the SAM server. For most of the inventory types collected by the SAM pack, there is a one-to-one correspondence between the inventory objects in the SAM server and the sub-elements in Proviso. (Note that this is with the entire inventory enabled on the SAM server.) For example, if you use the SAM GUI client to look the number of physical ports in the SAM server, the same number of physical port sub-elements will be created by the SAM pack. A more complex case is presented by the SAP queues and network queues. In these cases, the number of queue sub-elements for any port will be determined by the policy(s) assigned to that port and the number of queues defined by that policy. The total number of queue sub-elements may be determined by the sum of all the queues on each port for the entire network. This applies separately to both the network queues and SAP queues, using their respective policies.

In many cases, the default policy may be used. These defaults result in 3 queues per SAP (one ingress, one egress) and 16 queues per network port. This results in a simplified calculation of: Service queues = # of SAPS * 3 Network queues = # of ports * 16 The assumption being made here is that the number of queues per policy is uniform across all the network nodes. This will probably not be true if there are mixed node types in the network. The 7750 will have different defaults compared to the 7705, so a more accurate estimate would involve a calculation for each node type and the sum of these values taken. If metrics on service queues are being estimated, keep in mind that ingress queues and egress queues have different numbers of metrics on them, so that would need to be taken into account for any metric load calculations.

2 Subelements:

There are two broad categories of subelements available in the SAM pack.

   Sub-elements related to the Performance Metrics

For example, subelements related to the Performance metrics may depend on the some of the following types and number of interfaces and ports:

• MPLSInterface
• Channel
• Hw_Environment
• LAGInterface
• PhysicalPort
• PPP_Interface
• PPP_Protocol
• SAM_Shelf
• Others

   Subelements related to the Accounting metrics

For example, subelements related to the accounting metrics may depend on the some of the following type of services:

• Number of IES services (with a number of SAPs)
• Number of VPRN services (with a number of SAPs)
• Number of VLL Epipe services (with a number of SAPs)
• Number of VLL Apipe (with a number of SAPs)
• Number of VPLS services (with a number of SAPs)
• Number of Composite Service
• Other services

One should estimate the number of services related subelements based on the planned deployment.

3. Performance trends:

There are variations between SAM pack versions, and this will affect the performance, and therefore attempts to extrapolate the performance of one pack version based on data from another may have some error margin. Generally, each new version adds new features, which are usually an increase in the types of inventory and metrics that are collected. As a result, out of the box, newer pack versions will often require more CPU power than older ones. There may also be in some cases, changes which increase performance of the pack, too.

The following trends can be seen with help of some sample data but this may not be generic trends for all the systems:

- In most of the cases, Dataload UBA requires more processing power than CME, BLB and SAMIF - CME memory usage is generally higher than UBA, BLB, SAMIF. Irrespective of Metrics type (i.e. Performance/Accounting metrics), CME memory usage is proportional to the number of metrics processed. - CME normally reserves an initial amount of memory. The amount of allocated CME memory increases when number of processed metrics increases. Based on the combination of UBA processing power and associated CME memory, the maximum number of supported metrics by a subchannel can be provisioned. - UBA resource utilisation is normally different for Performance metrics and Accounting metrics. The resource utilisation for processing the Performance metrics is normally higher than the Accounting metrics. The UBA resource utilisation could be also be linked with the number of files/Network element records processed for a required set of metrics. - Generally the number of sub-elements associated with accounting metrics is a lot higher than performance metrics. - Generally the average of ‘RawIn per Subelement’ is higher for Performance metric than Accounting metrics. - The number of sub-elements per services related to the Accounting metrics is purely dependent on the service configuration and deployed policies. Based on this configuration and the information in Section 1&2, an estimation can be done for SAM Dataload budgetary sizing.

The maximum number of supported SEs per UBA/CME (sub-channel) will depend on various combinations e.g, CPU Speed, Hardware platform, services/metrics configuration etc.