1.2 An overview of the design process

1.2.1 The life cycle of a design

Network designs are predominantly living entities; they rarely stay the same. Even from inception to initial implementation, a design will often change—typically because of improvements in the quality of the data about the users, applications, and traffic flows, or design changes concerning the equipment selected and delivery technologies used. The point at which a network is installed often marks the start of a new phase of design rather than the end of the process. Consequently, it is useful to think of network design as a cyclic process, as illustrated in Figure 1.1.

click to expand
Figure 1.1: Network design process.

Before the design process can begin, a clear set of requirements should be established to capture what the organization and its users expect from the network and the services to be offered. The requirements should also clearly identify what the budget is and any other constraints that impact the design. The network design process then naturally follows a set sequence:

Information gathering
Planning
Implementation
Acceptance
Expansion and modification

Just as with any living organism, networks have a limited life span. Over time networks become increasingly unreliable, inflexible, and unable to cope with the pressures placed on them. Advances in network technology and increases in overall traffic levels render most technology obsolete within a few short years. The lifetime of a network may be extended with the aid of transplants to vital organs (upgrading routers, links, etc.); however, there generally comes a point where the network design itself requires a major overhaul, often resulting in total replacement (at which point the cycle starts over).

Some networks are destined to age much faster than others. Since networks are becoming increasingly inseparable from the organizations they are built for, a dynamic organization can put severe strain on a design, forcing radical changes over a much shorter time than a more stable organization. Massive growth, mergers, acquisitions, downsizing, or radical new ways of working can all result in a design that is obsolete or inadequate much faster than anticipated. Networks may even be dismantled and replaced for purely political reasons; it is not unusual for one company to take over another and have the absorbed network completely scrapped (this could simply be because the new decision maker does not like the installed technology, or it could be for strategic reasons). As companies expand and diverge, merge with other companies, and change their product focus and distribution methods, so too must the network.

1.2.2 Establishing requirements

To design and implement any new network or enhance an existing network, there must be two things: a requirement and a budget. At the early stages both elements may be quite loosely defined; without both in place and a willingness to expend effort in developing both, there is little point in proceeding. Large organizations that are very technology aware often have a rolling process of requirements and budgetary planning; to these organizations this comes as second nature and is fundamental to their business. Organizations that are less technically competent may have only the desire to improve matters and a willingness to spend money on it. Even so, in both cases the aims are the same—they just differ in the level of granularity. The job of the network designer is to cooperate with others in translating these wishes into a set of specific requirements, so that expenditure can be justified and appropriate technical choices can be made.

Engaging end users

Network engineering staff members often spend very little quality time with end users. The two groups may only interact when there is a serious problem, and then the engineer often feels outnumbered in a sea of angry users who are not the slightest bit interested in why the ISP router is down—they just expect service. On the other hand, users may have waited for hours to see any sign of progress, while business is being lost, commissions are being eroded, and angry customers are ringing in with complaints. Users often expect miracles; engineers often need them.

The design phase of any new network project is, however, a time for engaging user groups. It is important that the real users of the network and its services be involved from the start. Users are best placed to give feedback on how the applications should perform, what the current problem areas are, and what they like and don't like. Without user input you risk making fundamental errors with your design assumptions; by involving users throughout the transition you will achieve a much better buy-in (you really don't want to install a completely new infrastructure to find out that the users hate it). Having said this, user expectations need to be managed and prioritized. It is important that expectations are clearly defined, understood, and realistic. Before undertaking a design there should be a clear set of objectives visible to all interested parties.

Translating the requirements

Most reasonable-sized networks today are subject to a fairly formal process of specification. Requirements should ideally be specified from the top down. We start with the business objectives, and then refine these objectives by tighter specifications of what the business expects, what users expect, and any constraints that will be imposed on the designer. As part of the requirements specification process, it will become apparent that the requirement itself will be expressed in very different ways at different levels within the customer organization. At the board level, the requirement may simply be to increase adoption of client/server technology over the next three years to gain competitive advantage and achieve best practice.

While this may be the ultimate truth for a senior executive, it means very little to an engineer. The finance director may have his or her own requirement: to sustain a 35 percent return on investment while minimizing capital expenditure within this fiscal year.

We may have lost a few more engineers by this point. Joking aside, these are genuine requirements and must be translated and formulated into a set of specific requirements, aligned with the application strategy, user expansion plans, site geography, and available technology. The trick is to do all this without losing sight of the original business reasons for making the changes.

All too often the requirements come from the ground up. The network has been falling apart for several years, aided by an army of maintenance engineers performing artificial resuscitation on a daily basis, until new traffic levels and the loss of two key engineers finally bring the matter home. This is not a good start for a network design project, since the pressure is on to fix things quickly and there is unlikely to be a sensible budget in place (since clearly no planning has taken place). My advice here is to place a temporary bandage over the network while going through a full requirement and design process in parallel; otherwise, you could be throwing good money after bad.

Phasing the requirements

There is always a danger of overspecifying requirements too early, to the point where the requirements are simply unachievable. This is a particular problem if the authors of the requirements have very little knowledge of the networking technology. For example, a customer might express a requirement as follows: It is mandatory that all routers supplied should be supported and upgraded for the next ten years to incorporate new standards-based features and protocols.

Now, if you were investing serious money on this project, this might seem perfectly reasonable, but to most suppliers it appears impossible, or at least highly unattractive, for a number of reasons. Hence, requirements specification is generally a multistage process, starting with a fairly loose sense of direction and then progressively tightening the requirements as ideas firm up. It soon becomes apparent what is reasonable and what is achievable, as follows:

Request for Information—An initial Request for Information (RFI) document is often generated first. This document defines what the business is trying to achieve and may have some specific questions on the potential technologies available. The aim of this document is to solicit responses from all likely candidates so that an initial short list can be created of those best able to provide a complete solution and those interested in proceeding. Potential suppliers may include a mixture of equipment vendors, consortia, and systems integrators. It is unlikely at this stage that any serious design work will be achieved. General architectural models may be produced; an overview of product availability is provided, together with information on the supplier's stability and suitability for the project.
Request for Proposals—Once an initial short list of interested parties has been drawn up, the customer may issue a Request for Proposals (RFP) document to those suppliers. The recipients are expected to provide an initial outline design with budgetary costs and are expected to have addressed a number of questions posed by the customer. From the responses received a number of techniques are used to decide the final candidate list, including price, how many of the mandatory requirements are met, scalability, level of integration, and project management. The final short list is then drawn up based on the best responses, and those suppliers on the short list will be invited to present their proposals and to clarify any open issues with the customer directly.
Detailed Requirements Specification—Once a preferred partner and perhaps one other are selected, a more rigorous requirements specification, which will include a more expansive and more detailed list of questions, may be produced. In response to this document suppliers are expected to provide a comprehensive design, together with committed costs and draft equipment lists. There will be more interaction between suppliers and the customer, including product demonstrations closely aligned with project functionality. Beyond this phase the customer will have selected the final supplier.

Once a final supplier is chosen, this supplier will be invited to finalize design and to produce final equipment lists and finished schematics for every location. There may be some adjustment of pricing based on functionality. For large networks the supplier is normally responsible for the entire project plan, specifying exactly how and when various components will be installed and tested.

Note that this is far from an exact science. Different organizations will approach the process in various ways. Some may require a long, drawn-out process with many intermediate phases (typically, government organizations); others will feel sufficiently comfortable to issue a detailed requirements specification to a small number of suppliers at the outset, and then go straight to final design with a chosen supplier.

Designing the requirements

The process of developing and gauging responses to requirements specifications is typically done either within the customer organization or between the customer and some third party (e.g., a consultancy group or in some cases even a potential supplier). In practice only large, well-funded organizations (e.g., large financial institutions, large retail organizations, or national service providers) tend to employ their own full-time design experts, who are capable of fulfilling this role. For those organizations that do not have the necessary skills in-house but have financial resources, there are many highly skilled consultancy groups able to take on the task as a contract project. For organizations that have neither the skills nor sufficient budget for external consultancy, often the answer is to pick the safest vendor (usually the largest) and use the vendor's internal design skills as part of the sales offering. Vendors will often provide a cut-price design service in order to win the business. In the latter scenario the customer is really at the mercy of the supplier, and it usually pays to get at least some independent advice during the process as a final sanity check, especially if you are not dealing one of the major suppliers. If the network design is suboptimal, the customer will end up paying for it over and over again.

Requirements should be structured in such a way that associated topics are grouped by function (e.g., network management, routing, cabling, etc.). Individual requirements should be concise, unambiguous, and measurable. All requirements should have a reference number. Once you have a complete set of requirements, go through each item and prioritize, according to following criteria:

[M]—Mandatory: Must have. Failure to meet the requirement will eliminate the supplier from participating further.
[H]—Highly desirable: Important but not absolutely essential. Would be very advantageous.
[D]—Desirable: Not essential but would be nice to have.
[N]—Note: Not a requirement, but information that the supplier should take note of and acknowledge.

Take care to ensure that all mandatory requirements are actually achievable; otherwise, you run the risk that no one will meet the basic requirement. In the short-list stage it is likely that the responses to the highly desirable questions will strongly influence who the preferred supplier will be (assuming that the responders meet all mandatory requirements and all responses are within budget). From a vendor perspective it is often instructive to pay particular attention to any requirements that appear implementation specific; they often indicate that a competitor has been overly helpful in the drafting of the document or that there is strong product bias, either with the customer or with the authors of the document. Customers should be aware that vendors, if allowed access, may use this process to disable the competition (hopefully with greater subtlety).

Assessing the requirements

In practice, the assessment phase is often part scientific and part instinctive. Aside from cases where the customer is required by law to choose the cheapest solution that meets all mandatory requirements, the process is normally a combination of assessing the true costs of deployment, some form of weighted evaluation matrix, and the much less quantifiable element of whether the customer feels comfortable with the supplier. For obvious reasons we cannot deal with the latter here; comfortable means different things in different parts of the world.

The true cost of the network needs to be fully explored in detail. Items for consideration include support and maintenance, depreciation, commissioning costs, project management fees, hardware and software upgrade costs, circuit bandwidth charges, ongoing consultancy charges, whether current prices are fixed against future changes in the price list, and so on. It is important to remember that this is not a one-off purchase; significant network costs are due annually, so when comparing solutions this needs to be done for a period of at least three, and ideally five, years. What may initially be the cheapest solution may be far from it when calculated over the lifetime of the network. We dealt with cost modeling in detail in Chapter 4 of reference [1].

In assessing the specific requirements you should create a weighted matrix (e.g., using a spreadsheet) to clarify the responses and provide a quantitative view of the various responses. A simple weighting scheme is shown in Figure 1.2. The supplier with the lowest rank and the highest score will be most compliant. Note that this example is purely for illustration. Superior statistical analysis techniques are widely available and recommended.

Supplier ID: KWPK Micronetworks Associates
Ref	Pri	Description	Status	Mfail	Weight	Mult	Score
1.1	M	Supplier must have approvals for shipping to Europe and USA	FULL	0	100	1.0	100
2.1	M	Routers must support RIP, OSPF and BGPv4	FULL	0	100	1.0	100
2.1	H	Router must support OSPF unnumbered links	FULL	0	10	1.0	10
2.2.1	M	Router must support Ethernet, ATM and Token Ring interfaces	PART	1	100	0.5	50
2.2.2	H	Router must support Load balancing over serial links	NONE	0	10	0.0	0
3.1	M	PPP and HDLC are required for wide area encapsulation	PART	1	100	0.5	50
3.2	M	Modem dialback to be supported for secure remote configuration	FULL	0	100	1.0	100
3.2	H	Support for software update mechanisms across the network	FULL	0	10	1.0	10
4.1	D	Statistics mainained on routing and spanning tree convergences	FULL	0	1	1.0	1
4.2	D	An audit trail must be supported	FULL	0	1	1.0	1
5.1	M	Management system must support multi-users plus access levels	FULL	0	100	1.0	100
TOTAL SCORES				2	632	9	522
RANK							17

Figure 1.2: Sample requirements analysis.

In the unfortunate event that all suppliers fail to meet all of the mandatory requirements you may have to consider whether the requirements were really achievable or whether to reissue the document to a wider set of potential suppliers. Either way, with this approach you will be able to measure the best responses systematically.

1.2.3 Information gathering

Once you are clear about the business and user requirements, you must initiate research to characterize the behavior of the users and applications and where they are to be located. Clearly, this information is vital for understanding traffic flows over the network and will ultimately impact cost. It is important, therefore, that you attempt to be as comprehensive and accurate as possible during this phase, since poor-quality data could lead to poor choices being made later on. Ideally we want to build a database of information, such as the following:

Where are users to be located; how many per location; which services will they access, and how often?
How many sites are involved in the new network, and where are they?
Are there any constraints regarding how traffic can flow between sites (e.g., security, political, or cost related)?
Where are the main servers and services located? Do they need to be centralized, distributed, or mixed?
How much traffic is likely over the key backbone and wide area links?
What protocols are required to support the applications and services. Should they be routed, bridged, or switched? Is there any requirement for gateway-style translation?
Is there any legacy equipment (routers, hubs, etc.) that must be retained and integrated into the new design?
Are there any proprietary protocols or legacy services that must be integrated (e.g., SNA or old Wang hosts)?
Are there any specific availability requirements for the network or its systems (e.g., backup links between key sites, mirrored server sites, online trading floors, etc.)?
Are there any specific security requirements for the network or its systems?
What changes in user, application, or service populations are predicted over the next three to five years, and how is the network expected to meet these demands?
What are the budgetary constraints, by location?

Depending upon whether this is a new design or a modified existing design, you will face different challenges when attempting to collate some of this information, as follows:

Greenfield site—Installing a brand new network without the constraints of existing infrastructure is often seen as the ideal scenario, but it does have its drawbacks. On the plus side you have no existing hardware or cabling to deal with, often you can install and test the equipment without having to work around real users, and you can ensure that everything is really working as it should before real users come online. On the minus side you may find it hard to determine what the real network loads and stresses are, since often you will have no existing data to work with and no feedback on any existing systems. In order to get these data you are going to have to talk to the potential suppliers, get detailed specifications of the applications and the underlying protocols, and perform some form of simulation or pilot network to gauge the real performance issues and how they will scale.
Existing site—With an existing site you will have different problems to deal with. Often your access to the site may be limited to unsociable hours, and any testing on a live network may be heavily restricted. You could be limited for space or power supplies for the new equipment, and installing or reusing cabling may be a nightmare, especially if the existing cabling is either substandard or not clearly documented. On the positive side you may already be aware of the potential bottlenecks, and perhaps some of the services are already in place and so can be investigated by putting traffic analyzers onto the network.

The list presented here is far from exhaustive, since the relevance of these data will vary by project. However, by starting to capture information concerning issues presented here it will quickly become clear which information is most important and the level of detail required. In Chapter 2 of reference [1] we worked through a process of systematically refining and presenting this information to create a formal database called the capacity plan.

1.2.4 Planning

By this stage you should have established what the requirements are, and there should be a database of all relevant information concerning users, services, hosts, and how those entities interwork. The process typically starts with a rough conceptual design, often using a whiteboard. At this point the designer must remain open to making changes later on, since firm decisions made at this stage generally result in a design that is far from optimal. The conceptual design is repeatedly analyzed and refined until it begins to make sense. It may be appropriate to consider a number of local and wide area technologies, different equipment vendors, and possibly different application vendors. Choices in any of these areas can completely change the direction of the design.

Technology choices may be directed by pragmatic issues, such as the geographic relationships between sites, services, and users or the region of the world where the network is to be deployed (e.g., a developing country may have only a single service provider offering low-bandwidth leased lines). Such factors often simplify the design, and, although the results are not optimal, such compromises are common in large-scale international network design.

Through an iterative process involving brainstorming sessions, design reviews, and possibly the use of modeling tools, a detailed design will eventually emerge that meets all (or at least most) of the performance and cost constraints and delivers the expected service levels outlined by the requirements specification. This is unceremoniously referred to as the final design (although in practice this tends to be the first draft of the real final design).

The design specification

A network design is just a bunch of ideas in somebody's head unless there is detailed documentation describing that design. The network design specification not only communicates that design, but it also acts as a benchmark for changes made to the design. If there were good reasons for the design choices made in the final design, then there must be equally good reasons for changing that design, so all modifications to the design specification need to be documented together with appropriate justification.

Changes are often made at the commissioning stage that are not reflected back into the design specifications. Failure to record the change history can have serious consequences for the maintenance staff later on. Strong project management can help, and all key personnel in the organization should be regularly updated with current network diagrams and configuration data, and these data should be archived and easily retrievable. Above all, an accurate network design specification must be maintained. The penalty for not maintaining knowledge is at best the cost of retraining all key staff and at worst the job of redesigning the entire network so that the new staff can make sense of it (and this does occasionally happen).

The early stage conceptual design might be fine to get things moving, but ultimately you need detailed documentation to support the design, and it needs to be in a format that can readily be archived and distributed electronically. The design should ideally be presented as a top-down series of schematics, with accompanying documentation explaining the overall design concepts and individual configuration aspects that are significant. Documentation should include the following:

Cable plans for all floor and riser cabling, including patch panel and equipment cabinet layouts and locations, rack space, power requirements, and so on.
Configuration scripts for all core-networking components (routers, bridges, switches, gateways, etc.).
Network addressing models and location of address allocation systems (e.g., DHCP servers).
Resilience and high-availability features, the reasons why they are implemented, a description of how they work, and what the effects of failover are predicted to be.
Any security features that have been implemented (if so there should be a separate policy document explaining the security policy).
A clear description of how the network should be modified and enhanced in the future should be available. Several of the future changes may already have been anticipated at the design phase and should be addressed in the initial design documentation.

Armed with a network design specification, we can now begin to implement the technology.

1.2.5 Implementation

Successful implementation of the design depends upon many factors. At the outset it is vital that there is a clear project plan identifying all key activities, who will perform them, and when they will take place. From the business perspective, and for many other pragmatic reasons, any new technology should be introduced in a phased approach, as follows:

Educate: Start with a demonstration and presentation to senior representatives of the users. Explain what will happen and when. Ensure that access to floor areas and sites is cleared with the appropriate management team.
Pilot test: Install a pilot installation for a small group of users, who must be prepared for possible bugs and glitches. For some projects this may be a luxury, but on large projects this is essential to avoid nasty surprises.
Acceptance: Perform a comprehensive acceptance test to prove that the network performs as intended, and ensure that all outstanding items are resolved. The acceptance test should be used as a benchmark for any subsequent fine-tuning or optimization activities.
Deployment: Install the production network. As the network goes live, ensure that you have plenty of support around and make sure that you can invoke fallback plans in the event of critical problems.

Feedback must be taken at each level and either resolved by making explicit changes or by explaining what the limitations are and agreeing on possible future enhancements. It is important not to move between phases without getting consent from all interested parties. A clear head is required for the final deployment stage; on a large network installation, particularly when replacing existing infrastructure, there often comes a point of no return, and nerves may be stretched to the limit. There are no prizes for delivering a malfunctioning network regardless of how much effort has been put in to it.