In order to increase revenues, service providers are offering more and more services on the same infrastructure to their subscribers. While a few years back data services were confined to providing a vanilla broadband service to residential customers and an L2 or L3 VPN service to Enterprise customers, this is no longer enough to survive in the highly competitive telecom space. Service providers are expected to provide IPTV, VOIP, Video Calling, Bandwidth on Demand and Gaming Services. Similarly corporate customers expect Video Conferencing and SLA guarantees from the service providers.
While the demand for these value added services is increasing, itís becoming more and more difficult for service providers to ensure these SLAs and satisfactory operation of various applications. This is because firstly all these services are using a common shared infrastructure, and secondly, each service has a different set of requirements in terms of bandwidth, latency, jitter etc.
These concerns are addressed through the Hierarchical QoS Engine built into Tejas packet platforms.
Traditional QoS engines consist of only one level of Scheduler. The traffic is classified based on some pre-configured rules into multiple classes. This classification can be based on Ethernet, IP or TCP header values. The classified traffic is put into separate queues. The Scheduling Engine then picks up the traffic from these queues according to a pre-configured algorithm (eg Strict Priority or Weighted Fair Queueing) and transmits it onto the Egress ports. The traffic passing through each of these queues is measured and SLAs provided only at the level of this class of service.
The limitation of this approach is that while it can classify VOIP traffic coming from all the customers as Class of Service #1, and provide a guaranteed throughput to the total VOIP traffic, it cannot sub-classify between VOIP traffic from 2 separate customers.
A hierarchical QoS engine solves these problems by supporting multiple levels of scheduling. The first level scheduler feeds traffic to the next level and that feed to the third level. With each of these schedulers, a separate classification and scheduling algorithm can be applied at each level. The first level scheduler can classify traffic into flows (for eg, coming from a specific host or a group of hosts). The second level can classify them based on services (for eg, whether itís VOIP traffic or normal Internet traffic), and Third level scheduler can classify it based on Trunks (ie, a trunk going from location A to B and another going from A to C but sharing the same Egress port).
With an HqoS engine the service provider gets a lot of flexibility in managing his bandwidth. The first level scheduler would classify traffic into flows based on the service type (VOIP, Internet etc) coming from a particular customer (source address). The SLAs applied here would apply to the individual services for that customer. The second level scheduler can classify based on customers and apply CIR(Committed Information Rate) & EIR (Excess Information Rate) for that customer. The third level scheduler can apply a policy for a particular trunk (based on destination address). Thus all traffic going from location A to B would get a particular bandwidth guarantee within the shared Egress port.