Network Analysis, Architecture

and Design
INSA 443

Ch1: Introduction
Ch1: Introduction

Ch1 INTRODUCTION
 1.4 Overview of Analysis, Architecture, and Design Processes

• Network analysis entails learning what users, their

applications, and devices need from the network (Figure 1.2).
• It is also about understanding network behavior under various
situations.
• Network analysis also defines, determines, and describes
relationships among users, applications, devices, and networks.
• In the process, network analysis provides the foundation for all
the architecture and design decisions to follow.
• The purpose of network analysis is twofold:
• first, to listen to users and understand their needs;
• second, to understand the system. Ch1 INTRODUCTION
1.4 Overview of Analysis, Architecture, and Design Processes

Ch1 INTRODUCTION
 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.

• In developing the network architecture, 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.
Ch1 INTRODUCTION
1.4 Overview of Analysis, Architecture, and Design Processes

Ch1 INTRODUCTION
 1.4 Overview of Analysis, Architecture, and Design
Processes

• Network design provides physical detail to the architecture.

• It is the target of our work, the culmination of analysis and

architecture processes.

• Physical detail includes blueprints and drawings of the network;

selections of vendors and service providers; and selections of
equipment (including equipment types and configurations)
Ch1 INTRODUCTION
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
Ch1 INTRODUCTION
 1.5 System Methodology
• Viewing the network along with a subset of its environment as a system.
• Everything that the network interacts with or impacts.
• Associated with this system are sets of services (level of performance and
function) that are offered by the network to the rest of the system.
• So, the Network is considered as a part of a larger system with interactions
and dependences between the network and its users, applications, and
devices.
• It is not just providing connectivity and packet forwarding performance, but
a platform for various services.
• With this view, it helps in determining, defining, and describing the
important characteristics and capabilities of your network.
Ch1 INTRODUCTION
 1.6 System Description

• A system is a set of components that work together to support or provide

connectivity, communications, and services to the users.

• The system components are: users, applications, devices, and networks.

• The users considered as part of the system since they have requirements that

include them.
Ch1 INTRODUCTION
1.6 System Description (Cont.)

Ch1 INTRODUCTION
1.6 System Description (Cont.)

Ch1 INTRODUCTION
 1.7 Service Description
• The network services are the level of performance and function in the network.

• Also, they are sets of network capabilities that can be configured and managed within

the network and between networks.

• The services have two perspectives:

- Services being offered by the network to the rest of the system (users, APPs, and devices).

- Sets of requirements from the network that are expected by the users, APPs, or devices.

• Levels of performance are described by the performance characteristics, which are

capacity, delay, and RMA (reliability, maintainability, and availability). Ch1 INTRODUCTION
 1.7 Service Description (Cont.)

• Functions are described as security, accounting billing, scheduling,

management, …etc.

• The concept of services used in this book is based on what networks can deliver
to the system, and not confused by with services that other parts of the system
(APPs) can deliver to each other.

Ch1 INTRODUCTION
 1.8 Service Characteristics
• One of the goals of network analysis is to be able to characterize services so that they
can be designed into the network and purchased from vendors and service providers
• 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 if they are requested from the network by users, APPs, or devices, they are called the
service request (network requirements).
• Thus, service = performance + function.
• Service metrics are measurements of characteristics in the network to monitor, verify,
and manage services.
Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
• For services to be useful and effective, they must be described and provisioned end-

to-end at all network components between well-defined demarcation points.

• End-to-end could be from user’s device to another user’s device, users to servers,

between networks, or between specialized devices.

• The demarcation points determine where end-to-end is in the network and

determining these demarcation points is an important part of describing a service.

Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
• Services need to be configurable, measurable, and verifiable within the system

to ensure that end users, APPs, and devices are getting the services they have

requested (and possibly have being paying for),

• this leads to accounting and billing for system (including network) resources

• Again, service metrics are used to measure and verify services and their

characteristics.
Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)

• Services are also likely to be hierarchical within the system, with

different service types and mechanisms applied at each layer in the

hierarchy.

• The quality-of-service (QoS) at the core level is generalized.

• While it is specific at the access level.

Ch1 INTRODUCTION
1.8 Service Characteristics (Cont.)

Ch1 INTRODUCTION
 1.8 Service Characteristics

• 1.8.1 Service Levels

• 1.8.2 System Components and Network Services

• 1.8.3 Service Requests and Requirements

• 1.8.4 Service Offerings

• 1.8.5 Service Metrics Ch1 INTRODUCTION

 1.8 Service Characteristics (Cont.)
1.8.1 Service levels
• Service characteristics can be grouped together to form one or more service levels.
• This makes service provisioning easier to configure, manage, account, and bill for a group of
service characteristics (service level) instead of a number of individual characteristics.
• Ways to describe service levels:
- Committed Information Rates (CIRs) in Frame Relay network Level of capacity.
- Class of Services (CoSs) combine delay and capacity characteristics.
- IP Types of Service (ToSs) and Qualities of Service (QoSs)  prioritize traffic for traffic
conditioning functions.
• The above combinations depend on which network technology, protocol, mechanism, or
combination is providing the service. Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.1 Service levels (Example 1.7.)

A request came from a customer that each building should have Fast Ethernet (FE)
capacity to the rest of the network. As part of the requirements analysis, this request became a
requirement for 100 Mb/s peak capacity from the users in each building. This service request
was then matched in the requirements and design processes by a technology choice that could
meet or exceed the request.

In this case, FE was chosen as the technology, and the service offering was 100 Mb/s to
each building. Service metrics were then added, consisting of measuring the FE connections
from the IP switch or router at each building to the backbone.
Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.2 System Components and Network Services.

• Network services are derived from requirements at each of the components in the system.

• They have to be end-to-end according to the demarcations.

• There can be user, APPs, device, and network requirements.

• The requirements filter down from user to APP to device to network resulting in a set of

specific requirements that can be configured and managed in the network devices.
Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.2 System Components and Network Services (Cont.)

• This results in service offering that is end-to-end, consisting of service characteristics that are
configured in each network device in the path (i.e. switch, router).

• Defining network services and service metrics help keep the system functioning and can provide extra
value or convenience to users and their applications.

• By defining service metrics, we are determining what we will be measuring in the network, which will
help us in network monitoring and management.

• Recall that network services are sets of performance and function, so requirements may also include
functions of one of the components.

• Examples of functions include network monitoring and management, security, and accounting.
Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.3 Service requests and requirements.

• They are distinguished by the degree of predictability needed from the service by the
user, application, or device making the request.

Service Requests Category

Best of effort Predictable Guaranteed

Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.3 Service requests and requirements (Cont.)

• Best-effort service:
• No control over how the network will satisfy the service requests.
• Indicates that the rest of the system (users, APPs, and Devices) will have to
adapt to the state of the network at any given time.
• Services will be both un-predictable and unreliable.
• No specific performance requirements for the network.

Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.3 Service requests and requirements… Cont.

• Guaranteed service:
• guaranteed service must be predictable and reliable to such a degree that,
when service is not available, the system is held accountable.
• It implies a contract between the user and the provider.
• When the contract is broken, the provider is accountable and must
account for loss of service and compensate the user.

Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.3 Service requests and requirements (Cont.)

• Predictable service:
• This service falls in between best of effort and guaranteed services.
• They offer some degree of predictability and yet are not accountable.
• Predictable and guaranteed are based on some prior knowledge of and
control over the state of the system.
• This service must have clear set of service requirements.
• These requirements must be configurable, measurable and verifiable.
Ch1 INTRODUCTION
 1.8 Service Characteristics (Cont.)
1.8.4 Service Offerings

• Service offerings map to service requests and thus can also be categorized as best
effort, predictable, or guaranteed.
• Best-effort service offerings are not predictable— they are based on the state of the
network at any given time.
• There is little or no prior knowledge about available performance, and there is no
control over the network at any time. Most networks today operate in best-effort
mode.
• A good example of a network that offers best-effort service is the current Internet.
Ch1 INTRODUCTION
1.9 Performance Characteristics

• 1.9.1 Capacity

• 1.9.2 Delay

• 1.9.3 RMA

• 1.9.4 Performance Envelopes

Ch1 INTRODUCTION
1.9 Performance Characteristics
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 such as bandwidth, throughput, or goodput.

• Although we use the generic term capacity throughout this book to reference
this class of characteristics, you may choose to use another term in place of or
along with capacity.

Ch1 INTRODUCTION
 1.9 Performance Characteristics

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.

• As with capacity, there are several ways to describe and measure delay.

• 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).
Ch1 INTRODUCTION
 1.9 Performance Characteristics
1.9.3 RMA

• RMA refers to reliability, maintainability, and availability.

• Reliability is a statistical indicator of the frequency of failure of the network and its components
and represents the unscheduled outages of service.

• It is important to keep in mind that only failures that prevent the system from performing its
mission, or missioncritical failures (more on this in Chapter 2), are generally considered in this
analysis.

• Failures of components that have no effect on the mission, at least when they fail, are not
considered in these calculations. Failure of a standby component needs tending to but is not a
mission-critical failure.
Ch1 INTRODUCTION
 1.9 Performance Characteristics
1.9.3 RMA (reliability, maintainability, and availability)

• Maintainability is a statistical measure of the time to restore the system to fully operational status after it

has experienced a fault. This is generally expressed as a mean-time-to-repair (MTTR).

• 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); and the time to actually replace the component, test it, and restore full service.

• MTTR usually assumes the logistics time is zero; this is an assumption, which is invalid if a component must

be replaced to restore service but takes days to obtain.

Ch1 INTRODUCTION
 1.9 Performance Characteristics
1.9.3 RMA (reliability, maintainability, and availability)

• Availability (also known as operational availability) is the relationship between the

frequency of mission-critical failures and the time to restore service.

• This is defined as the mean time between mission-critical failures (or mean time
between failures) divided by the sum of mean time to repair and mean time
between mission-critical failures or mean time between failures. A = Availability:
• A = (MTBCF)/(MTBCF+MTTR) or A=(MTBF)/(MTBF+MTTR)

Ch1 INTRODUCTION
 1.9 Performance Characteristics

1.9.4 Performance Envelopes

• Performance requirements can be combined to describe a performance range for

the system.

• A 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

requirements are plotted.
Ch1 INTRODUCTION
 1.10 Network Supportability

• The ability of the customer to sustain the required level of performance (that

architected and designed into the network) over the entire life cycle of the network

is an area of networking that is often neglected.

• 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.

Ch1 INTRODUCTION
Ch1 INTRODUCTION
Network Analysis, Architecture
and design
INSA 443

Ch2: Requirements Analysis: Concepts

 Chapter 02:

Requirements Analysis:

Concepts
2.1 Objectives
• In this chapter we expand the concept of requirements for a network.

• Types of requirements, users, applications, devices, and network components.

• Grouping requirements together.

• Mapping the locations of applications and devices

• Combination of all the requirements and locations in two documents:

• a requirements specification and a requirements map.
 2.2.1 Requirements and Features
• The act of gathering and deriving requirements in order to understand systems and network

behaviors.

• There is a subtle difference between requirements and features:

• Requirements are description of network functions and performance needed for the

network to successfully support its users. (A.k.a. Core or fundamental requirements)

• Features are functions and performance that are desired but not deemed necessary

• e.g., think of some requirements and features on your current phone

 2.2.1 Requirements and Features (Cont.)
• A method to categorize requirements is based on the current practice of: Internet Engineering
Task Force (IETF)

• RFC 2119 identifies key words and phrases that can be used to describe the relative importance
of a requirement.

• Key Phrases used to classify importance of requirements.

1. Must/ Shall/ Require – Implementation is absolutely necessary

2. Must Not/ Shall Not – Absolute restricted requirements.

3. Should/ Recommend – Implementation is not absolutely necessary.

4. Should Not/ Not Recommended – Requirement may be prohibitive.

5. May/ Optional – May become a future or rejected requirement.

 2.2.2 The Need for requirement Analysis

• It is fundamental for network design, it is often ignored.

• Network personnel and management are often distanced from the users and do not have a
clear idea of what users want or need.

• The requirements analysis results in a requirements specification and a requirements map.

• A requirements specification: a document that lists and prioritizes the requirements

gathered for the architecture and design.

• The requirements map shows the location dependencies between applications and devices,
which will be used for flow analysis.
 2.3 User Requirements
• User represents primarily the end users of the system but
can be expanded to include everyone involved in the system,
such as network and system administrators and
management.

• User requirements comprise the set of requirements that is

gathered or derived from user input and represent what is
needed by users to successfully accomplish their tasks on
the system.

• Describing requirements at user layer, it will lead to the

development of more specific requirements as you work
through each of the components.
 2.3 User Requirements (Cont.)
1. Timeliness : user must be able to access, transfer, or modify information within
a tolerable time frame. e.g., Each file transfer shall take less than 10 minutes;
video frames should come in every 30 msec.
2. Interactivity : similar to timeliness but focuses on response time from the
system.
3. Reliability : the level of service to the user must be consistent and reliable
(RMA).
4. Presentation Quality : quality must be presentable.
5. Adaptability: ability of the system to adapt to users’ changing needs;
6. Security : guarantee of confidentiality, integrity, and authenticity.
7. Affordability : financial feasibility.
8. Functionality : functional requirements
9. Supportability : how well the customer can keep the network operating at
designated performance levels.
10. Future Growth : if and when users are planning to deploy new apps/devices
2.3 User Requirements
 2.4 Application Requirements
• Application requirements are requirements that
are determined from application information,
experience, or testing, and represent what is needed by
applications to successfully operate on the system.

• Are more technical than user requirements but may still

be subjective.

• The types of Application requirements;

• Application Types.

• Application Groups.

• Application Locations.
 2.4 Application Requirements (Cont.)
2.4.1 Application Types

• This component is often where many requirements for the network are determined, as

applications couple users and devices to the network.

• Applications are often end-to-end, between multiple devices; thus, their requirements span

the underlying network.

• These application types are described by their requirements and service metrics.
 2.4 Application Requirements (Cont.)

2.4.1 Application Types

• Based on service and performance requirements, we type applications as follows:

• Mission-critical applications have predictable, guaranteed, and/or high performance RMA

requirements.

• Rate-critical applications have predictable, guaranteed, and/or high-performance

capacity requirements.

• Real-time and interactive applications have predictable, guaranteed, and/or high

performance delay requirements.
 2.4 Application Requirements (Cont.)
2.4.1 Application Types
RMA Effect (Reliability , Maintainability, and Availability)
• Reliability is a statistical measure of the frequency of failure of the network.
• Maintainability is the statistical measure of the time to rest ore the system.
• Availability is a measure of the relationship between the frequency of critical failures and the
time to restore service.
• An application that handles a lot of transactions and money can loose revenue or customers.
• Telemetry and tele-conferencing applications can suffer from unrecoverable data.
• Sensitive data could be lost: customer ID or billing info
• Even life could be lost if a health care networking application fails.
 2.4 Application Requirements (Cont.)
2.4.1 Application Types
Capacity Effect
• Some applications require a predictable, bounded, or high degree of capacity.
• These applications, termed here rate-critical applications.
• E.g. voice, non-buffered video, and some “tele∗service” applications such as teleconferencing,
telemedicine, and teleseminars.
• Rate-critical applications may require thresholds, limits, or guarantees on minimum, peak,
and/or sustained capacities.
• It is not like best-effort applications where the application receives whatever capacity is
available from the network, based on the state of the network at that time as well as
interactions between TCP and the lower layers (e.g., FTP).
 2.4 Application Requirements (Cont.)
2.4.1 Application Types
Delay Effect
• Delay is a measure of the time differences in the transfer and processing of information.
• There are many sources of delay, including propagation, transmission, queuing, processing,
and routing.
• Increasing interactivity is the driving force behind the evolution of many applications (Telnet
and FTP to Gopher).
• This section focuses on end-to-end and roundtrip delays, which encompass all of the delay
types mentioned above.
• Applications used on the Internet did not have strict delay requirements (Best-effort service).
• Other applications, found primarily on private networks have had more strict delay
requirements (as well as capacity and RMA requirements).
 2.4 Application Requirements (Cont.)
2.4.2 Application Groups
1. Command and control /telemetry applications
• High-performance delay and reliability, mission-critical and/or real-time; e.g., aircraft control
2. Visualisation applications
• High performance capacity or delay, Real-time and/or controlled r ate; e.g., weather modelling
3. Distributed computing applications
• High performance delay, possibly interactive; e.g., Parallel or Cluster Computing
4. Web access, development and use
• Delay sensitive but not high performance
5. Bulk data transport
• Not high performance; e.g., ftp, file sharing
6. Tele-service applications
• High performance capacity, delay, and/or reliability, might require multicast backbone e.g.,
Teleconferencing, telemedicine, tele-seminars
7. Operations, administration and maintenance
• High reliability; e.g. network monitoring and management, network security
2.4 Application Requirements (Cont.)
2.5 Device Requirements
 2.5 Device Requirements (Cont.)
• Knowing the locations of existing or expected generic computing devices, servers,
and specialized devices can be helpful in determining the relationships among
system components

• Coupled with types and performance requirements of devices and servers, it gives
us an insight into the relative concentrations of users and devices, placement, and
relative concentrations.

• This also helps us determine the traffic flow characteristics.

• Why bother with device types? To avoid the last-foot problem: getting
services and performance from the network to the user.
 2.5 Device Requirements (Cont.)
Devices Groups:
1. Generic computing devices: difficult to list, describe, and graph each device; e.g.,
Desktop and laptops (portable)
2. Servers : provide a service to one or more users; e.g, web server
3. Specialized Devices : provide special capability; e.g., Surveillance Camera

• Unlike servers and generic devices, these tend to be location-dependant

• Performance Characteristics to measure:

• Storage performance, Processor (CPU) performance, Memory performance, Bus

performance, OS performance, Device driver performance
2.5 Device Requirements (Cont.)
 2.6 Network Requirements
• If the project is to improve a current network, then most network architectures/designs need

to incorporate existing networks.

• This includes system upgrades, such as adding a new application to the system, migrating to a

new or different technology or protocol, or upgrading the network infrastructure, and the

expansion

• Also, the network architecture and design must accommodate any dependencies and

constraints imposed by the existing network. or reduction of a system’s size or scope.

 2.6 Network Requirements (Cont.)
2.6.1 Existing Networks and Migration

• Scaling dependencies. The existing network can impact how the planned network will scale.
For example, how will the addition of the new network to the existing network change the size
and scope of the system?

• Location dependencies. Depending on how the new networks interface with or incorporate
the existing network, or how the network modifications are done, the locations and/or
concentrations of other components of the system are likely to change.

• Performance constraints. The overall performance of the system will be affected by our
architecture and design for the expected network (or network modification), how it interacts
with the existing network, and its performance levels.
 2.6 Network Requirements (Cont.)
2.6.1 Existing Networks and Migration (Cont.)

• Network, system, and support service dependencies. These include network addressing
strategies, security, choices and configurations of routing protocols, and naming strategies, while
support services include systemwide security, accounting, and monitoring and management.

• Interoperability dependencies. Interoperability dependencies between existing and planned

networks occur at boundaries between the networks, usually where different technologies or
media are used.

• Network obsolescence. Even though there may be parts of the existing network that will be
integrated into the planned network, these parts, including network devices, protocols, and
software, may become obsolete during the life cycle of your new network.
 2.6 Network Requirements (Cont.)
2.6.2 Network Management and Security

• It is useful to briefly outline their requirements here, as a start toward considering them in the
architecture and design process.
• And the later analysis in the architecture and design processes will generate new
requirements or modify some that we develop here.
• At this point in the analysis process we want to think in general terms about how we may
accomplish network management and security in the new network.
• There are four categories of network management tasks:
• Monitoring for event notification.
• Monitoring for metrics and planning.
• Network configuration.
• Troubleshooting.
 2.7 Other Requirements
2.7.1 Supplemental Performance Requirements

• To satisfy the customers and end users with what you have done, the engineer must consider
that phase when the network implementation is finally complete, and the system is in the
hands of the operators.
• Three characteristics of performance that reflect the customer’s impact on our network
design are operational suitability, supportability, and confidence:
• Operational suitability is a measure of how well our network design can be
configured, monitored, and adjusted by the customer’s operators.
• Supportability is a measure of how well the customer can keep the system
performing, as designed, over the entire life of the system.
• Confidence is a measure of the ability of the network to deliver data without
error or loss at the required throughput.
 2.7 Other Requirements (Cont.)
2.7.2 Financial Requirements
• This requirement serves to limit funding to network devices and services, instead of including other
parts of the system (e.g., desktop computers and servers).
• Funding is often bounded by an overall cost limit, consisting of both one-time and recurring
components.
• One-time costs are based on the actual planning and construction of the network and consist of
network architecture, design, procurement, deployment, integration, and testing, and all
hardware/software components, as well as the initial installation or establishment of any services from
service providers.
• Recurring costs are for tasks and items that are expected to occur or be replaced/upgraded on a
periodic basis. This includes network OAM&P, costs from service providers, and provisions for
modifications to the network. Time frames for recurring costs vary, driven by customer/end user,
administrative, and management financial cycles and technology life cycles.
• The financial requirements gathered during the analysis process will be combined with the users’
affordability requirements, to form a complete financial picture of the network.
 2.7 Other Requirements (Cont.)
2.7.2 Enterprise Requirements

• The commonly considered enterprise requirements are phone, FAX, voice, and
video.

• The integration of these types of requirements over the same transmission

infrastructure as data is becoming common,

• Such enterprise requirements need to be considered as part of the overall

requirements for the network.
• Such as phone, FAX, voice, and video.