|Cover of Top-Down Network Design, 1st edition, 1999|
Computer network design sure has changed in twenty years! Or has it? Although network technologies and applications have certainly changed, at least some of the classic principles of top-down design can still be applied today, whether your network is a set of virtual machines in the cloud or a set of Internet of Things devices.
Twenty years ago this month, I published Top-Down Network Design with Cisco Press. Macmillan Technical Publishing actually held the 1999 copyright. I mention this because the book is not specific to Cisco-based designs. As I recall, Cisco was just starting Cisco Press in the late 90s, working with Macmillan (which became Pearson) and Cisco documentation gurus such as Kim Lew and others. Some of the books are not specific to Cisco technology, though. Good architecture is vendor-neutral and timeless.
Cisco Press was a terrific partner in the development of all three editions of the book. They did a great job with editing, marketing, distribution, and beautiful covers. They found and worked well with some terrific technical reviewers, including, but not limited to, Dr. Alex Cannara, Dave Jansson, Hank Mauldin, and Dr. Peter Welcher. In addition, Brett Bartow, John Kane, and Mary Beth Ray at Cisco Press deserve much credit for making my book and countless other Cisco Press books such a big success.
Top-Down Network Design describes a top-down approach to network design that emphasizes the importance of analyzing business and technical goals before selecting hardware and software to build a network. The book presents a network design methodology that I developed based on my software development experience. "Don't start coding until you understand the problem you are trying to solve!" My professors and colleagues had drilled this axiom into me. I changed it to, "Don't start building a network until you have planned it out first."
|Photo by J. Kelly Brito on Unsplash|
- Analyze business goals
- Analyze technical goals
- Characterize the existing network
- Characterize network traffic
- Design a logical topology
- Design addressing and naming schemes
- Select bridging, switching, and routing protocols
- Develop plans for securing the network
- Develop plans for managing the network
- Test your design
- Optimize your design
- Document your design
Reading over the first edition (which I later updated to a 2nd and 3rd edition), I'm happy to see that a lot of the concepts remain important. I seem to have really enjoyed helping my readers learn network design terminology, such as scalability, availability, manageability, usability, adaptability, affordability, and other "abilities." All three editions also have good content about analyzing network performance goals and distinguishing requirements such as:
- Capacity (bandwidth): The data-carrying capability of a circuit or network, measured in bits per second (bps)
- Utilization: The percent of total available capacity in use
- Optimum utilization: Maximum average utilization before the network is considered saturated
- Throughput: Quantity of error-free data successfully transferred between nodes per unit of time, usually seconds
- Offered load: Sum of all the data all network nodes have ready to send at a particular time
- Accuracy: The amount of useful traffic that is correctly transmitted, relative to total traffic
- Efficiency: How much effort is required to produce a certain amount of data throughput
- Delay (latency): Time between a frame being ready for transmission from a node and delivery of the frame elsewhere in the network
- Delay variation: The amount of time average delay varies
- Response time: The amount of time between a request for some network service and a response to the request
Where the book hasn't aged well is when it recommends or discusses specific technologies. The first edition actually discusses ATM, Novell NetWare, and AppleTalk. :-)
The book also probably has too much focus on carefully provisioning the right amount of bandwidth and using the bandwidth sparingly to avoid performance problems. These days, with the exception of wireless networks, we don't seem to worry about bandwidth. Perhaps we should, but with wired networks especially, it's very hard to use all the bandwidth we have, and with 802.11ac and 5G networks coming online, even wireless networks will often have sufficient bandwidth.
Also, with current network planning, we don't tend to characterize network traffic as much as we used to. Perhaps we should pay more attention to the distinctions between network traffic that requires low delay and jitter, for example, and network traffic that demands huge amounts of bandwidth. On the other hand, maybe throwing lots of bandwidth at the problem and spreading it across the globe results in less worry about network traffic characteristics.
Despite these caveats, the book has aged pretty well. The importance of planning is still as relevant as it was in 1999. Yes, we live in an agile world today where there's less focus on requirements analysis. Also, it's possible to simply start building a virtual network and to tinker with it till it works. Nonetheless, I think even virtual networks can benefit from less tinkering and more design. Don't forget the concepts in Top-Down Network Design. They can still help.
And if you've been wondering, here's what I looked like in approximately 1999. I'm the one in red. I'm with my sister, nieces, and husband. I couldn't find any pictures where I'm not with family. That's a good thing.