This chapter serves as an introduction to the rest of the book by describing top-down network design. The
first section explains how to use a systematic, top-down process when designing
computer networks for your customers. Depending on your job, your customers
might be other departments within your company, those to whom you are trying
to sell products, or clients of your consulting business.
After describing the methodology, this chapter focuses on the first
step in top-down network design: analyzing your customer's business goals.
Business goals include the capability to run network applications to meet
corporate business objectives, and the need to work within business constraints,
such as budgets, limited networking personnel, and tight timeframes.
This chapter also covers what some people call the eighth layer of the
Open Systems Interconnection (OSI) reference model: workplace politics. To
ensure the success of your network design project, you should gain an understanding
of any corporate politics and policies at your customer's site that could
affect your project.
The chapter concludes with a checklist to help you determine if you
have addressed the business issues in a network design project.
According to Albert Einstein:
The world we've made as a result of the level of thinking
we have done thus far creates problems that we cannot solve at the same level
at which we created them.
To paraphrase Einstein, network engineers and users have
the ability to create network design problems that cannot be solved at the
same level at which they were created. This predicament can result in networks
that are hard to understand and troubleshoot. It can also result in networks
that don't perform as well as expected, don't scale as the need for growth
arises (as it almost always does), and don't match a customer's requirements.
A solution to this problem is to use a systematic, top-down network design
methodology that focuses on a customer's requirements, constraints, and goals.
Many network design tools and methodologies in use today resemble the “connect-the-dots”
game that some of us played as children. These tools let you place internetworking
devices on a palette and connect them with LAN or WAN media. The problem with
this methodology is that it skips the steps of analyzing a customer's requirements
and selecting devices and media based on those requirements.
Good network design must recognize that a customer's requirements embody
many business and technical goals, including requirements for availability,
scalability, affordability, security, and manageability. Many customers also
want to specify a required level of network performance, often called aservice level.
Difficult network design choices and tradeoffs must be made when designing
the logical network before any physical devices or media are selected.
When a customer expects a quick response to a network design request,
a bottom-up (connect-the-dots) network design methodology can be used, if
the customer's applications and goals are well known. However, network designers
often think they understand a customer's applications and requirements only
to discover, after a network is installed, that they did not capture the customer's
most important needs. Unexpected scalability and performance problems appear
as the number of network users increases. These problems can be avoided if
the network designer uses top-down methods that perform requirements analysis
before technology selection.
Top-down network design is a methodology for designing networks that
begins at the upper layers of the OSI reference model before moving to the lower layers. It focuses
on applications, sessions, and data transport before the selection of routers,
switches, and media that operate at the lower layers.
The top-down network design process includes exploring divisional and
group structures to find the people for whom the network will provide services
and from whom you should get valuable information to make the design succeed.
Top-down network design also is iterative. To avoid getting bogged down in details too quickly,
it is important to first get an overall view of a customer's requirements.
Later, more detail can be gathered on protocol behavior, scalability requirements,
technology preferences, and so on. Top-down network design recognizes that
the logical model and the physical design may change as more information is
Because top-down methodology is iterative, some topics are covered more
than once in this book. For example, this chapter discusses network applications.
Network applications are discussed again in Chapter 4, “Characterizing
Network Traffic,” which covers network traffic caused by application-
and protocol-usage patterns. A top-down approach lets a network designer get “the
big picture” first and then spiral downward into detailed technical
requirements and specifications.