| < Day Day Up > |
|
For the sake of discussion in these examples, let’s assume that you know the characteristics of your network. This is a process of gathering data that is unique to your situation and has been measured by your team.
Let’s say that we want to engineer traffic for an OC-12 pipe, which is 622Mbps (see Figure 5.5). You want to have rapid recovery, so you use two pipes and load balance each pipe for 45 percent of capacity. In this case, if one OC-12 pipe fails (see Figure 5.6), your rapid recovery protocol can move traffic from your under-provisioned pipe to the other, and the total utilization is still under-provisioned.
Figure 5.5: Sample Network Diagram: Example 1
Figure 5.6: Sample Network Failure
Our traffic trends for peak busy hour show that we have the calculations shown in Figure 5.7.
Figure 5.7: Traffic Trends
We can work these numbers just like we would in a checkbook. After we do the math, if we still have money (bits) remaining, we are okay. If our checkbook comes out in the red, we must go back and budget our spending.
Table 5.1 helps to simplify the bandwidth budgeting process as well as to demonstrate some of the calculations involved in traffic engineering.
Traffic Totals/Demands | Quantity | Totals and Subtotals | Notes |
---|---|---|---|
Number of voice calls | 200 | ||
b/s/call | 100,000 | ||
Total voice streams in b/s | 20,000,000 | 20,000,000 | |
Number of video calls | 3 | ||
b/s/call | 500,000 | ||
Total video streams in b/s | 1,500,000 | 1,500,000 | |
Committed information rate | 250,000,000 | 250,000,000 | |
Other traffic | 0 | 0 | |
Total traffic demand | 271,500,000 | BW needed | |
Usable Bandwidth | |||
Circuit BW OC-12 | 622,000,000 | ||
Percentage used | 45% | Over-provisioned | |
Total BW for over-provisioned | 279,900,000 | 279,900,000 | BW on hand |
271,500,000 | BW needed | ||
Remaining BW | 8,400,000 | Good BW remaining |
Now that we understand the basic concept, let’s play with the figures a bit to achieve the outcomes that we need.
First, let’s say that we are going to use “silence suppression” on the voice calls. The use of silence suppression means that we will not use bandwidth if we are not transmitting. You can see the effects of silence suppression in Figure 5.8, which is a simple 10 count over 10 seconds.
Figure 5.8: Voice with Silence Suppression
The lows in the graph indicate the periods in which no data is being sent. Silence suppression can be used if the calls have the characteristics of phone calls (see Figure 5.8). However, if the calls are streaming voice, like a radio show, or piped-in music (as shown in Figure 5.9), notice that the baseline is higher and that more overall bandwidth is used.
Figure 5.9: Vocal Jazz Music (The Andrews Sisters Singing “Boogie-Woogie Bugle Boy”)
We can reduce the number of bits required for voice calls down to100K using silence suppression. Notice in Table 5.2 that we have more remaining bandwidth with which to work.
Traffic Totals/Demands | Quantity | Totals and Subtotals | Notes |
---|---|---|---|
Number of voice calls | 100 | ||
b/s/call | 100,000 | ||
Total voice streams in b/s | 10,000,000 | 10,000,000 | |
Number of video calls | 3 | ||
b/s/call | 500,000 | ||
Total video streams in b/s | 1,500,000 | 1,500,000 | |
Committed information rate | 250,000,000 | 250,000,000 | |
Other traffic | 0 | 0 | |
Total traffic demand | 261,500,000 | BW needed | |
Usable Bandwidth | |||
Circuit BW OC-12 | 622,000,000 | ||
Percentage used | 45% | Over-provisioned | |
Total BW for over-provisioned | 279,900,000 | 279,900,000 | BW on hand |
261,500,000 | BW needed | ||
Remaining BW | 18,400,000 | Good BW remaining |
Many carriers choose over-provisioning because they cannot afford the cost of designing a highway system for rush-hour traffic. Instead, they design a network for “normal” traffic. Over-provisioning a network is similar to the airlines overbooking flights. There is a statistical point at which possible loss of customers costs less than running planes at half capacity.
Let’s use the same example as we used earlier, with no switchable path and an OC-12 pipe that is able to tolerate some congestion during rush hour. We choose not to design the tunnel for peak busy-hour traffic; instead, we design it for 10 percent over-provisioning, or 110 percent of the available bandwidth.
On paper, this looks great because we can still handle several hundred more calls, and it is an accountant’s dream. Trouble, however, lies in wait. What happens if all the traffic arrives at the same time? In addition, how can we handle a switchover to another link? If this link is provisioned at 110 percent and the spare link is provisioned at 110 percent, one link will have a 220 percent workload during a single link failure and is more than apt to fail itself (see Table 5.3).
Traffic Totals/Demands | Quantity | Totals and Subtotals | Notes |
---|---|---|---|
Number of voice calls | 100 | ||
b/s/call | 100,000 | ||
Total voice streams in b/s | 10,000,000 | 10,000,000 | |
Number of video calls | 3 | ||
b/s/call | 500,000 | ||
Total video streams in b/s | 1,500,000 | 1,500,000 | |
Committed information rate | 250,000,000 | 250,000,000 | |
Other traffic | 0 | 0 | |
Total traffic demand | 261,500,000 | BW needed | |
Usable Bandwidth | |||
Circuit BW OC-12 | 622,000,000 | ||
Percentage used | 110% | Over-provisioned | |
Total BW for over-provisioned | 684,200,000 | 684,200,000 | BW on hand |
261,500,000 | BW needed | ||
Remaining BW | 422,700,000 | Good BW remaining |
Checkpoint | Answer the following true/false questions.
Answers: 1. True; 2. true; 3. false; 4. true; 5. true. |
| < Day Day Up > |
|