331 Network Design

INFO 331
Computer Networking
Technology II
Network Design Intro
Glenn Booker
INFO 331
Network Design
Network Design
Through the Kurose text weve covered
The application, transport, network, & link layers

Wireless and multimedia technologies
Security
Network management
Not bad!
So how does all this come together to help
create a network?
INFO 331
Network Design
Network Design
Ok, thats not a small question well just

tickle the surface (not even scratch!)
Main resources for this section are:
INFO 331
McCabe, James D. (2003). Network Analysis,

Architecture & Design (2nd Ed.). San Francisco:
Morgan Kaufmann Publishers. [Chapters 1-5, 10]
Teare, Diane. (2004). CCDA Self-Study:
Designing for Cisco Internetworking Solutions
(DESGN). Indianapolis: Cisco Press.
Network Design
Network Design Objective
Ultimately, our network design must answer

some pretty basic questions
What stuff do we get for the network?

How do we connect it all?
How do we have to configure it to work right?
Traditionally this meant mostly capacity

planning having enough bandwidth to
keep data moving
INFO 331
May be effective, but result in over engineering

Network Design
Network Design Objective
And while some uses of the network will need

a lot of bandwidth (multimedia), we may also
need to address:
Security
Possible wireless connectivity

Reliability and/or availability
INFO 331
Considering both internal and external threats
Like speed for a car, how much are you willing

to afford?
Network Design
Network Design Phases
Designing a network is
typically broken into three
sections:
Determine requirements
Define the overall
architecture
Choose technology and
specific devices
(McCabe, 2003)
INFO 331
Network Design
Systems Methodology
Theres lots of room for refining these

sections (Teare, 2004)
INFO 331
Identify customer requirements

Characterize the existing network
Design topology
Plan the implementation
Build a pilot network
Document the design
Implement the design, and monitor its use
Network Design
Two Main Principles
For a network design to work well, we need

to balance between
Hierarchy how much network traffic flows

connect in tiers of organization
INFO 331
Like tiers on an org chart, hierarchy provides

separation and structure for the network
Interconnectivity offsets hierarchy by allowing

connections between levels of the design, often
to improve performance between them
Network Design
Two Main Principles
(McCabe, 2003)
INFO 331
Network Design
Plan Ahead!
The 80/20 rule applies here
80% of the cost of a network is its operation

and support
Only 20% is the cost of designing and
implementing it
So plan for easy operation, maintenance,

and upgrade of the network
INFO 331
Network Design
10
Requirements? Booooring!
Yes, determining the requirements for a

network probably isnt as much fun as
shopping for really expensive hardware
INFO 331
And that may be why many networks are poorly

designed no one bothered to think through
their requirements!
Many people will jump to a specific technology or
hardware solution, without fully considering other
options the obvious solution may not be the
best one
Network Design
11
Requirements
We need to develop the low level design and

the higher level architecture, and understand
the environment in which they operate
We also need to prove that the design weve
chosen is just right (Southey, 1837)
INFO 331
Is that $2 million network backbone really enough

to meet our needs?
How do we know $500,000 wouldnt have been
good enough?
Network Design
12
Requirements
Part of this process is managing the

customers expectations
INFO 331
They may expect a much simpler or more

expensive solution than is really needed
Showing analysis of different design options,
technologies, or architectures can help prove
you have the best solution
Network Design
13
Requirements
We need to use a systems approach for

understanding the network
The system goes far beyond the network

hardware, software, etc.
Also includes understanding the users,
applications or services, and external environment
How do these need to interact?

What does the rest of the organization
expect from the network?
INFO 331
Network Design
14
Requirements
Consider how devices communicate
Images from (McCabe, 2003)

unless noted otherwise
INFO 331
Network Design
15
Requirements
What services are expected from the

network?
Typical performance levels might include

capacity, delay time, reliability
Functions include security, accounting,

scheduling, management
INFO 331
Providing 1.5 Mb/s peak capacity to a remote user

Guaranteeing a maximum round-trip delay of 100 ms
to servers in a server farm
Defining a security or privacy level for a group of users

or an organization
Network Design
16
Requirements
Service requirements
could include the
QoS (quality of
service) guarantees
(ATM, Intserv,
Diffserv, etc.)
INFO 331
This connects to
network management
monitoring of network
performance
Network Design
17
Requirements
Capacity refers to the ability to transfer data
Bandwidth is the theoretical capacity of some part

of the network
Throughput is the actual capacity, which is less
than the bandwidth, due to protocol overhead,
network delays, etc.
INFO 331
Kind of like hard drive actual capacity is always less

than advertised, due to formatting
Network Design
18
Requirements Analysis
Given these concepts, how do we describe

requirements for a network?
Need a process to filter or classify
requirements
INFO 331
Network requirements (often have high, medium,

low priorities)
Future requirements (planned upgrades)
Rejected requirements (remember for future ref.)
Informational requirements (ideas, not required)
Network Design
19
Requirements Analysis
Requirements can come from many aspects

of the network system
User Requirements
Application Requirements
Device Requirements
Network Requirements
Other Requirements
INFO 331
Network Design
20
User Requirements
User requirements are

often qualitative and
very high level
INFO 331
What is fast enough

for download? System
response (RTT)?
How good does video
need to be?
Whats my budget?
Network Design
21
What types of apps are we using?
Mission-critical
Rate-critical
Real-time and/or interactive
How sensitive are apps to RMA (reliability,

maintainability, availability)?
What capacity is needed?
What delay time is acceptable?
INFO 331
Network Design
22
What groups of apps are being used?
INFO 331
Telemetry/command and control - remote devices

Visualization and simulation
Distributed computing
Web development, access, and use
Bulk data transport FTP
Teleservice VOIP, teleconference
Operations, admin, maintenance, and
provisioning (OAM&P) DNS, SMTP, SNMP
Client-server ERP, SCM, CRM
Network Design
23
Where are the

apps located?
Are some only
used in certain
locations?
INFO 331
Network Design
24
Device Requirements
What kinds of devices are on your network?
INFO 331
Generic computing devices include normal PCs,

Macs, laptops, handheld computers, workstations
Servers include all flavors of server file, print,
app/computation, and backup
Specialized devices include extreme servers
(supercomputers, massively parallel servers),
data collection systems (POS terminals), industryspecific devices, networked devices (cameras,
tools), stoplights, ATMs, etc.
Network Design
25
Device Requirements
Specialized
devices are
often locationspecific
INFO 331
Network Design
26
Device Requirements
We want an understanding of the devices

performance its ability to process data from
the network
INFO 331
Device I/O rates

Delay time for performing a given app function
Network Design
27
Device Requirements
Performance results from many factors
INFO 331
Storage performance, that is, flash, disk drive,

or tape performance
Processor (CPU) performance
Memory performance (access times)
Bus performance (bus capacity and arbitration
efficiency)
OS performance (effectiveness of the protocol
stack and APIs)
Device driver performance
Network Design
28
Device Requirements
The device
locations are also
critical
INFO 331
Often generic
devices can be
grouped by their
quantity
Servers and
specialized stuff are
shown individually
Network Design
29
Network requirements (sounds kinda

redundant) are the requirements for
interacting with the existing network(s) and
network management concerns
Most networks have to integrate into an
existing network, and plan for the future
evolution of the network
INFO 331
Network Design
30
Issues with network integration include
Scaling dependencies how will the size of the

existing network affect the new one?
INFO 331
Will the existing network change structure, or just add

on a new wing?
Location dependencies interaction between old

and new networks could change the location of
key components
Performance constraints existing network could
limit performance of the new one
Network Design
31
Network, system, and support service

dependencies
Interoperability dependencies
INFO 331
Addressing, security, routing protocols and network

management can all be affected by the existing
network
Changes in technology or media at the interfaces
between networks need to be accounted for, as well
as QoS guarantees, if any
Network obsolescence do protocols or

technologies become obsolete during transition?
Network Design
32
Network management and security issues

need to be addressed throughout
development
How will the network be monitored for events?

Monitoring for network performance?
INFO 331
What is the hierarchy for management data flow?
Network configuration?
Troubleshoot support?
Network Design
33
Security
analysis can
include the
severity
(effect) of
an attack,
and its
probability
of
occurrence
INFO 331
Effect/ Probability
User Devices
Servers
Network
Software
Services
Data
Unauthorized Access
B/A
B/B
C/B
A/B
B/C
A/B
Unauthorized Disclosure
B/C
B/B
C/C
A/B
B/C
A/B
Denial of Service
B/B
B/B
B/B
B/B
B/B
D/D
Theft
A/D
B/D
B/D
A/B
C/C
A/B
Corruption
A/C
B/C
C/C
A/B
D/D
A/B
Viruses
B/B
B/B
B/B
B/B
B/C
D/D
Physical Damage
A/D
B/C
C/C
D/D
D/D
D/D
Effect:
Probability:
A: Destructive
C: Disruptive
A: Certain
C: Likely
B: Disabling
D: No Impact
B: Unlikely
D: Impossible
Network Design
34
Other Requirements
Requirements can come from other outside

sources your customer, legal requirements,
larger scale organization (enterprise)
requirements, etc.
Additional requirements can include
INFO 331
Operational suitability how well can the

customer configure and monitor the system?
Supportability how well can the customer
maintain the system?
Network Design
35
Other Requirements
Confidence what is the data loss rate when the

system is running at its required throughput?
Financial requirements can include not only

the initial system cost, but also ongoing
maintenance costs
System architecture may be altered to remain

within cost constraints
INFO 331
This is a good reason to present the customer with

design choices, so they see the impact of cost
versus performance
Network Design
36
Other Requirements
Enterprise requirements typically include

integration of your network with existing
standards for voice, data, or other protocols
INFO 331
Network Design
37
Requirements Spec and Map
A requirements specification is a document

which summarizes the requirements for
(here) a network
Often it becomes a contractual obligation, so

assumptions, estimates, etc. should be carefully
spelled out
Requirements are classified by Status, as

noted earlier (core/current, future, rejected,
or informational requirement)
INFO 331
Network Design
38
Priority can provide additional numeric

distinction within a given Status (typically
on a 1-3 or 1-5 scale)
Sources for Gathering requirements can be
identified, or give basis for Deriving it
Type is user, app, device, network or other
Requirements Specification
ID/Name
INFO 331
Date
Type
Description
Gathered/Derived
Network Design
Locations
Status
Priority
39
Requirements
Mapping can
show graphically
where stuff is,
what kind of
apps are used,
and existing
connectivity
INFO 331
Network Design
40
Requirements Analysis Process
So, how do we
determine what the
requirements are for
our network?
Collect requirements
service metrics, and
delays to help
develop and
map requirements
INFO 331
Network Design
41
Gather and List Requirements
A great starting point is the very beginning

What initial conditions are you facing?
What type of project is this?
What is the overall scope of the project?
INFO 331
New network, Modifying an existing network,

Analysis of network problems, Outsourcing,
Consolidation, Upgrade
Network size, Number of sites, Distance between sites
Network Design
42
Initial Conditions
Why is the network being designed? What

are the goals for its architecture & design?
INFO 331
Upgrade technology and/or 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
Network Design
43
Initial Conditions
What project constraints are there?
Funding, organizations involved, existing network,

facility limitations, schedule, political, etc.
Are users receptive to the new network?
Are user needs homogeneous, or are there

multiple tiers of performance needs?
INFO 331
The former is easier to handle, of course
Network Design
44
Customer and User
Customer expectations need to be set quickly
What order of magnitude is the project, and does

that match what they thought?
Better to find out early on if theres a big gap!
Working with users is important, to know how

they use the network and what problems they
find important
INFO 331
Surveys, phone calls, personal meetings, and/or

group discussions could be used
Network Design
45
Customer and User
Look for red flags in early discussions
Abuse of the term "real-time"

Availability as solely a percentage (99.99%)
"High performance" without verification or
clarification
Highly variable, inconsistent requirements
Unrealistic expectations from the customer
Measure application performance using

existing network (if possible) or a test bed
INFO 331
Network Design
46
Requirements Management
The requirements you develop need to be

tracked and managed, just like any systems
requirements
Identify requirements by some form of ID and

short name
Need a tool to track requirements, their status,
changes, sources, etc.
Map location of apps and devices of the

existing network
INFO 331
Network Design
47
Service Metrics
Service metrics are characteristics measured

or derived from the network
Metrics must be configurable, measurable, and

verifiable
RMA metrics might include
INFO 331
Reliability mean time between failures (MTBFs)

and mean time between mission critical failures
(MTBCFs)
Maintainability mean time to repair (MTTR)
Availability MTBF, MTBCF, and MTTR
Network Design
48
Service Metrics
Related RMA metrics include
Uptime and downtime (percentage 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
Service metrics for capacity include:
INFO 331
Data rates peak data rate, sustained data rate,

and minimum data rate
Data sizes burst sizes and durations
Network Design
49
Service Metrics
Service metrics for delay include:
End-to-end or round-trip delay

Latency
Delay variation
SNMP or CMIP (Common Management

Information Protocol) can be used to
configure these metrics, which are kept in
the Management Information Base (MIB)
INFO 331
Network Design
50
Service Metrics
MIB Variables often used as service metrics:
INFO 331
Bytes in/out (per interface)

IP packets in/out (per interface)
Dropped ICMP messages per time per interface
Service-level agreement (SLA) metrics (per user)
Capacity limit
Burst tolerance
Delay
Downtime
Network Design
51
Metrics Tools
Tools for making service metric measurements

include
Ping, pathchar, traceroute, TCPdump

Packet capture utilities: Ethereal, Sniffer, and Etherpeak
Then summarize the metrics collection approach
Service Metric
Where Metric Will Be Measured in System
Measurement Method
LAN Delay
Between NM Device and Each Router in LAN
Ping
WAN Delay 1
Between NM Device and Local Router Interface to WAN
Ping
WAN Delay 2
Between NM Device and Remote Router Interface to WAN
Ping
LAN Packet Loss
At Each Local Router
SNMP
INFO 331
Network Design
52
Characterizing Behavior
Next we can analyze how users and apps

use the existing network
We could use simulations or models to
assess network behavior
Thats way beyond the scope here!
User behavior is looking for patterns in how

people use apps
INFO 331
How many users, how frequently, how long per

session, how much data they use
Network Design
53
Characterizing Behavior
Application behavior includes looking at how

each app uses the network
Communication between client/server parts

Multicast or broadcast transmissions how often,
how big
Focus on the most critical apps (mission

critical, real time, interactive, etc.)
Models can be simple or complex, as project
size and time constraints dictate
INFO 331
Network Design
54
RMA Requirements
Reliability is a common measurement
Mean time between mission critical failure

(MTBCF) focuses on failures during certain time
periods, excluding planned down times
Mean time between failure (MTBF) includes
failure at any time
Maintainability is typically captured with mean

time to repair (MTTR)
INFO 331
Network Design
55
RMA Requirements
Availability relates failures to repair time
Scheduled maintenance time doesnt count

against availability
Uptime and downtime measure those

percentages when the system is up or down
INFO 331
The upper practical limit is 99.999% uptime,

which is 5.3 minutes of downtime per year
Uptime of 99.99% is fairly common
How many events occur is also important
Network Design
56
RMA Requirements
Thresholds and limits can be defined for RMA

measures
MTBF is typically a couple thousand hours

MTTR may be a few hours
Different parts of the system may have

different requirements
INFO 331
Network Design
57
Delay Requirements
Various delays can have a strong impact on

network requirements
INFO 331
Interaction delay (INTD) is how long a user will

wait for a response from the system
Human response time (HRT) is when a system
delay becomes noticable to a user
Network propagation delay is how long it takes for
a command to cross the network and get the reply
Network Design
58
Delay Requirements
INTD and
HRT help
distinguish
burst from
bulk apps
INFO 331
Network Design
59
Delay Requirements
End-to-end and round-trip delays can be

network requirements
Weve used ping to get RTT (round trip time)
Delay variation can be defined for multimedia

apps typically is 1-2% of end-to-end delay
INFO 331
Network Design
60
Capacity Requirements
Much of the needed capacity of a network

derives from key applications that are
especially intense in such areas
Peak data rate

Minimum acceptable data rate
Sustained (long term) data rate
We need to distinguish apps that CAN use a

lot of capacity (if its available), versus those
that MUST use a lot
INFO 331
Network Design
61
Data Rates
Data rates for an app can be measured at

many levels of the protocols
App, network, etc.

Most TCP apps will take whats available, but
back off when the network gets crowded (why?)
Often we may need to identify where the

performance bottleneck is located
It helps to get a rough idea of typical app
performance
INFO 331
Network Design
62
Typical App Capacity Needs

Application
Average Completion
Time (Seconds)
Average Data
Size (Bytes)
Distributed Computing
(Batch Mode)
103
107
Web Transactions
10
104
Database
Entries/Queries
25
103
Payroll Entries
10
102
Teleconference
103
105
INFO 331
Network Design
63
Data Rates
Sometimes a range of values is more helpful
Processing credit card info might take 5-10

seconds, and require 100-1000 bytes of data
Multimedia rates are well known, and depend

on the protocol and level of compression and
quality desired
Low- and high-performance realms are
completely subjective there are no industry
or generic numbers to set them apart
INFO 331
Network Design
64
Supplemental Performance
Other non-functional requirements can be

important to a network
Operational Suitability is making sure your
customer can operate the network once its
running
INFO 331
How often are manual network adjustments

needed?
How often does network configuration change?
How much monitoring is automated?
Network Design
65
Operational Suitability
How many shifts of operators will there be?

How well trained are the network operators?
How often will hardware changes be needed?
What hardware can the operators change?

What level of component is an operator expected
to be able to change? Chip, board, rack unit,
entire rack? (Line-Replaceable Unit, LRU)
All of this can result in a Concept of

Operations description
INFO 331
Network Design
66
Supportability
Can the networks level of performance be

sustained over time?
Is affected by
INFO 331
RMA of the architecture and design

Workforce, including training and staffing levels
System procedures and technical documentation
Tools, both ordinary and special
Spare and repair parts
Network Design
67
Supportability
Maintenance of a system expects
Components are located where they can be

maintained without affecting the rest of the
system much
Spare parts are supplied to allow replacement of
failed and soon-failed components
Reliability can be formally modeled with

reliability block diagrams (RBDs) or failure
mode and effect analysis (FMECA)
INFO 331
Network Design
68
Supportability
Workforce should be equivalent to the ones

being replaced; or at least as cheap overall
Documentation typically includes
INFO 331
Technical documentation of the system

configuration, design, parts, etc.
Maintenance procedures describe routine actions
Casualty or corrective procedures describe how
to troubleshoot, debug, or otherwise fix basic
problems
Network Design
69
Supportability
Tools and test equipment describe what tools

are needed to maintain the system
How are faults detected?

How is performance being monitored?
What capabilities will be available to remotely
diagnose, reconfigure, or reset components?
Stuff breaks and wears out, so spare parts

are needed to improve availability
INFO 331
How much are you will to invest in parts?

Network Design
70
Supportability
All of this produces a concept for support of

a network
Important to state assumptions about the

knowledge, skills, and availability of support
personnel
Spares are an ongoing investment the customer
needs to be aware of their cost
Often results in at least three tiers of support

(onsite, central maintenance, and vendor)
INFO 331
Network Design
71
Supportability
Level
Tools and Test

Equipment
Organizational
Common tools
Operator consoles
and controls
Inexpensive special
tools
Intermediate
Depot
INFO 331
Corrective
Maintenance
Day-to-day
monitoring
Troubleshooting
Fault isolation
Reconfiguring
system
Preventive
Maintenance
Monitoring
performance Minor
on-site cleaning and
adjustments
Special or expensive On-site repair of

portable tools with
offline equipment
limited use
Major on-site
upgrades
Supplement
operators
Equipment to
refurbish
components
Scheduled overhaul
or disassembly of
LRUs
Overhaul and
refurbishment
Network Design
72
Confidence
Confidence is the ability of a network to

provide throughput at an acceptable error
or loss rate
Often thought of at the device or link level,

but can also be considered end-to-end
Measure by percent of traffic lost during a

given time period (e.g. 2% loss up to 1 min)
INFO 331
Ping might be used to measure losses
Network Design
73
Environment-specific Limits
What constitutes acceptable performance

depends wildly on the industry or particular
environment of the network
High-performance devices often drive the

acceptable thresholds or limits
Also consider if predictable or guaranteed

performance is important
INFO 331
May lead to high QoS requirements, since best

effort may not be good enough
Network Design
74
Map and Spec
Then, as mentioned earlier, map out the

requirements, and write them in a
specification
INFO 331
Make sure you and your customer are in

agreement on the needs of the network
Prioritize requirements, so if something has
to give, its not critical to your customer
Network Design
75
Flow Analysis
The requirements map is a great place to

start analysis of flows in your network
We dont want to model EVERY traffic (data) flow,

just the important ones
A traffic flow describes data movement, e.g.
INFO 331
Source and/or destination addresses

Type of information
Directionality (bidirectional or unidirectional)
Other aspects, such as QoS needs
Network Design
76
Flow Analysis
Flow Characteristics
Later, flows can be

broken down into
subnet or link level
flows
A key purpose of flow
analysis is to
understand the balance
between hierarchy and
interconnectivity
needed
Capacity (e.g., Bandwidth)

Performance
Requirements
Delay (e.g., Latency)

Reliability (e.g., Availability)
Quality of Service Levels
Importance/
Priority
Levels
Business/Enterprise/Provider
Political
Directionality
Common Sets of Users,
Applications, Devices
Other
Scheduling (e.g., Time-ofDay)

Protocols Used
Addresses/Ports
Security/Privacy Requirements
INFO 331
Network Design
77
Flow Analysis
Flows can be
individual, or
grouped into
composites
Flows can be
critical (and
often drive
architecture
and design)
INFO 331
Network Design
78
Flow Analysis
The requirements spec should be able to

define flows by user, app, device, & network
Looks for important flows by application,
location, user type, device, type of function
(multimedia, mission critical)
Define capacity (Kbps or Mbps), delay
requirements (ms), reliability requirement (%)
Map flows geographically
INFO 331
Network Design
79
Flow Analysis
INFO 331
Network Design
80
Consolidate Flows
INFO 331
Network Design
81
Data Sources and Sinks
Look for devices (servers, special devices)

which generate lots of data (sources) or take
in a lot of data (sinks)
Consider also WHEN the flows occur are
there specific times that are critical?
Consider worst-case and normal-usage
scenarios
INFO 331
Network Design
82
Flow Models
Model the flows using common examples
Peer-to-peer
Client-server
Hierarchical client-server
Distributed computing
These models differ in directionality (or lack

thereof), hierarchy, and interconnectivity
INFO 331
Network Design
83
Peer-to-Peer Flow Model
All users or apps

are equal
Flows are all
critical or none are
Flows are all
equivalent (have
same
specification)
INFO 331
Network Design
84
Client-Server Flow Model
Requests are small data amounts compared

to responses, so these flows are asymmetric
toward the clients
ERP, video editing, and
web apps often
follow this model
INFO 331
Network Design
85
Hierarchical Client-Server
INFO 331
Network Design
86
Distributed Computing
Behavior varies inverse client-server,

peer-to-peer,
hybrid, etc.
INFO 331
Network Design
87
Flow Prioritization
Flows are typically prioritized based on many

factors, only a couple of which are technical
INFO 331
Capacity, delay, RMA, and/or QoS requirements

Security requirements
Number of users or apps affected by each flow
Business or political objectives, and the impact
of the flow on the customers business
Who pays for it!
Network Design
88
Flow Specification
Like the requirements, the flows can be

summarized in a specification of some kind
Critical for identifying priorities, in case
everyone cant be happy with your design
Balancing flow requirements can be done
with a flowspec algorithm
INFO 331
Best effort algorithms only consider capacity

Predictable flow reqts consider capacity, delay,
and RMA
Guaranteed flow reqts are treated separately
Network Design
89
Network Architecture
Now that we FINALLY have requirements

and flows defined, we can consider how all
this will affect the architecture of our network
The architecture of a house needs many
views to understand not only the exterior
appearance, but also where the wires run,
where the pipes are, ductwork for heating
and cooling, etc.
INFO 331
Similarly, we need several views of a network

Network Design
90
Avoid thinking of just the physical

components of a network (routers, hubs, etc.)
Think of the functions its performing
(addressing, routing, security, network
management, performance) as an integral
part of the components
INFO 331
E.g. routing or switching can be affected by

security
So think of functional entities, not just HW
Network Design
91
Measure network success by how well user,

app, and device reqts are met functionally
Also connects easier to traffic flows

And scales well to large networks
Each function will be defined by a component

architecture; combine them to get the overall
reference architecture
INFO 331
See house analogy a couple slides back

Network Design
92
The design of a network is more detailed,

technology- and location-specific description
than its architecture
Component architectures describe the
hardware and software mechanisms needed
to make a type of function work
INFO 331
Each component is sort of a subsystem; so well

need to understand how they work together
Network Design
93
Network Functions
The key functions are
Addressing and routing

Network management
Performance
Security
Functions may also include storage and

infrastructure, but well focus on other ones
Making this work may require trade-offs!
INFO 331
Network Design
94
Basic Design Rules: Regions
Divide the network into regions, based on

similar traffic flows
INFO 331
Edges (access regions) are where flows start

or stop
Distribution regions are where flows collect and
terminate (app or storage servers)
Core (backbone) regions let collections of flows
pass through
External interfaces (DMZs) collect flows leaving
or entering the network from outside
Network Design
95
Addressing/Routing
Addressing applies MAC or IP addresses

for devices
Routing establishes connectivity within and
between networks
This component architecture defines how
user and management flows are forwarded,
and how hierarchy & interconnectivity are
balanced in subnets
INFO 331
Network Design
96
Addressing/Routing
Mechanisms for this architecture could be
Addressing: subnetting, supernetting, dynamic vs

private addressing, VLANs, IP v4 versus v6, NAT
Routing: CIDR, mobile IP, multicast, and various
routing protocols (BGP, RIP, etc.), establish
routing policies
Notice at the architecture level were just

choosing the types of mechanisms, not
deciding exact structures
INFO 331
Network Design
97
Network Management Arch.
This decides how the network will be

monitored and managed
Types of mechanisms include
INFO 331
Monitoring, instrumentation, configuration,

security management components, does mgmt
data flow in band or out?, how centralized is
mgmt?, mgmt capacity needs, duplicate mgmt
mechanisms, MIB selection
Network Design
98
Performance Architecture
This component defines how network

performance will be established and
managed
INFO 331
Defines how network resources are allocated

to users, apps, and devices
Capacity planning, traffic engineering, QoS,
access control, SLAs, policies, resource mgmt
Balances end-to-end vs per-link prioritization
DiffServ vs IntServ
Network Design
99
Security Architecture
How do you protect system resources and

data from theft, damage, DoS, and
unauthorized access?
VPN, encryption, firewalls, routing filters, NAT

Threat analysis, physical vs app security
Define security zones (cells) for different

levels of security
Affects how other architectural components
can interact with each other
INFO 331
Network Design
100
Reference Architecture
All these components need to be reconciled

with each other
Can add key reqts and chosen mechanisms to

flow diagram
Prioritize mechanisms and how they interact
The Reference Architecture is the collection

of all the component architectures
INFO 331
Network Design
101
Reference Architecture
Reqts
dictate
which
components
are favored,
if any
INFO 331
Network Design
102
Architectural Models
Models for network architecture can be based

on topology, flow, or functionality
Generally more than one model is needed

Often start with topology model and add other(s)
Topology models are mainly
INFO 331
The WAN/MAN/LAN model basic hierarchical

structure
The core/distribution/access model think of
getting videos from CNN
Network Design
103
Topology Models
INFO 331
Network Design
104
Flow Models
Weve already seen these (slides 84-87)
INFO 331
Peer-to-peer
Client-server
Hierarchical client-server
Distributed-computing
Network Design
105
Functionality Models
These models focus on supporting key

functions in the network
Service-provider like an ISP

Intranet/Extranet focus on security and privacy
Single-tier/Multi-tier Performance where flows
indicate different levels of performance needs
End-to-end Models where a single flow is critical
to understand and fulfill
These all require knowing location data
INFO 331
Network Design
106
Service provider
and intranet/
extranet models
INFO 331
Network Design
107
No cartoon for single- or multi-tier model;

could be a combination of the others
End-to-end model
INFO 331
Network Design
108
Applying Models
The flow and functional models overlap in

focus with the core/distribution/access model
INFO 331
Network Design
109
System Architecture
The network (reference) architecture

connects to the rest of the organization
Related components and functions may include

storage, clients and servers, databases, etc.
How much detail outside of networking you

include is up to the context of your problem
INFO 331
Network Design
110
Selecting Technologies
After the types of mechanisms in the

reference architecture have been selected,
we can start choosing more specific design
technologies for our network
This is where most people start network design
Technologies need to be consistent with the

goals of the network
INFO 331
What is most important cost, capacity, QoS,

security, manageability?
Network Design
111
The goals may be different in different parts

of the network
Consider having a primary goal and one or
more secondary goals
Consider graphs to show tradeoffs
Based on the flow requirements, how do

you evaluate candidate technologies?
INFO 331
RMA, capacity, cost, performance, supportability,

etc. can be your basis for judging technologies
Network Design
112
Consider a car-buying analogy; if youre

buying a car, you might consider many
characteristics to make your choice
Cost, performance, appearance, safety, comfort,

load capacity, handling, reputation, reliability, etc.
Here we look to the flowspec and reference

architecture for the relative importance of
each desirable characteristic
INFO 331
Network Design
113
Consider also design and configuration

issues for technology, not just price-vsperformance
For example, many older technologies have
built-in ARP capability
Ethernet, Token Ring, and FDDI all do this
But newer non-broadcast multiple access

(NBMA) technologies dont have this
INFO 331
ATM, frame relay, SMDS, HiPPI

Network Design
114
As a result, using NBMA technologies

requires separate support for broadcast
and multicast
Also consider how autonomous systems
(ASs) are being formed and managed
What kinds of connections are maintained
in the network?
INFO 331
Stateless, hard state, or soft state

Connections require more work from the network
Network Design
115
Technology Functions
What features and functions will each

technology offer to users, apps, and devices?
Does it depend on the local infrastructure?

Are flows asymmetric, like Web access?
Are there distance limitations?
INFO 331
HFC and DSL both take advantage of this

Affects delay time, buffering, reliability needs, and HW
Network Design
116
Performance Upgrades
How easily can your design be upgraded?
Generally focus on capacity, but delay and RMA

may be affected too
For examples, SONET optical carrier (OC) levels

can be easily upped in capacity for ATM or HiPPI
INFO 331
SONET Level
OC-3
OC-12
OC-48
OC-192
OC-768
Rate
155.52 Mb/s
622 Mb/s
2.488 Gb/s
9.953 Gb/s
39.812 Gb/s
Network Design
117
Performance Upgrades
Technology Maximum Capacity
Ethernet
10 Mb/s
100 Mb/s
1 Gb/s
Token Ring 4 Mb/s
16 Mb/s
100 Mb/s
ATM
T3
45 Mb/s
Maximum Throughput
39 Mb/s
8095 Mb/s
700980 Mb/s
4 Mb/s
16 Mb/s
80100 Mb/s
OC-3c
155 Mb/s
120135 Mb/s
OC-48
2.5 Gb/s
2.12.35 Gb/s
HiPPI
34 Mb/s
800 Mb/s
1.6 Gb/s
6.4 Gb/s
Frame relay 45 Mb/s
ADSL
Up to 1.5 Mb/s, depending on service level
INFO 331
350750 Mb/s
0.51.4 Gb/s
1.86 Gb/s
45 Mb/s
Up to 1.5 Mb/s, depending on service level
Network Design
118
Flow Considerations
The flow spec should help tell which flows

have similar requirements, and which need
special consideration for performance,
capacity, or other needs
INFO 331
Find backbone flows, which collect smaller flows

Capacity planning is based on estimating usage,
to compare against available technologies
Service planning also compares levels of
service needed
Network Design
119
Guidelines for Tech Eval
Use combined capacities for best-effort flows

(generic Internet), and RMA, capacity, and/or delay
requirements for predictable or guaranteed services
INFO 331
Guideline 1: If predictable and/or guaranteed requirements

are listed in the flow specification (service plan), then either
the technology or a combination of technology and
supporting protocols or mechanisms must support these
requirements. This guideline restricts the selection of
candidate technologies to those that can support
predictable and/or guaranteed requirements.
Network Design
120
For examples which are technologydependent, for predictable service:
Quality-of-service levels in ATM

Committed information rate levels in frame relay
Differentiated service or integrated service levels
in IP
Guaranteed service gets even messier!
INFO 331
Network Design
121
Guideline 2: When best-effort, predictable,

and/or guaranteed capacities are listed in the
flow specification, the selection of technology
may also be based on capacity planning for
each flow. Capacity planning uses the
combined capacities from the flow
specification to select candidate
technologies, comparing the scalability of
each technology to capacity and growth
expectations for the network.
INFO 331
Network Design
122
Specific flows in the flow spec can be

mapped to the best technology solution
INFO 331
Constraints in terms of RMA, delay, cost or QoS

can be used to eliminate technologies
Interaction with existing networks needs to be
checked for possible conflicts
Facility or other large scale issues may need to
be addressed too
Network Design
123
Segmenting the Network
Now that we have nailed down technology

choices, we can address the detailed
structure of the network how its segmented
Segmenting focuses technology selection
We could do it by geography, groups of users

(even virtual), or flow hierarchy
INFO 331
Groups of users could belong to different

organizations would that be a problem for
security or privacy?
Network Design
124
A geographic example of segmenting
INFO 331
Network Design
125
A user-based view of segmenting
INFO 331
Network Design
126
A flow hierarchy-based example
INFO 331
Network Design
127
Segments can include defining broadcast

domains, collision domains, or the scope of
autonomous systems (ASs)
Really large networks can be segmented by
the type of functions and features involved in
each segment (WAN, MAN, LAN, specialized
equipment areas, core business areas, etc.)
INFO 331
Network Design
128
Segmenting by types of function and feature
INFO 331
Network Design
129
Black Box Method
Once segments have been defined, we can

view each segment as black box(es)
INFO 331
Know inputs and outputs, and dont worry about

the inner details yet
A segment could have several black boxes
Network Design
130
Black Box Method
Then for each black box, determine the exact

technology needs within it
This lets us hide irrelevant information, and
focus our technology decisions on critical info
Naturally we dont want to have all
technology decisions made in a vacuum, or
wildly different or incompatible technologies
may be chosen
INFO 331
Common sense should prevail!

Network Design
131
Summary
Network design needs to understand and

balance requirements from network users,
applications, devices, and the external
environment
Flow analysis helps capture capacity, delay,
QoS, reliability, and other critical aspects
Then technology choices can be made based
on segmenting the network by geography,
user, flow spec, or functions provided
INFO 331
Network Design
132

331 Network Design

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

331 Network Design

Diunggah oleh

Hak Cipta:

Format Tersedia

INFO 331

Through the Kurose text weve covered

The application, transport, network, & link layers

Ok, thats not a small question well just

McCabe, James D. (2003). Network Analysis,

Network Design Objective

Ultimately, our network design must answer

What stuff do we get for the network?

Traditionally this meant mostly capacity

May be effective, but result in over engineering

Network Design Objective

And while some uses of the network will need

Possible wireless connectivity

Considering both internal and external threats

Like speed for a car, how much are you willing

Network Design Phases

Theres lots of room for refining these

Identify customer requirements

Two Main Principles

For a network design to work well, we need

Hierarchy how much network traffic flows

Like tiers on an org chart, hierarchy provides

Interconnectivity offsets hierarchy by allowing

Two Main Principles

The 80/20 rule applies here

80% of the cost of a network is its operation

So plan for easy operation, maintenance,

Yes, determining the requirements for a

And that may be why many networks are poorly

We need to develop the low level design and

Is that $2 million network backbone really enough

Part of this process is managing the

They may expect a much simpler or more

We need to use a systems approach for

The system goes far beyond the network

How do these need to interact?

Consider how devices communicate

Images from (McCabe, 2003)

What services are expected from the

Typical performance levels might include

Functions include security, accounting,

Providing 1.5 Mb/s peak capacity to a remote user

Defining a security or privacy level for a group of users

Capacity refers to the ability to transfer data

Bandwidth is the theoretical capacity of some part

Kind of like hard drive actual capacity is always less

Given these concepts, how do we describe

Network requirements (often have high, medium,

Requirements can come from many aspects

User requirements are

What is fast enough

What types of apps are we using?

How sensitive are apps to RMA (reliability,

What groups of apps are being used?

Telemetry/command and control - remote devices

Where are the

What kinds of devices are on your network?

Generic computing devices include normal PCs,

We want an understanding of the devices

Device I/O rates

Performance results from many factors

Storage performance, that is, flash, disk drive,

Network requirements (sounds kinda