You are on page 1of 132

INFO 331 Computer Networking Technology II

Network Design Intro


Glenn Booker

INFO 331

Network Design

Network Design

Through the Kurose text weve covered


The application, transport, network, & link layers Wireless and multimedia technologies Security Network management

Not bad! So how does all this come together to help create a network?
Network Design 2

INFO 331

Network Design

Ok, thats not a small question well just tickle the surface (not even scratch!) Main resources for this section are:

McCabe, James D. (2003). Network Analysis, Architecture & Design (2nd Ed.). San Francisco: Morgan Kaufmann Publishers. [Chapters 1-5, 10] Teare, Diane. (2004). CCDA Self-Study: Designing for Cisco Internetworking Solutions (DESGN). Indianapolis: Cisco Press.
Network Design 3

INFO 331

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 4

INFO 331

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 5

INFO 331

Network Design Phases

Designing a network is typically broken into three sections:


Determine requirements Define the overall architecture Choose technology and specific devices
(McCabe, 2003)

INFO 331

Network Design

Systems Methodology

Theres lots of room for refining these sections (Teare, 2004)


INFO 331

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

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
Network Design 8

INFO 331

Two Main Principles

(McCabe, 2003)
INFO 331 Network Design 9

Plan Ahead!

The 80/20 rule applies here

80% of the cost of a network is its operation and support Only 20% is the cost of designing and implementing it

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

INFO 331

Network Design

10

Requirements? Booooring!

Yes, determining the requirements for a network probably isnt as much fun as shopping for really expensive hardware

And that may be why many networks are poorly designed no one bothered to think through their requirements! Many people will jump to a specific technology or hardware solution, without fully considering other options the obvious solution may not be the best one
Network Design 11

INFO 331

Requirements

We need to develop the low level design and the higher level architecture, and understand the environment in which they operate We also need to prove that the design weve chosen is just right (Southey, 1837)

Is that $2 million network backbone really enough to meet our needs? How do we know $500,000 wouldnt have been good enough?
Network Design 12

INFO 331

Requirements

Part of this process is managing the customers expectations

They may expect a much simpler or more expensive solution than is really needed Showing analysis of different design options, technologies, or architectures can help prove you have the best solution

INFO 331

Network Design

13

Requirements

We need to use a systems approach for understanding the network

The system goes far beyond the network hardware, software, etc. Also includes understanding the users, applications or services, and external environment

How do these need to interact? What does the rest of the organization expect from the network?
Network Design 14

INFO 331

Requirements

Consider how devices communicate

Images from (McCabe, 2003) unless noted otherwise


INFO 331 Network Design 15

Requirements

What services are expected from the network?

Typical performance levels might include capacity, delay time, reliability


Providing 1.5 Mb/s peak capacity to a remote user Guaranteeing a maximum round-trip delay of 100 ms to servers in a server farm

Functions include security, accounting, scheduling, management

Defining a security or privacy level for a group of users or an organization


Network Design 16

INFO 331

Requirements

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

This connects to network management monitoring of network performance


Network Design 17

INFO 331

Requirements

Capacity refers to the ability to transfer data

Bandwidth is the theoretical capacity of some part of the network Throughput is the actual capacity, which is less than the bandwidth, due to protocol overhead, network delays, etc.

Kind of like hard drive actual capacity is always less than advertised, due to formatting

INFO 331

Network Design

18

Requirements Analysis

Given these concepts, how do we describe requirements for a network? Need a process to filter or classify requirements

INFO 331

Network requirements (often have high, medium, low priorities) Future requirements (planned upgrades) Rejected requirements (remember for future ref.) Informational requirements (ideas, not required)
Network Design 19

Requirements Analysis

Requirements can come from many aspects of the network system


User Requirements Application Requirements Device Requirements Network Requirements Other Requirements

INFO 331

Network Design

20

User Requirements

User requirements are often qualitative and very high level

What is fast enough for download? System response (RTT)? How good does video need to be? Whats my budget?
Network Design 21

INFO 331

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

INFO 331

Application Requirements

What groups of apps are being used?


INFO 331

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
Network Design 23

Application Requirements

Where are the apps located? Are some only used in certain locations?

INFO 331

Network Design

24

Device Requirements

What kinds of devices are on your network?

Generic computing devices include normal PCs, Macs, laptops, handheld computers, workstations Servers include all flavors of server file, print, app/computation, and backup Specialized devices include extreme servers (supercomputers, massively parallel servers), data collection systems (POS terminals), industryspecific devices, networked devices (cameras, tools), stoplights, ATMs, etc.
Network Design 25

INFO 331

Device Requirements

Specialized devices are often locationspecific

INFO 331

Network Design

26

Device Requirements

We want an understanding of the devices performance its ability to process data from the network

Device I/O rates Delay time for performing a given app function

INFO 331

Network Design

27

Device Requirements

Performance results from many factors


INFO 331

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
Network Design 28

Device Requirements

The device locations are also critical

Often generic devices can be grouped by their quantity Servers and specialized stuff are shown individually
Network Design 29

INFO 331

Network Requirements

Network requirements (sounds kinda redundant) are the requirements for interacting with the existing network(s) and network management concerns Most networks have to integrate into an existing network, and plan for the future evolution of the network

INFO 331

Network Design

30

Network Requirements

Issues 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 Design 31

INFO 331

Network Requirements

Network, system, and support service dependencies

Addressing, security, routing protocols and network management can all be affected by the existing network Changes in technology or media at the interfaces between networks need to be accounted for, as well as QoS guarantees, if any

Interoperability dependencies

Network obsolescence do protocols or technologies become obsolete during transition?


Network Design 32

INFO 331

Network Requirements

Network management and security issues need to be addressed throughout development


How will the network be monitored for events? Monitoring for network performance?

What is the hierarchy for management data flow?

Network configuration? Troubleshoot support?

INFO 331

Network Design

33

Network Requirements

Security analysis can include the severity (effect) of an attack, and its probability of occurrence

Effect/ Probability Unauthorized Access Unauthorized Disclosure Denial of Service Theft Corruption Viruses Physical Damage

User Devices B/A B/C B/B A/D A/C B/B A/D Effect:

Servers B/B B/B B/B B/D B/C B/B B/C

Network C/B C/C B/B B/D C/C B/B C/C

Software A/B A/B B/B A/B A/B B/B D/D Probability:

Services B/C B/C B/B C/C D/D B/C D/D

Data A/B A/B D/D A/B A/B D/D D/D

A: Destructive B: Disabling

C: Disruptive D: No Impact

A: Certain B: Unlikely

C: Likely D: Impossible

INFO 331

Network Design

34

Other Requirements

Requirements can come from other outside sources your customer, legal requirements, larger scale organization (enterprise) requirements, etc. Additional requirements can include

Operational suitability how well can the customer configure and monitor the system? Supportability how well can the customer maintain the system?
Network Design 35

INFO 331

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
Network Design 36

INFO 331

Other Requirements

Enterprise requirements typically include integration of your network with existing standards for voice, data, or other protocols

INFO 331

Network Design

37

Requirements Spec and Map

A requirements specification is a document which summarizes the requirements for (here) a network

Often it becomes a contractual obligation, so assumptions, estimates, etc. should be carefully spelled out

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

INFO 331

Requirements Spec and Map

Priority can provide additional numeric distinction within a given Status (typically on a 1-3 or 1-5 scale) Sources for Gathering requirements can be identified, or give basis for Deriving it Type is user, app, device, network or other
Requirements Specification

ID/Name

Date

Type

Description

Gathered/Derived

Locations

Status

Priority

INFO 331

Network Design

39

Requirements Spec and Map

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

INFO 331

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
Network Design 41

INFO 331

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 Network size, Number of sites, Distance between sites

What is the overall scope of the project?

INFO 331

Network Design

42

Initial Conditions

Why is the network being designed? What are the goals for its architecture & design?

Upgrade technology and/or vendor Improve performance to part or all of network Support new users, applications, or devices Solve perceived problems within system Increase security Support a new capability in system
Network Design 43

INFO 331

Initial Conditions

What project constraints are there?

Funding, organizations involved, existing network, facility limitations, schedule, political, etc. Are users receptive to the new network?

Are user needs homogeneous, or are there multiple tiers of performance needs?

The former is easier to handle, of course

INFO 331

Network Design

44

Customer and User

Customer expectations need to be set quickly

What order of magnitude is the project, and does that match what they thought? Better to find out early on if theres a big gap!

Working with users is important, to know how they use the network and what problems they find important

Surveys, phone calls, personal meetings, and/or group discussions could be used
Network Design 45

INFO 331

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
Network Design 46

INFO 331

Requirements Management

The requirements you develop need to be tracked and managed, just like any systems requirements

Identify requirements by some form of ID and short name Need a tool to track requirements, their status, changes, sources, etc.

Map location of apps and devices of the existing network


Network Design 47

INFO 331

Service Metrics

Service metrics are characteristics measured or derived from the network

Metrics must be configurable, measurable, and verifiable 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
Network Design 48

RMA metrics might include

INFO 331

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 Data rates peak data rate, sustained data rate, and minimum data rate Data sizes burst sizes and durations
Network Design 49

Service metrics for capacity include:

INFO 331

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)
Network Design 50

INFO 331

Service Metrics

MIB Variables often used as service metrics:


INFO 331

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
Network Design 51

Metrics Tools

Tools for making service metric measurements include

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

Then summarize the metrics collection approach


Where Metric Will Be Measured in System Between NM Device and Each Router in LAN Between NM Device and Local Router Interface to WAN Between NM Device and Remote Router Interface to WAN At Each Local Router
Network Design

Service Metric 1 2 3 4 LAN Delay WAN Delay 1 WAN Delay 2 LAN Packet Loss
INFO 331

Measurement Method Ping Ping Ping SNMP


52

Characterizing Behavior

Next we can analyze how users and apps use the existing network We could use simulations or models to assess network behavior

Thats way beyond the scope here!

User behavior is looking for patterns in how people use apps

How many users, how frequently, how long per session, how much data they use
Network Design 53

INFO 331

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
Network Design 54

INFO 331

RMA Requirements

Reliability is a common measurement

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

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

INFO 331

Network Design

55

RMA Requirements

Availability relates failures to repair time

Scheduled maintenance time doesnt count against availability

Uptime and downtime measure those percentages when the system is up or down

INFO 331

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
Network Design 56

RMA Requirements

Thresholds and limits can be defined for RMA measures


MTBF is typically a couple thousand hours MTTR may be a few hours

Different parts of the system may have different requirements

INFO 331

Network Design

57

Delay Requirements

Various delays can have a strong impact on network requirements

Interaction delay (INTD) is how long a user will wait for a response from the system Human response time (HRT) is when a system delay becomes noticable to a user Network propagation delay is how long it takes for a command to cross the network and get the reply

INFO 331

Network Design

58

Delay Requirements

INTD and HRT help distinguish burst from bulk apps

INFO 331

Network Design

59

Delay Requirements

End-to-end and round-trip delays can be network requirements

Weve used ping to get RTT (round trip time)

Delay variation can be defined for multimedia apps typically is 1-2% of end-to-end delay

INFO 331

Network Design

60

Capacity Requirements

Much of the needed capacity of a network derives from key applications that are especially intense in such areas

Peak data rate Minimum acceptable data rate Sustained (long term) data rate

We need to distinguish apps that CAN use a lot of capacity (if its available), versus those that MUST use a lot
Network Design 61

INFO 331

Data Rates

Data rates for an app can be measured at many levels of the protocols

App, network, etc. Most TCP apps will take whats available, but back off when the network gets crowded (why?)

Often we may need to identify where the performance bottleneck is located It helps to get a rough idea of typical app performance
Network Design 62

INFO 331

Typical App Capacity Needs


Application Average Completion Time (Seconds) Average Data Size (Bytes)

Distributed Computing (Batch Mode)


Web Transactions Database Entries/Queries Payroll Entries Teleconference
INFO 331

103
10 25 10 103
Network Design

107
104 103 102 105
63

Data Rates

Sometimes a range of values is more helpful

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

Multimedia rates are well known, and depend on the protocol and level of compression and quality desired Low- and high-performance realms are completely subjective there are no industry or generic numbers to set them apart
Network Design 64

INFO 331

Supplemental Performance

Other non-functional requirements can be important to a network Operational Suitability is making sure your customer can operate the network once its running

INFO 331

How often are manual network adjustments needed? How often does network configuration change? How much monitoring is automated?
Network Design 65

Operational Suitability

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

What hardware can the operators change? What level of component is an operator expected to be able to change? Chip, board, rack unit, entire rack? (Line-Replaceable Unit, LRU)

All of this can result in a Concept of Operations description


Network Design 66

INFO 331

Supportability

Can the networks level of performance be sustained over time? Is affected by


RMA of the architecture and design Workforce, including training and staffing levels System procedures and technical documentation Tools, both ordinary and special Spare and repair parts
Network Design 67

INFO 331

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)
Network Design 68

INFO 331

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
Network Design 69

INFO 331

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?


Network Design 70

INFO 331

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)
Network Design 71

INFO 331

Supportability
Level Tools and Test Equipment Common tools Operator consoles and controls Inexpensive special tools Corrective Maintenance Day-to-day monitoring Troubleshooting Fault isolation Reconfiguring system Preventive Maintenance Monitoring performance Minor on-site cleaning and adjustments

Organizational

Intermediate

Special or expensive On-site repair of portable tools with offline equipment limited use Equipment to refurbish components Overhaul and refurbishment

Major on-site upgrades Supplement operators Scheduled overhaul or disassembly of LRUs


72

Depot

INFO 331

Network Design

Confidence

Confidence is the ability of a network to provide throughput at an acceptable error or loss rate

Often thought of at the device or link level, but can also be considered end-to-end

Measure by percent of traffic lost during a given time period (e.g. 2% loss up to 1 min)

Ping might be used to measure losses

INFO 331

Network Design

73

Environment-specific Limits

What constitutes acceptable performance depends wildly on the industry or particular environment of the network

High-performance devices often drive the acceptable thresholds or limits

Also consider if predictable or guaranteed performance is important

May lead to high QoS requirements, since best effort may not be good enough
Network Design 74

INFO 331

Map and Spec

Then, as mentioned earlier, map out the requirements, and write them in a specification

Make sure you and your customer are in agreement on the needs of the network Prioritize requirements, so if something has to give, its not critical to your customer

INFO 331

Network Design

75

Flow Analysis

The requirements map is a great place to start analysis of flows in your network

We dont want to model EVERY traffic (data) flow, just the important ones

A traffic flow describes data movement, e.g.

INFO 331

Source and/or destination addresses Type of information Directionality (bidirectional or unidirectional) Other aspects, such as QoS needs
Network Design 76

Flow Analysis
Flow Characteristics

Later, flows can be broken down into subnet or link level flows A key purpose of flow analysis is to understand the balance between hierarchy and interconnectivity needed

Capacity (e.g., Bandwidth) Performance Requirements Delay (e.g., Latency) Reliability (e.g., Availability) Quality of Service Levels Importance/ Priority Levels Business/Enterprise/Provider

Political
Directionality Common Sets of Users, Applications, Devices

Other

Scheduling (e.g., Time-ofDay) Protocols Used Addresses/Ports Security/Privacy Requirements

INFO 331

Network Design

77

Flow Analysis

Flows can be individual, or grouped into composites Flows can be critical (and often drive architecture and design)
Network Design 78

INFO 331

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
Network Design 79

INFO 331

Flow Analysis

INFO 331

Network Design

80

Consolidate Flows

INFO 331

Network Design

81

Data Sources and Sinks

Look for devices (servers, special devices) which generate lots of data (sources) or take in a lot of data (sinks) Consider also WHEN the flows occur are there specific times that are critical? Consider worst-case and normal-usage scenarios

INFO 331

Network Design

82

Flow Models

Model the flows using common examples


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

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

INFO 331

Network Design

83

Peer-to-Peer Flow Model

All users or apps are equal Flows are all critical or none are Flows are all equivalent (have same specification)
Network Design 84

INFO 331

Client-Server Flow Model

Requests are small data amounts compared to responses, so these flows are asymmetric toward the clients ERP, video editing, and web apps often follow this model

INFO 331

Network Design

85

Hierarchical Client-Server

INFO 331

Network Design

86

Distributed Computing

Behavior varies inverse client-server, peer-to-peer, hybrid, etc.

INFO 331

Network Design

87

Flow Prioritization

Flows are typically prioritized based on many factors, only a couple of which are technical

Capacity, delay, RMA, and/or QoS requirements Security requirements Number of users or apps affected by each flow Business or political objectives, and the impact of the flow on the customers business Who pays for it!

INFO 331

Network Design

88

Flow Specification

Like the requirements, the flows can be summarized in a specification of some kind Critical for identifying priorities, in case everyone cant be happy with your design Balancing flow requirements can be done with a flowspec algorithm

Best effort algorithms only consider capacity Predictable flow reqts consider capacity, delay, and RMA Guaranteed flow reqts are treated separately
Network Design 89

INFO 331

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 Design 90

INFO 331

Network Architecture

Avoid thinking of just the physical components of a network (routers, hubs, etc.) Think of the functions its performing (addressing, routing, security, network management, performance) as an integral part of the components

INFO 331

E.g. routing or switching can be affected by security So think of functional entities, not just HW
Network Design 91

Network Architecture

Measure network success by how well user, app, and device reqts are met functionally

Also connects easier to traffic flows And scales well to large networks

Each function will be defined by a component architecture; combine them to get the overall reference architecture

See house analogy a couple slides back


Network Design 92

INFO 331

Network Architecture

The design of a network is more detailed, technology- and location-specific description than its architecture Component architectures describe the hardware and software mechanisms needed to make a type of function work

Each component is sort of a subsystem; so well need to understand how they work together

INFO 331

Network Design

93

Network Functions

The key functions are


Addressing and routing Network management Performance Security

Functions may also include storage and infrastructure, but well focus on other ones Making this work may require trade-offs!
Network Design 94

INFO 331

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
Network Design 95

INFO 331

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
Network Design 96

INFO 331

Addressing/Routing

Mechanisms for this architecture could be

Addressing: subnetting, supernetting, dynamic vs private addressing, VLANs, IP v4 versus v6, NAT Routing: CIDR, mobile IP, multicast, and various routing protocols (BGP, RIP, etc.), establish routing policies

Notice at the architecture level were just choosing the types of mechanisms, not deciding exact structures
Network Design 97

INFO 331

Network Management Arch.

This decides how the network will be monitored and managed Types of mechanisms include

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

INFO 331

Network Design

98

Performance Architecture

This component defines how network performance will be established and managed


INFO 331

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
Network Design 99

Security Architecture

How do you protect system resources and data from theft, damage, DoS, and unauthorized access?

VPN, encryption, firewalls, routing filters, NAT Threat analysis, physical vs app security

Define security zones (cells) for different levels of security Affects how other architectural components can interact with each other
Network Design 100

INFO 331

Reference Architecture

All these components need to be reconciled with each other

Can add key reqts and chosen mechanisms to flow diagram Prioritize mechanisms and how they interact

The Reference Architecture is the collection of all the component architectures

INFO 331

Network Design

101

Reference Architecture

Reqts dictate which components are favored, if any

INFO 331

Network Design

102

Architectural Models

Models for network architecture can be based on topology, flow, or functionality


Generally more than one model is needed Often start with topology model and add other(s) The WAN/MAN/LAN model basic hierarchical structure The core/distribution/access model think of getting videos from CNN
Network Design 103

Topology models are mainly

INFO 331

Topology Models

INFO 331

Network Design

104

Flow Models

Weve already seen these (slides 84-87)


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

INFO 331

Network Design

105

Functionality Models

These models focus on supporting key functions in the network


Service-provider like an ISP Intranet/Extranet focus on security and privacy Single-tier/Multi-tier Performance where flows indicate different levels of performance needs End-to-end Models where a single flow is critical to understand and fulfill

These all require knowing location data


Network Design 106

INFO 331

Functionality Models

Service provider and intranet/ extranet models

INFO 331

Network Design

107

Functionality Models

No cartoon for single- or multi-tier model; could be a combination of the others End-to-end model

INFO 331

Network Design

108

Applying Models

The flow and functional models overlap in focus with the core/distribution/access model

INFO 331

Network Design

109

System Architecture

The network (reference) architecture connects to the rest of the organization

Related components and functions may include storage, clients and servers, databases, etc.

How much detail outside of networking you include is up to the context of your problem

INFO 331

Network Design

110

Selecting Technologies

After the types of mechanisms in the reference architecture have been selected, we can start choosing more specific design technologies for our network

This is where most people start network design

Technologies need to be consistent with the goals of the network

What is most important cost, capacity, QoS, security, manageability?


Network Design 111

INFO 331

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
Network Design 112

INFO 331

Selecting Technologies

Consider a car-buying analogy; if youre buying a car, you might consider many characteristics to make your choice

Cost, performance, appearance, safety, comfort, load capacity, handling, reputation, reliability, etc.

Here we look to the flowspec and reference architecture for the relative importance of each desirable characteristic
Network Design 113

INFO 331

Selecting Technologies

Consider also design and configuration issues for technology, not just price-vsperformance For example, many older technologies have built-in ARP capability

Ethernet, Token Ring, and FDDI all do this

But newer non-broadcast multiple access (NBMA) technologies dont have this

ATM, frame relay, SMDS, HiPPI


Network Design 114

INFO 331

Selecting Technologies

As a result, using NBMA technologies requires separate support for broadcast and multicast Also consider how autonomous systems (ASs) are being formed and managed What kinds of connections are maintained in the network?

Stateless, hard state, or soft state Connections require more work from the network
Network Design 115

INFO 331

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 Affects delay time, buffering, reliability needs, and HW

Are there distance limitations?

INFO 331

Network Design

116

Performance Upgrades

How easily can your design be upgraded?

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

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

SONET Level OC-3 OC-12 OC-48 OC-192 OC-768

Rate 155.52 Mb/s 622 Mb/s 2.488 Gb/s 9.953 Gb/s 39.812 Gb/s
Network Design 117

INFO 331

Performance Upgrades
Technology Maximum Capacity Ethernet 10 Mb/s 100 Mb/s 1 Gb/s Token Ring 4 Mb/s 16 Mb/s 100 Mb/s ATM T3 45 Mb/s OC-3c OC-48 HiPPI 155 Mb/s 2.5 Gb/s Maximum Throughput 39 Mb/s 8095 Mb/s 700980 Mb/s 4 Mb/s 16 Mb/s 80100 Mb/s 34 Mb/s 120135 Mb/s 2.12.35 Gb/s 350750 Mb/s 0.51.4 Gb/s 1.86 Gb/s 45 Mb/s Up to 1.5 Mb/s, depending on service level
118

800 Mb/s 1.6 Gb/s 6.4 Gb/s Frame relay 45 Mb/s ADSL Up to 1.5 Mb/s, depending on service level
INFO 331

Network Design

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
Network Design 119

INFO 331

Guidelines for Tech Eval

Use combined capacities for best-effort flows (generic Internet), and RMA, capacity, and/or delay requirements for predictable or guaranteed services

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

INFO 331

Network Design

120

Guidelines for Tech Eval

For examples which are technologydependent, for predictable service:


Quality-of-service levels in ATM Committed information rate levels in frame relay Differentiated service or integrated service levels in IP

Guaranteed service gets even messier!

INFO 331

Network Design

121

Guidelines for Tech Eval

Guideline 2: When best-effort, predictable, and/or guaranteed capacities are listed in the flow specification, the selection of technology may also be based on capacity planning for each flow. Capacity planning uses the combined capacities from the flow specification to select candidate technologies, comparing the scalability of each technology to capacity and growth expectations for the network.
Network Design 122

INFO 331

Guidelines for Tech Eval

Specific flows in the flow spec can be mapped to the best technology solution

Constraints in terms of RMA, delay, cost or QoS can be used to eliminate technologies Interaction with existing networks needs to be checked for possible conflicts Facility or other large scale issues may need to be addressed too

INFO 331

Network Design

123

Segmenting the Network

Now that we have nailed down technology choices, we can address the detailed structure of the network how its segmented

Segmenting focuses technology selection

We could do it by geography, groups of users (even virtual), or flow hierarchy

Groups of users could belong to different organizations would that be a problem for security or privacy?
Network Design 124

INFO 331

Segmenting the Network

A geographic example of segmenting

INFO 331

Network Design

125

Segmenting the Network

A user-based view of segmenting

INFO 331

Network Design

126

Segmenting the Network

A flow hierarchy-based example

INFO 331

Network Design

127

Segmenting the Network

Segments can include defining broadcast domains, collision domains, or the scope of autonomous systems (ASs) Really large networks can be segmented by the type of functions and features involved in each segment (WAN, MAN, LAN, specialized equipment areas, core business areas, etc.)

INFO 331

Network Design

128

Segmenting the Network

Segmenting by types of function and feature

INFO 331

Network Design

129

Black Box Method

Once segments have been defined, we can view each segment as black box(es)

Know inputs and outputs, and dont worry about the inner details yet A segment could have several black boxes

INFO 331

Network Design

130

Black Box Method

Then for each black box, determine the exact technology needs within it This lets us hide irrelevant information, and focus our technology decisions on critical info Naturally we dont want to have all technology decisions made in a vacuum, or wildly different or incompatible technologies may be chosen

Common sense should prevail!


Network Design 131

INFO 331

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
Network Design 132

INFO 331

You might also like