Transcript Network design intro

INFO 331
Computer Networking
Technology II
Network Design Intro
Glenn Booker
INFO 331
Network Design
1
Network Design

Through the Kurose text we’ve 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
2
Network Design


Ok, that’s not a small question – we’ll 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
3
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
4
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
5
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
6
Systems Methodology

There’s 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
7
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
8
Two Main Principles
(McCabe, 2003)
INFO 331
Network Design
9
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 isn’t 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 we’ve
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 wouldn’t have been
good enough?
Network Design
12
Requirements

Part of this process is managing the
customer’s 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?
What’s my budget?
Network Design
21
Application Requirements

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
Application Requirements

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
Application Requirements


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 device’s
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


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
Network Requirements

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 Requirements

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 Requirements

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
Network Requirements

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
Requirements Spec and Map



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 Spec and Map

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 there’s 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 system’s
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
1
LAN Delay
Between NM Device and Each Router in LAN
Ping
2
WAN Delay 1
Between NM Device and Local Router Interface to WAN
Ping
3
WAN Delay 2
Between NM Device and Remote Router Interface to WAN
Ping
4
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


That’s 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 doesn’t 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


We’ve 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 it’s 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 what’s 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
2–5
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 it’s
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 network’s 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, it’s 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 don’t 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 customer’s 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 can’t 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 req’ts consider capacity, delay,
and RMA
Guaranteed flow req’ts 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
Network Architecture


Avoid thinking of just the physical
components of a network (routers, hubs, etc.)
Think of the functions it’s 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
Network Architecture

Measure network success by how well user,
app, and device req’ts 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
Network Architecture


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 we’ll
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 we’ll 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 we’re 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 req’ts 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

Req’ts
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

We’ve 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
Functionality Models

Service provider
and intranet/
extranet models
INFO 331
Network Design
107
Functionality Models


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
Selecting Technologies




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
Selecting Technologies

Consider a car-buying analogy; if you’re
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
Selecting Technologies


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 don’t have this

INFO 331
ATM, frame relay, SMDS, HiPPI
Network Design
114
Selecting Technologies



As a result, using NBMA technologies
requires separate support for broadcast
and multicast
Also consider how autonomous systems
(AS’s) 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
3–9 Mb/s
80–95 Mb/s
700–980 Mb/s
4 Mb/s
16 Mb/s
80–100 Mb/s
OC-3c
155 Mb/s
120–135 Mb/s
OC-48
2.5 Gb/s
2.1–2.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
350–750 Mb/s
0.5–1.4 Gb/s
1.8–6 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
Guidelines for Tech Eval

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
Guidelines for Tech Eval

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
Guidelines for Tech Eval

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 it’s 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
Segmenting the Network

A geographic example of segmenting
INFO 331
Network Design
125
Segmenting the Network

A user-based view of segmenting
INFO 331
Network Design
126
Segmenting the Network

A flow hierarchy-based example
INFO 331
Network Design
127
Segmenting the Network


Segments can include defining broadcast
domains, collision domains, or the scope of
autonomous systems (AS’s)
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 the Network

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 don’t 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 don’t 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