elmi.com

The need for network resilience is driven by the application availability

requirements. After ascertaining the availability requirements of each

application, a plan must be put in place to ensure that this availability can

be provided. A resilient design must provide full resilience along the clientto-

server data path. This entails achieving the following:

Most network designs are characterized by a tradeoff between cost and

availability. Providing a truly resilient design for all aspects of the network

in many cases will cause the network budget to be exceeded. It is then a

question of prioritizing and defining the exact level of resilience that will be

provided for each application and on each part of the network.

It is also important to define what you mean by resilience. Resilience on

paper does not always represent dynamic failover in the event of a problem.

The classic example is the question of resilience in the local loop. There is

not much point in having one leased line as backup for another if they are

both in the same local loop cable to the central office.

Another issue is how resilience against degraded service or congestion is

incorporated into the network. This again relates to the application availability

requirements and the sensitivity to delay and packet loss.

The speed of convergence is another key issue that determines whether

the failover to backup paths or devices results in any lost sessions. The specification

for convergence speed could, for example, determine the choice of

IP routing protocol.

The fundamental platform of the network should be designed once. This

design must incorporate scalability to cater for growth in applications,

users, or the number of sites on the network. The network should only be

redesigned if an event fundamentally changes the character of the network,

such as a new application that is radically more bandwidth-intensive than

any existing application. Another example might be connections to new

business partners that require various policies and configurations. The latter

is an example of a mini-design project that may change the characteristics

of the network.

In order to plan for growth and change, an estimate of the network’s life

expectancy should be established. Be realistic about this figure. You can

only look so far into the future in this field of endeavor. It should not be

more than 10 years. If it is expected to be in place for this length of duration,

however, then think back 10 years to how different the network was in

terms of networking technology, applications, and user requirement and

expectations. You will then clearly realize that all networks must be capable

of supporting change and evolution.

Network design should be able to incorporate likely future changes without

requiring a significant or radical redesign. Growth in the number of

users and the implementation of new applications should be provided for.

Although accurate estimates on growth or change in these areas might not

be realistic, it is important to gain at least a qualitative estimate.With this

in place, the network should be able to scale to these requirements by growing

rather than being completely overhauled.

Of course, instances will occur where an unforeseen event does require a

radical redesign. The company’s business strategy might alter and this

might affect the networking requirements. The enterprise might merge

with another company. In these situations, it may well be a case of “back to

the drawing board” for the design engineers.

The fundamental network design is only a starting point, but it is a starting

point that rarely should be deviated from in a fundamental manner.

Some industry commentators underestimate the importance of network

design and choose to bunch it in with network support as an ongoing

process. Network design is an ongoing process but should be a process of

refinement and modification rather than continuous redesign. Nobody can

predict the future with precise accuracy, but it is the first function of the

designer to incorporate an educated prediction into the design. To use an

analogy, consider a person planning his or her retirement fund. Many

unpredictable variables will change before retirement, but that does not

mean that he or she cannot have a plan or that the plan must persistently

and radically change every time a blip occurs in the stock market.

Scalability is a key issue that will be discussed in each of the upcoming

IP routing protocols, and device deployment and network topology.

Network management should be incorporated into the design. It is not sufficient

to treat it as an afterthought. Support is usually the second greatest

single cost of ownership on a network. It can be minimized through wellplanned

network management.

Each of the traditional elements of network management should be considered

as part of the initial design process:

minimize downtime should be decided at the design stage. For example,

the simple act of formulating a clear site and device-naming convention

can improve the efficiency with which troubleshooting is performed.

configurations and performing changes on the network should be

decided prior to rollout.

outset. Some networking devices support their own accounting features

and if accounting is a priority, then this may influence the choice of

devices and technology.

performance parameters should be monitored on a proactive basis. The

old adage “what gets measured improves,” while clichéd, is certainly

relevant here. Some networks may only require the periodic monitoring

of performance statistics.

The designer should be clear about the type and level of performance

management required and feasible within budgetary constraints. This

must be incorporated into the design as it influences the features that

need to be supported on the network devices.

the next section.