Anda di halaman 1dari 132

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:

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.
INFO 331

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

May be effective, but result in over engineering


INFO 331

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

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?
INFO 331

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)

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
INFO 331

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

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
INFO 331

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

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
INFO 331

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)

Is that $2 million network backbone really enough


to meet our needs?
How do we know $500,000 wouldnt have been
good enough?
INFO 331

Network Design

12

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

INFO 331

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

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
INFO 331

Network Design

16

Requirements
Service

requirements
could include the
QoS (quality of
service) guarantees
(ATM, Intserv,
Diffserv, etc.)

This connects to
network management
monitoring of network
performance
INFO 331

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.

Kind of like hard drive actual capacity is always less


than advertised, due to formatting

INFO 331

Network Design

18

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)
INFO 331

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

What is fast enough


for download? System
response (RTT)?
How good does video
need to be?
Whats my budget?
INFO 331

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?

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
INFO 331

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?

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.
INFO 331

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

Device I/O rates


Delay time for performing a given app function

INFO 331

Network Design

27

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
INFO 331

Network Design

28

Device Requirements
The

device
locations are also
critical

Often generic
devices can be
grouped by their
quantity
Servers and
specialized stuff are
shown individually
INFO 331

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

Scaling dependencies how will the size of the


existing network affect the new one?

with network integration include

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
INFO 331

Network Design

31

Network Requirements

Network, system, and support service


dependencies

Interoperability dependencies

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?
INFO 331

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?

What is the hierarchy for management data flow?

Network configuration?
Troubleshoot support?
INFO 331

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

Operational suitability how well can the


customer configure and monitor the system?
Supportability how well can the customer
maintain the system?
INFO 331

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

This is a good reason to present the customer with


design choices, so they see the impact of cost
versus performance
INFO 331

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

Date

Type

INFO 331

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?

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

INFO 331

Network Design

42

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
INFO 331

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?

The former is easier to handle, of course

INFO 331

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

Surveys, phone calls, personal meetings, and/or


group discussions could be used
INFO 331

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

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
INFO 331

Network Design

48

Service Metrics
Related

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

RMA metrics include

metrics for capacity include:

Data rates peak data rate, sustained data rate,


and minimum data rate
Data sizes burst sizes and durations
INFO 331

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:

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
INFO 331

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

How many users, how frequently, how long per


session, how much data they use
INFO 331

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

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
INFO 331

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

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

INFO 331

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

How often are manual network adjustments


needed?
How often does network configuration change?
How much monitoring is automated?
INFO 331

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

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
INFO 331

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

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
INFO 331

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

How much are you will to invest in parts?


INFO 331

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)

Ping might be used to measure losses


INFO 331

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

May lead to high QoS requirements, since best


effort may not be good enough
INFO 331

Network Design

74

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

INFO 331

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

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
INFO 331

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

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!

INFO 331

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

Best effort algorithms only consider capacity


Predictable flow reqts consider capacity, delay,
and RMA
Guaranteed flow reqts are treated separately
INFO 331

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.

Similarly, we need several views of a network


INFO 331

Network Design

90

Network Architecture
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
INFO 331

Network Design

91

Network Architecture
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


INFO 331

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

Each component is sort of a subsystem; so well


need to understand how they work together
INFO 331

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

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
INFO 331

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

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

INFO 331

Network Design

98

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
INFO 331

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

The WAN/MAN/LAN model basic hierarchical


structure
The core/distribution/access model think of
getting videos from CNN
INFO 331

Network Design

103

Topology Models

INFO 331

Network Design

104

Flow Models
Weve

already seen these (slides 84-87)

Peer-to-peer
Client-server
Hierarchical client-server
Distributed-computing

INFO 331

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

What is most important cost, capacity, QoS,


security, manageability?
INFO 331

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?

RMA, capacity, cost, performance, supportability,


etc. can be your basis for judging technologies
INFO 331

Network Design

112

Selecting 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
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 dont have this

ATM, frame relay, SMDS, HiPPI


INFO 331

Network Design

114

Selecting Technologies
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
INFO 331

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?

HFC and DSL both take advantage of this

Are there distance limitations?

Affects delay time, buffering, reliability needs, and HW

INFO 331

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

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
INFO 331

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

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
INFO 331

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

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.

INFO 331

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

INFO 331

service gets even messier!

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

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

INFO 331

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

Groups of users could belong to different


organizations would that be a problem for
security or privacy?
INFO 331

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 (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 the Network


Segmenting

INFO 331

by types of function and feature

Network Design

129

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

INFO 331

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

Common sense should prevail!


INFO 331

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

Anda mungkin juga menyukai