1

EENG 6014, Advanced

Telecommunications Engineering

4. Optimal Network Design of

Communication Networks

Yihenew Wondie (Dr. Eng.)

May, 2016
BiT
 Outline
2

 Traffic Networks Vs. Transport Networks

 Network Resource and Cost
 Network Demand
 Traffic in Telephone Network
 Logical Vs. Physical Network View
 Network Management Time Scale
 Topological Design
 Comprehensive Topological Design
 Towards IP Multiservice Networks
 Network Integration
 From Telephone Networks to Data Networks
3

 voice calls vs. datagrams

 circuit switching vs. packet switching
 multiplexing/de-multiplexing at edge, shared network core
 Voice & Data Communication
4

 Originally, There was a Sharp Distinction:

 Voice Communication

 Data Communication, in which one or both

parties is a computer
 Database
 Electronic mail
 World Wide Web

 Distinction is fading because voice communication

is increasingly computer-based
 Circuit Switching and Reserved Capacity
5

 Circuit
capacity is reserved during duration of
each call
 At each switch Reserved
Capacity
 On each trunk line
Reserved
Capacity

Circuit
 Pros and cons of Reserved Capacity
6

 Nothing like the congestion on the Internet

 Reserved Circuit Capacity is Expensive
 Have to pay for it whether you use it or not
 Good for voice, because conversations are fairly
constant
 Bad for data, because most data transmission is
bursty; e.g., in World Wide Web, download, then
stare at screen for a long time until next download
 Packet-Switching Data Networks
7

 Packet Switching
 Large messages are broken into small pieces called
packets (or frames)

 Packetsare short (averaging a few hundred bytes)

because networking devices handle short messages
more efficiently
Message Packets
 Packet-Switching Data Networks
8

 Multiplexing
 Packets from many conversations are mixed
(multiplexed) over each trunk line

Multiplexing on
Transmission Line
Packet Switching
 Network Service Providers
9

 multiple autonomous systems (ASes) managed by different

network providers
 peering at gateway routers
 dealing with network design within one admin. domain
 Traffic Networks vs. Transport Networks
10

 Traffic Networks: provide application services

to end users
 the Internet
 telephone networks
 private networks
 Transport Networks: provide physical facility
to transport traffic for customer networks
 setting up leased circuits/trunks (semi-
permanently)
 SONET, WDM, cross connects
 Network Resource & Cost
11

 link capacity (bps, pps)

 router/switch
 memory (bytes)
 processing power (CPU, Hz)

 network cost:
 provisioning cost ($, hours)
 operational cost ($, hours)
 Network Demand
12

 traffic characteristics
 how much point to point traffic volume
 stationary+stochastic
 + where? traffic demand matrix
 different natures for different networks
 the Internet: packets
 telephone network: calls
 transport network: circuits
 demand of traffic networks generated by end users
 demand of transport network generated by its customer
traffic networks
 Traffic in Telephone Network
13

 circuit switching
 calls blocked if no available circuit
 call arrivals approximately Poisson
 call duration approximately exponential
 offered load unit -- Erlang:
 call blocking probability

 Erlang-B loss formula

 24 Erls to link with capacity 24 --> 14.6% loss

 240 Erls to link with capacity 240 --> 4.9% loss
 Demand in Transport Network
14

 demand to transport network is less dynamic

 well specified start-end time
 measured in modular data rates

Signal Name Bit Rate (Mbps)

DS0 (voice) 0.064

T1 1.54

T3 45

OC-3 155.52

OC-48 2,488.32

OC-192 9,953.28
 A Simple Design Example
15

 set up links to carry demand under link utilization

constraint of 60%.

A A A

300Kbps 300Kbps 300Kbps 300Kbps300Kbps 300Kbps

B C B C
300Kbps
B C
300Kbps 300Kbps

demand matrix three T1 links two T1 links

utili.=19.5% utili.=39%
 Logical vs. Physical Network View
16

 traffic network runs on top of

transport network
 two independent logical links
might go through same
physical link
 implications on failure
recovery, restoration, network
reliability
 multiple-layer network design
 Network Design Objective
17

 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
18

 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
19

 Designing a network is typically

broken into three sections:
 Determine requirements
 Define the overall architecture

 Choose technology and specific

devices

(McCabe, 2003)
 Systems Methodology
20

 There’s lots of room for refining these sections

(Teare, 2004)
 Identifycustomer 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
21

 For a network design to work well, we need to

balance between
 Hierarchy – how much network traffic flows connect in
tiers of organization
 Liketiers 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
22

(McCabe, 2003)
 Plan Ahead!
23

 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!
24

 Yes, determining the requirements for a network

probably isn’t 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
25

 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)
 Isthat $2 million network backbone really enough to
meet our needs?
 How do we know $500,000 wouldn’t have been good
enough?
 Requirements
26

 Part of this process is managing the customer’s

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
27

 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
28

 Consider how devices communicate

Images from (McCabe, 2003)

unless noted otherwise
 Requirements
29

 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
 Defininga security or privacy level for a group of users or
an organization
 Requirements
30

 Service requirements
could include the QoS
(quality of service)
guarantees (ATM, Intserv,
Diffserv, etc.)
 Thisconnects to network
management monitoring
of network performance
 Requirements
31

 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.
 Kindof like hard drive actual capacity is always less than
advertised, due to formatting
 Requirements Analysis
32

 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
33

 Requirements can come from many aspects of the

network system
 User Requirements
 Application Requirements

 Device Requirements

 Network Requirements

 Other Requirements
 User Requirements
34

 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?
 What’s my budget?
 Application Requirements
35

 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?
 Application Requirements
36

 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
 Application Requirements
37

 Where are the

apps located?
 Are some only
used in certain
locations?
 Device Requirements
38

 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
39

 Specialized
devices are often
location-specific
 Device Requirements
40

 We want an understanding of the device’s

performance – its ability to process data from the
network
 Device I/O rates
 Delay time for performing a given app function
 Device Requirements
41

 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
42

 The device locations

are also critical
 Often generic devices
can be grouped by
their quantity
 Servers and
specialized stuff are
shown individually
 Network Requirements
43

 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
 Network Requirements
44

 Issues with network integration include

 Scaling dependencies – how will the size of the
existing network affect the new one?
 Willthe existing network change structure, or just add on a
new wing?
 Locationdependencies – 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 Requirements
45

 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 Requirements
46

 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?
Network Requirements

 Security Effect/ Probability User Devices Servers Network Software Services Data

analysis can Unauthorized Access B/A B/B C/B A/B B/C A/B

include the Unauthorized Disclosure B/C B/B C/C A/B B/C A/B

severity Denial of Service B/B B/B B/B B/B B/B D/D

(effect) of an Theft A/D B/D B/D A/B C/C A/B

attack, and Corruption A/C B/C C/C A/B D/D A/B

its Viruses B/B B/B B/B B/B B/C D/D

probability Physical Damage A/D B/C C/C D/D D/D D/D

of occurrence Effect: Probability:

A: Destructive C: Disruptive A: Certain C: Likely

B: Disabling D: No Impact B: Unlikely D: Impossible

47
 Other Requirements
48

 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
49

 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
 Thisis a good reason to present the customer with design
choices, so they see the impact of cost
versus performance
 Other Requirements
50

 Enterprise requirements typically include integration

of your network with existing standards for voice,
data, or other protocols
 Requirements Spec and Map
51

 A requirements specification is a document which

summarizes the requirements for (here) a network
 Oftenit 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 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 Description Gathered/Derived Locations Status Priority

52
 Requirements Spec and Map
53

 Requirements
Mapping can show
graphically where
stuff is, what kind
of apps are used,
and existing
connectivity
 Requirements Analysis Process
54

 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
55

 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
56

 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
57

 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
58

 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
 Surveys, phone calls, personal meetings, and/or group
discussions could be used
 Customer and User
59

 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
60

 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
 Service Metrics
61

 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
62

 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
63

 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
64

 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
Between NM Device and Remote Router Interface to
3 WAN Delay 2 Ping
WAN
LAN Packet
4 At Each Local Router SNMP
Loss
65
 Characterizing Behavior
66

 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
 How many users, how frequently, how long per session,
how much data they use
 Characterizing Behavior
67

 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
68

 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
69

 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
 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
70

 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
71

 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
 Delay Requirements
72

 INTD and
HRT help
distinguish
burst from
bulk apps
 Delay Requirements
73

 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
 Capacity Requirements
74

 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
 Data Rates
75

 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
Typical App Capacity Needs
Application Average Completion Average Data
Time (Seconds) Size (Bytes)
Distributed Computing 103 107
(Batch Mode)
Web Transactions 10 104

Database 2–5 103

Entries/Queries
Payroll Entries 10 102

Teleconference 103 105

76
 Data Rates
77

 Sometimes a range of values is more helpful

 Processingcredit 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
78

 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
 How often are manual network adjustments needed?
 How often does network configuration change?

 How much monitoring is automated?

 Operational Suitability
79

 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
80

 Can the network’s 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
81

 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
82

 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
83

 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
84

 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 Corrective Preventive

Equipment Maintenance Maintenance

Organizational Common tools Day-to-day Monitoring

Operator consoles monitoring performance Minor
and controls Troubleshooting on-site cleaning and
Inexpensive special Fault isolation adjustments
tools Reconfiguring
system
Intermediate Special or On-site repair of Major on-site
expensive portable offline equipment upgrades
tools with limited Supplement
use operators
Depot Equipment to Overhaul and Scheduled overhaul
refurbish refurbishment or disassembly of
components LRUs

85
 Confidence
86

 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
87

 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
88

 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, it’s not critical to your customer
 Flow Analysis
89

 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.
 Source and/or destination addresses
 Type of information

 Directionality (bidirectional or unidirectional)

 Other aspects, such as QoS needs

Flow Analysis
Flow Characteristics

 Later, flows can be broken Capacity (e.g., Bandwidth)

down into subnet or link Performance Delay (e.g., Latency)

Requirements
level flows Reliability (e.g., Availability)
Quality of Service Levels
 A key purpose of flow Importance/ Business/Enterprise/Provider
analysis is to understand Priority
Levels Political

the balance between Directionality

hierarchy and Common Sets of Users,

Applications, Devices
interconnectivity needed Scheduling (e.g., Time-of-
Other Day)
Protocols Used
Addresses/Ports
Security/Privacy
Requirements
90
 Flow Analysis
91

 Flows can be
individual, or
grouped into
composites
 Flows can be
critical (and often
drive architecture
and design)
 Flow Analysis
92

 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
93
 Consolidate Flows
94
 Data Sources and Sinks
95

 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
96

 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
97

 All users or apps are

equal
 Flows are all critical
or none are
 Flows are all
equivalent (have
same specification)
 Client-Server Flow Model
98

 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
99
 Distributed Computing
100

 Behavior varies – inverse client-server,

peer-to-peer,
hybrid, etc.
 Flow Prioritization
101

 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 customer’s business
 Who pays for it!
 Flow Specification
102

 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
 Besteffort algorithms only consider capacity
 Predictable flow req’ts consider capacity, delay, and
RMA
 Guaranteed flow req’ts are treated separately
 Network Architecture
103

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

 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
 E.g.routing or switching can be affected by security
 So think of functional entities, not just HW
 Network Architecture
105

 Measure network success by how well user, app,

and device req’ts are met functionally
 Alsoconnects 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
 Network Architecture
106

 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 we’ll need
to understand how they work together
 Network Functions
107

 The key functions are

 Addressingand 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!
 Basic Design Rules: Regions
108

 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
109

 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
110

 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
 Network Management Arch.
111

 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
112

 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
113

 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
114

 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
 Reference Architecture
115

 Req’ts dictate
which
components
are favored,
if any
 Architectural Models
116

 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
117
 Flow Models
118

 We’ve already seen these (slides 84-87)

 Peer-to-peer

 Client-server

 Hierarchical client-server
 Distributed-computing
 Functionality Models
119

 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
 Functionality Models
120

 Service provider
and intranet/
extranet models
 Functionality Models
121

 No cartoon for single- or multi-tier model; could be

a combination of the others
 End-to-end model
 Applying Models
122

 The flow and functional models overlap in focus with

the core/distribution/access model
 System Architecture
123

 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
124

 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…?
 Selecting Technologies
125

 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
 Selecting Technologies
126

 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
 Selecting Technologies
127

 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 don’t have this
 ATM, frame relay, SMDS, HiPPI
 Selecting Technologies
128

 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?
 Stateless,
hard state, or soft state
 Connections require more work from the network
 Technology Functions
129

 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
130

 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
 Performance Upgrades
131

Technology Maximum Capacity Maximum Throughput

Ethernet 10 Mb/s 3–9 Mb/s
100 Mb/s 80–95 Mb/s
1 Gb/s 700–980 Mb/s
Token Ring 4 Mb/s 4 Mb/s
16 Mb/s 16 Mb/s
100 Mb/s 80–100 Mb/s
ATM
T3 45 Mb/s 34 Mb/s

OC-3c 155 Mb/s 120–135 Mb/s

OC-48 2.5 Gb/s 2.1–2.35 Gb/s

HiPPI 800 Mb/s 350–750 Mb/s

1.6 Gb/s 0.5–1.4 Gb/s
6.4 Gb/s 1.8–6 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
 Flow Considerations
132

 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
133

 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
134

 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!

 Guidelines for Tech Eval
135

 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.
 Guidelines for Tech Eval
136

 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
137

 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
 Groups of users could belong to different
organizations – would that be a problem for security
or privacy?
 Segmenting the Network
138

 A geographic example of segmenting

 Segmenting the Network
139

 A user-based view of segmenting

 Segmenting the Network
140

 A flow hierarchy-based example

 Segmenting the Network
141

 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.)
 Segmenting the Network
142

 Segmenting by types of function and feature

 Black Box Method
143

 Once segments have been defined, we can view

each segment as black box(es)
 Know inputs and outputs, and don’t worry about the
inner details yet
 A segment could have several black boxes
 Black Box Method
144

 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
 Common sense should prevail!
 Network Management Timescale
145

Time Scale Micro-secs Mili-secs Seconds Minutes Hours Days Weeks Months

Packet Discarding Call Routing, Periodic Traffic Engineering, Traffic Network

Traffic Net. Buffer Management TCP Feedback control
Call Setup, Traffic Estimation OSPF weight updates, Capacity
Packet Routing Call Admission Control, Trunk Rearrangement Expansion
Call Rerouting,
Routing Information
Update

Trans. Net. SONET/SDH ring Mesh Transport Transport Network Transport Network
restoration Network Restoration Routing/Loading Capacity
Planning/Expansion
 Network Management Cycle
146
Traffic Network (IP, circuit-switched) Transport Network
New Transport Demand,
Forecast adjustment,
Marketing input
Marketing input

traffic data Network fill

capacity expansion/ factor, loading
protection
capacity change

routing update Route loading

various controls restoration

secs-mins Real-Time Traffic Management mins-hours Near Real-Time Management

Capacity Management, Capacity Management,

days-weeks days-weeks Network Engineering
Traffic Engineering

Network Planning Network Planning

months-years months-years

Network Management Network Management

 Topological Design
147

 So far deal with link dimensioning

 links already in place
 cost increases with link capacity
 Topological Design
 long-term network planning stage
 where to place nodes/links
 installation/opening cost capacity independent
 Two Types of Topological Design
 pure location: node/link placement to achieve a desirable topology,
demand volume not in consideration
 location & flow: node/link placement+link capacity to realize demands
at minimum installation+dimensioning cost
 Joint Node Location and Link Connectivity
148

 connectivity cost
 from access nodes to core nodes
 between core nodes
 fully connected core
 two models
 one-level design
all nodes same type, each site can be
possibly a core node site (same node for
access and core): IP routers with different IP
capacities
 two-level design
access node locations and core node
locations are different: IP/MPLS

MPLS
 One-level Design
149

 N sites, select P core sites, remaining N-P access

sites connect to one of P core sites
 core site j handles kj access sites
 fully connected backbone among core sites
 all sites connected through the core backbone
 symmetric (undirected) connections
 One-level Formulation
150
 Two-level Design
151

 access sites and core sites are different

 different types of nodes on access/core sites
 N access sites
 P core sites out of M possible locations
 connection cost
 between an access site and core site
 between two core sites
 Two-level Formulation
152
 Comprehensive Topological Design
153

 traffic demand has big impact on node and link

location
 jointly design location/dimension/flow
 given access/core locations, determine link locations,
flow and capacity allocation
 given access locations only, determine core locations,
link locations, flow and capacity allocation
 access nodes represent access networks
 traffic demand between access nodes, to be
realized; pure access nodes cannot transit traffic;
 pure core nodes only transit traffic, don’t generate
traffic access node
 cost
Core/transit node
 link/node opening
 Capacity cost
 Design with Budget Constraint: optimal
network problem
154

 access/core locations
given
 link cost
 capital cost (installation)
must be under budget
 maintenance/operational
(capacity dependent) cost
to be minimized
 Simple Design Problem
155

Shortest path allocation rule: allocate all volume to cheapest path

 Towards IP Multiservice Networks
156

P2P Grid

Triple
play VoIP Support of all
services over IP
Web MmediaoIP

SERVICES

IP

INFRASTRUCTURE
IP covers the
Technology
diversity
 Examples of Internet evolutions
157

 From a data network towards a multiservice-multimedia network

 From unicast to multicast
 The usage of new lower layer technologies (IP/ATM, IP/SONET, IP/DWDM,
etc.)
 From legacy dial-up to ADSL, HFC, WLL, Wi-Fi, FTTx, PLC, satellites, etc.
 From fixed to mobile network
 From isolation towards service integration with, for example, the telephony
network: NGN architectures
 Towards the provisioning of telecommunication services for private companies:
IP VPNs
 From software based to hardware based routers architectures (Giga/Tera
routers, flow based routers, etc.)
 A very fast evolution of the structure of the traffic requiring new traffic
engineering approaches
 Switching Capacity, not an issue any more,
but MPLS still needed
162

LSR

LSR
LSR
MPLS

SDH
(??)
Customer
Premises

• Quality of Service
• Evolved VPN
• Traffic Engineering, Protection
• Multicast
 Main trends
163
R3

R1

R2

IP C3
C2
SDH
C1 C4

ATM
Rapid and Predictable Restoration
LSR Standard Time Division Multiplexing

IP and ATM integration

Label Swapping Paradigm G-MPLS SONET/SDH
Dynamic Allocation and Control?

MPLS
10Gbps

10Gbps
10Gbps

10Gbps
Increasing
10Gbps Capacity Requirements
10Gbps

OCX OCX
DWDM
Dynamic Allocation and Control?
 Interesting problems
164

 Multi-layer dynamic routing

 Multi-layer protection/restoration
 Layout optimization under variable traffic
 Extension of G-MPLS for multipoint to multipoint
connections
 Statistical multiplexing modeling issues
165

Narrowband access, high aggregation Broadband access, low aggregation

 Given the increase in broadband network access, core

network flows are sporadic and network flows do not simply
add
 Hence, need for new statistical models and related
grooming strategies
 Access Networks Evolution Context
168

 New technologies and regulatory conditions

 xDSL and Unbundling of the local loop
 HFC-Hybrid Fiber Coax
 802.11 and WiFi, 802.16 and WiMax
 Satellites (LEO/MEO/GEO)
 3rd Generation and beyond Mobile Systems
 Power Line Communication (PLC)
 FTTx, PON, Metro WDM
 Next Generation SDH rings
 Ethernet rings
 Historical non competing operators would like to compete
on every service on every market.
 Main issue: multi-technology integration
 3G and beyond Mobile Networks
169

 Cell capacity optimization and fairness in HDR/HSDPA

networks
 Back to TDMA
 Considering traffic evolution increases the capacity of the cells
 Admission control and scheduling
 Opportunistic policies

 Transport protocols for wireless and mobile networks

 Horizontal integration, All IP mobility
 Ubiquity, vertical handover and roaming
 Network Architecture Evolution, Technology
Integration, Network Control
170

 Horizontal integration
 From extremely small to immensely big
 Sensor networks, PAN, Ad-hoc networks, access to
infrastructure networks
 The IP networking model is no longer applicable
 Ubiquity, Mobility, Context Awareness, Location Based
Services
 Vertical roaming
 Seamless interworking and handover, transparent and
dynamic adaptation of the used technology
 End to End services availability in a Multi-domain
context
 Network Architecture Evolution, Technology
Integration, Network Control
171

 Vertical Integration
 Multi-layernetworks
 Unified control and management planes
 Multi-layer routing, protection, restoration, etc.
 Integrated design of physical, MAC, routing and upper
layers including innovative air interfaces, optical
packet/burst switching, etc.
 Services Overlays
 Service planes and related middlewares
 P2P, Grids, others
172