Network Security
-
Upload
rahim-contractor -
Category
Documents
-
view
53 -
download
0
description
Transcript of Network Security
![Page 1: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/1.jpg)
INFO 331 Network Design 1
INFO 331Computer Networking
Technology II
Network Design Intro
Glenn Booker
![Page 2: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/2.jpg)
INFO 331 Network Design 2
Network Design
Through the Kurose text we’ve covered The application, transport, network, & link layers Wireless and multimedia technologies Security Network management
Not bad! So how does all this come together to help
create a network?
![Page 3: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/3.jpg)
INFO 331 Network Design 3
Network Design
Ok, that’s not a small question – we’ll 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.
![Page 4: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/4.jpg)
INFO 331 Network Design 4
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
![Page 5: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/5.jpg)
INFO 331 Network Design 5
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?
![Page 6: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/6.jpg)
INFO 331 Network Design 6
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)
![Page 7: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/7.jpg)
INFO 331 Network Design 7
Systems Methodology
There’s 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
![Page 8: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/8.jpg)
INFO 331 Network Design 8
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
![Page 9: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/9.jpg)
INFO 331 Network Design 9
Two Main Principles
(McCabe, 2003)
![Page 10: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/10.jpg)
INFO 331 Network Design 10
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
![Page 11: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/11.jpg)
INFO 331 Network Design 11
Requirements? Booooring!
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
![Page 12: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/12.jpg)
INFO 331 Network Design 12
Requirements
We need to develop the low level design and the higher level architecture, and understand the environment in which they operate
We also need to prove that the design we’ve chosen is ‘just right’ (Southey, 1837) Is that $2 million network backbone really enough
to meet our needs? How do we know $500,000 wouldn’t have been
good enough?
![Page 13: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/13.jpg)
INFO 331 Network Design 13
Requirements
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
![Page 14: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/14.jpg)
INFO 331 Network Design 14
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?
![Page 15: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/15.jpg)
INFO 331 Network Design 15
Requirements
Consider how devices communicate
Images from (McCabe, 2003) unless noted otherwise
![Page 16: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/16.jpg)
INFO 331 Network Design 16
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
![Page 17: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/17.jpg)
INFO 331 Network Design 17
Requirements
Service requirements could include the QoS (quality of service) guarantees (ATM, Intserv, Diffserv, etc.) This connects to
network management monitoring of network performance
![Page 18: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/18.jpg)
INFO 331 Network Design 18
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
![Page 19: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/19.jpg)
INFO 331 Network Design 19
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)
![Page 20: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/20.jpg)
INFO 331 Network Design 20
Requirements Analysis
Requirements can come from many aspects of the network system User Requirements Application Requirements Device Requirements Network Requirements Other Requirements
![Page 21: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/21.jpg)
INFO 331 Network Design 21
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?
What’s my budget?
![Page 22: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/22.jpg)
INFO 331 Network Design 22
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?
![Page 23: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/23.jpg)
INFO 331 Network Design 23
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
![Page 24: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/24.jpg)
INFO 331 Network Design 24
Application Requirements
Where are the apps located?
Are some only used in certain locations?
![Page 25: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/25.jpg)
INFO 331 Network Design 25
Device Requirements
What kinds of devices are on your network? Generic computing devices include normal PCs,
Macs, laptops, handheld computers, workstations Servers include all flavors of server – file, print,
app/computation, and backup Specialized devices include extreme servers
(supercomputers, massively parallel servers), data collection systems (POS terminals), industry-specific devices, networked devices (cameras, tools), stoplights, ATMs, etc.
![Page 26: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/26.jpg)
INFO 331 Network Design 26
Device Requirements
Specialized devices are often location-specific
![Page 27: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/27.jpg)
INFO 331 Network Design 27
Device Requirements
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
![Page 28: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/28.jpg)
INFO 331 Network Design 28
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
![Page 29: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/29.jpg)
INFO 331 Network Design 29
Device Requirements
The device locations are also critical Often generic
devices can be grouped by their quantity
Servers and specialized stuff are shown individually
![Page 30: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/30.jpg)
INFO 331 Network Design 30
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
![Page 31: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/31.jpg)
INFO 331 Network Design 31
Network Requirements
Issues with network integration include Scaling dependencies – how will the size of the
existing network affect the new one? Will the existing network change structure, or just add
on a new wing? Location dependencies – interaction between old
and new networks could change the location of key components
Performance constraints – existing network could limit performance of the new one
![Page 32: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/32.jpg)
INFO 331 Network Design 32
Network Requirements
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?
![Page 33: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/33.jpg)
INFO 331 Network Design 33
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?
![Page 34: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/34.jpg)
INFO 331 Network Design 34
Network Requirements
Security analysis can include the severity (effect) of an attack, and its probability of occurrence
Effect/ Probability User Devices Servers Network Software Services Data
Unauthorized Access B/A B/B C/B A/B B/C A/B
Unauthorized Disclosure B/C B/B C/C A/B B/C A/B
Denial of Service B/B B/B B/B B/B B/B D/D
Theft A/D B/D B/D A/B C/C A/B
Corruption A/C B/C C/C A/B D/D A/B
Viruses B/B B/B B/B B/B B/C D/D
Physical Damage A/D B/C C/C D/D D/D D/D
Effect: Probability:
A: Destructive C: Disruptive A: Certain C: Likely
B: Disabling D: No Impact B: Unlikely D: Impossible
![Page 35: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/35.jpg)
INFO 331 Network Design 35
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?
![Page 36: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/36.jpg)
INFO 331 Network Design 36
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
![Page 37: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/37.jpg)
INFO 331 Network Design 37
Other Requirements
Enterprise requirements typically include integration of your network with existing standards for voice, data, or other protocols
![Page 38: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/38.jpg)
INFO 331 Network Design 38
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)
![Page 39: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/39.jpg)
INFO 331 Network Design 39
Requirements Spec and Map
Requirements Specification
ID/Name Date Type Description Gathered/Derived Locations Status Priority
Priority can provide additional numeric distinction within a given Status (typically on a 1-3 or 1-5 scale)
Sources for Gathering requirements can be identified, or give basis for Deriving it
Type is user, app, device, network or other
![Page 40: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/40.jpg)
INFO 331 Network Design 40
Requirements Spec and Map
Requirements Mapping can show graphically where stuff is, what kind of apps are used, and existing connectivity
![Page 41: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/41.jpg)
INFO 331 Network Design 41
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
![Page 42: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/42.jpg)
INFO 331 Network Design 42
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
![Page 43: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/43.jpg)
INFO 331 Network Design 43
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
![Page 44: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/44.jpg)
INFO 331 Network Design 44
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
![Page 45: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/45.jpg)
INFO 331 Network Design 45
Customer and User
Customer expectations need to be set quickly What order of magnitude is the project, and does
that match what they thought? Better to find out early on if there’s a big gap!
Working with users is important, to know how they use the network and what problems they find important Surveys, phone calls, personal meetings, and/or
group discussions could be used
![Page 46: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/46.jpg)
INFO 331 Network Design 46
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
![Page 47: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/47.jpg)
INFO 331 Network Design 47
Requirements Management
The requirements you develop need to be tracked and managed, just like any system’s requirements Identify requirements by some form of ID and
short name Need a tool to track requirements, their status,
changes, sources, etc. Map location of apps and devices of the
existing network
![Page 48: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/48.jpg)
INFO 331 Network Design 48
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
![Page 49: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/49.jpg)
INFO 331 Network Design 49
Service Metrics
Related RMA metrics include Uptime and downtime (percentage of total time) Error and loss rates at various levels, such as
packet error rate, bit error rate (BER), cell loss ratio (CLR), cell misinsertion ratio (CMR), frame and packet loss rates
Service metrics for capacity include: Data rates – peak data rate, sustained data rate,
and minimum data rate Data sizes – burst sizes and durations
![Page 50: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/50.jpg)
INFO 331 Network Design 50
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)
![Page 51: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/51.jpg)
INFO 331 Network Design 51
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
![Page 52: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/52.jpg)
INFO 331 Network Design 52
Metrics Tools
Tools for making service metric measurements include Ping, pathchar, traceroute, TCPdump Packet capture utilities: Ethereal, Sniffer, and Etherpeak
Then summarize the metrics collection approach
Service Metric Where Metric Will Be Measured in System Measurement Method
1 LAN Delay Between NM Device and Each Router in LAN Ping
2 WAN Delay 1 Between NM Device and Local Router Interface to WAN Ping
3 WAN Delay 2 Between NM Device and Remote Router Interface to WAN Ping
4 LAN Packet Loss At Each Local Router SNMP
![Page 53: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/53.jpg)
INFO 331 Network Design 53
Characterizing Behavior
Next we can analyze how users and apps use the existing network
We could use simulations or models to assess network behavior That’s way beyond the scope here!
User behavior is looking for patterns in how people use apps How many users, how frequently, how long per
session, how much data they use
![Page 54: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/54.jpg)
INFO 331 Network Design 54
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
![Page 55: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/55.jpg)
INFO 331 Network Design 55
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)
![Page 56: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/56.jpg)
INFO 331 Network Design 56
RMA Requirements
Availability relates failures to repair time Scheduled maintenance time doesn’t count
against availability Uptime and downtime measure those
percentages when the system is up or down 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
![Page 57: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/57.jpg)
INFO 331 Network Design 57
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
![Page 58: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/58.jpg)
INFO 331 Network Design 58
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
![Page 59: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/59.jpg)
INFO 331 Network Design 59
Delay Requirements
INTD and HRT help distinguish burst from bulk apps
![Page 60: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/60.jpg)
INFO 331 Network Design 60
Delay Requirements
End-to-end and round-trip delays can be network requirements We’ve used ping to get RTT (round trip time)
Delay variation can be defined for multimedia apps – typically is 1-2% of end-to-end delay
![Page 61: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/61.jpg)
INFO 331 Network Design 61
Capacity Requirements
Much of the needed capacity of a network derives from key applications that are especially intense in such areas Peak data rate Minimum acceptable data rate Sustained (long term) data rate
We need to distinguish apps that CAN use a lot of capacity (if it’s available), versus those that MUST use a lot
![Page 62: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/62.jpg)
INFO 331 Network Design 62
Data Rates
Data rates for an app can be measured at many levels of the protocols App, network, etc. Most TCP apps will take what’s available, but
back off when the network gets crowded (why?) Often we may need to identify where the
performance bottleneck is located It helps to get a rough idea of typical app
performance
![Page 63: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/63.jpg)
INFO 331 Network Design 63
Typical App Capacity Needs
Application Average Completion Time (Seconds)
Average Data Size (Bytes)
Distributed Computing (Batch Mode)
103 107
Web Transactions 10 104
Database Entries/Queries
2–5 103
Payroll Entries 10 102
Teleconference 103 105
![Page 64: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/64.jpg)
INFO 331 Network Design 64
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
![Page 65: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/65.jpg)
INFO 331 Network Design 65
Supplemental Performance
Other non-functional requirements can be important to a network
Operational Suitability is making sure your customer can operate the network once it’s running How often are manual network adjustments
needed? How often does network configuration change? How much monitoring is automated?
![Page 66: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/66.jpg)
INFO 331 Network Design 66
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
![Page 67: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/67.jpg)
INFO 331 Network Design 67
Supportability
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
![Page 68: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/68.jpg)
INFO 331 Network Design 68
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)
![Page 69: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/69.jpg)
INFO 331 Network Design 69
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
![Page 70: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/70.jpg)
INFO 331 Network Design 70
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?
![Page 71: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/71.jpg)
INFO 331 Network Design 71
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)
![Page 72: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/72.jpg)
INFO 331 Network Design 72
Supportability
Level Tools and Test Equipment
Corrective Maintenance
Preventive Maintenance
Organizational Common tools Operator consoles and controls Inexpensive special tools
Day-to-day monitoring Troubleshooting Fault isolation Reconfiguring system
Monitoring performance Minor on-site cleaning and adjustments
Intermediate Special or expensive portable tools with limited use
On-site repair of offline equipment
Major on-site upgrades Supplement operators
Depot Equipment to refurbish components
Overhaul and refurbishment
Scheduled overhaul or disassembly of LRUs
![Page 73: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/73.jpg)
INFO 331 Network Design 73
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
![Page 74: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/74.jpg)
INFO 331 Network Design 74
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
![Page 75: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/75.jpg)
INFO 331 Network Design 75
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, it’s not critical to your customer
![Page 76: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/76.jpg)
INFO 331 Network Design 76
Flow Analysis
The requirements map is a great place to start analysis of flows in your network We don’t want to model EVERY traffic (data) flow,
just the important ones A traffic flow describes data movement, e.g.
Source and/or destination addresses Type of information Directionality (bidirectional or unidirectional) Other aspects, such as QoS needs
![Page 77: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/77.jpg)
INFO 331 Network Design 77
Flow Analysis
Later, flows can be broken down into subnet or link level flows
A key purpose of flow analysis is to understand the balance between hierarchy and interconnectivity needed
Flow Characteristics
Performance Requirements
Capacity (e.g., Bandwidth)
Delay (e.g., Latency)
Reliability (e.g., Availability)
Quality of Service Levels
Importance/ Priority Levels
Business/Enterprise/Provider
Political
Other
Directionality
Common Sets of Users, Applications, Devices
Scheduling (e.g., Time-of-Day)
Protocols Used
Addresses/Ports
Security/Privacy Requirements
![Page 78: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/78.jpg)
INFO 331 Network Design 78
Flow Analysis
Flows can be individual, or grouped into composites
Flows can be critical (and often drive architecture and design)
![Page 79: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/79.jpg)
INFO 331 Network Design 79
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
![Page 80: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/80.jpg)
INFO 331 Network Design 80
Flow Analysis
![Page 81: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/81.jpg)
INFO 331 Network Design 81
Consolidate Flows
![Page 82: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/82.jpg)
INFO 331 Network Design 82
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
![Page 83: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/83.jpg)
INFO 331 Network Design 83
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
![Page 84: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/84.jpg)
INFO 331 Network Design 84
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)
![Page 85: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/85.jpg)
INFO 331 Network Design 85
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
![Page 86: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/86.jpg)
INFO 331 Network Design 86
Hierarchical Client-Server
![Page 87: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/87.jpg)
INFO 331 Network Design 87
Distributed Computing
Behavior varies – inverse client-server, peer-to-peer, hybrid, etc.
![Page 88: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/88.jpg)
INFO 331 Network Design 88
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 customer’s business Who pays for it!
![Page 89: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/89.jpg)
INFO 331 Network Design 89
Flow Specification
Like the requirements, the flows can be summarized in a specification of some kind
Critical for identifying priorities, in case everyone can’t be happy with your design
Balancing flow requirements can be done with a flowspec algorithm Best effort algorithms only consider capacity Predictable flow req’ts consider capacity, delay,
and RMA Guaranteed flow req’ts are treated separately
![Page 90: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/90.jpg)
INFO 331 Network Design 90
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
![Page 91: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/91.jpg)
INFO 331 Network Design 91
Network Architecture
Avoid thinking of just the physical components of a network (routers, hubs, etc.)
Think of the functions it’s performing (addressing, routing, security, network management, performance) as an integral part of the components E.g. routing or switching can be affected by
security So think of functional entities, not just HW
![Page 92: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/92.jpg)
INFO 331 Network Design 92
Network Architecture
Measure network success by how well user, app, and device req’ts are met functionally Also connects easier to traffic flows And scales well to large networks
Each function will be defined by a component architecture; combine them to get the overall reference architecture See house analogy a couple slides back
![Page 93: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/93.jpg)
INFO 331 Network Design 93
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 we’ll
need to understand how they work together
![Page 94: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/94.jpg)
INFO 331 Network Design 94
Network Functions
The key functions are Addressing and routing Network management Performance Security
Functions may also include storage and infrastructure, but we’ll focus on other ones
Making this work may require trade-offs!
![Page 95: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/95.jpg)
INFO 331 Network Design 95
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
![Page 96: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/96.jpg)
INFO 331 Network Design 96
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
![Page 97: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/97.jpg)
INFO 331 Network Design 97
Addressing/Routing
Mechanisms for this architecture could be Addressing: subnetting, supernetting, dynamic vs
private addressing, VLANs, IP v4 versus v6, NAT Routing: CIDR, mobile IP, multicast, and various
routing protocols (BGP, RIP, etc.), establish routing policies
Notice at the architecture level we’re just choosing the types of mechanisms, not deciding exact structures
![Page 98: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/98.jpg)
INFO 331 Network Design 98
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
![Page 99: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/99.jpg)
INFO 331 Network Design 99
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
![Page 100: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/100.jpg)
INFO 331 Network Design 100
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
![Page 101: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/101.jpg)
INFO 331 Network Design 101
Reference Architecture
All these components need to be reconciled with each other Can add key req’ts and chosen mechanisms to
flow diagram Prioritize mechanisms and how they interact
The Reference Architecture is the collection of all the component architectures
![Page 102: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/102.jpg)
INFO 331 Network Design 102
Reference Architecture
Req’ts dictate which components are favored, if any
![Page 103: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/103.jpg)
INFO 331 Network Design 103
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
![Page 104: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/104.jpg)
INFO 331 Network Design 104
Topology Models
![Page 105: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/105.jpg)
INFO 331 Network Design 105
Flow Models
We’ve already seen these (slides 84-87) Peer-to-peer Client-server Hierarchical client-server Distributed-computing
![Page 106: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/106.jpg)
INFO 331 Network Design 106
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
![Page 107: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/107.jpg)
INFO 331 Network Design 107
Functionality Models
Service provider and intranet/ extranet models
![Page 108: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/108.jpg)
INFO 331 Network Design 108
Functionality Models
No cartoon for single- or multi-tier model; could be a combination of the others
End-to-end model
![Page 109: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/109.jpg)
INFO 331 Network Design 109
Applying Models
The flow and functional models overlap in focus with the core/distribution/access model
![Page 110: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/110.jpg)
INFO 331 Network Design 110
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
![Page 111: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/111.jpg)
INFO 331 Network Design 111
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…?
![Page 112: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/112.jpg)
INFO 331 Network Design 112
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
![Page 113: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/113.jpg)
INFO 331 Network Design 113
Selecting Technologies
Consider a car-buying analogy; if you’re buying a car, you might consider many characteristics to make your choice Cost, performance, appearance, safety, comfort,
load capacity, handling, reputation, reliability, etc. Here we look to the flowspec and reference
architecture for the relative importance of each desirable characteristic
![Page 114: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/114.jpg)
INFO 331 Network Design 114
Selecting Technologies
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
![Page 115: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/115.jpg)
INFO 331 Network Design 115
Selecting Technologies
As a result, using NBMA technologies requires separate support for broadcast and multicast
Also consider how autonomous systems (AS’s) are being formed and managed
What kinds of connections are maintained in the network? Stateless, hard state, or soft state Connections require more work from the network
![Page 116: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/116.jpg)
INFO 331 Network Design 116
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
![Page 117: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/117.jpg)
INFO 331 Network Design 117
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
![Page 118: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/118.jpg)
INFO 331 Network Design 118
Performance Upgrades
Technology Maximum Capacity Maximum Throughput10 Mb/s 3–9 Mb/s100 Mb/s 80–95 Mb/s1 Gb/s 700–980 Mb/s4 Mb/s 4 Mb/s16 Mb/s 16 Mb/s100 Mb/s 80–100 Mb/s
ATM
800 Mb/s 350–750 Mb/s1.6 Gb/s 0.5–1.4 Gb/s6.4 Gb/s 1.8–6 Gb/s
Frame relay 45 Mb/s 45 Mb/sADSL Up to 1.5 Mb/s, depending on service level Up to 1.5 Mb/s, depending on service level
HiPPI
OC-3c 155 Mb/s 120–135 Mb/s
OC-48 2.5 Gb/s 2.1–2.35 Gb/s
Token Ring
T3 45 Mb/s 34 Mb/s
Ethernet
![Page 119: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/119.jpg)
INFO 331 Network Design 119
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
![Page 120: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/120.jpg)
INFO 331 Network Design 120
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.
![Page 121: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/121.jpg)
INFO 331 Network Design 121
Guidelines for Tech Eval
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!
![Page 122: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/122.jpg)
INFO 331 Network Design 122
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.
![Page 123: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/123.jpg)
INFO 331 Network Design 123
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
![Page 124: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/124.jpg)
INFO 331 Network Design 124
Segmenting the Network
Now that we have nailed down technology choices, we can address the detailed structure of the network – how it’s segmented Segmenting focuses technology selection
We could do it by geography, groups of users (even virtual), or flow hierarchy Groups of users could belong to different
organizations – would that be a problem for security or privacy?
![Page 125: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/125.jpg)
INFO 331 Network Design 125
Segmenting the Network
A geographic example of segmenting
![Page 126: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/126.jpg)
INFO 331 Network Design 126
Segmenting the Network
A user-based view of segmenting
![Page 127: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/127.jpg)
INFO 331 Network Design 127
Segmenting the Network
A flow hierarchy-based example
![Page 128: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/128.jpg)
INFO 331 Network Design 128
Segmenting the Network
Segments can include defining broadcast domains, collision domains, or the scope of autonomous systems (AS’s)
Really large networks can be segmented by the type of functions and features involved in each segment (WAN, MAN, LAN, specialized equipment areas, core business areas, etc.)
![Page 129: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/129.jpg)
INFO 331 Network Design 129
Segmenting the Network
Segmenting by types of function and feature
![Page 130: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/130.jpg)
INFO 331 Network Design 130
Black Box Method
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
![Page 131: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/131.jpg)
INFO 331 Network Design 131
Black Box Method
Then for each black box, determine the exact technology needs within it
This lets us hide irrelevant information, and focus our technology decisions on critical info
Naturally we don’t want to have all technology decisions made in a vacuum, or wildly different or incompatible technologies may be chosen Common sense should prevail!
![Page 132: Network Security](https://reader036.fdocuments.us/reader036/viewer/2022070400/55cf9aef550346d033a41314/html5/thumbnails/132.jpg)
INFO 331 Network Design 132
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