Network Analysis & Design

Chapter 1: Introduction
Dr. Amjad Hawash
1.3 Background

● Network analysis, architecture, and design is combining an

individual’s particular rules on evaluating and choosing network
technologies; knowledge about how technologies, services, and
protocols can be meaningfully combined; experience in what works
and what doesn’t; along with (often arbitrary) selections of network
architectures.
● Success of a particular network design often depends primarily on
who is doing the work, with results that are rarely reproducible.
● Past: Network building was hobby, these days it is a resource
(revenue generating).
● They are considered “mission-critical” to corporate success and
provide near real-time access to information throughout the world.
1.3 Background

● The design of a network must be logical, reproducible, and

defensible.
● Network analysis, architecture, and design have been based on
developing and applying a set of rules for the network.
● Personal experience (source of rules) as well as from general rules
such as the 80/20 rule (where 80% of a network’s traffic is local and
20% is remote) or the adage “bridge when you can, route when you
must” (bridging being simpler, easier, and cheaper at the time).
● The previous are simple rules, but these days networks must be
adaptable to new technologies, kind of users and type of services
they can provide).
● Example: VPNs vs. Security and Privacy.
1.3 Background

● Network analysis, architecture, and design have traditionally

focused on capacity planning - engineering a network to provide
an amount of capacity (also known as bandwidth) estimated to
accommodate most short- and long-term traffic fluctuations over
the life cycle of the design.
● As network traffic grows over time, this bandwidth buffer is
reduced, and users experience problems related to traffic
congestion.
● This leads to:
– inefficient use of network resources, and
– wasting money
1.3 Background

● We also need to consider how delay through the network, as well

as network reliability, maintainability, and availability (RMA).
● We need to study:
– how the analysis, architecture, and design processes have
changed and how they continue to change.
– how these processes work together in engineering a new or
existing network.
– networks from a different perspective—as a system providing
services to its users.
– how networks can be designed to provide many different types
of services to users.
1.3 Background

● Network analysis helps us understand what is required of a

network in supporting its customers and their applications and
devices (specifically, how to develop requirements,
understand traffic flows, and conduct a risk analysis).
● Architecture: how to make technology and topology choices
for your network, how to understand the relationships among
the various functions within your network, and how to use this
information to develop an architecture.
● Design: where location information, equipment, and vendor
selections are used to detail the design.
1.3 Background
1.3 Background

● Network analysis, architecture, and design will help you

identify and apply network services and performance
levels needed to satisfy your users.
● Through these processes you will be able to understand
the problems you are trying to address with the new
network; determine the service and performance
objectives needed to tackle these problems; and architect
and design the network to provide the desired services
and performance levels.
1.4 Overview of Analysis,
Architecture, and Design Processes
● Network analysis, architecture, and design are processes
used to produce designs that are logical, reproducible, and
defensible.
● These processes are interconnected, in that the output of
one process is used directly as input to the next, thus
creating flows of information from analysis to architecture,
and from architecture to design (Figure 1).
● Network analysis entails learning what users, their
applications, and devices need from the network (Figure
1.2).
1.4 Overview of Analysis,
Architecture, and Design Processes
1.4 Overview of Analysis,
Architecture, and Design Processes
● It is also about understanding network behavior under various
situations.
● Network analysis also defines, determines, and describes
relationships among users, applications, devices, and networks.
● The purpose of network analysis is twofold: first, to listen to users
and understand their needs; and second, to understand the
system (matching).
● In analyzing a network we examine the state of the existing
network, including whatever problems it may be having.
● We develop sets of problem statements and objectives that
describe what our target network will be addressing.
1.4 Overview of Analysis,
Architecture, and Design Processes
● We develop requirements and traffic flows, as well as
mappings of users, applications, and devices, in support of
our problem statements and objectives.
● Network analysis helps us understand what problems we
are trying to solve, and in the process we compile
information that will be used in developing the architecture
and design.
● Consider the use of VPNs from Example 1.1. We can
develop problem statements, objectives, and requirements
for VPNs in an existing network, and develop an analysis,
architecture, and design solely around a VPN deployment.
1.4 Overview of Analysis,
Architecture, and Design Processes
● Network architecture uses the information from the analysis
process to develop a conceptual, high-level, end-to-end
structure for the network.
● We make technology and topology choices for the network.
● We also determine the relationships among the functions of the
network (addressing/routing, network management,
performance, and security), and how to optimize the
architecture across these relationships.
● There usually is not a single “right” architecture or design for a
network; instead there are several that will work, some better
than others (optimized across several parameters).
1.4 Overview of Analysis,
Architecture, and Design Processes
● The network architecture process determines sets of
technology and topology choices; the classes of
equipment needed; and the relationships among network
functions (Figure 1.3).
1.4 Overview of Analysis,
Architecture, and Design Processes
● Network design provides physical detail to the architecture.
It is the target of our work.
● Physical detail includes blueprints and drawings of the
network; selections of vendors and service providers; and
selections of equipment (including equipment types and
configurations) (Figure 1.4).
1.4 Overview of Analysis,
Architecture, and Design Processes
1.4 Overview of Analysis,
Architecture, and Design Processes
● During network design we use an evaluation process to
make vendor, service provider, and equipment selections,
based on input from the network analysis and architecture.
● (minimizing network costs or maximizing performance).
● Network design is also about applying the trade-offs,
dependencies, and constraints developed as part of the
network architecture.
● Trade-offs, such as cost versus performance or simplicity
versus function.
1.4 Overview of Analysis,
Architecture, and Design Processes
● Aim: network analysis, architecture, and design combine
several things—requirements, traffic flows, architectural
and design goals, interactions, trade-offs, dependencies,
constraints, and evaluation criteria—to optimize a
network’s architecture and design across several
parameters.
1.4.1 Process Components

● Analysis, architecture, and design processes have actions

that will be taken by project personnel and results or
products of each action (figure 1.5).
● Each of the processes and products has components that
describe specific actions or results (figure 1.6).
1.4.1 Process Components
1.4.1 Process Components
1.4.2 Tactical and Strategic
Significance
● Network analysis, architecture, and design are part of the
engineering process that forms the basis of networking
projects.
● Such projects have immediate, tactical (near-term), and
strategic (long-term) significance, and networking projects
should consider all of these areas.
● While the current target will be a network design, the near-
term and long-term targets can be proposed enhancements
to the current target, lists of problem statements, objectives,
and requirements for near-term and long-term, or all of
these. Example (Figure 1.7).
1.4.2 Tactical and Strategic
Significance
1.4.2 Tactical and Strategic
Significance
● The idea behind this plan is to develop a network design that
will be implemented within one year, will prepare us for any
changes we might need to make to the network within three
years, and will keep us in the direction of what is planned for
five years in the future.
● The long-term (five-year) target is a rough estimate because we
will not know
– what new networking technologies, services, or levels of
performance will be available five years out.
– how our customers’ business plans will change.
– what network problems will arise during that time.
1.4.2 Tactical and Strategic
Significance
● The current (one-year) target should be well understood and is the
focus of our analysis, architecture, and design effort.
● In between the one-year and five-year targets, the near-term (three-
year) target is intended to be somewhat flexible, yet better understood
than the long-term target.
● Example: VoIP
– one-year plan: prepare for VoIP by improving the overall eliability of
the network.
– three-year plan: add or expand VoIP to those areas that can support
it.
– five-year plan: address any major changes that occurred over the
previous four years, including advancements in VoIP technology
1.4.2 Tactical and Strategic
Significance
● These plans are intended to be iterative and should be
regularly reviewed, on the order of twice yearly, once per
year, or every two years, depending on your plan.
● One iteration of the cycle (including network
implementation, test, and acceptance) is shown in Figure
1.8.
1.4.2 Tactical and Strategic
Significance
● Each iteration is an incremental step toward the near-term
and long-term targets, as shown in Figure 1.9.
1.4.3 Hierarchy and Diversity

● Two important characteristics of networks: their levels of

hierarchy and diversity.
● Hierarchy is the degree of concentration of networks or
traffic flows at interconnection points within the network, as
well as the number of tiers of interconnection points within
the network.
● As networks grow in size and numbers of users,
applications, and devices increase, hierarchies provide
separation and structure within the network.
1.4.3 Hierarchy and Diversity

● Hierarchies are important because they help us in

determining the sizes of networks, including routing and
addressing configurations, and the scaling of network
technologies, performance, and service levels.
● Diversity (a.k.a. redundancy or interconnectivity) in the
network design.
● As hierarchy provides structure in the network, diversity
balances this structure by interconnecting the network at
different levels in the design to provide greater
performance through parts of the network.
1.4.3 Hierarchy and Diversity

● Diversity is important in that it provides a mechanism to

achieve performance within a hierarchical structure.
● There must be trade-off between Hierarchy and Diversity.
● Hierarchy provides a separation of the network into segments.
● These segments may be separate, smaller networks (subnets)
or broadcast domains.
● Hierarchy is necessary when the amount of traffic on the
network grows beyond the capacity of the network or when
interactions between devices on the network result in
congestion
1.4.3 Hierarchy and Diversity
1.4.3 Hierarchy and Diversity

● We have 4 levels of hierarchy.

● Note that the end points of this tree (commonly referred to
as leaves; they represent the end networks, devices, or
users).
● An example of adding hierarchy to a network is changing
from a flat (bridged or layer 2 switched) structure to a
routed structure.
● Adding routing to the network breaks a broadcast domain
into a number of smaller broadcast domains, and traffic
flows are concentrated at routers.
1.4.3 Hierarchy and Diversity
1.4.3 Hierarchy and Diversity

● Hierarchy is also added to networks when evolving from a

single autonomous system (AS) to connecting multiple
ASs, as well as when migrating from Interior Gateway
Protocols (IGPs) to Exterior Gateway Protocols (EGPs)
and to policy-based routing.
● A content delivery network (CDN) is an example of adding
diversity to a network.
● A CDN bypasses the core of a network, where congestion
is most likely to occur, and directly connects devices or
networks lower in the hierarchy.
1.4.3 Hierarchy and Diversity
1.4.3 Hierarchy and Diversity

● This provides better, more predictable performance but

can also affect the network hierarchy by modifying its
routing behavior.
1.4.4 Importance of Network Analysis

● Network requirements are requests for capabilities in the

network, usually in terms of performance and function, which
are necessary for the success of that network (can be gathered
and/or derived from customers, applications, and devices).
●
They form the basis for customer expectations and satisfaction.
● Requirements, in conjunction with measurements on the
existing network (if there is one), are used to derive traffic flows
(sets of network traffic that have some common attributes,
such as source/destination address, information type, routing,
or other end-to-end information)
1.4.4 Importance of Network Analysis

● The helps in detecting where “hot spots”—focal points for

network performance—will appear in the network.
● Evaluating security risks is also part of the analysis
process.
● Results of the analysis process, the requirements and flow
specifications, are then used as input for both network
architecture and design.
● Audit Trail: the resulting architecture and design are
defensible.
1.4.4 Importance of Network Analysis

● Analysis is important in that it helps us understand the complexity and

nuances (differences) of each network and the systems they support.
● Provides data upon which various decisions are made.
● Understanding Network and System Complexity
– Complexity lies in the sophistication of the capabilities provided by that
network.
– Capacity and delay control mechanisms.
– traffic shaping
– quality of service at multiple levels in the network
– service-level agreements to couple services to customers
– Policies to govern and implement service throughout the network
1.4.4 Importance of Network Analysis

● A service-level agreement is an informal or formal contract between a

provider and user.
● Policies are high-level statements about how network resources are to be
allocated among users.
● Network and system complexity is nonlinear.
● Network optimization must consider competing and often conflicting needs.
● These days:
– Networks focused on interoperability (allow connections among multiple
disparate networks).
– Service delivery is important to the success of users and their
applications.
1.4.4 Importance of Network Analysis
1.4.4 Importance of Network Analysis

– Components of the network will evolve to become self-

configurable and manageable.
– Dynamic between hierarchy and diversity that can be
seen in the current Internet.
● Hierarchy in the Internet often forces traffic flows through
nonoptimal paths, crossing several ASs (Autonomous
Systems) with differing performance and service
characteristics, hindering high-performance, high-quality
delivery.
1.4.4 Importance of Network Analysis
1.4.4 Importance of Network Analysis

● To counteract the impact of hierarchy, diversity can be

introduced into the Internet at strategic points, providing
shortcuts that bypass parts of the Internet.
●
1.4.4 Importance of Network Analysis

● Analysis helps us understand how technologies influence

networks, users, applications, and devices (and vice
versa).
● This is important for gauging how users of the network will
adapt to the network, which affects the overall life cycle of
the network.
● For example, the evolution of routing protocols, shown in
Figure 1.16. Although the Routing Information Protocol
(RIP), an Interior Gateway Protocol (IGP) deployed as part
of early TCP/IP releases.
1.4.4 Importance of Network Analysis
1.4.4 Importance of Network Analysis

● As new, upgraded, or different users, applications, and

devices are added to a network, the requirements on that
network may change.
● The analysis process must examine how high-end
computer and applications servers, data storage, analysis
and archival systems, and specialized environment-
specific devices such as PDAs, video cameras, or medical
equipment impact the network.
1.4.4 Importance of Network Analysis

● Finally, the analysis process helps us understand the

forces and changes at work within the system (network
and its users, applications, and devices).
1.4.4 Importance of Network Analysis

● Architecture and Design Defensibility

– Documentation that provides information about decision
making in the network architecture and design
processes.
– An audit trail helps address questions such as “Why did
you choose that technology?” “Why doesn’t this new
network perform as expected?” or “Why did this network
cost so much?”
1.4.4 Importance of Network Analysis

●
Decisions made regarding the network architecture and design need
to be defensible from several perspectives:
– Technical: in order to be able to address any technical challenges
made against your architecture and design.
– Budgetary: to ensure that network costs are within budget or to
justify why a budget has been exceeded.
– Schedule: to ensure that time frames for development, installation,
testing, and operations are being met.
– Resources: such as personnel or equipment, to ensure that the
customer has everything necessary to build and operate this
network (Audit trail is a history for personnel).
● Web pages can be used for Audit Trail.
1.4.5 Model for Network Analysis,
Architecture, and Design
● Lacking data from analysis and architecture, we may not
have a basis for making technology comparisons and
trade-offs.
● And most importantly, without the proper requirements
gathering and analysis, we cannot be sure if our network
will meet the needs of its users.
1.4.5 Model for Network Analysis,
Architecture, and Design
● Network analysis, architecture, and design are similar to other
engineering processes in that they address the following areas:
– Defining the problems to be addressed
– Establishing and managing customer expectations
– Monitoring the existing network, system, and its environment
– Analyzing data
– Developing a set of options to solve problems
– Evaluating and optimizing options based on various trade-offs
– Selecting one or more options
– Planning the implementation
1.4.5 Model for Network Analysis,
Architecture, and Design
● An early part of every project is determining what your
customer’s expectations are and adjusting these
expectations accordingly.
● Part of determining customers’ expectations means
understanding what customers want to do with their
network.
● Having established what the customer’s expectations are,
you may need to adjust and manage these expectations
(discuss trade-offs with them).
1.4.5 Model for Network Analysis,
Architecture, and Design
● If an existing network is part of this project, monitoring this
network, as well as other parts of the system and its environment,
can provide valuable information about the current behavior of
users, applications, and devices and their requirements for the
new network (define problems of the existing network).
● During the network monitoring process, collect data, then analyze:
requirements or needs analysis, flow analysis, and a risk
(security) analysis.
● Results of the network analysis are used in the architecture and
design processes, where sets of options are developed, including
potential architectures, designs, topologies, technologies,
hardware, software, protocols, and services.
1.4.5 Model for Network Analysis,
Architecture, and Design
● These sets of options are then evaluated to determine the
optimal solutions for the problems.
1.5 A Systems Methodology

● Systems methodology (as applied to networking) means

viewing the network that you are architecting and
designing, along with a subset of its environment
(everything that the network interacts with or impacts), as
a system (With the services it provides).
● Study dependencies (between NW and other systems).
1.6 System Description

● Components of the system include users, applications,

devices, and networks.
●
1.6 System Description

● The components of the previous diagram can be

subdivided.
● OSI: Open System Interconnect relation with previous
figure.
1.6 System Description

● All of these components work together to provide

connectivity and communications across the network,
among users, applications, and devices.
1.6 System Description

● The degree of granularity used to describe system

components is a trade-off between the amount of detail
and accuracy you want in the description and how much
time and effort you are willing to put into it.
● If you are the network architect responsible for a corporate
network, you may be able to invest time and resources into
developing a detailed description of your system’s
components, whereas a consultant or vendor’s design
engineer may have little time and resources to spend on
such a description.
1.6 System Description

● One reason for identifying components of the system is to

understand how these components interface with one
another across component boundaries.
● By defining what the components of the system are, we
are also setting what is to be expected across each
interface.
● Users may be other
devices in the system
Like SAN (Storage
Area Networks).
1.7 Service Description

● Network services: (two perspectives)

– Services being offered by the network to the rest of the
system (the devices, applications, and users).
– sets of requirements from the network that are expected
by the users, applications, or devices.
● Networks are based on best-effort (unpredictable and
unreliable) delivery.
● Some new types of services, including high-performance,
predictable (stochastic or probabilistic), and guaranteed
services.
1.7 Service Description

● Network services are hierarchical:

1.8 Service Characteristics

● Service characteristics are individual network performance

and functional parameters that are used to describe
services.
● These services are offered by the network to the system
(the service offering) or are requested from the network by
users, applications, or devices (the service request-aka
requirements).
●
1.8 Service Characteristics

● Such requirements are useful:

– determining the need of the system for services.
– providing input to the network architecture and design.
– Configuring services in network devices (e.g., routers,
switches, device operating systems).
● Measurements of these characteristics in the network to
monitor, verify, and manage services are called service
metrics.
1.8 Service Characteristics

● Services must be described and provisioned end-to-end at

all network components between well-defined demarcation
points (separation).
● “End-to-end” may be defined between networks, from
users to servers, or between specialized devices (Figure
1.23).
1.8 Service Characteristics

● Services also need to be configurable, measurable, and

verifiable within the NW.
● Necessary to ensure that end users, applications, and
devices are getting the services they have requested and
paying for.
●
1.8.1 Service Levels

● Service characteristics can be grouped together to form

one or more service levels for the network.
● Easier for configure, manage, account, and bill for a group
of service characteristics.
● For example, a service level (e.g., premium) may combine
capacity (e.g., 1.5 Mb/s) and reliability (as 99.99% uptime).
●
1.8.1 Service Levels
1.8.2 System Components and
Network Services
● Network services are derived from requirements at each of the
components in the system.
● Service requirements are derived from each component.
● There can be user requirements, application requirements,
device requirements, and (existing) network requirements.
● Requirements filter down from user to application to device to
network, resulting in a set of specific requirements that can be
configured and managed in the network devices themselves.
● This results in a service offering that is end-to-end, consisting of
service characteristics that are configured in each network device
in the path (e.g., routers, switches, hubs).
1.8.2 System Components and
Network Services
1.8.2 System Components and
Network Services
● Defining network services and service metrics helps keep
the system functioning and can provide extra value or
convenience to users and their applications.
● This helps in measuring the QoS in the network, which will
help us in network monitoring and management.
1.8.2 System Components and
Network Services
1.8.2 System Components and
Network Services

One of the architectural and design goals is to identify such performance

bottlenecks before the network is implemented.
1.8.3 Service Requests and
Requirements
● Service requests and requirements are, in part,
distinguished by the degree of predictability needed from
the service by the user, application, or device making the
request (best effort, predictable, and guaranteed).
● Best-effort service means that there is no control over
how the network will satisfy the service request.
– users have to adapt with the NW.
– the expected service for such requests will be both
unpredictable and unreliable.
1.8.3 Service Requests and
Requirements
● Guaranteed service is the opposite of best-effort service.
– must be predictable and reliable.
– contract between the user and provider.
– Penalty.
● Predictable services requires some degree of
predictability (more than best effort) yet do not require the
accountability of a guaranteed service.
1.8.3 Service Requests and
Requirements
1.8.3 Service Requests and
Requirements
1.8.3 Service Requests and
Requirements
● There is a trade-off between two approaches:
– Limit the number of resource allocation, hence provide
better services for the current users (but blocks extra users).
– Serve all of the users, limits the QoS for each one.
● Could be hybrid.
● There will be a threshold between low and high performance.
● Best-effort, predictable, and guaranteed service refer to the
degree of predictability of a request or requirement, whereas
low and high performances refer to a relative performance level
for that request or requirement.
1.8.4 Service Offerings

● Service requests that are generated by users, applications,

or devices are supported by services offered by the
network.
● Service offerings map to service requests and thus can
also be categorized as best effort, predictable, or
guaranteed.
● Best-effort service offerings are compatible with best-effort
service requests (like downloading using FTP with all
possible bandwidth).
1.8.4 Service Offerings

● On the other hand, predictable and guaranteed service

offerings have some degree of predictability or are
bounded.
● To achieve this, there has to be some knowledge of the
network, along with control over the network, in order to
meet performance bounds or guarantees.
● Such services must be measurable and verifiable.
● This does not necessarily imply that it is also high
performance.
1.8.5 Service Metrics

● For service performance requirements and characteristics

to be useful, they must be configurable, measurable, and
verifiable within the system.
● Because service metrics are meant to be measurable
quantities, they can be used to measure thresholds and
limits of service.
● A threshold is a value for a performance characteristic
that is a boundary between two regions of conformance
(compatible) and, when crossed in one or both directions,
will generate an action.
1.8.5 Service Metrics

● A limit is a boundary between conforming and nonconforming

regions and is taken as an upper or lower limit for a
performance characteristic.
● Crossing a limit is more serious than crossing a threshold, and
the resulting action is usually more serious.
● A threshold can be defined to distinguish between low and
high performance for a particular service.
● An example of this might be in measuring the round-trip delay
of a path. A threshold of N ms is applied to this measurement.
If the round-trip times exceed N ms, an alert is generated at a
network management station.
1.8.5 Service Metrics

● Limits can be created with service metrics to provide upper

and lower boundaries on a measured quantity.
● When a limit is crossed, traffic is considered
nonconforming (it exceeds the performance requirement),
and action is taken to bring the traffic back into
conformance (e.g., by delaying or dropping packets).
1.8.5 Service Metrics

● Figure 1.31 shows how limits and thresholds may be

applied in the system.
● In this figure, a threshold of 6 Mb/s is the boundary
between low and high performance for a service
requirement, and an upper limit of 8 Mb/s is the boundary
between conformance and nonconformance for that
service.
● When traffic crosses the 6 Mb/s threshold, a warning is
sent to network management (with a color change from
green to yellow).
1.8.5 Service Metrics
1.8.5 Service Metrics

● When traffic crosses the 8 Mb/s limit, the network takes

action to reduce the capacity used by that traffic flow and
an alert is sent to network management (with a color
change from yellow to red) until the capacity level drops
below 8 Mb/s and is again conforming.
● Thresholds and limits are useful applications of service
metrics to understand and control performance levels in
the network, in support of services.
1.9 Performance Characteristics

● Capacity, Delay and RMA.

● capacity is used as a label for the class of characteristics
that involves moving information from place to place,
including bandwidth, throughput, goodput (the number of
useful information bits delivered by the network to a certain
destination per unit of time.), and so forth.
● delay is a label for the class of characteristics that includes
end-to-end delay, round-trip delay, and delay variation.
● RMA is a label for the class of characteristics that includes
reliability, maintainability, and availability.
1.9.1 Capacity

● Capacity is a measure of the system’s ability to transfer

information (voice, data, video, or combinations of these).
Several terms are associated with capacity, such as
bandwidth, throughput, or goodput.
1.9.2 Delay

● Delay is a measure of the time difference in the

transmission of information across the system.
● In its most basic sense, delay is the time difference in
transmitting a single unit of information (bit, byte, cell,
frame, or packet) from source to destination.
● There are also various sources of delay, such as
propagation, transmission, queuing, and processing.
● Delay may be measured in one direction (end-to-end) and
both directions (round-trip using ping).
1.9.2 Delay

● Latency can also be used to describe the response time of

a network device, such as the latency through a switch or
router.
● In this case the processing time is of that switch or router.
● Delay variation (Jitter) is the change in delay over time.
1.9.3 RMA

● Reliability is a statistical indicator of the frequency of

failure of the network and its components and represents
the unscheduled outages of service.
● Reliability can be coupled with confidence in that it
describes how users have confidence that the network and
system will meet their requirements.
● Maintainability is a statistical measure of the time to
restore the system to fully operational status after it has
experienced a fault (MTTR).
1.9.3 RMA

● Repairing a system failure consists of several stages: detection;

isolation of the failure to a component that can be replaced; the
time required to deliver the necessary parts to the location of the
failed component (logistics time-assumed to be 0 seconds); and
the time to actually replace the component, test it, and restore
full service.
● Availability is the relationship between the frequency of
mission-critical failures and the time to restore service (mean
time between failures).
● A = (MTBCF)/(MTBCF + MTTR) or A = (MTBF)/(MTBF + MTTR).
● A is availability
1.9.4 Performance Envelopes

● Performance envelope is a combination of two or more

performance requirements, with thresholds and upper
and/or lower limits for each.
● Within this envelope, levels of application, device, and/or
network performance requirement are plotted.
● Figures 1.32 and 1.33 show two such envelopes.
1.9.4 Performance Envelopes

● The performance envelope in Figure 1.32 consists of

capacity, in terms of data sizes transferred across the
network, and end-to-end delay.
1.10 Network Supportability

● It is a mistake to assume that a successful network

architecture and design meet the requirements only on the
day it is delivered to the customer and that future
requirements are the responsibility of the customer.
● Experience indicates operations and support constitute
80% of the life-cycle costs of a system, whereas
development, acquisition, and installation represent only
20%.
● Good network architects/designers take into account the
major factors that affect operability and supportability as
they make their decisions.
1.10 Network Supportability

● The postimplementation phases of a network’s life cycle

can be broken into three elements: operations,
maintenance, and human knowledge.
● The operations element focuses on ensuring that the
network and system are properly operated and managed.
● The maintenance element focuses on preventive and
corrective maintenance.
● The human knowledge element is the set of
documentation, training, and skilled personnel required to
operate and maintain the network.
1.10 Network Supportability

● Failure to consider supportability in the analysis,

architecture, and design processes has a number of
serious consequences.
– Rejection of network if users not adapted to use it.
– If not adapted very well, losing business could be the
result.
– Continuous calls for maintenance.
1.10 Network Supportability

● Key characteristics of a network architecture and design

that affect the postimplementation costs include:
– Network and system reliability.
– Network and system maintainability.
– Training of the operators to stay within operational
constraints.
– Quality of the staff required to perform maintenance
actions.
1.10 Network Supportability

● Some examples of key network architecture/design

decisions that affect these characteristics include:
– Degree of diversity of critical-path components in
network architecture/design.
– Quality of network components selected for installation.
– Location and accessibility of components requiring
frequent maintenance.
– Implementation of built-in test equipment and
monitoring techniques.
1.10 Network Supportability

● Supportability is very important.

● Two major tasks must be accomplished to ensure
supportability:
– Conformance (compatibility) to the network architecture
and design must be validated and nonconformance
corrected or (at least) documented to ensure that
performance is adequate and that maintenance can be
performed.
– Operations and maintenance personnel must understand
and be trained in the technologies that are being deployed.