You are a Staff Engineer, Networking, for MegaMoron Communications Inc., the world's premier communications design company. You have been tasked with the design of an advanced WAN backbone for RedNeckNet, a regional Internet Service Provider (ISP).
    A year has passed since RedNeckNet installed a MegaMoron designed IP backbone network, with Points of Presence (POP's) in Stillwater & Tulsa, Oklahoma; St. Louis, Missouri; Lubbock, Texas; Little Rock, Arkansas; and Wichita, Kansas. Some recent well publicized link failures have led to a loss of customers and emphasized the importance of a more survivable network. In an attempt to reverse sinking profits, the company president, Mr. H. Simsen, has decided to upgrade RedNeckNet's offerings to include integrated voice and data services. RedNeckNet has decided to continue to purchase leased line bandwidth from U.S. Sprawl and install either upgraded Routers or ATM switches capable of moving mixed traffic at their six POP's.
    Your goal is to design a least cost network that will meet average one-way end-to-end delay specifications for a mixed traffic environment. This will involve specifying the number and type of Leased Line connections to obtain from U.S. Sprawl, and specifying the type of ACME switching gear to purchase and install at the six RedNeckNet POP's.
    After some discussion, you have decided that designing the network for the peak half-hour will be a good compromise between price and performance.
    Investigation has revealed the following:

Propagation Delays between sites are as follows:
        Stillwater - Lubbock: 5.2 msec
        Stillwater - St. Louis: 6.6 msec
        Stillwater - Wichita: 1.7 msec
        Stillwater - Tulsa: 1.0 msec
        Stillwater - Little Rock: 4.6 msec
        St. Louis - Lubbock: 11.9 msec
        St. Louis - Wichita: 3.6 msec
        St. Louis - Tulsa: 6.3 msec
        St. Louis - Little Rock: 4.7 msec
        Lubbock - Wichita: 6.1 msec
        Lubbock - Tulsa: 6.1 msec
        Lubbock - Little Rock: 8.9 msec
        Tulsa - Little Rock: 3.6 msec
        Tulsa - Wichita: 2.2 msec
        Wichita - Little Rock: 5.6 msec

Router/Switch Options:
    RedNeckNet wishes to use one of the following four techniques for connectivity:
    (1) Current Internet : Map all traffic to IP packets. StatMux the composite traffic flow over current generation IP Routers, which are unable to differentiate between traffic types and will treat all the traffic identically.
    (2) QoS Enabled Internet : Map all traffic to IP packets. StatMux the composite traffic flow over more expensive Differential Services (DiffServ) routers, which are capable of prioritizing traffic and hence can give preferential treatment to voice.
    (3) ATM using CBR Voice and UBR Data: Map all traffic to ATM cells. With this option, the two types of traffic are essentially segregated by the ATM switch. The voice traffic will receive guaranteed bandwidth, TDM-like service, and will be capable of operating at a 100% load on the line. Data traffic is StatMuxed onto bandwidth not reserved for the CBR voice traffic.
    (4) ATM using VBR Voice and UBR Data: Map all traffic to ATM cells. With this option, the composite traffic flow is StatMuxed by switches which are capable of prioritizing the traffic.

Data Traffic:
    The average packet size of data that will travel this network during the peak half-hour is 591 bytes.
    *An average packet therefore contains 7 bytes of PPP, 20 bytes of IP, and 20 bytes of TCP overhead, leaving 544 bytes of application traffic (92.05% traffic).
    *If the packet is moved over ATM, an average of thirteen cells are required to move each packet (78.96% application traffic).

Voice Traffic:
    Fixed rate or variable rate 24.0 Kbps voice coders will be installed.  A fixed rate coder will output a steady 24.0 Kbps of application traffic. Since experiments have shown that a typical interactive voice conversation consists of 60% silence (this includes intervals between words, sentences, and natural pauses in the conversation) and 40% talk, variable rate coders will output an average of 9.60 Kbps of application traffic per speaker.
    * If you go with either Router option, variable rate coders will be used. Each packet will contain 66 msec of coder output (198 bytes).  VoIP packets will require 7 bytes of PPP, 20 bytes of IP, 8 bytes of User Datagram Protocol (UDP), and 12 bytes of RTP (Real Time Transport Protocol) overhead to move 198 bytes of application voice traffic (80.82% traffic).
    * If you go with the ATM CBR Voice option, a fixed rate coder will be used.  Five cells using AAL1 will be required to move 66 msec of coder output (198 bytes).  265 bytes will therefore be required in order to move 198 bytes of voice traffic (74.72% traffic).
    * If you go with the ATM VBR Voice option, a variable rate coder will be used.  Five cells will again be required to move 66 msec of coder output (74.72% traffic).

Average Packet Size & Traffic Ratios:
    IP Options: Offered application traffic loads are expected to be 83% data and 17% voice. Hence for each Mbps of offered application traffic there will be 830 Kbps of data and 170 Kbps of voice, on average. The data will require (830 Kbps)/[(544 app. bytes/packet)(8 bits/byte)] = 190.7 packets/second to move (per Mbps of offered application traffic), and the voice will require (170 Kbps)/[(198 app. bytes/packet)(8 bits/byte)] = 107.3 packets/second (per Mbps of offered application traffic). 36.01% of the packets will therefore be carrying voice and 63.99% will be carrying data. The average packet size is therefore seen to be .3601(245) + .6399(591) = 466.4 bytes = 3,731 bits.
    ATM using CBR voice and UBR data: Traffic is segregated by the ATM switch, and can be analyzed separately.  Voice traffic gets dedicated bandwidth (TDM).  The data traffic gets statistically multiplexed onto the remaining leased line bandwidth not reserved for the voice.  See Traffic Matrix info below for voice vs. data application bit rates.
    ATM using VBR voice and UBR data: Offered application traffic loads are expected to be 83% data and 17% voice. As just noted above, for each Mbps of offered application traffic there will be 830 Kbps of data and 170 Kbps of voice. The data will generate 190.7 packets/second to move, which will require 2,479 cells/second (per Mbps of offered application traffic). The voice will require (170 Kbps)/[(198 app. bytes/ 5 cells)(8 bits/byte)] = 536.6 cells/second (per Mbps of offered application traffic). 82.21% of the cells will therefore be carrying data and 17.79% will be carrying voice.

End-to-End Delays:
    Based on the delays OSI Layer 7 Applications and the end users will tolerate, the target average one-way end-to-end delivery delays during the peak half-hour must be less than or equal to 190 msec for data, and less than or equal to 32 msec for voice.  Different switching choices allow these values to be analyzed differently.
    (1) Current Internet : If this option is chosen, to meet the required average end-to-end delivery delays for voice, you will have to deliver all the traffic end-to-end within the voice requirement of 32 msec (on the average), as the system is unable to discriminate between the various types of traffic. I.E. use 32 msec as your target end-to-end delay specification.
    (2) QoS Enabled Internet : This system can prioritize the voice traffic, moving it in a more timely manner than the data. If this option is chosen, to meet the required average end-to-end delays for voice and data you will need to design the system to meet a weighted average end-to-end delay of .6399(190 msec) + .3601(32 msec) = 133.1 msec. I.E. use 133.1 msec as your target end-to-end delay specification.
    (3) ATM using CBR Voice and UBR Data: The voice traffic end-to-end delivery delay is essentially equal to the sum of any propagation delays. The StatMuxed data traffic must be delivered within the average data end-to-end delay of 190 msec, on average.
    (4) ATM using VBR Voice and UBR Data: This system can also give preferential treatment to the voice traffic. If this option is chosen, to meet the required average end-to-end delays for voice and data you will need to design the system to meet an average end-to-end delay of .8221(190 msec) + .1779(32 msec) = 161.9 msec. I.E. use 161.9 msec as your target end-to-end delay specification.

Self-Similarity:
    Lab tests show that the data traffic has an H parameter of 0.77 and that compressed variable rate voice traffic has an H parameter of 0.64.  Assume that combined traffic has an H parameter equal to the weighted average of the traffic mix moving over the link.
    *Internet Options: Use an H parameter of .6399(.77) + .3601(.64) = .7232
    *ATM using CBR Voice and UBR data: The CBR traffic is fixed rate and is not self-similar. The data traffic should use an H parameter of .77
    *ATM using VBR Voice and UBR data: Use an H parameter of .8221(.77) + .1779(.64) = .7469

Application Traffic Matrix:
    The following layer 7 application traffic matrix shows the expected peak rate average layer 7 application traffic flows (in Kbps) between sites for case (1), (2), and (4) above- which all rely on variable rate voice coders.
    Option (3), which is using fixed rate voice coders, must move slightly more traffic. To support an equivalent number of voice calls, the fixed rate coder must move 24.0 Kbps of application traffic for every 9.6 Kbps a variable rate coder moves, a ratio of 2.5 to 1. Again assuming a ratio of 83% data to 17% variable rate voice, the fixed rate coder must move 425 Kbps for every 170 Kbps of voice moved by variable rate coders. Couple this to the 830 Kbps of data traffic and the fixed rate system must move 1.255 Mbps of application traffic for every 1 Mbps of application traffic moved by options (1), (2), and (4). Hence multiply the values in the traffic matrix by 1.255 to get the amount of application traffic that must be moved by option (3).
    Important!! Note that the matrix below does not include OSI Layer 2-6 overhead.  You need to add this overhead in when calculating the trunk loads.
 

    Note that as RedNeckNet cannot control the size of the access lines customers purchase, end-to-end here is defined from the input switch of RedNeckNet's backbone to the output switch.
    Use the following equation to estimate the overall average end-to-end delivery delay over a single hop Leased Line connection:
                    Average Delay = Average Switch Delay + Propagation Delay,
with
                     Average Switch Delay = Ts*(Load) ^{(2H-1)/(2-2H)}
                                                                                  (1- Load) ^H/(1-H)

where Ts is the average service time, and the average switch delay is "Tr" in Stallings' text.
    For example, if the amount of traffic routed over a 64 Kbps Leased Line is 34 Kbps for Option (1), the average queuing delay a packet can expect to see is (Ts =3,731/64,000 = 58.30 msec, H Parameter = .7232)
                (.05830*.5312^0.8064)/.4688^2.613 = .03500/.1381 = 253.4 msec.
    * End-to-End average delays associated with multiple hop paths are found by summing the per-hop delays.

U.S. Sprawl Leased Line Costs:
    *Leased Lines from U.S. Sprawl are available in integer multiples of 10 Kbps.  Note that the 64 Kbps Leased Line used in the example above is not a legal value for this design problem.
    *Leased Line pricing is a function of distance and bandwidth. Use the following formula to calculate monthly costs for each Leased Line in place:
                Monthly Leased Line Costs = $185 + $70(1000*propagation delay)^.69 [(trunk line speed)/(1.80 Mbps)]^.25
    Example) An 100 Kbps Leased Line between St. Louis and Little Rock would cost
            $185 + $70(4.7)^.69[(100 Kbps)/(1800 Kbps)]^.25 = $185 + $70(2.909).4855 = $283.86 per month.These are full duplex lines, so you get the listed bandwidth in both directions. For example, a 100 Kbps leased line between St. Louis and Little Rock gives you 100 Kbps from St. Louis to Little Rock and 100 Kbps from Little Rock to St. Louis.

ACME Monthly Router & Switch Costs:
    Switching devices have costs based on internal bus speed required, memory for handling traffic in queues, and a fixed cost associated with power supplies, internal software, etc.
    *Option 1 requires an Acme Roto-Router at each POP. Monthly cost is $57 + $7.40(Sum of Leased Line Trunk Speeds in Mbps attached to the router).
    *Option 2 requires an Acme Roto-Router Supra at each POP. Monthly cost is $63 + $12.90(Sum of Leased Line Trunk Speeds in Mbps attached to the router).
    *Option 3 or 4 requires an Acme ATM Glitch-Switch at each POP. Monthly cost is $121 + $12.60(Sum of Leased Line Trunk Speeds in Mbps attached to the router). 

Reliability:
    All POP's must have a minimum of two-connectivity . I.E. all POP's must have a minimum of two trunk lines terminated at two different POP's. Additionally, the loss of a single trunk line should not isolate any portion of the network.  Two-connectivity will allow the system to operate in a degraded manner in the event of the loss of any single trunk.
    Instead of doing a complicated analysis to properly size the protect bandwidth, we will specify that for the purposes of this design problem, each link attached to a POP must have a minimum line speed of 130 Kbps.  It is up to the designer as to how traffic will be split over these and other connections.

Rules of Engagement:
    Double-check the math in this document.  Derived values, while believed to be correct, are not guaranteed to be correct.  Watch out for round-off errors.  You are advised to set up your spread sheet to calculate all values using spread sheet precision, and not 4 significant digits as has been done in this sample calculation.
    You may work in two person teams if you so desire.
    The low bid will be that design with the lowest monthly cost. The low bid designer(s) will receive 20 extra credit points. The 2nd lowest bid designer(s) will receive 15 points, and the 3rd lowest bid designer(s) will receive 10 points. All remaining designs with cost < the average class cost will receive 5 points extra credit. Only working bids will be considered for the above. The instructor reserves the right to modify these rules in the event of a tie, and to deduct points for crappy designs.
    Make your final report short and sweet. DO NOT GIVE ME A RUNNING COMMENTARY OF YOUR DERIVATION. I will dock you points if you do so. Your final report should be about three pages and include:
    (1) a WAN backbone network diagram showing links used, average traffic routed over these links in both directions, and trunk size.
    (2) a table, with 30 entries, showing how each Traffic Matrix entry is routed, and the expected average one-way end-to-end delays traffic will face moving over this route.
    (3) a list of costs (links & router/switch)
    (4) Sample calculations or your original spreadsheet file.
    Treat your project as if it were proprietary corporate information, i.e. do not disseminate your design in any manner to the competition. Doing so, and getting caught, will get anyone involved either "demoted" (i.e. a 0 for the project) or "fired" (i.e. an F for the course) depending on the seriousness of the leak.
 
<<<<<end>>>>>