Two of the IP backbone design methods include a best-effort backbone with overprovisioning and a DiffServ backbone.
The more traditional approach is to use a best-effort backbone with overprovisioning. However, to meet the application needs of today (VoIP, videoconferencing, e-learning, and so on), deploying a DiffServ backbone and offering different SLAs for the different traffic classes can greatly reduce the cost and improve the delay, jitter, and packet loss and meet network QoS requirements.
With overprovisioning, a service provider typically uses an overprovisioning factor of 2. For example, if the aggregate traffic load on the network is 10 Gbps, the network is provisioned for 20 Gbps of maximum capacity. Some of the problems with a best-effort backbone with overprovisioning include:
■ If the capacity planning is not accurate and congestion occurs, because the traffic types are not differentiated, the VoIP packets will not be treated with higher priority than other data traffic, resulting in suboptimal treatment for VoIP packets.
■ Overprovisioning for all traffic is very expensive to implement.
■ During capacity planning, all of the failure scenarios might not be analyzed. Unplanned failures can cause unexpected congestion in the network. A link or node failure leading to traffic re-routing can take up all the excess capacity.
■ The network can experience unexpected traffic demands, which can cause congestions in the network.
■ Denial of service attacks on one service will affect all other services.
Using DiffServ, the traffic is isolated into different classes, and each traffic class is provisioned with a different traffic policy based on the QoS requirements of the traffic class. This will reduce the cost and provide better overall latency, delay, and jitter.
Was this article helpful?