331 Network Design

INFO 331 Network Design 1
INFO 331
Computer Networking
Technology II
Network Design Intro

Glenn Booker
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?
Network Design
Ok, thats not a small question well just
tickle the surface (not even scratch!)
Main resources for this section are:
McCabe, James D. (2003). Network Analysis,
Architecture & Design (2
nd
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 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
May be effective, but result in over engineering
Network Design Objective
And while some uses of the network will need
a lot of bandwidth (multimedia), we may also
need to address:
Security
Considering both internal and external threats
Possible wireless connectivity
Reliability and/or availability
Like speed for a car, how much are you willing
to afford?
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)
Systems Methodology
Theres lots of room for refining these
sections (Teare, 2004)
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
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
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
Two Main Principles
(McCabe, 2003)
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
Requirements? Booooring!
Yes, determining the requirements for a
network probably isnt as much fun as
shopping for really expensive hardware
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
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)
Is that $2 million network backbone really enough
to meet our needs?
How do we know $500,000 wouldnt have been
good enough?
Requirements
Part of this process is managing the
customers expectations
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

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?
Requirements
Consider how devices communicate
Images from (McCabe, 2003)
unless noted otherwise
Requirements
What services are expected from the
network?
Typical performance levels might include
capacity, delay time, reliability
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
Functions include security, accounting,
scheduling, management
Defining a security or privacy level for a group of users
or an organization
Requirements
Service requirements
could include the
QoS (quality of
service) guarantees
(ATM, Intserv,
Diffserv, etc.)
This connects to
network management
monitoring of network
performance
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.
Kind of like hard drive actual capacity is always less
than advertised, due to formatting

Requirements Analysis
Given these concepts, how do we describe
requirements for a network?
Need a process to filter or classify
requirements
Network requirements (often have high, medium,
low priorities)
Future requirements (planned upgrades)
Rejected requirements (remember for future ref.)
Informational requirements (ideas, not required)
Requirements Analysis
Requirements can come from many aspects
of the network system
User Requirements
Application Requirements
Device Requirements
Network Requirements
Other Requirements
User Requirements
User requirements are
often qualitative and
very high level
What is fast enough
for download? System
response (RTT)?
How good does video
need to be?
Whats my budget?
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?
What groups of apps are being used?
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
Where are the
apps located?
Are some only
used in certain
locations?
Device Requirements
What kinds of devices are on your network?
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), industry-
specific devices, networked devices (cameras,
tools), stoplights, ATMs, etc.
Device Requirements
Specialized
devices are
often location-
specific
Device Requirements
We want an understanding of the devices
performance its ability to process data from
the network
Device I/O rates
Delay time for performing a given app function
Device Requirements
Performance results from many factors
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
Device Requirements
The device
locations are also
critical
Often generic
devices can be
grouped by their
quantity
Servers and
specialized stuff are
shown individually
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
Issues with network integration include
Scaling dependencies how will the size of the
existing network affect the new one?
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, system, and support service
dependencies
Addressing, security, routing protocols and network
management can all be affected by the existing
network
Interoperability dependencies
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 management and security issues
need to be addressed throughout
development
How will the network be monitored for events?
Monitoring for network performance?
What is the hierarchy for management data flow?
Network configuration?
Troubleshoot support?
Security
analysis can
include the
severity
(effect) of
an attack,
and its
probability
of
occurrence
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
Other Requirements
Requirements can come from other outside
sources your customer, legal requirements,
larger scale organization (enterprise)
requirements, etc.
Additional requirements can include
Operational suitability how well can the
customer configure and monitor the system?
Supportability how well can the customer
maintain the system?
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
This is a good reason to present the customer with
design choices, so they see the impact of cost
versus performance
Other Requirements
Enterprise requirements typically include
integration of your network with existing
standards for voice, data, or other protocols

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)
Requirements Specification
ID/Name Date Type Description Gathered/Derived Locations Status Priority
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
Mapping can
show graphically
where stuff is,
what kind of
apps are used,
and existing
connectivity
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
Gather and List Requirements
A great starting point is the very beginning
What initial conditions are you facing?
What type of project is this?
New network, Modifying an existing network,
Analysis of network problems, Outsourcing,
Consolidation, Upgrade
What is the overall scope of the project?
Network size, Number of sites, Distance between sites
Initial Conditions
Why is the network being designed? What
are the goals for its architecture & design?
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
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?
The former is easier to handle, of course

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
Surveys, phone calls, personal meetings, and/or
group discussions could be used
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
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
Service Metrics
Service metrics are characteristics measured
or derived from the network
Metrics must be configurable, measurable, and
verifiable
RMA metrics might include
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
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:
Data rates peak data rate, sustained data rate,
and minimum data rate
Data sizes burst sizes and durations
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)
Service Metrics
MIB Variables often used as service metrics:
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
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
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
How many users, how frequently, how long per
session, how much data they use
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
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)
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
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
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
Delay Requirements
Various delays can have a strong impact on
network requirements
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 noticeable to a user
Network propagation delay is how long it takes for
a command to cross the network and get the reply
Delay Requirements
INTD and
HRT help
distinguish
burst from
bulk apps
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

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
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
Typical App Capacity Needs
Application Average Completion
Time (Seconds)
Average Data
Size (Bytes)
Distributed Computing
(Batch Mode)
10
3
10
7

Web Transactions 10 10
4

Database
Entries/Queries
25 10
3

Payroll Entries 10 10
2

Teleconference 10
3
10
5

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
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
How often are manual network adjustments
needed?
How often does network configuration change?
How much monitoring is automated?
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
Supportability
Can the networks level of performance be
sustained over time?
Is affected by
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
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)
Supportability
Workforce should be equivalent to the ones
being replaced; or at least as cheap overall
Documentation typically includes
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
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
How much are you will to invest in parts?
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)
Supportability
Level Tools and Test
Equipment
Corrective
Maintenance
Preventive
Maintenance
Organizational Common tools
Operator consoles
and controls
Inexpensive special
tools
Day-to-day
monitoring
Troubleshooting
Fault isolation
Reconfiguring
system
Monitoring
performance Minor
on-site cleaning and
adjustments
Intermediate Special or expensive
portable tools with
limited use
On-site repair of
offline equipment
Major on-site
upgrades
Supplement
operators
Depot Equipment to
refurbish
components
Overhaul and
refurbishment
Scheduled overhaul
or disassembly of
LRUs
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)
Ping might be used to measure losses

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
May lead to high QoS requirements, since best
effort may not be good enough
Map and Spec
Then, as mentioned earlier, map out the
requirements, and write them in a
specification
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
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.
Source and/or destination addresses
Type of information
Directionality (bidirectional or unidirectional)
Other aspects, such as QoS needs
Flow Analysis
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
Flow Characteristics
Performance
Requirements
Capacity (e.g., Bandwidth)
Delay (e.g., Latency)
Reliability (e.g., Availability)
Quality of Service Levels
Importance/
Priority
Levels
Business/Enterprise/Provider
Political
Other
Directionality
Common Sets of Users,
Applications, Devices
Scheduling (e.g., Time-of-
Day)
Protocols Used
Addresses/Ports
Security/Privacy Requirements
Flow Analysis
Flows can be
individual, or
grouped into
composites
Flows can be
critical (and
often drive
architecture
and design)
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
Flow Analysis
Consolidate Flows
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

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
Peer-to-Peer Flow Model
All users or apps
are equal
Flows are all
critical or none
Flows are all
equivalent (have
same
specification)
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
Hierarchical Client-Server
Distributed Computing
Behavior varies inverse client-server,
peer-to-peer,
hybrid, etc.
Flow Prioritization
Flows are typically prioritized based on many
factors, only a couple of which are technical
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!
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
Best effort algorithms only consider capacity
Predictable flow reqts consider capacity, delay,
and RMA
Guaranteed flow reqts are treated separately
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.
Similarly, we need several views of a network
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
E.g. routing or switching can be affected by
security
So think of functional entities, not just HW
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
See house analogy a couple slides back
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
Each component is sort of a subsystem; so well
need to understand how they work together
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!
Basic Design Rules: Regions
Divide the network into regions, based on
similar traffic flows
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
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
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
Network Management Arch.
This decides how the network will be
monitored and managed
Types of mechanisms include
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
Performance Architecture
This component defines how network
performance will be established and
managed
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
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
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
Reference Architecture
Reqts dictate
which
components
are favored, if
any
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
The WAN/MAN/LAN model basic hierarchical
structure
The core/distribution/access model think of
getting videos from CNN
Topology Models
Flow Models
Weve already seen these (slides 84-87)
Peer-to-peer
Client-server
Hierarchical client-server
Distributed-computing
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

Service provider
and intranet/
extranet models
No cartoon for single- or multi-tier model;
could be a combination of the others
End-to-end model
Applying Models
The flow and functional models overlap in
focus with the core/distribution/access model
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

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
What is most important cost, capacity, QoS,
security, manageability?
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?
RMA, capacity, cost, performance, supportability,
etc. can be your basis for judging technologies
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
Consider also design and configuration
issues for technology, not just price-vs-
performance
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
ATM, frame relay, SMDS, HiPPI
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?
Stateless, hard state, or soft state
Connections require more work from the network
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?
HFC and DSL both take advantage of this
Are there distance limitations?
Affects delay time, buffering, reliability needs, and HW

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
(High Performance Parallel Interface pre SCSI)
SONET Level Rate
OC-3 155.52 Mb/s
OC-12 622 Mb/s
OC-48 2.488 Gb/s
OC-192 9.953 Gb/s
OC-768 39.812 Gb/s
Performance Upgrades
Technology Maximum Capacity Maximum Throughput
10 Mb/s 39 Mb/s
100 Mb/s 8095 Mb/s
1 Gb/s 700980 Mb/s
4 Mb/s 4 Mb/s
16 Mb/s 16 Mb/s
100 Mb/s 80100 Mb/s
ATM
800 Mb/s 350750 Mb/s
1.6 Gb/s 0.51.4 Gb/s
6.4 Gb/s 1.86 Gb/s
Frame relay 45 Mb/s 45 Mb/s
ADSL Up to 1.5 Mb/s, depending on service level Up to 1.5 Mb/s, depending on service level
HiPPI
OC-3c 155 Mb/s 120135 Mb/s
OC-48 2.5 Gb/s 2.12.35 Gb/s
Token Ring
T3 45 Mb/s 34 Mb/s
Ethernet
Flow Considerations
The flow spec should help tell which flows
have similar requirements, and which need
special consideration for performance,
capacity, or other needs
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
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
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.
Guidelines for Tech Eval (1)
For examples which are technology-
dependent, 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!
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.
Specific flows in the flow spec can be
mapped to the best technology solution
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

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
Groups of users could belong to different
organizations would that be a problem for
security or privacy?
A geographic example of segmenting
A user-based view of segmenting
A flow hierarchy-based example
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.)
Segmenting by types of function and feature
Black Box Method
Once segments have been defined, we can
view each segment as black box(es)
Know inputs and outputs, and dont worry about
the inner details yet
A segment could have several black boxes
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
Common sense should prevail!
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

331 Network Design

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

331 Network Design

Uploaded by

Copyright:

Available Formats

INFO 331 Network Design 1

You might also like