| Generally speaking ... to answer the question you'd | | | | treated with the correct priority based on |
| likely need to at least consider the business oriented, | | | | organizational need and priority. |
| technology parameters, and application specific | | | | If starting with applications, be sure to include anything |
| components requiring emphasis for the specific | | | | needed during the future 12 months (i.e. don't use |
| location(s) involved. | | | | historical demand for anything but a starting point). |
| A good answer to the question requires a detailed | | | | Needs beyond the 12 month period should be |
| understanding of the kinds of traffic the proposed | | | | considered to ensure the equipment and services |
| network is intended to handle. For example, streaming | | | | choosen will allow future growth. |
| video often requires high net bandwidth, but can use | | | | To start the process, meeting and discussing needs |
| packet aggregation and may be able to accept the | | | | and expectation with all key stakeholders is critical. This |
| latency inherent in e.g. an asymmetrical satellite | | | | includes IT, Finance, Sales, Marketing and Operations. |
| downlink. | | | | Anyone left out of this early discovery will likely create |
| In contrast, heavy multi-user VOIP might require | | | | gaps in the analysis that will come back to bite you |
| symmetrical up and downlinks, in which per-user | | | | later. |
| latency and the ability to handle many | | | | Bandwidth should also be segmented on need across |
| packets-per-second are much more important to | | | | the WAN, internal backbone, distribution network and |
| performance than net bandwidth. | | | | access network. Also method of delivery is important |
| Or, you may have hybrid requirements in which part or | | | | (i.e. DSL, T1, DS3, OCx, Optical, copper, Wi-Fi). Breaking |
| all of the network has to handle multiple data types | | | | things out this way will also ensure you have the right |
| and amounts with varying latency requirements. | | | | technology, enough redundancy, and user flexibility to |
| Once you understand the various network use | | | | have a tight fit with the end user and organizational |
| scenarios, planning becomes largely a matter of | | | | needs and expectations. |
| understanding peak vs average use per node, as well | | | | Equipment decisions flow from the earlier points and |
| as local vs pass-through data flows per node, ..... and | | | | should be defined towards the end of the process. |
| designing node capacity, queuing, bandwidth shaping | | | | Adjustments to the plan can be made at this stage |
| and limiting, and overall system requirements | | | | dependent on equipment capability - assumptions |
| accordingly. | | | | about equipment capability early on are a sure way to |
| Yes .... every company is different hence every | | | | have your plan driven by the equipment vendors (not a |
| network is unique. | | | | good thing). For instance, a vendor I know of has some |
| Sometimes, network requirements are driven by the | | | | very powerful systems for using wireless at the |
| applications, sometimes it is the other way around - | | | | primary access network ..... but many customer's made |
| applications are engineered to cope with certain | | | | assumptions early on that this was not possible - the |
| network realities. | | | | results being they over spend on wired technology. |
| Here is a good example: | | | | Once a draft plan is created, this should be presented |
| If a company has operations all across the world, | | | | back to the same set of stakeholders you met early |
| round-trip delay will be at the top of my concerns. | | | | on to ensure you've captured everything and have |
| Since realistically the delay between US and China or | | | | one last chance to integrate any changes required |
| India will be in the range of 300ms round-trip (or more), | | | | since the 1st discussion. Also, this gives you a chance |
| the applications will have to be designed with this in | | | | to explain options to the plan and gain buy in to the |
| mind. For example interactivity across-the-pond is not | | | | preferred options. |
| going to work very well no matter how much | | | | A common practice is to "find the bottleneck". In |
| bandwidth you throw at it. | | | | designing a bandwidth solution, you can only be as fast |
| To over simplify ..... some common factors will be | | | | as the slowest component. |
| number of users, criticality of time sensitive information, | | | | In practice it is best to map out two things: |
| geographical spread/locations, types of applications, | | | | 1. Current data rate and maximum capacity |
| data only or data and voice. You also have to think | | | | 2. Desired data rate |
| about whether you are incorporating hubs or data | | | | From there you can look at the whole chain and make |
| centres. Last but certainly not least at present is what | | | | decisions around what you will do. |
| budget do you have to work with because knowing | | | | Do I need to change network service providers? How |
| that might simplify some of your decision making. | | | | much throughput do I need to design in? There is no |
| The two countervening issues are cost and | | | | sense building a ferrari if you only have local driving at |
| organizational applications demand/expectations. | | | | low speeds. |
| Depending on an organizations priorities, start with one | | | | But to the other extreme, there is no use designing a |
| of the two issues above (i.e. if they're driven by cost | | | | small 4 cylinder engine to drive local streets if changing |
| start there since any application driven model will be | | | | over to the expressway could get you there faster. |
| unappreciated or ignored). | | | | The bottom line is that you need to look at your |
| If starting with cost - you'll likely be building a network | | | | resources from end to end in order to determine the |
| model that forces application needs through priority | | | | best network solution. |
| based networking filters to ensure applications are | | | | |