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

Loading in 2 Seconds...

play fullscreen
1 / 132

INFO 331 Computer Networking Technology II - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

INFO 331 Computer Networking Technology II. Network Design Intro Glenn Booker. Network Design. Through the Kurose text we’ve covered The application, transport, network, & link layers Wireless and multimedia technologies Security Network management Not bad!

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

INFO 331 Computer Networking Technology II


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


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