Download
info 331 computer networking technology ii n.
Skip this Video
Loading SlideShow in 5 Seconds..
INFO 331 Computer Networking Technology II PowerPoint Presentation
Download Presentation
INFO 331 Computer Networking Technology II

INFO 331 Computer Networking Technology II

178 Vues Download Presentation
Télécharger la présentation

INFO 331 Computer Networking Technology II

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. INFO 331Computer Networking Technology II Network Design Intro Glenn Booker Network Design

  2. Network Design • Through the Kurose text we’ve covered • The application, transport, network, & link layers • Wireless and multimedia technologies • Security • Network management • Not bad! • So how does all this come together to help create a network? Network Design

  3. Network Design • Ok, that’s not a small question – we’ll just tickle the surface (not even scratch!) • Main resources for this section are: • McCabe, James D. (2003). Network Analysis, Architecture & Design (2nd Ed.). San Francisco: Morgan Kaufmann Publishers. [Chapters 1-5, 10] • Teare, Diane. (2004). CCDA Self-Study: Designing for Cisco Internetworking Solutions (DESGN). Indianapolis: Cisco Press. Network Design

  4. Network Design Objective • Ultimately, our network design must answer some pretty basic questions • What stuff do we get for the network? • How do we connect it all? • How do we have to configure it to work right? • Traditionally this meant mostly capacity planning – having enough bandwidth to keep data moving • May be effective, but result in over engineering Network Design

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

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

  7. Systems Methodology • There’s lots of room for refining these sections (Teare, 2004) • Identify customer requirements • Characterize the existing network • Design topology • Plan the implementation • Build a pilot network • Document the design • Implement the design, and monitor its use Network Design

  8. Two Main Principles • For a network design to work well, we need to balance between • Hierarchy – how much network traffic flows connect in tiers of organization • Like tiers on an org chart, hierarchy provides separation and structure for the network • Interconnectivity – offsets hierarchy by allowing connections between levels of the design, often to improve performance between them Network Design

  9. Two Main Principles (McCabe, 2003) Network Design

  10. Plan Ahead! • The 80/20 rule applies here • 80% of the cost of a network is its operation and support • Only 20% is the cost of designing and implementing it • So plan for easy operation, maintenance, and upgrade of the network Network Design

  11. Requirements? Booooring! • Yes, determining the requirements for a network probably isn’t as much fun as shopping for really expensive hardware • And that may be why many networks are poorly designed – no one bothered to think through their requirements! • Many people will jump to a specific technology or hardware solution, without fully considering other options – the obvious solution may not be the best one Network Design

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

  13. Requirements • Part of this process is managing the customer’s expectations • They may expect a much simpler or more expensive solution than is really needed • Showing analysis of different design options, technologies, or architectures can help prove you have the best solution Network Design

  14. Requirements • We need to use a systems approach for understanding the network • The system goes far beyond the network hardware, software, etc. • Also includes understanding the users, applications or services, and external environment • How do these need to interact? • What does the rest of the organization expect from the network? Network Design

  15. Requirements • Consider how devices communicate Images from (McCabe, 2003) unless noted otherwise Network Design

  16. Requirements • What services are expected from the network? • Typical performance levels might include capacity, delay time, reliability • Providing 1.5 Mb/s peak capacity to a remote user • Guaranteeing a maximum round-trip delay of 100 ms to servers in a server farm • Functions include security, accounting, scheduling, management • Defining a security or privacy level for a group of users or an organization Network Design

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

  18. Requirements • Capacity refers to the ability to transfer data • Bandwidth is the theoretical capacity of some part of the network • Throughput is the actual capacity, which is less than the bandwidth, due to protocol overhead, network delays, etc. • Kind of like hard drive actual capacity is always less than advertised, due to formatting Network Design

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

  20. Requirements Analysis • Requirements can come from many aspects of the network system • User Requirements • Application Requirements • Device Requirements • Network Requirements • Other Requirements Network Design

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

  22. Application Requirements • What types of apps are we using? • Mission-critical • Rate-critical • Real-time and/or interactive • How sensitive are apps to RMA (reliability, maintainability, availability)? • What capacity is needed? • What delay time is acceptable? Network Design

  23. Application Requirements • What groups of apps are being used? • Telemetry/command and control - remote devices • Visualization and simulation • Distributed computing • Web development, access, and use • Bulk data transport – FTP • Teleservice – VOIP, teleconference • Operations, admin, maintenance, and provisioning (OAM&P) – DNS, SMTP, SNMP • Client-server – ERP, SCM, CRM Network Design

  24. Application Requirements • Where are the apps located? • Are some only used in certain locations? Network Design

  25. Device Requirements • What kinds of devices are on your network? • Generic computing devices include normal PCs, Macs, laptops, handheld computers, workstations • Servers include all flavors of server – file, print, app/computation, and backup • Specialized devices include extreme servers (supercomputers, massively parallel servers), data collection systems (POS terminals), industry-specific devices, networked devices (cameras, tools), stoplights, ATMs, etc. Network Design

  26. Device Requirements • Specialized devices are often location-specific Network Design

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

  28. Device Requirements • Performance results from many factors • Storage performance, that is, flash, disk drive, or tape performance • Processor (CPU) performance • Memory performance (access times) • Bus performance (bus capacity and arbitration efficiency) • OS performance (effectiveness of the protocol stack and APIs) • Device driver performance Network Design

  29. Device Requirements • The device locations are also critical • Often generic devices can be grouped by their quantity • Servers and specialized stuff are shown individually Network Design

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

  31. Network Requirements • Issues with network integration include • Scaling dependencies – how will the size of the existing network affect the new one? • Will the existing network change structure, or just add on a new wing? • Location dependencies – interaction between old and new networks could change the location of key components • Performance constraints – existing network could limit performance of the new one Network Design

  32. Network Requirements • Network, system, and support service dependencies • Addressing, security, routing protocols and network management can all be affected by the existing network • Interoperability dependencies • Changes in technology or media at the interfaces between networks need to be accounted for, as well as QoS guarantees, if any • Network obsolescence – do protocols or technologies become obsolete during transition? Network Design

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

  34. Network Requirements • Security analysis can include the severity (effect) of an attack, and its probability of occurrence Network Design

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

  36. Other Requirements • Confidence – what is the data loss rate when the system is running at its required throughput? • Financial requirements can include not only the initial system cost, but also ongoing maintenance costs • System architecture may be altered to remain within cost constraints • This is a good reason to present the customer with design choices, so they see the impact of cost versus performance Network Design

  37. Other Requirements • Enterprise requirements typically include integration of your network with existing standards for voice, data, or other protocols Network Design

  38. Requirements Spec and Map • A requirements specification is a document which summarizes the requirements for (here) a network • Often it becomes a contractual obligation, so assumptions, estimates, etc. should be carefully spelled out • Requirements are classified by Status, as noted earlier (core/current, future, rejected, or informational requirement) Network Design

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

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

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

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

  43. Initial Conditions • Why is the network being designed? What are the goals for its architecture & design? • Upgrade technology and/or vendor • Improve performance to part or all of network • Support new users, applications, or devices • Solve perceived problems within system • Increase security • Support a new capability in system Network Design

  44. Initial Conditions • What project constraints are there? • Funding, organizations involved, existing network, facility limitations, schedule, political, etc. • Are users receptive to the new network? • Are user needs homogeneous, or are there multiple tiers of performance needs? • The former is easier to handle, of course Network Design

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

  46. Customer and User • Look for red flags in early discussions • Abuse of the term "real-time" • Availability as solely a percentage (99.99%) • "High performance" without verification or clarification • Highly variable, inconsistent requirements • Unrealistic expectations from the customer • Measure application performance using existing network (if possible) or a test bed Network Design

  47. Requirements Management • The requirements you develop need to be tracked and managed, just like any system’s requirements • Identify requirements by some form of ID and short name • Need a tool to track requirements, their status, changes, sources, etc. • Map location of apps and devices of the existing network Network Design

  48. Service Metrics • Service metrics are characteristics measured or derived from the network • Metrics must be configurable, measurable, and verifiable • RMA metrics might include • Reliability – mean time between failures (MTBFs) and mean time between mission critical failures (MTBCFs) • Maintainability – mean time to repair (MTTR) • Availability – MTBF, MTBCF, and MTTR Network Design

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

  50. Service Metrics • Service metrics for delay include: • End-to-end or round-trip delay • Latency • Delay variation • SNMP or CMIP (Common Management Information Protocol) can be used to configure these metrics, which are kept in the Management Information Base (MIB) Network Design