INFO 331Network Design*INFO 331Computer Networking Technology II Network Design Intro

Glenn Booker

Network Design

INFO 331Network Design*Network DesignThrough the Kurose text weve coveredThe application, transport, network, & link layersWireless and multimedia technologiesSecurityNetwork managementNot bad!So how does all this come together to help create a network?

Network Design

INFO 331Network Design*Network DesignOk, 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

INFO 331Network Design*Network Design ObjectiveUltimately, our network design must answer some pretty basic questionsWhat 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 movingMay be effective, but result in over engineering

Network Design

INFO 331Network Design*Network Design ObjectiveAnd 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 threatsPossible wireless connectivityReliability and/or availabilityLike speed for a car, how much are you willing to afford?

Network Design

INFO 331Network Design*Network Design PhasesDesigning a network is typically broken into three sections:Determine requirementsDefine the overall architectureChoose technology and specific devices(McCabe, 2003)

Network Design

INFO 331Network Design*Systems MethodologyTheres lots of room for refining these sections (Teare, 2004)Identify customer requirementsCharacterize the existing networkDesign topologyPlan the implementationBuild a pilot networkDocument the designImplement the design, and monitor its use

Network Design

INFO 331Network Design*Two Main PrinciplesFor a network design to work well, we need to balance betweenHierarchy how much network traffic flows connect in tiers of organizationLike tiers on an org chart, hierarchy provides separation and structure for the networkInterconnectivity offsets hierarchy by allowing connections between levels of the design, often to improve performance between them

Network Design

INFO 331Network Design*Two Main Principles(McCabe, 2003)

Network Design

INFO 331Network Design*Plan Ahead!The 80/20 rule applies here 80% of the cost of a network is its operation and supportOnly 20% is the cost of designing and implementing itSo plan for easy operation, maintenance, and upgrade of the network

Network Design

INFO 331Network Design*Requirements? Booooring! Yes, determining the requirements for a network probably isnt as much fun as shopping for really expensive hardwareAnd 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

INFO 331Network Design*RequirementsWe 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

INFO 331Network Design*RequirementsPart of this process is managing the customers expectationsThey may expect a much simpler or more expensive solution than is really neededShowing analysis of different design options, technologies, or architectures can help prove you have the best solution

Network Design

INFO 331Network Design*RequirementsWe need to use a systems approach for understanding the networkThe system goes far beyond the network hardware, software, etc.Also includes understanding the users, applications or services, and external environmentHow do these need to interact?What does the rest of the organization expect from the network?

Network Design

INFO 331Network Design*RequirementsConsider how devices communicateImages from (McCabe, 2003) unless noted otherwise

Network Design

INFO 331Network Design*RequirementsWhat services are expected from the network?Typical performance levels might include capacity, delay time, reliabilityProviding 1.5 Mb/s peak capacity to a remote userGuaranteeing a maximum round-trip delay of 100 ms to servers in a server farmFunctions include security, accounting, scheduling, managementDefining a security or privacy level for a group of users or an organization

Network Design

INFO 331Network Design*RequirementsService requirements could include the QoS (quality of service) guarantees (ATM, Intserv, Diffserv, etc.) This connects to network management monitoring of network performance

Network Design

INFO 331Network Design*RequirementsCapacity refers to the ability to transfer dataBandwidth is the theoretical capacity of some part of the networkThroughput 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

Network Design

INFO 331Network Design*Requirements AnalysisGiven these concepts, how do we describe requirements for a network?Need a process to filter or classify requirementsNetwork requirements (often have high, medium, low priorities)Future requirements (planned upgrades)Rejected requirements (remember for future ref.)Informational requirements (ideas, not required)

Network Design

INFO 331Network Design*Requirements AnalysisRequirements can come from many aspects of the network systemUser Requirements Application Requirements Device Requirements Network Requirements Other Requirements

Network Design

INFO 331Network Design*User RequirementsUser requirements are often qualitative and very high levelWhat is fast enough for download? System response (RTT)?How good does video need to be?Whats my budget?

Network Design

INFO 331Network Design*Application RequirementsWhat types of apps are we using?Mission-criticalRate-criticalReal-time and/or interactiveHow sensitive are apps to RMA (reliability, maintainability, availability)?What capacity is needed?What delay time is acceptable?

Network Design

INFO 331Network Design*Application RequirementsWhat groups of apps are being used?Telemetry/command and control - remote devicesVisualization and simulationDistributed computingWeb development, access, and useBulk data transport FTP Teleservice VOIP, teleconferenceOperations, admin, maintenance, and provisioning (OAM&P) DNS, SMTP, SNMPClient-server ERP, SCM, CRM

Network Design

INFO 331Network Design*Application RequirementsWhere are the apps located?Are some only used in certain locations?

Network Design

INFO 331Network Design*Device RequirementsWhat kinds of devices are on your network?Generic computing devices include normal PCs, Macs, laptops, handheld computers, workstationsServers include all flavors of server file, print, app/computation, and backupSpecialized devices include extreme servers (supercomputers, massively parallel servers), data collection systems (POS terminals), industry-specific devices, networked devices (cameras, tools), stoplights, ATMs, etc.

Network Design

INFO 331Network Design*Device RequirementsSpecialized devices are often location-specific

Network Design

INFO 331Network Design*Device RequirementsWe want an understanding of the devices performance its ability to process data from the networkDevice I/O ratesDelay time for performing a given app function

Network Design

INFO 331Network Design*Device RequirementsPerformance results from many factorsStorage performance, that is, flash, disk drive, or tape performanceProcessor (CPU) performanceMemory performance (access times)Bus performance (bus capacity and arbitration efficiency)OS performance (effectiveness of the protocol stack and APIs)Device driver performance

Network Design

INFO 331Network Design*Device RequirementsThe device locations are also criticalOften generic devices can be grouped by their quantityServers and specialized stuff are shown individually

Network Design

INFO 331Network Design*Network RequirementsNetwork requirements (sounds kinda redundant) are the requirements for interacting with the existing network(s) and network management concernsMost networks have to integrate into an existing network, and plan for the future evolution of the network

Network Design

INFO 331Network Design*Network RequirementsIssues with network integration includeScaling 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 componentsPerformance constraints existing network could limit performance of the new one

Network Design

INFO 331Network Design*Network RequirementsNetwork, system, and support service dependenciesAddressing, security, routing protocols and network management can all be affected by the existing networkInteroperability dependenciesChanges in technology or media at the interfaces between networks need to be accounted for, as well as QoS guarantees, if anyNetwork obsolescence do protocols or technologies become obsolete during transition?

Network Design

INFO 331Network Design*Network RequirementsNetwork management and security issues need to be addressed throughout developmentHow will the network be monitored for events?Monitoring for network performance?What is the hierarchy for management data flow?Network configuration?Troubleshoot support?

Network Design

INFO 331Network Design*Network RequirementsSecurity analysis can include the severity (effect) of an attack, and its probability of occurrence

Effect/ Probability User Devices Servers Network Software Services Data Unauthorized AccessB/AB/BC/BA/BB/CA/BUnauthorized DisclosureB/CB/BC/CA/BB/CA/BDenial of ServiceB/BB/BB/BB/BB/BD/DTheftA/DB/DB/DA/BC/CA/BCorruptionA/CB/CC/CA/BD/DA/BVirusesB/BB/BB/BB/BB/CD/DPhysical DamageA/DB/CC/CD/DD/DD/DEffect: Probability: A: DestructiveC: DisruptiveA: CertainC: LikelyB: DisablingD: No ImpactB: UnlikelyD: Impossible

Network Design

INFO 331Network Design*Other RequirementsRequirements can come from other outside sources your customer, legal requirements, larger scale organization (enterprise) requirements, etc.Additional requirements can includeOperational suitability how well can the customer configure and monitor the system?Supportability how well can the customer maintain the system?

Network Design

INFO 331Network Design*Other RequirementsConfidence 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 costsSystem architecture may be altered to remain within cost constraintsThis is a good reason to present the customer with design choices, so they see the impact of cost versus performance

Network Design

INFO 331Network Design*Other RequirementsEnterprise requirements typically include integration of your network with existing standards for voice, data, or other protocols

Network Design

INFO 331Network Design*Requirements Spec and MapA requirements specification is a document which summarizes the requirements for (here) a networkOften it becomes a contractual obligation, so assumptions, estimates, etc. should be carefully spelled outRequirements are classified by Status, as noted earlier (core/current, future, rejected, or informational requirement)

Network Design

INFO 331Network Design*Requirements Spec and MapPriority 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 itType is user, app, device, network or other

Requirements Specification ID/Name Date Type Description Gathered/Derived Locations Status Priority

Network Design

INFO 331Network Design*Requirements Spec and MapRequirements Mapping can show graphically where stuff is, what kind of apps are used, and existing connectivity

Network Design

INFO 331Network Design*Requirements Analysis ProcessSo, 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

INFO 331Network Design*Gather and List RequirementsA great starting point is the very beginningWhat initial conditions are you facing?What type of project is this?New network, Modifying an existing network, Analysis of network problems, Outsourcing, Consolidation, UpgradeWhat is the overall scope of the project?Network size, Number of sites, Distance between sites

Network Design

INFO 331Network Design*Initial ConditionsWhy is the network being designed? What are the goals for its architecture & design?Upgrade technology and/or vendorImprove performance to part or all of networkSupport new users, applications, or devicesSolve perceived problems within systemIncrease securitySupport a new capability in system

Network Design

INFO 331Network Design*Initial ConditionsWhat 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

Network Design

INFO 331Network Design*Customer and UserCustomer 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 importantSurveys, phone calls, personal meetings, and/or group discussions could be used

Network Design

INFO 331Network Design*Customer and UserLook for red flags in early discussionsAbuse of the term "real-time"Availability as solely a percentage (99.99%)"High performance" without verification or clarificationHighly variable, inconsistent requirementsUnrealistic expectations from the customerMeasure application performance using existing network (if possible) or a test bed

Network Design

INFO 331Network Design*Requirements ManagementThe requirements you develop need to be tracked and managed, just like any systems requirementsIdentify requirements by some form of ID and short nameNeed a tool to track requirements, their status, changes, sources, etc.Map location of apps and devices of the existing network

Network Design

INFO 331Network Design*Service MetricsService metrics are characteristics measured or derived from the networkMetrics must be configurable, measurable, and verifiableRMA metrics might includeReliability 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

INFO 331Network Design*Service MetricsRelated RMA metrics includeUptime 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 ratesService metrics for capacity include:Data rates peak data rate, sustained data rate, and minimum data rateData sizes burst sizes and durations

Network Design

INFO 331Network Design*Service MetricsService metrics for delay include:End-to-end or round-trip delayLatencyDelay variationSNMP or CMIP (Common Management Information Protocol) can be used to configure these metrics, which are kept in the Management Information Base (MIB)

Network Design

INFO 331Network Design*Service MetricsMIB Variables often used as service metrics:Bytes in/out (per interface)IP packets in/out (per interface)Dropped ICMP messages per time per interfaceService-level agreement (SLA) metrics (per user)Capacity limitBurst toleranceDelayDowntime

Network Design

INFO 331Network Design*Metrics ToolsTools for making service metric measurements includePing, pathchar, traceroute, TCPdumpPacket capture utilities: Ethereal, Sniffer, and EtherpeakThen summarize the metrics collection approach

Service MetricWhere Metric Will Be Measured in SystemMeasurement Method1LAN DelayBetween NM Device and Each Router in LANPing2WAN Delay 1Between NM Device and Local Router Interface to WANPing3WAN Delay 2Between NM Device and Remote Router Interface to WANPing4LAN Packet LossAt Each Local RouterSNMP

Network Design

INFO 331Network Design*Characterizing BehaviorNext we can analyze how users and apps use the existing networkWe could use simulations or models to assess network behaviorThats way beyond the scope here!User behavior is looking for patterns in how people use appsHow many users, how frequently, how long per session, how much data they use

Network Design

INFO 331Network Design*Characterizing BehaviorApplication behavior includes looking at how each app uses the networkCommunication between client/server partsMulticast or broadcast transmissions how often, how bigFocus 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

INFO 331Network Design*RMA RequirementsReliability is a common measurementMean time between mission critical failure (MTBCF) focuses on failures during certain time periods, excluding planned down timesMean time between failure (MTBF) includes failure at any timeMaintainability is typically captured with mean time to repair (MTTR)

Network Design

INFO 331Network Design*RMA RequirementsAvailability relates failures to repair timeScheduled maintenance time doesnt count against availabilityUptime and downtime measure those percentages when the system is up or downThe upper practical limit is 99.999% uptime, which is 5.3 minutes of downtime per yearUptime of 99.99% is fairly commonHow many events occur is also important

Network Design

INFO 331Network Design*RMA RequirementsThresholds and limits can be defined for RMA measuresMTBF is typically a couple thousand hoursMTTR may be a few hoursDifferent parts of the system may have different requirements

Network Design

INFO 331Network Design*Delay RequirementsVarious delays can have a strong impact on network requirementsInteraction delay (INTD) is how long a user will wait for a response from the systemHuman response time (HRT) is when a system delay becomes noticeable to a userNetwork propagation delay is how long it takes for a command to cross the network and get the reply

Network Design

INFO 331Network Design*Delay RequirementsINTD and HRT help distinguish burst from bulk apps

Network Design

INFO 331Network Design*Delay RequirementsEnd-to-end and round-trip delays can be network requirementsWeve 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

Network Design

INFO 331Network Design*Capacity RequirementsMuch of the needed capacity of a network derives from key applications that are especially intense in such areasPeak data rateMinimum acceptable data rateSustained (long term) data rateWe need to distinguish apps that CAN use a lot of capacity (if its available), versus those that MUST use a lot

Network Design

INFO 331Network Design*Data RatesData 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 locatedIt helps to get a rough idea of typical app performance

Network Design

INFO 331Network Design*Typical App Capacity Needs

Application Average Completion Time (Seconds) Average Data Size (Bytes) Distributed Computing (Batch Mode)103 107 Web Transactions10104 Database Entries/Queries25103 Payroll Entries10102 Teleconference103 105

Network Design

INFO 331Network Design*Data RatesSometimes a range of values is more helpfulProcessing credit card info might take 5-10 seconds, and require 100-1000 bytes of dataMultimedia rates are well known, and depend on the protocol and level of compression and quality desiredLow- and high-performance realms are completely subjective there are no industry or generic numbers to set them apart

Network Design

INFO 331Network Design*Supplemental PerformanceOther non-functional requirements can be important to a networkOperational Suitability is making sure your customer can operate the network once its runningHow often are manual network adjustments needed?How often does network configuration change?How much monitoring is automated?

Network Design

INFO 331Network Design*Operational SuitabilityHow 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

INFO 331Network Design*SupportabilityCan the networks level of performance be sustained over time?Is affected byRMA of the architecture and designWorkforce, including training and staffing levelsSystem procedures and technical documentationTools, both ordinary and specialSpare and repair parts

Network Design

INFO 331Network Design*SupportabilityMaintenance of a system expectsComponents are located where they can be maintained without affecting the rest of the system muchSpare parts are supplied to allow replacement of failed and soon-failed componentsReliability can be formally modeled with reliability block diagrams (RBDs) or failure mode and effect analysis (FMECA)

Network Design

INFO 331Network Design*SupportabilityWorkforce should be equivalent to the ones being replaced; or at least as cheap overallDocumentation typically includesTechnical documentation of the system configuration, design, parts, etc.Maintenance procedures describe routine actionsCasualty or corrective procedures describe how to troubleshoot, debug, or otherwise fix basic problems

Network Design

INFO 331Network Design*SupportabilityTools and test equipment describe what tools are needed to maintain the systemHow 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 availabilityHow much are you will to invest in parts?

Network Design

INFO 331Network Design*SupportabilityAll of this produces a concept for support of a networkImportant to state assumptions about the knowledge, skills, and availability of support personnelSpares are an ongoing investment the customer needs to be aware of their costOften results in at least three tiers of support (onsite, central maintenance, and vendor)

Network Design

INFO 331Network Design*Supportability

Level Tools and Test Equipment Corrective Maintenance Preventive Maintenance OrganizationalCommon tools Operator consoles and controls Inexpensive special toolsDay-to-day monitoring Troubleshooting Fault isolation Reconfiguring systemMonitoring performance Minor on-site cleaning and adjustmentsIntermediateSpecial or expensive portable tools with limited useOn-site repair of offline equipmentMajor on-site upgrades Supplement operatorsDepotEquipment to refurbish componentsOverhaul and refurbishmentScheduled overhaul or disassembly of LRUs

Network Design

INFO 331Network Design*ConfidenceConfidence is the ability of a network to provide throughput at an acceptable error or loss rateOften thought of at the device or link level, but can also be considered end-to-endMeasure 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

Network Design

INFO 331Network Design*Environment-specific LimitsWhat constitutes acceptable performance depends wildly on the industry or particular environment of the networkHigh-performance devices often drive the acceptable thresholds or limitsAlso consider if predictable or guaranteed performance is importantMay lead to high QoS requirements, since best effort may not be good enough

Network Design

INFO 331Network Design*Map and SpecThen, as mentioned earlier, map out the requirements, and write them in a specificationMake sure you and your customer are in agreement on the needs of the networkPrioritize requirements, so if something has to give, its not critical to your customer

Network Design

INFO 331Network Design*Flow AnalysisThe requirements map is a great place to start analysis of flows in your networkWe dont want to model EVERY traffic (data) flow, just the important onesA traffic flow describes data movement, e.g.Source and/or destination addressesType of informationDirectionality (bidirectional or unidirectional)Other aspects, such as QoS needs

Network Design

INFO 331Network Design*Flow AnalysisLater, flows can be broken down into subnet or link level flowsA 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 LevelsImportance/ Priority Levels Business/Enterprise/ProviderPoliticalOther DirectionalityCommon Sets of Users, Applications, DevicesScheduling (e.g., Time-of-Day)Protocols UsedAddresses/PortsSecurity/Privacy Requirements

Network Design

INFO 331Network Design*Flow AnalysisFlows can be individual, or grouped into compositesFlows can be critical (and often drive architecture and design)

Network Design

INFO 331Network Design*Flow AnalysisThe requirements spec should be able to define flows by user, app, device, & networkLooks 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

INFO 331Network Design*Flow Analysis

Network Design

INFO 331Network Design*Consolidate Flows

Network Design

INFO 331Network Design*Data Sources and SinksLook 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

Network Design

INFO 331Network Design*Flow ModelsModel the flows using common examplesPeer-to-peerClient-serverHierarchical client-serverDistributed computingThese models differ in directionality (or lack thereof), hierarchy, and interconnectivity

Network Design

INFO 331Network Design*Peer-to-Peer Flow ModelAll users or apps are equalFlows are all critical or noneFlows are all equivalent (have same specification)

Network Design

INFO 331Network Design*Client-Server Flow ModelRequests are small data amounts compared to responses, so these flows are asymmetric toward the clientsERP, video editing, and web apps often follow this model

Network Design

INFO 331Network Design*Hierarchical Client-Server

Network Design

INFO 331Network Design*Distributed ComputingBehavior varies inverse client-server, peer-to-peer, hybrid, etc.

Network Design

INFO 331Network Design*Flow PrioritizationFlows are typically prioritized based on many factors, only a couple of which are technicalCapacity, delay, RMA, and/or QoS requirementsSecurity requirementsNumber of users or apps affected by each flowBusiness or political objectives, and the impact of the flow on the customers businessWho pays for it!

Network Design

INFO 331Network Design*Flow SpecificationLike the requirements, the flows can be summarized in a specification of some kindCritical for identifying priorities, in case everyone cant be happy with your designBalancing flow requirements can be done with a flowspec algorithmBest effort algorithms only consider capacityPredictable flow reqts consider capacity, delay, and RMAGuaranteed flow reqts are treated separately

Network Design

INFO 331Network Design*Network ArchitectureNow that we FINALLY have requirements and flows defined, we can consider how all this will affect the architecture of our networkThe 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

INFO 331Network Design*Network ArchitectureAvoid 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 componentsE.g. routing or switching can be affected by securitySo think of functional entities, not just HW

Network Design

INFO 331Network Design*Network ArchitectureMeasure network success by how well user, app, and device reqts are met functionallyAlso connects easier to traffic flowsAnd scales well to large networksEach function will be defined by a component architecture; combine them to get the overall reference architectureSee house analogy a couple slides back

Network Design

INFO 331Network Design*Network ArchitectureThe design of a network is more detailed, technology- and location-specific description than its architectureComponent 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

Network Design

INFO 331Network Design*Network FunctionsThe key functions areAddressing and routingNetwork managementPerformanceSecurityFunctions may also include storage and infrastructure, but well focus on other onesMaking this work may require trade-offs!

Network Design

INFO 331Network Design*Basic Design Rules: RegionsDivide the network into regions, based on similar traffic flowsEdges (access regions) are where flows start or stopDistribution regions are where flows collect and terminate (app or storage servers)Core (backbone) regions let collections of flows pass throughExternal interfaces (DMZs) collect flows leaving or entering the network from outside

Network Design

INFO 331Network Design*Addressing/RoutingAddressing applies MAC or IP addresses for devicesRouting establishes connectivity within and between networksThis component architecture defines how user and management flows are forwarded, and how hierarchy & interconnectivity are balanced in subnets

Network Design

INFO 331Network Design*Addressing/RoutingMechanisms for this architecture could beAddressing: subnetting, supernetting, dynamic vs private addressing, VLANs, IP v4 versus v6, NATRouting: CIDR, mobile IP, multicast, and various routing protocols (BGP, RIP, etc.), establish routing policiesNotice at the architecture level were just choosing the types of mechanisms, not deciding exact structures

Network Design

INFO 331Network Design*Network Management Arch.This decides how the network will be monitored and managedTypes of mechanisms includeMonitoring, 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

Network Design

INFO 331Network Design*Performance ArchitectureThis component defines how network performance will be established and managedDefines how network resources are allocated to users, apps, and devicesCapacity planning, traffic engineering, QoS, access control, SLAs, policies, resource mgmtBalances end-to-end vs per-link prioritizationDiffServ vs IntServ

Network Design

INFO 331Network Design*Security ArchitectureHow do you protect system resources and data from theft, damage, DoS, and unauthorized access?VPN, encryption, firewalls, routing filters, NATThreat analysis, physical vs app securityDefine security zones (cells) for different levels of securityAffects how other architectural components can interact with each other

Network Design

INFO 331Network Design*Reference ArchitectureAll these components need to be reconciled with each otherCan add key reqts and chosen mechanisms to flow diagramPrioritize mechanisms and how they interactThe Reference Architecture is the collection of all the component architectures

Network Design

INFO 331Network Design*Reference ArchitectureReqts dictate which components are favored, if any

Network Design

INFO 331Network Design*Architectural ModelsModels for network architecture can be based on topology, flow, or functionalityGenerally more than one model is neededOften start with topology model and add other(s)Topology models are mainly The WAN/MAN/LAN model basic hierarchical structureThe core/distribution/access model think of getting videos from CNN

Network Design

INFO 331Network Design*Topology Models

Network Design

INFO 331Network Design*Flow ModelsWeve already seen these (slides 84-87)Peer-to-peerClient-serverHierarchical client-serverDistributed-computing

Network Design

INFO 331Network Design*Functionality ModelsThese models focus on supporting key functions in the networkService-provider like an ISPIntranet/Extranet focus on security and privacySingle-tier/Multi-tier Performance where flows indicate different levels of performance needsEnd-to-end Models where a single flow is critical to understand and fulfillThese all require knowing location data

Network Design

INFO 331Network Design*Functionality Models

Service provider and intranet/ extranet models

Network Design

INFO 331Network Design*Functionality ModelsNo cartoon for single- or multi-tier model; could be a combination of the othersEnd-to-end model

Network Design

INFO 331Network Design*Applying ModelsThe flow and functional models overlap in focus with the core/distribution/access model

Network Design

INFO 331Network Design*System ArchitectureThe network (reference) architecture connects to the rest of the organizationRelated 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

Network Design

INFO 331Network Design*Selecting TechnologiesAfter the types of mechanisms in the reference architecture have been selected, we can start choosing more specific design technologies for our networkThis is where most people start network designTechnologies need to be consistent with the goals of the networkWhat is most important cost, capacity, QoS, security, manageability?

Network Design

INFO 331Network Design*Selecting TechnologiesThe goals may be different in different parts of the networkConsider having a primary goal and one or more secondary goalsConsider graphs to show tradeoffsBased 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

INFO 331Network Design*Selecting TechnologiesConsider a car-buying analogy; if youre buying a car, you might consider many characteristics to make your choiceCost, 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

INFO 331Network Design*Selecting TechnologiesConsider also design and configuration issues for technology, not just price-vs-performanceFor example, many older technologies have built-in ARP capabilityEthernet, Token Ring, and FDDI all do thisBut newer non-broadcast multiple access (NBMA) technologies dont have thisATM, frame relay, SMDS, HiPPI

Network Design

INFO 331Network Design*Selecting TechnologiesAs a result, using NBMA technologies requires separate support for broadcast and multicast Also consider how autonomous systems (ASs) are being formed and managedWhat kinds of connections are maintained in the network?Stateless, hard state, or soft stateConnections require more work from the network

Network Design

INFO 331Network Design*Technology FunctionsWhat 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 thisAre there distance limitations?Affects delay time, buffering, reliability needs, and HW

Network Design

INFO 331Network Design*Performance UpgradesHow easily can your design be upgraded?Generally focus on capacity, but delay and RMA may be affected tooFor examples, SONET optical carrier (OC) levels can be easily upped in capacity for ATM or HiPPI (High Performance Parallel Interface pre SCSI)SONET Level Rate OC-3155.52 Mb/sOC-12622 Mb/sOC-482.488 Gb/sOC-1929.953 Gb/sOC-76839.812 Gb/s

Network Design

INFO 331Network Design*Performance Upgrades

Network Design

INFO 331Network Design*Flow ConsiderationsThe flow spec should help tell which flows have similar requirements, and which need special consideration for performance, capacity, or other needsFind backbone flows, which collect smaller flowsCapacity planning is based on estimating usage, to compare against available technologiesService planning also compares levels of service needed

Network Design

INFO 331Network Design*Guidelines for Tech EvalUse combined capacities for best-effort flows (generic Internet), and RMA, capacity, and/or delay requirements for predictable or guaranteed servicesGuideline 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.

Network Design

INFO 331Network Design*Guidelines for Tech Eval (1)For examples which are technology-dependent, for predictable service:Quality-of-service levels in ATMCommitted information rate levels in frame relayDifferentiated service or integrated service levels in IPGuaranteed service gets even messier!

Network Design

INFO 331Network Design*Guidelines for Tech Eval (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

INFO 331Network Design*Guidelines for Tech Eval (3)Specific flows in the flow spec can be mapped to the best technology solutionConstraints in terms of RMA, delay, cost or QoS can be used to eliminate technologiesInteraction with existing networks needs to be checked for possible conflictsFacility or other large scale issues may need to be addressed too

Network Design

INFO 331Network Design*Segmenting the NetworkNow that we have nailed down technology choices, we can address the detailed structure of the network how its segmentedSegmenting focuses technology selectionWe could do it by geography, groups of users (even virtual), or flow hierarchyGroups of users could belong to different organizations would that be a problem for security or privacy?

Network Design

INFO 331Network Design*Segmenting the NetworkA geographic example of segmenting

Network Design

INFO 331Network Design*Segmenting the NetworkA user-based view of segmenting

Network Design

INFO 331Network Design*Segmenting the NetworkA flow hierarchy-based example

Network Design

INFO 331Network Design*Segmenting the NetworkSegments 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.)

Network Design

INFO 331Network Design*Segmenting the NetworkSegmenting by types of function and feature

Network Design

INFO 331Network Design*Black Box MethodOnce segments have been defined, we can view each segment as black box(es)Know inputs and outputs, and dont worry about the inner details yetA segment could have several black boxes

Network Design

INFO 331Network Design*Black Box MethodThen for each black box, determine the exact technology needs within itThis lets us hide irrelevant information, and focus our technology decisions on critical infoNaturally we dont want to have all technology decisions made in a vacuum, or wildly different or incompatible technologies may be chosenCommon sense should prevail!

Network Design

INFO 331Network Design*SummaryNetwork design needs to understand and balance requirements from network users, applications, devices, and the external environmentFlow analysis helps capture capacity, delay, QoS, reliability, and other critical aspectsThen technology choices can be made based on segmenting the network by geography, user, flow spec, or functions provided

Network Design