Bandwidth and Storage Guide

Overview

You will learn about the following:

Bandwidth Utilization

Storage

Audience

This guide is intended for system administrators or engineers who have system administration access and technical knowledge along with a familiarity with deploying the Nectar Foundation.

Supported Software Versions

• Nectar v8.7

Bandwidth Utilization

This section provides the following:

RTCP Bandwidth

SNMP Poller Bandwidth

Client Session Bandwidth to Nectar RIG

RIG Session Bandwidth to EIP/CIP

RIG Session Bandwidth to Avaya Communication Manager (ACM)

RTCP Bandwidth

Nectar conservatively expects 64bps of RTCP data per RTCP stream. There are at least two streams per conversation (IP Phone to MedPro, MedPro to IP Phone). As a result, there are 128bps per call leg. There are potentially additional legs (MedPro to another MedPro or Media Gateway) that will increase this by 128bps each.

The architecture of your network (trunk locations, calling patterns, routing, shuffling, Avaya Network Regions, etc.) ultimately determines how many RTCP legs (and streams) there are per conversation. There may and will be a different amount for different calls.

Allowing for up to three legs (six streams) for a single conversation, estimate a range from 128Kbps up to 384Kbps of bandwidth per 1000 conversations (live VoIP calls) between a Nectar RIG and the respective location where the RTCP streams originate. This traffic can be treated as best effort within any QoS mechanisms in place during network congestion.

RTCP Bandwidth Calculator

Conservatively using an equivalent mix of 1, 2, and 3 call legs (2, 4, and 6 streams) per call, we get an average of 256bps per call. As a result, the calculation is:

Number of Concurrent Calls * 256bps = Expected RTCP Bandwidth (bps)

Guide: 1000 concurrent calls ~= 256Kbps

SNMP Poller Bandwidth

A Poller is an active query against a device, for instance, CPU utilization. All deployments of Nectar UCMP differ, and the number of Pollers depends on the type and quantity of devices being monitored. If you were tracking the following for a server, it would count as five Pollers:

• 
  
  • CPU utilization
  • RAM utilization
  • Disk utilization
  • NIC up/down status
  • NIC utilization

For reference, the Avaya Communication Manager VKM generates roughly 100 Pollers monitoring a small system (two locations with three gateways). Naturally, this value varies, depending on the composition of the system. Each Media Gateway generates 10-20 Pollers. That is the main item that drives this number higher.

Though poll sizes vary, we will conservatively use a 1500 Byte packet per request and 1500 Bytes per response, for a total of 3KB per poll. Converting from Bytes to bits gives 24Kb per poll. Pollers default to run every 60 seconds, therefore, 1,000 Pollers generate roughly 17 polls per second. Seventeen polls times 24Kb equates to 408Kbps bandwidth utilization.

2.2.1SNMP Poller Bandwidth

The calculation is:

Number of Pollers / 60s * 24Kbps = Expected SNMP Poller Bandwidth (bps)

Guide: 1000 Pollers ~= 408Kbps

Client Session Bandwidth to Nectar RIG

Nectar Client sessions are lightweight and should have minimal to no bandwidth impact, if the RIG is accessed on the LAN. If connections occur across a WAN, then the following figures should be considered.

Each Client session that connects to a RIG creates roughly an 8kbps stream. However, this may increase, depending on your activity. For example, if a user initiates a Remote Desktop Connection (RDC) via the RIG, this increases this stream by the RDP session bandwidth, roughly 32-64kbps. An Avaya SAT session consumes roughly 24-32Kbps when active. If no commands are being executed, only TCP keep-alives are present (nominal).

Users will not use Connection Broker/Socket Tunnel access at all times. However, planning on a 56kbps average per user should allow some leeway in WAN utilization estimates and should provide an adequate level of headroom.

RIG Session Bandwidth to EIP/CIP

This is analogous to Section 2.3 above.

RIG Session Bandwidth to Avaya Communication Manager (ACM)

The RIG maintains anywhere from one to six active logins to the ACM. These consume anywhere from 8-12Kbps each. In addition, there will be a single session (8-12Kbps) to each survivable processor (ESS or LSP). While this is nominal per session, it can grow to be large depending on the number of survivable processors involved.

RIG Sessions to ACM Bandwidth

The calculation is:

(Number of ACM Logins + Number of ESS/LSP) * 12Kbps = Expected Bandwidth (Kbps)