INFO 331Network Design1 UNIT – III 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

INFO 331Network Design2 Flow Analysis

INFO 331Network Design3 Consolidate Flows

INFO 331Network Design4 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 331Network Design5 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 331Network Design6 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)

INFO 331Network Design7 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 331Network Design8 Hierarchical Client-Server

INFO 331Network Design9 Distributed Computing Behavior varies – inverse client-server, peer-to-peer, hybrid, etc.

INFO 331Network Design10 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!

INFO 331Network Design11 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

INFO 331Network Design12 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

INFO 331Network Design13 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

INFO 331Network Design14 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

INFO 331Network Design15 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

INFO 331Network Design16 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!

INFO 331Network Design17 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

INFO 331Network Design18 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

INFO 331Network Design19 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

INFO 331Network Design20 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 331Network Design21 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

INFO 331Network Design22 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

INFO 331Network Design23 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

INFO 331Network Design24 Reference Architecture Req’ts dictate which components are favored, if any

INFO 331Network Design25 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

INFO 331Network Design26 Topology Models

INFO 331Network Design27 Flow Models We’ve already seen these (slides 84-87) – Peer-to-peer – Client-server – Hierarchical client-server – Distributed-computing

INFO 331Network Design28 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

INFO 331Network Design29 Functionality Models Service provider and intranet/ extranet models

INFO 331Network Design30 Functionality Models No cartoon for single- or multi-tier model; could be a combination of the others End-to-end model

INFO 331Network Design31 Applying Models The flow and functional models overlap in focus with the core/distribution/access model

INFO 331Network Design32 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 331Network Design33 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…?

INFO 331Network Design34 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

INFO 331Network Design35 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

INFO 331Network Design36 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

INFO 331Network Design37 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

INFO 331Network Design38 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

INFO 331Network Design39 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 Mb/s OC Mb/s OC Gb/s OC Gb/s OC Gb/s

INFO 331Network Design40 Performance Upgrades

INFO 331Network Design41 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

INFO 331Network Design42 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 331Network Design43 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!

INFO 331Network Design44 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.

INFO 331Network Design45 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 331Network Design46 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?

INFO 331Network Design47 Segmenting the Network A geographic example of segmenting

INFO 331Network Design48 Segmenting the Network A user-based view of segmenting

INFO 331Network Design49 Segmenting the Network A flow hierarchy-based example

INFO 331Network Design50 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.)

INFO 331Network Design51 Segmenting the Network Segmenting by types of function and feature

INFO 331Network Design52 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

INFO 331Network Design53 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!

INFO 331Network Design54 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