Transcript NET Mgmt ch1and 3

Introduction
By Dr. Shadi Masadeh
Company
LOGO
1
Overview of Network Analysis, Architecture,
and Design
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; and second, to understand the system.
Overview of Network Analysis, Architecture,
and Design
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
A Systems Methodology
•Systems methodology : 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
•Users
•Applications
•Devices.
•Associated with this system are sets of services (levels of performance and
function)
•When a network is viewed as part of a system that provides services, the systems
methodology works quite well for a variety of networks, from small and simple
to large, complex networks.
•It helps in determining, defining, and describing the important characteristics and
capabilities of your network.
System Description
•A system is a set of components that work together to support or provide connectivity,
communications, and services to users of the system.
•Users: network and computer support personnel, as well as developers and customers
of that corporation’s product
•Applications: may be specific to a particular user, customer or group, generic to a
customer base, or generic across the entire network.
•Devices: can be subdivided by class to show specialized functions, such as storage,
computing, or application servers, or an individual device may be subdivided to show
its operating system (OS), device drivers, peripheral hardware, or application
programming interface (API).
•Networks.: different size, types of networks.
System Description
System Description
System Description
Service Description
• The concept of network services build upon the (IETF),( Internet Engineering Task
Force ) perspective for IP networks.
•In general, Network services are sets of network capabilities that can be configured and
managed within the network and between networks.
•Network services, are defined as levels of performance and function in the network. We
can look at this from two perspectives as:
•Sets of services being offered by the network to the rest of the system (the devices,
applications, and users) or
•Sets of requirements from the network that are expected by the users, applications,
or devices.
•Levels of performance are described by the performance characteristics capacity, delay,
and RMA (reliability, maintainability, and availability),
•Levels of functions are described as security, accounting, billing, scheduling, and
management (and others).
Service Description
Service Characteristics
•Characteristics of services that are requested from the network can also be considered
requirements for that network.
•Examples of service characteristics:
•Estimates of capacity requirements based on qualitative information about the network
•Elaborate listings of various capacity, delay, and RMA requirements, per user,
application, and/or device,
•Requirements for security, manageability, usability, flexibility
•And others.
Service Characteristics
•Effective services must be described and provisioned end-to-end at all network
components
•
•“End-to-end” does not necessarily mean only from one user’s device to another user’s
device. It may be defined between networks, from users to servers, or between
specialized devices (Figure 1.23).
•When services are not provisioned end-to-end, some components may not be capable
of supporting them, and thus the services will fail
Service Characteristics
Service Characteristics
•Services need to be configurable, measurable, and verifiable within the system to ensure
that end users, applications, and devices are getting the services they have requested.
•Services are also likely to be hierarchical within the system, with different service types
and mechanisms applied at each layer in the hierarchy.
•Figure 1.24 shows a (QoS) hierarchy that focuses on bulk traffic transport in the core
of the network while placing specific services at the access network close to the end
users, applications, and devices.
Service Characteristics
Service Levels
•Service characteristics can be grouped together to form one or more service levels for the
network:
•To make service provisioning easier in that you can
• configure, manage, account, and bill for a group of service characteristics
(service level) instead of a number of individual characteristics.
•For example, a service level (e.g., premium) may combine capacity (e.g.,
1.5 Mb/s) and reliability (as 99.99% uptime).
•Service levels are also helpful in billing and accounting.
•This is a service provider view of the network, where services are offered to
customers (users) for a fee.
Service Levels
• There are many ways to describe service levels:
•
• Levels of capacity
• Classes of service (CoSs), which combine delay and capacity
characteristics
• IP types of service (ToSs)
• Qualities of service (QoSs), which prioritize traffic for traffic
conditioning functions
• Combinations of the aforementioned mechanisms
• Custom service levels, based on groups of individual service
characteristics.
Service Levels
•In Figure 1.25 service offerings, requests, and metrics are shown applied to the system. In
this example a demarcation of services is shown between the device and network
components. Depending on the service requirement or characteristic, however, demarcation
may also be between the device and application components.
System Components and Network Services
 Network services are derived from requirements at each of the components in the
system.
 There can be user requirements, application requirements, device requirements, and
(existing) network requirements.
 User requirements, which are the most subjective and general, are refined and
expanded by requirements from the application component, which are in turn refined
and expanded by the device and network components. Thus, 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).
System Components and Network Services
Services Requests and Requirements
•Services Requests and Requirements Categorized as:
•Best-effort service means that there is no control over how the network will satisfy the
service
•Guaranteed service is the opposite of best-effort service. Where best-effort service is
unpredictable and unreliable, guaranteed service must be predictable and reliable to such
a degree
•These are predictable services, which require some degree of predictability (more than
best effort) yet do not require the accountability of a guaranteed service.
Services Requests and Requirements
Call Admission Control
Service Metrics
 For service performance requirements and characteristics to be useful, they must be
configurable, measurable, and verifiable within the system.
 Therefore, we will describe performance requirements and characteristics in terms of
service metrics, which are intended to be configurable and measurable.
Performance Characteristics
 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.
 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 (roundtrip).
 Another measure of delay incorporates device and application processing, taking
into account the time to complete a task. As the size of a task increases, the
application processing times
 Response time, termed here latency, may yield important information about the
behavior of the application and the network.
 Jitter Delay variation, which is the change in delay over time.
 Together, delay (end-to-end and round-trip), latency, and delay variation help describe
network behavior.
Performance Characteristics

RMA :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.

Maintainability is a statistical measure of the time to restore the system to fully
operational status after it has experienced a fault.

Availability (also known as operational availability) is the relationship between
the frequency of mission-critical failures and the time to restore service.
End of Chapter 1
Requirements Analysis
By Dr. Shadi Masadeh
Company
LOGO
28
Requirements Analysis
Chapter Objectives

Learn about gathering and managing user, application, device, and network
requirements.

Setting and managing your customer’s expectations about the network.

Determining the variables to measure (service metrics) and how to make
measurements.

Developing performance requirements for capacity, delay, and RMA, including
developing performance thresholds and limits.

Discuss predictable and guaranteed performance requirements and their importance

Mapping requirements to geographic locations, in preparation for traffic flow analysis.
The Requirements Analysis Process
Requirements Analysis





Gathering and Listing Requirements
Service requirements are gathered and developed with initial conditions on the
architecture and design, with input from:

Users

Administration,

Management
Then refined by applying experience and knowledge about the analysis process.
Determining Initial Conditions
Initial conditions consist of:

the type of network project,

the scope of the architecture and design,

initial architecture/design goals,

any outside forces acting on the network.
Requirements Analysis

Determining Initial Conditions (continued)

Type of Network Project
 New network
 Modification of an existing network
 Analysis of network problems
 Outsourcing
 Consolidation
 Upgrade

Scope of Network Project
 Network size
 Number of sites
 Distance between sites
Requirements Analysis

Initial Architecture/Design Goals






Upgrade technology/vendor
Improve performance to part or all of network
Support new users, applications, or devices
Solve perceived problems within system
Increase security
Support a new capability in system
Requirements Analysis
Setting Customer Expectations

Customers’ definition of the problem, and their expectations, is quite correct.

Customers’ expectations need to be adjusted somewhat. And there may be times when
you find that their expectations and your expectations are so far apart that it is better
not to continue

on that project
Requirements Analysis
Working with users

A key trade-off is the amount of time spent versus the quality of information
gathered.

Working with your users, administration, and management, not just developing a
network “in the dark.”

Applications have to be designed to work across the network; and devices must be
chosen with the system in mind.

Therefore, it is important not to take a hit-and-run approach
Developing Service Metrics
Developing Service Metrics

We will develop and use performance thresholds and limits to distinguish

between low and high performance, and also use performance characteristics to
identify predictable and guaranteed performance levels

Service metrics are either actual measurable quantities in the network or are derived
from measured quantities

The types of service metrics depend on your design and the types of equipment
(network devices) you implement in your network
Developing Service Metrics

Service metrics for RMA include:

Reliability, in terms of mean time between failures (MTBF) and mean time
between mission-critical failures (MTBCF)

Maintainability, in terms of mean time to repair (MTTR)

Availability, in terms of MTBF, MTBCF, MTTR

Optionally, uptime and downtime (as a percent of total time), error and loss
rates at various levels, such as packet error rate, bit error rate (BER), cell loss
ratio (CLR), cell misinsertion ratio (CMR), frame and packet loss rates
Developing Service Metrics

Service metrics for capacity include:



Data rates, in terms of peak data rate (PDR), sustained data rate (SDR), and
minimum data rate (MDR)
Data sizes, including burst sizes and durations
Service metrics for delay include:

End-to-end or round-trip delay

Latency

Delay variation
Developing Service Metrics

Examples of variables used as service metrics include:

Bytes in/out (per interface)

IP packets in/out (per interface)

Dropped Internet control message protocol (ICMP) messages/unit time (per
interface)

Service-level agreement (SLA) metrics (per user)
 Capacity limit
 Burst tolerance
 Delay
 Downtime
Measurement Tools

Management protocols and MIBs

Commonly available tools to help measure service metrics:

Ping (available in TCP/IP releases), which roughly measures round-trip delays
between selected sources and destinations in the network.

Pathchar (available from ee.lbl.gov), which combines round-trip delay and perlink capacity measurements with path traces, as does another popular utility
traceroute.

TCPdump to analyze TCP traffic .

There are also proprietary, enterprise, and technology-specific tools:
Measurement Tools
Characterizing Behavior
User Behavior


How users of the system will apply applications.
Logic here is that we can develop a rule of thumb for scaling the expected
performance of the network by examining user and application behavior

Simple usage patterns can include:





User work times and durations
For each application the total number of users
The frequency that a user is expected to have an application session running
(usually as number of sessions per user, per day)
How long an average application session will last (usually on the order of
minutes)
An estimate of the expected number of simultaneous user sessions for that
application.
Characterizing Behavior
User Behavior
•Estimating the frequency and duration of application sessions and the number of simultaneous
sessions allows you to apply a modifier to the performance requirement for each application
Characterizing Behavior
Application Behavior

Consider the data sizes that the application will be processing and passing across
the network

The frequency and time duration for data to be passed across the network;

Flow directions (e.g., from client to server); and any requirements for
multicasting (including broadcasts).

Simple model: one session of an application active at any time.

Another model: apply statistical formulas to the usage pattern and application
behavior.
Developing RMA Requirements
Reliability: Reliability is a statistical indicator of the frequency of failure of the
network and its.

Measures of reliability

Mean time between mission-critical failure (MTBCF), usually expressed in
hours.

Mean time between failure (MTBF), which considers all failures, regardless of
their significance at the time of failure, and is a conservative approximation,
useful in simple systems.
Developing RMA Requirements
Maintainability: Maintainability is a statistical measure of the time to restore the
system to fully operational status, once it has experienced a fault.

Measures of reliability
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),

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.



Developing RMA Requirements
Availability: Availability (also known as operational availability) is the relationship
between the frequency of mission-critical failure and the time to restore service.

Measures of availability:
A = MTBCF/MTBCF+MTTR or
A = MTBF/MTBF+MTTR

Where:
 A is availability.
 mean time between mission-critical failures (MTBCF)
 Mean time to repair (MTTR).
 mean time between failure (MTBF)
Developing RMA Requirements

Uptime and Downtime

A common measure of availability is expressed in terms of percent of uptime or
downtime.

For example, a request for proposal (RFP) from a potential customer may state
a required uptime of 99.999% (commonly known as “five nines”) measured per
week, month, or year, based on the total amount of time for that period.

Uptime is when the system (applications, devices, networks) is available to the user

By available, we mean the range from having basic connectivity to actually being
able to run applications across the network.

Downtime can range from being unable to connect across the network, to having
connectivity but with loss rates high enough (or capacity low enough) that
applications do not function properly.
Developing RMA Requirements



Uptime and Downtime
Figure 3.10 below shows some commonly used availability percentages
(as percent of uptime), ranging from 99% to 99.999%.
50
51
52
53
54
55