Networking Objectives

{\rtf1\ansi\ansicpg1252\deff0\deflang16393{\fonttbl{\f0\froman\fcharset0 TimesNewRoman;}{\f1\fswiss\fcharset0 Arial,Bold;}{\f2\fnil\fcharset0 Calibri;}}
{\colortbl ;\red0\green0\blue0;\red53\green66\blue120;}
{\*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\cf1\lang9\f0\fs21 The American architect Louis Henry Sullivan described his design philosophy with the simple statement\par
"form follows function." By this credo he meant that a structure's physical layout and design should reflect\par
as precisely as possible how this structure will be used. Every door and window is where it is for a reason.\par
He was talking about building skyscrapers, but this philosophy is perhaps even more useful for network\par
design. Where building designs often include purely esthetic features to make them more beautiful to look\par
at, every element of a good network design should serve some well-defined purpose. There are no\par
gargoyles or frescos in a well-designed network.\par
The location and configuration of every piece of equipment and every protocol must be carefully\par
optimized to create a network that fulfills the ultimate purposes for which it was designed. Any sense of\par
esthetics in network design comes from its simplicity and reliability. The network is most beautiful when it\par
is invisible to the end user.\par
So the task of designing a network begins with a thorough study of the required functions. And the form\par
will follow from these business requirements.\par
\par
\cf2\b\f1\fs30 1.1 Business Requirements\par
\cf1\b0\f0\fs21\par
This is the single most important question to answer when starting a network design: why do you want to\par
build a network? It sounds a little silly, but frequently people seem confused about this point. Often they\par
start building a network for some completely valid and useful reason and then get bogged down in\par
technical details that have little or nothing to do with the real objectives. It is important to always keep\par
these real objectives in mind throughout the process of designing, implementing, and operating a network.\par
Too often people build networks based on technological, rather than business, considerations. Even if the\par
resulting network fulfills business requirements, it will usually be much more expensive to implement than\par
is necessary.\par
If you are building a network for somebody else, then they must have some reason why they want this\par
done. Make sure you understand what the real reasons are. Too often user specifications are made in terms\par
of technology. Technology has very little to do with business requirements. They may say that they need a\par
Frame Relay WAN, or that they need switched 100Mbps Ethernet to every desk. You wanted them to tell\par
you why they needed these things. They told you they needed a solution, but they didn't tell you what\par
problem you were solving.\par
It's true that they may have the best solution, but even that is hard to know without understanding the\par
problem. I will call these underlying reasons for building the network "business requirements." But I want\par
to use a very loose definition for the word "business." There are many reasons for building a network, and\par
only some of them have anything to do with business in the narrow sense of the word. Networks can be\par
built for academic reasons, or research, or for government. There are networks in arts organizations and\par
charities. Some networks have been built to allow a group of friends to play computer games. And there\par
are networks that were built just because the builders wanted to try out some cool new technology, but this\par
can probably be included in the education category.\par
What's important is that there is always a good reason to justify spending the money. And once the money\par
is spent, it's important to make sure that the result actually satisfies those requirements. Networks cost\par
money to build, and large networks cost large amounts of money.\par
\fs24\par
\cf2\b\f1\fs26 1.1.1 Money\par
\par
\cf1\b0\f0\fs21 So the first step in any network design is always to sit down and list the requirements. If one of the\par
requirements is to save money by allowing people to do some task faster and more efficiently, then it is\par
critical to understand how much money is saved.\par
Money is one of the most important design constraints on any network. Money forms the upper limit to\par
what can be accomplished, balancing against the "as fast as possible" requirement pushing up from below.\par
How much money do they expect the network to save them? How much money do they expect it will make\par
for them? If you spend more money building this network than it's going to save (or make) for the\par
organization, then it has failed to meet this critical business objective. Perhaps neither of these questions is\par
directly relevant. But in that case, somebody is still paying the bill, so how much money are they willing to\par
spend?\par
\cf2\b\f1\fs26 1.1.2 Geography\par
\cf1\b0\f0\fs21 Geography is the second major requirement to understand. Where are the users? Where are the services\par
they want to access? How are the users organized geographically? By geography I mean physical location\par
on whatever scale is relevant. This book's primary focus is on Local Area Network (LAN) design, so I will\par
generally assume that most of the users are in the same building or in connected building complexes. But if\par
there are remote users, then this must be identified at the start as well. This could quite easily spawn a\par
second project to build a Wide Area Network (WAN), a remote-access solution, or perhaps a Metropolitan\par
Area Network (MAN). However, these sorts of designs are beyond the scope of this book.\par
One of the keys to understanding the local area geography is establishing how the users are grouped. Do\par
people in the same area all work with the same resources? Do they need access to the same servers? Are\par
the users of some resources scattered throughout the building? The answers to these questions will help to\par
define the Virtual LAN (VLAN) architecture. If everybody in each area is part of a self-contained work\par
group, then the network could be built with only enough bandwidth between groups to support whatever\par
small amounts of interaction they have. But, at the opposite extreme, there are organizations in which all\par
communication is to a centralized group of resources with little or no communication within a user area. Of\par
course, in most real organizations, there is most likely a mixture of these extremes with some common\par
resources, some local resources, and some group-to-group traffic.\par
\cf2\b\f1\fs26 1.1.3 Installed Base\par
\cf1\b0\f0\fs21 The next major business requirement to determine is the installed base. What technology exists today?\par
Why does it need to be changed? How much of the existing infrastructure must remain?\par
It would be extremely unusual to find a completely new organization that is very large, has no existing\par
technology today, and needs it tomorrow. Even if you did find one, chances are that the problem of\par
implementing this new technology has been broken down among various groups. So the new network\par
design will need to fit in with whatever the other groups need for their servers and applications.\par
Installed base can cause several different types of constraints. There are geographical constraints, such as\par
the location and accessibility of the computer rooms and LAN rooms. There may be existing legacy\par
network technology that has to be supported. Or it may be too difficult, inconvenient, or expensive to\par
replace the existing cable plant or other existing services.\par
Constraints from an existing installed base of equipment can be among the most difficult and frustrating\par
parts of a network design, so it is critical to establish them as thoroughly and as early as possible.\par
\fs24\par
\cf2\b\f1\fs26 1.1.4 Bandwidth\par
\cf1\b0\f0\fs21 Now that you understand what you're connecting and to where, you need to figure out how much traffic to\par
expect. This will give the bandwidth requirements. Unfortunately, this often winds up being pure\par
guesswork. But if you can establish that there are 50 users in the accounting department who each use an\par
average of 10kbps in their connections to the mainframe throughout the day, plus one big file transfer at\par
5:00 P.M., then you have some very useful information. If you know further that this file transfer is 5\par
gigabytes and it has to be completed by 5:30, then you have another excellent constraint.\par
The idea is to get as much information as possible about all of the major traffic patterns and how much\par
volume they involve. What are the expected average rates at the peak periods of the day (which is usually\par
the start and end of the day for most 9-5 type operations)? Are there standard file transfers? If so, how big\par
are they, and how quickly must they complete? Try to get this sort of information for each geographical\par
area because it will tell you not only how to size the trunks, but also how to interconnect the areas most\par
effectively.\par
In the end it is a good idea to allow for a large amount of growth. Only once have I seen a network where\par
the customer insisted that it would get smaller over time. And even that one got larger before it got smaller.\par
Always assume growth. If possible, try to obtain business-related growth projections. There may be plans\par
to expand a particular department and eliminate another. Knowing this ahead of time will allow the\par
designer to make important money-saving decisions.\par
\cf2\b\f1\fs26 1.1.5 Security\par
\cf1\b0\f0\fs21 Last among the top-level business requirements is security. What are the security requirements? This is\par
even important in networks that are not connected to anything else, like the Internet or other shared\par
networks. For example, in many organizations the servers in the Payroll Department are considered\par
sensitive, and access is restricted. In investment banks, there may be regulations that require the trading\par
groups to be separate from corporate financing groups. The regulatory organizations tend to get annoyed\par
when people make money on stock markets using secret insider information.\par
The relationship between security and geography requirements may make it necessary to implement\par
special encryption or firewall measures, so these have to be understood before a single piece of equipment\par
is ordered.\par
\cf2\b\f1\fs26 1.1.6 Philosophical and Policy Requirements\par
\cf1\b0\f0\fs21 Besides the business requirements, there could be philosophical requirements. There may be a corporate\par
philosophy that dictates that all servers must be in a central computer room. Not all organizations require\par
this, but many do. It makes server maintenance and backups much easier if this is the case. But it also\par
dictates that the network must be able to carry all of the traffic to and from remote user areas.\par
There may be a corporate philosophy that, to facilitate moves, adds, and changes, any PC can be picked up\par
and moved anywhere else and not require reconfiguration. Some organizations insist that all user files be\par
stored on a file server so that they can be backed up. Make sure that you have a complete list of all such\par
philosophical requirements, as well as the business requirements, before starting.\par
\cf2\b\f1\fs30 1.2 OSI Protocol Stack Model\par
\cf1\b0\f0\fs21 No book on networking would be complete without discussing the Open System Interconnection (OSI)\par
model. This book is more interested in the lower layers of the protocol stack. One of the central goals of\par
network design is to build reliable networks for applications to use. So a good design starts at the bottom of\par
the stack, letting the upper layers ride peacefully on a stable architecture. Software people take a\par
completely different view of the network. They tend to be most concerned about the upper layers, from\par
\fs24\par
\fs21 Layer 7 down to about Layer 4 or 5. Network designers are most concerned with Layers 1 through 4 or 5.\par
Software people don't care much about cabling, as long as it doesn't lose their data. Network designers\par
don't care much about the data segment of a packet, as long as the packet meets the standard specifications.\par
This fact alone explains much of my bias in focusing on the lower parts of the stack. There are excellent\par
books on network programming that talk in detail about the upper layers of the stack. That is largely\par
\pard\sa200\sl276\slmult1 beyond the scope of this book, however.\cf0\f2\fs22\par
}