Скачать презентацию Network Design Intro INFO 331 Network Design 1 Скачать презентацию Network Design Intro INFO 331 Network Design 1

947dfda836a19ccee73e8d5003258b0b.ppt

  • Количество слайдов: 132

Network Design Intro INFO 331 Network Design 1 Network Design Intro INFO 331 Network Design 1

Network Design l Through the Kurose text we’ve covered l l l The application, Network Design l Through the Kurose text we’ve covered l l l 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? INFO 331 Network Design 2

Network Design l l Ok, that’s not a small question – we’ll just tickle Network Design l l Ok, that’s not a small question – we’ll just tickle the surface (not even scratch!) Main resources for this section are: l l INFO 331 Mc. Cabe, James D. (2003). Network Analysis, Architecture & Design (2 nd 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

Network Design Objective l Ultimately, our network design must answer some pretty basic questions Network Design Objective l Ultimately, our network design must answer some pretty basic questions l l 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 l INFO 331 May be effective, but result in over engineering Network Design 4

Network Design Objective l And while some uses of the network will need a Network Design Objective l And while some uses of the network will need a lot of bandwidth (multimedia), we may also need to address: l Security l l l Possible wireless connectivity Reliability and/or availability l INFO 331 Considering both internal and external threats Like speed for a car, how much are you willing to afford? Network Design 5

Network Design Phases l Designing a network is typically broken into three sections: l Network Design Phases l Designing a network is typically broken into three sections: l l l Determine requirements Define the overall architecture Choose technology and specific devices (Mc. Cabe, 2003) INFO 331 Network Design 6

Systems Methodology l There’s lots of room for refining these sections (Teare, 2004) l Systems Methodology l There’s lots of room for refining these sections (Teare, 2004) l l l l 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 l For a network design to work well, we need to Two Main Principles l For a network design to work well, we need to balance between l Hierarchy – how much network traffic flows connect in tiers of organization l l INFO 331 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

Two Main Principles (Mc. Cabe, 2003) INFO 331 Network Design 9 Two Main Principles (Mc. Cabe, 2003) INFO 331 Network Design 9

Plan Ahead! l The 80/20 rule applies here l l l 80% of the Plan Ahead! l The 80/20 rule applies here l l l 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? l Yes, determining the requirements for a network probably isn’t as much fun Requirements? l Yes, determining the requirements for a network probably isn’t as much fun as shopping for really expensive hardware l l INFO 331 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

Requirements l l We need to develop the low level design and the higher Requirements l l We need to develop the low level design and the higher level architecture, and understand the environment in which they operate We also need to prove that the design we’ve chosen is ‘just right’ (Southey, 1837) l l INFO 331 Is that $2 million network backbone really enough to meet our needs? How do we know $500, 000 wouldn’t have been good enough? Network Design 12

Requirements l Part of this process is managing the customer’s expectations l l INFO Requirements l Part of this process is managing the customer’s expectations l l INFO 331 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 Network Design 13

Requirements l We need to use a systems approach for understanding the network l Requirements l We need to use a systems approach for understanding the network l l 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? INFO 331 Network Design 14

Requirements l Consider how devices communicate Images from (Mc. Cabe, 2003) unless noted otherwise Requirements l Consider how devices communicate Images from (Mc. Cabe, 2003) unless noted otherwise INFO 331 Network Design 15

Requirements l What services are expected from the network? l Typical performance levels might Requirements l What services are expected from the network? l Typical performance levels might include capacity, delay time, reliability l l l Functions include security, accounting, scheduling, management l INFO 331 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 Defining a security or privacy level for a group of users or an organization Network Design 16

Requirements l Service requirements could include the Qo. S (quality of service) guarantees (ATM, Requirements l Service requirements could include the Qo. S (quality of service) guarantees (ATM, Intserv, Diffserv, etc. ) l INFO 331 This connects to network management monitoring of network performance Network Design 17

Requirements l Capacity refers to the ability to transfer data l l Bandwidth is Requirements l Capacity refers to the ability to transfer data l l Bandwidth is 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. l INFO 331 Kind of like hard drive actual capacity is always less than advertised, due to formatting Network Design 18

Requirements Analysis l l Given these concepts, how do we describe requirements for a Requirements Analysis l l Given these concepts, how do we describe requirements for a network? Need a process to filter or classify requirements l l 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 l Requirements can come from many aspects of the network system l Requirements Analysis l Requirements can come from many aspects of the network system l User Requirements Application Requirements Device Requirements Network Requirements Other Requirements INFO 331 Network Design l l 20

User Requirements l User requirements are often qualitative and very high level l INFO User Requirements l User requirements are often qualitative and very high level l INFO 331 What is ‘fast enough’ for download? System response (RTT)? How good does video need to be? What’s my budget? Network Design 21

Application Requirements l What types of apps are we using? l l l Mission-critical Application Requirements l What types of apps are we using? l l l 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? INFO 331 Network Design 22

Application Requirements l What groups of apps are being used? l l l l Application Requirements l What groups of apps are being used? l l l l INFO 331 Telemetry/command 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 l l Where are the apps located? Are some only used in Application Requirements l l Where are the apps located? Are some only used in certain locations? INFO 331 Network Design 24

Device Requirements l What kinds of devices are on your network? l l l Device Requirements l What kinds of devices are on your network? l l l INFO 331 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

Device Requirements l Specialized devices are often locationspecific INFO 331 Network Design 26 Device Requirements l Specialized devices are often locationspecific INFO 331 Network Design 26

Device Requirements l We want an understanding of the device’s performance – its ability Device Requirements l We want an understanding of the device’s performance – its ability to process data from the network l l INFO 331 Device I/O rates Delay time for performing a given app function Network Design 27

Device Requirements l Performance results from many factors l l l INFO 331 Storage Device Requirements l Performance results from many factors l l l 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 l The device locations are also critical l l INFO 331 Often Device Requirements l The device locations are also critical l l INFO 331 Often generic devices can be grouped by their quantity Servers and specialized stuff are shown individually Network Design 29

Network Requirements l l Network requirements (sounds kinda redundant) are the requirements for interacting Network Requirements l l 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 l Issues with network integration include l Scaling dependencies – how will Network Requirements l Issues with network integration include l Scaling dependencies – how will the size of the existing network affect the new one? l l l INFO 331 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

Network Requirements l Network, system, and support service dependencies l l Interoperability dependencies l Network Requirements l Network, system, and support service dependencies l l Interoperability dependencies l l INFO 331 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 Qo. S guarantees, if any Network obsolescence – do protocols or technologies become obsolete during transition? Network Design 32

Network Requirements l Network management and security issues need to be addressed throughout development Network Requirements l Network management and security issues need to be addressed throughout development l l How will the network be monitored for events? Monitoring for network performance? l l l INFO 331 What is the hierarchy for management data flow? Network configuration? Troubleshoot support? Network Design 33

Network Requirements l Security analysis can include the severity (effect) of an attack, and Network Requirements l Security analysis can include the severity (effect) of an attack, and its probability of occurrence Effect/ Probability User Devices Servers Network Software Services Data Unauthorized Access B/A B/B C/B A/B B/C A/B Unauthorized Disclosure B/C B/B C/C A/B B/C A/B Denial of Service B/B B/B B/B D/D Theft A/D B/D A/B C/C A/B Corruption A/C B/C C/C A/B D/D A/B Viruses B/B B/B B/C D/D Physical Damage A/D B/C C/C D/D D/D Effect: Probability: C: Disruptive A: Certain C: Likely B: Disabling INFO 331 A: Destructive D: No Impact B: Unlikely D: Impossible Network Design 34

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

Other Requirements l l Confidence – what is the data loss rate when the Other Requirements l l 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 l System architecture may be altered to remain within cost constraints l INFO 331 This is a good reason to present the customer with design choices, so they see the impact of cost versus performance Network Design 36

Other Requirements l Enterprise requirements typically include integration of your network with existing standards Other Requirements l 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 l A requirements specification is a document which summarizes the Requirements Spec and Map l A requirements specification is a document which summarizes the requirements for (here) a network l l 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) INFO 331 Network Design 38

Requirements Spec and Map l l l Priority can provide additional numeric distinction within Requirements Spec and Map l l l 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 INFO 331 Date Type Description Gathered/Derived Network Design Locations Status Priority 39

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

Requirements Analysis Process l l So, how do we determine what the requirements are Requirements Analysis Process l l So, how do we determine what the requirements are for our network? Collect requirements service metrics, and delays to help develop and map requirements INFO 331 Network Design 41

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

Initial Conditions l Why is the network being designed? What are the goals for Initial Conditions l Why is the network being designed? What are the goals for its architecture & design? l l l INFO 331 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

Initial Conditions l What project constraints are there? l l l Funding, organizations involved, Initial Conditions l What project constraints are there? l l l 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? l INFO 331 The former is easier to handle, of course Network Design 44

Customer and User l Customer expectations need to be set quickly l l l Customer and User l Customer expectations need to be set quickly l l l What order of magnitude is the project, and does that match what they thought? Better to find out early on if there’s a big gap! Working with users is important, to know how they use the network and what problems they find important l INFO 331 Surveys, phone calls, personal meetings, and/or group discussions could be used Network Design 45

Customer and User l Look for red flags in early discussions l l l Customer and User l Look for red flags in early discussions l l l 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 INFO 331 Network Design 46

Requirements Management l The requirements you develop need to be tracked and managed, just Requirements Management l The requirements you develop need to be tracked and managed, just like any system’s requirements l l l 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 INFO 331 Network Design 47

Service Metrics l Service metrics are characteristics measured or derived from the network l Service Metrics l Service metrics are characteristics measured or derived from the network l l Metrics must be configurable, measurable, and verifiable RMA metrics might include l l l INFO 331 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

Service Metrics l Related RMA metrics include l l l Uptime and downtime (percentage Service Metrics l Related RMA metrics include l l l Uptime and downtime (percentage of total time) Error and loss rates at various levels, such as packet error rate, bit error rate (BER), cell loss ratio (CLR), cell misinsertion ratio (CMR), frame and packet loss rates Service metrics for capacity include: l l INFO 331 Data rates – peak data rate, sustained data rate, and minimum data rate Data sizes – burst sizes and durations Network Design 49

Service Metrics l Service metrics for delay include: l l End-to-end or round-trip delay Service Metrics l Service metrics for delay include: l l 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) INFO 331 Network Design 50

Service Metrics l MIB Variables often used as service metrics: l l l l Service Metrics l MIB Variables often used as service metrics: l l l l 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 l Tools for making service metric measurements include l l l Ping, Metrics Tools l Tools for making service metric measurements include l l l Ping, pathchar, traceroute, TCPdump Packet capture utilities: Ethereal, Sniffer, and Etherpeak Then summarize the metrics collection approach Service Metric Where Metric Will Be Measured in System Measurement Method 1 LAN Delay Between NM Device and Each Router in LAN Ping 2 WAN Delay 1 Between NM Device and Local Router Interface to WAN Ping 3 WAN Delay 2 Between NM Device and Remote Router Interface to WAN Ping 4 LAN Packet Loss At Each Local Router SNMP INFO 331 Network Design 52

Characterizing Behavior l l Next we can analyze how users and apps use the Characterizing Behavior l l Next we can analyze how users and apps use the existing network We could use simulations or models to assess network behavior l l That’s way beyond the scope here! User behavior is looking for patterns in how people use apps l INFO 331 How many users, how frequently, how long per session, how much data they use Network Design 53

Characterizing Behavior l Application behavior includes looking at how each app uses the network Characterizing Behavior l Application behavior includes looking at how each app uses the network l l 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 INFO 331 Network Design 54

RMA Requirements l Reliability is a common measurement l l l Mean time between RMA Requirements l Reliability is a common measurement l l l 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 l Availability relates failures to repair time l l Scheduled maintenance time RMA Requirements l Availability relates failures to repair time l l Scheduled maintenance time doesn’t count against availability Uptime and downtime measure those percentages when the system is up or down l l l 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 l Thresholds and limits can be defined for RMA measures l l RMA Requirements l Thresholds and limits can be defined for RMA measures l l l 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 l Various delays can have a strong impact on network requirements l Delay Requirements l Various delays can have a strong impact on network requirements l l l INFO 331 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 Network Design 58

Delay Requirements l INTD and HRT help distinguish burst from bulk apps INFO 331 Delay Requirements l INTD and HRT help distinguish burst from bulk apps INFO 331 Network Design 59

Delay Requirements l End-to-end and round-trip delays can be network requirements l l We’ve Delay Requirements l End-to-end and round-trip delays can be network requirements l l We’ve used ping to get RTT (round trip time) Delay variation can be defined for multimedia apps – typically is 1 -2% of end-to-end delay INFO 331 Network Design 60

Capacity Requirements l Much of the needed capacity of a network derives from key Capacity Requirements l Much of the needed capacity of a network derives from key applications that are especially intense in such areas l l Peak data rate Minimum acceptable data rate Sustained (long term) data rate We need to distinguish apps that CAN use a lot of capacity (if it’s available), versus those that MUST use a lot INFO 331 Network Design 61

Data Rates l Data rates for an app can be measured at many levels Data Rates l Data rates for an app can be measured at many levels of the protocols l l App, network, etc. Most TCP apps will take what’s available, but back off when the network gets crowded (why? ) Often we may need to identify where the performance bottleneck is located It helps to get a rough idea of typical app performance INFO 331 Network Design 62

Typical App Capacity Needs Application Average Completion Time (Seconds) Average Data Size (Bytes) Distributed Typical App Capacity Needs Application Average Completion Time (Seconds) Average Data Size (Bytes) Distributed Computing (Batch Mode) 103 107 Web Transactions 10 104 Database Entries/Queries 2– 5 103 Payroll Entries 10 102 Teleconference 103 105 INFO 331 Network Design 63

Data Rates l Sometimes a range of values is more helpful l Processing credit Data Rates l Sometimes a range of values is more helpful l 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 INFO 331 Network Design 64

Supplemental Performance l l Other non-functional requirements can be important to a network Operational Supplemental Performance l l Other non-functional requirements can be important to a network Operational Suitability is making sure your customer can operate the network once it’s running l l l 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 l l l How many shifts of operators will there be? How Operational Suitability l l l How many shifts of operators will there be? How well trained are the network operators? How often will hardware changes be needed? l l l 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 INFO 331 Network Design 66

Supportability l l Can the network’s level of performance be sustained over time? Is Supportability l l Can the network’s level of performance be sustained over time? Is affected by l l l INFO 331 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

Supportability l Maintenance of a system expects l l l Components are located where Supportability l Maintenance of a system expects l l l 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) INFO 331 Network Design 68

Supportability l l Workforce should be equivalent to the ones being replaced; or at Supportability l l Workforce should be equivalent to the ones being replaced; or at least as cheap overall Documentation typically includes l l l INFO 331 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

Supportability l Tools and test equipment describe what tools are needed to maintain the Supportability l Tools and test equipment describe what tools are needed to maintain the system l l 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 l INFO 331 How much are you will to invest in parts? Network Design 70

Supportability l All of this produces a concept for support of a network l Supportability l All of this produces a concept for support of a network l l l 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) INFO 331 Network Design 71

Supportability Level Tools and Test Equipment Organizational Common tools Operator consoles and controls Inexpensive Supportability Level Tools and Test Equipment Organizational Common tools Operator consoles and controls Inexpensive special tools Intermediate Depot INFO 331 Corrective Maintenance Day-to-day monitoring Troubleshooting Fault isolation Reconfiguring system Preventive Maintenance Monitoring performance Minor on-site cleaning and adjustments Special or expensive On-site repair of portable tools with offline equipment limited use Major on-site upgrades Supplement operators Equipment to refurbish components Scheduled overhaul or disassembly of LRUs Overhaul and refurbishment Network Design 72

Confidence l Confidence is the ability of a network to provide throughput at an Confidence l Confidence is the ability of a network to provide throughput at an acceptable error or loss rate l l 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) l INFO 331 Ping might be used to measure losses Network Design 73

Environment-specific Limits l What constitutes acceptable performance depends wildly on the industry or particular Environment-specific Limits l What constitutes acceptable performance depends wildly on the industry or particular environment of the network l l High-performance devices often drive the acceptable thresholds or limits Also consider if predictable or guaranteed performance is important l INFO 331 May lead to high Qo. S requirements, since best effort may not be good enough Network Design 74

Map and Spec l Then, as mentioned earlier, map out the requirements, and write Map and Spec l Then, as mentioned earlier, map out the requirements, and write them in a specification l l INFO 331 Make sure you and your customer are in agreement on the needs of the network Prioritize requirements, so if something has to give, it’s not critical to your customer Network Design 75

Flow Analysis l The requirements map is a great place to start analysis of Flow Analysis l The requirements map is a great place to start analysis of flows in your network l l We don’t want to model EVERY traffic (data) flow, just the important ones A traffic flow describes data movement, e. g. l l INFO 331 Source and/or destination addresses Type of information Directionality (bidirectional or unidirectional) Other aspects, such as Qo. S needs Network Design 76

Flow Analysis Flow Characteristics l l Later, flows can be broken down into subnet Flow Analysis Flow Characteristics l l 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-of. Day) Protocols Used Addresses/Ports Security/Privacy Requirements INFO 331 Network Design 77

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

Flow Analysis l l The requirements spec should be able to define flows by Flow Analysis l l 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 331 Network Design 79

Flow Analysis INFO 331 Network Design 80 Flow Analysis INFO 331 Network Design 80

Consolidate Flows INFO 331 Network Design 81 Consolidate Flows INFO 331 Network Design 81

Data Sources and Sinks l l l Look for devices (servers, special devices) which Data Sources and Sinks l l l 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 l Model the flows using common examples l l l Peer-to-peer Client-server Flow Models l Model the flows using common examples l l l 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 l All users or apps are equal Flows are all critical Peer-to-Peer Flow Model l All users or apps are equal Flows are all critical or none are Flows are all equivalent (have same specification) INFO 331 Network Design 84

Client-Server Flow Model l l Requests are small data amounts compared to responses, so Client-Server Flow Model l l 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 Hierarchical Client-Server INFO 331 Network Design 86

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

Flow Prioritization l Flows are typically prioritized based on many factors, only a couple Flow Prioritization l Flows are typically prioritized based on many factors, only a couple of which are technical l l INFO 331 Capacity, delay, RMA, and/or Qo. S 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! Network Design 88

Flow Specification l l l Like the requirements, the flows can be summarized in Flow Specification l l l 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 l l l INFO 331 Best effort algorithms only consider capacity Predictable flow req’ts consider capacity, delay, and RMA Guaranteed flow req’ts are treated separately Network Design 89

Network Architecture l l Now that we FINALLY have requirements and flows defined, we Network Architecture l l 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. l INFO 331 Similarly, we need several views of a network Network Design 90

Network Architecture l l Avoid thinking of just the physical components of a network Network Architecture l l 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 l l 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 l Measure network success by how well user, app, and device req’ts Network Architecture l Measure network success by how well user, app, and device req’ts are met functionally l l l 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 l INFO 331 See house analogy a couple slides back Network Design 92

Network Architecture l l The design of a network is more detailed, technology- and Network Architecture l l 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 l INFO 331 Each component is sort of a subsystem; so we’ll need to understand how they work together Network Design 93

Network Functions l The key functions are l l l Addressing and routing Network Network Functions l The key functions are l l l 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 331 Network Design 94

Basic Design Rules: Regions l Divide the network into regions, based on similar traffic Basic Design Rules: Regions l Divide the network into regions, based on similar traffic flows l l INFO 331 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

Addressing/Routing l l l Addressing applies MAC or IP addresses for devices Routing establishes Addressing/Routing l l l 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 331 Network Design 96

Addressing/Routing l Mechanisms for this architecture could be l l l Addressing: subnetting, supernetting, Addressing/Routing l Mechanisms for this architecture could be l l l Addressing: subnetting, supernetting, dynamic vs private addressing, VLANs, IP v 4 versus v 6, 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 331 Network Design 97

Network Management Arch. l l This decides how the network will be monitored and Network Management Arch. l l This decides how the network will be monitored and managed Types of mechanisms include l INFO 331 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 Network Design 98

Performance Architecture l This component defines how network performance will be established and managed Performance Architecture l This component defines how network performance will be established and managed l l INFO 331 Defines how network resources are allocated to users, apps, and devices Capacity planning, traffic engineering, Qo. S, access control, SLAs, policies, resource mgmt Balances end-to-end vs per-link prioritization Diff. Serv vs Int. Serv Network Design 99

Security Architecture l How do you protect system resources and data from theft, damage, Security Architecture l How do you protect system resources and data from theft, damage, Do. S, and unauthorized access? l l 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 331 Network Design 100

Reference Architecture l All these components need to be reconciled with each other l Reference Architecture l All these components need to be reconciled with each other l l l 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 331 Network Design 101

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

Architectural Models for network architecture can be based on topology, flow, or functionality l Architectural Models for network architecture can be based on topology, flow, or functionality l l l Generally more than one model is needed Often start with topology model and add other(s) Topology models are mainly l l INFO 331 The WAN/MAN/LAN model – basic hierarchical structure The core/distribution/access model – think of getting videos from CNN Network Design 103

Topology Models INFO 331 Network Design 104 Topology Models INFO 331 Network Design 104

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

Functionality Models l These models focus on supporting key functions in the network l Functionality Models l These models focus on supporting key functions in the network l l l 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 fulfill These all require knowing location data INFO 331 Network Design 106

Functionality Models l Service provider and intranet/ extranet models INFO 331 Network Design 107 Functionality Models l Service provider and intranet/ extranet models INFO 331 Network Design 107

Functionality Models l l No cartoon for single- or multi-tier model; could be a Functionality Models l l 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 l The flow and functional models overlap in focus with the core/distribution/access Applying Models l The flow and functional models overlap in focus with the core/distribution/access model INFO 331 Network Design 109

System Architecture l The network (reference) architecture connects to the rest of the organization System Architecture l The network (reference) architecture connects to the rest of the organization l l 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 l After the types of mechanisms in the reference architecture have been Selecting Technologies l After the types of mechanisms in the reference architecture have been selected, we can start choosing more specific design technologies for our network l l This is where most people start ‘network design’ Technologies need to be consistent with the goals of the network l INFO 331 What is most important – cost, capacity, Qo. S, security, manageability…? Network Design 111

Selecting Technologies l l The goals may be different in different parts of the Selecting Technologies l l 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? l INFO 331 RMA, capacity, cost, performance, supportability, etc. can be your basis for judging technologies Network Design 112

Selecting Technologies l Consider a car-buying analogy; if you’re buying a car, you might Selecting Technologies l Consider a car-buying analogy; if you’re buying a car, you might consider many characteristics to make your choice l l 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 331 Network Design 113

Selecting Technologies l l Consider also design and configuration issues for technology, not just Selecting Technologies l l Consider also design and configuration issues for technology, not just price-vsperformance For example, many older technologies have built-in ARP capability l l Ethernet, Token Ring, and FDDI all do this But newer non-broadcast multiple access (NBMA) technologies don’t have this l INFO 331 ATM, frame relay, SMDS, Hi. PPI Network Design 114

Selecting Technologies l l l As a result, using NBMA technologies requires separate support Selecting Technologies l l l 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? l l INFO 331 Stateless, hard state, or soft state Connections require more work from the network Network Design 115

Technology Functions l What features and functions will each technology offer to users, apps, Technology Functions l What features and functions will each technology offer to users, apps, and devices? l l Does it depend on the local infrastructure? Are flows asymmetric, like Web access? l l Are there distance limitations? l INFO 331 HFC and DSL both take advantage of this Affects delay time, buffering, reliability needs, and HW Network Design 116

Performance Upgrades l How easily can your design be upgraded? l l Generally focus Performance Upgrades l How easily can your design be upgraded? l l 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 Hi. PPI l l l INFO 331 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

Performance Upgrades INFO 331 Network Design 118 Performance Upgrades INFO 331 Network Design 118

Flow Considerations l The flow spec should help tell which flows have similar requirements, Flow Considerations l The flow spec should help tell which flows have similar requirements, and which need special consideration for performance, capacity, or other needs l l l INFO 331 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

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

Guidelines for Tech Eval l For examples which are technologydependent, for predictable service: l Guidelines for Tech Eval l For examples which are technologydependent, for predictable service: l l 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 l Guideline 2: When best-effort, predictable, and/or guaranteed capacities are Guidelines for Tech Eval l 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 331 Network Design 122

Guidelines for Tech Eval l Specific flows in the flow spec can be mapped Guidelines for Tech Eval l Specific flows in the flow spec can be mapped to the best technology solution l l l INFO 331 Constraints in terms of RMA, delay, cost or Qo. S 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 Network Design 123

Segmenting the Network l Now that we have nailed down technology choices, we can Segmenting the Network l Now that we have nailed down technology choices, we can address the detailed structure of the network – how it’s segmented l l Segmenting focuses technology selection We could do it by geography, groups of users (even virtual), or flow hierarchy l INFO 331 Groups of users could belong to different organizations – would that be a problem for security or privacy? Network Design 124

Segmenting the Network l A geographic example of segmenting INFO 331 Network Design 125 Segmenting the Network l A geographic example of segmenting INFO 331 Network Design 125

Segmenting the Network l A user-based view of segmenting INFO 331 Network Design 126 Segmenting the Network l A user-based view of segmenting INFO 331 Network Design 126

Segmenting the Network l A flow hierarchy-based example INFO 331 Network Design 127 Segmenting the Network l A flow hierarchy-based example INFO 331 Network Design 127

Segmenting the Network l l Segments can include defining broadcast domains, collision domains, or Segmenting the Network l l 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 331 Network Design 128

Segmenting the Network l Segmenting by types of function and feature INFO 331 Network Segmenting the Network l Segmenting by types of function and feature INFO 331 Network Design 129

Black Box Method l Once segments have been defined, we can view each segment Black Box Method l Once segments have been defined, we can view each segment as black box(es) l l INFO 331 Know inputs and outputs, and don’t worry about the inner details yet A segment could have several black boxes Network Design 130

Black Box Method l l l Then for each black box, determine the exact Black Box Method l l l 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 l INFO 331 Common sense should prevail! Network Design 131

Summary l l l Network design needs to understand balance requirements from network users, Summary l l l Network design needs to understand balance requirements from network users, applications, devices, and the external environment Flow analysis helps capture capacity, delay, Qo. S, reliability, and other critical aspects Then technology choices can be made based on segmenting the network by geography, user, flow spec, or functions provided INFO 331 Network Design 132