331 network design

INFO 331 Network Design 1

INFO 331Computer Networking

Technology II

Network Design Intro

Glenn Booker


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?


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.


Network Design Objective Ultimately, our network design must answer

some pretty basic questions What stuff do we get for the network? How do we connect it all? How do we have to configure it to work right?

Traditionally this meant mostly capacity planning – having enough bandwidth to keep data moving May be effective, but result in over engineering


Network Design Objective And while some uses of the network will need

a lot of bandwidth (multimedia), we may also need to address: Security

Considering both internal and external threats Possible wireless connectivity Reliability and/or availability

Like speed for a car, how much are you willing to afford?


Network Design Phases Designing a network is

typically broken into three sections: Determine requirements Define the overall

architecture Choose technology and

specific devices

(McCabe, 2003)


Systems Methodology 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


Two Main Principles For a network design to work well, we need

to balance between Hierarchy – how much network traffic flows

connect in tiers of organization Like tiers on an org chart, hierarchy provides

separation and structure for the network Interconnectivity – offsets hierarchy by allowing

connections between levels of the design, often to improve performance between them


Two Main Principles

(McCabe, 2003)


Plan Ahead! The 80/20 rule applies here

80% of the cost of a network is its operation and support

Only 20% is the cost of designing and implementing it

So plan for easy operation, maintenance, and upgrade of the network


Requirements? Booooring! Yes, determining the requirements for a

network probably 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 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?


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


Requirements We need to use a systems approach for

understanding the network The system goes far beyond the network

hardware, software, etc. Also includes understanding the users,

applications or services, and external environment How do these need to interact? What does the rest of the organization

expect from the network?


Requirements Consider how devices communicate

Images from (McCabe, 2003) unless noted otherwise


Requirements What services are expected from the

network? Typical performance levels might include

capacity, delay time, reliability Providing 1.5 Mb/s peak capacity to a remote user Guaranteeing a maximum round-trip delay of 100 ms

to servers in a server farm Functions include security, accounting,

scheduling, management Defining a security or privacy level for a group of users

or an organization


Requirements Service requirements

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

network management monitoring of network performance


Requirements Capacity refers to the ability to transfer data

Bandwidth is the theoretical capacity of some part of the network

Throughput is the actual capacity, which is less than the bandwidth, due to protocol overhead, network delays, etc. Kind of like hard drive actual capacity is always less

than advertised, due to formatting


Requirements Analysis Given these concepts, how do we describe

requirements for a network? Need a process to filter or classify

requirements Network requirements (often have high, medium,

low priorities) Future requirements (planned upgrades) Rejected requirements (remember for future ref.) Informational requirements (ideas, not required)


Requirements Analysis Requirements can come from many aspects

of the network system User Requirements Application Requirements Device Requirements Network Requirements Other Requirements


User Requirements User requirements are

often qualitative and very high level What is ‘fast enough’

for download? System response (RTT)?

How good does video need to be?

What’s my budget?


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?


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


Application Requirements Where are the

apps located? Are some only

used in certain locations?


Device Requirements What kinds of devices are on your network?

Generic computing devices include normal PCs, Macs, laptops, handheld computers, workstations

Servers include all flavors of server – file, print, app/computation, and backup

Specialized devices include extreme servers (supercomputers, massively parallel servers), data collection systems (POS terminals), industry-specific devices, networked devices (cameras, tools), stoplights, ATMs, etc.


Device Requirements Specialized

devices are often location-specific


Device Requirements We want an understanding of the 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 Performance results from many factors

Storage performance, that is, flash, disk drive, or tape performance

Processor (CPU) performance Memory performance (access times) Bus performance (bus capacity and arbitration

efficiency) OS performance (effectiveness of the protocol

stack and APIs) Device driver performance


Device Requirements The device

locations are also critical Often generic

devices can be grouped by their quantity

Servers and specialized stuff are shown individually


Network Requirements 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 Issues with network integration include

Scaling dependencies – how will the size of the existing network affect the new one? Will the existing network change structure, or just add

on a new wing? Location dependencies – interaction between old

and new networks could change the location of key components

Performance constraints – existing network could limit performance of the new one


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


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?


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


Other Requirements Requirements can come from other outside

sources – your customer, legal requirements, larger scale organization (enterprise) requirements, etc.

Additional requirements can include Operational suitability – how well can the

customer configure and monitor the system? Supportability – how well can the customer

maintain the system?


Other Requirements Confidence – what is the data loss rate when the

system is running at its required throughput? Financial requirements can include not only

the initial system cost, but also ongoing maintenance costs System architecture may be altered to remain

within cost constraints This is a good reason to present the customer with

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


Other Requirements Enterprise requirements typically include

integration of your network with existing standards for voice, data, or other protocols


Requirements Spec and Map A requirements specification is a document

which summarizes the requirements for (here) a network Often it becomes a contractual obligation, so

assumptions, estimates, etc. should be carefully spelled out

Requirements are classified by Status, as noted earlier (core/current, future, rejected, or informational requirement)


Requirements 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


Requirements Spec and Map Requirements

Mapping can show graphically where stuff is, what kind of apps are used, and existing connectivity


Requirements Analysis Process So, how do we

determine what the requirements are for our network?

Collect requirements service metrics, and delays to help develop and map requirements


Gather and List Requirements A great starting point is the very beginning What initial conditions are you facing?

What type of project is this? New network, Modifying an existing network,

Analysis of network problems, Outsourcing, Consolidation, Upgrade

What is the overall scope of the project? Network size, Number of sites, Distance between sites


Initial Conditions Why is the network being designed? What

are the goals for its architecture & design? Upgrade technology and/or vendor Improve performance to part or all of network Support new users, applications, or devices Solve perceived problems within system Increase security Support a new capability in system


Initial Conditions What project constraints are there?

Funding, organizations involved, existing network, facility limitations, schedule, political, etc.

Are users receptive to the new network? Are user needs homogeneous, or are there

multiple tiers of performance needs? The former is easier to handle, of course


Customer and User Customer expectations need to be set quickly

What order of magnitude is the project, and does that match what they thought?

Better to find out early on if 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 Look for red flags in early discussions

Abuse of the term "real-time" Availability as solely a percentage (99.99%) "High performance" without verification or

clarification Highly variable, inconsistent requirements Unrealistic expectations from the customer

Measure application performance using existing network (if possible) or a test bed


Requirements Management The requirements you develop need to be

tracked and managed, just like any 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 Service metrics are characteristics measured

or derived from the network Metrics must be configurable, measurable, and

verifiable RMA metrics might include

Reliability – mean time between failures (MTBFs) and mean time between mission critical failures (MTBCFs)

Maintainability – mean time to repair (MTTR) Availability – MTBF, MTBCF, and MTTR


Service Metrics Related RMA metrics include

Uptime and downtime (percentage of total time) Error and loss rates at various levels, such as

packet error rate, bit error rate (BER), cell loss ratio (CLR), cell misinsertion ratio (CMR), frame and packet loss rates

Service metrics for capacity include: Data rates – peak data rate, sustained data rate,

and minimum data rate Data sizes – burst sizes and durations


Service Metrics Service metrics for delay include:

End-to-end or round-trip delay Latency Delay variation

SNMP or CMIP (Common Management Information Protocol) can be used to configure these metrics, which are kept in the Management Information Base (MIB)


Service Metrics MIB Variables often used as service metrics:

Bytes in/out (per interface) IP packets in/out (per interface) Dropped ICMP messages per time per interface Service-level agreement (SLA) metrics (per user) Capacity limit Burst tolerance Delay Downtime


Metrics Tools Tools for making service metric measurements

include Ping, pathchar, traceroute, TCPdump Packet capture utilities: Ethereal, Sniffer, and Etherpeak

Then summarize the metrics collection approach

Service Metric Where Metric Will Be Measured in System Measurement Method

1 LAN Delay Between NM Device and Each Router in LAN Ping

2 WAN Delay 1 Between NM Device and Local Router Interface to WAN Ping

3 WAN Delay 2 Between NM Device and Remote Router Interface to WAN Ping

4 LAN Packet Loss At Each Local Router SNMP

http://ee.lbl.gov/


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


Characterizing Behavior Application behavior includes looking at how

each app uses the network Communication between client/server parts Multicast or broadcast transmissions – how often,

how big Focus on the most critical apps (mission

critical, real time, interactive, etc.) Models can be simple or complex, as project

size and time constraints dictate


RMA Requirements Reliability is a common measurement

Mean time between mission critical failure (MTBCF) focuses on failures during certain time periods, excluding planned down times

Mean time between failure (MTBF) includes failure at any time

Maintainability is typically captured with mean time to repair (MTTR)


RMA Requirements Availability relates failures to repair time

Scheduled maintenance time 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 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

http://library.books24x7.com.ezproxy.library.drexel.edu/viewer.asp?bkid=7059&image_src=http://images.books24x7.com.ezproxy.library.drexel.edu/bookimages/id_7059/fig143%5F01%5F0%2Ejpg&image_id=54&previd=IMG_54&titlelabel=Figure+3%2E13%3A+&title=Thresholds+between+testbed+and+low%2Dand+high%2Dperformance+uptime%2E


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


Delay Requirements INTD and

HRT help distinguish burst from bulk apps


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


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


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


Typical App Capacity NeedsApplication 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


Data Rates Sometimes a range of values is more helpful

Processing credit card info might take 5-10 seconds, and require 100-1000 bytes of data

Multimedia rates are well known, and depend on the protocol and level of compression and quality desired

Low- and high-performance realms are completely subjective – there are no industry or generic numbers to set them apart


Supplemental Performance Other non-functional requirements can be

important to a network Operational Suitability is making sure your

customer can operate the network once it’s running How often are manual network adjustments

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


Operational Suitability How many shifts of operators will there be? How well trained are the network operators? How often will hardware changes be needed?

What hardware can the operators change? What level of component is an operator expected

to be able to change? Chip, board, rack unit, entire rack? (Line-Replaceable Unit, LRU)

All of this can result in a Concept of Operations description


Supportability Can the 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 Maintenance of a system expects

Components are located where they can be maintained without affecting the rest of the system much

Spare parts are supplied to allow replacement of failed and soon-failed components

Reliability can be formally modeled with reliability block diagrams (RBDs) or failure mode and effect analysis (FMECA)


Supportability Workforce should be equivalent to the ones

being replaced; or at least as cheap overall Documentation typically includes

Technical documentation of the system configuration, design, parts, etc.

Maintenance procedures describe routine actions Casualty or corrective procedures describe how

to troubleshoot, debug, or otherwise fix basic problems


Supportability Tools and test equipment describe what tools

are needed to maintain the system How are faults detected? How is performance being monitored? What capabilities will be available to remotely

diagnose, reconfigure, or reset components? Stuff breaks and wears out, so spare parts

are needed to improve availability How much are you will to invest in parts?


Supportability All of this produces a concept for support of

a network Important to state assumptions about the

knowledge, skills, and availability of support personnel

Spares are an ongoing investment – the customer needs to be aware of their cost

Often results in at least three tiers of support (onsite, central maintenance, and vendor)


SupportabilityLevel Tools and Test

Equipment Corrective

Maintenance Preventive

Maintenance

Organizational Common tools Operator consoles and controls Inexpensive special tools

Day-to-day monitoring Troubleshooting Fault isolation Reconfiguring system

Monitoring performance Minor on-site cleaning and adjustments

Intermediate Special or expensive portable tools with limited use

On-site repair of offline equipment

Major on-site upgrades Supplement operators

Depot Equipment to refurbish components

Overhaul and refurbishment

Scheduled overhaul or disassembly of LRUs


Confidence Confidence is the ability of a network to

provide throughput at an acceptable error or loss rate Often thought of at the device or link level,

but can also be considered end-to-end Measure by percent of traffic lost during a

given time period (e.g. 2% loss up to 1 min) Ping might be used to measure losses


Environment-specific Limits What constitutes acceptable performance

depends wildly on the industry or particular environment of the network High-performance devices often drive the

acceptable thresholds or limits Also consider if predictable or guaranteed

performance is important May lead to high QoS requirements, since best

effort may not be good enough


Map and Spec Then, as mentioned earlier, map out the

requirements, and write them in a specification Make sure you and your customer are in

agreement on the needs of the network Prioritize requirements, so if something has

to give, it’s not critical to your customer


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


Flow Analysis Later, flows can be

broken down into subnet or link level flows

A key purpose of flow analysis is to understand the balance between hierarchy and interconnectivity needed

Flow Characteristics

Performance Requirements

Capacity (e.g., Bandwidth)

Delay (e.g., Latency)

Reliability (e.g., Availability)

Quality of Service Levels

Importance/ Priority Levels

Business/Enterprise/Provider

Political

Other

Directionality

Common Sets of Users, Applications, Devices

Scheduling (e.g., Time-of-Day)

Protocols Used

Addresses/Ports

Security/Privacy Requirements


Flow Analysis Flows can be

individual, or grouped into composites

Flows can be critical (and often drive architecture and design)


Flow Analysis The requirements spec should be able to

define flows by user, app, device, & network Looks for important flows by application,

location, user type, device, type of function (multimedia, mission critical)

Define capacity (Kbps or Mbps), delay requirements (ms), reliability requirement (%)

Map flows geographically


Flow Analysis


Consolidate Flows


Data Sources and Sinks Look for devices (servers, special devices)

which generate lots of data (sources) or take in a lot of data (sinks)

Consider also WHEN the flows occur – are there specific times that are critical?

Consider worst-case and normal-usage scenarios


Flow Models Model the flows using common examples

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

These models differ in directionality (or lack thereof), hierarchy, and interconnectivity


Peer-to-Peer Flow Model All users or apps

are equal Flows are all

critical or none are Flows are all

equivalent (have same specification)


Client-Server Flow Model Requests are small data amounts compared

to responses, so these flows are asymmetric toward the clients

ERP, video editing, and web apps often follow this model


Hierarchical Client-Server


Distributed Computing Behavior varies – inverse client-server,

peer-to-peer, hybrid, etc.


Flow Prioritization Flows are typically prioritized based on many

factors, only a couple of which are technical Capacity, delay, RMA, and/or QoS requirements Security requirements Number of users or apps affected by each flow Business or political objectives, and the impact

of the flow on the customer’s business Who pays for it!


Flow Specification Like the requirements, the flows can be

summarized in a specification of some kind Critical for identifying priorities, in case

everyone 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


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


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


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


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


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!


Basic Design Rules: Regions Divide the network into regions, based on

similar traffic flows Edges (access regions) are where flows start

or stop Distribution regions are where flows collect and

terminate (app or storage servers) Core (backbone) regions let collections of flows

pass through External interfaces (DMZs) collect flows leaving

or entering the network from outside


Addressing/Routing Addressing applies MAC or IP addresses

for devices Routing establishes connectivity within and

between networks This component architecture defines how

user and management flows are forwarded, and how hierarchy & interconnectivity are balanced in subnets


Addressing/Routing Mechanisms for this architecture could be

Addressing: subnetting, supernetting, dynamic vs private addressing, VLANs, IP v4 versus v6, NAT

Routing: CIDR, mobile IP, multicast, and various routing protocols (BGP, RIP, etc.), establish routing policies

Notice at the architecture level we’re just choosing the types of mechanisms, not deciding exact structures


Network Management Arch. This decides how the network will be

monitored and managed Types of mechanisms include

Monitoring, instrumentation, configuration, security management components, does mgmt data flow in band or out?, how centralized is mgmt?, mgmt capacity needs, duplicate mgmt mechanisms, MIB selection


Performance Architecture This component defines how network

performance will be established and managed Defines how network resources are allocated

to users, apps, and devices Capacity planning, traffic engineering, QoS,

access control, SLAs, policies, resource mgmt Balances end-to-end vs per-link prioritization DiffServ vs IntServ


Security Architecture How do you protect system resources and

data from theft, damage, DoS, and unauthorized access? VPN, encryption, firewalls, routing filters, NAT Threat analysis, physical vs app security

Define security zones (cells) for different levels of security

Affects how other architectural components can interact with each other


Reference Architecture All these components need to be reconciled

with each other Can add key 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 Req’ts

dictate which components are favored, if any


Architectural Models Models for network architecture can be based

on topology, flow, or functionality Generally more than one model is needed Often start with topology model and add other(s)

Topology models are mainly The WAN/MAN/LAN model – basic hierarchical

structure The core/distribution/access model – think of

getting videos from CNN


Topology Models


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

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


Functionality Models These models focus on supporting key

functions in the network Service-provider – like an ISP Intranet/Extranet – focus on security and privacy Single-tier/Multi-tier Performance – where flows

indicate different levels of performance needs End-to-end Models – where a single flow is critical

to understand and fulfill These all require knowing location data


Functionality Models

Service provider and intranet/ extranet models


Functionality Models No cartoon for single- or multi-tier model;

could be a combination of the others End-to-end model


Applying Models The flow and functional models overlap in

focus with the core/distribution/access model


System Architecture The network (reference) architecture

connects to the rest of the organization Related components and functions may include

storage, clients and servers, databases, etc. How much detail outside of networking you

include is up to the context of your problem


Selecting Technologies After the types of mechanisms in the

reference architecture have been selected, we can start choosing more specific design technologies for our network This is where most people start ‘network design’

Technologies need to be consistent with the goals of the network What is most important – cost, capacity, QoS,

security, manageability…?


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


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


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


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


Technology Functions What features and functions will each

technology offer to users, apps, and devices? Does it depend on the local infrastructure? Are flows asymmetric, like Web access?

HFC and DSL both take advantage of this Are there distance limitations?

Affects delay time, buffering, reliability needs, and HW


Performance Upgrades How easily can your design be upgraded?

Generally focus on capacity, but delay and RMA may be affected too

For examples, SONET optical carrier (OC) levels can be easily upped in capacity for ATM or HiPPI

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 UpgradesTechnology Maximum Capacity Maximum Throughput

10 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


Flow Considerations The flow spec should help tell which flows

have similar requirements, and which need special consideration for performance, capacity, or other needs Find backbone flows, which collect smaller flows Capacity planning is based on estimating usage,

to compare against available technologies Service planning also compares levels of

service needed


Guidelines for Tech Eval Use combined capacities for best-effort flows

(generic Internet), and RMA, capacity, and/or delay requirements for predictable or guaranteed services Guideline 1: If predictable and/or guaranteed requirements

are listed in the flow specification (service plan), then either the technology or a combination of technology and supporting protocols or mechanisms must support these requirements. This guideline restricts the selection of candidate technologies to those that can support predictable and/or guaranteed requirements.


Guidelines for Tech Eval 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 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 Specific flows in the flow spec can be

mapped to the best technology solution Constraints in terms of RMA, delay, cost or QoS

can be used to eliminate technologies Interaction with existing networks needs to be

checked for possible conflicts Facility or other large scale issues may need to

be addressed too


Segmenting the Network Now that we have nailed down technology

choices, we can address the detailed structure of the network – how 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 A geographic example of segmenting


Segmenting the Network A user-based view of segmenting


Segmenting the Network A flow hierarchy-based example


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.)


Segmenting the Network Segmenting by types of function and feature


Black Box Method Once segments have been defined, we can

view each segment as black box(es) Know inputs and outputs, and don’t worry about

the inner details yet A segment could have several black boxes


Black Box Method Then for each black box, determine the exact

technology needs within it This lets us hide irrelevant information, and

focus our technology decisions on critical info Naturally we 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!


Summary Network design needs to understand and

balance requirements from network users, applications, devices, and the external environment

Flow analysis helps capture capacity, delay, QoS, reliability, and other critical aspects

Then technology choices can be made based on segmenting the network by geography, user, flow spec, or functions provided

331 network design

Documents